🧱 Modelação de Dados — Base forte

Em contexto de migração: Redesenhar schema (normalizado → dimensional)? SCD ao migrar dimensões históricas? Tratamento de duplicados na origem?

---

Star Schema vs Snowflake

Star Schema

• Estrutura: Uma fact table central + várias dimension tables (normalizadas ao mínimo). Dimensões ligam diretamente à fact.
• Prós: Queries simples, joins diretos, BI tools adoram. Performance em leitura.
• Contras: Redundância nas dimensões.
• Quando: Reporting, analytics, dashboards.

Snowflake Schema

• Estrutura: Dimensões normalizadas — sub-dimensões ligam a dimensões (ex: Região → País → Continente).
• Prós: Menos redundância, armazenamento eficiente.
• Contras: Mais joins, queries mais complexas.
• Quando: Dados muito normalizados, menos redundância desejada.

---

Fact vs Dimension Tables

Fact Table

• O quê: Medidas e eventos (vendas, cliques, transações).
• Contém: Foreign keys para dimensões + métricas (amount, quantity).
• Granularidade: Uma linha = um evento ou agregado.
• Exemplo: fact_sales (sale_id, date_id, product_id, customer_id, amount, quantity)

Dimension Table

• O quê: Contexto descritivo (quem, o quê, quando, onde).
• Contém: Atributos (nome, categoria, região).
• Exemplo: dim_product (product_id, name, category, brand)

---

Slowly Changing Dimensions (SCD)

Type 1 — Overwrite

• Atualiza o registo existente. Perde histórico.
• Quando: Histórico não importa (ex: correção de typo).

Type 2 — New Row

• Adiciona nova linha com valid_from, valid_to, is_current.
• Quando: Histórico importa (ex: mudança de região de cliente).

Type 3 — New Column

• Adiciona colunas previous_value, current_value.
• Quando: Só precisas do valor anterior (raro).

---

ETL vs ELT

---

Batch vs Streaming

Híbrido: Lambda (batch + stream) ou Kappa (só stream).