Cómo implementar SCD Tipo 2 en ELT: paso a paso

João Barros 04 de July de 2026 5 min de lectura

Guardar el histórico de cambios de un cliente — como un cambio de dirección o de segmento — es esencial para análisis fiables a lo largo del tiempo. El patrón SCD Tipo 2 (Slowly Changing Dimension) resuelve esto: crea una nueva versión del registro cada vez que un atributo cambia, en lugar de sobrescribir el valor anterior. En un flujo ELT, los datos llegan primero a la capa de staging y se transforman con SQL ya dentro del data warehouse.

Requisitos previos

Acceso a un data warehouse con SQL (SQL Server, Azure Synapse, Snowflake, Databricks o BigQuery).
Una tabla de staging con los datos actuales del origen (por ejemplo, stg_clientes).
Nociones básicas de SQL: INSERT, UPDATE y JOIN.
Permisos para crear y modificar tablas en el destino.

Paso 1: Entender qué es una dimensión SCD Tipo 2

Una dimensión SCD Tipo 2 mantiene varias filas para la misma entidad — un cliente, por ejemplo — una por cada periodo en el que sus datos fueron válidos. Tres columnas de control lo hacen posible: valid_from (inicio de validez), valid_to (fin de validez) e is_current (marca la versión activa). Así, una consulta puede saber a qué segmento pertenecía un cliente en cualquier fecha pasada, algo imposible si solo guardáramos el valor más reciente.

Paso 2: Crear la tabla de dimensión con columnas de histórico

Además de los atributos de negocio (nombre, segmento), la tabla final necesita una clave sustituta (surrogate key) y las tres columnas de control. La columna cliente_id guarda la clave de negocio que enlaza cada versión con el mismo cliente real. Los ejemplos usan sintaxis de SQL Server; la lógica es la misma en otros warehouses.

CREATE TABLE dim_cliente (
    cliente_sk INT IDENTITY(1,1) PRIMARY KEY,
    cliente_id INT NOT NULL,
    nome VARCHAR(100),
    segmento VARCHAR(50),
    valid_from DATE NOT NULL,
    valid_to DATE NULL,
    is_current BIT NOT NULL
);

Paso 3: Cerrar las versiones antiguas que cambiaron

La primera parte de la transformación encuentra los registros cuyo nome o segmento difiere de la versión que está en staging y los "cierra": rellena valid_to con la fecha de hoy y pone is_current = 0. Solo se ven afectadas las filas actuales que realmente cambiaron; las demás quedan intactas.

UPDATE d
SET d.valid_to = CAST(GETDATE() AS DATE),
    d.is_current = 0
FROM dim_cliente AS d
INNER JOIN stg_clientes AS s
    ON s.cliente_id = d.cliente_id
WHERE d.is_current = 1
  AND (d.segmento <> s.segmento OR d.nome <> s.nome);

Paso 4: Insertar las nuevas versiones

A continuación, insertamos una fila nueva para cada cliente que es nuevo o que acabamos de cerrar en el paso anterior. La nueva versión queda marcada como actual (is_current = 1), con valid_from en hoy y valid_to vacío.

INSERT INTO dim_cliente (cliente_id, nome, segmento, valid_from, valid_to, is_current)
SELECT s.cliente_id, s.nome, s.segmento, CAST(GETDATE() AS DATE), NULL, 1
FROM stg_clientes AS s
LEFT JOIN dim_cliente AS d
    ON d.cliente_id = s.cliente_id AND d.is_current = 1
WHERE d.cliente_id IS NULL;

El LEFT JOIN seguido de WHERE d.cliente_id IS NULL captura dos casos a la vez: clientes totalmente nuevos (que nunca tuvieron fila en la dimensión) y clientes cuya versión actual se cerró en el Paso 3 — y que, por eso, ya no tienen ninguna fila con is_current = 1. Los clientes que no cambiaron conservan su fila actual y no se duplican.

Paso 5: Automatizar la transformación en el pipeline ELT

Une los dos comandos en un único procedimiento almacenado o script, ejecutado siempre después de cargar la capa de staging. El orden importa: primero el UPDATE que cierra, luego el INSERT que crea. Un orquestador como Azure Data Factory, Databricks Workflows o un simple planificador puede ejecutar este paso en cada actualización de datos. Como el proceso siempre compara el staging con la versión actual, ejecutar el script dos veces seguidas no crea duplicados: es idempotente.

Verificar el resultado

La regla de oro de una SCD Tipo 2 es simple: cada entidad solo puede tener una versión actual. La siguiente consulta no debe devolver ninguna fila; si lo hace, hay un cliente con demasiadas versiones actuales.

SELECT cliente_id, COUNT(*) AS versoes_atuais
FROM dim_cliente
WHERE is_current = 1
GROUP BY cliente_id
HAVING COUNT(*) > 1;

Para ver el histórico, consulta un cliente concreto y ordena por valid_from: deberías ver una fila cerrada (con valid_to relleno e is_current = 0) y una fila actual. Eso confirma que el cambio se guardó sin perder el valor anterior.

Conclusión

Con solo dos comandos SQL — cerrar las versiones antiguas e insertar las nuevas — ya puedes mantener un histórico fiable en una dimensión SCD Tipo 2 dentro de un flujo ELT. A partir de aquí, puedes añadir una columna hash para detectar cambios en muchos atributos a la vez, o usar una fecha de fin máxima (por ejemplo 9999-12-31) en lugar de NULL para simplificar los joins. ¿Qué atributos de tu negocio cambian con el tiempo y merecerían guardarse en histórico?