Entenda o esquema em estrela e a importância para o Power BI

Este artigo se destina a modeladores de dados do Power BI Desktop. Ele descreve o design do esquema em estrela e sua relevância para o desenvolvimento de modelos semânticos do Power BI otimizados para desempenho e usabilidade.

Importante

Os modelos semânticos do Power BI dependem do Power Query para importar ou se conectar a dados. Isso significa que você deve usar o Power Query para transformar e preparar os dados de origem, o que pode ser desafiador quando você tem grandes volumes de dados ou precisa implementar conceitos avançados, como dimensões de alteração lenta (descritas posteriormente neste artigo).

Quando você se deparar com esses desafios, recomendamos que você primeiro desenvolva um data warehouse e processos de ETL (Extração, Transformação e Carregamento) para carregar periodicamente o data warehouse. Seu modelo semântico pode então se conectar ao data warehouse. Para obter mais informações, consulte Modelagem dimensional no Microsoft Fabric Warehouse.

Dica

Este artigo não pretende oferecer uma discussão completa sobre o design do esquema em estrela. Para obter mais informações, consulte diretamente o conteúdo publicado amplamente adotado, como The Data Warehouse Toolkit: The Definitive Guide to Dimensional Modeling (3ª edição, 2013) de Ralph Kimball e outros.

Visão geral do esquema em estrela

O esquema em estrela é uma abordagem de modelagem madura amplamente adotada por data warehouses relacionais. Ele requer que os modeladores classifiquem suas tabelas de modelo como dimensão ou fato.

• Tabelas de dimensões descrevem as entidades de negócios – os itens que você modela. As entidades podem incluir produtos, pessoas, locais e conceitos, incluindo o próprio tempo. A tabela mais consistente que você encontrará em um esquema em estrela é uma tabela de dimensão de data. Uma tabela de dimensões contém uma coluna (ou colunas) de chave que atua como um identificador exclusivo e outras colunas. Outras colunas dão suporte à filtragem e ao agrupamento de seus dados.
• As tabelas de fatos armazenam observações ou eventos e podem ser ordens de venda, saldos de estoque, taxas de câmbio, temperaturas e muito mais. Uma tabela fato contém colunas chave de dimensão relacionadas a tabelas dimensão e colunas de medida numérica. As colunas de chave de dimensão determinam a dimensionalidade de uma tabela de fatos, enquanto os valores de chave de dimensão determinam a granularidade de uma tabela de fatos. Por exemplo, considere uma tabela de fatos projetada para armazenar destinos de venda que tenha duas colunas Date de chave de dimensão e ProductKey. É fácil entender que a tabela tem duas dimensões. No entanto, a granularidade não pode ser determinada sem considerar os valores de chave de dimensão. Neste exemplo, considere que os valores armazenados na Date coluna são o primeiro dia de cada mês. Nesse caso, a granularidade está no nível do mês-produto.

Em geral, as tabelas de dimensões contêm um número relativamente pequeno de linhas. As tabelas de fatos, por outro lado, podem conter um grande número de linhas e continuar a crescer ao longo do tempo.

Normalização versus desnormalização

Para entender alguns conceitos de esquema em estrela descritos neste artigo, é importante conhecer dois termos: normalização e desnormalização.

Normalização é o termo usado para descrever os dados armazenados de uma forma que reduz dados repetidos. Considere uma tabela de produtos que tenha uma coluna de chave-valor exclusiva, como a chave do produto, e outras colunas que descrevam as características do produto, como nome, categoria, cor e tamanho do produto. Uma tabela de vendas é considerada normalizada quando armazena apenas chaves, como a chave do produto. Na imagem a seguir, observe que somente a ProductKey coluna registra o produto.

Se, no entanto, a tabela de vendas armazenar detalhes do produto além da chave, ela será considerada desnormalizada. Na imagem a seguir, observe que as ProductKey colunas e outras colunas relacionadas ao produto registram o produto.

Quando você obtém dados de um arquivo de exportação ou extração de dados, é provável que ele represente um conjunto de dados desnormalizado. Nesse caso, use o Power Query para transformar e moldar os dados de origem em várias tabelas normalizadas.

Conforme descrito neste artigo, você deve se esforçar para desenvolver modelos semânticos otimizados do Power BI com tabelas que representam dados de fato e dimensão normalizados. No entanto, há uma exceção em que uma dimensão de floco de neve pode ser desnormalizada para produzir uma única tabela de modelo.

Relevância do esquema em estrela para modelos semânticos do Power BI

O design de esquema em estrela e muitos conceitos relacionados apresentados neste artigo são altamente relevantes para o desenvolvimento de modelos do Power BI otimizados para desempenho e usabilidade.

Considere que cada visual de relatório do Power BI gera uma consulta que é enviada ao modelo semântico do Power BI. Geralmente, as consultas filtram, agrupam e resumem os dados do modelo. Assim, um modelo bem projetado fornece tabelas para filtragem e agrupamento e tabelas para resumo. Esse design se ajusta bem aos princípios de esquema em estrela:

• As tabelas de dimensões permitem a filtragem e o agrupamento.
• As tabelas de fatos permitem o resumo.

Não há nenhuma propriedade de tabela que os modeladores definam para definir o tipo de tabela como dimensão ou fato. Na verdade, é determinado pelas relações do modelo. Uma relação de modelo estabelece um caminho de propagação de filtro entre duas tabelas e é a propriedade de cardinalidade da relação que determina o tipo de tabela. Uma cardinalidade em uma relação comum é uma relação de um para muitos ou seu inverso, de muitos para um. O lado "um" é sempre uma tabela de dimensões, enquanto o lado "muitos" é sempre uma tabela de fatos.

Um design de modelo bem estruturado inclui tabelas que são tabelas de dimensões ou tabelas de fatos. Evite misturar os dois tipos em uma única tabela. Também recomendamos que você se esforce para fornecer o número certo de tabelas com os relacionamentos certos. Também é importante que as tabelas de fatos sempre carreguem dados em uma granularidade consistente.

Por fim, é importante entender que o design ideal de modelos é parte ciência e parte arte. Às vezes, você pode romper com uma boa orientação quando fizer sentido.

Há muitos conceitos relacionados ao design de esquema em estrela que podem ser aplicados a um modelo semântico do Power BI. Esses conceitos incluem:

• Medidas
• Chaves alternativas
• Dimensões de floco de neve
• Dimensões com função múltipla
• Dimensões de alteração lenta
• Dimensões de lixo eletrônico
• Dimensões de degeneração
• Tabelas de fatos sem fatos

Medidas

No design de esquema em estrela uma medida é uma coluna de tabela de fatos que armazena valores a serem resumidos. Em um modelo semântico do Power BI, uma medida tem uma definição diferente, mas semelhante. Um modelo dá suporte a medidas explícitas e implícitas.

• Medidas explícitas são criadas expressamente e são baseadas em uma fórmula escrita em DAX (Data Analysis Expressions) que obtém resumo. As expressões de medida geralmente usam funções de agregação DAX como SUM, MIN, MAX, AVERAGEe outras para produzir um resultado de valor escalar no momento da consulta (os valores nunca são armazenados no modelo). A expressão de medida pode variar de agregações de coluna simples a fórmulas mais sofisticadas que substituem o contexto de filtro e/ou a propagação de relação. Para obter mais informações, leia sobre Noções básicas do DAX no Power BI Desktop.
• Medidas implícitas são colunas que podem ser resumidas por um visual de relatório ou P e R. Eles oferecem uma conveniência para você como desenvolvedor de modelos, pois em muitos casos você não precisa criar medidas (explícitas). Por exemplo, a coluna de vendas Sales Amount do revendedor Adventure Works pode ser resumida de várias maneiras (soma, contagem, média, mediana, mínimo, máximo e outras), sem a necessidade de criar uma medida para cada tipo de agregação possível.

No painel Dados, as medidas explícitas são representadas pelo ícone da calculadora, enquanto as medidas implícitas são representadas pelo símbolo sigma (∑).

No entanto, há três razões convincentes pelas quais você pode criar medidas, mesmo para resumos simples em nível de coluna:

• Quando você sabe que os autores do relatório consultarão o modelo semântico usando MDX, o modelo deve incluir medidas explícitas. Isso ocorre porque o MDX não pode obter o resumo de valores de coluna. Notavelmente, o MDX é usado ao executar Analisar no Excel porque as Tabelas Dinâmicas emitem consultas MDX.

• Quando você sabe que os autores de relatório criarão relatórios paginados do Power BI usando o designer de consulta MDX, o modelo semântico deve incluir medidas explícitas. Somente o designer de consulta MDX dá suporte a agregações de servidor. Portanto, se os autores de relatório precisarem ter medidas avaliadas pelo Power BI (em vez de pelo mecanismo de relatório paginado), eles deverão usar o designer de consulta MDX.

• Quando você deseja controlar como os autores do relatório resumem as colunas de maneiras específicas. Por exemplo, a coluna de vendas Unit Price do revendedor (que representa uma taxa por unidade) pode ser resumida, mas somente usando funções de agregação específicas. Ele nunca deve ser somado, mas é apropriado resumir usando outras funções de agregação como min, max ou average. Nesse caso, o modelador pode ocultar a Unit Price coluna e criar medidas para todas as funções de agregação apropriadas.

  Essa abordagem de design funciona bem para relatórios criados no serviço do Power BI e para P e R. No entanto, as conexões dinâmicas do Power BI Desktop permitem que os autores de relatórios mostrem campos ocultos no painel Dados, o que pode resultar em contornar essa abordagem de design.

Chaves alternativas

Uma chave alternativa é um identificador exclusivo que você adiciona a uma tabela para dar suporte à modelagem de esquema em estrela. Por definição, não é definida nem armazenada nos dados de origem. Normalmente, as chaves substitutas são adicionadas às tabelas de dimensões relacionais do data warehouse para fornecer um identificador exclusivo para cada linha da tabela de dimensões.

As relações do modelo semântico do Power BI são baseadas em uma única coluna exclusiva em uma tabela, que propaga filtros para uma única coluna em uma tabela diferente. Quando uma tabela de dimensões em seu modelo semântico não inclui uma única coluna exclusiva, você deve adicionar um identificador exclusivo para se tornar o lado "um" de uma relação. No Power BI Desktop, você pode atender a esse requisito adicionando uma coluna de índice do Power Query.

Você deve mesclar essa consulta com a consulta do lado "muitos" para poder adicionar a coluna de índice a ela também. Ao carregar essas consultas no modelo semântico, você pode criar uma relação um-para-muitos entre as tabelas de modelo.

Dimensões de floco de neve

Uma dimensão de floco de neve é um conjunto de tabelas normalizadas para uma única entidade de negócios. Por exemplo, a Adventure Works classifica produtos por categoria e subcategoria. Os produtos são atribuídos a subcategorias e as subcategorias, por sua vez, são atribuídas a categorias. No data warehouse relacional da Adventure Works, a dimensão do produto é normalizada e armazenada em três tabelas relacionadas: DimProductCategory, DimProductSubcategorye DimProduct.

Se você usar sua imaginação, poderá modelar as tabelas normalizadas posicionadas para cima da tabela de fatos, formando um design de floco de neve.

No Power BI Desktop, você pode optar por imitar um design de dimensão de floco de neve (talvez porque seus dados de origem o façam) ou combinar as tabelas de origem para formar uma única tabela de modelo desnormalizada. Em geral, os benefícios de uma tabela de modelo única superam os benefícios de várias tabelas de modelo. A decisão mais ideal pode depender dos volumes de dados e dos requisitos de usabilidade para o modelo.

Quando você opta por imitar um design de dimensão floco de neve:

• O Power BI carrega mais tabelas, o que é menos eficiente das perspectivas de armazenamento e desempenho. Essas tabelas devem incluir colunas para dar suporte a relações de modelo e isso pode resultar em um tamanho de modelo maior.
• Cadeias de propagação de filtro de relacionamento mais longas precisam ser percorridas, o que pode ser menos eficiente do que os filtros aplicados a uma única tabela.
• O painel Dados apresenta mais tabelas de modelo para os autores de relatórios, o que pode resultar em uma experiência menos intuitiva, especialmente quando as tabelas de dimensões do floco de neve contêm apenas uma ou duas colunas.
• Não é possível criar uma hierarquia que inclua colunas de mais de uma tabela.

Quando você opta por integrar em uma única tabela de modelo, também pode definir uma hierarquia que abrange as granularidades mais alta e mais baixa da dimensão. Possivelmente, o armazenamento de dados desnormalizados redundantes pode resultar em maior tamanho de armazenamento de modelo, especialmente para tabelas de dimensões grandes.

Dimensões de alteração lenta

Uma dimensão de mudança lenta (ou SCD) é aquela que gerencia adequadamente a alteração de membros da dimensão ao longo do tempo. Ela se aplica quando os valores da entidade comercial mudam lentamente ao longo do tempo de maneira não planejada. Um bom exemplo de um SCD é uma dimensão de cliente, pois suas colunas de detalhes de contato, como endereço de email e número de telefone, mudam com pouca frequência. Por outro lado, algumas dimensões são consideradas como mudando rapidamente quando um atributo de dimensão muda com frequência, como o preço de mercado de uma ação. A abordagem de design comum nesses casos é armazenar valores de atributos de alteração rápida em uma medida de tabela de fatos.

A teoria do design do esquema em estrela refere-se a dois tipos comuns de SCD: Tipo 1 e Tipo 2. Uma tabela de dimensões pode ser Tipo 1 ou Tipo 2 ou dar suporte a ambos os tipos simultaneamente para colunas diferentes.

SCD do Tipo 1

Uma SCD do Tipo 1 sempre reflete os valores mais recentes e, quando são detectadas alterações nos dados de origem, os dados da tabela de dimensões são substituídos. Essa abordagem de design é comum para colunas que armazenam valores suplementares, como o endereço de email ou o número de telefone de um cliente. Quando um endereço de email ou um número de telefone do cliente muda, a tabela de dimensões atualiza a linha de cliente com os novos valores. É como se o cliente sempre tivesse essas informações de contato.

Uma atualização não incremental de uma tabela de dimensões de modelo do Power BI obtém o resultado de um SCD Tipo 1. Ela atualiza os dados da tabela para garantir que os valores mais recentes sejam carregados.

SCD do Tipo 2

Uma SCD do Tipo 2 é compatível com o controle de versão dos membros da dimensão. Se o sistema de origem não armazenar versões, geralmente é o processo de carregamento do data warehouse que detecta as alterações e gerencia adequadamente as alterações em uma tabela de dimensões. Nesse caso, a tabela de dimensões deve usar uma chave substituta para fornecer uma referência exclusiva a uma versão do membro da dimensão. Ele também inclui colunas que definem a validade do intervalo de datas da versão (por exemplo, StartDate e EndDate) e, possivelmente, uma coluna de sinalizador (por exemplo, IsCurrent) para filtrar facilmente por membros da dimensão atual.

Por exemplo, a Adventure Works atribui cada vendedor a uma região de vendas. Quando um vendedor realoca a região, uma nova versão do vendedor deve ser criada para garantir que os fatos históricos permaneçam associados à região anterior. Para dar suporte à análise histórica precisa das vendas por vendedor, a tabela de dimensões deve armazenar versões de vendedores e suas regiões associadas. A tabela também deve incluir valores de data de início e de término para definir a validade do tempo. As versões atuais podem definir uma data de término vazia (ou 31/12/9999), o que indica que a linha é a versão atual. A tabela também deve ter uma chave substituta porque a chave comercial (neste caso, ID do funcionário) não será exclusiva.

É importante entender que, quando os dados de origem não armazenam versões, você deve usar um sistema intermediário (como um data warehouse) para detectar e armazenar as alterações. O processo de carregamento de tabela deve preservar os dados existentes e detectar alterações. Quando uma alteração é detectada, o processo de carregamento de tabela deve expirar a versão atual. Ele registra essas alterações atualizando o valor EndDate e inserindo uma nova versão com o valor StartDate começando do valor EndDate anterior. Além disso, os fatos relacionados devem usar uma pesquisa baseada em tempo para recuperar o valor da chave de dimensão relevante para a data do fato. Um modelo semântico do Power BI usa o Power Query e, portanto, não pode produzir esse resultado. No entanto, ele pode carregar dados de uma tabela de dimensão SCD Tipo 2 pré-carregada.

Dica

Para saber como implementar uma tabela de dimensões SCD Tipo 2 em um warehouse do Fabric, consulte Gerenciar alterações históricas.

O modelo semântico do Power BI deve dar suporte à consulta de dados históricos para um membro, independentemente da alteração, e para uma versão do membro, que representa um estado específico do membro no tempo. No contexto da Adventure Works, esse design permite consultar o vendedor, independentemente da região de vendas atribuída ou uma versão específica do vendedor.

Para atender a esse requisito, a tabela de dimensões do modelo semântico do Power BI deve incluir uma coluna para filtrar o vendedor e uma coluna diferente para filtrar uma versão específica do vendedor. É importante que a coluna version forneça uma descrição não ambígua, como David Campbell (12/15/2008-06/26/2019) ou David Campbell (06/27/2019-Current). Também é importante treinar autores e consumidores de relatórios sobre os fundamentos de SCD Tipo 2 e como obter designs de relatórios apropriados aplicando os filtros corretos.

É uma boa prática de design incluir uma hierarquia que permita que os visuais façam uma busca detalhada até o nível da versão.

Dimensões com função múltipla

Uma dimensão com função múltipla é uma dimensão que pode filtrar fatos relacionados de forma diferente. Por exemplo, na Adventure Works, a tabela de dimensões de data tem três relações com os fatos de vendas do revendedor. A mesma tabela de dimensão pode ser usada para filtrar os fatos por data do pedido, data de remessa ou data de entrega.

Em um data warehouse, a abordagem de design aceita é definir uma tabela de dimensão de data única. No momento da consulta, a "função" da dimensão de data é estabelecida por qual coluna de fato você usa para unir as tabelas. Por exemplo, quando você analisa as vendas pela data do pedido, a junção da tabela se relaciona à coluna data do pedido de venda do revendedor.

Em um modelo semântico do Power BI, esse design pode ser imitado criando várias relações entre duas tabelas. No exemplo da Adventure Works, as tabelas vendas de data e revendedor teriam três relações.

Embora esse design seja possível, só pode haver uma relação ativa entre duas tabelas de modelo semântico do Power BI. Todas as relações restantes devem ser definidas como inativas. Ter um único relacionamento ativo significa que há uma propagação de filtro padrão da data para as vendas do revendedor. Nesse caso, a relação ativa é definida como o filtro mais comum usado pelos relatórios, que na Adventure Works é a relação de data do pedido.

A única maneira de usar uma relação inativa é definir uma expressão DAX que usa a função USERELATIONSHIP. Em nosso exemplo, o desenvolvedor do modelo deve criar medidas para habilitar a análise de vendas do revendedor por data de remessa e data de entrega. Esse trabalho pode ser entediante, especialmente quando a tabela de revendedores define muitas medidas. Ele também cria um painel de dados desordenado que tem uma superabundância de medidas. Também há outras limitações:

• Quando os autores de relatórios dependem de colunas de resumo em vez de definir medidas, eles não podem obter o resumo das relações inativas sem escrever uma medida no nível do relatório. As medidas em nível de relatório só podem ser definidas durante a criação de relatórios no Power BI Desktop.
• Com apenas um caminho de relação ativo entre a data e as vendas do revendedor, não é possível filtrar simultaneamente as vendas do revendedor por diferentes tipos de datas. Por exemplo, você não pode produzir um visual que plote vendas de datas do pedido por remessa de vendas.

Para superar essas limitações, uma técnica comum de modelagem do Power BI é criar uma tabela de dimensões para cada instância de role-playing. Você pode criar cada tabela de dimensões como uma consulta de referência usando Power Query ou uma tabela calculada usando DAX. O modelo pode conter uma Date tabela, uma Ship Date tabela e uma Delivery Date tabela, cada uma com uma relação única e ativa com suas respectivas colunas da tabela de vendas do revendedor.

Essa abordagem de design não exige que você defina várias medidas para diferentes funções de data e permite a filtragem simultânea por diferentes funções de data. Um preço menor a pagar com essa abordagem de design, no entanto, é que haverá duplicação da tabela de dimensões de data, resultando em um tamanho de armazenamento de modelo maior. Como as tabelas de dimensões normalmente armazenam menos linhas em relação às tabelas de fatos, isso raramente é uma preocupação.

Recomendamos que você siga as boas práticas de design ao criar tabelas de dimensões de modelo para cada função:

• Verifique se os nomes de coluna são autodescritivos. Embora seja possível ter uma Year coluna em todas as tabelas de datas (os nomes das colunas são exclusivos em sua tabela), ela não é autodescritiva por títulos visuais padrão. Considere renomear colunas em cada tabela de função de dimensão para que a Ship Date tabela tenha uma coluna de ano chamada Ship Yeare assim por diante.
• Quando relevante, verifique se as descrições de tabela fornecem comentários aos autores de relatórios (por meio de dicas de ferramentas do painel Dados ) sobre como a propagação de filtro é configurada. Essa clareza é importante quando o modelo contém uma tabela com nome genérico, como Date, que é usada para filtrar muitas tabelas de fatos. Caso essa tabela tenha, por exemplo, uma relação ativa com a coluna de data do pedido de venda do revendedor, considere fornecer uma descrição de tabela como Filters reseller sales by order date.

Para saber mais, confira Diretrizes de relações ativas vs inativas.

Dimensões de lixo eletrônico

Uma dimensão de lixo eletrônico é útil quando há muitas dimensões, especialmente consistindo em alguns atributos (talvez um) e quando esses atributos têm poucos valores. Bons candidatos incluem colunas de status do pedido ou colunas demográficas do cliente, como sexo ou faixa etária.

O objetivo de design de uma dimensão indesejada é consolidar muitas dimensões pequenas em uma única dimensão para reduzir o tamanho do armazenamento do modelo e também reduzir a desordem do painel de dados exibindo menos tabelas de modelo.

Uma tabela de dimensões indesejadas normalmente é o produto cartesiano de todos os membros do atributo de dimensão, com uma coluna de chave substituta para identificar exclusivamente cada linha. Você pode criar a dimensão em um data warehouse ou usando o Power Query para criar uma consulta que execute junções de consulta externa completa e, em seguida, adicionar uma chave substituta (coluna de índice).

Você carrega essa consulta no modelo como uma tabela de dimensões. Você também precisa mesclar essa consulta com a consulta de fato para que a coluna de índice seja carregada no modelo para dar suporte à criação de uma relação de modelo "um para muitos".

Degenerar dimensões

Uma dimensão degenerada refere-se a um atributo da tabela de fatos que é necessário para filtragem. Na Adventure Works, o número da ordem de venda do revendedor é um bom exemplo. Nesse caso, não faz sentido criar uma tabela independente que consista apenas nessa coluna, pois isso aumentaria o tamanho do armazenamento do modelo e resultaria em desordem no painel de dados .

No modelo semântico do Power BI, pode ser apropriado adicionar a coluna de número da ordem de venda à tabela de fatos para permitir a filtragem ou o agrupamento por número da ordem de venda. É uma exceção à regra introduzida anteriormente de que você não deve misturar tipos de tabela (geralmente, as tabelas de modelo devem ser dimension ou fact).

No entanto, se a tabela de vendas de revendedores da Adventure Works tiver colunas de número de pedido e número de linha de pedido e elas forem necessárias para filtragem, a criação de uma tabela de dimensões degenerada seria um bom design. Para saber mais, confira as Diretrizes de relação um-para-um (Dimensões de degeneração).

Tabelas de fatos sem fatos

Uma tabela de fatos sem fatos não inclui nenhuma coluna de medida. Ela contém apenas chaves de dimensão.

Uma tabela de fatos sem fatos poderia armazenar observações definidas por chaves de dimensão. Por exemplo, em uma data e hora específicas, um cliente específico fez login em seu site. Você pode definir uma medida para contar as linhas da tabela de fatos sem fatos para executar a análise de quando e quantos clientes entraram.

Um uso mais atraente de uma tabela de fatos sem fatos é armazenar relações entre dimensões, e é uma abordagem de design de modelo semântico do Power BI que recomendamos para definir relações de dimensão muitos para muitos. Em um design de relação de dimensão muitos para muitos, a tabela de fatos sem fatos é conhecida como uma tabela de pontes.

Por exemplo, considere que os vendedores podem ser atribuídos a uma ou mais regiões de vendas. A tabela de pontes seria projetada como uma tabela de fatos informativa que consiste em duas colunas: chave de vendedor e chave de região. Valores duplicados podem ser armazenados em ambas as colunas.

Essa abordagem de design de muitos para muitos é bem documentada e pode ser obtida sem uma tabela de pontes. No entanto, a abordagem da tabela de pontes é considerada a melhor prática ao relacionar duas dimensões. Confira mais informações em Diretrizes de relação de muitos para muitos (Relacionar duas tabelas de tipo dimensão).

Conteúdo relacionado

Para obter mais informações sobre o design do esquema em estrela ou o design do modelo semântico do Power BI, consulte os seguintes artigos:

• Artigo da Wikipédia de modelagem dimensional
• Modelar relações no Power BI Desktop
• Diretrizes de relação um-para-um
• Diretrizes da relação muitos para muitos
• Diretrizes de relação bidirecional
• Diretrizes de relações ativas vs inativas
• Modelagem dimensional no Microsoft Fabric Warehouse
• Alguma dúvida? Tente perguntar à comunidade do Fabric
• Sugestões? Contribua com ideias para melhorar o Fabric