Dimensiones lentamente cambiantes (SCD)

Un concepto importante en el diseño de los procesos de aprovisionamiento de un DWH es la estrategia de carga de las dimensiones. No es la primera vez que hablo sobre esto.

Trataré de explicar en este artículo cómo se deben cargar las dimensiones de un DWH. Conceptualmente, no es algo complejo en absoluto.

Se suele hablar de "dimensiones lentamente cambiantes" pero desde mi simplificador punto de vista esa es una expresión desafortunada. Todas las dimensiones son "lentamente cambiantes". Me explico:

• El término dimensiones lentamente cambiantes (SCD, por sus siglas en inglés: Slowly Changing Dimensions) hace referencia a que los datos de las dimensiones van cambiando poco a poco a lo largo del tiempo. No son incrementales como los "hechos". Cada día hay nuevas ventas o pedidos, sin embargo la categorización de los productos o clientes va cambiando poco a poco a lo largo del tiempo.
• Las dimensiones pueden ser estáticas como los meses, o cambiar muy muy lentamente (como el nombre de los municipios), o cambiar algo más rápidamente (como la edad de los clientes, o la clasificación de los productos en familias...). Entre dos días consecutivos, nuestro maestro de clientes puede crecer un poco, o puede aparecer un nuevo producto esporádicamente.
• En realidad, no sé cuales son las dimensiones rápidamente cambiantes. Dependerá, en todo caso, de la paciencia del observador el determinar si los cambios son más rápidos o más lentos.

Por lo tanto, a todos los efectos, hablar de estrategias SCD es hablar del modo de cargar dimensiones. Punto. Las dimensiones son así.

Si buscas por internet, verás que se habla hasta de seis tipos de estrategias de carga SCD. La Wikipedia también habla de un montón de tipos de carga SCD.

Desde un punto de vista práctico, sin embargo, solo dos tipos de carga SCD merecen nuestra atención. Las cargas tipo 1 y las cargas tipo 2. El resto solo tienen interés desde un punto de vista académico (o histórico). En la práctica, hoy en día, lo único que hemos de tener en cuenta a la hora de diseñar la estrategia de carga de una tabla de dimensión es si queremos guardar la historia de los cambios o no.

Dimensiones Tipo 1: Se sobrescriben los valores

Es el tipo de carga más básico y el más habitual. En este caso, se sobrescriben los valores existentes en el maestro con los nuevos valores.

Pensemos en el caso del pueblo burgalés de "Castrillo Mota de Judíos" que antes se llamaba "Castrillo Matajudíos". ¿Cómo debemos cargar la tabla de municipios de nuestro datawarehouse? ¿Es importante conocer la fecha en que ese pueblo cambio de nombre? ¿Cuando consultemos las ventas de los habitantes de Castrillo Mota de Judíos queremos que se incluyan también las ventas de cuando se llamaba Castrillo Matajudíos?

Evidentemente, no. No nos importa. Ese cambio de nombre será importante desde un punto de vista histórico y será relevante políticamente como muestra de integración y respeto cultural, etc. Sin embargo, en nuestro DWH de llamadas telefónicas, o de ventas, o de acciones comerciales... es un cambio irrelevante. No es necesario guardar esa historia. Nos basta con el nombre actual.

Para finalizar este tema, un apunte relevante: Que no nos interese guardar la historia de cambios no implica que no debamos mantener campos de auditoría. Todas las tablas de dimensión deben tener los campos de fecha de alta, fecha de baja y fecha de modificación. Es una buena práctica tener siempre estos campos de auditoría y nos será de utilidad para detectar incidencias... Recuerda:

Consejo gratis: Añade campos de auditoria en todas las tablas de tu DWH (fecha de alta, fecha de modificación y fecha de baja). #scd

— BI fácil (@bifacil) julio 3, 2015

Dimensiones Tipo 2: Se guarda la historia de cambios

En los casos que sí que nos interesa guardar la historia se utiliza la estrategia conocida como "SCD Tipo 2". En este caso, la tabla de dimensión incluye los campos de fecha inicio de vigencia y fecha fin de vigencia. Estas fechas nos permiten determinar en que estado estaba la dimensión en cualquier fecha del calendario.

Esta estrategia ETL de aprovisionamiento se utiliza, por ejemplo, para guardar la estructura comercial de una organización (quién es el responsable de un determinado producto o zona en un momento determinado...). También es habitual en otros escenarios: En un entorno CRM puede interesar conocer los cambios de domicilio de los clientes, o sus cambios de preferencias...

Siempre que nos interese guardar la historia de cambios utilizaremos fechas de vigencia (ya sea en el maestro principal o en una tabla auxiliar...).

En estos casos, tampoco hemos de olvidar los campos de auditoría (fecha de alta y fecha de modificación, al menos...).

Cómo se hace

Todo lo anterior está muy bien, ¿Pero cómo se hacen estas cargas? ¿Cuál es el código SQL o qué herramientas tenemos para aplicar correctamente estas estrategias de carga?

Lo comento otro día que hoy ya me he alargado suficiente. Suscríbete al blog si no quieres perdértelo... :-)