Blog Haciendo cubos

Condividi contenuti Some Rights Reserved
Un blog de Business Intelligence sobre un tema que no podemos dejar de lado: Data Warehousing, Cubos, indicadores, dimensiones y bases de datos
Aggiornato: 4 giorni 20 ore fa

Usando indicadores de tipo fecha en Artus

16 Dicembre, 2008 - 02:06

DimensionFecha

A veces se requiere usar la fecha como una dimensión, si tenemos el campo en la tabla de hechos, a lo mejor es la fecha de la factura, se puede añadir como una dimensión en una tabla dinámica. Lo malo es que si el campo es tipo datetime como se vé en la imagen la tabla me muestra la parte hora.

Una posible solución sería tener el campo con la fecha de la factura con el tipo varchar y dejarlo ya formateado. Si sucede como siempre que no podemos modificar la tabla de hechos tal vez una vista sería apropiado, pero si no podemos crear vistas ¿entonces que se puede hacer?

Todos los componentes de Artus están hechos para mostrar números en las columnas de indicadores, entonces lo que podemos hacer es convertir la fecha a un número de esta manera la podemos mostrar. Podemos crear un indicador lógico con la siguiente fórmula:

max(year( t1.TheDate )*10000 + month( t1.TheDate )*100 + day( t1.TheDate ))

Como los indicadores siempre llevan una función de agregación entonces le añadimos el max.

DimensionFecha1

La fecha la vamos a convertir a un numero con el formato YYYYMMDD, esto es 4 digitos del año, 2 del mes y 2 del día. Así el 31 de diciembre del 2008 será 20081231

Ya está, lo único que tenemos que hacer es usar un formato del tipo ####-##-## para que dicho número nos lo despliegue en 3 partes.

DimensionFecha2

¡Listo! Para consultas complejas recuerde que tiene una función de agregacion por lo que nos dará una sola fecha, una manera de darle la vuelta sería añadir la columna fecha como dimension y esconderla para provocar que Artus la incluya en el group by.

      

Indicadores Filtrados en Artus

5 Dicembre, 2008 - 17:40

Muchas veces es más fácil crear un indicador filtrado en la metadata que usar el indicador base para pintar el escenario. Al usar el indicador base habrá que filtrarlo por la dimensión cada vez que se suelta en el escenario.

Piense en un cubo financiero con una dimension “Cuenta” y donde cada vez que quiere el Costo en un dashboard tiene que soltar el indicador y luego filtrarlo por las cuentas que corresponden al Costo. En vez de eso podemos usar los indicadores filtrados, así lo creamos una vez y lo usamos n veces.

Para crear un indicador filtrado entre a Artus Administrador, localize el cubo y luego cree un nuevo indicador (click en “nuevo”)

IndicadorFiltrado1

Luego seleccione el indicador (o los indicadores, puede ser una fórmula) que desea incluir en el indicador, en mi caso selecciono ventas.

IndicadorFiltrado2

Una vez que he seleccionado el indicador hay que dar click en filtrar

IndicadorFiltrado3

y seleccionar el filtro correspondiente. En mi caso quiero crear un indicador Ventas de Comida ( Food Sales) por lo que voy a seleccionar comida (Food). Listo! ahora solo hay que oprimir Ok para crear el indicador. No olvide incluir este indicador nuevo en los grupos de indicadores para que los usuarios tengan acceso a dicho indicador.

Desde Artus Designer solo tendremos que arrastrar y soltarlo y listo, tendremos las ventas de comida sobre nuestra tabla.

IndicadorFiltrado4

      

Llamando un componente de Artus por medio de una URL

24 Novembre, 2008 - 17:38

Tal vez quiera incluir un componente de Artus en algún portal o llamarlo desde Power Point.

Esto se puede hacer desde Generacion V, en Generación VI existe todavía pero ha sufrido algunos cambios. Es necesario extraer primero una dirección base y sobre esa base hacer las modificaciones pertinentes. Existe un documento que explica con detalle como modificar la URL para incluir parámetros,

Se puede enviar como parámetro un filtro de dimensión (para modificar a que pueda solo ver Monterrey por ejemplo) o cambiar el rango de fechas que el componente muestra.

Respecto a la seguridad aunque se puede enviar el usuario y password en la URL, se sugiere usar autentificacion (&SSO=1) de active directory de tal forma que el usuario y password no viajen con la URL.

      

Antes de comenzar un presupuesto

12 Novembre, 2008 - 15:48

PresupuestoHeaderPost

Antes de hacer una proyecto de presupuestos debe de estar consciente de todas las implicaciones. Hay varios temas que cuidar: negocio, logística y sistemas. Negocio se refiere al presupuesto en si, logística se refiere a como debo organizar los recursos en una corporación para lograr sacar adelante un presupuesto y sistemas el punto que tiene que ver con el software.

Antes de comenzar el presupuesto debe existir un análisis, guía y roadmap para lograr el objetivo. Para aquellas personas que estén planeando entrarle al tema del presupuesto (hacer una implementación de Ektos por ejemplo) he aquí una lista parcial de las preguntas que deben ser contestadas e incluidas en el análisis.

  • El flujo de la información. ¿Qué presupuesto se capturará primero?¿ventas, gastos? ¿Cuál es el orden que se seguirá? Es importante tener clara esta parte de esta manera usted puede programar dependencias en la herramienta y de esta manera no permitir si así lo desea capturar el presupuesto de costos si aún no ha terminado del de gastos. ¿Existe un responsable para cada presupuesto?
  • Los indicadores a capturar y los indicadores calculados. Es necesario saber todos los indicadores que participarán en el presupuesto, llámense ventas, costos, gastos, costos de materia prima de mano de obra, ventas en unidades, recetas de productos, etc. Usted puede así planear los diferentes cubos que requerirá para capturar los presupuestos.
  • Valores requeridos para los cálculos. ¿Requiere tener a la mano el tipo de cambio para calcular alguna conversión de moneda?¿requiere un factor global para el cálculo de algún impuesto?¿la tasa de inflación?
  • La granularidad de la información. Cuál es el grado de detalle al cual se capturara la información ¿a nivel cliente? ¿a nivel producto o departamento? ¿Habrá diferentes presupuestos que se capturarán a diferente nivel? ¿Las ventas se presupuestarán a nivel familia de productos pero requiere calcular costos a nivel producto?
  • La periodicidad de la información: ¿el presupuesto será a totales mensuales o será por semana? ¿Se usarán meses fiscales? ¿Habrá cruces posteriormente entre presupuestos a periodos diferentes, por ejemplo debe traducir el presupuesto mensual a valores semanales?
  • Seguridad o que es lo que puede cada persona ver. Hay que saber si una persona solo podrá capturar cierta información y que porción ¿es una zona? ¿es una región?¿puede capturar solo una parte pero puede ver todo?¿Hay personas que solo podrán consultar la información?
  • ¿Todas las personas tienen acceso al sistema?¿Hay alguien que de manera remota envié una hoja de cálculo con su presupuesto a la oficina central para ser concentrado ahí y cargado en el sistema?
  • ¿Cómo será el flujo de autorización de la información? ¿Quién le autorizará a quién? ¿Que pasará si la persona que debe autorizar un presupuesto en una fecha límite está de vacaciones, alguien puede tomar su lugar?
  • Que información requiere presentar para analizar el presupuesto. ¿Requiere hacer comparativos vs la historia? ¿está a la mano? ¿puede ser utilizada? ¿requiera algún comparativo contra alguna otra información? ¿cuales son los dashboards que debe construir para presentar la información?
  • ¿Se requiere trabajar con diferentes versiones del presupuesto? Debe estar prepara para saber si cuenta con el suficiente espacio para el manejo de varias versiones del presupuesto.

Por supuesto que hay mas ¿quién se apunta?

      

¿por qué los cubos se tardan cada día más y más en procesarse?

5 Novembre, 2008 - 18:40

Tortuga

Es un comentario frecuente “hace un año se tomaba una hora, hoy se tardan 2″ ¿Qué es lo que ha ocurrido? ¿Se puede optimizar?¿se puede bajar el tiempo?

Respuestas hay varias pero creo que las mas importantes son:

El volumen de información ha crecido y no tenemos una estrategia adecuada para refrescar el cubo. He visto MUCHAS veces cubos que se reprocesan completamente en su historia, así que cada mes el volumen a procesar se incrementa… Esto quiere decir que se borran todos los datos y se generan desde cero. Hay una gran oportunidad aquí. Los cubos o las herramientas no necesitan reprocesarse completamente, solo necesitan refrescar aquella parte que ya cambió. Si por ejemplo, las ventas solo están cambiando este mes entonces reprocesemos y refresquemos la información de únicamente este mes. Para esto se pueden usar varias estrategias como las particiones o manipulación de información en el ETL.

…y a veces hasta los 5 años de historia del data warehouse se generan de nuevo Hypnotized

Otra pudiera ser que está procesando únicamente el mes o día actual pero ahora hay mas transacciones. Pareciera obvio pero hay que decirlo. Hace dos años había información de 10 tiendas y ahora tenemos 20, hará una año se vendían 1000 dlls ahora se venden 2000. Mayor volumen implica mas trabajo, mas acceso a disco, etc. A veces sucede que el ancho de banda de la red no es suficiente para transferir la información a buen ritmo. Ha sucedido que existe un superserver, con un super site, pero el socket para el cable de red junto al servidor tiene 10 años y es de 10 MBITs.

Sucede.

      

Tablas con columnas agrupadas

30 Ottobre, 2008 - 15:22

En Artus Designer muchas veces queremos crear tablas donde la columnas de la tabla tengan un encabezado o header que las agrupe. 

GroupedTable23

Con Generación 6 ahora es mucho más sencillo, solo hay que editar las columnas y poner el texto por el que se quiere agrupar, para hacer esto solo hay que dar click derecho a una columna y seleccionar editar.

GroupedTable2

Y escribimos en el campo grupo el texto por el que las deseamos agrupar

GroupedTable3

Ahora solo hay que activar que nos muestre los grupos. Esto se hace en las propiedades de la tabla, en el sub menú de “mostrar” o “show” la opción”mostrar grupos de indicadores” o “show indicators group”.

GroupedTable4

Y listo, obtendremos la tabla con las columnas agrupadas.

GroupedTable1

      

A la búsqueda del producto del año

22 Ottobre, 2008 - 21:16

Generic_POY

La gente de SearchDataManagement.com esta a la búsqueda del producto del año.

Los productos que se nominen deben de caer en la siguientes categoría:

  • Data warehouses
  • Data integration platforms
  • Data analytics (BI, CPM, OLAP, data mining, etc.)
  • Data quality and stewardship
  • Master data management (MDM)/product information management (PIM)/customer data integration (CDI)

La fecha límite es Noviembre 7 del 2008.

Aquí les dejo la liga para aquellos que deseen nominar a Artus o algún producto de BITAM

Nomina un producto

      

Cómo especificar rangos de colores en un Mapa

20 Ottobre, 2008 - 23:07

MapaColores1

en Artus los Mapas pueden mostrarse con colores en base a un rango. En la imagen anterior se muestran en base a una alarma por ejemplo que las ventas hayan rebasado la cuota de ventas.

Hay otra manera de mostrarlos y es en base a la intensidad del indicador. Mientras mas alto sea el valor más oscuro será. Es sencillo, solo tenemos que editar las propiedades del mapa en Designer

MapaColores2

y debemos localizar la opción degradado. Solo necesitamos especificar cuantos intervalos vamos a mostrar en el mapa, cual es el color para el inicio y cual para el indicador más intenso. Yo voy a especificar 6 intervalos y que vaya del blanco al azul. El resultado es el siguiente

MapaColores3

Listo! Artus creara los 6 intervalos de valores asignándoles un apropiado color en base a la intensidad del rango.

Para devolverlo a su estado original solo hay que regresar el valor cero al numero de intervalos

      

¿Cómo convertir columnas a renglones?

17 Ottobre, 2008 - 16:57

Problema:

Tengo una tabla más o menos así…

TiendaID AñoFiscal Indicador Dia1 Dia2 … Dia365 1 2009 1 45 55   76 1 2009 1 42 53   72

Se requiere escribir un query con la sintaxis de Oracle que voltee los renglones a columnas (e.g. las ventas del día 3 al 21 del mes). Es Oracle 8i así que no se pueden usar instrucciones sofisticadas. Además se requiere que dicho query funcione con DB2 por lo que la sintaxis deberá ser lo más atea posible.

El rango de fechas es dinámico.

¿quién se apunta?

¿POR QUÉEE, POR QUÉEEE, POR QUÉE ME HACEN ESTO A MI? Crying

      

Documentando las tablas

15 Ottobre, 2008 - 00:40

A veces me es necesario documentar las tablas que una base de datos tiene. Cuando no hay nada sofisticado a la mano lo mejor es un query. Este query me ha sacado de muchos apuros.

Me da el detalle de las tablas existentes en una base de datos

select
    b.name as TableName,
    a.name as ColumnName,
    c.name as DataType,
    a.length as Length
from syscolumns a
join sysobjects b on b.id = a.id
join systypes c on c.xtype = a.xtype
where
    –b.name LIKE ‘SI_CONCEPTO%’and
    b.type = ‘U’
order by    
    b.name asc,
    a.colid asc

Se puede hacer más complejo para obtener más detalle. Si alguien tiene uno a la mano que pueda compartir se los agradecería!

      

Manejo de Presupuestos

8 Ottobre, 2008 - 14:49

FlujoPresupuestos

Muchas veces pareciera que los cubos se reducen a la explotación de la información. Estos últimos meses he participado en varios proyectos de manejo de presupuestos con cubos utilizando herramientas de BITAM para planeación financiera llamada Ektos.

Una de las 3 partes de Ektos, la parte de presupuestos Ektos Budget, trabaja con algo que en la industria de BI se llama “write back” o “escribir de vuelta” que no es otra cosa que escribir en el cubo (si, podemos hacer write back sobre los cubos).

Pero no es una simple escritura.

Imaginemos que trabajamos en una empresa muy grande cuya jerarquía de ventas es muy grande, hay direcciones, regiones, ciudades, cada ciudad tiene vendedores, hay productos, familias, clientes, tipos de clientes, etc.; y queremos hacer el presupuesto de cuanto vamos a vender el siguiente año.

Bueno, pues es un caos.

Lo que normalmente se hace es a cada vendedor pedirle su presupuesto de ventas para el siguiente año. Para hacer dicho presupuesto el vendedor requiere conocer la historia de como ha vendido para en base a eso hacer su presupuesto. Ejemplo: si el año pasado vendí 10,000 unidades este año venderé 15,000. Mi vendedor además debe de tomar en cuenta: la inflación, el incremento en la lista de precios, clientes nuevos, productos nuevos, el número que pensó el director y el dinero que mercadotecnia dijo que iba a vender.

Además los vendedores tienen que negociar con su jefe, los jefes de ciudad con el director regional, y los regionales con la dirección. Habrá que en este proceso bajar las venta de un producto, subírsela a otro, abrir rutas, obtener clientes nuevos y más.

Los niveles superiores consolidarán la información. Por si fuera poco, a la dirección general le interesa saber todo eso que van a vender el siguiente año cuento costará producirlo, que montos de inversión requiere y cuanto de margen dejará de rendimiento a la empresa.

Se requieren hacer costeos para obtener el margen en base a la mezcla de productos vendidos y saber cual será la mejor estrategia a seguir.

Y todo esto que a lo mejor les lleva un mes lo tienen que hacer de nuevo cuando a la dirección general recibe el consolidado de todo y sale con un «…nó, mejor hay que incrementar un 10% a esta línea de producto y bajale un 5% a esta otra…»

Bueno, pues todo esto es lo que hace Ektos Budget

El concepto es bién sencillo. Ektos puede, dado que trabaja con cubos, tomar la historia de un indicador (en este ejemplo: ventas), aplicarle la inflación, aplicar una lista de precios y % de incremento de ventas y usar eso como sugerido inicial para la captura de un  presupuesto. De esta forma el vendedor ya vería cuanto se le sugiere vender y el haría los ajustes finales al presupuesto. Se pueden establecer reglas complejas para los valores sugeridos.

Cuando el vendedor graba su presupuesto Ektos lo graba en el cubo por lo que en automático puedo, con una herramienta OLAP, hacer escenarios y análisis comparando presupuestos y reales.

La herramienta soporta flujos de autorización, se puede establecer quién le autoriza a quién, autorizaciones temporales, ciclos de espera (por si por ejemplo la gente de gastos debe de esperar a que ventas termine). Hemos hecho proyectos donde la gente captura de diferentes plantas en diferentes países de diferentes continentes con éxito.

Algo sumamente poderoso es la generación de valores colaterales en el grabado. Por ejemplo, al momento de grabar las ventas se puede ir y localizar la receta de un producto y en base a esa receta calcular el costo de materia prima y de mano de obra de dicho producto. Hemos usado en algunas partes esta característica para el calculo de impuestos de nómina, costos de materia prima, calculo de ingresos por intereses en la banca y más. Se pueden establecer libremente las fórmulas que se ocuparán para generar los valores colaterales.

Presupuestos

De esta forma podemos tener el siguiente flujo de trabajo. Se presupuestan las ventas, se genera un presupuesto de costos, se complementa con un presupuesto de gastos en donde algunos de los gastos se generan en base al volumen de venta ( eg. monto de fletes) y con toda la información anterior se puede obtener un margen operativo. Si el margen operativo no es correcto se puede reiniciar el ciclo de manera muy sencilla.

Esto sirve como entrada para la planeación financiera.

Esto es lo que es Ektos Budget, el primer eslabón de Ektos Planeación Financiera. Ahora de cuando en cuando verán algún post relacionado con esta herramienta.

      

Torturando datos

7 Ottobre, 2008 - 16:35

Hoy mientras leía Microsiervos me he encontrado con un excelente post titulado tortura numérica y una frase que vale millones:

Si torturas los datos lo suficiente, acabarán confesando cualquier cosa.

– Fred Menger, profesor de química e investigador

¿Qué seremos nosotros? ¿Inquisidores de la información? Devil

Seguramente con el trabajo de estas ultimas noches me iré al cielo.

Liga al post original

      

Creando mejores agregados para optimizar el performance de un cubo (o el Data Warehouse)

19 Settembre, 2008 - 22:38

image

Muchas veces he visto cubos saturados de agregados. Los agregados son totales pre-calculados de la información y sirven para acelerar el tiempo de respuesta de las consultas.

Un agregado:

  • Ocupa espacio
  • Toma tiempo de procesamiento el llenarlo.

Lo anterior quiere decir que los agregados no son gratis.

Puede ser que un mes de información en la tabla de hechos ocupe 100 megas y los agregados para ese mes 50 megas. Tal vez llenar la tabla de hechos tome 10 minutos pero calcular los agregados tome una hora.

Así que no hay que crear agregados por crearlos, hay que analizar y poner en la balanza cuales realmente traerán beneficios y el costo que implicarán mantenerlos.

Los motores de cubos normalmente tienen un "query advisor" o parecido que pueden ayudar a sugerir los agregados. Hagamos de cuenta que esto no existe ¿cuáles pueden ser buenos agregados?

Pensemos:

Un agregado es un total de la información, si tengo un cubo, estrella o copo de nieve de ventas con 540 millones de registros y mi compañía se divide en 4 regiones (Norteamérica, América Latina, Europa y Asia) y quiero un agregado por región lo que obtendremos es una tabla con 4 registros. 1 registro con el total para la zona norte, uno para la zona sur, uno para la zona este y otro para la oeste.

Norteamérica $2,345,000 América Latina $1,934,567 Europa $2,567,000 Asian $2,200,000

Si quiero saber cuánto vendió la zona norte solo se barren únicamente 4 registros y no los 54 millones. Ahora, normalmente las regiones agrupan paises. Si quiero saber cuánto vendimos se vendió en la Canadá que pertenece a la zona norte no podemos usar el agregado anterior.

Lo que necesitamos es un agregado por Ciudad.

EUA $1,250,000 Canada $1,095,000 Inglaterra $1,490,000 España $1,077,000 China $989,000 Japon $1,211,000

Suponiendo que tenemos ventas en 20 países nos quedaría una tabla con 20 registros. Pero ahora el problema es que tengo 2 agregados, uno para resolver las consultas por ciudad y uno para las de región.

La mayoría de las herramientas OLAP pueden deducir un total a partir de su nivel inmediato inferior de granularidad. Esto es, debiera ser posible calcular el total por región a partir de las ciudades lo cual implicaría que no sería necesario tener los 2 agregados si no solamente uno. El de menor nivel. Las herramientas OLAP resuelven esto usando las jerarquías de las dimensiones, esa es una de las razones de establecer las jerarquías en Oracle o Analysis Services por ejemplo.

Cuando me ahorro agregados me estoy ahorrando espacio y tiempo de procesamiento del agregado.

Regresando al ejemplo anterior que pasaría si en cada ciudad tengo 3 tiendas, ¿no sería conveniente mejor realizar el agregado a nivel tienda (ya que tendríamos 20 x 3 = 60 registros) y ahorrarnos 2 agregados para matar 3 consultas diferentes? 60 registros para una tabla aun es nada

Bueno, la cosa no es tan fácil, tener un agregado sin incluir la dimensión tiempo no sirve de nada. Si queremos un total por mes necesitamos multiplicar por 12 la cantidad de registros, pero si nuestros usuarios consultan el detalle a nivel diario entonces tal vez nos interese el detalle mensual, entonces necesitaríamos multiplicar por 365 los registros.

Usted tiene que poner en la balanza que cantidad de registros es el máximo óptimo en un agregado.

Cosas que nunca haga, (ok, tips):

  • Si tiene una tabla de hechos cuyo menor nivel de detalle es cliente, producto entonces no haga un agregado x la combinación de cliente + producto por que estaría obteniendo un agregado con la misma cantidad de registros que la tabla de hechos Doh
  • Nunca haga un agregado con todas las dimensiones. Obtendría una tabla más grande que la tabla de hechos.
  • Incluya en el agregado todos los campos de la tabla de hechos así cuando esté realizando una consulta no planeada el usuario tendrá el mismo performance al incluir en la consulta los diferentes indicadores que el cubo tiene.
  • Normalmente no se requieren agregados a nivel muy granular, a nadie le sirve para un análisis saber cuánto vendí en $ de cada uno de los 158 mil 289 productos en el catálogo. Es muy importante saber el detalle de algunos de ellos (los de mayor venta). Bastará hacer agregados a los niveles superiores. Al hacer dril down en alguna tienda, alguna familia de productos, alguna categoría, la consulta se irá acotando. Bastará con algunos índices adecuados en la tabla de hechos para saber cuánto se ha vendido en la tienda 25 de algún producto.
  • A veces se requieren agregados exactos.
  • No olvide que los agregados siguen siendo tablas por lo que también es válido indexarlas.

PD: Si el motor OLAP que está usando no soporta jerarquías puede usar entonces un agregado compuesto: Región+Ciudad+Tienda; el efecto es el mismo ya que de un agregado se puede calcular el total de ventas por cualquiera combinación de las 3 dimensiones.

      

Google