Los datos cambian con el paso del tiempo ¿Tus soluciones de BI reflejan estos cambios manteniendo diversas versiones de datos? Los orígenes de datos que solemos utilizar tienen una problemática que en la mayoría de los casos pasa desapercibida al usuario y al analista de negocio, pero que tiene una vital importancia a la hora de conocer la verdad de lo ocurrido históricamente en nuestro negocio:
“La mayoría de los sistemas tratan datos históricos con respecto a la realidad actual, no con respecto a la realidad que había en el momento en que se produjeron”
Versiones de datos: en búsqueda de la verdad
En este tema explicaremos con detalle este importante aspecto y ofreceremos diversas soluciones de diseño del modelo y de los procesos ETL (procesos de extracción, transformación y carga de datos) que darán solución a este problema, que consideramos de gran importancia y de necesaria solución para tener una información de calidad.
Veamos un ejemplo para entender lo anterior:
Tenemos datos de ventas almacenados en nuestro sistema de origen, entre otros y por simplificar (esto es más complejo en la realidad, aquí sólo contamos lo mínimo para entender la problemática) tenemos los datos de clientes almacenados en una tabla y los datos de ventas en otra, tal y como se muestra en la siguiente imagen, que representa la información tal y como estaba el 30/3/2008:
Si con esta información sacamos nuestro informe de ventas por estado civil, nos da el siguiente resultado:
Versiones de datos: encontrando las mentiras de los sistemas transaccionales
Va transcurriendo el tiempo, seguimos haciendo ventas a estos clientes. El 2/4/2008 viene Juan a nuestra tienda y, además de venderle productos nuevamente, nos comunica que se ha casado, y nosotros actualizamos su ficha de cliente:
Sigue transcurriendo el tiempo, seguimos vendiendo a Juan y Pepe, y a 5/5/2014, así quedan nuestras tablas de Ventas y Clientes:
Volvemos sacar un informe de ventas por estado civil, cuyo resultado es el siguiente:
¿Es correcto este informe?, ¿Qué ha pasado con las ventas que hicimos a Juan mientras estaba soltero?
Que desde el 2/4/2008 en que actualizamos los datos de Juan cambiando su estado civil de ‘Soltero’ a ‘Casado’ se han falseado todos los datos históricos de las ventas de Juan, apareciendo en todas ellas como ‘Casado’. Es decir, estamos tratando datos históricos teniendo en cuenta la realidad actual, no la que había cuando se produjeron los hechos.
Solucionando los errores de los sistemas transaccionales. La verdad es necesaria
A continuación vamos a aplicar a este mismo caso las técnicas estudiadas referentes a SCD (Slowly Changing Dimensions) para entender qué estructura de almacenamiento de datos deberíamos tener y cómo sería el proceso ETL que nos permitiese mantener los datos históricos sin que se vean afectados por cambios que se producen posteriormente y que no les deberían afectar.
Ahora veremos la información como estaba, teniendo en cuenta una nueva estructura (con más columnas en cada tabla de dimensiones) y procesos ETL que permitan mantener el historial tal y como estaba cuando se produjeron los hechos.
Información a 30/3/2008:
Si con esta información sacamos nuestro informe de ventas por estado civil, nos da el siguiente resultado:
Va transcurriendo el tiempo, seguimos haciendo ventas a estos clientes. El 2/4/2008 viene ‘Juan’ a nuestra tienda y, además de venderle productos nuevamente, nos comunica que se ha casado y nosotros actualizamos su ficha de cliente. Pero en esta ocasión cuando por la noche se ejecuta el proceso ETL que actualiza los datos del cliente en el Data Mart, se detecta el cambio y se genera una nueva versión de la ficha de Juan, y además, las ventas de ese día ya se asignan a la nueva versión:
Sigue transcurriendo el tiempo, seguimos vendiendo a Juan y Pepe, y a 5/5/2014, así quedan nuestras tablas de Ventas y Clientes:
Para las ventas que se han producido entre el 01/01/2003 y el 01/04/2008 el proceso ETL les asignó el código 1130 (esto quedó grabado en su momento y no se modifica con el paso del tiempo), y para las ventas desde el 02/04/2008 en adelante les asigna el código 1254. Por tanto, si consultamos por el cliente ‘Juan’, se suman todas, pero si consultamos por el estado civil cada una va al grupo que le corresponde.
En resumen, en la tabla de dimensiones aplicamos las técnicas SCD vistas en el post anterior y por cada cambio en un atributo del que queramos mantener su historial de cambios, generamos en el proceso ETL una nueva versión del registro, asignando una nueva clave subrogada, y controlamos el rango de fechas de vigencia de cada versión. Adicionalmente en el proceso ETL que carga los hechos, asignamos, en función de la fecha del hecho, la clave subrogada de la fila de la dimensión con la versión que corresponde a ese rango.
Volvemos sacar un informe de ventas por estado civil, cuyo resultado es el siguiente:
Ahora si han quedado las ventas de Juan asignadas correctamente al estado civil en el que se encontraba en el momento en que le realizamos cada una de las ventas.
Hasta aquí esta entrada, tras este ejemplo práctico espero que haya quedado más claro el concepto de Slow Changing Dimensions.
¿Quieres dominar el Modelado Dimensional? Consulta nuestros cursos de Power BI para todos los niveles y conviértete en un experto.
2 comments
Hola, Excelentes documentos que aclaran estos temas de BI. Tengo una pregunta, que implicaciones puede tener si se condensa en una sola tabla todas las dimensiones?, tener una dimension Generica en la cual una columna adicional indica a cual “dimension pertenece”.
Implicaciones malas, todas negativas. Mucho peor rendimiento, mucho más complicado localizar y clasificar los elementos.
Si todo fuese así, no habría técnicas de modelado dimensional ni nada más, iría todo a una sola tabla. Nunca hagas esto.
Te invito a que te descargues uno de mis libros que trata este tema:
https://www.solidq.com/es/producto/data-warehouse-data-marts-y-modelos-dimensionales/