Dimensión tipo 2

Curso de Data Warehousing y Modelado OLAP

Contenido del curso

No sé dónde empezar

Introducción a BI y Data Warehouse

Modelos dimensionales

ETL para inserción en Data Warehouse

Cierre

26
De datos crudos a modelo dimensional listo
01:18 min

Tomar examen

Cursos Empresas Blog Live Conf Eventos Precios

0:006:05

Dimensión tipo 2

Curso de Data Warehousing y Modelado OLAP

Clase 10 de 26

Clase 10 / 26

Recursos

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.

Mario Alexander Vargas Celis

Hace 2 años

Una dimensión tipo 2 es un tipo de dimensión en un Data Warehouse diseñada para rastrear y preservar el historial de cambios en los datos. A diferencia de una dimensión tipo 1, que sobrescribe los valores antiguos, la dimensión tipo 2 crea una nueva fila en la tabla para cada cambio, permitiendo conservar los datos históricos.

Características principales:

Registro del historial: Cada cambio en un atributo de la dimensión se guarda como una nueva fila en la tabla.
Identificadores únicos: Cada versión de un registro tiene un identificador único o clave sustituida (surrogate key) para diferenciar las versiones del mismo objeto.
Control de vigencia: Se utilizan columnas para rastrear el período de tiempo en que cada versión estuvo activa, como fechas de inicio y fin o un indicador de "fila activa".

Casos de uso:

Cuando es necesario analizar datos históricos o realizar un seguimiento de cómo han cambiado los valores a lo largo del tiempo.
Ideal para áreas donde los cambios en atributos impactan el análisis, como datos de clientes, ubicaciones o productos.

Ejemplo práctico:

Supongamos que tienes una tabla de dimensión para clientes:

Estado inicial:

SK_ClienteID_ClienteNombreCiudadFecha_InicioFecha_FinActivo11001JuanBogotá2024-01-019999-12-31Sí

Cambio: Juan se muda de Bogotá a Medellín el 2024-06-01.

Estado actualizado:

SK_ClienteID_ClienteNombreCiudadFecha_InicioFecha_FinActivo11001JuanBogotá2024-01-012024-05-31No21001JuanMedellín2024-06-019999-12-31Sí

Ventajas:

Permite análisis históricos al conservar el contexto de los datos en el tiempo.
Facilita el seguimiento de cambios relevantes para los negocios.

Desventajas:

Aumenta la complejidad y el tamaño de la tabla debido a la creación de múltiples versiones.
Requiere procesos ETL más elaborados para manejar las fechas de vigencia y los indicadores de estado.

La dimensión tipo 2 es una excelente opción cuando los cambios en los datos son críticos para el análisis de negocios y la toma de decisiones.

Introducción a BI y Data Warehouse

Qué es Business Intelligence y Data Warehousing

Niveles de analítica y jerarquía de datos

Qué son data warehouse, data mart y dimensiones

OLTP vs OLAP: diferencias clave

Inmon, Kimball y Hefesto en BI

Modelos dimensionales

Data Warehouse, Data Lake y Lakehouse

Modelo estrella vs copo de nieve en datos

Tipos de dimensiones lentamente cambiantes

Dimensión tipo 1: sobrescribir sin guardar historia

Dimensión tipo 2

Dimensión tipo 3: historia en columnas

Tabla de hechos (fact)

Configuración de herramientas para Data Warehouse y ETL

Cómo extraer dimensiones de preguntas de negocio

Diseño de tablas en un modelo dimensional

ETL para inserción en Data Warehouse

Documento de mapeo en ETL para data warehouse

Creando tablas dimensionales en Redshift

Extracción: querys en SQL

Cruce de fuentes en Pentaho con Stream Lookup

Transformación ETL con Pentaho paso a paso

Carga de datos transformados a Redshift con Pentaho

Cómo cargar la tabla de hechos con Pentaho

Cómo calcular MaxID y MaxDate en Pentaho

Orquestar ETL en Pentaho: job

Solución ETL con dimensiones en paralelo en Redshift

Cierre

De datos crudos a modelo dimensional listo

Dimensión tipo 2

Progreso del curso

Introducción a BI y Data Warehouse

Modelos dimensionales

ETL para inserción en Data Warehouse

Cierre

Recursos

Recursos