Cabeçalho e item de pedido são duas tabelas fato, não uma
Sua planilha de vendas tem uma linha por pedido com o total e o frete, e outra fonte com uma linha por item vendido dentro de cada pedido. É tentador juntar tudo numa tabela só — mas isso é exatamente o que quebra o relacionamento e infla os números no Power BI.
- Pedido (cabeçalho) tem 1 linha por pedido; Item do Pedido (detalhe) tem N linhas por pedido.
- Granularidades diferentes não cabem numa tabela fato só.
- A solução é relacionar as duas tabelas em 1:N pelo número do pedido.
- O mesmo padrão vale pra nota fiscal, fatura, ordem de produção — qualquer resumo com detalhe.
O que acontece quando cabeçalho e detalhe viram uma tabela só
Imagine um pedido com frete de R$ 20 e três itens dentro dele. Se você duplica o valor do frete em cada uma das três linhas de item pra "juntar tudo numa tabela", qualquer soma de frete no relatório vai contar R$ 60 em vez de R$ 20 — porque o mesmo valor de cabeçalho foi repetido artificialmente pra caber na granularidade mais fina do detalhe.
Por que a granularidade diferente é o problema real
Pedido e Item do Pedido não são a mesma coisa medida duas vezes — são dois níveis de detalhe diferentes da mesma operação. Pedido responde perguntas como "quantos pedidos tivemos" ou "qual foi o frete total". Item do Pedido responde perguntas como "qual produto vendeu mais" ou "qual foi o ticket médio por item". Forçar as duas granularidades numa tabela única não elimina a diferença — só esconde ela até um cálculo dar errado.
Como modelar certo: duas tabelas fato relacionadas
A solução é manter Pedido e Item do Pedido como duas tabelas separadas, cada uma na sua própria granularidade, relacionadas entre si por um campo em comum — normalmente o número do pedido — num relacionamento um-para-muitos. Uma linha de Pedido se conecta a várias linhas de Item do Pedido, e cada tabela guarda só os campos que fazem sentido no seu próprio nível: frete e desconto no Pedido, quantidade e preço unitário no Item.
Esse desenho não é uma regra arbitrária de curso — é o mesmo princípio do esquema estrela aplicado a duas tabelas fato distintas em vez de uma dimensão e uma fato: cada tabela fica na sua granularidade certa, e o relacionamento cuida de conectar os dois níveis sem duplicar valor.
Onde esse padrão aparece além de pedidos de venda
O mesmo problema — e a mesma solução — aparecem em qualquer par cabeçalho/detalhe: nota fiscal e item da nota, fatura e linha da fatura, ordem de produção e etapa da ordem, orçamento e item do orçamento. Sempre que uma fonte de dados tiver um resumo com granularidade grossa e um detalhe com granularidade fina, vale parar e perguntar se elas deveriam ser uma tabela fato só ou duas relacionadas — a resposta quase sempre é duas.
Quer aprender modelagem de dados de verdade?
O curso completo de Power BI da TECH SANTOS BR cobre modelagem de dados, Power Query e DAX — do zero até dashboards publicados sem número errado.
Perguntas frequentes
Pedido e item do pedido devem ser a mesma tabela fato?
Não. Pedido tem 1 linha por pedido; item do pedido tem N linhas por pedido — são granularidades diferentes que precisam de duas tabelas relacionadas.
Por que juntar cabeçalho e detalhe numa tabela só dá problema?
Um valor do cabeçalho repetido em cada linha de item multiplica esse valor pelo número de itens do pedido, inflando qualquer soma.
Como relacionar corretamente pedido e item do pedido?
Com um relacionamento um-para-muitos pelo número do pedido — cada tabela mantém sua própria granularidade e suas próprias medidas.
Isso vale só pra pedidos de venda?
Não — o mesmo padrão aparece em nota fiscal e item, fatura e linha, ordem de produção e etapa. Qualquer resumo com detalhe segue essa lógica.
Fontes: Microsoft Learn — Entender o esquema estrela. Consultada em 03/08/2026.