DP-600: optimizar modelos semânticos com star schema

João Barros 09 de August de 2026 6 min de leitura

Esta lição foca uma competência chave do DP-600: implementar e gerir modelos semânticos utilizando o padrão star schema (esquema em estrela). Saber quando e como estruturar fact e dimension tables melhora desempenho, facilita cálculos DAX e é frequentemente avaliado no exame e usado em cenários reais. Um modelo bem desenhado reduz tempos de resposta, diminui o consumo de memória e simplifica a governação do relatório e dos dados.

O que precisas de saber

Um star schema organiza dados em tabelas de fact (fact tables) que contêm medidas numéricas (como vendas, quantidades) e tabelas de dimensão (dimension tables) que contêm atributos descritivos (como produto, cliente, data). A ideia central é manter a fact table desnormalizada e as dimensões relativamente estáveis, ligadas por chaves simples. Vantagens: consultas mais rápidas, modelação DAX mais simples e melhor compressão no motor VertiPaq.

Exemplo simples: uma fact table Sales com colunas SaleID, ProductKey, CustomerKey, DateKey, Quantity, SalesAmount; e dimensões Product (ProductKey, ProductName, Category), Customer (CustomerKey, Name, Region) e Date (DateKey, Date, Year, Month). Em cenários reais, a fact table pode alcançar milhões de linhas (por exemplo 5–50M rows), enquanto as dimensões tipicamente têm dezenas a centenas de milhares de registos (por exemplo Product = 10k, Customer = 120k). Manter as dimensões limpas e com chaves inteiras ajuda a compressão: trocar chaves textuais por surrogate keys pode reduzir espaço ocupado por essas colunas de 60–80% em muitos casos.

Como funciona na prática

Principais elementos e passos para implementar um star schema eficaz no Power BI/Fabric:

Identificar facts e dimensions: parte das fontes; tabelas transaccionais (vendas, transacções) tornam-se fact tables. Tabelas com atributos descritivos (produtos, clientes, calendário) tornam-se dimensões. Por exemplo, uma tabela de orders com 12 colunas e 10M de linhas deve ser convertida numa fact table com chaves e medidas e as restantes colunas movidas para dimensões para reduzir a duplicação.
Escolher e manter chaves de ligação: utiliza surrogate keys inteiras quando possível (ex.: ProductKey) em vez de combinação de strings. Chaves inteiras optimizam relacionamentos e compressão. Na prática, gera um ProductKey como inteiro sequencial no ETL (IDENTITY/auto-increment) e armazena a chave natural (SKU) apenas na dimensão para referência. Isto acelera joins e reduz o tamanho do índice; por exemplo, uma coluna int ocupa 4 bytes, enquanto uma SKU de 20 caracteres pode ultrapassar 20 bytes por registo.
Desnormalizar fact, normalizar dimensões: evita joins profundos em consultas analíticas; a fact table deve conter apenas as chaves e as medidas. As dimensões podem agrupar atributos relacionados (ex.: ProductCategory na dimensão Product). Desnormalizar a fact significa, por exemplo, evitar colunas que repetem texto longo em cada linha de venda; em vez disso, guarda a referência à dimensão.
Modelar relações com cardinalidade correcta: define relações 1:* (dimension → fact). No Power BI Desktop/Fabric, marca as relações activate/bi-directional conforme necessário, mas prefere filtragem unidireccional na maioria dos casos. Relações unidireccionais mantêm o modelo previsível e evitam contextos ambíguos; usa bi-directional apenas quando precisares de filtrar across sem bridge tables, e faz testes de integridade antes de publicar.
Gerir hierarquias e colunas calculadas: cria hierarquias (Year > Month > Day) nas dimensões de data. Usa colunas calculadas com parcimónia: prefere medidas DAX para cálculos dinâmicos e melhores performances. Por exemplo, calcular margem média por produto deve ser feito como medida (agregada em runtime) e não como coluna calculada que aumenta o tamanho do modelo; apenas cria colunas calculadas quando precisares que a coluna exista para segmentação ou relacionamentos.

Na prática — exemplo DAX e modelação

Suponha que tens as tabelas Sales (fact) e Date (dim). Para criar uma medida de Total Sales em vez de coluna calculada, escreve:

Total Sales = SUM(Sales[SalesAmount])

YTD Sales = TOTALYTD([Total Sales], Date[Date])

Explicação: SUM agrega a fact table; TOTALYTD usa a dimensão Date para avaliar o ano até à data. Se a relação entre Sales[DateKey] e Date[DateKey] for correcta (1:*), estas medidas são eficientes e reutilizáveis em visuais. Numa base com 10M de linhas de fact, medidas bem escritas reduzem dramaticamente o tempo de cálculo: consultas típicas de somatório que demoravam 5–10s em modelos mal desenhados podem cair para 0.2–2s com compressão e chaves correctas.

Erros comuns

Usar relações muitos-para-muitos sem necessidade: recorrer a cardinalidade *:* e filtragem bi-directional por defeito pode causar resultados incorrectos e lentos. Avalia alternativas (bridge tables ou modelação diferente). Por exemplo, múltiplas relações diretas entre fact e várias dimensões podem levar a duplicação de resultados se não forem isoladas correctamente.
Colunas calculadas em excesso na fact table: criar muitas colunas derivadas em facts aumenta o tamanho do modelo. Prefere medidas DAX, excepto quando precisares de colunas para segmentação/categorização persistente. Como regra prática, cada coluna adicional numa fact de 20M de linhas acrescenta custos de memória lineares.
Chaves textuais longas como PK/FK: usar strings como chaves de ligação (ex.: códigos alfa) aumenta o espaço e reduz performance. Substitui por surrogate keys inteiras sempre que conseguires.

Como praticar

Para praticar, monta um pequeno projecto em Power BI Desktop/Fabric: importa uma tabela de vendas e tabelas dimensionais, cria o modelo star, define relações e implementa medidas como Total Sales, YTD e Average Price. Experimenta comparar performance entre colunas calculadas e medidas usando o Performance Analyzer e observando o tamanho do ficheiro (.pbix/.parquet) antes e depois. Um exercício útil é duplicar o modelo com chaves textuais e com chaves inteiras e comparar: muitas equipas observam reduções de 30–70% no tamanho do modelo após optimizar chaves e remover colunas desnecessárias.

Consulta os recursos oficiais gratuitos da Microsoft: o Practice Assessment OFICIAL para DP-600 (prática de avaliação grátis) e a study guide da Microsoft para DP-600. Ambos são gratuitos e ajudam a validar o teu conhecimento nas skills measured sem recorrer a material não autorizado.

Em resumo

Star schema separa fact tables (medidas) de dimension tables (atributos) para melhor desempenho e clareza.
Utiliza surrogate keys inteiras, relações 1:*, e preferivelmente filtragem unidireccional.
Prefere medidas DAX a colunas calculadas na fact table para reduzir uso de memória e melhorar performance.
Evita cardinalidades muitos-para-muitos e chaves textuais longas; testa e compara performance no teu ambiente usando ferramentas como Performance Analyzer antes de publicar.