Diretrizes de modelos compostos no Power BI Desktop

Este artigo se destina a modeladores de dados que estão desenvolvendo modelos compostos no Power BI. Ele descreve os casos de uso de modelo composto e fornece diretrizes de design. Especificamente, as diretrizes podem ajudar você a determinar se um modelo composto é apropriado para sua solução. Se esse for o caso, este artigo também ajudará você a criar relatórios e modelos compostos ideais.

Casos de uso de modelo composto

Por definição, um modelo composto combina vários grupos de origem. Um grupo de origem pode representar dados importados ou uma conexão com uma fonte do DirectQuery. Uma fonte DirectQuery pode ser um banco de dados relacional ou outro modelo de tabela, que pode ser um modelo semântico do Power BI ou um modelo de tabela do Analysis Services. Quando um modelo tabular se conecta a outro, isso é conhecido como encadeamento. Para obter mais informações, confira Usando o DirectQuery para os modelos semânticos do Power BI e para o Analysis Services.

Conectar-se a modelos tabulares é especialmente relevante ao estender um modelo semântico empresarial (quando é um modelo semântico do Power BI ou um modelo do Analysis Services). Um modelo semântico empresarial é fundamental para o desenvolvimento e a operação de um data warehouse. Ele fornece uma camada de abstração sobre os dados no data warehouse para apresentar definições de negócios e terminologia. Normalmente, ele é usado como um link entre modelos de dados físicos e ferramentas de relatório, como o Power BI. Na maioria das organizações, é gerenciado por uma equipe central, e por isso é descrito como empresarial. Para obter mais informações, consulte o cenário de uso de BI empresarial.

Você pode considerar o desenvolvimento de um modelo composto nas situações a seguir.

• Seu modelo pode ser do DirectQuery e você quer melhorar o desempenho. Em um modelo composto, você pode melhorar o desempenho configurando o armazenamento apropriado para cada tabela. Você também pode adicionar agregações definidas pelo usuário. Ambas as otimizações serão descritas mais adiante neste artigo.
• Você deseja combinar um modelo DirectQuery com mais dados, que devem ser importados para o modelo. Você pode carregar dados importados de uma fonte de dados diferente ou de tabelas calculadas.
• Você deseja combinar duas ou mais fontes de dados DirectQuery em um único modelo. Essas fontes podem ser bancos de dados relacionais ou outros modelos tabulares.

Avaliar outras opções de design de modelo

Embora os modelos compostos do Power BI possam resolver desafios de design específicos, eles podem contribuir para um desempenho lento. Além disso, em algumas situações, podem ocorrer resultados de cálculo inesperados (descritos posteriormente neste artigo). Por esses motivos, avalie outras opções de design de modelo quando houver.

Sempre que possível, é melhor desenvolver um modelo no modo de importação. Esse modo fornece a maior flexibilidade de design e o melhor desempenho.

No entanto, os desafios relacionados a grandes volumes de dados ou relatórios de dados quase em tempo real nem sempre podem ser resolvidos pelos modelos de importação. Em qualquer um desses casos, você pode considerar o uso de um modelo DirectQuery, desde que seus dados sejam armazenados em uma única fonte de dados compatível com o modo DirectQuery. Para obter mais informações, confira Modelos do DirectQuery no Power BI Desktop.

Modo de armazenamento de tabela

Em um modelo composto, você pode definir o modo de armazenamento para cada tabela (exceto tabelas calculadas).

• DirectQuery: recomendamos que você defina esse modo para tabelas que representam grandes volumes de dados ou que precisam fornecer resultados quase em tempo real. Os dados nunca serão importados para essas tabelas. Normalmente, essas tabelas serão tabelas de tipo de fato, que são tabelas resumidas.
• Importação: recomendamos que você defina esse modo para tabelas que não são usadas para filtragem e agrupamento de tabelas do tipo fato no modo DirectQuery ou Híbrido. É também a única opção para tabelas baseadas em fontes sem suporte pelo modo DirectQuery. Tabelas calculadas sempre são tabelas de importação.
• Duplo: recomendamos que você defina esse modo para tabelas de tipo de dimensão quando houver a possibilidade de serem consultadas junto com tabelas de tipo de fato DirectQuery da mesma origem.
• Híbrido: recomendamos que você defina esse modo adicionando partições de Importação, bem como uma partição DirectQuery a uma tabela fato, quando quiser incluir as alterações de dados mais recentes em tempo real ou quando quiser fornecer acesso rápido aos dados mais usados por meio de partições de importação, deixando a maior parte dos dados usados com menos frequência no data warehouse.

Há vários cenários possíveis em que o Power BI consulta um modelo composto.

• Consulta somente tabelas duplas ou de importação: o Power BI recupera todos os dados do cache de modelo. Isso fornecerá o desempenho mais rápido possível. Esse cenário é comum para tabelas de tipo de dimensão consultadas por filtros ou visuais de segmentação.
• Consulta tabelas duplas ou tabelas DirectQuery da mesma origem: o Power BI recupera todos os dados enviando uma ou mais consultas nativas para a fonte DirectQuery. Isso fornecerá um bom desempenho, especialmente quando existirem índices apropriados nas tabelas de origem. Esse cenário é comum para consultas que relacionam tabelas de tipo de dimensão duplas e tabelas de tipo de fato DirectQuery. Essas consultas são internas ao grupo de origem e, portanto, todas as relações um-para-um ou um-para-muitos são avaliadas como relações regulares.
• Consulta tabelas duplas ou tabelas híbridas da mesma origem: esse cenário é uma combinação dos dois cenários anteriores. O Power BI recupera dados do cache do modelo quando eles estão disponíveis em partições de importação; caso contrário, envia uma ou mais consultas nativas para a origem do DirectQuery. Ele fornecerá o desempenho mais rápido possível porque apenas uma porção dos dados é consultada no data warehouse, especialmente quando os índices apropriados existem nas tabelas de origem. Quanto às tabelas duplas do tipo dimensão e as tabelas DirectQuery do tipo fato, essas consultas são dentro do grupo de origem e, portanto, todas as relações de um para um ou um para muitos são avaliadas como relações regulares.
• Todas as outras consultas: essas consultas envolvem relações entre grupos de origem. Isso ocorre porque uma tabela de importação está relacionada a uma tabela DirectQuery, ou uma tabela dupla está relacionada a uma tabela DirectQuery de uma fonte diferente; nesse caso, ela se comporta como uma tabela de importação. Todas as relações são avaliadas como relações limitadas. Isso também significa que os agrupamentos aplicados a tabelas que não sejam DirectQuery devem ser enviados para a origem do DirectQuery como subconsultas materializadas (tabelas virtuais). Nesse caso, a consulta nativa pode ser ineficiente, especialmente para grandes conjuntos de agrupamentos.

Em resumo, recomendamos que você:

• Considere com atenção se o modelo composto é a solução certa – embora ele permita a integração no nível de modelo de diferentes fontes de dados, também apresenta complexidades de design com possíveis consequências (descritas posteriormente neste artigo).
• Defina o modo de armazenamento para DirectQuery quando a tabela for de um tipo de fato que armazena grandes volumes de dados ou quando precisar fornecer resultados quase em tempo real
• Considere usar o modo híbrido definindo uma política de atualização incremental e dados em tempo real, ou particionando a tabela fato usando TOM, TMSL ou uma ferramenta de terceiros. Para obter mais informações, consulte Atualização incremental e dados em tempo real para modelos semânticos e o cenário de uso Gerenciamento avançado de modelo de dados.
• Defina o modo de armazenamento como Duplo quando uma tabela for do tipo dimensão e ela será consultada junto com tabelas de tipo fato DirectQuery ou híbridas no mesmo grupo de origem.
• Defina as frequências de atualização apropriadas para manter o cache de modelo de tabelas duplas e híbridas (e quaisquer tabelas calculadas dependentes) sincronizado com os bancos de dados da fonte
• Busque garantir a integridade dos dados entre os grupos de origem (incluindo o cache de modelo), pois relações limitadas eliminarão as linhas nos resultados da consulta quando os valores das colunas relacionadas não corresponderem.
• Sempre que possível, otimize as fontes de dados DirectQuery com índices apropriados para ter junções, filtragem e agrupamentos eficientes.

Agregações definidas pelo usuário

Você pode adicionar agregações definidas pelo usuário às tabelas DirectQuery. Sua finalidade é melhorar o desempenho de consultas de granulação mais alta.

Quando agregações são armazenadas em cache no modelo, elas comportam-se como tabelas de importação (embora não possam ser usadas como uma tabela de modelo). Adicionar agregações de importação a um modelo DirectQuery resultará em um modelo composto.

Recomendamos que uma agregação siga uma regra básica: sua contagem de linhas deve ser pelo menos 10 vezes menor que a tabela subjacente. Por exemplo, se a tabela subjacente armazenar 1 bilhão de linhas, a tabela de agregação não deverá exceder 100 milhões linhas. Essa regra garante um ganho de desempenho adequado em relação ao custo de criação e manutenção da agregação.

Relações entre grupos de origem

Quando uma relação de modelo abrange grupos de origem, ela é conhecida como uma relação entre grupos de origem. Relações entre grupos de origem também são relações limitadas porque não há um lado "um" garantido. Para obter mais informações, confira Avaliação da relação.

Ao definir relações entre grupos de origem, considere as recomendações a seguir.

• Use colunas de relação de baixa cardinalidade: para o melhor desempenho, recomendamos que as colunas de relação sejam de baixa cardinalidade, o que significa que devem armazenar menos de 50.000 valores exclusivos. Essa recomendação é especialmente verdadeira ao combinar modelos tabulares e para colunas que não são de texto.
• Evite usar colunas de relação de texto grandes: se você precisar usar colunas de texto em uma relação, calcule o comprimento de texto esperado para o filtro multiplicando a cardinalidade pelo comprimento médio da coluna de texto. O comprimento do texto possível não deve exceder 1.000.000 caracteres.
• Aumente a granularidade da relação: se possível, crie relações com um nível mais alto de granularidade. Por exemplo, em vez de relacionar uma tabela de data em sua chave de data, use a chave de mês. Essa abordagem de design exige que a tabela relacionada inclua uma coluna de chave de mês, e os relatórios não poderão mostrar fatos diários.
• Busque alcançar um design de relação simples: crie apenas uma relação entre grupos de origem quando necessário e tente limitar o número de tabelas no caminho da relação. Essa abordagem de design ajudará a aprimorar o desempenho e a evitar caminhos de relacionamento ambíguos.

Cenário 1 de relação entre grupos de origem

Considere um cenário de um design de relação complexo e como ele poderia produzir resultados diferentes, ainda que válidos.

Nesse cenário, a tabela Região no grupo de origem A tem uma relação com a tabela Data e a tabela Vendas no grupo de origem B. A relação entre a tabela Região e a tabela Data está ativa, enquanto a relação entre a tabela Região e a tabela Vendas está inativa. Além disso, há uma relação ativa entre a tabela Região e a tabela Vendas, ambas no grupo de origem B. A tabela Vendas inclui uma medida chamada TotalSales e a tabela Região inclui duas medidas denominadas RegionalSales e RegionalSalesDirect.

Aqui estão as definições de medida.

TotalSales = SUM(Sales[Sales])
RegionalSales = CALCULATE([TotalSales], USERELATIONSHIP(Region[RegionID], Sales[RegionID]))
RegionalSalesDirect = CALCULATE(SUM(Sales[Sales]), USERELATIONSHIP(Region[RegionID], Sales[RegionID]))

Observe como a medida RegionalSales se refere à medida TotalSales, enquanto a medida RegionalSalesDirect não. Em vez disso, a medida RegionalSalesDirect usa a expressão SUM(Sales[Sales]), que é a expressão da medida TotalSales.

A diferença no resultado é sutil. Quando o Power BI avalia a medida RegionalSales, ele aplica o filtro da tabela Região à tabela Vendas e à tabela Data. Portanto, o filtro também se propaga da tabela Data para a tabela Vendas. Por outro lado, quando o Power BI avalia a medida RegionalSalesDirect, ele propaga apenas o filtro da tabela Região para a tabela Vendas. Os resultados retornados pela medida RegionalSales e pela medida RegionalSalesDirect podem ser diferentes, embora as expressões sejam semanticamente equivalentes.

Cenário 2 de relação entre grupos de origem

Considere um cenário em que uma relação entre grupos de origem tem colunas de relação de alta cardinalidade.

Nesse cenário, a tabela Data está relacionada à tabela Vendas nas colunas DateKey. O tipo de dados das colunas DateKey é inteiro, armazenando números inteiros que usam o formato aammdd. As tabelas pertencem a diferentes grupos de origem. Além disso, é uma relação de alta cardinalidade porque a data mais antiga na tabela Data é 1º de janeiro de 1900 e a data mais recente é 31 de dezembro de 2100; portanto, há um total de 73.414 linhas na tabela (uma linha para cada data no intervalo de tempo de 1900 a 2100).

Há dois motivos de preocupação.

Primeiro, quando você usar as colunas da tabela Data como filtros, a propagação do filtro filtrará a coluna DateKey da tabela Vendas para avaliar as medidas. Ao filtrar por um ano, como 2022, a consulta DAX incluirá uma expressão de filtro como Sales[DateKey] IN { 20220101, 20220102, …20221231 }. O tamanho do texto da consulta poderá aumentar e se tornar extremamente grande quando o número de valores na expressão de filtro for grande ou quando os valores de filtro forem cadeias de caracteres longas. É caro para o Power BI gerar a consulta longa e para a fonte de dados executar a consulta.

Em segundo lugar, quando você usa colunas da tabela Data – como Ano, Trimestre ou Mês – como colunas de agrupamento, isso resulta em filtros que incluem todas as combinações exclusivas de ano, trimestre ou mês e os valores de coluna DateKey. O tamanho da cadeia de caracteres da consulta, que contém filtros nas colunas de agrupamento e na coluna de relação, pode se tornar extremamente grande. Isso é especialmente verdadeiro quando o número de colunas de agrupamento e/ou a cardinalidade da coluna de junção (a coluna DateKey) é grande.

Para resolver problemas de desempenho, você pode:

• Adicionar a tabela Data à fonte de dados, resultando em um só modelo de grupo de origem (ou seja, ele deixa de ser um modelo composto).
• Aumentar a granularidade da relação. Por exemplo, você pode adicionar uma coluna MonthKey a ambas as tabelas e criar a relação nessas colunas. No entanto, aumentando a granularidade da relação, você perde a capacidade de relatar sobre a atividade diária de vendas (a menos que use a coluna DateKey da tabela Vendas).

Cenário 3 de relação entre grupos de origem

Considere um cenário em que não há valores correspondentes entre tabelas em uma relação entre grupos de origem.

Nesse cenário, a tabela Data no grupo de origem B tem uma relação com a tabela Vendas nesse grupo de origem e também com a tabela Destino no grupo de origem A. Todas as relações são de um para muitos da tabela Data que relaciona as colunas Ano. A tabela Vendas inclui uma coluna SalesAmount que armazena valores de vendas, enquanto a tabela Destino inclui uma coluna TargetAmount que armazena os valores de destino.

A tabela Data armazena os anos de 2021 e 2022. A tabela Vendas armazena valores de vendas para os anos de 2021 (100) e 2022 (200), enquanto a tabela Destino armazena valores alvo para 2021 (100), 2022 (200) e 2023 (300)— um ano futuro.

Quando um visual de tabela do Power BI consulta o modelo composto agrupando na coluna Ano da tabela Data e somando as colunas SalesAmount e TargetAmount, ele não mostrará um valor de destino para 2023. Isso ocorre porque a relação entre grupos de origem é uma relação limitada e, portanto, usa semântica INNER JOIN, que elimina linhas em que não há nenhum valor correspondente em ambos os lados. No entanto, ele produzirá um valor de destino total correto (600), porque um filtro de tabela Data não se aplica à sua avaliação.

Se a relação entre a tabela Data e a tabela Destino for uma relação de grupo de origem interna (supondo que a tabela Destino pertencia ao grupo de origem B), o visual incluirá um ano (Em branco) para mostrar o valor de destino de 2023 (e qualquer outro ano sem correspondência).

Para obter mais informações sobre relações limitadas, consulte Avaliação de relação.

Cálculos

Considere limitações específicas ao adicionar colunas calculadas e grupos de cálculo a um modelo composto.

Colunas calculadas

As colunas calculadas adicionadas a uma tabela DirectQuery que obtém seus dados de um banco de dados relacional, como o Microsoft SQL Server, são limitadas a expressões que operam em uma linha de cada vez. Essas expressões não podem usar funções de iterador DAX, como SUMX, nem filtrar funções de modificação de contexto, como CALCULATE.

Uma expressão de coluna calculada em uma tabela do DirectQuery remota é limitada apenas à avaliação de linha interna. No entanto, você pode criar essa expressão, mas isso resultará em um erro quando ela for usada em um visual. Por exemplo, se você adicionar uma coluna calculada a uma tabela remota do DirectQuery chamada DimProduct usando a expressão [Product Sales] / SUM (DimProduct[ProductSales]), poderá salvar com êxito a expressão no modelo. No entanto, isso resultará em um erro quando for usado em um visual porque viola a restrição de avaliação de linha interna.

Por outro lado, colunas calculadas adicionadas a uma tabela do DirectQuery remota que é um modelo tabular, que é um modelo semântico do Power BI ou um modelo do Analysis Services, são mais flexíveis. Nesse caso, todas as funções DAX são permitidas porque a expressão será avaliada dentro do modelo tabular de origem.

Muitas expressões exigem que o Power BI materialize a coluna calculada antes de usá-la como um grupo ou filtro ou de agregá-la. Quando uma coluna calculada é materializada sobre uma tabela grande, ela pode ser cara em termos de CPU e memória, dependendo da cardinalidade das colunas das quais a coluna calculada depende. Nesse caso, recomendamos que você adicione essas colunas calculadas ao modelo de origem.

Grupos de cálculo

Se houver grupos de cálculo em um grupo de origem que se conecta a um modelo semântico do Power BI ou a um modelo do Analysis Services, o Power BI poderá retornar resultados inesperados. Para obter mais informações, consulte Grupos de cálculo, avaliação de consulta e medida.

Design de modelo

Você sempre deve otimizar um modelo do Power BI adotando um design de esquema em estrela.

Crie tabelas de dimensões separadas das tabelas de fatos para que o Power BI possa interpretar as junções corretamente e produzir planos de consulta eficientes. Embora essas diretrizes sejam verdadeiras para qualquer modelo do Power BI, isso é especialmente verdadeiro para modelos que você reconhece que se tornarão um grupo de origem de um modelo composto. Isso permitirá uma integração mais simples e eficiente de outras tabelas em modelos downstream.

Sempre que possível, evite ter tabelas de dimensão em um grupo de origem relacionadas a uma tabela de fatos em um grupo de origem diferente. Isso ocorre porque é melhor ter relações dentro dos grupos de origem do que relações entre grupos de origem, especialmente para colunas de relação de alta cardinalidade. Conforme descrito anteriormente, as relações entre grupos de origem dependem de ter valores correspondentes nas colunas de relação, caso contrário, resultados inesperados podem ser mostrados em visuais de relatório.

Segurança em nível de linha

Se o modelo incluir agregações definidas pelo usuário, colunas calculadas em tabelas de importação ou tabelas calculadas, verifique se a RLS (segurança em nível de linha) está configurada corretamente e testada.

Se o modelo composto se conectar a outros modelos tabulares, as regras de RLS serão aplicadas somente ao grupo de origem (modelo local) em que são definidas. Elas não serão aplicadas a outros grupos de origem (modelos remotos). Além disso, você não pode definir regras de RLS em uma tabela de outro grupo de origem nem pode definir regras de RLS em uma tabela local que tenha uma relação com outro grupo de origem.

Design de relatório

Em algumas situações, você pode aprimorar o desempenho de um modelo composto projetando um layout de relatório otimizado.

Visuais de grupo de origem único

Sempre que possível, crie visuais que usam campos de um só grupo de origem. Isso ocorre porque as consultas geradas por visuais terão um desempenho melhor quando o resultado for recuperado de um só grupo de origem. Considere criar dois visuais posicionados lado a lado que recuperam dados de dois grupos de origem diferentes.

Usar segmentações de sincronização

Em algumas situações, você pode configurar segmentações de sincronização para evitar a criação de uma relação entre grupos de origem em seu modelo. Isso pode permitir que você combine grupos de origem visualmente que podem ter um desempenho melhor.

Considere um cenário em que o modelo tem dois grupos de origem. Cada grupo de origem tem uma tabela de dimensões de produto usada para filtrar vendas de revendedor e da internet.

Nesse cenário, o grupo de origem A contém a tabela Produto relacionada à tabela ResellerSales. O grupo de origem B contém a tabela Product2 relacionada à tabela InternetSales. Não há relações entre os grupos de origem.

No relatório, você adiciona uma segmentação de dados que filtra a página usando a coluna Cor da tabela Produto. Por padrão, a segmentação filtra a tabela ResellerSales, mas não a tabela InternetSales. Em seguida, adicione uma segmentação oculta usando a coluna Cor da tabela Product2. Ao definir um nome de grupo idêntico (encontrado nas Opções avançadas das segmentações de sincronização), os filtros aplicados à segmentação visível são propagados automaticamente para a segmentação oculta.

Para obter mais informações, consulte Sincronizar segmentações separadas.

Outras diretrizes

Aqui estão algumas outras diretrizes para ajudar você a projetar e manter modelos compostos.

• Desempenho e escala: se os relatórios estavam conectados dinamicamente a um modelo semântico do Power BI ou ao modelo do Analysis Services, o serviço do Power BI poderia reutilizar caches visuais em relatórios. Após você converter a conexão dinâmica para criar um modelo DirectQuery local, os relatórios não se beneficiarão mais desses caches. Como resultado, você pode ter um desempenho mais lento ou até mesmo falhas de atualização. Além disso, a carga de trabalho para o serviço do Power BI aumentará, o que pode exigir que você aumente sua capacidade ou distribua a carga de trabalho entre outras capacidades. Para obter mais informações sobre atualização e cache de dados, consulte Atualização de dados no Power BI.
• Renomear: não recomendamos renomear modelos semânticos usados por modelos compostos ou renomear seus workspaces. Isso ocorre porque os modelos compostos se conectam aos modelos semânticos do Power BI usando os nomes do workspace e do modelo semântico (e não seus identificadores exclusivos internos). Renomear um modelo semântico ou workspace pode interromper as conexões usadas pelo modelo composto.
• Governança: não recomendamos que sua única versão do modelo de verdade seja um modelo composto. Isso ocorre porque ele dependeria de outras fontes de dados ou modelos, que, se atualizados, poderiam resultar na quebra do modelo composto. Em vez disso, recomendamos que você publique um modelo semântico empresarial como a única versão da verdade. Considere esse modelo como uma base confiável. Outros modeladores de dados podem criar modelos compostos que estendem o modelo de base para criar modelos especializados.
• Linhagem de dados: use a linhagem de dados e os recursos de análise de impacto do modelo semântico antes de publicar alterações no modelo composto. Esses recursos estão disponíveis no serviço do Power BI e podem ajudar você a entender como os modelos semânticos são relacionados e usados. É importante entender que você não pode executar a análise de impacto em modelos semânticos externos mostrados na exibição de linhagem, mas que estão, na verdade, localizados em outro workspace. Para executar a análise de impacto em um modelo semântico externo, você precisa navegar até o workspace de origem.
• Atualizações de esquema: você deve atualizar seu modelo composto no Power BI Desktop quando forem feitas alterações de esquema em fontes de dados upstream. Em seguida, você precisará republicar o modelo no serviço do Power BI. Certifique-se de testar completamente cálculos e relatórios dependentes.

Conteúdo relacionado

Para obter mais informações relacionadas a este artigo, confira os recursos a seguir.

• Usar modelos compostos no Power BI Desktop
• Modelar relações no Power BI Desktop
• Modelos de DirectQuery no Power BI Desktop
• Usar o DirectQuery no Power BI Desktop
• Usar modelos semânticos do DirectQuery para Power BI e o Analysis Services
• Modo de armazenamento no Power BI Desktop
• Agregações definidas pelo usuário
• Perguntas? Experimente perguntar à Comunidade do Power BI
• Sugestões? Contribuir com ideias para aprimorar o Power BI