(+351) 21 24 10006  ·  info@bconcepts.pt
Carnaxide, Lisboa
Power BI

Modelação em estrela no Power BI: boas práticas que fazem a diferença

João Barros 28 de June de 2024 2 min de leitura

A qualidade de um relatório Power BI depende 80% do modelo de dados subjacente, não dos visuais. A modelação em estrela — com uma tabela de factos central rodeada de dimensões — é o padrão recomendado pela Microsoft e pelo motor VertiPaq.

Porquê a modelação em estrela?

O motor de colunas VertiPaq comprime dados repetidos com elevada eficiência. Numa esquema em estrela, as dimensões têm poucos valores únicos (e.g., nomes de produto, regiões) e comprimem quase na perfeição. A tabela de factos tem muitas linhas mas colunas com alta cardinalidade que também comprimem bem por colunas separadas.

Esquemas snow-flake (dimensões normalizadas) parecem mais "limpos", mas forçam o VertiPaq a fazer mais joins em memória, aumentando o footprint e degradando performance. Regra: desnormalize as dimensões.

Regras práticas

  • Uma tabela de datas por modelo — nunca use a hierarquia de datas automática do Power BI; crie uma tabela de datas explícita marcada como Date Table.
  • Evite relações many-to-many directas — use tabelas de ponte e filtragem bidirecional apenas quando indispensável.
  • Chaves surrogate inteiras — joins em INT são mais rápidos do que em strings.
  • Remova colunas desnecessárias — cada coluna que não é usada no relatório ocupa memória e aumenta o tempo de refresh.

Estrutura típica

Factos: fVendas
  SurrogateKey_Data INT
  SurrogateKey_Produto INT
  SurrogateKey_Cliente INT
  Quantidade INT
  ValorLiquido DECIMAL

Dimensões: dData, dProduto, dCliente, dRegiao

Validar o modelo

Use o Performance Analyzer (View → Performance Analyzer) para identificar visuais lentos. Um visual que demora mais de 2 segundos a carregar geralmente indica um problema no modelo — cardinalidade elevada numa dimensão ou medidas DAX ineficientes.

Conclusão

Investir tempo na modelação em estrela antes de construir relatórios poupa horas de troubleshooting mais tarde. Um modelo bem estruturado traduz-se em tempos de refresh menores, queries DAX mais simples e relatórios que os utilizadores adoram porque são rápidos.

Partilhar: