Dimensiones de cambio lento: sobrescribir, añadir una fila o añadir una columna

Qué es

Los atributos de dimensión cambian de forma lenta e irregular, y un almacén de datos debe decidir si un hecho registrado el año pasado debe reportarse con el valor de atributo del año pasado o con el de hoy. Las páginas de técnicas del Kimball Group (citadas) definen las respuestas básicas. Tipo 1: el valor antiguo del atributo en la fila de dimensión se sobrescribe con el nuevo valor, de modo que el atributo siempre refleja la asignación más reciente y el historial se destruye; los agregados construidos sobre el valor antiguo deben recalcularse. Tipo 2: se añade una fila de dimensión nueva con los valores actualizados y una nueva clave primaria subrogada, a la que las filas de hechos hacen referencia desde el momento del cambio en adelante; la página exige al menos tres columnas adicionales: una fecha de vigencia de la fila, una fecha de expiración de la fila y un indicador de fila actual. El tipo 3 añade un atributo que conserva el valor antiguo mientras se sobrescribe el atributo principal, de modo que los reportes pueden agruparse por el valor actual o por el anterior; la página describe la técnica como usada con relativa poca frecuencia. Los snapshots de dbt (citados) implementan el tipo 2 sobre tablas de origen mutables, añadiendo dbt_valid_from y dbt_valid_to a cada versión; una estrategia de marca de tiempo detecta el cambio mediante una columna updated_at, una estrategia de comprobación lo hace comparando una lista de columnas, y una configuración decide si las filas eliminadas en el origen se ignoran, se invalidan o se registran como una versión nueva.

Por qué importa

Sin una política, el mismo reporte da respuestas distintas según cuándo se ejecute, y nadie puede decir si «ventas por región» usa la región del cliente en el momento de la compra o la actual. El tipo 2 responde a ambas preguntas, pero multiplica las filas de dimensión y exige que cada carga de hechos busque la clave subrogada vigente en el momento del evento.

Cómo aplicarlo

• Decidir por atributo, no por tabla: las correcciones de errores de entrada de datos son de tipo 1; los cambios del mundo real que los reportes deben atribuir históricamente son de tipo 2.
• Mantener la clave natural en cada fila de tipo 2 e indexar (clave natural, valid_from) para las consultas «a fecha de»; usar un centinela abierto o NULL para la fila actual de forma consistente y documentar cuál se usa.
• Ejecutar los snapshots con una frecuencia al menos igual a la del período de reporte más fino; los cambios entre dos snapshots colapsan en una sola versión.
• Cargar los hechos uniendo por la clave natural con el rango de vigencia que contiene la marca de tiempo del evento, no con la fila actual.

Trampas

Los cambios de dimensión que llegan tarde exigen volver a asignar la clave a los hechos ya cargados. El tipo 2 en atributos de alta rotación (último inicio de sesión) hace que la dimensión crezca más que los hechos; conviene mover esos atributos a la tabla de hechos o a una minidimensión aparte.