Aula 19 - Modelagem Dimensional (Star Schema) para Data Warehouses 📊

📑 1. Fundamentos Teóricos & Análise Técnica

Bancos de dados transacionais (OLTP) são projetados segundo as formas normais de Edgar F. Codd (3FN) para eliminar redundâncias e acelerar escritas atômicas. Entretanto, rodar consultas analíticas complexas de BI sobre esquemas 3FN com dezenas de JOINs degrada o sistema transacional e torna as consultas excessivamente lentas.

A Modelagem Dimensional (proposta por Ralph Kimball) reestrutura os dados analíticos em volta de processos de negócio: 1. Tabelas Fato (Fact Tables): Contêm as métricas numéricas quantitativas de eventos de negócio (vendas, acessos, pagamentos). Caracterizam-se por grande volume de linhas e chaves estrangeiras para as dimensões. 2. Tabelas Dimensão (Dimension Tables): Contêm o contexto descritivo e qualitativo do evento (Quem? Onde? Quando? O quê?). Ex: Dimensão Tempo, Dimensão Cliente, Dimensão Produto. 3. Esquema Estrela (Star Schema): Estrutura onde a tabela fato fica no centro cercada diretamente por dimensões desnormalizadas (sem joins adicionais), proporcionando performance imbatível em ferramentas analíticas (Power BI, BigQuery, Snowflake, Redshift).

📐 Arquitetura Conceitual & Diagrama de Fluxo

graph TD
    DimTime["Dim_Tempo<br>(Data, Mês, Ano, Trimestre)"] --> FactSales["FATO_VENDAS<br>(ID_Tempo, ID_Cliente, ID_Produto, Qtd, Valor_Total)"]
    DimCustomer["Dim_Cliente<br>(Nome, Cidade, Estado, Segmento)"] --> FactSales
    DimProduct["Dim_Produto<br>(Título, Categoria, Marca, Preço_Base)"] --> FactSales
    DimStore["Dim_Loja<br>(Filial, Região, Gerente)"] --> FactSales
    style FactSales fill:#fff3e0,stroke:#e65100,stroke-width:2px
    style DimTime fill:#e1f5fe,stroke:#01579b
    style DimCustomer fill:#e1f5fe,stroke:#01579b
    style DimProduct fill:#e1f5fe,stroke:#01579b
    style DimStore fill:#e1f5fe,stroke:#01579b

🔍 Pilares e Diretrizes Técnicas

Nesta unidade, aprofundamos os seguintes conceitos fundamentais: - Granularidade da Fato: Definição formal do que exatamente uma linha representa na tabela fato (ex: item individual vendido no checkout). - Chaves Substitutas (Surrogate Keys): Uso de inteiros sequenciais sintéticos em vez de chaves de negócio para isolar o DW de mudanças nos sistemas de origem. - Dimensões Lentamente Mutáveis (SCD Tipo 2): Preservação do histórico de alterações através de colunas de validade (data_inicio, data_fim, is_current). - Agregações Rápidas: Consultas analíticas com SUM, AVG e GROUP BY executadas sem subconsultas complexas.

🛠️ 2. Implementação Prática em Business Intelligence e Data Warehousing

Abaixo está a implementação técnica de referência, estruturada com padrões de engenharia de software e foco em robustez:

// star_schema.sql (Criação de Esquema Estrela Dimensional)
-- 1. Dimensão Tempo
CREATE TABLE dim_tempo (
    sk_tempo INT PRIMARY KEY,
    data_completa DATE NOT NULL,
    ano INT NOT NULL,
    mes INT NOT NULL,
    nome_mes VARCHAR(20) NOT NULL,
    trimestre INT NOT NULL,
    dia_semana VARCHAR(20) NOT NULL
);

-- 2. Dimensão Produto (Desnormalizada para alta velocidade)
CREATE TABLE dim_produto (
    sk_produto INT PRIMARY KEY,
    id_produto_origem INT NOT NULL,
    nome_produto VARCHAR(150) NOT NULL,
    categoria VARCHAR(50) NOT NULL,
    marca VARCHAR(50) NOT NULL
);

-- 3. Tabela Fato Central
CREATE TABLE fato_vendas (
    sk_venda BIGSERIAL PRIMARY KEY,
    sk_tempo INT REFERENCES dim_tempo(sk_tempo),
    sk_produto INT REFERENCES dim_produto(sk_produto),
    quantidade INT NOT NULL,
    valor_total NUMERIC(12, 2) NOT NULL,
    desconto NUMERIC(12, 2) DEFAULT 0.00
);

💡 Análise Passo a Passo do Código

1. Surrogate Keys (sk_*): Garante independência total de IDs do sistema transacional e padronização como inteiros rápidos.
2. Desnormalização Deliberada: Categorias e marcas residem na mesma tabela dim_produto, dispensando joins extras.
3. Consultas Analíticas Diretas: Permite que ferramentas de BI façam agregações em segundos sobre milhões de vendas.

🎯 3. Próximos Passos & Sequência Didática