Como hemos comentado anteriormente, la información de los sistemas transaccionales puede ser modificada, aunque éstos sólo guardan la última versión. Por el contrario en un Data Warehouse, debemos reflejar ese historial de cambios para mostrar la verdad que había en el momento en que se produjeron los hechos. Slowly Changing Dimensions es la solución.
Veamos un ejemplo. Si en nuestro sistema transaccional asociamos cada venta al comercial que la realiza, y éste a su vez depende de un director de zona. En la tabla de ventas queda reflejado el comercial que realiza la venta, y en la tabla del empleado se almacena el director de zona del que depende, ya que tenemos los datos normalizados. ¿Qué ocurre si un comercial, por cualquier motivo, bien personal o bien laboral, le cambian la zona asignada?, ¿Y si además la nueva zona depende de otro director de zona?, ¿Y qué ocurre si sacamos un informe de ventas de ese nuevo director de zona? Pues que se le han trasladado a él todas las ventas que ha hecho este comercial durante toda su vida laboral en la empresa. Esto no es real, e imaginamos que su antiguo jefe de zona no estará en absoluto de acuerdo con estos informes de ventas, además de que no son ciertos. Cuando diseñamos un Data Warehouse debemos evitar esta problemática que tenemos en muchos sistemas transaccionales, donde sólo tenemos la versión actual de los datos. Para ello hay una serie de técnicas que nos permiten ir detectando los cambios que ocurren en el transaccional y dejándolos reflejados. Volviendo con el ejemplo anterior, en la tabla de dimensiones se deberían tener dos filas (o versiones) del empleado, una en la que se indica cuál es su jefe de zona antiguo, y durante qué periodo ha sido su jefe de zona, y otra que indica cuál es su jefe actual y desde cuándo. Adicionalmente, cada una de las ventas debe estar apuntando a la versión correcta del comercial, es decir, las ventas deben apuntar a la versión del comercial correspondiente al momento en que se produjeron, quedando así reflejado el jefe de zona y la zona que realmente tenía asignados en el momento de cada venta.
Por el contrario, hay otros casos en los que no necesito reflejar el historial, por ejemplo, si corrijo el nombre de dicho comercial porque lo tenía mal escrito, no quiero tener dos versiones de él, una con el nombre mal escrito y otra con él bien escrito, sino que quiero que se sobrescriba y siempre aparezca la versión actual que es donde está escrito correctamente.
Vistos estos ejemplos, pasemos a describir los diferentes tipos de Slowly Changing Dimensions más habituales:
- Slowly Changing Dimensions tipo 1 ? Sobrescritura: la nueva información sobrescribe a la antigua, no se guardan históricos y sólo se tiene la versión actual. Dicha sobre escritura se produce cuando se detecta algún error en los valores para corregirlo y mejorar la calidad del dato. Desde el punto de vista analítico sólo interesa la versión actual.
- Slowly Changing Dimensions tipo 2 ? Historial de cambios: refleja toda la información histórica. Por cada cambio que se produzca, se crea una nueva fila en la tabla de dimensiones con la fecha de inicio y una nueva clave subrogada, y se marca la fecha de fin de la versión anterior. Cada hecho que entra, debe comprobar a qué versión de la fila en la tabla de dimensiones se debe asociar (qué clave subrogada debe almacenar) en función de la fecha en la que se produzca.
Como hemos visto en los ejemplos, es habitual, que incluso en una misma tabla haya atributos de tipo 1 y de tipo 2, y deberemos dar el tratamiento adecuando a cada caso en nuestros procesos ETL.
El término Slowly Changing Dimension, SCD por sus siglas en inglés, suele aparecer traducido como “dimensiones lentamente cambiantes”, aunque en la ayuda de SQL Server (Books Online) aparece como “dimensiones de variación lenta”, téngalo en cuenta el lector si busca información en español sobre este término.
Recomiendo al lector que consulte la bibliografía de Ralph Kimball, especialmente el libro “The Data Warehouse Toolkit: The Complete Guide to Dimensional Modeling (second edition)” donde se exponen ampliamente estos conceptos y otros relacionados con el modelado dimensional, así como una amplia variedad de casos prácticos
Por último quiero concluir indicando los elementos que van a formar una tabla de dimensiones:
- Clave subrogada: Es la clave principal de la tabla de dimensiones. Nos permite identificar de forma única cada fila, suele ser un entero autoincremental. Es totalmente transparente al usuario de negocio, no la usará en ningún momento, ni tan siquiera tendrá conocimiento de su existencia.
- Clave de negocio: Es la clave con la que trabaja habitualmente el usuario, pero no puede ser la clave principal porque se pueden producir duplicidades.
- Atributos de la dimensión: serán cada una de las características que necesitemos almacenar. Lo habitual es que haya varias decenas de ellos, incluso que en algunos casos superen el centenar.
- Fecha de Inicio y Fecha de Fin: Servirán para conocer el periodo de vigencia de cada una de las versiones de los atributos.
Básicamente, una tabla de un sistema OLTP tiene una clave de negocio que suele ser además clave principal, y una serie de atributos. Cuando tenemos una tabla de dimensiones, la clave de negocio deja de ser la clave principal, aparece una nueva clave principal, que es la clave subrogada, y se agregan dos columnas (FechaInicio y FechaFin) para gestionar los periodos de vigencia de cada versión. Además es habitual que tenga un mayor número de atributos, que son la recopilación de los existentes en las diferentes fuentes de datos, y algunos adicionales que se calculan en los procesos ETL.
Volvamos a mostrar la figura de la tabla de la dimensión Producto donde se aprecia todo lo visto para tres productos. Vemos que los productos BK-M83B-44 y BK-M68S-38, han tenido dos versiones, dado que se cambiaron de categoría, así como las fechas en las que ha estado vigente cada una de ellas, mientras que el producto BK-R79Y-42 sólo tiene una versión. También podemos saber cuál es la versión actual de cada uno de ellos, ésta es la que la columna FechaFin vale NULL.
En la siguiente entrada, abordaremos diversas casuísticas de “versionado de datos” y volveremos sobre las estructuras de las tablas de hechos y de dimensiones, así como sobre el concepto de SCD (Slowly Changing Dimensions).
Si os gustan nuestros posts, desde SolidQ os invitamos a visitar nuestro blog o a suscribiros a nuestra newsletter para recibir las últimas novedades del sector en vuestro correo 🙂
