DP-700: como projetar e implementar esquemas dimensionais para analytics

Neste guia vou ensinar a competência de projetar e a implementar esquemas dimensionais (star e snowflake) para soluções de analytics no contexto do DP-700. Esta competência importa porque modelos dimensionais melhoram o desempenho das consultas, facilitam relatórios em Power BI e são frequentemente exigidos em arquiteturas de Data Warehouse e Lakehouse.

O que precisas de saber

Um esquema dimensional organiza os dados em fact tables (factos) e dimension tables (dimensões). A fact table contém medidas numéricas (ex.: sales_amount, quantity) e chaves para dimensões; as dimension tables contêm atributos descritivos (ex.: product_name, customer_segment). O formato mais comum é o star schema (fact table central ligada a várias dimensões), e a variante snowflake normaliza dimensões em múltiplas tabelas.

Exemplo simples:

FactSales
- SalesID (PK)
- DateKey (FK -> DimDate.DateKey)
- ProductKey (FK -> DimProduct.ProductKey)
- CustomerKey (FK -> DimCustomer.CustomerKey)
- SalesAmount

DimDate
- DateKey (PK)
- Date
- Year
- Month

DimProduct
- ProductKey (PK)
- ProductName
- Category

DimCustomer
- CustomerKey (PK)
- CustomerName
- Region

Neste modelo, consultas analíticas típicas (ex.: total de vendas por mês e por categoria) juntam a fact table às dimensões por chaves numéricas, o que é eficiente.

Como funciona

Passos práticos para projetar e implementar um esquema dimensional numa solução Fabric (OneLake, Delta tables, Power BI):

1. Identifica os processos de negócio e as métricas — começa por listar os principais indicadores (KPIs) que os relatórios vão precisar: revenue, units_sold, margin, etc.
2. Define as granularidades — a fact table deve refletir a menor granularidade necessária (ex.: por transacção, por linha de pedido, por dia). Uma granularidade incorreta obriga a agregações complexas no consumo.
3. Modela as dimensões — cria dimensões para entidades que descrevem os factos: cliente, produto, tempo, localização. Evita duplicação de atributos que pertençam claramente a uma dimensão.
4. Escolhe chaves surrogate — prefere surrogate keys inteiras (ProductKey, CustomerKey) em vez de natural keys (SKU, NIF) para manter integridade e performance.
5. Implementa no Fabric — cria tabelas Delta no OneLake (ou tabelas do Lakehouse):

   -- Exemplo simplificado T-SQL / SQL para criar tabelas Delta no Notebook SQL
   CREATE TABLE lakehouse.dbo.DimDate (
     DateKey INT PRIMARY KEY,
     Date DATE,
     Year INT,
     Month INT
   ) WITH ( LOCATION = '.../DimDate' );
   
   CREATE TABLE lakehouse.dbo.FactSales (
     SalesID BIGINT,
     DateKey INT,
     ProductKey INT,
     CustomerKey INT,
     SalesAmount DECIMAL(18,2)
   ) USING DELTA;
   

6. Ingestão e manutenção — usa pipelines (Dataflows, Synapse Pipelines ou Fabric pipelines) para carregar facts e dimensões. Para dimensões lentas (slowly changing dimensions, SCD) implementa a estratégia adequada (Type 1 ou Type 2). Por exemplo, para SCD Type 2 adiciona colunas de effective_date e end_date e gera nova row quando o atributo muda.
7. Optimização física — indexação em sistemas MPP não é directa; em Fabric optimiza com ordenação (sort order) e partições adequadas (ex.: partição por DateKey). Para consultas por categoria, considera clustering por Category ou ProductKey.

Na prática — um caso de uso passo-a-passo

Objectivo: criar um star schema simples para relatórios de vendas por mês e categoria.

1. Identifica campos: SalesDate, ProductSKU, CustomerID, Quantity, Amount, Category.
2. Cria DimDate com DateKey = YYYYMMDD; popula a dimensão com um pipeline diário.
3. Cria DimProduct com ProductKey (surrogate), ProductSKU, ProductName, Category. Resolve duplicados no processo ETL e gera ProductKey com sequência.
4. Cria FactSales com SalesID, DateKey, ProductKey, CustomerKey, Quantity, Amount. No pipeline de ingestão converte ProductSKU -> ProductKey usando lookup na DimProduct.
5. Particiona FactSales por YearMonth (ex.: 202601) para consultas por período, e ordena por ProductKey para análise por produto.
6. Testa consultas típicas (GROUP BY Month, Category) com dados de amostra e mede tempos; ajusta partição/ordenamento conforme necessário.

Erros comuns

• Granularidade incorrecta: definir a fact table com granularidade demasiado agregada ou demasiado fina que não corresponde aos requisitos analíticos; ambos causam problemas de performance ou complicações nas agregações.
• Usar chaves naturais como PKs: chaves textuais ou compostas (ex.: SKU) degradam performance e complicam alterações; prefere surrogate integer keys.
• Dimensões sem historial quando necessário: tratar mudanças históricas como Type 1 quando precisas de historial (Type 2) leva a relatórios errados e perda de rastreabilidade.

Como praticar

Pratica implementando um star schema num ambiente Fabric ou num sandbox: cria DimDate, DimProduct, FactSales; implementa pipelines simples para popular tabelas e cria relatórios em Power BI sobre esse modelo. Para preparação do exame, usa o Practice Assessment OFICIAL e gratuito da Microsoft e a Study Guide oficial (ambos gratuitos) — estes recursos ajudam a validar o conhecimento naquele domínio sem recorrer a dumps. Procura na página do exame DP-700 os links para o practice assessment e a study guide.

Em resumo

• Modela facts e dimensões com base nos KPIs e na granularidade necessária.
• Usa surrogate keys, partições e ordenamento para optimizar consultas analíticas.
• Implementa SCDs adequadas para preservar historial quando necessário.
• Testa consultas reais e ajusta parâmetros físicos (partições/clustering) no Fabric antes de publicar para consumo.