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:

versiones de datos ejemplo 1

 

Si con esta información sacamos nuestro informe de ventas por estado civil, nos da el siguiente resultado:

versiones2

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:

versiones de datos ejemplo 2

Sigue transcurriendo el tiempo, seguimos vendiendo a Juan y Pepe, y a 5/5/2014, así quedan nuestras tablas de Ventas y Clientes:

versiones de datos ejemplo 3

 

Volvemos sacar un informe de ventas por estado civil, cuyo resultado es el siguiente:

versiones5

¿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:

solucion versiones de datos

Si con esta información sacamos nuestro informe de ventas por estado civil, nos da el siguiente resultado:

versiones7

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:

versiones8

Sigue transcurriendo el tiempo, seguimos vendiendo a Juan y Pepe, y a 5/5/2014, así quedan nuestras tablas de Ventas y Clientes:

versiones9

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:

versiones10

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.

0 Shares:
2 comments
  1. 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”.

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

You May Also Like
Arquitectura Power BI Premium
Leer más

Arquitecturas Power BI Premium

Repasamos las posibles arquitecturas que puede tomar un proyecto de BI, partiendo de un escenario de Power BI Premium y en el que principalmente el dato viene de orígenes ya estructurados, analizando las principales ventajas e inconvenientes de cada uno, para poder elegir siempre el mejor camino.