Utilizar modelos compostos no Power BI Desktop

Anteriormente, no Power BI Desktop, quando você usava um DirectQuery em um relatório, nenhuma outra conexão de dados, seja DirectQuery ou importação, era permitida para esse relatório. Com os modelos compostos, essa restrição é removida. Um relatório pode incluir perfeitamente conexões de dados de mais de um DirectQuery ou importar conexão de dados, em qualquer combinação que você escolher.

O recurso de modelos compostos no Power BI Desktop consiste em três recursos relacionados:

• Modelos compostos: permite que um relatório tenha duas ou mais conexões de dados de grupos de origem diferentes. Esses grupos de origem podem ser uma ou mais conexões DirectQuery e uma conexão de importação, duas ou mais conexões DirectQuery ou qualquer combinação delas. Este artigo descreve modelos compostos em detalhes.

• Relações muitos-para-muitos: com modelos compostos, você pode estabelecer relações muitos-para-muitos entre tabelas. Essa abordagem remove os requisitos para valores exclusivos em tabelas. Também remove soluções anteriores, como a introdução de novas tabelas apenas para estabelecer relações. Para obter mais informações, consulte Aplicar muitas e muitas relações no Power BI Desktop.

• Modo de armazenamento: agora você pode especificar quais visuais consultam fontes de dados back-end. Esse recurso ajuda a melhorar o desempenho e reduzir a carga de back-end. Anteriormente, até mesmo visuais simples, como segmentações de dados, iniciavam consultas a fontes de back-end. Para obter mais informações, consulte Gerenciar o modo de armazenamento no Power BI Desktop.

Usar modelos compostos

Com modelos compostos, você pode se conectar a diferentes tipos de fontes de dados ao usar o Power BI Desktop ou o serviço do Power BI. Você pode fazer essas conexões de dados de algumas maneiras:

• Importando dados para o Power BI, que é a maneira mais comum de obter dados.
• Conectando-se diretamente aos dados em seu repositório de origem original usando o DirectQuery. Para saber mais sobre o DirectQuery, consulte DirectQuery no Power BI.

Quando você usa o DirectQuery, os modelos compostos possibilitam a criação de um modelo do Power BI, como um único arquivo .pbix do Power BI Desktop que executa uma ou ambas as seguintes ações:

• Combina dados de uma ou mais fontes DirectQuery.
• Combina dados de fontes do DirectQuery e importa dados.

Por exemplo, usando modelos compostos, você pode criar um modelo que combine os seguintes tipos de dados:

• Dados de vendas de um armazém de dados empresarial.
• Dados de destino de vendas de um banco de dados SQL Server departamental.
• Dados importados de uma folha de cálculo.

Um modelo que combina dados de mais de uma fonte DirectQuery ou que combina DirectQuery com dados de importação é chamado de modelo composto.

Você pode criar relações entre tabelas como sempre fez, mesmo quando essas tabelas vêm de fontes diferentes. Todas as relações que são de fonte cruzada são criadas com uma cardinalidade de muitos-para-muitos, independentemente de sua cardinalidade real. Você pode alterá-los para um-para-muitos, muitos-para-um ou um-para-um. Seja qual for a cardinalidade que você definir, as relações entre fontes têm um comportamento diferente. Não é possível usar funções DAX (Data Analysis Expressions) para recuperar valores do one lado oposto many . Você também pode ver um impacto no desempenho versus relacionamentos muitos-para-muitos dentro da mesma fonte.

Exemplo de um modelo composto

Para obter um exemplo de um modelo composto, considere um relatório que se conecta a um data warehouse corporativo no SQL Server usando DirectQuery. Neste caso, o armazém de dados contém dados de Vendas por País, Trimestre e Bicicleta (Produto), conforme mostrado na imagem a seguir:

Neste ponto, você pode criar visuais simples usando campos dessa fonte. A imagem a seguir mostra o total de vendas por ProductName, para um trimestre selecionado.

Mas e se você tiver dados em uma planilha do Excel sobre o gerente de produto atribuído a cada produto, juntamente com a prioridade de marketing? Se você quiser exibir o Valor de Vendas por Gerente de Produto, talvez não seja possível adicionar esses dados locais ao data warehouse corporativo. Ou pode levar meses, na melhor das hipóteses.

Talvez seja possível importar esses dados de vendas do data warehouse, em vez de usar o DirectQuery. E os dados de vendas podem ser combinados com os dados que você importou da planilha. No entanto, essa abordagem não é razoável, pelas razões que levaram ao uso do DirectQuery em primeiro lugar. As razões podem incluir:

• Alguma combinação das regras de segurança aplicadas na fonte subjacente.
• A necessidade de ser capaz de visualizar os dados mais recentes.
• A grande escala dos dados.

É aqui que entram os modelos compostos. Os modelos compostos permitem que você se conecte ao data warehouse usando o DirectQuery e, em seguida, use Obter dados para mais fontes. Neste exemplo, primeiro estabelecemos a conexão DirectQuery com o data warehouse corporativo. Usamos Obter dados, escolhemos Excel e navegamos até a planilha que contém nossos dados locais. Por fim, importamos a planilha que contém os Nomes de Produtos, o Gerente de Vendas atribuído e a Prioridade.

Na lista Campos, você pode ver duas tabelas: a tabela Bike original do SQL Server e uma nova tabela ProductManagers. A nova tabela contém os dados importados do Excel.

Da mesma forma, no modo de exibição Relacionamento no Power BI Desktop, agora vemos outra tabela chamada ProductManagers.

Agora precisamos relacionar essas tabelas com as outras tabelas do modelo. Como sempre, criamos uma relação entre a tabela Bike do SQL Server e a tabela ProductManagers importada. Ou seja, a relação é entre Bike[ProductName] e ProductManagers[ProductName]. Como discutido anteriormente, todas as relações que atravessam a origem têm como padrão a cardinalidade de muitos para muitos.

Agora que estabelecemos essa relação, ela é exibida no modo de exibição Relacionamento no Power BI Desktop, como seria de esperar.

Agora podemos criar elementos visuais usando qualquer um dos campos na lista Campos . Essa abordagem combina perfeitamente dados de várias fontes. Por exemplo, o SalesAmount total para cada Product Manager é exibido na imagem a seguir:

O exemplo a seguir exibe um caso comum de uma tabela de dimensão , como Produto ou Cliente, que é estendida com alguns dados extras importados de outro lugar. Também é possível que as tabelas usem o DirectQuery para se conectar a várias fontes. Para continuar com nosso exemplo, imagine que as metas de vendas por país e período são armazenadas em um banco de dados departamental separado. Como de costume, você pode usar Obter dados para se conectar a esses dados, conforme mostrado na imagem a seguir:

Como fizemos anteriormente, podemos criar relações entre a nova tabela e outras tabelas no modelo. Em seguida, podemos criar elementos visuais que combinam os dados da tabela. Vejamos novamente a visualização Relacionamentos , onde estabelecemos os novos relacionamentos:

A próxima imagem é baseada nos novos dados e relacionamentos que criamos. O visual no canto inferior esquerdo mostra o valor total das vendas versus o destino, e o cálculo da variância mostra a diferença. Os dados Valor de Vendas e Destino vêm de dois bancos de dados SQL Server diferentes.

Definir o modo de armazenamento

Cada tabela em um modelo composto tem um modo de armazenamento que indica se a tabela é baseada em DirectQuery ou importação. O modo de armazenamento pode ser visualizado e modificado no painel Propriedade . Para exibir o modo de armazenamento, clique com o botão direito do mouse em uma tabela na lista Campos e selecione Propriedades. A imagem a seguir mostra o modo de armazenamento para a tabela SalesTargets .

O modo de armazenamento também pode ser visualizado na dica de ferramenta para cada tabela.

Para qualquer arquivo do Power BI Desktop (um arquivo .pbix ) que contenha algumas tabelas do DirectQuery e algumas tabelas de importação, a barra de status exibe um modo de armazenamento chamado Misto. Você pode selecionar esse termo na barra de status e alternar facilmente todas as tabelas para importar.

Para obter mais informações sobre o modo de armazenamento, consulte Gerenciar o modo de armazenamento no Power BI Desktop.

Tabelas calculadas

Você pode adicionar tabelas calculadas a um modelo no Power BI Desktop que usa DirectQuery. As DAX (Data Analysis Expressions) que definem a tabela calculada podem fazer referência a tabelas importadas ou DirectQuery ou a uma combinação das duas.

As tabelas calculadas são sempre importadas e seus dados são atualizados quando você atualiza as tabelas. Se uma tabela calculada se referir a uma tabela DirectQuery, os elementos visuais que se referem à tabela DirectQuery sempre mostram os valores mais recentes na fonte subjacente. Como alternativa, os elementos visuais que se referem à tabela calculada mostram os valores no momento em que a tabela calculada foi atualizada pela última vez.

Implicações para a segurança

Os modelos compostos têm algumas implicações em termos de segurança. Uma consulta enviada a uma fonte de dados pode incluir valores de dados que foram recuperados de outra fonte. No exemplo anterior, o visual que mostra (Valor de Vendas) pelo Product Manager envia uma consulta SQL para o banco de dados relacional Sales. Essa consulta SQL pode conter os nomes dos Gerentes de Produto e seus Produtos associados.

Assim, as informações armazenadas na planilha agora são incluídas em uma consulta enviada ao banco de dados relacional. Se estas informações forem confidenciais, deve considerar as implicações para a segurança. Em particular, considere os seguintes pontos:

• Qualquer administrador do banco de dados que possa exibir rastreamentos ou logs de auditoria pode exibir essas informações, mesmo sem permissões para os dados em sua fonte original. Neste exemplo, o administrador precisaria de permissões para o arquivo do Excel.

• As configurações de criptografia para cada fonte devem ser consideradas. Você deseja evitar recuperar informações de uma fonte por uma conexão criptografada e, em seguida, incluí-las inadvertidamente em uma consulta enviada a outra fonte por uma conexão não criptografada.

Para permitir a confirmação de que você considerou quaisquer implicações de segurança, o Power BI Desktop exibe uma mensagem de aviso quando você cria um modelo composto.

Além disso, se um autor adicionar a Tabela 1 do Modelo A a um Modelo Composto (vamos chamá-lo de Modelo C para referência), um usuário exibindo um relatório criado no Modelo C poderá consultar qualquer tabela no Modelo A que não esteja protegida por RLS de segurança em nível de linha.

Por motivos semelhantes, tenha cuidado ao abrir um arquivo do Power BI Desktop enviado de uma fonte não confiável. Se o arquivo contiver modelos compostos, as informações que alguém recuperar de uma fonte, usando as credenciais do usuário que abre o arquivo, serão enviadas para outra fonte de dados como parte da consulta. As informações podem ser visualizadas pelo autor mal-intencionado do arquivo do Power BI Desktop. Quando você abre inicialmente um arquivo do Power BI Desktop que contém várias fontes, o Power BI Desktop exibe um aviso. O aviso é semelhante ao exibido quando você abre um arquivo que contém consultas SQL nativas.

Implicações de desempenho

Ao usar o DirectQuery, você deve sempre considerar o desempenho, principalmente para garantir que a fonte de back-end tenha recursos suficientes para fornecer uma boa experiência aos usuários. Uma boa experiência significa que os visuais são atualizados em cinco segundos ou menos. Para obter mais conselhos de desempenho, consulte DirectQuery no Power BI.

O uso de modelos compostos adiciona outras considerações de desempenho. Um único visual pode resultar no envio de consultas para várias fontes, que geralmente passam os resultados de uma consulta para uma segunda fonte. Esta situação pode resultar nas seguintes formas de execução:

• Uma consulta de origem que inclui um grande número de valores literais: por exemplo, um visual que solicita o Valor total de Vendas para um conjunto de Gerentes de Produto selecionados precisaria primeiro encontrar quais Produtos foram gerenciados por esses gerentes de produto. Essa sequência deve acontecer antes que o visual envie uma consulta SQL que inclua todas as IDs do produto em uma WHERE cláusula.

• Uma consulta de origem que consulta em um nível mais baixo de granularidade, com os dados sendo posteriormente agregados localmente: à medida que o número de Produtos que atendem aos critérios de filtro no Gerenciador de Produtos cresce, pode se tornar ineficiente ou inviável incluir todos os produtos em uma WHERE cláusula. Em vez disso, você pode consultar a fonte relacional no nível inferior de Produtos e, em seguida, agregar os resultados localmente. Se a cardinalidade de Produtos exceder um limite de 1 milhão, a consulta falhará.

• Várias consultas de origem, uma por grupo por valor: quando a agregação usa DistinctCount e é agrupada por uma coluna de outra fonte, e se a fonte externa não oferece suporte à passagem eficiente de muitos valores literais que definem o agrupamento, é necessário enviar uma consulta SQL por grupo por valor.

  Um visual que solicita uma contagem distinta de CustomerAccountNumber da tabela do SQL Server por Product Managers importados da planilha precisaria passar os detalhes da tabela Product Managers na consulta enviada ao SQL Server. Sobre outras fontes, Redshift, por exemplo, esta ação é inviável. Em vez disso, haveria uma consulta SQL enviada por Gerente de Vendas, até algum limite prático, momento em que a consulta falharia.

Cada um desses casos tem suas próprias implicações no desempenho, e os detalhes exatos variam para cada fonte de dados. Embora a cardinalidade das colunas usadas na relação que une as duas fontes permaneça baixa, alguns milhares, o desempenho não deve ser afetado. À medida que essa cardinalidade cresce, você deve prestar mais atenção ao impacto no desempenho resultante.

Além disso, o uso de relações muitos-para-muitos significa que consultas separadas devem ser enviadas para a fonte subjacente para cada nível total ou subtotal, em vez de agregar os valores detalhados localmente. Um visual de tabela simples com totais enviaria duas consultas de origem, em vez de uma.

Grupos de origem

Um grupo de origem é uma coleção de itens, como tabelas e relações, de uma fonte DirectQuery ou de todas as fontes de importação envolvidas em um modelo de dados. Um modelo composto é feito de um ou mais grupos de fontes. Considere os seguintes exemplos:

• Um modelo composto que se conecta a um modelo semântico do Power BI chamado Sales e enriquece o modelo semântico adicionando uma medida de Sales YTD , que não está disponível no modelo semântico original. Este modelo consiste em um grupo de origem.
• Um modelo composto que combina dados importando uma tabela de uma planilha do Excel chamada Destinos e um arquivo CSV chamado Regiões, e fazendo uma conexão DirectQuery com um modelo semântico do Power BI chamado Vendas. Nesse caso, há dois grupos de fontes, conforme mostrado na imagem a seguir:
  • O primeiro grupo de origem contém as tabelas da planilha Excel Destinos e o arquivo CSV Regiões.
  • O segundo grupo de origem contém os itens do modelo semântico do Sales Power BI.

Se você adicionou outra conexão DirectQuery a outra fonte, como uma conexão DirectQuery a um banco de dados do SQL Server chamado Inventário, os itens dessa fonte serão adicionados a outro grupo de fontes:

Grupos e relações de origem

Existem dois tipos de relações em um modelo composto:

• Relações intra-grupo de origem. Essas relações relacionam itens dentro de um grupo de origem. Estas relações são sempre relações regulares, a menos que sejam muitos-para-muitos, caso em que são limitadas.
• Relações de grupo entre fontes. Essas relações começam em um grupo de origem e terminam em um grupo de origem diferente. Estas relações são sempre relações limitadas.

Leia mais sobre a distinção entre relacionamentos regulares e limitados e seu impacto.

Por exemplo, na imagem a seguir, adicionamos três relações de grupo entre fontes, relacionando tabelas entre os vários grupos de origem:

Local e remoto

Qualquer item que esteja em um grupo de origem que seja um grupo de origem do DirectQuery é considerado remoto, a menos que o item tenha sido definido localmente como parte de uma extensão ou enriquecimento para a fonte do DirectQuery e não faça parte da fonte remota, como uma medida ou uma tabela calculada. Uma tabela calculada com base em uma tabela do grupo de origem do DirectQuery pertence ao grupo de origem "Importar" e é considerada local. Qualquer item que esteja no grupo de origem "Importar" é considerado local. Por exemplo, se você definir a seguinte medida em um modelo composto que usa uma conexão DirectQuery com a fonte de inventário, a medida será considerada local:

[Average Inventory Count] = Average(Inventory[Inventory Count])

Grupos de cálculo, consulta e avaliação de medidas

Os grupos de cálculo fornecem uma maneira de reduzir o número de medidas redundantes e agrupar expressões de medidas comuns. Os casos de uso típicos são cálculos de inteligência de tempo em que você deseja poder alternar de cálculos reais para cálculos mensais, trimestrais ou anuais até a data. Ao trabalhar com modelos compostos, é importante estar ciente da interação entre grupos de cálculo e se uma medida se refere apenas a itens de um único grupo de origem remota. Se uma medida se refere apenas a itens de um único grupo de origem remota e o modelo remoto define um grupo de cálculo que afeta a medida, esse grupo de cálculo é aplicado, mesmo que a medida tenha sido definida no modelo remoto ou no modelo local. No entanto, se uma medida não se referir exclusivamente a itens de um único grupo de origem remota, mas se referir a itens de um grupo de origem remota no qual um grupo de cálculo remoto é aplicado, os resultados da medida ainda poderão ser afetados pelo grupo de cálculo remoto. Considere o seguinte exemplo:

• Reseller Sales é uma medida definida no modelo remoto.
• O modelo remoto contém um grupo de cálculo que altera o resultado das Vendas do Revendedor
• Vendas pela Internet é uma medida definida no modelo local.
• Total de Vendas é uma medida definida no modelo local, e tem a seguinte definição:

[Total Sales] = [Internet Sales] + [Reseller Sales]

Nesse cenário, a medida de vendas pela Internet não é afetada pelo grupo de cálculo definido no modelo remoto porque eles não fazem parte do mesmo modelo. No entanto, o grupo de cálculo pode alterar o resultado da medida de vendas do revendedor , porque eles estão no mesmo modelo. Este facto significa que os resultados devolvidos pela medida Total de Vendas devem ser cuidadosamente avaliados. Imagine que usamos o grupo de cálculo no modelo remoto para retornar os resultados do ano até a data. O resultado retornado pelo Reseller Sales é agora um valor acumulado do ano, enquanto o resultado retornado pelo Internet Sales ainda é real. O resultado das Vendas Totais é agora provavelmente inesperado, uma vez que adiciona um resultado real a um resultado do acumulado do ano.

Modelos compostos em modelos semânticos do Power BI e Analysis Services

Usando modelos compostos com modelos semânticos do Power BI e Analysis Services, você pode criar um modelo composto usando uma conexão DirectQuery para se conectar a modelos semânticos do Power BI, Azure Analysis Services (AAS) e SQL Server 2022 Analysis Services. Usando um modelo composto, você pode combinar os dados nessas fontes com outros dados DirectQuery e importados. Os autores de relatórios que desejam combinar os dados de seu modelo semântico corporativo com outros dados de sua propriedade, como uma planilha do Excel, ou que desejam personalizar ou enriquecer os metadados de seu modelo semântico corporativo, acharão essa funcionalidade especialmente útil.

Gerenciando modelos compostos em modelos semânticos do Power BI

Para habilitar a criação e o consumo de modelos compostos em modelos semânticos do Power BI, seu locatário precisa ter as seguintes opções habilitadas:

• Permita pontos de extremidade XMLA e analise no Excel com modelos semânticos locais. Se essa opção estiver desabilitada, uma conexão DirectQuery com um modelo semântico do Power BI não poderá ser feita.
• Os usuários podem trabalhar com modelos semânticos do Power BI no Excel usando uma conexão ao vivo. Se essa opção estiver desabilitada, os usuários não poderão fazer conexões em tempo real com modelos semânticos do Power BI, portanto, o botão Fazer alterações neste modelo não poderá ser alcançado.
• Permitir conexão DirectQuery a modelos semânticos do Power BI. Consulte os parágrafos seguintes para obter mais informações sobre esta opção e o efeito da sua desativação.

Além disso, para capacidades Premium e Premium por usuário, a configuração "Ponto de extremidade XMLA" deve ser habilitada e definida como "Somente leitura" ou "Leitura/gravação".

Os administradores de locatários podem habilitar ou desabilitar conexões DirectQuery com modelos semânticos do Power BI no portal de administração. Embora isso esteja habilitado por padrão, desativá-lo impede que os usuários publiquem novos modelos compostos em modelos semânticos do Power BI no serviço.

Os relatórios existentes que usam um modelo composto em um modelo semântico do Power BI continuam a funcionar e os usuários ainda podem criar o modelo composto usando a Área de Trabalho, mas não podem publicar no serviço. Em vez disso, ao criar uma conexão DirectQuery com o modelo semântico do Power BI, selecionando Fazer alterações neste modelo , você verá a seguinte mensagem de aviso:

Dessa forma, você ainda pode explorar o modelo semântico em seu ambiente local do Power BI Desktop e criar o modelo composto. No entanto, não é possível publicar o relatório no Serviço. Ao publicar o relatório e o modelo, você verá a seguinte mensagem de erro e a publicação será bloqueada:

As conexões em tempo real com modelos semânticos do Power BI não são influenciadas pelo switch, nem as conexões ao vivo ou DirectQuery com o Analysis Services. Estes continuam a funcionar independentemente de o interruptor ter sido desligado. Além disso, todos os relatórios publicados que usam um modelo composto em um modelo semântico do Power BI continuarão a funcionar mesmo que o switch tenha sido desativado depois de publicados.

Construindo um modelo composto em um modelo semântico ou modelo

A criação de um modelo composto em um modelo semântico do Power BI ou modelo do Analysis Services exige que seu relatório tenha um modelo local. Você pode começar a partir de uma conexão em tempo real e adicionar ou atualizar para um modelo local, ou começar com uma conexão DirectQuery ou dados importados, que cria automaticamente um modelo local em seu relatório.

Para ver quais conexões estão sendo usadas em seu modelo, verifique a barra de status no canto inferior direito do Power BI Desktop. Se você estiver conectado apenas a uma fonte do Analysis Services, verá uma mensagem como a seguinte imagem:

Se estiver ligado a um modelo semântico do Power BI, verá uma mensagem a indicar a que modelo semântico do Power BI está ligado:

Se quiser personalizar os metadados dos campos em seu modelo semântico conectado ao vivo, selecione Fazer alterações neste modelo na barra de status. Como alternativa, você pode selecionar o botão Fazer alterações neste modelo na faixa de opções, conforme mostrado na imagem a seguir. Em Exibição de Relatório, o botão Fazer alterações neste modelo na guia Modelagem . Na Vista de Modelo, o botão encontra-se no separador Base .

Selecionar o botão exibe uma caixa de diálogo confirmando a adição de um modelo local. Selecione Adicionar um modelo local para habilitar a criação de novas colunas ou a modificação dos metadados, para campos de modelos semânticos do Power BI ou do Analysis Services. A imagem a seguir mostra a caixa de diálogo mostrada.

Quando você está conectado ao vivo a uma fonte do Analysis Services, não há um modelo local. Para usar o DirectQuery para fontes conectadas em tempo real, como modelos semânticos do Power BI e Analysis Services, você deve adicionar um modelo local ao relatório. Quando você publica um relatório com um modelo local no serviço do Power BI, um modelo semântico para esse modelo local é publicado um poço.

Encadeamento

Os modelos semânticos e os modelos semânticos nos quais se baseiam formam uma cadeia. Esse processo, chamado encadeamento, permite publicar um relatório e um modelo semântico com base em outros modelos semânticos do Power BI, um recurso que anteriormente não era possível.

Por exemplo, imagine que seu colega publica um modelo semântico do Power BI chamado Vendas e Orçamento com base em um modelo do Analysis Services chamado Vendas e o combina com uma planilha do Excel chamada Orçamento.

Quando você publica um novo relatório (e modelo semântico) chamado Sales and Budget Europe com base no modelo semântico do Power BI de Vendas e Orçamento publicado por seu colega, fazendo algumas modificações ou extensões adicionais à medida que faz isso, você está efetivamente adicionando um relatório e um modelo semântico a uma cadeia de comprimento três, que começou com o modelo Sales Analysis Services, e termina com o seu modelo semântico do Power BI de Vendas e Orçamento da Europa . A imagem a seguir visualiza esse processo de encadeamento.

A cadeia na imagem anterior é de comprimento três, que é o comprimento máximo. Não há suporte para além de um comprimento de cadeia de três e resulta em erros.

Permissões e licenciamento

Os usuários que acessam relatórios usando um modelo composto precisam ter permissões adequadas para todos os modelos semânticos e modelos na cadeia.

O proprietário do modelo composto requer permissão Build nos modelos semânticos usados como fontes para que outros usuários possam acessar esses modelos em nome do proprietário. Como resultado, criar a conexão de modelo composto no Power BI Desktop ou criar o relatório no Power BI requer permissões de compilação nos modelos semânticos usados como fontes.

Os usuários que visualizam relatórios usando o modelo composto geralmente precisarão de permissões de leitura no próprio modelo composto e nos modelos semânticos usados como fontes. As permissões de compilação podem ser necessárias se os relatórios estiverem em um espaço de trabalho Pro. Essas opções de locatário devem ser habilitadas para o usuário.

As permissões necessárias podem ser ilustradas com o seguinte exemplo:

• Modelo Composto A (propriedade do Proprietário A)

  • Fonte de dados A1: Modelo semântico B.
    O proprietário A deve ter permissão de compilação no modelo semântico B para que os usuários visualizem o relatório usando o modelo composto A.

• Modelo Composto C (propriedade do Proprietário C)

  • Fonte de dados C1: Modelo semântico D
    O proprietário C deve ter permissão de compilação no modelo semântico D para que os usuários visualizem o relatório usando o modelo composto C.
  • Fonte de dados C2: Modelo composto A
    O proprietário C deve ter permissão de compilação no modelo composto A e permissão de leitura no modelo semântico B.

Um usuário que exibe relatórios usando o Modelo Composto A deve ter permissões de Leitura para o Modelo Composto A e o Modelo Semântico B, enquanto um usuário que exibe relatórios usando o Modelo Composto C deve ter permissões de Leitura no Modelo Composto C, Modelo Semântico D, Modelo Composto A e Modelo Semântico B.

Se qualquer conjunto de dados na cadeia estiver em um espaço de trabalho Premium por usuário, o usuário que acessá-lo precisará de uma licença Premium por usuário. Se qualquer conjunto de dados na cadeia estiver em um espaço de trabalho Pro, o usuário que acessá-lo precisará de uma licença Pro. Se todos os conjuntos de dados na cadeia estiverem em capacidades Premium ou Fabric F64 ou maior capacidade, um usuário pode acessá-lo usando uma licença Livre.

Aviso de segurança

O uso do recurso Modelos compostos em modelos semânticos do Power BI e modelos do Analysis Services apresenta uma caixa de diálogo de aviso de segurança, mostrada na imagem a seguir.

Os dados podem ser enviados por push de uma fonte de dados para outra, que é o mesmo aviso de segurança para combinar o DirectQuery e importar fontes em um modelo de dados. Para saber mais sobre esse comportamento, consulte Usando modelos compostos no Power BI Desktop.

Cenários suportados

Você pode criar modelos compostos usando dados de modelos semânticos do Power BI ou modelos do Analysis Services para atender aos seguintes cenários:

• Conectando-se a dados de várias fontes: Importar (como arquivos), modelos semânticos do Power BI, modelos do Analysis Services
• Criando relações entre diferentes fontes de dados
• Escrever medidas que usam campos de diferentes fontes de dados
• Criando novas colunas para tabelas a partir de modelos semânticos do Power BI ou modelos do Analysis Services
• Criação de elementos visuais que usam colunas de diferentes fontes de dados
• Você pode remover uma tabela do seu modelo usando a lista de campos, para manter os modelos tão concisos e enxutos quanto possível (se você se conectar a uma perspetiva, não poderá remover tabelas do modelo)
• Você pode especificar quais tabelas carregar, em vez de ter que carregar todas as tabelas quando quiser apenas um subconjunto específico de tabelas. Consulte Carregando um subconjunto de tabelas posteriormente neste documento.
• Você pode especificar se deseja adicionar tabelas que serão adicionadas posteriormente ao modelo semântico depois de fazer a conexão em seu modelo.

Trabalhando com um modelo composto baseado em um modelo semântico

Ao trabalhar com modelos semânticos do DirectQuery para Power BI e Analysis Services, considere as seguintes informações:

• Se você atualizar suas fontes de dados e houver erros com nomes de campos ou tabelas conflitantes, o Power BI resolverá os erros para você.

• Não é possível editar, excluir ou criar novas relações no mesmo modelo semântico do Power BI ou na mesma fonte do Analysis Services. Se você tiver acesso de edição a essas fontes, poderá fazer as alterações diretamente na fonte de dados.

• Não é possível alterar tipos de dados de colunas que são carregadas de um modelo semântico do Power BI ou de uma fonte do Analysis Services. Se você precisar alterar o tipo de dados, altere-o na origem ou use uma coluna calculada.

• Para criar relatórios no serviço do Power BI em um modelo composto com base em outro modelo semântico, todas as credenciais devem ser definidas.

• As conexões com um servidor SQL Server 2022 e posterior do Analysis Services local ou IAAS exigem um gateway de dados local (modo Padrão).

• Todas as conexões com modelos semânticos remotos do Power BI são feitas usando logon único. Atualmente, não há suporte para autenticação com uma entidade de serviço.

• As regras RLS são aplicadas na origem na qual são definidas, mas não são aplicadas a nenhum outro modelo semântico no modelo. As RLS definidas no relatório não são aplicadas a fontes remotas e as RLS definidas em fontes remotas não são aplicadas a outras fontes de dados. Além disso, não é possível definir RLS em uma tabela carregada de uma fonte remota, e RLS definidas em tabelas locais não filtram nenhuma tabela carregada de uma fonte remota.

• KPIs, segurança em nível de linha e traduções não são importados da origem.

• Você pode ver algum comportamento inesperado ao usar uma hierarquia de data. Para resolver esse problema, use uma coluna de data em vez disso. Depois de adicionar uma hierarquia de data a um visual, você pode alternar para uma coluna de data clicando na seta para baixo no nome do campo e, em seguida, clicando no nome desse campo em vez de usar Hierarquia de Data:

  

  Para obter mais informações sobre como usar colunas de data versus hierarquias de data, consulte Aplicar data ou hora automática no Power BI Desktop.

• O comprimento máximo de uma cadeia de modelos é de três. Não há suporte para além do comprimento da cadeia de três e resulta em erros.

• Um sinalizador de desencorajamento do encadeamento pode ser definido em um modelo para impedir que uma cadeia seja criada ou estendida. Para obter mais informações, consulte Gerenciar conexões DirectQuery com um modelo semântico publicado.

• A ligação a um modelo semântico do Power BI ou a um modelo do Analysis Services não é apresentada no Power Query.

As limitações a seguir se aplicam ao trabalhar com modelos semânticos do DirectQuery para Power BI e Analysis Services:

• Os parâmetros para nomes de banco de dados e servidor estão desabilitados no momento.
• Não há suporte para a definição de RLS em tabelas a partir de uma fonte remota.
• Não há suporte para o uso de qualquer uma das seguintes fontes como uma fonte do DirectQuery:
  • Modelos tabulares do SQL Server Analysis Services (SSAS) anteriores à versão 2022
  • Modelos multidimensionais SSAS
  • SAP HANA
  • SAP Business Warehouse
  • Modelos semânticos em tempo real
  • Modelos semânticos de exemplo
  • Atualização do Excel Online
  • Dados importados de arquivos Excel ou CSV no Serviço
  • Métricas de utilização
  • Modelos semânticos armazenados em "Meu espaço de trabalho"
• Atualmente, não há suporte para o uso do Power BI Embedded com modelos semânticos que incluem uma conexão DirectQuery com um modelo do Analysis Services.
• Não há suporte para a publicação de um relatório na Web usando o recurso publicar na Web.
• Não há suporte para grupos de cálculo em fontes remotas, com resultados de consulta indefinidos.

• Tabelas calculadas e colunas calculadas que fazem referência a uma tabela DirectQuery de uma fonte de dados com autenticação de logon único (SSO) são suportadas no serviço do Power BI com uma conexão de nuvem compartilhável atribuída e/ou controle de acesso granular.

• Se você renomear um espaço de trabalho após a conexão DirectQuery ter sido configurada, precisará atualizar a fonte de dados no Power BI Desktop para que o relatório continue funcionando.
• A atualização automática de página (APR) só é suportada em alguns cenários, dependendo do tipo de fonte de dados. Para obter mais informações, consulte Atualização automática de página no Power BI.
• Não há suporte para assumir o controle de um modelo semântico que está usando o DirectQuery para outros recursos de modelos semânticos.
• Como em qualquer fonte de dados DirectQuery, as hierarquias definidas em um modelo do Analysis Services ou modelo semântico do Power BI não são mostradas ao se conectar ao modelo ou modelo semântico no modo DirectQuery usando o Excel.

Há algumas outras coisas a considerar ao trabalhar com modelos semânticos do DirectQuery para Power BI e Analysis Services:

• Usar colunas de baixa cardinalidade em relações de grupo entre fontes: quando você cria uma relação entre dois grupos de origem diferentes, as colunas que participam da relação (também chamadas de colunas de junção) devem ter baixa cardinalidade, idealmente 50.000 ou menos. Esta consideração aplica-se a colunas de chave sem cadeia de caracteres; Para colunas de chave de cadeia de caracteres, consulte a seguinte consideração.
• Evite usar colunas de chave de cadeias de caracteres grandes em relações de grupo de origem cruzada: ao criar uma relação de grupo de origem cruzada, evite usar colunas de cadeia de caracteres grandes como colunas de relacionamento, especialmente para colunas que têm cardinalidade maior. Quando você precisar usar colunas de cadeia de caracteres como a coluna de relacionamento, calcule o comprimento de cadeia de caracteres esperado para o filtro multiplicando a cardinalidade (C) pelo comprimento médio da coluna de cadeia de caracteres (A). Verifique se o comprimento esperado da cadeia de caracteres está abaixo de 250.000, de modo que A ∗ C < 250.000.

Para obter mais considerações e orientações, consulte Diretrizes de modelo composto.

Considerações sobre o locatário

Qualquer modelo com uma conexão DirectQuery com um modelo semântico do Power BI ou com o Analysis Services deve ser publicado no mesmo locatário, o que é especialmente importante ao acessar um modelo semântico do Power BI ou um modelo do Analysis Services usando identidades de convidado B2B, conforme descrito no diagrama a seguir. Consulte Usuários convidados que podem editar e gerenciar conteúdo para encontrar a URL do locatário para publicação.

Considere o diagrama a seguir. As etapas numeradas no diagrama são descritas nos parágrafos a seguir.

No diagrama, Ash trabalha com a Contoso e está acessando dados fornecidos pela Fabrikam. Com o Power BI Desktop, Ash cria uma conexão DirectQuery com um modelo do Analysis Services hospedado no locatário da Fabrikam.

Para autenticar, Ash usa uma identidade de usuário B2B Guest (etapa 1 no diagrama).

Se o relatório for publicado no serviço Power BI da Contoso (etapa 2), o modelo semântico publicado no locatário da Contoso não poderá ser autenticado com êxito no modelo do Analysis Services da Fabrikam (etapa 3). Como resultado, o relatório não funciona.

Nesse cenário, como o modelo do Analysis Services usado está hospedado no locatário da Fabrikam, o relatório também deve ser publicado no locatário da Fabrikam. Após a publicação bem-sucedida no locatário da Fabrikam (etapa 4), o modelo semântico pode acessar com êxito o modelo do Analysis Services (etapa 5) e o relatório funciona corretamente.

Trabalhando com segurança no nível do objeto

Quando um modelo composto obtém dados de um modelo semântico do Power BI ou do Analysis Services via DirectQuery, e esse modelo de origem é protegido pela segurança no nível do objeto, os consumidores do modelo composto podem notar resultados inesperados. A seção a seguir explica como esses resultados podem surgir.

A segurança em nível de objeto (OLS) permite que os autores de modelos ocultem objetos que compõem o esquema do modelo (ou seja, tabelas, colunas, metadados etc.) dos consumidores do modelo (por exemplo, um construtor de relatórios ou um autor de modelo composto). Ao configurar o OLS para um objeto, o autor do modelo cria uma função e, em seguida, remove o acesso ao objeto para os usuários atribuídos a essa função. Do ponto de vista desses usuários, o objeto oculto simplesmente não existe.

O OLS é definido e aplicado no modelo de origem. Ele não pode ser definido para um modelo composto construído no modelo de origem.

Quando um modelo composto é criado sobre um modelo semântico do Power BI protegido pelo OLS ou um modelo do Analysis Services por meio da conexão DirectQuery, o esquema de modelo do modelo de origem é copiado para o modelo composto. O que é copiado depende do que o autor do modelo composto pode ver no modelo de origem de acordo com as regras OLS que se aplicam lá. Os dados não são copiados para o modelo composto – em vez disso, são sempre recuperados via DirectQuery do modelo de origem quando necessário. Em outras palavras, a recuperação de dados sempre volta ao modelo de origem, onde as regras OLS se aplicam.

Como o modelo composto não é protegido por regras OLS, os objetos que os consumidores do modelo composto veem são aqueles que o autor do modelo composto poderia ver no modelo de origem, em vez do que eles mesmos poderiam ter acesso. Isso pode resultar nas seguintes situações:

• Alguém olhando para o modelo composto pode ver objetos que estão ocultos deles no modelo de origem pelo OLS.
• Por outro lado, eles podem NÃO ver um objeto no modelo composto que PODEM ver no modelo de origem, porque esse objeto foi oculto do autor do modelo composto pelas regras OLS que controlam o acesso ao modelo de origem.

Um ponto importante é que, apesar do caso descrito no primeiro ponto, os consumidores do modelo composto nunca veem dados reais que não deveriam ver, porque os dados não estão localizados no modelo composto. Em vez disso, devido ao DirectQuery, ele é recuperado conforme necessário do modelo semântico de origem, onde o OLS bloqueia o acesso não autorizado.

Com esse histórico em mente, considere o seguinte cenário:

1. Admin_user publicou um modelo semântico empresarial usando um modelo semântico do Power BI ou um modelo do Analysis Services que tem uma tabela Customer e uma tabela Territory. Admin_user publica o modelo semântico no serviço Power BI e define regras OLS que têm o seguinte efeito:

   • Os usuários de finanças não conseguem ver a tabela Cliente
   • Os usuários de marketing não conseguem ver a tabela Território

2. Finance_user publica um modelo semântico chamado "Modelo semântico financeiro" e um relatório chamado "Relatório financeiro" que se conecta via DirectQuery ao modelo semântico empresarial publicado na etapa 1. O relatório Finanças inclui um visual que usa uma coluna da tabela Território.

3. Marketing_user abre o relatório Finanças. O visual que usa a tabela Territory é exibido, mas retorna um erro, porque quando o relatório é aberto, o DirectQuery tenta recuperar os dados do modelo de origem usando as credenciais do Marketing_user, que é impedido de ver a tabela Territory de acordo com as regras OLS definidas no modelo semântico da empresa.

4. Marketing_user cria um novo relatório chamado "Relatório de Marketing" que usa o modelo semântico de Finanças como fonte. A lista de campos mostra as tabelas e colunas às quais Finance_user tem acesso. Assim, a tabela Território é mostrada na lista de campos, mas a tabela Cliente não. No entanto, quando o Marketing_user tenta criar um visual que usa uma coluna da tabela Territory, um erro é retornado, porque nesse ponto o DirectQuery tenta recuperar dados do modelo de origem usando as credenciais do Marketing_user, e as regras do OLS mais uma vez entram em ação e bloqueiam o acesso. A mesma coisa acontece quando Marketing_user cria um novo modelo semântico e relatório que se conectam ao modelo semântico Finance com uma conexão DirectQuery – eles veem a tabela Territory na lista de campos, já que é isso que Finance_user podem ver, mas quando tentam criar um visual que usa essa tabela, eles são bloqueados pelas regras OLS no modelo semântico empresarial.

5. Agora, digamos que Admin_user atualize as regras do OLS no modelo semântico empresarial para impedir que o Finance veja a tabela Território.

6. As regras OLS atualizadas só são refletidas no modelo semântico Finance quando ele é atualizado. Assim, quando o Finance_user atualiza o modelo semântico Finanças, a tabela Território não é mais mostrada na lista de campos e o visual no relatório Finanças que usa uma coluna da tabela Território retorna um erro para Finance_user, porque eles agora não têm permissão para acessar a tabela Território.

Para resumir:

• Os consumidores de um modelo composto veem os resultados das regras OLS que eram aplicáveis ao autor do modelo composto quando criaram o modelo. Assim, quando um novo relatório é criado com base no modelo composto, a lista de campos mostra as tabelas às quais o autor do modelo composto tinha acesso quando criou o modelo, independentemente do que o usuário atual tenha acesso no modelo de origem.
• As regras do OLS não podem ser definidas no próprio modelo composto.
• Um consumidor de um modelo composto nunca verá dados reais que não deveria ver, porque as regras OLS relevantes no modelo de origem os bloqueiam quando o DirectQuery tenta recuperar os dados usando suas credenciais.
• Se o modelo de origem atualizar suas regras OLS, essas alterações só afetarão o modelo composto quando ele for atualizado.

Carregando um subconjunto de tabelas de um modelo semântico do Power BI ou modelo do Analysis Services

Ao se conectar a um modelo semântico do Power BI ou modelo do Analysis Services usando uma conexão DirectQuery, você pode decidir a quais tabelas se conectar. Você também pode optar por adicionar automaticamente qualquer tabela que possa ser adicionada ao modelo semântico ou modelo depois de fazer a conexão com seu modelo. Quando você se conecta a uma perspetiva, seu modelo contém todas as tabelas no modelo semântico e todas as tabelas não incluídas na perspetiva ficam ocultas. Além disso, qualquer tabela que possa ser adicionada à perspetiva é adicionada automaticamente. No menu Configurações, você pode decidir se conectar automaticamente a tabelas que são adicionadas ao modelo semântico depois de configurar a conexão pela primeira vez.

Esta caixa de diálogo não é mostrada para conexões em tempo real.

Configuração de regras de eliminação de duplicação

Você pode especificar regras de desduplicação para manter os nomes de medidas e tabelas exclusivos em um modelo composto usando a opção Configurações na caixa de diálogo mostrada anteriormente:

No exemplo anterior, adicionamos ' (marketing)' como sufixo a qualquer nome de tabela ou medida que esteja em conflito com outra fonte no modelo composto. Pode:

• Insira um texto a ser adicionado ao nome de tabelas ou medidas conflitantes
• Especifique se deseja que o texto seja adicionado ao nome da tabela ou medida como um prefixo ou sufixo
• aplicar a regra de desduplicação a tabelas, medidas ou ambas
• Escolha aplicar a regra de desduplicação somente quando ocorrer um conflito de nome ou aplicá-la o tempo todo. O padrão é aplicar a regra somente quando ocorrer duplicação. No nosso exemplo, qualquer tabela ou medida da fonte de marketing que não tenha uma duplicata na fonte de vendas não receberá uma alteração de nome.

Depois de fazer as conexões e configurar a regra de desduplicação, sua lista de campos mostrará "Cliente" e "Cliente (marketing)" de acordo com a regra de desduplicação configurada em nosso exemplo:

Se você não especificar uma regra de desduplicação ou se as regras de desduplicação especificadas não resolverem o conflito de nome, as regras de desduplicação padrão ainda serão aplicadas. As regras padrão de desduplicação adicionam um número ao nome do item conflitante. Se houver um conflito de nomes na tabela 'Cliente', uma das tabelas 'Cliente' será renomeada para 'Cliente 2'.

Modificações XMLA e modelos compostos

Ao alterar um modelo semântico usando XMLA, você deve atualizar a coleção ChangedProperties e PBI_RemovedChildren para que o objeto alterado inclua quaisquer propriedades modificadas ou removidas. Se você não executar essa atualização, as ferramentas de modelagem do Power BI poderão substituir quaisquer alterações na próxima vez que o esquema for sincronizado com o Lakehouse associado.

Os modelos suportados para alterar um modelo semântico usando XMLA são os seguintes:

• Renomeação de tabela/coluna (ChangeProperty = nome)
• Remover tabela (adicionar tabela a PBI_RemovedChildren anotação na expressão de consulta)

Considerações e limitações

Os modelos compostos apresentam algumas considerações e limitações:

Conexões de modo misto - Ao usar uma conexão de modo misto que contém dados online (como um modelo semântico do Power BI) e um modelo semântico local (como uma pasta de trabalho do Excel), você deve ter o mapeamento de gateway estabelecido para que os visuais apareçam corretamente.

Atualmente, a atualização incremental é suportada apenas para modelos compostos que se conectam a fontes de dados SQL, Oracle e Teradata.

As seguintes fontes tabulares do Live Connect não podem ser usadas com modelos compostos:

• SAP HANA
• SAP Business Warehouse
• SQL Server Analysis Services anterior à versão 2022
• Métricas de uso (Meu espaço de trabalho)

Não há suporte para o uso de modelos semânticos de streaming em modelos compostos.

As limitações existentes do DirectQuery ainda se aplicam quando você usa modelos compostos. Muitas dessas limitações agora são por tabela, dependendo do modo de armazenamento da tabela. Por exemplo, uma coluna calculada em uma tabela de importação pode se referir a outras tabelas que não estão no DirectQuery, mas uma coluna calculada em uma tabela DirectQuery ainda pode se referir apenas a colunas na mesma tabela. Outras limitações se aplicam ao modelo como um todo, se qualquer uma das tabelas dentro do modelo for DirectQuery. Por exemplo, o recurso QuickInsights não estará disponível em um modelo se qualquer uma das tabelas dentro dele tiver um modo de armazenamento do DirectQuery.

Se você estiver usando segurança em nível de linha em um modelo composto com algumas das tabelas no modo DirectQuery, deverá atualizar o modelo para aplicar novas atualizações das tabelas DirectQuery. Por exemplo, se uma tabela Usuários no modo DirectQuery tiver novos registros de usuário na origem, os novos registros só serão incluídos após a próxima atualização do modelo. O Serviço do Power BI armazena em cache a consulta Usuários para melhorar o desempenho e não recarrega os dados da origem até a próxima atualização manual ou agendada.

Conteúdos relacionados

Para obter mais informações sobre modelos compostos e DirectQuery, consulte os seguintes artigos:

• Aplicar relações muitos-para-muitos no Power BI Desktop
• Gerenciar o modo de armazenamento no Power BI Desktop
• DirectQuery no Power BI
• Fontes de dados do Power BI
• Relações de modelo no Power BI Desktop