Dimensión tipo 3: historia en columnas

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:003:31

Dimensión tipo 3: historia en columnas

Curso de Data Warehousing y Modelado OLAP

Clase 11 de 26

Clase 11 / 26

Recursos

La dimensión lentamente cambiante tipo 3 te permite almacenar historia en un data warehouse sin duplicar registros: en lugar de insertar una fila nueva cuando un atributo cambia, agregas columnas que guardan el valor anterior y el actual. Es útil cuando solo necesitas conservar el cambio más reciente y el inmediatamente previo, no toda la línea de tiempo.

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

La clave está en cómo se guarda la historia. Mientras la tipo 2 crea un registro nuevo por cada cambio, la tipo 3 mantiene un único registro por entidad y abre columnas adicionales para versionar el atributo que cambia.

Piensa en Pepito Pérez, un estudiante que pasa de la Facultad de Mercadeo a la Facultad de Ingeniería. En lugar de duplicar su fila, creas dos atributos: facultad new y facultad old. El mismo ID, el mismo estudiante, pero ahora sabes a qué facultad pertenecía antes y a cuál pertenece hoy.

¿Qué es una dimensión lentamente cambiante tipo 3? Es un tipo de dimensión que guarda la historia de un atributo creando columnas nuevas (valor anterior y valor actual) en lugar de insertar un registro nuevo por cada cambio.

¿Cómo se carga una dimensión tipo 3 paso a paso?

Vamos con el ejemplo concreto que da la clase. Pepito Pérez está asignado a la Facultad de Salud, y su registro fue actualizado por última vez el 24 de febrero de 2030. Esa es la información de origen que va a entrar en la ETL.

Primera carga: cuando la dimensión está vacía

En la primera ejecución de la ETL, Pepito Pérez se almacena tal como existe en el origen. Como la dimensión está vacía, el ID se calcula a partir del máximo registro existente, así que arranca en 1.

El registro queda así:

ID: 1.
Facultad Old: nulo, porque nunca tuvo una facultad anterior.
Facultad New: Salud.
Fecha de carga: 24 de febrero de 2030.

Ese campo de fecha de inserción es el que después te permite consultar solo los registros nuevos, sin reprocesar toda la historia.

Segunda carga: cuando el atributo cambia

Un mes después, en marzo, a Pepito lo cambian a la Facultad de Ingeniería. Aquí está el corazón de la tipo 3: no creas un registro nuevo ni sobrescribes el vigente perdiendo lo anterior. Actualizas las dos columnas.

El cruce se hace por el código del estudiante (Pepito Pérez sigue siendo el mismo, conserva ID 1) y la actualización queda así:

Facultad Old pasa a ser Salud (lo que antes estaba en new).
Facultad New pasa a ser Ingeniería.
Fecha de carga se actualiza a marzo.

Salud se desplaza a la columna old e Ingeniería ocupa new. Y aquí viene lo interesante: si Pepito vuelve a cambiar de facultad, el valor de Salud se pierde, porque solo conservas un nivel de historia.

¿Cuándo conviene usar una dimensión tipo 3? Cuando solo necesitas comparar el estado actual con el estado anterior de un atributo, sin necesidad de auditar toda la trazabilidad histórica.

¿Por qué importa la fecha de carga del registro?

Actualizar la fecha de inserción en cada cambio no es un detalle decorativo. Es lo que te permite hacer cargas incrementales en tu ETL.

En lugar de leer la dimensión completa cada vez que ejecutas el proceso, filtras por la fecha de la última carga y traes solo lo que cambió desde entonces. Eso reduce tiempo de procesamiento, costo de cómputo y carga sobre las fuentes.

¿Qué se pierde con una dimensión tipo 3? Pierdes los valores intermedios. Solo conservas el último valor anterior y el actual; cualquier cambio previo a esos dos queda fuera.

¿Cómo se vería la combinación de tipo 2 y tipo 3?

La tipo 2 guarda historia con registros nuevos. La tipo 3 guarda historia con columnas. ¿Qué pasa cuando juntas ambas estrategias en una misma dimensión, creando registros nuevos y, a la vez, columnas old y new dentro de cada registro?

Déjame en los comentarios cómo crees que funcionaría esa combinación.

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 3: historia en columnas

Progreso del curso

Introducción a BI y Data Warehouse

Modelos dimensionales

ETL para inserción en Data Warehouse

Cierre

Recursos

Recursos