Usar modelos compostos no Power BI

Os modelos semânticos do Power BI podem incluir tabelas de uma ou mais fontes de dados usando qualquer um dos modos de armazenamento de tabela com suporte. Quando as tabelas usam modos de armazenamento diferentes, o modelo é um modelo semântico composto. Para o modo de armazenamento de tabela DirectQuery, o modelo é composto quando as tabelas DirectQuery usam fontes de dados diferentes.

Por exemplo, se você se conectar a outro modelo semântico do Power BI usando o DirectQuery (que adiciona tabelas no modo de armazenamento DirectQuery) e também tiver tabelas locais no modo De importação, seu modelo se tornará um modelo composto porque ele contém tabelas com modos de armazenamento diferentes.

Tipos de modelos compostos

Existem diferentes tipos de modelos compostos dependendo da combinação de modos de armazenamento de tabela no modelo semântico. Cada tipo tem suas próprias considerações sobre funcionalidade e ferramentas.

Criar modelos compostos no Power BI Desktop

No Power BI Desktop, você pode criar modelos semânticos com tabelas de importação ou DirectQuery localmente. Em seguida, você pode adicionar mais tabelas do botão Obter dados na outra faixa de opções de modo de armazenamento para criar um modelo composto.

Adicionar tabelas DirectQuery de outro modelo semântico do Power BI tem alguns caminhos de criação diferentes.

1. Em um arquivo do Power BI em branco, conecte-se primeiro ao modelo semântico do Power BI. Depois de conectado ao vivo, você tem a opção de fazer alterações nesse modelo. Selecionar Fazer alterações nesse modelo na faixa de opções ou rodapé converte a conexão dinâmica em uma conexão DirectQuery. A conexão DirectQuery cria um novo modelo semântico local com as tabelas no modo de armazenamento DirectQuery. Você pode adicionar novas tabelas no modo de armazenamento de importação ou de DirectQuery, além de oferecer a opção de substituir algumas propriedades de coluna no modelo semântico de origem.

2. Em um modelo semântico com tabelas de importação ou DirectQuery já, conecte-se a um modelo semântico do Power BI e as tabelas escolhidas são adicionadas como DirectQuery.

Modelos semânticos criados com tabelas do Direct Lake são editados ao vivo no Power BI Desktop. Você pode adicionar mais tabelas do Direct Lake. Para adicionar tabelas de importação, abra o modelo semântico na modelagem web do Power BI. Para adicionar tabelas DirectQuery, use XMLA.

Você pode editar ao vivo um Direct Lake e importar um modelo semântico na Área de Trabalho, mas não pode adicionar mais tabelas. Você só pode adicionar tabelas da modelagem Web do Power BI para o Direct Lake e importar modelos compostos.

Criar modelos compostos na modelagem da Web

Na modelagem web do Power BI, você pode criar modelos semânticos com tabelas de importação ou Direct Lake. Você não pode adicionar tabelas DirectQuery. Você pode adicionar mais tabelas no outro modo de armazenamento para criar um modelo composto.

Usar modelos compostos

Com modelos compostos, você pode se conectar a diferentes 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:

• Importar dados para o Power BI, que é a maneira mais comum de obter dados.
• Conectar-se diretamente aos dados no repositório fonte original usando o DirectQuery. Para saber mais sobre o DirectQuery, confira DirectQuery no Power BI.

Quando você usa o DirectQuery, os modelos compostos tornam possível criar um modelo do Power BI, como um único arquivo .pbix do Power BI Desktop, que execute uma destas ações ou ambas:

• Combina dados de uma ou mais fontes de DirectQuery.
• Combina dados de fontes de DirectQuery e importação de dados.

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

• Dados de vendas de um data warehouse corporativo.
• Dados de meta de vendas de um banco de dados departamental do SQL Server.
• Dados importados de uma planilha.

Um modelo semântico que combina tabelas de mais de uma fonte DirectQuery, ou combina DirectQuery, Direct Lake e tabelas importadas, é um modelo semântico composto.

É possível criar relações entre tabelas, como sempre, mesmo as tabelas provenientes de outras origens. Todas as relações de origem cruzada são criadas com uma cardinalidade de muitos para muitos, independentemente da cardinalidade atual. É possível alterá-las para "um para muitos", "muitos para um" ou "um para um". Independentemente da cardinalidade definida, as relações entre origens têm um comportamento diferente. Não é possível usar funções DAX (Data Analysis Expressions) para recuperar valores no lado do one a partir do lado do many. Também é possível ver o impacto de desempenho em comparação com as relações "muitos para muitos" na mesma origem.

Exemplo de um modelo composto

Para obter um exemplo de um modelo composto, considere a possibilidade de um relatório que se conecta a um depósito de dados corporativos no SQL Server usando o DirectQuery. Nesse caso, o data warehouse contém dados de Vendas por País, Trimestre e Bicicleta (produto) , conforme mostrado na seguinte imagem:

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

Porém, e se você tiver dados em uma planilha do Excel sobre o gerente 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 então, pode levar meses, na melhor das hipóteses.

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

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

É aí que entram os modelos compostos. Os modelos compostos permitem que você se conecte ao data warehouse usando o DirectQuery e use Obter dados para fontes adicionais. Neste exemplo, primeiro vamos estabelecer a conexão do DirectQuery para o data warehouse corporativo. Usamos Obter dados, escolhemos o Excel e navegamos até a planilha que contém os dados locais. Por fim, podemos importar 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 original Bicicleta do SQL Server e uma nova tabela ProductManagers. A nova tabela contém os dados importados do Excel.

Da mesma forma, na exibição Relacionamento no Power BI Desktop, agora podemos ver uma tabela adicional chamada ProductManagers.

Agora, precisamos relacionar essas tabelas às outras tabelas no modelo. Como sempre, criamos um relacionamento entre a tabela Bicicleta do SQL Server e a tabela importada ProductManagers. Ou seja, o relacionamento entre Bike[ProductName] e ProductManagers[ProductName] . Como discutido anteriormente, todas as relações que passam pela origem padrão têm a cardinalidade muitos para muitos.

Agora que estabelecemos esse relacionamento, ele é mostrado na exibição Relacionamento no Power BI Desktop, como se poderia esperar.

Agora podemos criar elementos visuais usando qualquer um dos campos na lista Campos. Essa abordagem combina perfeitamente os dados de várias fontes. Por exemplo, o total de SalesAmount de cada Gerente de Produto é exibido na seguinte imagem:

O exemplo a seguir exibe um caso comum de uma tabela dimensão, como Produto ou Cliente, que é estendida com alguns dados extras importados de outro lugar. Também é possível fazer com que as tabelas usem o DirectQuery para se conectar a várias fontes. Para continuar o exemplo, imagine que SalesTargets por País e Período sejam armazenados em um banco de dados de departamento separado. Como de costume, você pode usar Obter dados para se conectar aos dados, como mostrado na imagem a seguir:

Como fizemos anteriormente, podemos criar relacionamentos entre a nova tabela e outras tabelas no modelo. Em seguida, podemos criar visuais que combinam os dados da tabela. Vamos examinar novamente a exibição Relacionamentos, em que estabelecemos novos relacionamentos:

A imagem a seguir baseia-se em novos dados e relacionamentos que criamos. O visual na parte inferior esquerda mostra o total de Valor de Vendas versus Destino, e o cálculo de variância mostra a diferença. Os dados de Valor de Vendas e o Destino são provenientes de dois bancos de dados do SQL Server diferentes.

Definir o modo de armazenamento

Cada tabela em um modelo composto tem um modo de armazenamento que indica se ela é baseada no DirectQuery ou em importação. Você pode exibir e modificar o modo de armazenamento no painel Propriedades . Para exibir o modo de armazenamento:

1. No modo de exibição Modelo , selecione a tabela.
2. No painel Propriedades , expanda a seção Avançado e expanda a lista de modos de armazenamento .

Você também pode visualizar o modo de armazenamento na dica de ferramenta para cada tabela ao passar o mouse sobre ela no painel Dados.

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

Para saber mais sobre o modo de armazenamento, confira 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 o DirectQuery. As DAX (Expressões de Análise de Dados) que definem a tabela calculada podem fazer referência a tabelas importadas, a tabelas do DirectQuery ou a uma combinação das duas.

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

Implicações de segurança

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

Assim, as informações armazenadas na planilha agora estão incluídas em uma consulta enviada ao banco de dados relacional. Se essas informações são confidenciais, você deve considerar as implicações de 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 precisa de permissões para o arquivo do Excel.

• As configurações de criptografia para cada fonte. Convém evitar a recuperação de informações de uma fonte por meio de uma conexão criptografada e sua inclusão acidental em uma consulta enviada a outra fonte por meio de uma conexão não criptografada.

Para confirmar que você considerou quaisquer implicações de segurança, o Power BI Desktop exibe uma mensagem de aviso ao criar um modelo composto.

Além disso, se um autor adicionar Table1 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 pela RLS (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 recupera 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. O autor mal-intencionado do arquivo do Power BI Desktop pode exibir as informações. 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 que é exibido quando você abre um arquivo que contém consultas SQL nativas.

Implicações de desempenho

Ao usar o DirectQuery, considere sempre o desempenho. Verifique se a fonte de back-end tem recursos suficientes para fornecer uma boa experiência para os usuários. Uma boa experiência significa que os visuais são atualizados em cinco segundos ou menos. Para obter mais conselhos de desempenho, confira DirectQuery no Power BI.

O uso de modelos compostos gera considerações de desempenho adicionais. Um único visual pode enviar consultas para várias fontes. Muitas vezes, uma consulta passa seus resultados para uma segunda fonte. Essa 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 valor total de vendas para um conjunto de Gerentes de Produtos selecionados primeiro precisaria encontrar quais produtos esses gerentes de produto gerenciam. 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 fonte que consulta em um nível mais baixo de granularidade, com os dados posteriormente sendo agregados localmente: à medida que o número de Produtos que atende aos critérios de filtro de Gerente de produto aumenta, pode se tornar ineficiente ou inviável incluir todos os produtos em uma cláusula WHERE. Em vez disso, você pode consultar a origem relacional em um nível inferior de Produtos e agregar os resultados localmente. Se a cardinalidade de Produtos exceder um limite de um 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 origem, e se a fonte externa não dá suporte à passagem eficiente de muitos valores literais que definem o agrupamento, você precisa enviar uma consulta SQL por grupo por valor.

  Um visual que solicita uma contagem distinta de CustomerAccountNumber da tabela do SQL Server por Gerentes de Produto importados da planilha precisa incluir os detalhes da tabela Gerentes de Produto na consulta enviada ao SQL Server. Em outras fontes, por exemplo Redshift, essa ação é impraticável. Em vez disso, deve haver uma consulta SQL enviada por Gerente de Vendas até um limite prático e, nesse ponto, a consulta falha.

Cada um desses casos tem suas próprias implicações sobre o 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 aumenta, preste 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 à fonte subjacente para cada total ou subtotal nível, em vez de agregar os valores detalhados localmente. Um visual de tabela simples com totais envia duas consultas à 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 do DirectQuery ou de todas as fontes de importação envolvidas em um modelo de dados. Um modelo composto é formado por um ou mais grupos de origem. Considere os seguintes exemplos:

• Um modelo composto que se conecta a um modelo semântico do Power BI chamado Vendas e enriquece o modelo semântico adicionando a medida de Vendas YTD, que não está disponível no modelo semântico original. Esse 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, além de fazer uma conexão DirectQuery com um modelo semântico do Power BI chamado Vendas. Nesse caso, há dois grupos de origem, conforme mostrado na seguinte imagem:
  • O primeiro grupo de origem contém as tabelas da planilha Destinos do Excel, bem como o arquivo CSV Regiões.
  • O segundo grupo de origem contém os itens do modelo semântico Vendas do Power BI.

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

Grupos de origem e relacionamentos

Um modelo composto tem dois tipos de relações:

• Relacionamentos entre grupos de origem. Essas relações conectam itens em um grupo de origem. Esses relacionamentos são sempre regulares, a menos que sejam muitos para muitos; nesse caso, são limitados.
• Relacionamentos entre grupos de origem. Esses relacionamentos começam em um grupo de origem e terminam em outro. Esses relacionamentos são sempre limitados.

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

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

Local e remoto

Qualquer item em um grupo de origem que seja um grupo de origem do DirectQuery é remoto, a menos que você defina o item localmente como parte de uma extensão ou enriquecimento para a origem do DirectQuery e ele não faz parte da origem remota, como uma medida ou uma tabela calculada. Uma tabela calculada com base em uma tabela do grupo de origem DirectQuery pertence ao grupo de origem "Importar" e é local. Qualquer item no grupo de origem "Import" é local. Por exemplo, se você definir a seguinte medida em um modelo composto que usa uma conexão DirectQuery com a origem de Inventário, a medida será local:

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

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

Os grupos de cálculo ajudam você a reduzir o número de medidas redundantes e agrupar expressões de medida comuns. Casos de uso típicos são cálculos de inteligência temporal em que você deseja mudar de dados reais para cálculos acumulados do mês, do trimestre ou do ano até a data atual. 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 grupo de origem remoto. Se uma medida se referir apenas a itens de um único grupo de origem remoto e o modelo remoto definir um grupo de cálculo que afeta a medida, o grupo de cálculo será aplicado, mesmo se você definir a medida 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 remoto 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:

• Vendas do Revendedor é 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 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 Vendas do Revendedor , pois eles estão no mesmo modelo. Isso significa que os resultados retornados pela medida Total de Vendas precisam ser avaliados cuidadosamente. Imagine que você use o grupo de cálculo no modelo remoto para retornar resultados ano a ano. O resultado retornado pelas Vendas do Revendedor agora é um valor que reflete o total do ano até o momento, enquanto o resultado retornado pelas Vendas pela Internet ainda é um valor real. O resultado do Total de Vendas agora provavelmente será inesperado, pois soma um resultado real com uma totalização do ano até o momento.

Modelos compostos nos modelos semânticos do Power BI e no 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, AAS (Azure Analysis Services) e SQL Server 2022 Analysis Services. Com um modelo de composição, você pode combinar os dados nessas fontes com outros dados importados e DirectQuery. Os autores de relatório que desejam combinar os dados de seu modelo semântico empresarial com outros dados que possuem, como uma planilha do Excel, ou desejam personalizar ou enriquecer os metadados de seu modelo semântico empresarial, acham essa funcionalidade especialmente útil.

Gerenciando modelos compostos em modelos semânticos do Power BI

Para criar e usar modelos compostos em modelos semânticos do Power BI, seu locatário precisa ter os seguintes comutadores habilitados:

• Permitir pontos de extremidade XMLA e analisar no Excel com modelos semânticos locais. Se você desabilitar essa opção, não poderá fazer uma conexão DirectQuery com um modelo semântico do Power BI.
• Os usuários podem trabalhar com modelos semânticos do Power BI no Excel usando uma conexão dinâmica. Se você desabilitar essa opção, os usuários não poderão fazer conexões dinâmicas com modelos semânticos do Power BI para que o botão Fazer alterações neste modelo não esteja disponível.
• Permitir conexão do DirectQuery com modelos semânticos do Power BI. Consulte os parágrafos a seguir para obter mais informações sobre essa opção e o efeito de desativá-la.

Além disso, para capacidades Premium e Premium Por Usuário, a configuração do "endpoint XMLA" deve ser habilitada e configurada como "Somente Leitura" ou "Leitura/Gravação".

Os administradores de locatários podem habilitar ou desabilitar as conexões do DirectQuery com os modelos semânticos do Power BI no portal de administração. Embora essa configuração esteja habilitada por padrão, desabilitá-la 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 funcionando. Os usuários ainda podem criar o modelo de composição no Power BI Desktop, mas não podem publicá-lo no serviço. Em vez disso, ao criar uma conexão DirectQuery com o modelo semântico do Power BI selecionando Fazer alterações nesse modelo, você verá a seguinte mensagem de aviso:

Dessa forma, você ainda poderá explorar o modelo semântico no ambiente do Power BI Desktop local e criar o modelo composto. No entanto, você não pode 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 é bloqueada:

As conexões dinâmicas com os modelos semânticos do Power BI não são influenciadas pelo switch, nem as conexões dinâmicas ou do DirectQuery com o Analysis Services. Essas conexões continuam funcionando independentemente da configuração de comutador. Além disso, todos os relatórios publicados que usam um modelo composto em um modelo semântico do Power BI continuam funcionando, mesmo que o interruptor esteja desligado depois de publicados.

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

Para criar um modelo composto em um modelo semântico do Power BI ou no modelo do Analysis Services, seu relatório precisa de um modelo local. Você pode iniciar de uma conexão dinâmica e adicionar ou atualizar para um modelo local, ou começar com uma conexão do DirectQuery ou dados importados, o que cria automaticamente um modelo local em seu relatório.

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

Se você estiver conectado a um modelo semântico do Power BI, verá uma mensagem informando a qual modelo semântico do Power BI você está conectado:

Se você quiser personalizar os metadados dos campos em seu modelo semântico conectado dinamicamente, selecione Fazer alterações neste modelo na barra de status. Como alternativa, selecione o botão Fazer alterações nesse modelo na faixa de opções, conforme mostrado na imagem a seguir. No Modo de Exibição de Relatório , o botão Fazer alterações neste modelo está na guia Modelagem . No Modo de Exibição de Modelo, o botão está na guia Página Inicial .

Quando você seleciona o botão, aparece uma caixa de diálogo que confirma a adição de um modelo local. Selecione Adicionar um modelo local para habilitar a criação de novas colunas ou modificar os metadados para campos de modelos semânticos do Power BI ou do Analysis Services. A imagem a seguir mostra a caixa de diálogo.

Quando você tiver uma conexão dinâmica com uma fonte do Analysis Services, não haverá modelo local. Para usar o DirectQuery para fontes conectadas dinamicamente, como modelos semânticos do Power BI e Analysis Services, você precisa 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 também é publicado.

Encadeamento

Modelos semânticos e 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.

Por exemplo, imagine que seu colega publique um modelo semântico do Power BI chamado Vendas e orçamento com base em um modelo do Analysis Services chamado Vendas e o combine com uma planilha do Excel chamada Orçamento. Em seguida, você cria e publica um relatório e modelo semântico composto, chamado Vendas e Orçamento da Europa, usando o modelo semântico de Vendas e Orçamento do Power BI com suas próprias modificações. Esse modelo semântico é o terceiro da cadeia.

1. A primeira cadeia é o modelo Sales Analysis Services.
2. A segunda cadeia é o modelo semântico composto de Vendas e Orçamento do Power BI.
3. A terceira cadeia é o modelo semântico composto Vendas e Orçamento da Europa do Power BI.

A imagem a seguir visualiza esse processo de encadeamento.

O comprimento da cadeia na imagem anterior é três, que é o comprimento máximo. Não há suporte para ampliar o tamanho da cadeia além de três, pois isso resulta em erros.

Permissões e licenciamento

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

O proprietário do modelo composto precisa de 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 build nos modelos semânticos usados como fontes.

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

O exemplo a seguir ilustra as permissões necessárias:

• Modelo composto A (de propriedade do Proprietário A)

  • Fonte de dados A1: modelo semântico B.
    O proprietário A deve ter permissão build no Modelo Semântico B para que os usuários exibam o relatório que usa o Modelo Composto A.

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

  • Fonte de dados C1: Modelo Semântico D
    O proprietário C deve ter permissão build no Modelo Semântico D para que os usuários exibam o relatório que usa o Modelo Composto C.
  • Fonte de dados C2: Modelo Composto A
    O proprietário C deve ter permissão Build no Modelo Composto A e permissão de Leitura no Modelo Semântico B.

Um usuário que exibe relatórios que usam 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 exibindo relatórios que usam 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 modelo semântico na cadeia estiver em um espaço de trabalho Premium por Usuário, o usuário que o acessar precisará de uma licença Premium por Usuário. Se qualquer modelo semântico na cadeia estiver em um workspace Pro, o usuário que o acessar precisará de uma licença Pro. Se todos os modelos semânticos na cadeia estiverem em capacidades Premium ou Fabric F64 ou maior capacidade, um usuário poderá acessá-lo usando uma licença gratuita.

Aviso de segurança

Ao usar os modelos compostos em modelos semânticos do Power BI e no recurso de modelos do Analysis Services , você verá 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 fonte de dados. Esse aviso de segurança se aplica à combinação do DirectQuery e à importação de fontes em um modelo de dados. Para obter mais informações sobre esse comportamento, consulte o uso de modelos compostos no Power BI Desktop.

Cenários com suporte

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:

• Conecte-se a dados de várias fontes: Importar (como arquivos), modelos semânticos do Power BI, modelos do Analysis Services
• Criar relações entre diferentes fontes de dados
• Escrever medidas que usam campos de diferentes fontes de dados
• Criar novas colunas para tabelas de modelos semânticos do Power BI ou modelos do Analysis Services
• Criar visuais que usam colunas de diferentes fontes de dados
• Remova uma tabela do modelo usando a lista de campos, para manter os modelos o mais concisos e enxutos possível (ao se conectar a uma perspectiva, não é possível remover tabelas do modelo)
• Especifique quais tabelas carregar, em vez de ter que carregar todas as tabelas quando desejar apenas um subconjunto específico de tabelas. Consulte o Carregando um subconjunto de tabelas posteriormente neste documento.
• Especifique se deseja adicionar tabelas que você adicionar 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 ou modelo

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

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

• Você não pode editar, excluir nem criar relações no mesmo modelo semântico do Power BI ou na fonte do Analysis Services. Se você tiver acesso de edição a essas fontes, poderá fazer as alterações diretamente na fonte de dados.

• Você não pode alterar os tipos de dados de colunas 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 fonte 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, você deve definir todas as credenciais.

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

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

• As regras RLS se aplicam à origem na qual estão definidas, mas não se aplicam a nenhum outro modelo semântico no modelo. O RLS definido no relatório não se aplica a fontes remotas e o RLS definido em fontes remotas não se aplica a outras fontes de dados. Além disso, você não pode definir RLS em uma tabela carregada de uma origem remota e o RLS definido em tabelas locais não filtra tabelas carregadas de uma fonte remota.

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

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

  

  Para obter mais informações sobre o uso de colunas de data versus hierarquias de data, confira aplicar data ou hora automática no Power BI Desktop.

• O comprimento máximo de uma cadeia de modelos é três. Não há suporte para ampliar o tamanho da cadeia além de três, pois isso resulta em erros.

• Você pode configurar um sinalizador para desencorajar o encadeamento em um modelo, evitando que uma corrente seja criada ou estendida. Para saber mais, confira Gerenciar conexões DirectQuery a um modelo semântico publicado.

• O Power Query não mostra a conexão com um modelo semântico do Power BI ou com o modelo do Analysis Services.

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

• Os parâmetros dos nomes de banco de dados e servidor estão desabilitados no momento.
• Não há suporte para a definição de RLS em tabelas de uma fonte remota.
• Não há suporte para o uso das seguintes fontes como uma fonte do DirectQuery:
  • Modelos tabulares do SSAS (SQL Server Analysis Services) antes da versão 2022
  • Modelos multidimensionais SSAS
  • SAP HANA
  • SAP Business Warehouse
  • Modelos semânticos em tempo real
  • Exemplos de modelos semânticos
  • Atualização do Excel Online
  • Dados importados de arquivos do Excel ou CSV no serviço
  • Métricas de uso
  • Modelos semânticos armazenados em “Meu espaço de trabalho”
• No momento, não há suporte para o uso do Power BI Embedded com modelos semânticos que incluem uma conexão DirectQuery com um modelo externo do Analysis Services (Azure Analysis Services/SQL Server 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 SSO (logon único) têm suporte 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 workspace depois de configurar a conexão DirectQuery, precisará atualizar a fonte de dados no Power BI Desktop para que o relatório continue funcionando.
• A APR (atualização automática de página) só tem suporte em alguns cenários, dependendo do tipo de fonte de dados. Para obter mais informações, confira Atualização automática de página no Power BI.
• Atualmente, não há suporte para assumir o controle de um modelo semântico que esteja usando o recurso DirectQuery para outros modelos semânticos.
• Assim como acontece com qualquer fonte de dados do DirectQuery, 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.

Ao trabalhar com o DirectQuery para modelos semânticos do Power BI e o Analysis Services, considere as seguintes diretrizes:

• Usar colunas de baixa cardinalidade em relacionamentos entre grupos de origem: quando você cria uma relação entre dois grupos de origem diferentes, as colunas que participam do relacionamento (também chamadas de colunas de junção) devem ter baixa cardinalidade, idealmente 50.000 ou menos. Essa consideração se aplica a colunas de chave que não são de cadeia de caracteres; para colunas de chave de cadeia de caracteres, veja a consideração a seguir.
• Evitar o uso de colunas de chaves de cadeias de caracteres grandes em relacionamentos de grupo entre origens: ao criar um relacionamentos de grupos entre origens, evite usar colunas de cadeia de caracteres grandes como colunas de relacionamento, especialmente para colunas com maior cardinalidade. Quando você precisar usar colunas de cadeias de caracteres como a coluna de relação, calcule o comprimento de cadeia de caracteres esperado para o filtro multiplicando cardinalidade (C) pelo comprimento médio da coluna de cadeia de caracteres (A). Verifique se o comprimento da cadeia de caracteres esperado está abaixo de 250.000, de modo que A ∗ C < 250.000.

Para obter mais considerações e orientações, confira orientação do modelo composto.

Considerações sobre o locatário

Você deve publicar qualquer modelo com uma conexão DirectQuery com um modelo semântico do Power BI ou com o Analysis Services no mesmo locatário. Esse requisito é especialmente importante ao acessar um modelo semântico do Power BI ou um modelo do Analysis Services usando identidades de convidado B2B, conforme mostrado no diagrama a seguir.

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 acessa os dados fornecidos pela Fabrikam. Com o Power BI Desktop, a Ash cria uma conexão DirectQuery com um modelo do Analysis Services que a Fabrikam hospeda.

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

Se Ash publicar o relatório no serviço Power BI da Contoso (etapa 2), o modelo semântico publicado no locatário da Contoso não pode autenticar-se com sucesso contra o modelo do Analysis Services da Fabrikam (etapa 3). Como resultado, o relatório não funciona.

Nesse cenário, como a Fabrikam hospeda o modelo do Analysis Services, você também deve publicar o relatório no tenant da Fabrikam. Após a publicação no locatário da Fabrikam (etapa 4), o modelo semântico pode acessar 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 observar resultados inesperados. A seção a seguir explica como esses resultados podem ser obtidos.

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

A OLS é definida para e aplicada no modelo de fonte. Você não pode defini-lo para um modelo composto criado no modelo de origem.

Ao criar um modelo composto sobre um modelo semântico do Power BI protegido por OLS ou o modelo do Analysis Services por meio da conexão DirectQuery, você copia o esquema de modelo do modelo de origem para o modelo composto. O que você copia depende do que você tem permissão para ver no modelo de origem de acordo com as regras do OLS que se aplicam lá. Você não copia os dados para o modelo composto– você sempre os recupera por meio do DirectQuery do modelo de origem quando necessário. Em outras palavras, a recuperação de dados sempre volta ao modelo de fonte, em que as regras da OLS se aplicam.

Como o modelo composto não é protegido por regras OLS, os objetos que os consumidores do modelo composto podem ver são aqueles visíveis por você no modelo de origem, em vez dos que eles próprios poderiam acessar. Essa situação pode resultar nos seguintes resultados:

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

Um ponto importante é que, apesar do caso descrito no primeiro marcador, os consumidores do modelo composto nunca veem os dados reais que não devem ver, pois 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 a OLS bloqueia o acesso não autorizado.

Com esse pano de fundo em mente, considere o seguinte cenário:

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

   • Os usuários financeiros não podem ver a tabela Customer
   • Os usuários de marketing não podem ver a tabela Territory

2. Finance_user publica um modelo semântico chamado “Modelo semântico de Finance” e um relatório chamado "Relatório Finance" que se conecta por meio do DirectQuery ao modelo semântico corporativo publicado na etapa 1. O relatório Finance inclui um visual que usa uma coluna da tabela Territory.

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

4. Marketing_user cria um relatório chamado “Relatório de Marketing” que usa o modelo semântico Finance como fonte. A lista de campos mostra as tabelas e colunas às quais Finance_user tem acesso. Portanto, a tabela Territory é mostrada na lista de campos, mas a tabela Customer não é. No entanto, quando o Marketing_user tenta criar um visual que aproveita 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 da OLS são ativadas novamente e bloqueiam o acesso. O mesmo acontece quando o Marketing_user cria um modelo semântico e um relatório que se conectam ao modelo semântico Finance com por conexão do DirectQuery. Ele vê a tabela Territory na lista de campos, pois é isso que o Finance_user pode ver, mas quando tenta criar um visual que utiliza essa tabela, ele é bloqueado pelas regras de OLS no modelo semântico empresarial.

5. Agora, digamos que o Admin_user atualiza as regras da OLS no modelo semântico empresarial para impedir que Finance veja a tabela Territory.

6. As regras de OLS atualizadas só são refletidas no modelo semântico Finance quando são atualizadas. Assim, quando o Finance_user atualiza o modelo semântico Finance, a tabela Territory não é mais mostrada na lista de campos e o visual no relatório Finance que usa uma coluna da tabela Territory retorna um erro para Finance_user, pois agora ele não tem permissão para acessar a tabela Territory.

Para resumir:

• Os consumidores de um modelo composto veem os resultados das regras da OLS que foram aplicáveis ao autor do modelo composto quando criaram o modelo. Portanto, 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 teve acesso quando criou o modelo, independentemente do acesso a que o usuário atual tem no modelo de origem.
• Você não pode definir regras OLS no próprio modelo composto.
• Um consumidor de um modelo composto nunca vê dados reais que não deveriam 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 da OLS, essas alterações afetarão apenas 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 ao modelo do Analysis Services usando uma conexão DirectQuery, você escolhe 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 o modelo. Quando você se conectar a uma perspectiva, o modelo conterá todas as tabelas no modelo semântico ou modelo e todas as tabelas não incluídas na perspectiva serão ocultadas. Além disso, qualquer tabela que possa ser adicionada à perspectiva será adicionada automaticamente. No menu Configurações, você pode decidir se conectar automaticamente a tabelas adicionadas ao modelo semântico ou modelo depois de configurar a conexão pela primeira vez.

Essa caixa de diálogo não é mostrada para conexões dinâmicas.

Configurando regras de eliminação de duplicação

Você pode especificar regras de eliminação de duplicaçã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 mostrado anteriormente:

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

• Insira um texto para adicionar ao nome de tabelas ou medidas conflitantes.
• Especifique se deseja que o texto seja adicionado à tabela ou ao nome da medida como um prefixo ou sufixo.
• Aplique a regra de desduplicação a tabelas, medidas ou ambas.
• Escolha aplicar a regra de eliminação de duplicação somente quando ocorrer um conflito de nomes ou aplicá-la o tempo todo. O padrão é aplicar a regra somente quando ocorre a duplicação. Em nosso exemplo, se uma tabela ou medida da fonte de marketing não tiver uma duplicata na fonte de vendas, não terá seu nome alterado.

Depois de fazer as conexões e configurar a regra de eliminação de duplicação, sua lista de campos mostra 'Cliente' e 'Cliente (marketing)' de acordo com a regra de eliminação de duplicação configurada em nosso exemplo:

Se você não especificar uma regra de eliminação de duplicação ou as regras de eliminação de duplicação especificadas não resolverem o conflito de nomes, as regras de eliminação de duplicação padrão ainda serão aplicadas. As regras de eliminação de duplicação padrã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 como 'Cliente 2'.

Modificações XMLA e modelos compostos

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

Para obter mais informações sobre marcas de linhagem de objeto de modelo semântico, consulte marcas de linhagem para modelos semânticos do Power BI.

Considerações e limitações

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

Conexões de modo misto – quando você usa 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 estabelecer o mapeamento de gateway para que os visuais apareçam corretamente.

No momento, há suporte para atualização incremental somente para modelos compostos conectando-se a fontes de dados SQL, Oracle e Teradata.

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

• SAP HANA
• SAP Business Warehouse
• SQL Server Analysis Services anteriores à versão 2022
• Métricas de uso (meu workspace)

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 ao usar modelos compostos. Muitas dessas limitações agora são por tabela, dependendo do modo de armazenamento dela. 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 do DirectQuery ainda pode se referir apenas a colunas na mesma tabela. Outras limitações se aplicam ao modelo como um todo se quaisquer das tabelas no modelo forem DirectQuery. Por exemplo, o recurso QuickInsights não estará disponível em um modelo se qualquer uma das tabelas nele tiver um modo de armazenamento do DirectQuery.

Se você usar a 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 serão incluídos somente 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 fonte até a próxima atualização manual ou agendada.

Conteúdo relacionado

Para obter mais informações sobre modelos compostos e DirectQuery, confira 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
• Modelar relações no Power BI Desktop