Dimensión tipo 2

Cuando un atributo cambia en una tabla dimensional, perder el valor anterior puede significar perder contexto analítico valioso. La dimensión lentamente cambiante tipo 2 (Slowly Changing Dimension Type 2 o SCD Type 2) resuelve exactamente ese problema: permite conservar cada versión histórica de un registro sin sobrescribir la información previa. A continuación se explica su mecánica paso a paso, usando un ejemplo práctico que aclara cada detalle del proceso.

¿Qué diferencia a la dimensión tipo 2 de la tipo 1?

En la dimensión tipo 1, cuando un atributo cambia simplemente se reemplaza el valor anterior por el nuevo. No queda rastro del dato original. En cambio, la dimensión tipo 2 no reemplaza nada: crea un registro completamente nuevo para reflejar el cambio, manteniendo intacto el registro anterior [0:15].

Esto significa que ambos registros conviven en la misma tabla dimensional. Para distinguir cuál es vigente y cuál es histórico, se incorporan dos campos adicionales:

• Start date (fecha inicio): indica cuándo entró en vigencia el registro.
• End date (fecha fin): indica cuándo dejó de estar vigente.

Gracias a estos campos de vigencia es posible consultar en cualquier momento el estado de un registro en una fecha específica, lo que otorga trazabilidad completa sobre los cambios de atributos.

¿Cómo funciona la carga de una dimensión tipo 2 paso a paso?

Imagina que el estudiante Pepito Pérez pertenece a la Facultad de Ingeniería y su registro fue creado el 24 de febrero de 2030. Un mes después, el 24 de marzo de 2030, Pepito Pérez cambia a la Facultad de Salud [1:30].

¿Qué hace el proceso ETL al detectar el cambio?

El proceso de ETL (Extract, Transform, Load) busca en la dimensión el registro más actualizado y determina que la última carga ocurrió el 24 de febrero de 2030. Luego va a la fuente de datos —en este ejemplo, la tabla transaccional TBL Estudiante— y extrae todos los registros con fecha superior a esa última carga [2:15].

Al encontrar que existe un registro nuevo del 24 de marzo correspondiente a Pepito Pérez con la facultad Salud, el proceso compara el código del estudiante contra la dimensión. Descubre que ese código ya existe, pero en lugar de sobrescribir el atributo de facultad, genera un nuevo ID dimensional para el mismo estudiante [2:50].

El resultado en la dimensión queda así:

• ID 1: Pepito Pérez — Ingeniería — Inicio: 24/02/2030 — Fin: 24/03/2030.
• ID 2: Pepito Pérez — Salud — Inicio: 24/03/2030 — Fin: nulo o 31/12/9999.

¿Cómo se asignan las fechas de vigencia?

La vigencia del registro anterior se cierra con la fecha en la que se crea el nuevo registro. El nuevo registro inicia su vigencia en esa misma fecha (puede ser un minuto después para evitar cruces en consultas). Para la fecha fin del registro vigente existen dos convenciones habituales [3:40]:

• Dejarla como nulo, lo que indica que el registro sigue activo.
• Asignar una fecha futura lejana como 31/12/9999, que cumple la misma función.

Ambas opciones permiten identificar de forma inequívoca cuál es el registro actualmente vigente.

¿Por qué importa la calidad de datos en este proceso?

Durante el ejemplo se mencionó una fecha ficticia: el 30 de febrero, que no existe en el calendario. Este tipo de inconsistencias deben ser detectadas y corregidas dentro del proceso ETL antes de cargar los datos en el data warehouse [1:15]. La calidad de datos es un paso crítico que garantiza que las fechas de vigencia y los atributos cargados sean confiables para el análisis posterior.

Sin controles de calidad, se podrían insertar fechas imposibles que romperían las consultas de vigencia y generarían resultados analíticos incorrectos.

La dimensión tipo 2 es la solución más utilizada cuando se necesita conservar el historial completo de cambios en atributos dimensionales. Si te interesa conocer alternativas que no crean registros nuevos sino columnas adicionales, eso es exactamente lo que aborda la dimensión tipo 3. Comparte en los comentarios cómo manejas la vigencia de registros en tus proyectos de datos.