Cuando un dato cambia en tu sistema transaccional, no siempre necesitas conservar su historia. La dimensión lentamente cambiante tipo 1 (Slowly Changing Dimension Type 1) resuelve exactamente eso: reemplaza el valor anterior por el nuevo, manteniendo tu modelo dimensional limpio y actualizado sin acumular versiones innecesarias.
¿Cómo funciona el reemplazo de atributos en una dimensión tipo 1?
El principio es directo: cuando un atributo cambia en la base de datos transaccional, la dimensión correspondiente en el data warehouse se actualiza sobrescribiendo el valor antiguo. No se crea un registro nuevo ni se guarda la versión anterior.
El ejemplo clásico ilustra esto con claridad [0:20]:
- El estudiante Pepito Pérez pertenecía a la Facultad de Mercadeo.
- Posteriormente cambió a la Facultad de Ingeniería.
- En la dimensión de estudiante, el valor "Mercadeo" se reemplaza por "Ingeniería".
- A partir de ese momento, no existe rastro de que Pepito Pérez alguna vez perteneció a Mercadeo.
Esta decisión de diseño es intencional. Si tu negocio solo necesita conocer el estado actual de un atributo, la tipo 1 es la opción correcta.
¿Por qué crear un ID propio en la dimensión?
Uno de los puntos más relevantes del proceso de carga es la creación de un ID surrogate (identificador propio) dentro de la dimensión [1:30]. En los sistemas transaccionales, los identificadores suelen combinar números y texto, como códigos alfanuméricos. Esto genera problemas de rendimiento:
- Las búsquedas sobre campos varchar son más lentas.
- La indexación pierde eficiencia.
- Las relaciones entre la dimensión y la tabla de hechos se vuelven costosas.
Por eso, en el data warehouse se asigna un ID numérico incremental propio. El identificador original del sistema transaccional se conserva como código operativo, pero las relaciones internas del modelo dimensional funcionan con el nuevo ID numérico. Así, las consultas y los joins entre dimensiones y hechos son mucho más rápidos.
¿Qué papel juega el proceso ETL en la carga de dimensiones?
El proceso de ETL (Extract, Transform, Load) es el intermediario entre la fuente de datos transaccional y la dimensión en el data warehouse [2:10]. Durante la transformación se aplican las reglas de negocio definidas. Por ejemplo, si el negocio requiere separar un campo de nombre completo en nombre y apellido, esa lógica se ejecuta en la ETL antes de cargar la dimensión.
El flujo completo funciona así:
- Se identifican los registros nuevos en la tabla transaccional comparando fechas.
- Se extraen solo esos registros.
- Se transforman según las reglas de negocio.
- Se cargan en la dimensión, asignando el ID a partir del máximo existente.
- Si un registro ya existe y cambió algún atributo, se actualiza en lugar de insertarse.
¿Cuándo conviene usar tipo 1 en lugar de tipo 2?
La decisión depende del valor que tenga la historia de ese atributo para el negocio [4:05]. Una dimensión de clientes normalmente no necesita almacenar cada cambio de domicilio; basta con tener la dirección actual. Sin embargo, si tu negocio requiere la trazabilidad completa de cambios en correo electrónico o teléfono, entonces necesitas una dimensión tipo 2, que sí conserva el historial.
¿Qué son los campos de auditoría y por qué importan?
Agregar atributos de auditoría a la dimensión es una práctica recomendada [4:40]:
- Fecha de carga: indica cuándo se insertó el registro.
- Fecha de actualización: registra la última modificación.
- Usuario: identifica si la carga fue automática o manual.
Estos campos permiten comparar contra la tabla transaccional para detectar solo los registros nuevos o modificados. Esto evita tener que reprocesar toda la tabla en cada ejecución, lo cual es crítico cuando se trabaja con grandes volúmenes de datos. En tablas que no tienen campos de fecha, será necesario procesar toda la información, aunque generalmente son tablas pequeñas [5:20].
Si quieres profundizar en cómo la dimensión tipo 2 maneja el historial de cambios, comparte tus dudas y conversemos al respecto.
