Cómo crear una Slowly Changing Dimension Tipo 1 en Modelado de Datos (Kimball)

Aprende a implementar una Slowly Changing Dimension Tipo 1 (SCD Type 1) en Modelado de Datos (Kimball) para actualizar atributos de dimensión cuando no es necesario mantener historial. Esta técnica es útil para corregir o sobrescribir valores (ej.: contactos, direcciones) y simplifica ETL e informes.

Requisitos previos

• Conocimientos básicos de SQL (SELECT, INSERT, UPDATE).
• Una base de datos relacional (ej.: SQL Server, PostgreSQL) para probar.
• Datos de origen con una clave de negocio y atributos que pueden cambiar.
• Herramienta ETL simple (ej.: scripts SQL, SSIS, Azure Data Factory).

Paso 1: Identificar la dimensión y los atributos Tipo 1

Elegir la dimensión que se actualizará sin mantener historial. Ejemplos: Customer, Product (nombre), Supplier contact. Decide qué atributos se sobrescribirán (Tipo 1) y cuáles, si los hay, requieren otro tratamiento.

Paso 2: Diseñar la tabla de dimensión

Crear la tabla de dimensión en star schema con una surrogate key (clave sustituta) y la business key. No es necesaria columna de validez 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
);

Paso 3: Preparar los datos de origen

Leer los datos de origen (ej.: tabla staging o feed). Normalmente tienes una tabla staging con snapshot reciente. Estándar: staging_customer contiene customer_id y atributos actuales.

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

Paso 4: Comparar e identificar cambios (INSERT vs UPDATE)

Usar MERGE (o JOIN + UPDATE/INSERT) para distinguir nuevos registros a insertar y registros existentes a actualizar. Para SCD Type 1, las filas existentes se actualizan para reflejar los nuevos valores.

-- Ejemplo usando MERGE (SQL Server / compatible)
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());

Paso 5: Manejar columnas sensibles y reglas de negocio

Si existen reglas (ej.: no sobrescribir email si es nulo) aplica condiciones adicionales en el MERGE/UPDATE. Para atributos críticos, validaciones y logging ayudan a rastrear cambios inesperados.

-- Ejemplo: no sobrescribir email si 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 ...

Paso 6: Registrar cambios y auditoría

Aun sin preservar el historial en la dimensión, es útil mantener una tabla de audit con before/after o un log de ETL para rastrear cambios y 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' o 'UPDATE'
  old_values JSON, -- o formato apropiado
  new_values JSON
);

-- Insertar registro en el proceso ETL siempre que haya UPDATE o INSERT

Verificar el resultado

Confirmar que nuevos clientes fueron insertados y que clientes existentes tienen atributos actualizados sin duplicar surrogate keys. Ejemplos de verificaciones:

• Contar registros: SELECT COUNT(*) FROM dim_customer;
• Verificar cambios: SELECT * FROM dim_customer WHERE last_updated > DATEADD(hour,-1,GETDATE());
• Comprobar integridad: claves business únicas y sin duplicados.

Conclusión

Implementar una Slowly Changing Dimension Tipo 1 es una tarea común y sencilla en Modelado de Datos (Kimball): actualiza atributos sin preservar historial, reduce complejidad y mejora rendimiento de consulta. Próximos pasos: automatizar el job ETL, añadir pruebas y considerar SCD Type 2 si necesitas historial. Consejo: documenta siempre las reglas de sobrescritura para evitar sorpresas en los informes.