Eventos
Junte-se a nós na FabCon Vegas
31 de mar., 23 - 2 de abr., 23
O melhor evento liderado pela comunidade Microsoft Fabric, Power BI, SQL e AI. 31 de março a 2 de abril de 2025.
Registre-se hoje mesmoNão há mais suporte para esse navegador.
Atualize o Microsoft Edge para aproveitar os recursos, o suporte técnico e as atualizações de segurança mais recentes.
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.
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.
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.
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.
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:
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:
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.
SUM
, MIN
, MAX
, AVERAGE
e 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.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.
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.
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
, DimProductSubcategory
e 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:
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.
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.
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.
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.
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:
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:
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 Year
e assim por diante.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.
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".
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).
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).
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:
Eventos
Junte-se a nós na FabCon Vegas
31 de mar., 23 - 2 de abr., 23
O melhor evento liderado pela comunidade Microsoft Fabric, Power BI, SQL e AI. 31 de março a 2 de abril de 2025.
Registre-se hoje mesmoTreinamento
Módulo
Projetar um modelo semântico no Power BI - Training
O processo de criação de um modelo semântico complicado no Power BI é simples. Se os dados vêm de mais de um sistema transacional, antes que você perceba, pode ter dezenas de tabelas com as quais precisa trabalhar. Criar um ótimo modelo semântico significa simplificar a desordem. Um esquema em estrela é uma maneira de simplificar um modelo semântico, e você aprenderá sobre a terminologia e a implementação deles neste módulo. Você também aprenderá por que a escolha da granularidade de dados correta é importa
Certificação
Microsoft Certified: Power BI Data Analyst Associate - Certifications
Demonstre métodos e boas práticas que se alinhem aos requisitos técnicos e comerciais para modelagem, visualização e análise de dados com o Microsoft Power BI.