DP-600: implementar tabelas de referência/desnormalizadas em modelos semânticos

Vou ensinar como implementar tabelas de referência desnormalizadas (lookup/denormalized reference tables) num modelo semântico Power BI/Fabric. Esta competência é importante para o exame DP-600 porque demonstra capacidade de optimizar modelos e, na prática, reduz a complexidade das consultas e melhora o desempenho de relatórios.

O que precisas de saber

Uma tabela de referência desnormalizada reúne informação que, em fontes operacionais, está espalhada por várias tabelas relacionadas. No contexto de modelos semânticos (import mode ou DirectQuery), desnormalizar algumas entidades pode:

• Reduzir o número de junções em runtime;
• Simplificar o modelo para utilizadores finais e para medidas DAX;
• Melhorar o desempenho de relatórios ao reduzir cardinalidade e travessias de relações.

Exemplo simples: em vez de ligar uma tabela fact_vendas a uma tabela cliente e outra tabela morada através de chaves, podes construir uma tabela cliente_desnormalizada que inclui cliente_id, nome_cliente, cidade, país. Assim, relatórios que só precisam de cidade e país consultam a tabela desnormalizada directamente, sem múltiplas junções.

Como funciona (passo a passo)

Vou explicar um fluxo prático para criar e integrar uma tabela de referência desnormalizada no Fabric/Power BI Desktop:

1. Identificar candidatos à desnormalização:

   • Procura queries ou relatórios com muitas junções ou filtros sobre atributos espalhados.
   • Prioriza entidades com alta cardinalidade ou junções que aparecem em páginas críticas de relatórios.

2. Escolher a granularidade e os atributos:

   Inclui apenas os campos necessários para relatórios e medidas. Evita campos voláteis que mudam com frequência (isso aumenta a manutenção).

3. Construir a tabela de referência na camada correcta:

   Preferível construir no processo ETL/ELT (Synapse, Data Factory, Power Query) antes de carregar para o modelo. No entanto, pode ser feita no Power Query se o volume for pequeno.

4. Exemplo em Power Query (Power BI Desktop):

   let
     Clientes = Sql.Database("servidor", "db"){[Schema="dbo",Item="Clientes"]}[Data],   Moradas = Sql.Database("servidor", "db"){[Schema="dbo",Item="Moradas"]}[Data],   Merge = Table.NestedJoin(Clientes, {"cliente_id"}, Moradas, {"cliente_id"}, "Morada", JoinKind.LeftOuter),   Expanded = Table.ExpandRecordColumn(Merge, "Morada", {"cidade","pais"}, {"cidade","pais"}),   SelectCols = Table.SelectColumns(Expanded, {"cliente_id","nome_cliente","cidade","pais"}) in   SelectCols

   Este script faz uma junção entre Clientes e Moradas e expande apenas as colunas necessárias, criando uma tabela desnormalizada.

5. Carregar para o modelo e criar relações:

   Substitui relações múltiplas entre fact e várias dimensões por uma relação única entre fact e a tabela desnormalizada. Mantém relações de 1 para muitos com cardinalidade correcta e direcção de filtro adequada.

6. Actualizar medidas e evitar ambiguidade:

   Revisita medidas DAX que usavam as tabelas originais; ajusta nomes de colunas se necessário. Evita colunas duplicadas com o mesmo significado.

7. Documentar e gerir actualizações:

   Regista a decisão de desnormalização e define um processo de actualização (ETL/Refresh incremental) para manter os dados consistentes.

Na prática — dicas e melhores práticas

Algumas orientações práticas ao implementar estas tabelas:

• Não desnormalizar tudo: a melhoria de desempenho vem com custo de manutenção e maior tamanho do dataset.
• Para DirectQuery, evita desnormalização que cria linhas agregadas muito grandes; pode prejudicar a execução remota.
• Usa colunas de chave natural ou surrogate keys conforme o padrão do teu ambiente; mantêm unicidade e integridade.
• Se a fonte é actualizada frequentemente, considera criar a tabela desnormalizada no Data Warehouse/OneLake para centralizar a lógica e partilhar com outras equipas.

Erros comuns

Algumas armadilhas típicas ao desnormalizar:

• Desnormalizar campos voláteis: incluir atributos que mudam frequentemente (ex.: estado civil) implica grande sobrecarga de manutenção.
• Duplicar sem gerir chaves: criar duplicação de valores sem chave única pode levar a contagens e somas incorrectas nas medidas.
• Desnormalizar indiscriminadamente para reduzir cardinalidade: por vezes a cardinalidade aumenta (ex.: juntar tabelas com many-to-many inadvertidos) e degrada o desempenho.

Como praticar

Para praticar esta competência de forma segura e alinhada com a certificação:

• Faz os laboratórios do practice assessment OFICIAL da Microsoft (gratuito) para DP-600 — eles focam as skills measured e são o recurso recomendado para treino prático.
• Consulta a study guide oficial da Microsoft (gratuita) para DP-600 para ver o contexto das skills measured e exercícios sugeridos.
• Num ambiente de desenvolvimento (Power BI Desktop, Fabric), cria um pequeno dataset com fact_vendas, clientes e moradas e implementa a tabela desnormalizada usando Power Query ou ELT; mede a diferença de tempo de refresh e de rendering de páginas antes/depois.

Em resumo

• Tabelas de referência desnormalizadas reduzem junções e simplificam o modelo, melhorando a experiência do utilizador.
• A decisão de desnormalizar deve equilibrar desempenho, manutenção e frequência de actualização dos dados.
• Constrói estas tabelas preferencialmente na camada ETL/ELT e documenta o processo para garantir consistência.
• Pratica com os recursos oficiais: o Practice Assessment e a study guide da Microsoft são gratuitos e recomendados para preparação do DP-600.