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:

  1. Usar un Lookup en modo partial caché o no caché y modificando la consulta
  2. Usar un Merge Join + un Conditional Split para elegir el miembro adecuado para cada línea de hechos
  3. 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

0 Shares:
1 comment
Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

You May Also Like
SQL Server en Kubernetes (Parte 2)
Leer más

Matar al mensajero – SQL Server en Kubernetes (Parte 2)

En la primera parte de este artículo explicamos en qué consiste un SQL Server en contenedores y mostramos una forma sencilla de crear un entorno Kubernetes manejado. En esta segunda parte vamos a enfocarnos en los escenarios más críticos donde el uso de contenedores puede añadirnos latencias y esperas extras que acaben impactando en el rendimiento percibido por nuestros usuarios tras una migración de SQL Server a contenedores.
Leer más

Extraer datos de Twitter desde un servicio creado con Python en Visual Studio 2017

En el post que os traemos hoy vamos a ver como crear (con Visual studio 2017) mediante un script en python un programa que podremos ejecutar como un servicio de windows y que extraiga en tiempo real los twitts relacionados con determinadas palabras o hashtags, los almacene en una base de datos sql server, para luego explotarlos con powerbi. El objetivo de este script es el de conectar al api de streaming de twitter al que le pasaremos una lista de hashtags o terminos y nos devolverá de forma indefinida en tiempo real los twitts que se van publicando que contienen estos terminos.