Cuando un dato cambia en tu base de datos transaccional y no necesitas conservar el valor anterior, la dimensión lentamente cambiante tipo 1 es la solución. Este enfoque sobrescribe el atributo modificado en tu data warehouse, dejando solo el valor más reciente disponible para análisis.

Es ideal para escenarios donde la trazabilidad histórica no aporta valor al negocio, como corregir errores tipográficos o actualizar datos que pierden relevancia con el tiempo.

¿Cómo funciona la dimensión tipo 1 en un caso real?

Imagina al estudiante Pepito Pérez, registrado inicialmente en la facultad de Mercadeo. Si más adelante cambia a Ingeniería, la dimensión tipo 1 simplemente reemplaza Mercadeo por Ingeniería. No hay registro del pasado, solo el presente.

El flujo desde la fuente hasta el data warehouse sigue tres momentos clave:

• La tabla transaccional (por ejemplo, TBL_estudiante) guarda el dato con su ID original, que suele ser alfanumérico tipo varchar.
• El proceso ETL identifica los registros nuevos o modificados usando campos de fecha de carga o actualización.
• La dimensión en el data warehouse recibe el dato ya transformado, con un ID propio numérico para optimizar búsquedas.

¿Qué es una dimensión lentamente cambiante tipo 1? Es un tipo de dimensión donde los atributos que cambian se sobrescriben directamente, sin conservar el valor anterior. Solo queda el dato más reciente.

¿Por qué crear un ID propio en la dimensión?

Las tablas transaccionales suelen tener identificadores con texto y números, lo que ralentiza las búsquedas y los joins contra la tabla de hechos. Por eso, en el modelo dimensional creamos un ID numérico propio y convertimos el identificador original en un código operativo dentro de la dimensión [02:00].

Esto te da dos ventajas concretas:

• Indexación más rápida al trabajar con enteros en lugar de varchar.
• Relaciones más eficientes entre dimensiones y la tabla de hechos.

Además, durante el ETL aplicas las reglas de negocio que necesites. Si te piden separar nombre y apellido en columnas distintas, ese trabajo ocurre en la transformación, no en la fuente.

¿Cómo identifico los registros nuevos para cargar?

Aquí es donde los campos de auditoría se vuelven tus mejores aliados. En la dimensión deberías agregar al menos tres atributos:

1. Fecha de carga del registro.
2. Fecha de última actualización.
3. Usuario o proceso que ejecutó la carga.

Con estos campos comparas contra la tabla transaccional y capturas únicamente lo que cambió. No necesitas reprocesar millones de filas cada vez que corres tu ETL, solo el delta.

¿Qué pasa si la tabla origen no tiene campo de fecha? En ese caso debes procesar toda la información completa. Por suerte, suelen ser tablas pequeñas donde el costo es bajo.

Ejemplo práctico de la primera carga

Supón que el 21 de febrero de 2030 a las 10:00 a.m. se crea el registro de Pepito Pérez en Mercadeo. Tu dimensión está vacía, así que el ETL detecta el registro nuevo, le asigna un ID propio (el máximo existente más uno) y carga todos los atributos.

Días después, el 30 de febrero de 2030, Pepito cambia a Ingeniería en el sistema transaccional. Cuando el ETL vuelve a correr, identifica que ya existe un registro para ese estudiante y actualiza la facultad sobrescribiendo Mercadeo por Ingeniería. La historia anterior desaparece.

¿Cuándo conviene usar tipo 1 y cuándo no?

La decisión depende de si el negocio necesita trazabilidad o no. Algunos ejemplos donde tipo 1 funciona bien:

• Corrección de errores de digitación en nombres o documentos.
• Cambios de domicilio en una dimensión de clientes, cuando no importa el histórico.
• Atributos que solo importan en su versión actual.

Pero hay casos donde sobrescribir es un error. Si tu negocio necesita auditar cambios de número telefónico, correos electrónicos o direcciones de un cliente a lo largo del tiempo, la tipo 1 se queda corta. Ahí entra la dimensión tipo 2, que sí almacena la historia completa.

¿Cuál es la diferencia entre dimensión tipo 1 y tipo 2? La tipo 1 sobrescribe el dato y pierde la historia. La tipo 2 crea un nuevo registro por cada cambio y conserva todas las versiones del atributo.

Buenas prácticas al implementar dimensiones tipo 1

Antes de poner en producción tu modelo, ten presente lo siguiente:

• Define con el negocio qué atributos realmente no necesitan historia.
• Crea siempre un ID numérico propio en la dimensión, distinto al código operativo.
• Agrega campos de auditoría desde el primer día, aunque parezcan opcionales.
• Apóyate en fechas de actualización del origen para procesar solo lo nuevo.

La próxima parada es la dimensión lentamente cambiante tipo 2, donde aprenderás a conservar la historia completa de los cambios. ¿Has tenido que decidir entre guardar o sobrescribir un atributo en tu modelo? Cuéntame en los comentarios cómo lo resolviste.