Documentando las tablas

14 10 2008

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 10 2008

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 10 2008

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 09 2008

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.





Quiero que los filtros solo muestren aquellas dimensiones con movimientos.

9 09 2008

image

Por: Diana Luz Vazquez

Sí usted se preguntaba como hacerle para que Artus solo muestre en los filtros aquellos valores de las dimensiones que tengan información en la tabla de hechos, esto es de gran utilidad.

Cuando incluyo un filtro de dimensión, lo que se espera es que las opciones de valores de esa dimensión que se muestran en el filtro, sean solamente aquéllas para las que el cubo tiene datos (sobre todo para dimensiones con gran cantidad de elementos). De manera que si tengo 100 Sucursales en el CAT de ésa dimensión pero en el cubo realmente solo hay datos para 30 Sucursales, sólo quiero ver esas 30 sucursales como opción de elementos para seleccionar en el combo del filtro.

MenuCubo
Esto lo he conseguido utilizando la opción de Artus Administrador de ‘Indicador con datos para todas las dimensiones’. Para ello, lo que hago es identificar un indicador base del cubo (de entre los principales) que sabemos que siempre tiene valor. Si es un cubo de Ventas, probablemente el indicador idóneo sea ‘ImporteVta’ y así… si el cubo está distribuido, o sea que no puedo identificar 1 indicador que sé que tendrá datos para todo el cubo, lo que hago es crear uno que sea una especie de ‘Contador de Registros’ (normalmente lo incluyo directamente en la estrella como un Identity).
Finalmente lo que hago es agregar ese indicador en la definición del cubo como ‘Indicador con datos para todas las dimensiones’ (te incluyo una imagen). Lo que ocurre es que internamente en el query MDX, se valida con base en ese indicador para llenar los valores de los filtros de dimensión. Resultado: Cuando sincronices un Filtro de Dimensión con los objetos del escenario, los combos sólo mostrarán elementos de dimensión válidos (para aquellos en los que el cubo tiene datos) =D

IndDatosTodasDim
Ése indicador no tiene que ser visible en Artus Desktop, pues es sólo para uso interno

No estoy segura si también funciona para ROLAP. Lo que sí puedo decirte es que para cubos de Analysis Services, funciona muy bien y no se afecta en nada al performance de las consultas que genera el escenario.

Si, esto también funciona para los cubos ROLAP.





Creando un agregado en Artus

8 09 2008

Los agregados son tablas con la información del cubo pre-sumarizada a diferentes niveles. De esta forma cuando usted lanza una consulta la herramienta OLAP determina que es más rápido obtener la información de las tablas de agregados y no del detalle, mejorando increíblemente el tiempo de respuesta (pasando las consultas de 30 mins a 2 o 3 segs algunas veces).

Si usted está trabajando en Artus con cubos propietarios o cubos ROLAP puede utilizar los agregados propietarios de Artus.

Entremos al Administrador de Artus; dé un clic al cubo sobre el que quiere crear un agregado.

agregados

Leer el resto de esta entrada »





Como definir un cubo

5 09 2008

image

Tal vez esta sea una de las partes más complicadas sobretodo cuando uno apenas comienza. Un método que nosotros usamos bastante seguido es utilizar una matriz, por ejemplo:

Indicador/ Dimensión Tienda Producto Vendedor Ciudad
Ventas $ x x x x
Venta # x x x x
Descuentos x x x x
Nómina x   x x
Headcount x   x x

El concepto es sencillo, ponemos los indicadores en renglones y las posibles dimensiones en columnas. De esta forma visualmente tenemos la foto global de los cubos que serán necesarios construir. Normalmente aquellos indicadores que tienen exactamente las mismas dimensiones van en el mismo cubo.

Es importante que para este método usemos la dimensionalidad que técnicamente puede existir y no la funcional. Por ejemplo, para el caso de la nómina si tomamos el headcount a nivel vendedor el valor en dicho cruce será de 1 (el headcount es el # de personas que trabajan en la empresa) por lo que pareciera fácil decir que no tiene sentido el cruce y no la pondríamos, pero técnicamente es posible así que la ponemos….es más fácil hacer el cubo y en Artus esconder la dimension vendedor para el headcount que hacer un cubo con diferente dimensionalidad entre los indicadores y meterse a empatar dimensiones

Entonces, terminada la matriz, solo ponga en el mismo cubo todos aquellos indicadores que comparten las dimensiones.





¿por qué no me salen todos los valores posibles en el filtro de dimensión?

1 09 2008

image

Varias veces un usuario nos ha preguntado por qué no salen todos los valores en los filtros de dimensión.

—..solo salen los clientes hasta la letra b, faltan muchos.

Las respuesta es bien simple. Artus está programado para cargar por defecto solo los primeros 1000 valores de una dimensión en el filtro. Usted puede cambiar a su entera conveniencia dicho comportamiento pero ese es el default.

Piense ahora en un cubo de supermercados con una dimensión producto compuesta por 100,000 productos diferentes, los productos actuales mas los productos que ya no se venden pero que tienen que estar ahí por propósitos de la historia. Dado que artus trataría llenar el filtro con todos los valores posibles se tardaría bastante en leer los 100,000 productos. Además una vez que lo llene imagínese lo difícil que es buscar un producto “Jitomates Saladet” en una lista que mide 1 pulgada de alta. Al mover la barra de scroll o desplazamiento 3 milímetros pasaría de la letra h a la m.

Esta es la razón por la que solo se cargan 1000 valores, performance. De nuevo, es más rápido cargar 1000 valores que 100,000; y al usuario le es más fácil buscar un valor en 1000 valores que entre 100,000

Para cambiar el # de valores que Artus carga por defecto, vaya a Artus Administrador, localice el cubo y haga doble click en la dimensión cuyo comportamiento desee cambiar

image

Le saldrá la pantalla anterior donde podrá cambiar el 1000 por el # que quiera.

Yo en lo personal no hago esto por que se me hace impráctico y lento. Prefiero resolverlo de una manera más sencilla, funcional y práctica: poniendo los filtros en cascada.

image

Añado varios filtros y los sincronizo entre ellos. De esta manera departamento sincroniza a familia y familia a producto. Así podré seleccionar un departamento y en las familias solo me aparecerán las categorías comprendidas en ese departamento. Cuando seleccione una categoría de productos entonces me saldrán los productos que pertenecen a dicha categoría. De esta manera los filtros se cargarán rápido dado que solo cargan 1000 valores, y será mucho más fácil de encontrar lo que estoy buscando.

Si no le parece el filtrado automático puede usar la opción aplicar filtros del enlazador

image

De esta manera hasta que le dé click al enlazador Artus aplicará los filtros.

Si todo lo anterior no es suficiente entonces utilice el filtro multinivel

image

Fácil ¿nó?





Noticias

30 07 2008

uanio

¡¡Hola!!

Ha sido un mes muy pesado y he tenido muy poco tiempo para escribir. Pero hoy les tengo noticias.

  • ¡¡Este blog cumple un año!!

Hace un año que empecé a escribir. El tiempo se ha pasado volando. Ha sido maravilloso poder compartir con todos ustedes en este espacio los temas que más les apasionan y que todos ocupamos. No siempre ha sido fácil, a veces he tenido días difíciles pero siempre ha sido hecho con gusto. Quiero agradecer a todos y cada uno de ustedes que con sus comentarios me han hecho seguir adelante. Mil gracias a todos, tenganme paciencia y prometo contestar los comentarios que están pendientes.

¿Y eso que tiene que ver? Tiene muchas implicaciones.

Finalmente se me concedió volver a la tierra que tanto extrañaba (o sea que soy Yucateco! ) así que los fines de semana me esperaran la playa Island with a palm tree, el sol Cool, unas cañas de pescar, las pirámides de chichen itza …je,je,je, es para darles envidia :D .

Ya, en serio, en serio: Ahora formo parte de BITAM LA y desde Yucatán estaré apoyando a nuestro canal de distribución y clientes en latinoamerica. No ha sido fácil, después de 13 años en BITAM Monterrey he dejado muchos amigos maravillosos que me han enseñado todo lo que sé. Muchos son lectores de este blog. Reciban todos ustedes mi agradecimiento por todos estos años que hemos compartido juntos, por las anécdotas, los buenos y momentos. Un abrazo a todos.

  • ¡¡visita a Brasil!!

La siguiente semana estaremos en Sao Paulo, Brasil. Es la primera etapa de mi nuevo rol el cual pinta ser emocionante y excitante. Les aseguro que pondré todo de mi parte para que dicho entrenamiento sea un éxito!! Así que si alguien se anima a tomar una cerveza en Sao Paulo por las tardes y platicar de cubos y BI ya saben.

Finalmente las disculpas, pero entenderán que ha sido un mes pesado, cambiarme de área, entregar los zapatos y cambiar de ciudad no ha sido fácil. Les reitero mis disculpas y se las pido de nuevo por anticipado ya que no creo poder escribir estos días… tengo que echarle muchas ganas a mi curso rápido de portugués.

un saludo.





¿Qué va en una dimensión?

30 06 2008

image

Varias veces me ha ocurrido que al trabajar con un data warehouse me encuentro con que en la dimensión producto viene todo lo imaginariamente posible. Por ejemplo, si estamos hablando que si la información viene de un sistema de dulcería, en el catálogo de productos vienen todos los productos vendibles en ella: paletas, dulces, refrescos, palomitas o rosetas de maíz, chocolates, etc.

… pero también vienen escobas, el detergente para lavar los pisos, el aceite para el maíz inflado, los vasos desechables y hasta el papel higiénico del baño.

¿Qué sucede? Pues que el sistema sirve tanto para vender que como sistema de inventarios o almacén. Así que el catálogo de producto almacena todo.

Pregunta ¿entonces en un modelo de ventas de dulcería, la dimensión de productos deberá tener todos estos artículos aunque no se vendan?

Yo creo que nó.

Creo que lo correcto es crear 2 dimensiones: productos y materias primas. Los 2 se llenarán a partir del único catálogo de productos. Debemos extraer solo aquello que tiene que ver con ventas y depositarlo en el modelo de ventas. Lo otro irá al modelo de inventario o almacén.

Recuerden que a la información de un data warehouse o cubo “se le habrán aplicado procesos de transformación y limpieza”.