Como criar uma Slowly Changing Dimension Tipo 1 em Modelação de Dados (Kimball)

Aprende a implementar uma Slowly Changing Dimension Tipo 1 (SCD Type 1) em Modelação de Dados (Kimball) para actualizar atributos de dimensão quando não é necessário manter histórico. Esta técnica é útil para corrigir ou sobrescrever valores (ex.: contactos, moradas) e simplifica ETL e relatórios.

Pré-requisitos

• Conhecimentos básicos de SQL (SELECT, INSERT, UPDATE).
• Uma base de dados relacional (ex.: SQL Server, PostgreSQL) para testar.
• Dados de origem com uma chave de negócio e atributos que podem mudar.
• Ferramenta ETL simples (ex.: scripts SQL, SSIS, Azure Data Factory).

Passo 1: Identificar a dimensão e os atributos Tipo 1

Escolher a dimensão que será actualizada sem manter histórico. Exemplos: Customer, Product (nome), Supplier contact. Decide quais os atributos que serão sobrescritos (Tipo 1) e quais, se houver, que exigem outro tratamento.

Passo 2: Desenhar a tabela de dimensão

Criar a tabela de dimensão em star schema com uma surrogate key (chave substituta) e a business key. Não é preciso coluna de validade temporal (start_date/end_date) para SCD Type 1.

CREATE TABLE dim_customer (
  customer_sk INT IDENTITY(1,1) PRIMARY KEY,
  customer_id VARCHAR(50) UNIQUE, -- business key
  customer_name VARCHAR(200),
  email VARCHAR(200),
  city VARCHAR(100),
  country VARCHAR(100),
  last_updated DATETIME
);

Passo 3: Preparar os dados de origem

Ler os dados de origem (ex.: tabela staging ou feed). Normalmente tens uma tabela staging com snapshot recente. Padrão: staging_customer contém customer_id e atributos actuais.

-- Exemplo de staging
CREATE TABLE staging_customer (
  customer_id VARCHAR(50),
  customer_name VARCHAR(200),
  email VARCHAR(200),
  city VARCHAR(100),
  country VARCHAR(100)
);

Passo 4: Comparar e identificar mudanças (INSERT vs UPDATE)

Usar MERGE (ou JOIN + UPDATE/INSERT) para distinguir novos registos a inserir e registos existentes a actualizar. Para SCD Type 1, as linhas existentes são actualizadas para reflectir os novos valores.

-- Exemplo usando MERGE (SQL Server / compatível)
MERGE INTO dim_customer AS tgt
USING staging_customer AS src
  ON tgt.customer_id = src.customer_id
WHEN MATCHED AND (
     ISNULL(tgt.customer_name,'') <> ISNULL(src.customer_name,'')
  OR ISNULL(tgt.email,'') <> ISNULL(src.email,'')
  OR ISNULL(tgt.city,'') <> ISNULL(src.city,'')
  OR ISNULL(tgt.country,'') <> ISNULL(src.country,'')
) THEN
  UPDATE SET
    customer_name = src.customer_name,
    email = src.email,
    city = src.city,
    country = src.country,
    last_updated = GETDATE()
WHEN NOT MATCHED BY TARGET THEN
  INSERT (customer_id, customer_name, email, city, country, last_updated)
  VALUES (src.customer_id, src.customer_name, src.email, src.city, src.country, GETDATE());

Passo 5: Lidar com colunas sensíveis e regras de negócio

Se houver regras (ex.: não sobrescrever email se for nulo) aplica condições adicionais no MERGE/UPDATE. Para atributos críticos, validações e logging ajudam a rastrear alterações inesperadas.

-- Exemplo: não sobrescrever email se src.email IS NULL
WHEN MATCHED AND (
  (ISNULL(tgt.customer_name,'') <> ISNULL(src.customer_name,''))
  OR (src.email IS NOT NULL AND ISNULL(tgt.email,'') <> src.email)
)
THEN UPDATE SET ...

Passo 6: Registar alterações e auditoria

Mesmo não preservando o histórico na dimensão, é útil manter uma tabela de audit com before/after ou um log de ETL para rastrear alterações e permitir debugging.

CREATE TABLE dim_customer_audit (
  audit_id INT IDENTITY(1,1) PRIMARY KEY,
  customer_id VARCHAR(50),
  changed_at DATETIME,
  changed_by VARCHAR(100),
  change_type VARCHAR(10), -- 'INSERT' ou 'UPDATE'
  old_values JSON, -- ou formato apropriado
  new_values JSON
);

-- Inserir registo no processo ETL sempre que houver UPDATE ou INSERT

Verificar o resultado

Confirmar que novos clientes foram inseridos e que clientes existentes têm atributos actualizados sem duplicar surrogate keys. Exemplos de verificações:

• Contar registos: SELECT COUNT(*) FROM dim_customer;
• Verificar alterações: SELECT * FROM dim_customer WHERE last_updated > DATEADD(hour,-1,GETDATE());
• Checar integridade: chaves business únicas e sem duplicados.

Conclusão

Implementar uma Slowly Changing Dimension Tipo 1 é uma tarefa comum e simples em Modelação de Dados (Kimball): actualiza atributos sem preservar histórico, reduz complexidade e melhora performance de consulta. Próximos passos: automatizar o job ETL, adicionar testes e considerar SCD Type 2 se precisares de histórico. Dica: sempre documenta as regras de sobrescrição para evitar surpresas nos relatórios.