Conservando la información histórica frente a los cambios en el data warehouse
Introducción
Es evidente que ninguna organización es un ente estático y, por lo tanto, su actividad no cesa de generar datos nuevos que deben incorporarse a su data warehouse para que este siga siendo una herramienta útil y válida. En esta entrada vamos a revisar las técnicas básicas para Gestionar los cambios en nuestro data warehouse.
Cuando gestionar los cambios en nuestro data warehouse
Para empezar, diremos que los cambios pueden darse en cualquiera de los dos tipos de tablas que contiene nuestro data warehouse; las tablas de hechos y las tablas de dimensiones. Sin embargo el tratamiento de los cambios en estas dos tablas será completamente diferente.
Cuando hay cambios en las tablas de hechos
Desde un punto de vista conceptual, los hechos producidos no deberían cambiar.
Una vez que se ha introducido un hecho en el data warehouse, adoptando una actitud purista, debería permanecer tal y como entró para siempre. Si alguien compró 100 cajas de tornillos o un cliente pidió 600 Kgs. de un producto, lo hizo. No importa si posteriormente los devolvió o modificó el pedido.
Cambios hay cambios en las tablas de dimensiones
En las tablas de dimensión, a diferencia de en las tablas de hechos, los cambios no son sólo admisibles sino deseables. La naturaleza descriptiva de los registros de estas tablas hace que deban reflejar lo más fielmente posible el contexto en el que se produjeron los hechos registrados en las tablas de hechos, ocurrieran cuando ocurrieran.
Para gestionar los cambios en las tablas de dimensiones de nuestro data warehouse emplearemos una serie de técnicas básicas que vamos a comentar aquí.
Cómo gestionar los cambios en nuestro data warehouse
En las tablas de hechos
Volvamos a los ejemplos de los tornillos y el pedido de producto misterioso
En el primer caso, la devolución es otro hecho a registrar independientemente de la compra y que, seguramente, se producirá algún tiempo después de que el primero haya entrado en el data warehouse.
En el segundo caso, el tratamiento que le demos dependerá del nivel de granularidad (detalle) que escojamos para registrar los pedidos.
Usando el nivel más detallado se debería registrar no los pedidos sino los diferentes estados del pedido hasta que se cierra. De esta manera no perdemos la información relativa a la los cambios de opinión o necesidades del cliente desde que se pone en contacto con nosotros hasta que cierra el pedido. Ninguno de esos estados debería ser cambiado.
Usando el nivel menos detallado se debería cargar sólo el último estado del pedido ya cerrado y, caso de ser cancelado, ocurre lo mismo que con las ventas; deberíamos registrar ese hecho de forma independiente.
Si gestionamos los hechos de otra forma, podríamos encontrar incoherencias entre la información que proporciona el data warehouse en diferentes momentos.
En las tablas de dimensión
En estas tablas empezaremos por clasificar sus atributos en tres tipos según el tratamiento que les queramos dar. No entraremos en técnicas más sofisticadas y complicadas y nos centraremos en las más elementales.
Clasificación de atributos para gestionar los cambios en nuestro data warehouse
De una forma básica podemos clasificar los atributos de una dimensión en tres tipos siempre según nuestras reglas de negocio:
- Tipo 0: En este tipo de atributos no se permiten cambios y una detección de alguno debería ser registrada y notificada a las personas interesadas. ej. el DNI, su fecha de nacimiento etc.
- Tipo 1: En este tipo de atributos los cambios simplemente sobrescriben los valores antiguos del atributo. Aquí la información histórica se pierde al no considerarse de interés el conservarla. ej. el número de teléfono.
- Tipo 2: En este tipo de atributos los cambios se reflejan en un nuevo registro para el miembro de la dimensión afectado mientras se conservan las versiones anteriores de dicho miembro para no perder la información histórica. ej. el domicilio de un cliente, el número de vehículos de una persona.
Mientras que los tipos 0 y 1 no requieren de técnica alguna, el tipo 2 nos exige modificar la estructura de la tabla de dimensiones para añadir unas columnas de control de versión así como incorporar a nuestro sistema ETL las rutinas necesarias para emplearlas.
Columna de clave sustituta
Esta columna pasa a ser la clave única de la tabla y sus valores serán las claves externas en las tablas de hechos relacionadas. Sustituye así a la clave natural o de negocio que identificaba a los miembros de la dimensión antes de incorporar la gestión de los atributos de tipo 2. Los valores de la clave sustituta deben estar gestionados por el sistema de BI y deberían ser anónimos. Una columna autonumérica es una elección idónea.
Columna de entrada en vigor del registro
Debe de ser una columna que contenga la fecha y hora en que se considera (siempre según nuestras reglas de negocio) que este registro es vigente en para nuestra organización. Nótese que no tiene por qué ser la fecha y hora del momento en que se graba el registro.
Columna de caducidad del registro
Debe de ser también una columna que contenga la fecha y hora en que se considera (otra vez según nuestras reglas de negocio) que este registro deja de estar en vigor para la organización. Esta caducidad puede no sólo ser provocada por un cambio en un atributo de tipo 2 sino porque el miembro de la dimensión ha dejado aparecer en las BBDD de producción por cualquier motivo. En caso de que el registro sea un registro vigente, el valor de esta columna no debería dejarse como NULL sino que debería grabarse una fecha acordada, lo bastante lejana en el futuro. La fecha máxima del sistema de BD es una buena elección.
Columna de vigencia
Esta columna sirve simplemente para indicar si el registro es el más actual de todos los de un miembro o no. Aunque es un simple indicador, no aconsejo usar valores como 0, 1 ó 0, -1. Es preferible usar lago más claro como S, N o Y, N o SI, NO.
Cambios en la carga de las tablas de hechos
La inclusión de la clave sustituta y el hecho de que pase a ser la nueva clave única de la tabla de dimensión ya no nos permite cargar las tablas de hechos con un simple JOIN entre los registros a introducir y los de la dimensión.
Ahora necesitaremos usar la clave natural o de negocio que identifica al miembro de la dimensión junto con la fecha en que se produjo el hecho. Para obtener el valor de clave sustituta que hará de clave externa para este hecho, seleccionaremos el registro que tenga igual clave natural y cuyo periodo de vigencia incluya la fecha del hecho.
Podéis encontrar información más detallada en los siguientes enlaces:
También podéis consultar nuestra oferta de cursos sobre data warehouse en la página de SQL Server y BI de Certia
¡Hasta la próxima!