Slowly Changing Dimensions

Por Rut Almoguera 

                                           

En el post anterior definimos el concepto de “Surrogate Key”, y mencionamos cuáles son las ventajas de su uso.  En esta ocasión vamos a explicar el concepto de “Slowly Changing Dimension”,  para lo cual es necesario tener claro el concepto de “Surrogate Key”.

“Slowly Changing Dimensions” o “Dimensiones de cambio lento en el tiempo” (o también SCD por sus siglas en inglés) se refiere a que las dimensiones NO permanecen estáticas en el tiempo, sino que sus atributos sufren cambios, y con frecuencia se desea guardar un registro de esos cambios.

En un DataWarehouse es necesario aplicar el concepto de SCD para hacer seguimiento de los cambios en los atributos de dimensión, con el fin de informar el estado correcto de los datos en un momento determinado. Es por esto que el SCD se define por cada atributo de la dimensión.

Para poder comprender este concepto, veamos primero los tres primeros tipos de SCD que existen:

Tipo 0 (SCD0): El atributo o columna de la dimensión no permite que se le hagan actualizaciones. Por ejemplo, imaginemos que tenemos una dimensión CLIENTES, en donde tenemos un campo que representa el número de seguridad social de la persona (número de CI en Venezuela, o el SSN en USA), dicho atributo “jamás” debería poder ser cambiado, por lo tanto se definiría como SCD0.

Tipo 1(SCD1): El atributo o columna si puede cambiar en el tiempo, pero solo se desea conocer el último valor, sin guardar un histórico de sus cambios.  Un ejemplo de este comportamiento, podría ser el número telefónico de un cliente, en donde es poco probable que se requiera conocer los números anteriores para contactarlo.

Tipo 2(SCD2): El atributo o columna en la dimensión puede sufrir cambios y se desea guardar un histórico de dichos cambios. Pues sus cambios son relevantes para el análisis del negocio.  Por ejemplo imaginemos el precio de un producto, del cual se desea conocer su valor en un momento determinado del tiempo y no solo saber el precio actual.  Es en este caso, diremos que dicho atributo tiene SCD2.

Para comprender como influye el uso de los “Surrogate Key” en la definición de los SCD de los atributos de la dimensión, veamos cuales son las técnicas que se utilizan para implementarlos:

Implementación SCD0:  En este caso, simplemente cualquier cambio que sufra el campo en la tabla origen, será ignorado por el ETL, y no se actualizara en la dimensión.

Implementacion SCD1:  En este caso, simplemente se sobrescribe el valor viejo del atributo con el valor nuevo (UPDATE).

Implementacion SCD2:  En este caso, dado que se desea guardar la historia, el registro anterior en la dimensión debe ser marcado como “NO VIGENTE” (bien sea con un campo extra de vigencia o con dos campos para la fechas de inicio de vigencia del registro y otro para la fecha de fin del registro), e insertar un registro nuevo en la tabla de la dimensión, usando la misma clave del negocio, pero con un “Surrogate Key” nuevo, marcando dicho registro como “VIGENTE”.

Para comprender mejor este caso vamos a imaginarnos que tenemos una dimensión de los productos (DIM_PRODUCTO), la cual tiene el precio de los productos, y que se desea guardar el cambio histórico del precio de los mismos.

La tabla de PRODUCTOS el día 2 de agosto del 2015 tiene los siguientes registros:

Codigo_Producto	Descripcion	Precio
SANDDAMLUJ0012	Sandalia de Dama de Fiesta	20.000,00
ZAPCABACUER0018	Zapato Caballero Cuero Cerrados	35.000,00
ZAPDAMTAC0039	Zapato Dama Tacón Corrido	15.000,00

En este caso, como se tendrá que manejar SCD2 para el campo Precio, se agregaron en la dimensión  dos campos que representan la fecha del inicio de vigencia del registro y la fecha de fin de vigencia del registro, quedando la tabla DIM_PRODUCTO como se muestra a continuación:

SK_Producto	Codigo_Producto	Descripcion	Precio	Fecha_Inicio_Vigencia	Fecha_Fin_Vigencia
1	SANDDAMLUJ0012	Sandalia de Dama de Fiesta	20.000,00	2015-08-02
2	ZAPCABACUER0018	Zapato Caballero Cuero Cerrados	35.000,00	2015-08-02
3	ZAPDAMTAC0039	Zapato Dama Tacón Corrido	15.000,00	2015-08-02

Como se puede observar en el ejemplo, el campo Fecha_Fin_Vigencia está vacío, pues todos los precios están vigentes. Pero ahora asumamos que el precio del último artículo (ZAPDAMTAC0039 ) sube a 25.000,00 el día 17 de agosto del 2015.  En la tabla PRODUCTO en el origen tendríamos lo siguiente:

Codigo_Producto	Descripcion	Precio
SANDDAMLUJ0012	Sandalia de Dama de Fiesta	20.000,00
ZAPCABACUER0018	Zapato Caballero Cuero Cerrados	35.000,00
ZAPDAMTAC0039	Zapato Dama Tacón Corrido	25.000,00

Ahora en la tabla de la dimensión, como ha cambiado el precio de un producto, se debe agregar una fila nueva, pues el campo precio es SCD2.  La tabla de la dimensión quedara como se muestra a continuación:

SK_Producto	Codigo_Producto	Descripcion	Precio	Fecha_Inicio_Vigencia	Fecha_Fin_Vigencia
1	SANDDAMLUJ0012	Sandalia de Dama de Fiesta	20.000,00	2015-08-02
2	ZAPCABACUER0018	Zapato Caballero Cuero Cerrados	35.000,00	2015-08-02
3	ZAPDAMTAC0039	Zapato Dama Tacón Corrido	15.000,00	2015-08-02	2015-08-17
4	ZAPDAMTAC0039	Zapato Dama Tacón Corrido	25.000,00	2015-08-17

Como podemos notar, se ha insertado una fila nueva con un “Surrogate Key” nuevo (4), con el nuevo precio, y la fila anterior (que tiene el “Surrogate Key” 3) ha sido pasada a NO VIGENTE, pues se lleno el campo “Fecha_Fin_De_Vigencia” con la fecha del 17 de agosto del 2015, que fue cuando dicho registro termino su vigencia.

Es importante destacar que las herramientas de ETL registran correctamente los hechos (FACTS) tomando en cuenta solamente los registros vigentes acorde a la fecha del evento.