Power BI de verdade: 7 padrões de modelagem (estrela, medidas e performance)
Um dashboard lento, filtros que “somem” e medidas que mudam quando você troca o visual raramente são culpa do DAX sozinho. Na maioria das vezes, a raiz é modelagem. Um modelo bem desenhado reduz o custo de renderização, melhora compressão do motor e deixa as medidas mais estáveis.
O ponto de partida mais confiável é o esquema estrela (star schema), com fato no centro e dimensões ao redor. A própria Microsoft recomenda esse padrão como o caminho mais consistente para Power BI.
A seguir, você vai ver 7 padrões de modelagem que elevam performance e reduzem “medidas quebradas” em projetos reais de BI.
1) Modele em estrela, não em “tabela grandona”
O anti-pattern mais comum em Power BI é tentar colocar tudo em uma tabela única, “flat”, porque é mais rápido no começo. O problema aparece depois: duplicação de atributos, filtros confusos, medidas instáveis e performance pior.
O padrão estrela resolve isso separando:
- Fato: eventos mensuráveis (venda, pedido, sessão, ticket)
- Dimensões: quem/onde/quando/o quê (cliente, produto, canal, data)
Esse desenho é o que mais ajuda o Power BI a trabalhar bem com filtros e compressão.
2) Declare a granularidade da fato antes de criar medida
“Granularidade” é o grão do seu dado: 1 linha por pedido? por item do pedido? por dia e produto? Essa decisão muda tudo.
Quando a granularidade é mal definida, as pessoas começam a “compensar” com DAX complexo, e aí surgem medidas que funcionam em um visual e falham em outro. Um bom modelo deixa o grão óbvio e consistente: a fato representa um tipo de evento, com chave e datas claras.
Padrão prático: se você não consegue responder “o que uma linha significa?”, pare a modelagem antes de criar medidas.
3) Use dimensões conformadas para manter métricas consistentes
Dimensões conformadas são dimensões reutilizadas em diferentes fatos com a mesma definição (por exemplo, DimData, DimProduto, DimCliente servindo para Vendas e Atendimento). Isso evita o cenário clássico: “o dashboard de vendas mede cliente de um jeito, o de suporte mede de outro”.
Esse conceito vem do dimensional modeling clássico e é um dos pilares para escalar BI sem virar Frankenstein.
4) Tenha uma tabela calendário de verdade (e uma única fonte de tempo)
Quase todo modelo sólido tem uma DimData dedicada com colunas de ano, mês, semana, trimestre e indicadores úteis (mês atual, YTD, etc.). Ela serve como “relógio” do seu modelo.
Quando você usa datas “soltas” direto da fato (ou pior, várias colunas de data em várias tabelas), você aumenta o risco de filtros inconsistentes e “time intelligence” quebrando.
A prática recomendada no Power BI é ter uma tabela de datas bem definida e utilizar relações corretas com as colunas de data relevantes.
5) Relações: direção de filtro e cardinalidade são decisões de performance
Dois pontos derrubam modelos:
Direção de filtro
Na maioria dos casos, use filtro em uma direção (dimensão filtra fato). Bidirecional pode até “resolver” um problema pontual, mas costuma trazer ambiguidade e custo de performance.
Cardinalidade
O padrão saudável é 1: (um-para-muitos)* entre dimensão e fato. Muitos-para-muitos quase sempre é sintoma de:
- dimensão sem chave única
- fato com grão errado
- necessidade de tabela ponte (bridge) bem definida
A documentação da Microsoft explica relações, cardinalidade e direção de filtro e por que isso impacta o comportamento do modelo.
6) Medidas primeiro, colunas calculadas com parcimônia
Em geral:
- medidas são para cálculo sob filtro (agregações, taxas, comparações)
- colunas calculadas devem ser usadas quando você precisa de um atributo fixo por linha (categoria, chave auxiliar) e isso realmente faz sentido no modelo
Coluna calculada aumenta o tamanho do modelo; medida mal pensada pode ficar lenta. A melhor forma de reduzir “medida quebrada” é manter medidas simples e apoiar-se na modelagem correta.
Uma referência útil para boas práticas de modelo tabular (a base técnica por trás do Power BI) é o guia de design do modelo tabular do Microsoft Learn.
7) Evite alta cardinalidade em eixos e segmentações
Um dos motivos mais comuns de visual lento é usar colunas de alta cardinalidade como eixo ou slicer: IDs, timestamps completos, textos longos, descrições muito únicas.
Padrão prático:
- use eixos “humanos” (mês, categoria, canal)
- deixe detalhamento para drillthrough, tooltip e páginas de detalhe
- esconda colunas técnicas que existem só para relacionamento
Anti-patterns que mais quebram performance e confiança
Muitos-para-muitos sem necessidade
Quase sempre dá para corrigir com chave única na dimensão, ajuste de grão ou tabela ponte.
Modelo flat pesado
Facilita no começo e cobra juros depois.
Bidirecional como curativo
Gera resultados inesperados e performance pior.
Medidas iterativas sem critério
Iteradores são úteis, mas se a modelagem está errada você vai pagar caro no DAX.
Checklist rápido antes de publicar (copiar e usar)
Antes de publicar um relatório:
- Está em estrela (fato no centro, dimensões ao redor)?
- A granularidade da fato está clara?
- Existe DimData única e consistente?
- Dimensões principais são conformadas (reutilizáveis)?
- Relações são majoritariamente 1:* e filtro em uma direção?
- Evitei M:M e bidirecional sem justificativa?
- Evitei alta cardinalidade em eixos e segmentações?
- Medidas estão simples e bem nomeadas?
Se você passa por isso, a maior parte dos problemas de “medidas quebradas” e lentidão some.
Conclusão
Power BI “de verdade” é modelagem que aguenta crescimento: estrela bem feita, grão definido, dimensões conformadas, calendário único e relações saudáveis. Quando isso está certo, as medidas ficam mais simples, o dashboard fica mais rápido e o time confia no que está vendo.
Esse tipo de padrão é exatamente o que diferencia BI operacional de BI confiável, e faz parte do repertório aplicado no Bootcamp Data Analytics & AI da Tekne.
