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.

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).

Proceso de Instalación de BigInsights versión 3.0.0.2 Parte I


v  

     Por Yosely Quintero

    Validación Pre-Instalación Parte I

Antes de iniciar el proceso de instalación se debe validar que el ambiente está listo para dicha instalación (Se debió culminar la guía de Pre-requisitos/tips para instalación de BigInights V3.0.0.2):
Ø  Ubíquese en la ruta donde tiene el archivo comprimido a instalar
Ø  Liste lo que tiene en la ruta para certificar que allí este el instalador
Ø  A continuación descomprima el  archivo .tar.gz
tar -xvf IS_BigIn_EE_3002_LNX64.tar.gz
Ø  Ubíquese en la carpeta bin de la ruta del archivo de instalación como se muestra en la siguiente imagen:
Ø  Seguidamente procedemos a ejecutar el comando bi-prechecker.shque permite validar todos los requisitos para la instalación. 
-Cree un archivo para que guarde el valor del FDQN del servidor.
   echo “bda.iicbang.ibm.com” > hostlist.txt
Luego ejecute el comando, donde especifique el tipo de instalación (en este caso ENTERPRISE) el archivo que apunte al hostname y el usuario.
./bi-prechecker.sh -m ENTERPRISE -f hostlist.txt -u root
 
Salida: Si todos los requisitos están en [OK] o el mensaje al final de la salida que indica que en el chequeo han pasado todos.
v  Instalación de BigInsights V3.0.0.2
Ø  Ubíquese en la carpeta de instalación
Ø  Corra el script para iniciar el proceso de instalación
               ./start.sh
                               
Ø  Luego vaya a la url que se le indica.
 
Ø  Acá se inicia el wizard de instalación, solo se siguen los siguientes pasos:
Ø  Indique el tipo de instalación 
Ø  Coloque el nombre del cluster y las rutas donde desea realizar la instalación. (En este caso se dejaron las rutas por defecto)
Ø  Seguidamente continúe con la seguridad Shell, para permitir la ejecución de los distintos scripts.Como ya hemos configurado el SSH, seleccionamos la opción use root user.
Continua en la Parte II la próxima semana…

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