Partilhar via

Diretrizes de modelagem do Power BI para Power Platform

  • Artigo

O Microsoft Dataverse é a plataforma de dados padrão para muitos produtos de aplicativos de negócios da Microsoft, incluindo os aplicativos de tela Dynamics 365 Customer Engagement e Power Apps, e também o Dynamics 365 Customer Voice (anteriormente Microsoft Forms Pro), aprovações do Power Automatic, portais do Power Apps e outros.

Este artigo fornece orientação sobre como criar um modelo de dados do Power BI que se conecta ao Dataverse. Ele descreve as diferenças entre um esquema Dataverse e um esquema otimizado do Power BI e fornece orientação para expandir a visibilidade dos dados do seu aplicativo de negócios no Power BI.

Devido à sua facilidade de configuração, implantação rápida e adoção generalizada, o Dataverse armazena e gerencia um volume crescente de dados em ambientes em todas as organizações. Isso significa que há uma necessidade e oportunidade ainda maiores de integrar análises com esses processos. As oportunidades incluem:

  • Crie relatórios sobre todos os dados do Dataverse que vão além das restrições dos gráficos internos.
  • Forneça acesso fácil a relatórios relevantes e contextualmente filtrados dentro de um registro específico.
  • Aumente o valor dos dados do Dataverse integrando-os com dados externos.
  • Tire partido da inteligência artificial (IA) incorporada do Power BI sem a necessidade de escrever código complexo.
  • Aumentar a adoção de soluções Power Platform aumentando a sua utilidade e valor.
  • Forneça o valor dos dados em seu aplicativo aos tomadores de decisões de negócios.

Conectar o Power BI ao Dataverse

Conectar o Power BI ao Dataverse envolve a criação de um modelo de dados do Power BI. Você pode escolher entre três métodos para criar um modelo do Power BI.

  • Importar dados do Dataverse usando o conector Datavers: esse método armazena em cache (armazena) dados do Dataverse em um modelo do Power BI. Proporciona um desempenho rápido graças às consultas na memória. Ele também oferece flexibilidade de projeto aos modeladores, permitindo que eles integrem dados de outras fontes. Devido a esses pontos fortes, a importação de dados é o modo padrão ao criar um modelo no Power BI Desktop.
  • Importar dados do Dataverse usando o Azure Synapse Link: esse método é uma variação do método de importação, porque ele também armazena dados em cache no modelo do Power BI, mas faz isso conectando-se ao Azure Synapse Analytics. Usando o Azure Synapse Link for Dataverse, as tabelas Dataverse são replicadas continuamente para o Azure Synapse ou Azure Data Lake Storage (ADLS) Gen2. Essa abordagem é usada para gerar relatórios sobre centenas de milhares ou até milhões de registros em ambientes Dataverse.
  • Crie uma conexão DirectQuery usando o conector Dataverse: esse método é uma alternativa à importação de dados. Um modelo DirectQuery consiste apenas em metadados que definem a estrutura do modelo. Quando um usuário abre um relatório, o Power BI envia consultas nativas ao Dataverse para recuperar dados. Considere a criação de um modelo DirectQuery quando os relatórios devem mostrar dados Dataverse quase em tempo real ou quando o Dataverse deve impor segurança baseada em função para que os usuários possam ver apenas os dados que têm privilégios para acessar.

Importante

Embora um modelo DirectQuery possa ser uma boa alternativa quando você precisa de relatórios quase em tempo real ou imposição de segurança Dataverse em um relatório, isso pode resultar em desempenho lento para esse relatório.

Você pode aprender sobre as considerações para o DirectQuery mais adiante neste artigo.

Para determinar o método certo para seu modelo do Power BI, você deve considerar:

  • Desempenho de consultas
  • Volume de dados
  • Latência de dados
  • Segurança baseada em funções
  • Complexidade da configuração

Gorjeta

Para obter uma discussão detalhada sobre estruturas de modelo (importar, DirectQuery ou composto), seus benefícios e limitações e recursos para ajudar a otimizar modelos de dados do Power BI, consulte Escolher uma estrutura de modelo do Power BI.

Desempenho de consultas

As consultas enviadas para importar modelos são mais rápidas do que as consultas nativas enviadas para fontes de dados do DirectQuery. Isso ocorre porque os dados importados são armazenados em cache na memória e são otimizados para consultas analíticas (operações de filtro, agrupamento e resumo).

Por outro lado, os modelos DirectQuery só recuperam dados da origem depois que o usuário abre um relatório, resultando em segundos de atraso à medida que o relatório é renderizado. Além disso, as interações do usuário no relatório exigem que o Power BI consulte novamente a fonte, reduzindo ainda mais a capacidade de resposta.

Volume de dados

Ao desenvolver um modelo de importação, você deve se esforçar para minimizar os dados carregados no modelo. É especialmente verdadeiro para modelos grandes, ou modelos que você prevê que crescerão para se tornarem grandes ao longo do tempo. Para obter mais informações, consulte Técnicas de redução de dados para modelagem de importação.

Uma conexão DirectQuery com Dataverse é uma boa opção quando o resultado da consulta do relatório não é grande. Um resultado de consulta grande tem mais de 20.000 linhas nas tabelas de origem do relatório, ou o resultado retornado ao relatório após a aplicação dos filtros é superior a 20.000 linhas. Nesse caso, você pode criar um relatório do Power BI usando o conector Dataverse.

Nota

O tamanho de 20.000 linhas não é um limite rígido. No entanto, cada consulta de fonte de dados deve retornar um resultado dentro de 10 minutos. Mais adiante neste artigo, você aprenderá como trabalhar dentro dessas limitações e sobre outras considerações de design do Dataverse DirectQuery.

Você pode melhorar o desempenho de modelos semânticos maiores usando o conector Dataverse para importar os dados para o modelo de dados.

Modelos semânticos ainda maiores, com várias centenas de milhares ou até milhões de linhas, podem se beneficiar do uso do Azure Synapse Link for Dataverse. Essa abordagem configura um pipeline gerenciado contínuo que copia dados do Dataverse para o ADLS Gen2 como arquivos CSV ou Parquet. O Power BI pode consultar um pool SQL sem servidor do Azure Synapse para carregar um modelo de importação.

Latência de dados

Quando os dados do Dataverse mudam rapidamente e os usuários do relatório precisam ver dados atualizados, um modelo DirectQuery pode fornecer resultados de consulta quase em tempo real.

Gorjeta

Você pode criar um relatório do Power BI que usa a atualização automática de página para mostrar atualizações em tempo real, mas somente quando o relatório se conecta a um modelo DirectQuery.

Os modelos de dados de importação devem concluir uma atualização de dados para permitir a geração de relatórios sobre alterações de dados recentes. Lembre-se de que há limitações no número de operações diárias agendadas de atualização de dados. Você pode agendar até oito atualizações por dia em uma capacidade compartilhada. Em uma capacidade Premium ou Microsoft Fabric, você pode agendar até 48 atualizações por dia, o que pode atingir uma frequência de atualização de 15 minutos.

Importante

Às vezes, este artigo se refere ao Power BI Premium ou suas assinaturas de capacidade (SKUs P). Lembre-se de que a Microsoft está atualmente consolidando opções de compra e desativando as SKUs do Power BI Premium por capacidade. Em vez disso, os clientes novos e existentes devem considerar a compra de assinaturas de capacidade de malha (SKUs F).

Para obter mais informações, consulte Atualização importante chegando ao licenciamento do Power BI Premium e Perguntas frequentes sobre o Power BI Premium.

Você também pode considerar o uso da atualização incremental para obter atualizações mais rápidas e desempenho quase em tempo real (disponível apenas com Premium ou Fabric).

Segurança baseada em funções

Quando há a necessidade de impor a segurança baseada em função, isso pode influenciar diretamente a escolha da estrutura do modelo do Power BI.

O Dataverse pode impor segurança complexa baseada em funções para controlar o acesso de registros específicos a usuários específicos. Por exemplo, um vendedor pode ter permissão para ver apenas suas oportunidades de vendas, enquanto o gerente de vendas pode ver todas as oportunidades de vendas para todos os vendedores. Você pode personalizar o nível de complexidade com base nas necessidades da sua organização.

Um modelo DirectQuery baseado em Dataverse pode se conectar usando o contexto de segurança do usuário de relatório. Dessa forma, o usuário do relatório verá apenas os dados que tem permissão para acessar. Essa abordagem pode simplificar o design do relatório, proporcionando que o desempenho seja aceitável.

Para melhorar o desempenho, você pode criar um modelo de importação que se conecta ao Dataverse. Nesse caso, você pode adicionar segurança em nível de linha (RLS) ao modelo, se necessário.

Nota

Pode ser um desafio replicar alguma segurança baseada em função do Dataverse como RLS do Power BI, especialmente quando o Dataverse impõe permissões complexas. Além disso, pode exigir gerenciamento contínuo para manter as permissões do Power BI sincronizadas com as permissões do Dataverse.

Para obter mais informações sobre o Power BI RLS, consulte Diretrizes de segurança em nível de linha (RLS) no Power BI Desktop.

Complexidade da configuração

Usar o conector Dataverse no Power BI, seja para modelos de importação ou DirectQuery, é simples e não requer nenhum software especial ou permissões elevadas do Dataverso. Essa é uma vantagem para organizações ou departamentos que estão começando.

A opção Azure Synapse Link requer acesso de administrador do sistema ao Dataverse e a determinadas permissões do Azure. Essas permissões do Azure são necessárias para configurar a conta de armazenamento e um espaço de trabalho Synapse.

Esta seção descreve padrões de design (e antipadrões) que você deve considerar ao criar um modelo do Power BI que se conecta ao Dataverse. Apenas alguns desses padrões são exclusivos do Dataverse, mas tendem a ser desafios comuns para os criadores do Dataverse quando criam relatórios do Power BI.

Concentre-se em um caso de uso específico

Em vez de tentar resolver tudo, concentre-se no caso de uso específico.

Esta recomendação é provavelmente o anti-padrão mais comum e facilmente o mais desafiador a evitar. Tentar construir um modelo único que atenda a todas as necessidades de relatórios de autoatendimento é um desafio. A realidade é que modelos bem-sucedidos são construídos para responder a perguntas em torno de um conjunto central de fatos sobre um único tópico central. Embora isso possa inicialmente parecer limitar o modelo, na verdade é empoderador porque você pode ajustar e otimizar o modelo para responder a perguntas dentro desse tópico.

Para ajudar a garantir que você tenha uma compreensão clara do propósito do modelo, faça a si mesmo as seguintes perguntas.

  • Que área temática suportará este modelo?
  • Quem é o público das reportagens?
  • A que perguntas estão os relatórios a tentar responder?
  • Qual é o modelo semântico mínimo viável?

Resista à combinação de várias áreas de tópico em um único modelo apenas porque o usuário do relatório tem perguntas em várias áreas de tópico que deseja abordar em um único relatório. Ao dividir esse relatório em vários relatórios, cada um com foco em um tópico (ou tabela de fatos) diferente, você pode produzir modelos muito mais eficientes, escaláveis e gerenciáveis.

Projetar um esquema em estrela

Os desenvolvedores e administradores do Dataverse que se sentem confortáveis com o esquema do Dataverse podem ficar tentados a reproduzir o mesmo esquema no Power BI. Esta abordagem é um anti-padrão, e é provavelmente a mais difícil de superar porque parece certo manter a consistência.

Dataverse, como um modelo relacional, é bem adequado para o seu propósito. No entanto, ele não foi projetado como um modelo analítico otimizado para relatórios analíticos. O padrão mais prevalente para modelar dados analíticos é um design de esquema em estrela. O esquema Star é uma abordagem de modelagem madura amplamente adotada por data warehouses relacionais. Ele requer que os modeladores classifiquem suas tabelas de modelo como dimensão ou fato. Os relatórios podem filtrar ou agrupar usando colunas de tabela de dimensão e resumir colunas de tabela de fatos.

O diagrama mostra um esquema em estrela compreendendo uma única tabela de fatos de oportunidade e tabelas de quatro dimensões.

Para obter mais informações, consulte Compreender o esquema em estrela e a importância para o Power BI.

Otimizar consultas do Power Query

O motor de mashup do Power Query esforça-se por conseguir a dobragem de consultas sempre que possível por razões de eficiência. Uma consulta que alcança dobrar delega o processamento de consultas ao sistema de origem.

O sistema de origem, neste caso o Dataverse, só precisa entregar resultados filtrados ou resumidos ao Power BI. Uma consulta dobrada geralmente é significativamente mais rápida e eficiente do que uma consulta que não se dobra.

Para obter mais informações sobre como você pode fazer dobragem de consulta, consulte Dobragem de consulta do Power Query.

Nota

A otimização do Power Query é um tópico amplo. Para obter uma melhor compreensão do que o Power Query está fazendo na criação e no momento da atualização do modelo no Power BI Desktop, consulte Diagnóstico de consulta.

Minimizar o número de colunas de consulta

Por predefinição, quando utiliza o Power Query para carregar uma tabela Dataverse, esta recupera todas as linhas e todas as colunas. Quando você consulta uma tabela de usuário do sistema, por exemplo, ela pode conter mais de 1.000 colunas. As colunas nos metadados incluem relações com outras entidades e pesquisas para rótulos de opção, de modo que o número total de colunas cresce com a complexidade da tabela Dataverse.

Tentar recuperar dados de todas as colunas é um antipadrão. Isso geralmente resulta em operações de atualização de dados estendidas e fará com que a consulta falhe quando o tempo necessário para retornar os dados exceder 10 minutos.

Recomendamos que você recupere apenas as colunas exigidas pelos relatórios. Muitas vezes, é uma boa ideia reavaliar e refatorar consultas quando o desenvolvimento do relatório estiver concluído, permitindo identificar e remover colunas não utilizadas. Para obter mais informações, consulte Técnicas de redução de dados para modelagem de importação (Remover colunas desnecessárias).

Além disso, certifique-se de que introduz o passo Remover colunas do Power Query com antecedência para que este volte à origem. Dessa forma, o Power Query pode evitar o trabalho desnecessário de extrair dados de origem apenas para descartá-los mais tarde (em uma etapa desdobrada).

Quando tem uma tabela que contém muitas colunas, poderá ser impraticável utilizar o construtor de consultas interativas do Power Query. Nesse caso, você pode começar criando uma consulta em branco. Em seguida, você pode usar o Editor Avançado para colar em uma consulta mínima que cria um ponto de partida.

Considere a consulta a seguir que recupera dados de apenas duas colunas da tabela de contas .

let
    Source = CommonDataService.Database("demo.crm.dynamics.com", [CreateNavigationProperties=false]),
    dbo_account = Source{[Schema="dbo", Item="account"]}[Data],
    #"Removed Other Columns" = Table.SelectColumns(dbo_account, {"accountid", "name"})
in
    #"Removed Other Columns"

Escrever consultas nativas

Quando você tem requisitos de transformação específicos, você pode obter um melhor desempenho usando uma consulta nativa escrita em Dataverse SQL, que é um subconjunto do Transact-SQL. Você pode escrever uma consulta nativa para:

  • Reduza o número de linhas (usando uma WHERE cláusula).
  • Agregar dados (usando as GROUP BY cláusulas e HAVING ).
  • Junte tabelas de uma maneira específica (usando a JOIN sintaxe ou APPLY ).
  • Use funções SQL suportadas.

Para obter mais informações, consulte:

Execute consultas nativas com a opção EnableFolding

O Power Query executa uma consulta nativa utilizando a Value.NativeQuery função.

Ao usar essa função, é importante adicionar a EnableFolding=true opção para garantir que as consultas sejam dobradas de volta ao serviço Dataverse. Uma consulta nativa não será dobrada, a menos que essa opção seja adicionada. Habilitar essa opção pode resultar em melhorias significativas de desempenho — até 97% mais rápido em alguns casos.

Considere a consulta a seguir que usa uma consulta nativa para originar colunas selecionadas da tabela de contas . A consulta nativa será dobrada porque a EnableFolding=true opção está definida.

let
    Source = CommonDataService.Database("demo.crm.dynamics.com"),
    dbo_account = Value.NativeQuery(
        Source,
        "SELECT A.accountid, A.name FROM account A"
        ,null
        ,[EnableFolding=true]
    )
in
     dbo_account

Você pode esperar obter as melhores melhorias de desempenho ao recuperar um subconjunto de dados de um grande volume de dados.

Gorjeta

A melhoria do desempenho também pode depender de como o Power BI consulta o banco de dados de origem. Por exemplo, uma medida que usa a COUNTDISTINCT função DAX não mostrou quase nenhuma melhoria com ou sem a dica de dobragem. Quando a fórmula de medida foi reescrita para usar a SUMX função DAX, a consulta foi dobrada, resultando em uma melhoria de 97% em relação à mesma consulta sem a dica.

Para obter mais informações, consulte Value.NativeQuery. (A EnableFolding opção não está documentada porque é específica apenas para determinadas fontes de dados.)

Acelerar a fase de avaliação

Se você estiver usando o conector Dataverse (anteriormente conhecido como Common Data Service), poderá adicionar a CreateNavigationProperties=false opção para acelerar o estágio de avaliação de uma importação de dados.

A etapa de avaliação de uma importação de dados itera através dos metadados de sua fonte para determinar todas as relações de tabela possíveis. Esses metadados podem ser extensos, especialmente para o Dataverse. Ao adicionar esta opção à consulta, está a informar o Power Query de que não pretende utilizar essas relações. A opção permite que o Power BI Desktop ignore esse estágio da atualização e passe para a recuperação dos dados.

Nota

Não use essa opção quando a consulta depender de colunas de relacionamento expandidas.

Considere um exemplo que recupera dados da tabela de contas . Contém três colunas relacionadas com o território: territory, territoryid e territoryidname.

A captura de tela mostra uma visualização dos dados para a tabela de contas de três colunas de território.

Quando você definir a CreateNavigationProperties=false opção, as colunas territoryid e territoryidname permanecerão, mas a coluna territory , que é uma coluna de relacionamento (mostra links de valor ), será excluída. É importante entender que as colunas de relacionamento do Power Query são um conceito diferente das relações de modelo, que propagam filtros entre tabelas de modelo.

Considere a consulta a seguir que usa a CreateNavigationProperties=false opção (na etapa Origem ) para acelerar a etapa de avaliação de uma importação de dados.

let
    Source = CommonDataService.Database("demo.crm.dynamics.com"
        ,[CreateNavigationProperties=false]),
    dbo_account = Source{[Schema="dbo", Item="account"]}[Data],
    #"Removed Other Columns" = Table.SelectColumns(dbo_account, {"accountid", "name", "address1_stateorprovince", "address1_country", "industrycodename", "territoryidname"}),
    #"Renamed Columns" = Table.RenameColumns(#"Removed Other Columns", {{"name", "Account Name"}, {"address1_country", "Country"}, {"address1_stateorprovince", "State or Province"}, {"territoryidname", "Territory"}, {"industrycodename", "Industry"}})
in
    #"Renamed Columns"

Ao usar essa opção, é provável que você experimente uma melhoria significativa de desempenho quando uma tabela Dataverse tiver muitos relacionamentos com outras tabelas. Por exemplo, como a tabela SystemUser está relacionada a todas as outras tabelas no banco de dados, o desempenho de atualização dessa tabela seria vantajoso definindo a CreateNavigationProperties=false opção.

Nota

Esta opção pode melhorar o desempenho da atualização de dados de tabelas de importação ou tabelas de modo de armazenamento duplo, incluindo o processo de aplicação de alterações na janela do Editor do Power Query. Ele não melhora o desempenho da filtragem cruzada interativa de tabelas de modo de armazenamento DirectQuery.

Resolver rótulos de escolha em branco

Se você descobrir que os rótulos de escolha do Dataverse estão em branco no Power BI, pode ser porque os rótulos não foram publicados no ponto de extremidade TDS (Fluxo de Dados Tabulares).

Nesse caso, abra o Dataverse Maker Portal, navegue até a área Soluções e selecione Publicar todas as personalizações. O processo de publicação atualizará o ponto de extremidade TDS com os metadados mais recentes, disponibilizando os rótulos de opção para o Power BI.

O Dataverse inclui a capacidade de sincronizar tabelas com o Azure Data Lake Storage (ADLS) e, em seguida, conectar-se a esses dados por meio de um espaço de trabalho do Azure Synapse. Com o mínimo de esforço, você pode configurar o Azure Synapse Link para preencher dados do Dataverse no Azure Synapse e permitir que as equipes de dados descubram insights mais profundos.

O Azure Synapse Link permite uma replicação contínua dos dados e metadados do Dataverse para o data lake. Ele também fornece um pool SQL interno sem servidor como uma fonte de dados conveniente para consultas do Power BI.

Os pontos fortes desta abordagem são significativos. Os clientes ganham a capacidade de executar cargas de trabalho de análise, business intelligence e aprendizado de máquina em dados do Dataverse usando vários serviços avançados. Os serviços avançados incluem Apache Spark, Power BI, Azure Data Factory, Azure Databricks e Azure Machine Learning.

Para criar um Azure Synapse Link for Dataverse, você precisará dos seguintes pré-requisitos.

  • Acesso do administrador do sistema ao ambiente Dataverse.
  • Para o Armazenamento do Azure Data Lake:
  • Para o espaço de trabalho Sinapse:
    • Você deve ter acesso a um espaço de trabalho Synapse e receber acesso Synapse Administrator . Para obter mais informações, consulte Funções e escopos RBAC Synapse integrados.
    • O espaço de trabalho deve estar na mesma região da conta de armazenamento do ADLS Gen2.

A configuração envolve entrar no Power Apps e conectar o Dataverse ao espaço de trabalho do Azure Synapse. Uma experiência semelhante a um assistente permite criar um novo link selecionando a conta de armazenamento e as tabelas a serem exportadas. Em seguida, o Azure Synapse Link copia dados para o armazenamento ADLS Gen2 e cria automaticamente exibições no pool SQL sem servidor interno do Azure Synapse. Em seguida, você pode se conectar a esses modos de exibição para criar um modelo do Power BI.

O diagrama mostra o Azure Synapse Link copiando dados para o armazenamento ADLS Gen2 e o Power BI se conectando ao Azure Synapse Analytics.

Gorjeta

Para obter documentação completa sobre como criar, gerenciar e monitorar o Azure Synapse Link, consulte Criar um Azure Synapse Link for Dataverse com seu Azure Synapse Workspace.

Criar um segundo banco de dados SQL sem servidor

Você pode criar um segundo banco de dados SQL sem servidor e usá-lo para adicionar exibições de relatório personalizadas. Dessa forma, você pode apresentar um conjunto simplificado de dados ao criador do Power BI que permite que ele crie um modelo com base em dados úteis e relevantes. O novo banco de dados SQL sem servidor torna-se a conexão de origem primária do criador e uma representação amigável dos dados provenientes do data lake.

O diagrama mostra o Azure Synapse Link copiando dados para o armazenamento ADLS Gen2 e o Power BI se conectando ao Azure Synapse Analytics. Inclui vistas de relatório personalizadas.

Essa abordagem fornece dados ao Power BI focados, enriquecidos e filtrados.

Você pode criar um banco de dados SQL sem servidor no espaço de trabalho do Azure Synapse usando o Azure Synapse Studio. Selecione Serverless como o tipo de banco de dados SQL e insira um nome de banco de dados. O Power Query pode ligar-se a esta base de dados ligando-se ao ponto de extremidade SQL da área de trabalho.

Criar vistas personalizadas

Você pode criar exibições personalizadas que encapsulam consultas de pool SQL sem servidor. Essas exibições servirão como fontes de dados diretas e limpas às quais o Power BI se conecta. Os pontos de vista devem:

  • Inclua os rótulos associados aos campos de escolha.
  • Reduza a complexidade incluindo apenas as colunas necessárias para a modelagem de dados.
  • Filtre linhas desnecessárias, como registros inativos.

Considere o modo de exibição a seguir que recupera dados da campanha.

CREATE VIEW [VW_Campaign]
AS
    SELECT
        [base].[campaignid] AS [CampaignID]
        [base].[name] AS [Campaign],
        [campaign_status].[LocalizedLabel] AS [Status],
        [campaign_typecode].[LocalizedLabel] AS [Type Code]
    FROM
        [<MySynapseLinkDB>].[dbo].[campaign] AS [base]
        LEFT OUTER JOIN [<MySynapseLinkDB>].[dbo].[OptionsetMetadata] AS [campaign_typecode]
            ON [base].[typecode] = [campaign_typecode].[option]
               AND [campaign_typecode].[LocalizedLabelLanguageCode] = 1033
               AND [campaign_typecode].[EntityName] = 'campaign'
               AND [campaign_typecode].[OptionSetName] = 'typecode'
        LEFT OUTER JOIN [<MySynapseLinkDB>].[dbo].[StatusMetadata] AS [campaign_status]
            ON [base].[statuscode] = [campaign_Status].[status]
               AND [campaign_status].[LocalizedLabelLanguageCode] = 1033
               AND [campaign_status].[EntityName] = 'campaign'
    WHERE
        [base].[statecode] = 0;

Observe que o modo de exibição inclui apenas quatro colunas, cada uma com um nome amigável. Há também uma WHERE cláusula para retornar apenas as linhas necessárias, neste caso campanhas ativas. Além disso, o modo de exibição consulta a tabela de campanha que ingressou nas tabelas OptionsetMetadata e StatusMetadata , que recuperam rótulos de escolha.

Gorjeta

Para obter mais informações sobre como recuperar metadados, consulte Acessar rótulos de escolha diretamente do Azure Synapse Link for Dataverse.

Consultar tabelas apropriadas

O Azure Synapse Link for Dataverse garante que os dados sejam continuamente sincronizados com os dados no data lake. Para atividades de alto uso, gravações e leituras simultâneas podem criar bloqueios que fazem com que as consultas falhem. Para garantir a confiabilidade ao recuperar dados, duas versões dos dados da tabela são sincronizadas no Azure Synapse.

  • Dados quase em tempo real: fornece uma cópia dos dados sincronizados do Dataverse por meio do Azure Synapse Link de maneira eficiente, detetando quais dados foram alterados desde que foram inicialmente extraídos ou sincronizados pela última vez.
  • Dados de instantâneo: fornece uma cópia somente leitura de dados quase em tempo real que são atualizados em intervalos regulares (neste caso, a cada hora). Os nomes das tabelas de dados de instantâneo _partitioned anexados ao seu nome.

Se você prevê que um grande volume de operações de leitura e gravação será executado simultaneamente, recupere dados das tabelas de instantâneo para evitar falhas de consulta.

Para obter mais informações, veja Aceder a dados em tempo quase real e dados de instantâneos só de leitura.

Conecte-se ao Synapse Analytics

Para consultar um pool SQL sem servidor do Azure Synapse, você precisará de seu ponto de extremidade SQL do espaço de trabalho. Você pode recuperar o ponto de extremidade do Synapse Studio abrindo as propriedades do pool SQL sem servidor.

No Power BI Desktop, você pode se conectar ao Azure Synapse usando o conector SQL do Azure Synapse Analytics. Quando solicitado para o servidor, insira o ponto de extremidade SQL do espaço de trabalho.

A captura de tela mostra a janela Banco de Dados do SQL Server usada para definir o valor do servidor.

Considerações sobre o DirectQuery

Há muitos casos de uso em que o uso do modo de armazenamento DirectQuery pode resolver seus requisitos. No entanto, usar o DirectQuery pode afetar negativamente o desempenho do relatório do Power BI. Um relatório que usa uma conexão DirectQuery com Dataverse não será tão rápido quanto um relatório que usa um modelo de importação. Geralmente, você deve importar dados para o Power BI sempre que possível.

Recomendamos que você considere os tópicos desta seção ao trabalhar com o DirectQuery.

Para obter mais informações sobre como determinar quando trabalhar com o modo de armazenamento DirectQuery, consulte Escolher uma estrutura de modelo do Power BI.

Usar tabelas de dimensões de modo de armazenamento duplo

Uma tabela de modo de armazenamento duplo é definida para usar os modos de armazenamento de importação e DirectQuery. No momento da consulta, o Power BI determina o modo mais eficiente a ser usado. Sempre que possível, o Power BI tenta satisfazer consultas usando dados importados porque é mais rápido.

Você deve considerar a configuração de tabelas de dimensões para o modo de armazenamento duplo, quando apropriado. Dessa forma, os visuais de segmentação de dados e as listas de cartões de filtro, que geralmente se baseiam em colunas de tabelas de dimensões, serão renderizados mais rapidamente porque serão consultados a partir de dados importados.

Importante

Quando uma tabela de dimensões precisa herdar o modelo de segurança Dataverse, não é apropriado usar o modo de armazenamento duplo.

As tabelas de fatos, que normalmente armazenam grandes volumes de dados, devem permanecer como tabelas de modo de armazenamento DirectQuery. Eles serão filtrados pelas tabelas de dimensões do modo de armazenamento duplo relacionadas, que podem ser unidas à tabela de fatos para obter filtragem e agrupamento eficientes.

Considere o seguinte design de modelo de dados. As tabelas tridimensionais, Proprietário, Conta e Campanha têm uma borda superior listrada, o que significa que estão definidas para o modo de armazenamento duplo.

A captura de tela mostra um diagrama de modelo com três tabelas de modo de armazenamento duplo, conforme descrito no parágrafo anterior.

Para obter mais informações sobre modos de armazenamento de tabela, incluindo armazenamento duplo, consulte Gerenciar modo de armazenamento no Power BI Desktop.

Ativar o início de sessão único

Ao publicar um modelo DirectQuery no serviço do Power BI, você pode usar as configurações do modelo semântico para habilitar o logon único (SSO) usando o Microsoft Entra ID OAuth2 para seus usuários de relatório. Você deve habilitar essa opção quando as consultas Dataverse tiverem que ser executadas no contexto de segurança do usuário do relatório.

Quando a opção SSO está habilitada, o Power BI envia as credenciais autenticadas do Microsoft Entra do usuário de relatório nas consultas para o Dataverse. Essa opção permite que o Power BI honre as configurações de segurança configuradas na fonte de dados.

A captura de tela mostra a janela de credenciais do modelo semântico com a opção SSO ativada.

Para obter mais informações, consulte Logon único (SSO) para fontes do DirectQuery.

Replicar filtros "Meus" no Power Query

Ao usar o Microsoft Dynamics 365 Customer Engagement (CE) e o Power Apps orientado por modelo criado no Dataverse, você pode criar modos de exibição que mostram apenas registros em que um campo de nome de usuário, como Proprietário, é igual ao usuário atual. Por exemplo, você pode criar visualizações chamadas "Minhas oportunidades abertas", "Meus casos ativos" e outras.

Considere um exemplo de como o modo de exibição Minhas Contas Ativas do Dynamics 365 inclui um filtro em que Proprietário é igual a usuário atual.

A captura de ecrã mostra os filtros configurados para a vista As Minhas Contas Ativas. A condição do filtro é proprietário igual a usuário atual.

Pode reproduzir este resultado no Power Query utilizando uma consulta nativa que incorpora o CURRENT_USER token.

Considere o exemplo a seguir que mostra uma consulta nativa que retorna as contas para o usuário atual. WHERE Na cláusula, observe que a coluna ownerid é filtrada CURRENT_USER pelo token.

let
    Source = CommonDataService.Database("demo.crm.dynamics.com", [CreateNavigationProperties=false],
    dbo_account = Value.NativeQuery(Source, "
        SELECT
            accountid, accountnumber, ownerid, address1_city, address1_stateorprovince, address1_country
        FROM account
        WHERE statecode = 0
            AND ownerid = CURRENT_USER
    ", null, [EnableFolding]=true])
in
    dbo_account

Ao publicar o modelo no serviço do Power BI, você deve habilitar o logon único (SSO) para que o Power BI envie as credenciais autenticadas do Microsoft Entra do usuário de relatório para o Dataverse.

Criar modelos de importação suplementares

Você pode criar um modelo DirectQuery que impõe permissões do Dataverse sabendo que o desempenho será lento. Em seguida, você pode complementar esse modelo com modelos de importação direcionados a assuntos ou públicos específicos que podem impor permissões RLS.

Por exemplo, um modelo de importação pode fornecer acesso a todos os dados do Dataverse, mas não impor permissões. Este modelo seria adequado para executivos que já têm acesso a todos os dados do Dataverse.

Como outro exemplo, quando o Dataverse impõe permissões baseadas em função por região de vendas, você pode criar um modelo de importação e replicar essas permissões usando RLS. Como alternativa, você pode criar um modelo para cada região de vendas. Em seguida, você pode conceder permissão de leitura a esses modelos (modelos semânticos) aos vendedores de cada região. Para facilitar a criação desses modelos regionais, você pode usar parâmetros e modelos de relatório. Para obter mais informações, consulte Criar e usar modelos de relatório no Power BI Desktop.

Conteúdos relacionados

Para obter mais informações relacionadas a este artigo, consulte os seguintes recursos.