Usar 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 modelos compostos, essa restrição é removida. Um relatório pode incluir perfeitamente as conexões de dados de mais de um DirectQuery ou conexão de importaçã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 diferentes grupos de origem. Esses grupos de origem podem ser uma ou mais conexões do DirectQuery e uma conexão de importação, duas ou mais conexões do DirectQuery ou qualquer combinação delas. Este artigo descreve os modelos compostos em detalhes.

• Relações muitos-para-muitos: Com modelos compostos, você pode estabelecer relações muitos para muitos entre tabelas. Esta abordagem remove os requisitos de valores exclusivos nas tabelas. Ela também remove as soluções alternativas anteriores, como introduzir novas tabelas somente para estabelecer relações. Para mais informações, confira Aplicar relações muitos para muitos no Power BI Desktop.

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

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 que combina dados de mais de uma origem de DirectQuery ou que combina o DirectQuery com a importação de dados é chamado de modelo 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. O modo de armazenamento pode ser exibido 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 da tabela SalesTargets.

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

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.

As tabelas calculadas sempre são 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 que foram recuperados de outra origem. No exemplo anterior, o visual que mostra (Valor de Vendas) por Gerente de Produto envia uma consulta SQL ao 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 de banco de dados que pode 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. 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 todas as 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 Tabela1 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 contém modelos compostos, as informações que alguém recupera de uma fonte usando as credenciais do usuário que abre o arquivo são enviadas para outra fonte de dados como parte da consulta. As informações podem ser exibidas 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 que é exibido quando você abre um arquivo que contém consultas SQL nativas.

Implicações de desempenho

Ao usar o DirectQuery, você deve sempre considerar 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, confira DirectQuery no Power BI.

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

• Uma consulta de fonte que inclui um grande número de valores literais: por exemplo, um visual que solicitar o total de Valor de Vendas para um conjunto de Gerentes de Produto selecionado primeiro precisará saber quais Produtos eram gerenciadas pelos gerentes de produto. Essa sequência deve ocorrer antes que o visual envie uma consulta SQL que inclui todas as IDs de produto em uma cláusula WHERE.

• 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 fonte, uma por grupo por valor: quando a agregação usa DistinctCount e é agrupada por alguma coluna de outra fonte, e se a fonte externa não dão suporte à passagem eficiente de vários 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 Gerente de Produto importada de uma planilha precisa passar 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 a cardinalidade cresce, você deve prestar mais atenção ao impacto sobre o 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 enviaria as 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 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ê adicionou outra conexão DirectQuery a outra fonte, como uma conexão DirectQuery a um banco de dados do SQL Server chamado Estoque, os itens dessa fonte serão adicionados como outro grupo de origem:

Grupos de origem e relacionamentos

Há dois tipos de relacionamentos em um modelo composto:

• Relacionamentos entre grupos de origem. Esses relacionamentos associam 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 seguinte imagem, adicionamos três relacionamentos entre grupos de origem, associando tabelas entre vários grupos de origem:

Local e remoto

Qualquer item que esteja em um grupo de origem que pertença ao DirectQuery é considerado remoto, a menos que o item tenha sido definido localmente como parte de uma extensão ou enriquecimento para a origem do DirectQuery e não faça 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 é 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 Estoque, a medida será considerada local:

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

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

Os grupos de cálculo fornecem uma forma de reduzir o número de medidas redundantes, bem como agrupar expressões de medida comuns. Casos de uso típicos são cálculos de inteligência de tempo em que você deseja conseguir mudar de cálculos reais para cálculos do mês até o momento, do trimestre até o momento ou do ano até o momento. 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 grupo de origem remoto e o modelo remoto definir um grupo de cálculo que afeta a medida, esse grupo de cálculo será aplicado, independentemente de a medida ter sido definida no modelo remoto ou no modelo local. No entanto, se uma medida não se referir exclusivamente a itens de um grupo de origem remoto, mas se referir a itens de um grupo de origem remoto em que é aplicado um grupo de cálculo remoto, 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, pois 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 elas estão no mesmo modelo. Isso significa que os resultados retornados pela medida Total de Vendas precisam ser avaliados cuidadosamente. Imagine que usamos o grupo de cálculo no modelo remoto para retornar os resultados do ano até o momento. 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 o Analysis Services e modelos semânticos do Power BI, você pode criar um modelo composto usando uma conexão DirectQuery para se conectar aos modelos semânticos do Power BI, ao Azure Analysis Services (AAS) e ao SQL Server Analysis Services 2022. Usando um modelo composto, você pode combinar os dados nessas fontes com outros dados importados e do DirectQuery. Os autores de relatórios que desejam combinar os dados do seu modelo semântico corporativo com outros dados que possuem, como uma planilha do Excel, ou desejam personalizar ou enriquecer os metadados do seu modelo semântico corporativo, acharão essa funcionalidade especialmente útil.

Gerenciando modelos compostos em modelos semânticos do Power BI

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

• Permitir pontos de extremidade XMLA e analisar no Excel com modelos semânticos locais. Se essa opção estiver desabilitada, não será possível estabelecer uma conexão do 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 essa opção estiver desabilitada, os usuários não poderão fazer conexões dinâmicas com os modelos semânticos do Power BI; portanto, o botão Fazer alterações neste modelo não poderá ser acessado.
• 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 as 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 as conexões do DirectQuery com os modelos semânticos do Power BI no portal de administração. Embora esse recurso esteja habilitado por padrão, desabilitá-lo impedirá que os usuários publiquem novos modelos compostos em modelos semânticos do Power BI no serviço.

Os relatórios existentes que utilizam um modelo composto em um modelo semântico do Power BI continuam funcionando e os usuários ainda podem criar o modelo composto usando o Desktop, mas não podem publicá-lo no serviço. Em vez disso, ao criar uma conexão do 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 poderá explorar o modelo semântico no ambiente do Power BI Desktop local e criar o modelo composto. No entanto, você não poderá 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 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. Elas continuam funcionando, independentemente da desativação da opção. Além disso, todos os relatórios publicados que utilizam um modelo composto em um modelo semântico do Power BI continuarão funcionando, mesmo se a opção tiver sido desativada após a publicação.

Criando 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 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 estão sendo 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. Na Exibição de relatório, clique no botão Fazer alterações nesse modelo na guia Modelagem. Na Exibição de modelo, o botão está na guia Página Inicial.

A seleção do 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 colunas ou a modificação dos metadados, para campos dos modelos semânticos do Power BI ou Analysis Services. A imagem abaixo mostra a caixa de diálogo exibida.

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 para o serviço do Power BI, um modelo semântico desse modelo local também é publicado.

Encadeamento

Os modelos semânticos e os modelos semânticos nos quais se baseiam formam uma cadeia. Esse processo, chamado de 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 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.

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

A cadeia na imagem anterior é de tamanho 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 ter as permissões adequadas para todos os modelos semânticos e modelos na cadeia.

O proprietário do modelo composto requer a 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, a criação da conexão do modelo composto no Power BI Desktop ou a criação do relatório no Power BI exigem permissões Build 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 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.

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

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

  • Fonte de dados A1: modelo semântico B.
    O Proprietário A deve ter a permissão Build no Modelo Semântico B para que os usuários possam exibir o relatório usando 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 a permissão Build no Modelo Semântico D para que os usuários possam exibir o relatório usando 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 visualiza relatórios usando o Modelo Composto A deve ter permissões de Leitura tanto no Modelo Composto A quanto no Modelo Semântico B, enquanto um usuário que visualiza relatórios usando Modelo Composto C deve ter permissões de Leitura no Modelo Composto C, no Modelo Semântico D, no Modelo Composto A e no Modelo Semântico B.

Se qualquer conjunto de dados na cadeia estiver em um workspace Premium por Usuário, o usuário que o acessar precisará de uma licença Premium por Usuário. Se algum conjunto de dados na cadeia estiver em um workspace Pro, o usuário que o acessar precisará de uma licença Pro. Se todos os conjuntos de dados na cadeia estiverem em capacidades Premium, Fabric F64 ou superior, um usuário poderá acessá-la usando uma Licença Gratuita.

Aviso de segurança

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

Os dados podem ser enviados de uma fonte de dados para outra, que é o mesmo aviso de segurança para combinar as fontes do DirectQuery e de importação em um modelo de dados. Para saber mais sobre esse comportamento, confira usando modelos compostos no Power BI Desktop.

Cenários com suporte

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

• Conexão com dados de várias fontes: importação (como arquivos), modelos semânticos do Power BI, modelos do Analysis Services
• Criar relacionamentos entre diferentes fontes de dados
• Escrever medidas que usam campos de diferentes fontes de dados
• Criando novas colunas nas tabelas usando modelos semânticos do Power BI ou modelos do Analysis Services
• Criar visuais que usam colunas de diferentes fontes de dados
• Você pode remover uma tabela do modelo usando a lista de campos, para que os modelos fiquem sempre concisos e enxutos ao máximo (se você se conectar com uma perspectiva, não poderá remover tabelas do modelo)
• Você pode especificar quais tabelas carregar, em vez de precisar carregar todas as tabelas quando quiser apenas um subconjunto específico de tabelas. Consulte o Carregando um subconjunto de tabelas posteriormente neste documento.
• Você pode especificar se quer adicionar as tabelas que serão adicionadas mais tarde ao modelo semântico depois de fazer a conexão no 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 baseado em outro modelo semântico, todas as credenciais precisam ser definidas.

• 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 são feitas usando logon único. No momento, não há suporte para autenticação com uma entidade de serviço.

• As regras de RLS são aplicadas na fonte na qual estão definidas, mas não são aplicadas a nenhum outro modelo semântico no modelo. A RLS definida no relatório não é aplicada a fontes remotas e a RLS definida em fontes remotas não é aplicada a outras fontes de dados. Além disso, você não pode definir a RLS em uma tabela carregada de uma fonte remota, e a RLS definida em tabelas locais não filtra nenhuma tabela carregada 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 clicando na seta para baixo no nome do campo e clicando no nome desse campo em vez de usar 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.

• Um sinalizador para desencorajar encadeamento pode ser definido em um modelo para impedir que uma cadeia seja criada ou estendida. Para saber mais, confira Gerenciar conexões DirectQuery a um modelo semântico publicado.

• A conexão com um modelo semântico do Power BI ou modelo do Analysis Services não é mostrada no Power Query.

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”
• O uso do Power BI Embedded com modelos semânticos que incluem uma conexão do DirectQuery com um modelo do Analysis Services não tem suporte no momento.
• Não há suporte para a publicação de um relatório na Web usando o recurso de publicação 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 que a conexão do DirectQuery tiver sido configurada, você 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.
• No momento, não há suporte para assumir o controle de um modelo semântico que está usando o recurso DirectQuery para outros modelos semânticos.
• Assim como acontece com qualquer fonte de dados do DirectQuery, hierarquias definidas em um modelo de Analysis Services ou em um modelo semântico do Power BI não serão mostradas ao se conectar ao modelo ou ao modelo semântico no modo DirectQuery usando Excel.

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

• 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

Qualquer modelo com uma conexão do 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 modelos semânticos do Power BI ou um modelo do Analysis Services usando identidades de convidado B2B, conforme descrito no diagrama a seguir. Confira Usuários convidados que podem editar e gerenciar conteúdo para localizar 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, a Ash opera com a Contoso e acessa dados fornecidos pela fabrikam. Com Power BI Desktop, a Ash cria uma conexão do DirectQuery com um modelo do Analysis Services que é hospedado no locatário da Fabrikam.

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

Se o relatório for publicado no serviço do Power BI da Contoso (etapa 2), o modelo semântico publicado no locatário da Contoso não conseguirá se autenticar 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 é hospedado no locatário da Fabrikam, o relatório também deve ser publicado no locatário 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 em nível de objeto) permite que os autores de modelo ocultem objetos que compõem o esquema de modelo (ou seja, tabelas, colunas, metadados etc.) de consumidores de modelo (por exemplo, um construtor de relatório 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. Ele não pode ser definido para um modelo composto criado no modelo de fonte.

Quando um modelo composto é criado em cima de um modelo semântico do Power BI protegido por OLS ou um modelo do Analysis Services via conexão DirectQuery, o esquema do modelo de origem é copiado para o modelo composto. O que é copiado depende do que o autor do modelo composto tem permissão para ver no modelo de fonte de acordo com as regras da OLS que se aplicam lá. Os dados não são copiados para o modelo composto – em vez disso, eles são sempre recuperados por meio do DirectQuery do modelo de fonte 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 pelas regras da OLS, os objetos que os consumidores do modelo composto veem são aqueles que o autor do modelo composto pode ver no modelo de fonte, em vez dos objetos aos quais eles mesmos podem ter acesso. Isso poderá resultar nas seguintes situações:

• 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. O Admin_user publicou um modelo semântico empresarial usando um modelo semântico do Power BI ou um Analysis Services que tem uma tabela Customer 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.
• As regras da OLS não podem ser definidas no próprio modelo composto.
• Um consumidor de um modelo composto nunca verá dados reais que ele não deveria ver, pois as regras relevantes da OLS no modelo de fonte as bloquearão quando o DirectQuery tentar 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 modelo do Analysis Services usando uma conexão do 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 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á:

• inserir um texto a ser adicionado ao nome de tabelas ou medidas conflitantes
• especificar se você deseja que o texto seja adicionado à tabela ou ao nome da medida como um prefixo ou sufixo
• aplicar a regra de eliminação de duplicação a tabelas, medidas ou ambos
• 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. No nosso exemplo, nenhuma tabela ou medida da fonte de marketing que tenha uma duplicata na fonte de vendas receberá uma alteração de nome.

Após fazer as conexões e configurar a regra de eliminação de duplicação, sua lista de campos mostrará tanto 'Cliente' quanto '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 se as regras de eliminação de duplicação especificadas não resolverem o conflito de nome, 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, você deve atualizar o ChangedProperties e a coleção PBI_RemovedChildren para que o objeto alterado inclua todas as propriedades modificadas ou removidas. Se você não executar essa atualização, as ferramentas de modelagem do Power BI poderão substituir todas as alterações na próxima vez que o esquema for sincronizado com o Lakehouse associado.

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

• Renomeação de tabela/coluna (ChangeProperty = name)
• 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 elementos 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ê estiver usando 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 fonte, 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