En el diseño de data warehouses el tratamiento de datos históricos es uno de los aspectos complejos y que admiten más variantes. No importa cuántas modificaciones en los diseños hayamos visto, siempre habrá un modelo de datos diferente que requiera de nuevas aproximaciones.
Uno de los escenarios más comunes es el tratamiento de miembros versionados (historificados) en dimensiones, las conocidas como Slowly Changing Dimensions (SCD). En los casos de Tipo 0 ó 1 no tenemos necesidad de preocuparnos por las diferentes versiones, simplemente no actualizaremos (en el caso de las Tipo 0) o haremos una actualización simple (en el caso de las Tipo 1)
Sin embargo, a partir del Tipo 2 tendremos que lidiar con historificación y versiones de nuestros miembros. Uno de los métodos más habituales es el de controlar dichas versiones con campos extra para marcar el inicio y el fin de la versión en el tiempo. Esto es, el rango de tiempo en el que una versión determinada del miembro fue válida.
En este caso nuestro objetivo es que los hechos estén asociados a la versión del miembro correspondiente. Para ello, el miembro que escojamos para asociar al hecho deberá ser aquel que esté entre las fechas de inicio y fin de cierta versión. Si la versión es la última disponible se suele dejar el campo de fecha de fin con el valor NULL para indicar que aún no ha llegado a su fin.
Hasta ahora, para tratar este escenario en Integration Services teníamos varias opciones:
- Usar un Lookup en modo partial caché o no caché y modificando la consulta
- Usar un Merge Join + un Conditional Split para elegir el miembro adecuado para cada línea de hechos
- Usar un Script Component que cargue la tabla de referencia (la dimensión) en memoria y evalúe la condición de pertenencia al rango temporal mediante código .Net
En estos posts excluiremos la opción número 3, dado que es mucho más compleja a nivel de desarrollo y queda fuera del ámbito de la serie.
Asumiendo que nuestras dimensiones se encuentran en una instancia de SQL Server, a partir de la versión SQL Server 2014 (codename Hekaton) podemos plantear una opción extra que alivia ciertas limitaciones de las anteriores: usar un Lookup en modo partial caché o no caché, modificando la consulta y usando una tabla en memoria para almacenar la dimensión.
Compararemos sus ventajas y desventajas, tanto a nivel de desarrollo como de rendimiento, y finalmente expondremos la alternativa que aparece en SQL Server 2014. Para todos los ejemplos usaremos como ejemplo Adventure Works DW 2012 con las modificaciones necesarias para aprovechar las funcionalidades extra
Lookup en modo partial o no-caché
Merge Join + Conditional Split
1 comment
Interesante articulo