Star schema no Power BI: modele fatos e dimensões

O star schema no Power BI organiza eventos de negócio em tabelas fato e descrições em dimensões. A estrutura ajuda a filtrar e agregar dados de forma previsível. O guia abaixo mostra como escolher o grão, criar relações e revisar o resultado antes de publicar.

Quando o star schema no Power BI precisa de fatos e dimensões

Uma tabela fato registra ocorrências mensuráveis, como uma linha de pedido, uma movimentação de estoque ou uma hora apontada. Suas colunas numéricas costumam ser agregadas. Dimensões descrevem essas ocorrências por data, produto, cliente, filial ou outra perspectiva usada na análise.

Separar os papéis deixa o modelo mais fácil de navegar. Quem cria um relatório pode colocar atributos da dimensão em linhas ou filtros e medidas da fato em valores. A Microsoft descreve dimensões para filtrar e agrupar e fatos para resumir. Isso é uma orientação de modelagem, não uma exigência para toda fonte pequena.

Defina o grão antes de carregar colunas

O grão responde o que representa uma linha da fato. Escreva a definição numa frase: por exemplo, “uma linha por item de pedido faturado”. Ela impede que quantidades de pedido, de item e de entrega se misturem numa mesma contagem sem regra.

Exemplo hipotético: um pedido com três produtos tem três linhas na tabela de itens. Se uma tabela de cabeçalho, com valor total do pedido, for mesclada aos itens, o total poderá aparecer três vezes. Mantenha cada processo no grão adequado ou distribua o valor com uma regra comercial documentada.

Desenhe dimensões reutilizáveis

Uma dimensão deve apresentar uma linha por entidade e uma chave que identifique essa linha. A dimensão de produto pode guardar código, nome, categoria e marca; a fato guarda a chave do produto e as quantidades vendidas. Evite repetir descrições extensas em cada evento.

Use uma dimensão compartilhada quando dois processos precisarem da mesma perspectiva, como calendário para vendas e devoluções. Antes, confirme que seus atributos têm a mesma definição e que as chaves representam a mesma entidade. Uma dimensão compartilhada torna comparações coerentes, mas não resolve diferenças de significado entre fontes.

Escolha chaves estáveis e trate mudanças

Identificadores vindos de sistemas diferentes podem colidir ou mudar. Uma chave substituta numérica criada na camada de preparação permite relacionar cada versão da dimensão à fato sem expor códigos de origem. Preserve também o identificador natural para rastreio e reconciliação.

Se o endereço ou a categoria de um cliente muda, decida se a análise deve mostrar o atributo atual ou o válido no momento do evento. No segundo caso, a dimensão precisa manter versões e a preparação deve atribuir a chave correta a cada fato. Documente a regra e teste períodos históricos.

Configure relações simples e direção de filtro

Na maioria dos casos, uma dimensão tem uma relação um-para-muitos com uma fato: uma linha da dimensão filtra várias linhas de eventos. Confirme unicidade da chave no lado um e tipos compatíveis nos dois lados. A relação não deve esconder duplicatas que pertencem à origem.

Prefira direção de filtro única da dimensão para fato, salvo quando um requisito concreto exigir outra configuração. Filtros bidirecionais podem introduzir caminhos ambíguos quando várias dimensões e fatos se conectam. Se a relação muitos-para-muitos for inevitável, documente sua semântica e demonstre o resultado com casos pequenos.

Prepare o calendário e as datas do processo

Modelos com datas normalmente precisam de uma dimensão de calendário com uma linha por dia e atributos de ano, mês, trimestre e períodos fiscais. Verifique que a coluna de data não tenha lacunas no intervalo necessário e que a chave usada na relação tenha o mesmo tipo da data na fato.

Um evento pode ter várias datas, como pedido, expedição e entrega. Escolha uma relação ativa para a leitura mais comum e modele as demais datas de modo explícito nas medidas. O relatório deve dizer qual marco temporal está respondendo; trocar a relação sem intenção pode alterar a interpretação do indicador.

Valide agregações com uma amostra rastreável

Escolha poucos registros conhecidos e acompanhe-os da origem até o relatório. Compare número de linhas, soma de quantidade e valor por período e produto. Essa checagem encontra duplicação causada por junção, chave ausente ou grão incompatível antes de o modelo chegar ao usuário.

Crie medidas para valores de negócio e oculte chaves técnicas e colunas que não devam ser usadas diretamente. Teste totais e subtotais em mais de um nível. Um resultado que confere no detalhe pode divergir no total quando a medida ou a relação não representa a regra de negócio.

Decida onde transformar os dados

O Power Query pode preparar fontes simples e volumes compatíveis com o ambiente. Para transformações pesadas, históricos extensos ou regras complexas, uma camada de warehouse e processo de ETL pode melhorar controle, reuso e observabilidade. A escolha deve considerar atualização, capacidade, equipe e origem, não apenas uma fórmula genérica de desempenho.

Registre a linhagem, a regra de atualização e o responsável por cada etapa. Se o conjunto cresce, meça duração e consumo antes de redesenhar. A orientação oficial da Microsoft sobre esquema em estrela detalha os papéis das tabelas e ressalta cenários em que uma preparação prévia é útil.

Checklist de revisão para o modelo

Antes de publicar, confirme: cada fato tem um grão declarado; chaves de dimensão são únicas; relações filtram na direção prevista; datas e moedas têm regras claras; totais reconciliam com a fonte; e atributos têm descrições compreensíveis. Registre exceções como decisões, não como surpresas.

Peça a uma pessoa de negócio para validar nomes e interpretações e a outra pessoa técnica para revisar relações e atualização. Depois, use o guia de medidas DAX legíveis ao criar indicadores e o processo de implantação para promover alterações. O modelo de Vendas pode servir de referência visual, mas adapte as definições aos seus dados.

Erros que um teste de modelo dimensional encontra

Procure chaves repetidas nas dimensões, linhas sem correspondência, datas fora do calendário e fatos carregados no grão errado. Cada condição precisa de uma regra: rejeitar, classificar como desconhecida ou corrigir na origem. Não apague registros silenciosamente, pois isso altera totais sem deixar rastros.

Compare também resultado antes e depois de cada transformação. Uma tabela de controle com contagem de linhas e somas de referência localiza a etapa que introduziu diferença. Guarde amostras pequenas e reproduzíveis para que uma revisão futura consiga verificar o mesmo comportamento, mesmo quando a origem já mudou.

Fonte técnica: Microsoft Learn — esquema em estrela e Power BI. Consultado em 25/10/2026.