martes, 24 de noviembre de 2015

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 Facts y 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 Fact una 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 Medidas en 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 Dimensiones y 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 Datawarehouse para 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 Fact de 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 Fact de 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.

miércoles, 18 de noviembre de 2015

Utilidad de atributos de dimensión en Cognos TM1

Por Edgar Barrios

En el artículo de hoy vamos a hablar sobre las capacidades que nos ofrecen los atributos que podemos definir en una dimensión dentro de Cognos TM1.

Los atributos permiten ampliar la información sobre los miembros existentes en una dimensión. En TM1 existen tres tipos de atributos Numérico, Texto y Alias. A continuación definimos cada uno de ellos:

·      Numérico: este tipo de atributos sólo admiten valores numéricos y pueden resultar de mucha utilidad al momento de realizar cálculos.

·   Texto: en este tipo de atributos podemos cargar información textual relacionada al miembro de la dimensión.

·         Alias: los atributos de este tipo permiten sustituir el nombre definido para el miembro por el valor del atributo: en expresiones, vistas de cubo y enlaces.

La creación de un atributo en Cognos TM1 es una tarea bastante sencilla, a continuación se mostrarán los pasos de creación a través de imágenes:

·         Clic derecho sobre el encabezado de la dimensión y seleccionar Añadir un nuevo atributo.





·         Se introduce el nombre y se selecciona el tipo del atributo (Cualquiera de los descritos anteriormente).

·         Finalmente se presiona el botón Aceptar.

De acuerdo a la definición de cada uno de los tipos de atributos existentes en TM1 podemos deducir la funcionalidad que nos ofrece cada uno de ellos. Para mostrarlo mejor, vamos a usar como ejemplo una dimensión llamada Productos, la cual almacena los productos que una empresa vende y una dimensión de Tiempo que guarda los meses del año a la cual llamaremos Meses.

Por si solos, estos elementos permiten conocer información sobre el negocio, por ejemplo en un cubo que guarda el monto generado por las ventas de un producto por mes, podremos conocer la cantidad de dinero mensual generada por los productos que vende nuestra empresa. Pero, ¿Qué ocurre si el negocio nos exige un nivel de información mayor?, por ejemplo, ¿en promedio, cual fue la cantidad de dinero que un producto generó por día?, ¿Cuál es la marca del producto?, y por último la información requiere ser mostrada en inglés y en español.

Los requerimientos antes descritos pueden ser resueltos con el uso de atributos, con este escenario podemos ver la aplicación de los tres tipos de atributos existentes en Cognos TM1. A continuación los detalles:

·         ¿En promedio, cual fue la cantidad de dinero que un producto generó por día?, para responder esta pregunta podemos definir un atributo de tipo Numérico en la dimensión Meses, el cual guardará la cantidad de días que tiene cada mes, por ejemplo, para el mes de Enero este atributo valdrá 31. Con este atributo podemos escribir una regla en Cognos TM1 en la que el monto total de ventas de un producto en un mes determinado sea divido entre el valor de este atributo para dicho mes. Este simple cálculo respondería la pregunta planteada.

·         ¿Cuál es la marca del producto?. Si deseamos consultar los productos de una marca especifica podemos crear un atributo de tipo Texto en el cual guardemos la marca del producto, con esto podemos realizar filtros sobre nuestra dimensión Productos para que esta sólo muestre aquellos productos de una determinada marca.

·         La información requiere ser mostrada en inglés y en español. Para resolver esto, podemos crear los elementos de la dimensión Productos, en español, por ejemplo: Zapatos y Camisas. De esta manera se satisface el 50% del requerimiento. Para tener la posibilidad de mostrar los productos tanto en inglés como en español podemos crear un atributo de tipo Alias que guarde el nombre del producto en inglés, por ejemplo: Shoes y Shirts. Esta configuración permitirá mostrar los productos en el idioma adecuado para el usuario, es decir, los usuarios de países latinos podrán visualizar el nombre del producto como Zapatos, mientras los usuarios de países de habla inglesa podrán ver el nombre de producto como Shoes. Para mostrar la información en Español no es necesario realizar nada, pero para mostrar los productos en inglés puede seguir los siguientes pasos:

o   Se hace clic derecho sobre el encabezado de la dimensión. Se selecciona Todas las opciones de visualización.




o   Se selecciona el alias a utilizar y se presiona Aceptar.
   

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

Por Yosely Quintero


Iniciamos los servicios de BigInsights,con el siguiente comando:

./start-all.sh


Salida:







Luego de iniciar su maquina pruebe que BigInsights este arriba, para ello coloque la siguiente url:
HostName:8080






 




 
Al ver esta pagina se certifica que la instalación se realizó exitosamente. 

Introducción a Procesos de Turbo Integrator: Origenes de Datos

Por Edgar Barrios

Los procesos de Turbo Integrator son usados principalmente con la finalidad de importar información dentro de modelos creados en Cognos TM1, bien sea para crear o actualizar cubos y dimensiones. En este artículo nos vamos a enfocar en la definición del origen de datos, que usaremos para actualizar nuestro modelo.

Los pasos en la creación de procesos son los siguientes:

·         Clic derecho, crear  nuevo proceso, dar nombre al proceso.


·       
      Existen tres pestañas que debemos completar en la creación de un proceso: Origen de Datos, Mapas y Avanzados.


·         
   Origen de Datos: en esta pestaña debemos indicar cuál es el origen de datos que utilizaremos para actualizar nuestro modelo. Los tipos disponibles son:

o   Archivo CSV.
o   Bases de Datos relacionales.
o   Otros cubos y vistas.
o   Microsoft Analysis Services.
o   SAP vía RFC.
o   IBM Cognos Packages.

Nota: En este artículo nos enfocaremos sólo en Archivos CSV y Bases de datos relacionales.

·         Lo primero que debemos hacer es indicar el tipo de origen de datos, para nuestro caso puede ser Archivo u ODBC.


·         
     Dependiendo del tipo de origen seleccionado en el paso anterior será necesario suministrar cierta información, por ejemplo para Archivo es necesario indicar la ruta en la que se encuentra el archivo. Para un ODBC se debe indicar el nombre del ODBC y las credenciales de usuario necesarias para conectarse a la base de datos requerida.


·        
                   Debemos tener claro que independientemente del tipo de origen de datos seleccionado turbo integrator manejará los datos de entrada como una tabla en un archivo plano. Por ejemplo:
o   Si la entrada es el siguiente archivo:



o   O si la entrada es un ODBC cuya consulta es la siguiente:


o   Nota: la consulta debe ser escrita en un lenguaje soportado por el manejador de bases de datos usado.


o  
Para Turbo Integrator los datos serán procesados de la siguiente manera, donde cada fila representa un registro a crear o actualizar dentro del modelo:



Con los pasos anteriormente descritos se estaría creando una dimensión sin jerarquías dentro de TM1, la cual contendría los siguientes elementos: Enero, Febrero y Marzo.

¿Qué ocurre si en lugar de una dimensión deseamos crear o actualizar los datos de un cubo? ¿Cambiarían los pasos antes descritos? La respuesta es No. Hasta este punto sólo hemos definido el origen de datos que utilizaremos en la importación, lo único que debe cambiar para que en lugar de gestionar dimensiones actualicemos un cubo es el contenido que incluyamos en el origen de datos. Por ejemplo:

·         El archivo de carga sería:





·        
La consulta SQL sería:






·         Turbo Integrator procesaría los datos de la siguiente manera: Imagen



Con esto finalizamos con la configuración requerida en la pestaña Orígenes de Datos, en futuros artículos le daremos continuidad a la creación de procesos,  explicando las tareas necesarias en las pestañas Mapas y Avanzado. La idea es comprender la manera en la cual trabajan los procesos de turbo integrator para poder crearlos y usarlos de manera efectiva.