Dimensión tipo 1: sobrescribir sin guardar historia

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:007:13

Dimensión tipo 1: sobrescribir sin guardar historia

Curso de Data Warehousing y Modelado OLAP

Clase 9 de 26

Clase 9 / 26

Recursos

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:

Fecha de carga del registro.
Fecha de última actualización.
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.

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 1: sobrescribir sin guardar historia

Progreso del curso

Introducción a BI y Data Warehouse

Modelos dimensionales

ETL para inserción en Data Warehouse

Cierre

Recursos

Recursos