Regla en IBM Planning Analytics: uso de elemento con formato tipo texto

Realizado por nuestros SmartB Gerardo Delgado

En IBM Planning Analytics, es posible utilizar elementos en formato de Tipo Texto. Para hacer uso del mismo, básicamente es necesario cumplir con dos (2) condiciones:

1.Al crear el Elemento en la dimensión, ubicar el atributo Formato y seleccionar la opción de Texto.

2.La dimensión donde este creado el Elemento tipo Texto, debe ser la última dimensión dentro del Cubo. En otras palabras, la última dimensión agregada al crear el cubo o al realizar un reordenamiento del mismo, asegurarse de colocar en la última posición la dimensión que contiene dicho elemento.

Las opciones por las cuales necesitaríamos incluir datos de tipo Texto o PickList dentro de un cubo son varias, en este caso particular, será expuesta la necesidad de crear una validación según la opción de Activación o Desactivación que contendrá nuestro elemento de tipo texto.

El cubo en cuestión cuenta con tres (3) dimensiones: Artículos, Periodos, Medidas. Donde dentro de la dimensión medida tenemos el elemento textual y es deseable poder activar o desactivar para un periodo y artículo particular, la sumatoria del mismo en alguna medida.

Por lo tanto para hacer uso del valor en una regla, sería necesario hacer un llamado al elemento:

[] =N: [‘Medidas’:’Estatus’]

Sin embargo, al ser un Elemento de tipo Texto, Planning Analytics no podrá devolvernos el valor. Por lo tanto es necesario hacer uso de la función DB para hacer un llamado a dicho elemento, inclusive dentro del mismo cubo. Por lo tanto la regla tendría la siguiente estructura:

[]=N: DB(‘nombre_del_cubo’, !Articulos, !Periodos, ‘Estatus’) ;

Si se quisiera compara dicho valor con alguna cadena especifica de texto, vale recordar que es necesario colocar el símbolo “@” antes del “=”. Por ejemplo:

[]=N: DB(‘nombre_del_cubo’, !Articulos, !Periodos, ‘Estatus’)@=’Activación’

Finalmente, se concluye con la recomendación de primero realizar el reordenamiento de las dimensiones del cubo para luego si hacer la inclusión del elemento textual en la última dimensión del mismo. Para la utilización en reportes de dicho campo/elemento, lo podremos visualizar sin problemas en una Lista.

Caso de Uso con Cognos TM1 de IBM : modelo y reporte para periodo actual (Parte 3)

Realizado por nuestro SmartB Gerardo Delgado

Reporte

Dentro de la herramienta Cognos TM1 de IBM, tenemos la posibilidad de crear filtros, asociados a una dimensión tiempo.

Este artículo permitirá dar una idea al usuario de como se establecen por defecto los elementos actuales (Año, Mes, etc) en los filtros.

Permitiendo visualizar los valores de los reportes en función de la fecha actual y así como el histórico en caso de que se requiera. Continue reading

Caso de Uso con Cognos TM1: modelo y reporte para periodo actual (Parte 2)

Realizado por nuestro SmartB Gerardo Delgado

Traspaso de Datos

En IBM Cognos TM1 una de las formas para la movilización de los datos entre elementos de una misma dimensión, es la generación de una regla utilizando la función DB.

Por lo tanto es necesario también la creación de su respectivo Feeder, ya que sin este podrán apreciarse en el cubo los valores, mas no en el reporte..

Esto fue explicado en el artículo anterior  Ver artículo. Continue reading

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.

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.