Dois sistemas com propósitos opostos. OLTP registra. OLAP analisa. Misturá-los é a receita do desempenho ruim.
Repositório central para dados históricos e sumarizados. Otimizado para leitura analítica — não para gravação transacional.
Extract, Transform, Load. O processo que copia, limpa e consolida dados dos sistemas operacionais para o DW.
Modelo dimensional com uma tabela fato central (métricas) e tabelas dimensão ao redor (contexto). Simples, rápido, legível.
O nível de detalhe de cada linha na tabela fato. Declarar o grão é o segundo passo de Kimball — e o mais crítico.
Slowly Changing Dimensions. O que acontece com a dimensão Cliente quando o endereço muda? Três estratégias com consequências diferentes.
Compare a receita do segundo trimestre deste ano com o mesmo período do ano passado — por gênero, por país e por tipo de dispositivo.
O analista rodou a query no banco de produção da SoundByte. Em 40 segundos, o sistema de streaming travou para 80 mil usuários simultâneos.
Uma loja é organizada para facilitar a venda. Um armazém, para facilitar o inventário. O mesmo dado com estruturas diferentes para propósitos diferentes.
| Característica | OLTP — Transacional | OLAP — Analítico |
|---|---|---|
| Usuário | Operacional | Analista de Negócio |
| Foco | Operações diárias | Tomada de decisão |
| Orientado por | Aplicação | Assunto / Negócio |
| Dados | Atualizados e detalhados | Histórico e sumarizado |
| Atende | Milhares de usuários | Centenas de usuários |
| Histórico | Até 24 meses | 5 a 10 anos |
| Exemplo SoundByte | BD de produção (Aula 2) | Data Warehouse + Star Schema |
Um Data Warehouse consolida dados de várias fontes em uma visão integrada e histórica, preparada para consultas analíticas complexas. Ao contrário do banco transacional, o DW é otimizado para leitura, não para escrita.
O que acontece com a dimensão DIM_CLIENTE quando um cliente muda de país? O endereço antigo some ou a empresa mantém os dois? Esse dilema é real em toda empresa com base de clientes — e tem três respostas possíveis.
scd_versao) diferencia as versões. Histórico preservado. Implementação mais complexa, mas correto.pais_anterior ao lado de pais_atual. Histórico limitado (apenas uma mudança). Útil quando só importa o "antes" e "depois".artista diretamente — no OLTP isso seria uma tabela separada. No DW, a desnormalização acelera queries e simplifica joins.trimestre = 2 e comparação entre anosgeneropaistipo_dispreceitapais ou genero não existissem nas dimensões, a pergunta seria impossível de responder com precisão.
Contexto: Estou modelando o Data Warehouse da SoundByte, uma
plataforma de streaming de música. Tenho uma DIM_CLIENTE com
os campos: cliente_sk, nome, pais, genero, faixa_etaria.
Pergunta: Como eu deveria modelar a Dimensão Cliente para manter
o histórico de mudanças de endereço (país) ao longo dos anos,
sem perder a precisão dos relatórios de vendas passados?
Por favor: explique o conceito de SCD Tipo 2, mostre a estrutura
da tabela com os campos adicionais necessários e dê um exemplo
de como ficaria o registro de um cliente que mudou do Brasil
para Portugal em 2024.-- SCD Tipo 2: nova linha para cada mudança de atributo
CREATE TABLE DIM_CLIENTE (
cliente_sk SERIAL PRIMARY KEY, -- Surrogate Key
cliente_id INTEGER, -- NK — ID original do OLTP
nome VARCHAR(100),
pais CHAR(2),
genero CHAR(1),
faixa_etaria VARCHAR(20),
-- Campos de controle SCD Tipo 2 ↓
dt_inicio DATE NOT NULL, -- Quando este registro entrou em vigor
dt_fim DATE, -- NULL = registro atual
is_atual BOOLEAN DEFAULT TRUE -- Flag de facilidade para filtrar
);
-- Cliente que mudou de Brasil para Portugal em 2024:
-- Linha 1 (histórica): dt_inicio='2019-01-10', dt_fim='2024-06-01', is_atual=FALSE, pais='BR'
-- Linha 2 (atual): dt_inicio='2024-06-01', dt_fim=NULL, is_atual=TRUE, pais='PT'
-- Relatório de vendas até 2023 usa SK da linha 1 → pais='BR' ✓
-- Relatório de vendas de 2025 usa SK da linha 2 → pais='PT' ✓