En los anteriores comentarios de esta serie sobre cómo construir un datawarehouse, explicaba las características de las dimensiones y las jerarquías. Sin embargo, estaba omitiendo un aspecto principal de estas tablas.
La información de las dimensiones no es estática, ya que puede modificarse en el operacional por diferentes motivos. Por ejemplo, puede corregirse la fecha de nacimiento de un cliente, o éste puede cambiar de ciudad, o una delegación puede asignarse a un delegado diferente, etc. ¿Cómo debe gestionarse esta información?
En primer lugar, debe tenerse en cuenta que el tratamiento que se realizará dependerá de cada dimensión y de las necesidades del negocio. Por ejemplo, si se actualiza la fecha de nacimiento de un cliente se puede asumir que ese cambio aplica a toda la historia de ese cliente. Sin embargo, existen casos donde la información dimensional histórica es importante. Considera estas dos situaciones:
Previsión de ventas: Para realizar una previsión de ventas para el próximo año, deberemos considerar las ventas históricas de las tiendas que actualmente tiene asignado cada delegado.
Análisis de márgenes: Si queremos analizar los descuentos que aplica cada delegado, deberemos considerar las ventas de aquellas tiendas que han tenido asignadas a lo largo del tiempo.
Por lo tanto, en este ejemplo, deberemos modelizar la información de tal modo que seamos capaces de conocer el "delegado actual" y el "delegado/s histórico/s".
Para conseguir este objetivo se introducen las "claves subrogadas", que son identificadores sin ningún significado específico para el negocio. Aunque existen diferentes maneras de modelizar estos datos, lo habitual es trabajar con las "fechas de vigencia". Por ejemplo, esta sería la estructura de la tabla de DELEGACIONES en el modelo relacional:
Ampliar imagen
Analizando cuidadosamente los valores de esta tabla, puede observarse que Pedro era el responsable de las delegaciones de Madrid y Barcelona, y que sus funciones fueron asumidas posteriormente por Juan y María. En el modelo dimensional, la tabla podría modelizarse de este modo:
El sistema funcionaría de manera similar con cualquier otra dimensión que pudiese tener la jerarquía de delegaciones, o cualquier otra jerarquía. Evidentemente, se trata de un tema complejo y que debe considerarse, o caeríamos de lleno en el error número 9:
Error 9: No afrontar el tratamiento de las dimensiones lentamente cambiantes
En cualquier definición del término datawarehouse se menciona que es un repositorio de información histórica, y con ello se pretende enfatizar que contiene:
- Historia de los hechos: En el operacional existe registro de los "hechos" del negocio de los últimos meses o de unos pocos años. Sin embargo, en el DWH se intenta que exista un histórico mucho mayor.
- Historia de las dimensiones: El operacional sólo suele guardar la situación actual de las dimensiones. En el DWH, sin embargo, debe mantenerse toda la evolución de los cambios dimensionales.
Pues bien, este segundo punto se suele olvidar (o ignorar) en algunas implantaciones de DWH por las siguientes razones:
- La "visión actual" parece suficiente. Al fin y al cabo, es lo que siempre se ha hecho en el sistema operacional.
- El usuario no siempre entiende la diferencia entre la "visión actual" y la "visión histórica". Y por lo tanto no sabe concretar sus necesidades reales.
- La gestión de cambios en las dimensiones nunca aparece en los requerimientos que motivaron el proyecto. De entrada, no parece importante (pero lo es).
No nos dejemos engañar. A pesar de todo esto, la gestión de dimensiones lentamente cambiantes es imprescindible. Personalmente, acostumbro a guardar toda la historia de las dimensiones en el modelo relacional (incluso algunos datos que inicialmente no parecen necesarios como la "fecha de nacimiento"). En el modelo dimensional, de entrada, sólo publico la visión actual, y sólo cuando lo solicita explícitamente el usuario de negocio, añado la visión histórica de esa dimensión.
