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 apenas do DAX. Na maioria das vezes, a raiz do problema está na modelagem.
Além disso, um modelo bem desenhado reduz o custo de renderização, melhora a compressão do motor e deixa as medidas mais estáveis. Por isso, o ponto de partida mais confiável é o esquema estrela, também conhecido como star schema, com uma tabela fato no centro e dimensões ao redor.
Nesse sentido, a própria Microsoft recomenda esse padrão como um caminho consistente para trabalhar com Power BI. A seguir, você vai ver 7 padrões de modelagem que melhoram a performance, reduzem medidas quebradas e aumentam a confiança 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 única tabela “flat”. No começo, essa escolha pode parecer mais rápida. No entanto, o problema aparece depois: duplicação de atributos, filtros confusos, medidas instáveis e performance pior.
Por outro lado, o padrão estrela organiza melhor o modelo porque separa claramente fatos e dimensões:
- Fato: eventos mensuráveis, como venda, pedido, sessão ou ticket.
- Dimensões: contexto da análise, como cliente, produto, canal, data e região.
Dessa forma, o Power BI trabalha melhor com filtros, relacionamentos e compressão. Além disso, o modelo fica mais fácil de entender, validar e manter.
Na prática, um bom modelo estrela evita que toda nova análise dependa de correções complexas em DAX. Portanto, antes de criar medidas avançadas, vale garantir que a estrutura do modelo esteja correta.
2) Declare a granularidade da fato antes de criar medida
Granularidade é o grão do dado. Em outras palavras, ela define o que uma linha da tabela fato representa: um pedido, um item do pedido, uma venda por dia ou uma sessão de usuário.
Essa decisão, porém, muda todo o modelo. Quando a granularidade é mal definida, as pessoas começam a compensar o problema com DAX complexo. Como resultado, surgem medidas que funcionam em um visual e falham em outro.
Por isso, um bom modelo deixa o grão óbvio e consistente. A tabela fato deve representar um tipo de evento, com chaves e datas claras.
Assim, antes de criar qualquer medida, faça uma pergunta simples: o que uma linha dessa tabela significa? Se a resposta não estiver clara, pare a modelagem antes de avançar.
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 e DimCliente podem servir tanto para vendas quanto para atendimento.
Com isso, você evita um problema comum: o dashboard de vendas mede cliente de um jeito, enquanto o dashboard de suporte mede de outro. Consequentemente, a empresa passa a discutir definições em vez de tomar decisões.
Além disso, dimensões conformadas ajudam a escalar BI com mais consistência. Em vez de cada área criar suas próprias regras, o modelo passa a ter uma base comum.
Esse conceito vem da modelagem dimensional clássica e é um dos pilares para evitar que o ambiente de BI vire um “Frankenstein”.
4) Tenha uma tabela calendário de verdade (e uma única fonte de tempo)
Quase todo modelo sólido precisa de uma DimData dedicada. Em geral, essa tabela inclui colunas de ano, mês, semana, trimestre e indicadores úteis, como mês atual, YTD e outros recortes temporais.
Na prática, a tabela calendário funciona como o relógio do modelo. Por isso, ela deve ser consistente, bem relacionada e usada como fonte principal para análises de tempo.
Quando você usa datas soltas diretamente da fato, o risco de filtros inconsistentes aumenta. Além disso, quando existem várias colunas de data espalhadas pelo modelo, recursos de time intelligence podem quebrar ou gerar leituras confusas.
Dessa forma, a prática recomendada é ter uma tabela de datas bem definida e relações corretas com as colunas de data relevantes.
5) Relações: direção de filtro e cardinalidade são decisões de performance
Relacionamentos não são apenas detalhes técnicos. Pelo contrário, eles influenciam diretamente a performance, a previsibilidade das medidas e o comportamento dos filtros.
Em geral, dois pontos derrubam muitos modelos: direção de filtro e cardinalidade.
Direção de filtro
Na maioria dos casos, use filtro em uma direção: dimensão filtra fato. Assim, o modelo tende a ficar mais previsível e mais performático.
O filtro bidirecional pode resolver um problema pontual. No entanto, ele costuma trazer ambiguidade, aumentar o custo de processamento e dificultar a manutenção.
Portanto, trate o bidirecional como exceção, não como padrão.
Cardinalidade
O padrão mais saudável costuma ser 1:*, ou seja, um-para-muitos entre dimensão e fato. Nesse caso, a dimensão possui uma chave única, enquanto a fato possui várias ocorrências relacionadas a essa chave.
Por outro lado, muitos-para-muitos quase sempre indica algum problema anterior, como dimensão sem chave única, fato com grão errado ou necessidade de uma tabela ponte.
Antes disso, vale revisar o modelo. Muitas vezes, corrigir o grão ou criar uma bridge bem definida resolve o problema com mais clareza.
A documentação da Microsoft explica como relacionamentos no Power BI, cardinalidade e direção de filtro impactam o comportamento do modelo.
6) Medidas primeiro, colunas calculadas com parcimônia
Em geral, medidas são indicadas para cálculos sob contexto de filtro, como agregações, taxas, comparações e variações ao longo do tempo.
Colunas calculadas, por sua vez, devem ser usadas quando você precisa de um atributo fixo por linha. Por exemplo, uma categoria, uma chave auxiliar ou uma classificação estática podem fazer sentido como coluna.
No entanto, é preciso cuidado. Colunas calculadas aumentam o tamanho do modelo. Por outro lado, medidas mal pensadas também podem ficar lentas, especialmente quando dependem de iteradores ou de uma modelagem ruim.
Como resultado, a melhor forma de reduzir medidas quebradas não é escrever DAX cada vez mais complexo. Na verdade, o caminho mais seguro é apoiar as medidas em uma modelagem correta, com grão claro, dimensões bem definidas e relações saudáveis.
Uma boa referência técnica para esse tema é o guia da Microsoft sobre modelos tabulares, base por trás do Power BI.
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 segmentação. Por exemplo, IDs, timestamps completos, textos longos e descrições muito únicas costumam pesar no relatório.
Na prática, quanto mais valores distintos uma coluna possui, maior tende a ser o custo para renderizar visuais, aplicar filtros e calcular medidas.
Por isso, prefira eixos mais legíveis, como mês, categoria, canal, produto agrupado ou região. Além disso, deixe detalhes mais específicos para drillthrough, tooltips e páginas de detalhe.
Também vale esconder colunas técnicas usadas apenas para relacionamento. Dessa forma, você melhora a experiência de quem consome o relatório e reduz a chance de uso incorreto dos campos.
Anti-patterns que mais quebram performance e confiança
Mesmo quando o relatório parece funcionar, alguns padrões ruins podem comprometer a performance e a credibilidade do BI. Por isso, vale revisar os principais sinais de alerta.
Muitos-para-muitos sem necessidade
Relacionamentos muitos-para-muitos quase sempre devem ser investigados. Em muitos casos, o problema pode ser corrigido com chave única na dimensão, ajuste de grão ou tabela ponte.
Modelo flat pesado
Um modelo flat facilita a primeira versão do relatório. No entanto, ele costuma cobrar juros depois, principalmente quando o projeto cresce e novas métricas aparecem.
Bidirecional como curativo
Usar filtro bidirecional para “fazer o número bater” pode resolver um sintoma. Porém, se a causa estiver na modelagem, o problema tende a voltar em outro visual.
Como consequência, o modelo pode gerar resultados inesperados e piorar a performance.
Medidas iterativas sem critério
Iteradores são úteis no DAX. Ainda assim, se a modelagem estiver errada, eles podem se tornar caros e difíceis de manter.
Portanto, antes de otimizar uma medida complexa, revise se o modelo está sustentando bem o cálculo.
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.
