Partilhar via

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

  • Artigo

Este artigo destina-se aos 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 ligar 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 que mudam lentamente (descritas mais adiante neste artigo).

Quando você se deparar com esses desafios, recomendamos que você primeiro desenvolva um data warehouse e processos de extração, transformação e carregamento (ETL) 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.

Gorjeta

Este artigo não se destina a fornecer 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 Star é 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.

  • As tabelas de dimensão descrevem entidades comerciais — as coisas que você modela. As entidades podem incluir produtos, pessoas, lugares 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 de chave (ou colunas) que atua como um identificador exclusivo e outras colunas. Outras colunas suportam filtragem e agrupamento de 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 de fatos contém colunas de chave de dimensão relacionadas a tabelas de 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 alvos de venda que tenha colunas Date de chave de duas dimensões e ProductKey. É fácil entender que a tabela tem duas dimensões. A granularidade, no entanto, não pode ser determinada sem considerar os valores-chave da dimensão. Neste exemplo, considere que os Date valores armazenados na coluna são o primeiro dia de cada mês. Neste caso, a granularidade está no nível do produto do mês.

Geralmente, as tabelas de dimensão contêm um número relativamente pequeno de linhas. As tabelas de factos, por outro lado, podem conter um grande número de linhas e continuar a crescer ao longo do tempo.

Diagrama mostrando uma ilustração de um esquema em estrela.

Normalização vs. desnormalização

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

Normalização é o termo usado para descrever dados armazenados de forma a reduzir dados repetitivos. Considere uma tabela de produtos que tenha uma coluna de valor de chave exclusiva, como a chave do produto, e outras colunas que descrevem 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 apenas a ProductKey coluna registra o produto.

Diagrama mostrando uma tabela de dados que inclui uma coluna Chave do Produto.

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

Diagrama mostrando uma tabela de dados que inclui uma Chave do Produto e outras colunas relacionadas ao produto, incluindo Categoria, Cor e Tamanho.

Quando você obtém dados de um arquivo de exportação ou extração de dados, é provável que eles representem um conjunto desnormalizado de dados. Neste caso, utilize 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 modelo.

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

O design de esquema em estrela e muitos conceitos relacionados introduzidos 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 para o modelo semântico do Power BI. Geralmente, as consultas filtram, agrupam e resumem dados do modelo. Um modelo bem projetado, então, é aquele que fornece tabelas para filtragem e agrupamento, e tabelas para resumir. Este design se encaixa bem com os princípios do esquema em estrela:

  • As tabelas de dimensão permitem a filtragem e o agrupamento.
  • As tabelas de fatos permitem a sumarização.

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 cardinalidade da relação que determina o tipo de tabela. Uma cardinalidade de relacionamento comum é um-para-muitos ou seu inverso muitos-para-um. O lado "um" é sempre uma tabela de dimensões, enquanto o lado "muitos" é sempre uma tabela de factos.

Diagrama mostrando uma ilustração conceitual de um esquema em estrela.

Um design de modelo bem estruturado inclui tabelas que são tabelas de dimensão ou tabelas de fatos. Evite misturar os dois tipos para uma única mesa. Também recomendamos que você se esforce para fornecer o número certo de mesas com os relacionamentos certos no lugar. Também é importante que as tabelas de fatos sempre carreguem os dados em um grão 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 faz sentido fazê-lo.

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

Medições

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 suporta medidas explícitas e implícitas.

  • Medidas explícitas são expressamente criadas e são baseadas em uma fórmula escrita em Data Analysis Expressions (DAX) que alcança a sumarização. 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 simples agregações de coluna a fórmulas mais sofisticadas que substituem o contexto do filtro e/ou a propagação da 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 relatório, visual ou P&R. Eles oferecem uma conveniência para você como desenvolvedor de modelos, já que 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, min, max 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 (∑).

Diagrama mostrando ícones encontrados no painel Dados.

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ê souber que os autores do relatório consultarão o modelo semântico usando MDX (Multidimensional Expressions), o modelo deverá incluir medidas explícitas. Isso porque o MDX não consegue resumir os valores das colunas. Notavelmente, o MDX é usado ao executar Analisar no Excel porque as Tabelas Dinâmicas emitem consultas MDX.

  • Quando você souber que os autores do relatório criarão relatórios paginados do Power BI usando o designer de consulta MDX, o modelo semântico deverá incluir medidas explícitas. Somente o designer de consulta MDX oferece 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 apenas usando funções de agregação específicas. 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 Power BI e para P&R. No entanto, as conexões em tempo real 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 substitutas

Uma chave substituta é um identificador exclusivo que você adiciona a uma tabela para dar suporte à modelagem de esquema em estrela. Por definição, ele não é definido ou armazenado nos dados de origem. Geralmente, as chaves substitutas são adicionadas às tabelas de dimensões do data warehouse relacional para fornecer um identificador exclusivo para cada linha da tabela de dimensão.

As relações de 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 atingir esse requisito adicionando uma coluna de índice do Power Query.

Diagrama a mostrar o comando Criar coluna de índice no Power Query Editor.

Você deve mesclar essa consulta com a consulta do lado "muitos" para que você possa 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 dos flocos de neve

Uma dimensão de floco de neve é um conjunto de tabelas normalizadas para uma única entidade comercial. Por exemplo, a Adventure Works classifica os produtos por categoria e subcategoria. Os produtos são atribuídos a subcategorias e, por sua vez, as subcategorias 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.

Diagrama mostrando um exemplo de um diagrama de floco de neve compreendendo três tabelas relacionadas.

Se você usar sua imaginação, você pode imaginar as mesas normalizadas posicionadas para fora da tabela de fatos, formando um design de floco de neve.

Diagrama mostrando um exemplo conceitual de um diagrama de floco de neve composto por três tabelas relacionadas.

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. Geralmente, os benefícios de uma única tabela de modelo 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ê escolhe imitar um design de dimensão de floco de neve:

  • O Power BI carrega mais tabelas, o que é menos eficiente do ponto de vista do armazenamento e do 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 filtros de relacionamento mais longas precisam ser percorridas, o que pode ser menos eficiente do que 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 de flocos de neve contêm apenas uma ou duas colunas.
  • Não é possível criar uma hierarquia que inclua colunas de mais de uma tabela.

Ao optar por integrar em uma única tabela modelo, você também pode definir uma hierarquia que engloba o grão mais alto e o menor grão da dimensão. Possivelmente, o armazenamento de dados desnormalizados redundantes pode resultar no aumento do tamanho do armazenamento do modelo, particularmente para tabelas de grandes dimensões.

Diagrama mostrando um exemplo de uma hierarquia dentro de uma tabela de dimensões que tem colunas como Categoria, Subcategoria e Produto.

Dimensões em mudança lenta

Uma dimensão de mudança lenta (ou SCD) é aquela que gerencia adequadamente a mudança de membros da dimensão ao longo do tempo. Aplica-se quando os valores da entidade empresarial mudam lentamente ao longo do tempo de uma forma não planeada. Um bom exemplo de um SCD é uma dimensão do cliente, porque suas colunas de detalhes de contato, como endereço de e-mail e número de telefone, mudam com pouca frequência. Em contraste, algumas dimensões são consideradas como mudando rapidamente quando um atributo de dimensão muda frequentemente, como o preço de mercado de uma ação. A abordagem de design comum nesses casos é armazenar valores de atributos que mudam rapidamente em uma medida de tabela de fatos.

A teoria do projeto de 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 suportar ambos os tipos simultaneamente para colunas diferentes.

SCD tipo 1

Um SCD Tipo 1 sempre reflete os valores mais recentes e, quando alterações nos dados de origem são detetadas, 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 e-mail ou o número de telefone de um cliente. Quando um endereço de e-mail ou número de telefone do cliente é alterado, a tabela de dimensões atualiza a linha do cliente com os novos valores. É como se o cliente sempre tivesse essa informação de contato.

Diagrama mostrando um exemplo de uma dimensão de mudança lenta tipo 1 onde um número de telefone de funcionário é atualizado.

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

SCD tipo 2

Um SCD Tipo 2 suporta versionamento de membros de dimensão. Se o sistema de origem não armazenar versões, geralmente é o processo de carregamento do data warehouse que deteta 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 todos os vendedores a uma região de vendas. Quando um vendedor realoca uma 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 a uma análise histórica precisa das vendas por vendedor, a tabela de dimensões deve armazenar versões dos vendedores e sua(s) região(ões) associada(s). A tabela também deve incluir valores de data de início e término para definir a validade de 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.

Diagrama mostrando um exemplo de uma dimensão de mudança lenta tipo 2 onde uma região de vendas de funcionários é atualizada criando uma nova versão.

É 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 detetar e armazenar alterações. O processo de carregamento de tabela deve preservar os dados existentes e detetar alterações. Quando uma alteração é detetada, o processo de carregamento da tabela deve expirar a versão atual. Ele registra essas alterações atualizando o EndDate valor e inserindo uma nova versão com o StartDate valor começando a partir do valor anterior EndDate . Além disso, os fatos relacionados devem usar uma pesquisa baseada no tempo para recuperar o valor da chave da 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ões SCD Tipo 2 pré-carregada.

Gorjeta

Para saber como implementar uma tabela de dimensões SCD Tipo 2 em um armazém de malha, 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 que você consulte o vendedor independentemente da região de vendas atribuída ou de uma versão específica do vendedor.

Para atingir 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 versão 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 educar os autores e consumidores de relatórios sobre os conceitos básicos do SCD Tipo 2 e como obter designs de relatório apropriados aplicando filtros corretos.

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

Diagrama mostrando o painel Dados com colunas para Versão do Vendedor e do Vendedor.

Dimensões de desempenho de funções

Uma dimensão de interpretação de papéis é 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ões pode ser usada para filtrar os fatos por data do pedido, data de envio ou data de entrega.

Diagrama mostrando um exemplo conceitual de uma única dimensão e relações de interpretação de papéis. A tabela Data tem duas relações com a tabela de fatos para data do pedido e data de envio.

Em um data warehouse, a abordagem de design aceita é definir uma única tabela de dimensão de data. No momento da consulta, a "função" da dimensão de data é estabelecida pela coluna de fato que você usa para unir as tabelas. Por exemplo, quando você analisa as vendas por data do pedido, a junção da tabela está relacionada à coluna de data da ordem 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 de vendas de data e revendedor teriam três relações.

Diagrama mostrando um exemplo de uma única dimensão de interpretação de papéis e relações. A tabela Data tem três relações com a tabela de fatos.

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, o relacionamento ativo é definido como o filtro mais comum usado pelos relatórios, que na Adventure Works é o relacionamento 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 permitir a análise das vendas do revendedor por data de envio e data de entrega. Este trabalho pode ser tedioso, especialmente quando a tabela do revendedor define muitas medidas. Ele também cria um painel de dados confuso que tem uma superabundância de medidas. Existem também outras limitações:

  • Quando os autores de relatórios confiam em resumir colunas em vez de definir medidas, eles não podem obter a sumarização para as relações inativas sem escrever uma medida no nível de relatório. As medidas no nível de relatório só podem ser definidas ao criar relatórios no Power BI Desktop.
  • Com apenas um caminho de relacionamento ativo entre data e vendas de revendedores, não é possível filtrar simultaneamente as vendas de revendedores por diferentes tipos de datas. Por exemplo, não é possível produzir um visual que plote as vendas da data do pedido pelas vendas enviadas.

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 representação de funções. Você pode criar cada tabela de dimensão como uma consulta de referência usando o 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 respetivas colunas da tabela de vendas do revendedor.

Diagrama mostrando um exemplo de dimensões e relações de interpretação de papéis. Existem três tabelas de dimensões de data diferentes relacionadas com a tabela de factos.

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 aumento do tamanho de armazenamento do modelo. Como as tabelas de dimensão 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ão de modelo para cada função:

  • Certifique-se de que os nomes das colunas são autodescritos. Embora seja possível ter uma Year coluna em todas as tabelas de data (os nomes das colunas são exclusivos dentro da 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 Year, e assim por diante.
  • Quando relevante, certifique-se de que as descrições das tabelas forneçam feedback aos autores de relatórios (por meio de dicas de ferramentas do painel Dados ) sobre como a propagação do 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 esta tabela tenha, por exemplo, um relacionamento ativo com a coluna de data da ordem de venda do revendedor, considere fornecer uma descrição da tabela como Filters reseller sales by order date.

Para obter mais informações, consulte Orientação de relacionamento ativo versus inativo.

Dimensões do lixo

Uma dimensão lixo é útil quando há muitas dimensões, especialmente consistindo em poucos atributos (talvez um), e quando esses atributos têm poucos valores. Os 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 de lixo é consolidar muitas dimensões pequenas em uma única dimensão para reduzir o tamanho de armazenamento do modelo e também reduzir a desorganização do painel de dados ao apresentar menos tabelas de modelo.

Uma tabela de dimensão de lixo é tipicamente o produto cartesiano de todos os membros do atributo de dimensão, com uma coluna de chave substituta para identificar exclusivamente cada linha. Pode criar a dimensão num armazém de dados ou utilizando o Power Query para criar uma consulta que efetua junções de consulta externas completas e, em seguida, adiciona uma chave substituta (coluna de índice).

Diagrama mostrando um exemplo de uma tabela de dimensão de lixo. O Status do Pedido tem três estados, enquanto o Status da Entrega tem dois estados. A tabela de dimensões de lixo armazena todas as seis combinações dos dois status.

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

Dimensões degeneradas

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 nesta coluna, porque isso aumentaria o tamanho do armazenamento do modelo e resultaria em confusão no painel Dados .

No modelo semântico do Power BI, pode ser apropriado adicionar a coluna 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 que você não deve misturar tipos de tabela (geralmente, as tabelas modelo devem ser dimensão ou fato).

Diagrama mostrando o painel Dados e a tabela de fatos de vendas, que inclui o campo Número do pedido.

No entanto, se a tabela de vendas dos 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, criar uma tabela de dimensão degenerada seria um bom design. Para obter mais informações, consulte Orientação de relacionamento um-para-um (Dimensões degeneradas).

Tabelas de factos sem factos

Uma tabela de fatos sem fatos não inclui colunas de medidas. Ele 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 entrou no 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 muitas para muitas dimensões. Em um design de relacionamento de muitas dimensões para muitas, a tabela de fatos sem fatos é referida como uma tabela de ponte.

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

Diagrama mostrando uma tabela de fatos sem fatos que une as dimensões Vendedor e Região. A tabela de fatos sem fatos é composta por duas colunas, que são as chaves de dimensão.

Esta abordagem de design muitos-para-muitos está bem documentada e pode ser alcançada sem uma mesa de transição. No entanto, a abordagem da tabela de transição é considerada a melhor prática quando se relacionam duas dimensões. Para obter mais informações, consulte Orientação de relacionamento muitos-para-muitos (Relacionar tabelas de tipo bidimensional).

Conteúdos relacionados

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