Cuando trabajamos el modelado dimensional de un Data Warehouse, debemos conocer y entender la naturaleza de la información dentro del contexto del proyecto y las necesidades del negocio para definir si ésta puede sobrescribirse o si debe guardar un registro histórico de todos sus cambios.
Por defecto, un sistema transaccional puede modificar la información. No obstante, únicamente conserva la última versión del dato afectado por dicha modificación. La manera de guardar en nuestro Data Warehouse un historial de todos los cambios que permitan explorar el valor específico de un dato en un momento dado es aplicando las metodologías Slowly Changing Dimensions (SCD).
Una Slowly Changing Dimension cambiará lentamente a lo largo del tiempo sin un patrón definido en lugar de en intervalos predeterminados.
Para entender la importancia de las SCD es mejor verlo con un ejemplo. Una empresa de venta de teléfonos móviles divide los dispositivos en 3 gamas: alta, media, básica. En este sector, la tecnología evoluciona rápido, por lo que un terminal que es de gama alta (por ejemplo), unos meses después puede considerarse de gama media con la llegada de nuevos dispositivos.
El sistema transaccional del ERP de la empresa guarda la información en una base de datos normalizada. Por un lado, tenemos la tabla “ventas”, donde se registra cada operación. Otra tabla “producto” contiene la información técnica de los móviles, incluyendo un campo que indica la gama.
El departamento de marketing, al cargar los datos en el Data Warehouse necesita conocer cuántos móviles se venden cada año de cada una de las gamas. ¿Qué ocurre cuando un móvil cambia de gama? Pues que al modificar este dato en la tabla producto, todas sus ventas pasadas también cambian a la nueva gama, falseando la información e imposibilitando saber con certeza este dato.
Una posible solución a la problemática anterior sería utilizar la metodología, añadiendo a la tabla producto dos campos de fecha que nos indiquen respectivamente la fecha de inicio y la fecha final de validez de un registro y añadiendo una nueva fila/versión del registro cada vez que se aplica algún cambio en la gama.
Siguiendo con el ejemplo, la tabla producto inicialmente tendría una estructura como esta:
Aplicando la solución arriba indicada, la nueva estructura de datos de la tabla producto sería la siguiente para el mismo teléfono móvil (SA-23) una vez se decide cambiar su gama:
Es importante señalar que también se ha añadido una nueva columna SK (clave subrogada), ya que la clave ID natural de producto que se utilizaba anteriormente dejará de ser única.
Gracias a esta solución, será posible conocer la gama de cada producto en el momento exacto de la venta.
Dependerá siempre de la naturaleza del dato. Si por ejemplo el dato que cambiamos es el atributo “Name” del teléfono móvil porque lo habíamos escrito incorrectamente no será necesario tener otra fila/versión con el nombre corregido ya que lo que queremos es que siempre aparezca bien, incluso en las ventas que se hicieron anteriormente.
Esto nos lleva a la existencia de diferentes tipos de SCD.
Existen diversos tipos de SCD dependiendo de la metodología utilizada en cada caso.
– Tipo 0. Los datos nunca cambian. Los hechos se asocian con el valor original del atributo.
– Tipo 1. Sobreescritura. Un nuevo valor del atributo sobrescribe un valor anterior. Los hechos se asocian con el valor actual del atributo. No existe un histórico de cambios en los datos.
Tipo 2. Añadir una nueva fila de dimensión con el nuevo valor del atributo. El método guarda un histórico de cada cambio, sobrescribiendo los atributos “fecha final” y “versión actual” de la versión anterior. Es también necesario añadir una clave subrogada. Los hechos se asocian con el valor activo del atributo en el momento en que sucede el hecho. Existen varias formas de implementar este tipo de SCD, siendo la más común y completa la siguiente:
Su principal desventaja es que la clave natural se repite por lo que es necesario eliminar la restricción de utilizar un valor único. Esto implica que es necesario añadir una clave subrogada.
– Tipo 3. Añadir una nueva columna para conservar únicamente el valor actual y el valor anterior del atributo. Cuando se detecta un cambio, el valor actual se mueve a la columna de valor anterior y el nuevo valor sobrescribe la columna del valor actual. Los hechos están asociados a los valores del atributo actual y anterior.
Su principal desventaja es que el número de estados está limitado al estado al actual y el anterior.
– Tipo 4. Utilizar una tabla mini-dimensional derivada de una tabla histórica principal. La tabla histórica contiene todos los atributos, incluyendo una “fecha inicial” y una clave subrogada. Se crea una nueva fila por cada versión. La tabla mini-dimensional contiene únicamente la versión más reciente de cada atributo con todas sus columnas, únicamente algunas columnas o columnas derivadas de estas. La tabla de hechos estárá asociada tanto con la tabla mini-dimensional como con la tabla histórica.
– Tipo 5. Es una combinación del tipo 1 y el tipo 4. En la práctica, consistiría en añadir una copia adicional de la tabla mini-dimensional relacionada en este caso directamente con la tabla histórica para no tener que pasar forzosamente por la tabla de hechos para realizar en ella una consulta.
– Tipo 6. Se trata de una combinación de los tipos 1, 2 y 3. Se utiliza la sobreescritura de atributos del tipo 1, las filas dimensionales adicionales del tipo 2 y la sobreescritura del “valor histórico” (o valor anterior) del tipo 3. El “valor histórico” coincidirá con el “valor actual”, por lo que se sobrescriben todos los estados previos. Los hechos están asociados con el valor activo del atributo en el momento en que sucede el hecho y con los valores actuales.
– Tipo 7. Siguiendo la funcionalidad del tipo 6, se utiliza una tabla adicional que contiene únicamente la versión actual para mejorar el rendimiento en el reporting. Los hechos están asociados tanto con el valor activo del atributo en el momento en que sucede el hecho como con los valores actuales.
Dependerá completamente de las necesidades del proyecto. Es más, en una misma tabla se pueden aplicar tipos de SCD diferentes para cada columna.
Por ejemplo, en una tabla donde tenemos entre otros datos la ciudad de un empleado y su fecha de nacimiento, podríamos aplicar un tipo 2 para la ciudad y un tipo 1 para la fecha de nacimiento.
Por lo tanto, necesitamos analizar y entender para cada dimensión:
– Qué atributos son constantes
– Qué atributos son variables
– En qué atributos deberíamos guardar un histórico completo de versiones o guardar únicamente la versión actual y la anterior.
También es interesante conocer el volumen de datos actual y el esperado en el futuro ya que puede ayudar en la elección del tipo de SCD.
No obstante, ante la duda y en ausencia de otras restricciones, mantener un histórico de versiones siempre será una solución más flexible y reversible.
Las metodologías Slowly Changing Dimensions son un imprescindible a la hora de planificar la carga de datos en el Data Warehouse. Pero también es imprescindible conocer las necesidades específicas del proyecto y de cada uno de los atributos para decidir cuándo se requiere su aplicación y el tipo adecuado de SCD.
Ahora ya conoces la razón de ser de las SCD y sus implicaciones. En un próximo artículo comentaremos cómo realizar su implantación a nivel práctico.
* Tu información será utilizada exclusivamente para contactarte en relación al Business Data Master. No hacemos spam ni compartimos datos con terceros.
