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.