Slowly Changing Dimensions Tipo 2 sem dor de cabeça

Toda vez que alguém pergunta "qual era o endereço deste cliente quando a venda aconteceu?", você está diante de um problema de Slowly Changing Dimension (SCD). E a resposta, na maioria das vezes, é o SCD Tipo 2.

O problema

Imagine uma dimensão de clientes. Um cliente muda de cidade. Se você simplesmente atualizar a linha (SCD Tipo 1), perde a informação de onde ele estava antes — e suas vendas históricas passam a apontar para a cidade errada.

A solução: Tipo 2

No SCD Tipo 2, você nunca atualiza uma linha existente para um atributo rastreado. Em vez disso, você fecha a linha atual e insere uma nova versão. Cada linha ganha três colunas de controle:

• valid_from — quando a versão passou a valer
• valid_to — quando deixou de valer (ou NULL/data futura se ativa)
• is_current — flag booleana para a versão vigente

-- Fecha a versão anterior
UPDATE dim_cliente
SET valid_to = current_date(), is_current = false
WHERE cliente_id = 42 AND is_current = true;

-- Insere a nova versão
INSERT INTO dim_cliente (cliente_id, cidade, valid_from, valid_to, is_current)
VALUES (42, 'Lisboa', current_date(), NULL, true);

A tabela fato sempre referencia a chave substituta (surrogate key) da versão correta no momento do evento — não a chave natural do cliente.

Os erros mais comuns

1. Usar a chave natural na fato. Use sempre a surrogate key da versão vigente no momento.
2. Esquecer da idempotência. Se o pipeline rodar duas vezes, ele não pode criar versões duplicadas. Compare os atributos antes de gerar uma nova versão.
3. Rastrear atributos demais. Nem todo campo precisa de histórico. Decida conscientemente o que é Tipo 1 e o que é Tipo 2.

No Lakehouse, o MERGE do Delta Lake torna o Tipo 2 muito mais elegante do que era nos tempos de SSIS. Mas o conceito é o mesmo há décadas — e continua sendo um dos fundamentos que mais separa quem sabe modelar de quem só sabe carregar tabelas.