Tips de Diseño de DWH- La Granularidad – Parte 1

 

 

Por nuestra Blogger SmartB: Rut Almoguera

Querido lector que te inicias en el diseño de DWHs, si crees que la granularidad es un término elegante para referirse a la cantidad de granos de arena que hay en una hermosa playa del Caribe… Entonces este post es para ti.
Cuando escuchamos la palabra granularidad normalmente lo asociamos a granos de arena, sin embargo en el caso del diseño de un DWH, este concepto se refiere a dos cosas.  Una es al nivel de detalle de la data que guardamos en una tabla de una dimensión, y otra al nivel de detalle que con el que registramos los hechos en una tabla Fact.
En este post hablaremos de la granularidad en las dimensiones.
La granularidad como instintivamente pensamos está asociada al grano, pero al grano de las dimensiones de un DWH. El grano de las dimensiones es el nivel de detalle a la que llegamos en la data que guardamos en la dimensión. Para entender mejor este concepto, usemos de ejemplo la dimensión Región.
Imaginemos por un momento que tenemos un DWH en donde registramos las ventas de unos almacenes que tienen presencia a nivel mundial.  En este DWH se requiere que se registren las regiones en donde se realizaron las ventas para poder analizar cómo fueron las ventas en cada una de ellas y tal vez analizar donde aplicar campañas estratégicas con ofertas por Región.
 
 
Supongamos que nuestra región de venta se registra en el transaccional a nivel de Municipio, es decir cada tienda que realiza una venta deja registrado en el sistema el Municipio de la misma.  En este caso en el sistema transaccional conocemos el detalle de las ventas con el Continente, el País, el Estado, la Ciudad y el Municipio, con lo cual tendríamos una jerarquía que llega hasta el detalle del Municipio:
 
Con esta jerarquía en la dimensión Región, tendríamos que la granularidad de dicha dimensión es hasta el nivel de Municipio.
Con gran frecuencia la granularidad de las dimensiones en el DWH es la que encontramos en el sistema transaccional, pero a veces ese nivel de detalle es excesivo para el DWH, y entonces debemos decidir cambiarlo por algo más resumido, para que sea útil para los análisis que se desean realizar.  Imaginemos por ejemplo que el detalle que deseamos conocer en el DWH es solo hasta el nivel de la Región.  En este caso la jerarquía que estaríamos usando dentro de nuestro DWH para la dimensión Región sería diferente al nivel de detalle que tenemos en el transaccional.  En este caso la jerarquía para dicha dimensión sería la siguiente:
 
Con esto la dimensión Región llegaría solo hasta la granularidad de Región y no del Municipio.
Mientras más detalle tiene una dimensión en el DWH más fino es el grano y diríamos que tiene una granularidad más fina, y mientras menos detalle, el grano es más grueso, y por lo tanto la granularidad es más gruesa.
Con frecuencia se recomienda que el grano de las dimensiones en el DWH sea el mismo que tenemos en el transaccional, pero sucede que en ocasiones demasiado detalle implica tablas Facts más grandes, y con eso puede causar que se degrade el tiempo de respuesta del DWH.  Además de esto, los DWHs guardan data histórica de varios años, lo que puede causar que el nivel de detalle se convierta en un problema para el mantenimiento de los mismos, pues tendríamos que decidir entre tener más detalle del transaccional en cada hecho guardado en la tabla Fact vs tener menos años de historia en el DWH.
Por esto al momento de diseñar las dimensiones y decidir el grano de las mismas debemos sopesar que es más importante para nuestro análisis: si el hecho de tener mayor detalle por hecho en la Fact y que se degrade el performance de respuesta del DWH con un nivel de detalle que a lo mejor no es requerido en los análisis de la empresa y que puede estar afectando el tamaño de la BD del DWH, o tener menor detalle que causaría que tuviésemos menos historia dentro del DWH.  Por esto es necesario que antes de diseñar estudiemos detenidamente los requerimientos de los usuarios, y veamos los Reportes y Dashboards que se desean que el DWH ayude a realizar, pues el DWH no está hecho para sustituir los reportes ya existentes en el sistema transaccional sino para complementarlo y responder a las preguntas de alto nivel que se hacen los directivos de la empresa con respecto al desempeño de la misma.
Así que querido lector, la próxima vez que estés diseñando un DWH es importante no solo decidir las dimensiones que participaran del mismo, sino también hay que prestar atención a la granularidad de las mismas, pues esto contribuirá con el éxito de nuestro diseño, adaptándose mejor a los análisis que se harán de los datos y también al mantenimiento de la BD que lo contiene.
En un próximo post hablaremos sobre la granularidad de las tablas Fact.

Tips de diseño de DWH: Bus Matrix

Por Rut Almoguera Poggi



Si te estás iniciando en el mundo de los Datawarehouses y la única “Matrix” que conoces es la película de los 90’s cuyo héroe es Neo, este post es para ti.
Aparte de la famosa película Matrix también existe otra Matrix que es igualmente famosa e importante, que es la Bus Matrix (o Matriz de Bus en español).  Esta es una de las más importante herramientas en el diseño de un Datawarehouse y que se usa universalmente al momento del levantamiento de los requerimientos. 
La Bus Matrix o Matriz de Bus es un instrumento de documentación de alcance, y de definición de la estructura de las tablas Fact.
Como sabemos, cuando estamos diseñando un Datawarehouse, debemos definir principalmente tres tipos de entes: las Facts , las Medidas que están en dichas Factsy las Dimensiones.  Una vez que hemos decidido cuales son las Dimensiones, las Medidas y las Facts tenemos que tener una manera de representar estos entes del diseño y las relaciones existentes entre ellos. Hacer por cada Factuna lista de las Dimensiones con las que se relaciona, seria tedioso e ilegible, no solo para un técnico, sino también para discutir y revisar el modelo con nuestros clientes.  Es aquí que surge la Matriz de Bus, que es una excelente y casi indispensable herramienta que nos ayuda a representar nuestro diseño.
Principalmente se encarga de mostrar cuales serán las medidas a implementar en cada Fact y como están relacionadas con las distintas Dimensiones del modelo.  Una vez que sabemos cuáles son las Dimensiones y las Facts que tendrá nuestro Datawarehouse, para construir la Matriz de Bus de cada Fact en nuestro modelo, debemos crear una matriz o tabla mostrando las Medidasen las filas y las Dimensiones en las columnas, y marcando la intersección existente entre ellas con una ‘x’.
Las Matrices de Bus son en general como se muestran a continuación:
 Nombre Fact
Dimensión 1
Dimensión 2
Dimensión 3
Dimensión M
Medida 1
X
X
X
X
Medida 2
X
X
X
Medida 3
X
X
X
X
X
Medida 4
X
X
Medida N
X
X
X
X
Y ud.  mi apreciado lector, seguramente vera esto y pensara que evidentemente es más sencillo visualmente, pero probablemente también se preguntara:  ¿Por qué debo colocar una equis (X) marcando las asociaciones entre las Dimensionesy las Medidas? ¿Acaso no están TODAS las Dimensiones relacionadas con TODAS las Medidas de una Fact específica? La respuesta a esta interrogante es: NO.
Para ilustrar esto, consideremos el siguiente ejemplo: Imaginemos que tenemos un cliente que es una Tienda, y que ellos desean crear un Datawarehousepara sus ventas.  Esta tienda tiene sucursales en todo el país, y también tiene un Site o Pagina Web por donde los clientes pueden hacer sus compras que recibirán en la dirección que deseen pagando un monto extra por transporte y entrega a domicilio.
En nuestro Datawarehouse tenemos que reflejar en este caso en una Fact de Ventas, cuándo se hace una venta, a que cliente se le realizo la venta, en qué fecha, cuál fue el articulo comprado, cuántos compro y cuál fue el vendedor que realizo la venta (en caso que aplique), teniendo por separado las ventas por internet de las ventas en las tiendas.
En este caso, tendríamos las Medidas: “Ventas Tienda” y “Ventas Internet” para la Factde Ventas.
Y las Dimensiones: Fecha, Cliente, Vendedor y Producto.
Como podemos notar, en este caso la medida “Ventas Tienda” tendrá un vendedor asociado, pero en el caso de la medida “Ventas Internet”, el vendedor NO existe, por lo tanto, la Matriz de Bus de la Factde Ventas que tendríamos para nuestro ejemplo sería la siguiente:
 Fact Ventas
Fecha
Cliente
Producto
Vendedor
Ventas Tienda
X
X
X
X
Ventas Internet
X
X
X
Como podemos ver, la Matriz de Bus en este caso nos sirvió para mostrar de una manera fácil y sencilla cuáles son nuestras Dimensiones, cuáles son nuestras Medidas y cuáles son las relaciones entre ellas.

Así que querido lector, adopta la Matriz de Bus como una herramienta para plasmar tu diseño y así poder mostrárselo a tu cliente, que te vera como a un héroe (igual que Neo en Matrix), por simplificarle el entendimiento del modelo del Datawarehouse para su negocio.

Tips de diseño de DWH: La Omnisciente Dimensión Time – Parte 2

Por Rut Almoguera Poggi 


Ahora que ya hemos visto en el post anterior lo imprescindible que es la dimensión Time, en esta entrega vamos a hablar sobre cuáles son las mejores prácticas para construirla.

La dimensión Time es especial pues no suele tener una fuente de donde llenarla, por lo que tenemos nosotros mismos que cargarla en el Datawarehouse.

A diferencia del resto de las tablas de dimensión, podemos construir la tabla Time por adelantado, cargándola con 5 o 10 años de registros cubriendo algunos años hacia atrás y/o hacia adelante (10 años = 3.650 registros, sí la granularidad es de día). 

Es recomendable que creemos un Store Procedure en la BD o algún programa para pre-cargarla.  Por lo general es común que se pre-carguen algunos años en la dimensión Time aunque también podría programarse el proceso de llenado de la dimensión Time para que revise al inicio del mismo si el año actual esta presenta ya en la data de la dimensión, y sino esta insertar el año actual completo, y en caso contrario, simplemente terminar.

Otra consideración importante al momento de crear la dimensión Time es revisar la granularidad de la misma.  Por ejemplo, si la dimensión Time por necesidades del negocio requiere tener un detalle más fino que el de día, por ejemplo, que necesitáramos guardar la hora exacta en la que sucede un evento, sería recomendable que la misma se partiera en dos dimensiones, una que contenga solo las fechas, y otra que contenga solo las horas del día, pues de lo contrario la dimensión terminaría siendo demasiado grande, y degradaría el performance de las consultas al Datawarehouse.

También al momento de diseñarla tenemos que considerar como serán los Rollups en las jerarquías de dicha dimensión.

Por ejemplo, si nuestra dimensión Time tiene una granularidad de día, y tiene una jerarquía como la siguiente:


No tendremos mayores problemas, con el Rollup.

Pero consideremos una jerarquía diferente en donde esté presente la Semana del año y el Mes como niveles de la jerarquía.  Algo como lo siguiente:


En este caso, si tendríamos un problema al hacer el Rollup, pues por lo general un mes NO termina o comienza en una semana completa, sino que puede hacerlo a la mitad de una semana, con lo cual la semana podría pertenecer a dos meses diferentes.  Veamos por ejemplo las fechas 31/03/2015 que fue martes,  y 01/04/2015 que fue miércoles:


Como podemos ver, ambas fechas están en la semana 14 del año, pero pertenecen a meses diferentes, por lo tanto NO podemos colocar el nivel Semana del Año en una jerarquía que también contenga el nivel Mes pues el resultado de hacer Rollup por dicha jerarquía podría arrojar valores incorrectos.  Si necesitamos tener los dos niveles, porque el cliente lo requiere para los reportes, se deberán tener dos jerarquías para dicha dimensión, una que contenga el Mes y otra que contenga la Semana del Año.

Otro tema importante a considerar cuando estamos diseñando una dimensión Time es sobre la decisión de cuál campo sería el Primary Key de la tabla.  Por lo general para el resto de las dimensiones lo recomendable es un usar un Surrogate Key, pero en el caso de la dimensión Time, esto no aplicaría, pues por lo general la data de las tablas Facts, suelen particionarse por la fecha, y por lo tanto, es buena idea tener como Primary Key de la dimensión Time un código inteligente que contenga el año, y nos permita particionar la Fact por la data de dicho campo.

Esto nos facilitaría poder “quitar” una partición de la tabla Fact, que corresponda a un año específico cuando ya la data relativa a ese año no sea de utilidad o se requiera consultarla con muy poca frecuencia, y el costo de mantenerla en el Datawarehouse sea mayor que los beneficios que obtendríamos en el performance de las consultas si la eliminamos.  Como por ejemplo podrían ser las ventas en una tabla Fact de Ventas que sean de 10 años atrás.
Lo más recomendable para usar como la clave de dicha dimensión es un código “inteligente” que contenga el año.  Por ejemplo si tenemos una dimensión Time cuya granularidad llega solo hasta el nivel de mes, podríamos crear el identificador del mes, concatenando el año con el mes:

YYYYMM: en donde YYYY es el año y MM el mes, y para este cálculo se debe multiplicar el año por 100 y sumarle el mes (getyear(Fecha)*100  + getmonth(Fecha)).

Si por ejemplo la granularidad de nuestra dimensión Time es de día.  Siguiendo con esta regla podríamos tener el siguiente Primary Key:

YYYYMMDD: en donde YYYY es el año, MM el mes y DD el día. Para el cálculo es necesario obtener el año, multiplicarlo por 10000, sumarle el mes multiplicado por 100 y sumarle el día (getyear(Fecha)*10000 + getmonth(Fecha)*100 + getday(Fecha)).

Así cuando se cree la tabla de la Fact particionada, se realizaría la partición por los valores del campo de la fecha, y todas las filas que correspondan a un año específico irían a una partición especial para ese año, y así será muy sencillo mantener en la tabla Fact solo la data relevante, pues, si no hacemos limpieza de la misma y dejamos que se llene de data muy vieja, el performance de los queries contra la Fact se degradaría notablemente.

Con esto terminamos la discusión sobre la dimensión Time, espero que consideres estos consejos cuando diseñes dicha dimensión.

Implementación de un DWH: creación de objetos

Por Edgar Barrios
 
Continuando con el ejemplo de implementación de un DWH, ahora vamos entrar en detalle con los objetos que se deben crear en la base de datos que contendrá el DWH. Para un mejor entendimiento de lo expuesto en este artículo, se recomienda ver primero el artículo Fuentes de datos y área de staging en un Data Warehouse (DWH).
 
Lo primero es identificar el tipo de modelo a implementar, de los cuales tenemos el modelo estrella y el modelo copo de nieve, para entender un poco de que se trata a continuación se presenta una breve definición y las diferencias existentes entre ellos:
 
       Estrella: Desnormaliza las dimensiones.
 
 
       Copo de nieve: Normaliza las dimensiones.
 
 
Tabla Comparativa Modelo Estrella Vs Modelo Copo de Nieve
 
 
Dadas las razones expuestas en la tabla anterior, lo más recomendable es siempre usar el modelo estrella.  Sin embargo, dependiendo de las necesidades el usuario puede usar el que desee.
 
Para nuestro ejemplo el modelo a utilizar es el modelo estrella, el cual se puede observar en la siguiente imagen:
 
A continuación se muestran las tablas que se deben crear:
 


Dim_Sales_Rep: en esta tabla se encuentra la data de los vendedores, y prácticamente es la misma información que tenemos en el Staging en la tabla STA_Sales_Rep, con la excepción del campo surrogate key (SK), que no es más que una clave numérica que se usará en esta tabla como el primary key.

 
Dim_Customer: en esta tabla se encuentra la data de los clientes, y es exactamente la misma data de la tabla STA_Customer con la excepción de que esta tabla tendrá el surrogate key como PK.
 
Dim_Date: en esta tabla se encuentra exactamente la misma data que en la tabla STA_Date del Staging.
 
Dim_Product: en esta tabla se encuentra la misma data que se encuentra en la tabla STA_Product, pero aquí existirá el campo surrogate key.
 
Fact_Sales: esta será la tabla de la fact, Aquí estarán los SKs de las tablas de dimensión, excepto la tabla Dim_Date que en su lugar tendrá un campo con la clave de la tabla Dim_Date y los campos de las medidas, que en este caso serán: las cantidades vendidas y el monto de la venta
 
Se deben crear las claves primarias para las tablas de dimensión y definir índices tanto para las tablas de dimensión como para las tablas fact.
Ya pudimos ver cuáles son las áreas involucradas en un DWH, ahora vamos ver a manera de resumen los pasos a seguir para ejecutar el proceso de Extracción, Transformación y Carga (ETL por sus siglas en inglés) del DWH:

       Crear las tablas en el área de Staging (planas y de dimensión) y en el DWH con sus respectivas primary keys. La tabla de la Fact en el DWH debe ser particionada. Generalmente dicho particionado se hace por el año.
       Crear los índices que puedan ser necesarios.
       Crear en la herramienta para desarrollar el ETL los procesos para cargar las tablas planas desde la fuente hasta el Staging. Es importante que a estas tablas se les haga un TRUNCATE antes de insertar la información que viene de la fuente.
       Es importante solo traerse las columnas y filas necesarias.
       Llenar en el ETL las tablas de las dimensiones en el Staging.  En  caso que alguno de los queries para el llenado de las dimensiones sea muy lento, crear los índices necesarios para optimizarlos. Es importante recordar que en estas tablas NO deben estar los surrogates keys.
       Llenar la tabla STA_Date, construyendo para esto o bien un Store Procedure o un desarrollo en el ETL que se encargue de llenar dicha tabla.
       Llenar las dimensiones en el DWH con un proceso del ETL usando como fuente las dimensiones ya calculadas en el Staging.  Estas tablas son casi iguales a las que están en el Staging con la excepción  del surrogate key, que debe ser el primary key de las dimensiones.
       Desarrollar los procesos para cargar las medidas en la fact en el ETL.  En caso de que alguno de los queries creados para llenar las medidas de la fact sea muy lento, crear los índices necesarios para optimizarlos.
       Crear un proceso automático que ejecute los procesos del ETL en el orden mencionado con la frecuencia requerida de carga (diario, mensual, etc).

Tips de diseño de DWH: La Omnisciente Dimensión Time – Parte 1

Por Rut Almoguera Poggi



Si estas iniciándote en el diseño de DWH hay una dimensión que deberías conocer pues te va a acompañar en todos los diseños que realices: La dimensión Time.
Voy a comenzar este post con una afirmación que  a lo mejor te va a asombrar: La dimensión Time es una dimensión usada en TODOS los Data Warehouses.
La primera pregunta que se suele hacerse alguien que esta iniciándose en el diseño de DWH es ¿Por qué es necesario utilizar una dimensión Time, si se puede registrar la fecha como un hecho o medición más de la Fact?.
La respuesta a esa pregunta la encontramos, al igual que las respuestas a todas las decisiones de diseño en un solo sitio: “Los requerimientos del Cliente”.  Revisando cuales son los requerimientos de nuestro cliente, cuales son las preguntas que el DWH necesita responder podremos determinar si necesitamos o no una dimensión Time.
La experiencia nos dice que los análisis que los clientes quieren hacer suelen ser cosas como: ver cuando sucedió un evento específico, o hacer comparaciones entre periodos de tiempo diferentes, por ejemplo en un DWH en donde se guarden las ventas, podríamos querer comparar las ventas del mes actual con las del mes anterior, o con este mismo mes pero el año anterior. O podría querer ver el comportamiento de las ventas en fechas especiales, como por ejemplo el último día del año o los días cercanos a las quincenas o al cobro de las utilidades.
Además con frecuencia los Clientes requieren de Cubos n-dimensionales que totalicen la data a través de las jerarquías de las dimensiones para poder tener respuestas a todos sus interrogantes,  siguiendo con nuestro ejemplo del DWH de ventas, podría querer ver las ventas diarias, pero también poder consultar las ventas del semestre actual o del año o del mes, por lo tanto con declarar la fecha simplemente como un atributo de la tabla Fact no nos basta, es necesario crear una dimensión.
Dicha dimensión Time, en ocasiones tiene una gran complejidad, conteniendo una gran cantidad de información, como por ejemplo los días feriados, el total de días hábiles del mes, el número de la semana del año a la que pertenece una fecha en específico, cual es el periodo fiscal especifico de nuestra empresa, tener un atributo que  indique si un día es o no el ultimo día del mes, etc.  Como podemos ver, estas no son cosas simples de determinar a simple vista o con cálculos sencillos y nos pueden ser muy útiles para hacer cálculos requeridos por el Cliente.
Dado que ya determinamos que la dimensión Time es imprescindible y que ella debe ser una tabla física dentro de nuestro DWH, nos enfrentamos a un segundo problema: ¿De dónde sacamos la data? Todas las demás dimensiones en un Data Warehouse tienen un origen de datos, bien sea una tabla, un archivo plano, etc.  Sin embargo, la dimensión Time, es una dimensión especial, pues de esta dimensión NUNCA se tiene una fuente.  Esto se debe a que los sistemas transaccionales no necesitan por lo general tener una tabla con la data de las fechas, pues en los sistemas OLTP no se realizan análisis de los datos, solo se registran los mismos, y es en el DWH en donde se realizaran los análisis de los comportamientos del negocio asociados a los periodos de tiempo.
 Dada esta limitación, de no contar con una fuente de datos para la construcción de la dimensión Time,  la misma debe ser llenada haciendo uso de un Store Procedure de BD,  una hoja de Excel con la cual podamos precargar un rango grande de fechas o algún otro programa que desarrollemos para tal fin.
Hoy en día, muchas herramientas de ETL te permiten crear una dimensión Time sin tener ninguna fuente de donde sacar los valores, pero en general es más recomendable que dicha dimensión la construyamos nosotros mismos, pues de esta manera podemos colocarle las particularidades necesarias para el diseño especifico que estemos realizando, como por ejemplo los periodos fiscales, o la cantidad de días hábiles acumulados al mes en una fecha específica.  Obviamente la complejidad o simplicidad de nuestra dimensión Time dependerá en gran medida de la granularidad que vaya a tener dicha dimensión y de los requerimientos de nuestro Cliente.

En la siguiente entrada de este post hablaremos un poco sobre cuáles son las recomendaciones a seguir cuando vamos a crear nuestra dimensión Time.

Slowly Changing Dimensions – Tipos 3. 4 y 6.

Rut Almoguera Poggi

                                              


En el post anterior hablamos de los SCD 0,1 y 2, en esto post veremos algunos otros que en varios casos son más complicados de implementar.
 
Además de los SCD 0, 1 y 2 que vimos en el post anterior, que son las más comunes y fáciles de implementar, existen otras alternativas interesantes sobre cómo se puede manejar el cambio en las dimensiones cuando se desea registrar en el DWH dichos cambios.  En esta ocasión nos encargaremos de definir los tipos 3, 4 y 6, los cuales guardan los cambios de las dimensiones, pero cada uno lo hace de una manera diferente. 
 
Tipo 3(SCD3): En este caso, se desea guardar la historia de los cambios, pero a diferencia del tipo 2, se guarda solamente un número finito y predeterminado de cambios, y no se agrega un registro nuevo en la tabla, sino que se tienen campos extra en la misma fila para guardar los valores anteriores.
 
Usualmente se implementa el tipo 3 si tenemos la necesidad de guardar unos pocos cambios, como por ejemplo, las direcciones de residencia de una persona, en donde podríamos tener tres campos dentro de la tabla para guardar los últimos tres sitios en donde la persona ha vivido.  En este caso, si la persona se vuelve a mudar, la dirección más antigua se pierde y se guardan solamente las tres últimas.
 
Sin embargo, es importante advertir que este método sube la complejidad del desarrollo del ETL, pero tiene la ventaja de no aumentar el tamaño de la tabla de la dimensión, pues en ocasiones ciertas tablas de dimensiones pueden ser demasiado grandes, como suelen ser,  por ejemplo, las tablas de clientes en un banco internacional, y si se desea guardar la historia de los cambios de algún atributo de la dimensión, se prefiere la complejidad antes que incrementar el tamaño de la tabla, pues esto podría degradar el performance de consulta al DWH.
 
Para ilustrar esto, , si tenemos la dimensión producto, y queremos guardar el histórico de 2 cambios de  precio, la tabla que tendríamos para dicha dimensión seria como se muestra a continuación:
 
SK_Producto
Codigo_Producto
Descripcion
Precio_actual
Precio_anterior
1
SANDDAMLUJ0012
Sandalia de Dama de Fiesta
20.000,00
2
ZAPCABACUER0018
Zapato Caballero Cuero Cerrados
35.000,00
3
ZAPDAMTAC0039
Zapato Dama Tacón Corrido
25.000,00
15.000,00
 
En dicha tabla podemos notar que el producto ZAPDAMTAC0039 tiene un precio actual de 25.000,00 y que anteriormente su precio era de 15.000,00.  Si ese mismo producto cambiara ahora su precio a 30.000,00, la tabla se mostraría como sigue:
 
SK_Producto
Codigo_Producto
Descripcion
Precio_actual
Precio_anterior
1
SANDDAMLUJ0012
Sandalia de Dama de Fiesta
20.000,00
2
ZAPCABACUER0018
Zapato Caballero Cuero Cerrados
35.000,00
3
ZAPDAMTAC0039
Zapato Dama Tacón Corrido
30.000,00
25.000,00
 
Nótese como en este caso, ya no tenemos manera de saber que dicho producto en algún momento tuvo un precio de 15.000,00, pero seguimos viendo los últimos dos cambios de precio sin agregar ninguna fila estra a la tabla.
 
Tipo 4 (SCD 4):  En este tipo, se guarda en la tabla original el último valor, pero se tiene una mini tabla de dimensión que guarda la historia de los cambios.  Y en este caso, la tabla Fact guarda referencia a las dos dimensiones, es decir a la que tiene el valor actual y a la que tiene la historia de los cambios.
 
En la dimensión que contiene el último valor se encuentran todos los campos de la dimensión, pero en la que tiene el histórico de cambios solo están el SK de ese registro, la clave natural y el campo que cambio, con otros dos campos de fecha que indican el inicio y el fin de la vigencia de dicho valor.  Con esto, se preserva la historia de cambios y no se afecta el performance de consulta, sin embargo sube la complejidad de los queries cuando se desea consultar la historia de los cambios de dicho campo.  Esto se suele usar cuando se tiene un campo que es extremadamente volátil y que sufre cambios con una frecuencia alta.
 
Siguiendo con nuestro ejemplo de la tabla de productos, en donde el producto ZAPDAMTAC0039, ha tenido tres precios distintos, que son 15.000, 25.000 y finalmente 30.000, tendríamos dos tablas, una con los productos con su precio actual:
SK_Producto
Codigo_Producto
Descripcion
Precio
1
SANDDAMLUJ0012
Sandalia de Dama de Fiesta
20.000,00
2
ZAPCABACUER0018
Zapato Caballero Cuero Cerrados
35.000,00
5
ZAPDAMTAC0039
Zapato Dama Tacón Corrido
30.000,00
Y otra tabla con el histórico de los cambios:
SK_Producto
Codigo_Producto
Precio
Fecha_Inicio_Vigencia
Fecha_Fin_Vigencia
3
ZAPDAMTAC0039
15.000,00
2015-08-02
2015-08-17
4
ZAPDAMTAC0039
25.000,00
2015-08-17
2015-09-20
Nótese como en la tabla del histórico de cambios solo están los campos pertinentes al cambio de precios, y los otros campos de la dimensión, como la descripción del producto no se encuentran en dicha tabla de históricos de precios.
Tipo 6 (SCD 6): Este tipo es una combinación del tipo 1 el tipo 2.  Se implementa igual que el tipo 2, agregando una fila nueva por cada cambio en el campo al que se le desea guardar el histórico de cambios, pero además de esto, se tiene una columna extra en donde se guarda cual es el valor actual.
 
Siguiendo con nuestro ejemplo de la dimensión producto, en donde el productoZAPDAMTAC0039  ha tenido tres precios que son 15.000, 25.000 y 30.000, tendríamos la tabla de productos como sigue:
 
                                                                                 
SK_Producto
Codigo_Producto
Descripcion
Precio
Fecha_Inicio_Vigencia
Fecha_Fin_Vigencia
Precio_actual
1
SANDDAMLUJ0012
Sandalia de Dama de Fiesta
20.000,00
2015-08-02
20.000,00
2
ZAPCABACUER0018
Zapato Caballero Cuero Cerrados
35.000,00
2015-08-02
35.000,00
3
ZAPDAMTAC0039
Zapato Dama Tacón Corrido
15.000,00
2015-08-02
2015-08-17
30.000,00
4
ZAPDAMTAC0039
Zapato Dama Tacón Corrido
25.000,00
2015-08-17
2015-09-20
30.000,00
5
ZAPDAMTAC0039
Zapato Dama Tacón Corrido
30.000,00
2015-09-20
30.000,00
Como podemos observar en nuestro ejemplo, todas las filas del producto ZAPDAMTAC0039, tienen un campo que indica cual es el valor vigente para el precio, que en este caso es 30.000,00.
 
Como podemos ver existen muchas propuestas para manejar el cambio en las dimensiones, cual elijamos implementar, dependerá del caso particular que estemos modelando.

Áreas involucradas en la construcción de un Data Warehouse (DWH)

Por Édgar Barrios 

La construcción de un Data Warehouse siempre es una tarea exigente, por esta razón es muy importante tener bien definido el diseño que se utilizará para la implementación. En este artículo vamos a hablar un poco de cuáles son las áreas (Bases de Datos) que siempre se deben tomar en cuenta al momento de construir un DWH.


·         Fuentes de datos: son todos aquellos repositorios de datos donde se encuentra almacenada la información que maneja la empresa sobre sus operaciones. Puede ser de diversos tipos, por ejemplo, archivos planos, bases de datos, etc.
·         Área de Staging: es una base de datos que debe ser creada con la finalidad de ser un área de aterrizaje de datos sobre la cual se importa toda la información extraída de los orígenes de datos y se llevan a cabo las tareas de transformación de la data. En esta área se debería crear una réplica del modelo de Base de Datos existente en los orígenes de datos, consiguiendo con esto independizar el proceso de transformación y carga de datos, de los sistemas operacionales de la empresa. De igual modo también se deberían crear las tablas definidas como tablas de dimensión, las cuales serán alimentadas por la réplica de las fuentes de datos implementada en esta área.
·         Área de Data Warehouse: Es el área en la cual se carga toda la información en el Data Warehouse diseñado. Aquí deben existir las tablas de dimensión y las tablas facts que fueron definidas. El proceso consiste en comenzar cargando la información en las dimensiones y luego cargar la tabla fact. La fuente de datos para esta área debería ser el área de Staging.
Tener clara la función que cumple cada una de estas áreas es un buen comienzo para poder llevar a cabo la implementación de un DWH de manera exitosa. En futuros artículos hablaremos de forma más detallada acerca de cada una de ellas, donde se profundizará el tema con el apoyo de ejemplos prácticos.