Hace unos meses tuve ocasión de asistir a una conferencia de Isak Andic, uno de los emprendedores más interesantes en nuestro país. En aquella ocasión, la charla resultó sumamente agradable, y nos explicó las características que debería tener un buen emprendedor.

Hoy he encontrado en Youtube una conferencia similar donde Isak explica brevemente su trayectoria, y donde también enumera los "secretos" de su éxito...

Más o menos a la mitad del vídeo, enumera estos “secretos”, y llama la atención que las cualidades o circunstancias que justifican su éxito no son cinco o seis, sino que son 32...

• Involucrar a todos en el proyecto
• Estar predispuesto a cambios constantes
• Escuchar
• Ser constante
• Disciplina
• Mejora continua cada día, cada año, y un gran cambio cada 5 años.
• Arriesgar
• Presión
• Honestidad, confianza
• Rapidez en la toma de decisiones, agilidad
• Pasión
• Ilusión
• Rodearse de un buen equipo
• Sentido común
• Echarle horas
• Suerte
• Buen humor
• Mantenerse en forma
• Equilibro familia, trabajo
• Tener información
• Viajar. Salir del despacho.
• Tener claras las prioridades
• Objetivos claros
• Comunicación
• Curiosidad
• Decirlo en público
• Revisar la estrategia continuamente
• Organigrama
• Crear ambiente agradable. Promoción interna.
• Ser distinto a los demás
• Cuestionárselo todo
• Obsesión

¿Y por qué cuento esto en este blog de Business Intelligence en español?

Si repasamos la lista, se entenderá. Ninguna enumeración debería tener más de 10 elementos (el listín telefónico es la única excepción), por lo que resulta conveniente agrupar estas 32 claves en 5 grandes grupos:

• Equipo (personas, involucración, organigrama, promoción, etc.).
• Cualidades personales (sentido común, buen humor, honestidad, ejercicio,...)
• Espíritu emprendedor (predisposición a cambios, riesgo, ilusión, curiosidad,...)
• Trabajo (constancia, disciplina, horas, viajes, ...)
• Inteligencia de negocio (información, toma de decisiones, estrategia, prioridades, ...)

Y algo de suerte.

Entre estas claves del éxito, evidentemente, aparece escondido el Business Intelligence, y realmente es una de las claves de éxito empresarial. Hoy más que nunca, es necesario disponer de información, tomar decisiones con rapidez, hacer un seguimiento continuo de la estrategia y los objetivos empresariales…

Quod erat demonstrandum

Un saludo,

BI fácil

Sólo los más observadores habrán visto que entre los links de la izquieda hay una novedad: Billage. Se trata de una comunidad de interesados en el Business Intelligence promovida por la UOC. No tengo claro si la participación está reservada a alumnos y ex-alumnos de la UOC, o si por el contrario está abierta a toda la comunidad BI. En cualquier caso, me parece una iniciativa excelente.

La Universistat Oberta de Catalunya (UOC) ofrece masters y postgrados en el ámbito BI, y creo que tienen bastante éxito. Yo mismo realicé uno de estos posgrados hace unos años, y fue una experiencia enriquecedora. Algún día me gustaría terminar el master. Aclaro -para los más mal pensados- que no cobro nada por escribir esto (y aclaro también que es una desgracia que así sea, y que no me importaría que me regalasen la matrícula para el próximo curso, o por lo menos unas vacaciones en Hawaii...).

Billage se acaba de fundar y, actualmente, está bastante despoblado. Tiene un par de blogs, y unos foros con poca participación. Habrá que ver cómo evoluciona. Al contar con el apoyo de la UOC, creo que tiene posibilidades de convertirse en un foro de referencia importante.

Un saludo,

Bi fácil

PD: Quería poner el link al master de BI pero no he sido capaz de encontrarlo. ¿Es que ya no se hace? ¿O sólo se publicita durante el periodo de matriculación?

En ocasiones, desde IT tenemos la tentación de atribuir los fracasos en los proyectos BI a razones estrictamente extra-tecnológicas (gestión de proyecto, indefinición de requerimientos, falta de apoyo de Dirección, etc.). Personalmente, niego la mayor. Es decir, comparto que es necesaria una implicación de los usuarios de negocio y un apoyo decidido de la compañía, pero considero que existen una serie de barreras, muchas de ellas tecnológicas, que dificultan la adopción de soluciones BI y que terminan generando desconfianza, incredulidad, y en definitiva, falta de apoyo a este tipo de proyectos.

En uno de los blogs de Billage, he encontrado una muy interesante reflexión sobre las barreras existentes en la adopción de soluciones Business Intelligence. Se citan las siguientes:

Barreras tecnológicas

• Facilidad de uso para los usuarios.
• Falta de estándares del mercado.
• Problemas de integración y compatibilidad.
• No integración con soluciones de BPM.
• Problemas de escalabilidad.
• Problemas de calidad de datos.

Barreras económicas

• ROI no claro.
• Las licencias de software son caras.
• Coste de formación.
• Coste del equipo de Business Intelligence.

Barreras culturales

• No existe una cultura de la información.
• No se comprende en qué consiste Business Intelligence.

Me gusta y comparto esta lista de barreras. Aunque el autor del blog no ordena estas barreras por su importancia, ni indica cuales considera que son las determiantes, se observa que ganan por goleada las barreras tecnológicas. Por algo será.

Creo que los proveedores de software deberían reflexionar sobre estas cuestiones. Falta innovación en este sector. Faltan alternativas. Faltan proveedores que hagan cosquillas a los grandes dinosaurios del mercado Business Intelligence.

En el mercado de las soluciones BI existen tres tipos de aplicaciones principales:

• Reporting
• Análisis OLAP
• Cuadros de mando

Existe cierta confusión entre estos conceptos, y en demasiadas ocasiones los "expertos" tenemos dificultades en explicar qué solución necesita la empresa cliente y por qué. Los requerimientos suelen ser similares... Todos los usuarios quieren acceder a la información corporativa, de una manera rápida y sencilla, y por supuesto con datos fiables, exactos y actualizados. La respuesta del "experto" es siempre la misma:

"Usted necesita una herramienta de Business Intelligence"

"Sí, ¿Pero cuál?"

Para responder a esta pregunta, intentaré explicar las características fundamentales de estos tres tipos de soluciones.

• Reporting: Los informes que se generan son básicamente estáticos, y su mayor dinamismo suele ser la existencia de “filtros dinámicos”, que permiten ejecutar el informe de manera parametrizada. El usuario avanzado tiene capacidad de realizar informes ad-hoc. Otra característica fundamental es la posibilidad de incluir varias tablas o gráficos, es decir, el informe tiene distintos “bloques de información”.
• Análisis OLAP: Son las tablas dinámicas de Excel de toda la vida, que han evolucionado hasta convertirse en “cubos”. Tanto las tablas dinámicas como los cubos proporcionan una manera muy fácil y dinámica de navegar por la información. Invariablemente, estas soluciones sólo permiten navegar por un único “bloque de información” (tabla o gráfico). El usuario tiene total autonomía para navegar libremente por el cubo.
• Cuadros de mando. Se trata de unos informes predefinidos, y muy visuales, con los que cualquier persona (habitualmente cargos con responsabilidad) puede hacer el seguimiento de los indicadores de su interés sin ningún tipo de conocimiento técnico. Actualmente, el desarrollo de estos cuadros de mando es costoso, se requieren conocimientos técnicos, y es necesario un importante análisis funcional para definir la navegabilidad deseada. Son, por lo tanto, informes dinámicos, pero predefinidos.

Teniendo en cuenta estas consideraciones, es fácil ver las diferencias entre los diferentes productos (y entre las diferentes necesidades de los usuarios), y permite entender el confuso catálogo de productos que ofrecen todos los fabricantes de software. Estas reflexiones se pueden formular con las tres ecuaciones fundamentales del Business Intelligence del s.XX:

• Reporting = Informe estático
• Análisis OLAP = Tabla dinámica
• Cuadro de mando = Informe dinámico predefinido

Este enfoque me gusta porque permite explicar muchas cosas del mundo actual, pero deja demasiadas preguntas sin respuesta:

• ¿Por qué un informe no puede ser tan dinámico y visual cómo un cuadro de mando?
• ¿Por qué no puedo navagar por varias tablas dinámicas simultáneamente?
• ¿Por qué el jefe no puede crear su propio cuadro de mando?
• ¿Por qué seguimos utilizando masivamente el Excel cuando llevamos 15 años tratando de sustituirlo con inversiones en BI?

El futuro pasa sin duda por la unificación de estas tres fuerzas en una única ecuación fundamental del Business Intelligence. Esta unificación, en mi opinión, y teniendo en cuenta la situación en el mercado Business Intelligence 2009, sólo puede venir de fuera de los agentes principales del mercado.

Hace unos días explicaba la inauguración del wikidata, y el éxito que estaba teniendo entre los usuarios del data. En uno de los comentarios que recibimos nos decían que el wikidata estaba muy bien, y qué para cuando tendríamos el Google-data… Este comentario me dejó pensativo. ¿Cómo sería un Google-data? ¿Es posible utilizar la tecnología de Google en las búsquedas de información dentro de la empresa?

Hoy he leído un artículo en CincoDias.com titulado “Se abre la lucha por ser el Google empresarial” que responde alguna de estas preguntas… Cito textualmente:

Si alguien piensa en un buscador, seguramente le vendrán a la cabeza nombres como Google, Yahoo o Microsoft con su nuevo Bing. Y ciertamente son los reyes de la búsqueda cuando se trata de encontrar información en internet. Sin embargo, una hornada de buscadores se está consolidando alrededor del mundo corporativo. Son empresas como Exalead, Autonomy, Vivisimo o Endeca, y viejas conocidas del sector TIC como SAP o Information Builders. Todas tienen herramientas que aspiran a ser las Google empresariales, aunque no lo tendrán fácil porque Google y Microsoft tienen sus propias ofertas para atraer a las compañías. Todas se disputan un mercado que, segúnla consultora IDC, moverá en 2009 más de 2.000 millones de euros, y que registra crecimientos de entre el 20% y el 25% cada año.

Los buscadores empresariales permiten hacer lo mismo que Google, pero acotado a cualquier dato que resida en una organización. Una imperiosa necesidad para las empresas dado el volumen de datos que están acumulando. Enterprise Strategy Group calcula que las bases de datos primarias crecen a un ritmo anual del 25%.

Pero buena parte de esa información no está estructurada, es decir, no está sólo en bases de datos o ERP, sino repartida en múltiples formatos: e-mails, documentos adjuntados de powerpoint o PDF, vídeos... […]

El uso de estos motores no tiene ningún secreto. Se manejan como otros de internet a los que la gente está acostumbrada. Pero en esa vía de comprensión de los datos, estas soluciones unen el mundo de la búsqueda con la analítica del business intelligence. […]

En este punto se abre una disputa sobre la calidad de las ofertas. IDC señala que Google es un jugador en esta área "pero tiene menos prestaciones en sus ofertas". Aquí, los representantes de SAP y Exalead coinciden en que Google Enterprise no tiene las capacidades de análisis necesarias para que el resultado sea la base de una toma de decisión. "El business intelligence es la parte diferencial", afirma Cadillon. […]

A mí, que llevo 15 años estructurando información, me parece prácticamente un sacrilegio mantener la información desestructurada. Si realmente se trata de información valiosa (desde el punto de vista analítico), considero que debe estar estructurada o semiestructurada de algún modo, y por supuesto catalogada. Una solución de gestión documental puede ser suficiente en muchas ocasiones.

Realmente, yo no invertiría demasiado en tratar de sacar información de los correos electrónicos, o en los PC de los empleados. Por la siguiente razón: En Internet la información está desordenada por naturaleza, cada página es hija de su padre y de su madre. Dentro de la empresa, en cambio, la situación es (o debería ser) muy diferente y se deberían seguir estándares de documentación, de gestión, de catalogación, etc.

Apuesto, por lo tanto, por toda aquella solución que trate de integrar, organizar y estructurar la información corporativa, y desconfío de las “búsquedas tipo Google” aplicadas al ámbito empresarial.

Esa es mi apuesta, y dentro unos años se verá si es así, o si mi pronóstico es erróneo y descabellado. Puede ser que la experiencia acumulada en estructurar y normalizar la información me impida ver las posibilidades de estas consultas innovadoras. Puede ser. ¿Qué pensáis? ¿Empiezo a hacerme mayor?

Se ha escrito mucho sobre los cuadros de mando. Los consultores, los jefes de Business Intelligence, los vendedores de herramientas necesitamos estar al día, y conocer los conceptos teóricos que nos permitirán mejor "vender" nuestros proyectos. De esta manera, no hemos tenido problema en consturir todo un armazón conceptual de cómo ha de ser un CdM, de la tipología de indicadores que han de presentarse, y del tipo de decisiones que se tomarán en función del CdM.

Se ha escrito mucho, y sin embargo se ha leído mucho menos. Los destinatarios de los CdM han leído muy poco, y conocen muy poco la terminología que empleamos los "expertos"... Han de fiarse de nosotros, y han de confiar en que nos les vendemos excesivo humo.

¿Qué es un cuadro de mando? En el sentido más genérico posible, un cuadro de mando es una aplicación informática que facilita el acceso a la información corporativa con el objetivo de mejorar la toma de decisiones y que se caracteriza por ser muy rápida y visual y por ser extremadamente sencilla de utilizar, sin necesidad de tener conocimientos técnicos.

En esta definición, he intentado dejar la básico, y he ignorado lo accesorio. Por ejemplo, no digo que esté dirigido a la dirección o a cargos de responsabilidad. Para mi, eso es accesorio, y sólo es una consecuencia del coste de desarrollo. Si fuera fácil, rápido y económico contruir un cuadro de mando, cada empleado tendría el suyo propio. Tampoco hablo de indicadores, ni de KPI, ni de objetivos, ni nada de eso. Eso también es accesorio; se trata de una característica particular de unos determinados CdM dirigidos a unas determinadas personas. Lo importante es que aparezca la información que se necesita, y que te permita tomar mejores decisiones en tu trabajo diario. Por supuesto tampoco hablo de si ha de ser una aplicación web, lo cual es totalmente secundario. Ni se han de aparecer las 4 perspectivas de Kaplan... eso lo decidirá el cliente según sus necesidades. Y no digo si es sencillo o complicado construirlo y mantenerlo, ni la libertad que tiene el usuario para personalizarlo, ya que todo eso es dependiente del estado de la técnica actual.

¿Qué os parece esta definición de cuadro de mando? ¿Simplifico demasiado? ¿Me dejo alguna característica fundamental?

Aunque cada vez son menos, aún existen muchas medianas y grandes empresas que no disponen de un sistema de BI. Si ese es su caso, y está leyendo este blog, seguro que ya ha se ha dado cuenta que realmente necesita Business Intelligence en su organización.

Los proyectos de Business Intelligence no son especialmente sencillos. De hecho, son complejos y sólo unos pocos tienen un éxito rotundo a corto plazo. Parte de la dificultad está en la intervención de múltiples factores tecnológicos y no tecnológicos. En concreto, es necesario diferenciar estos tres aspectos o subproyectos:

• Proyecto Definición. Donde deben identificarse los conceptos de negocio que requieren atención. Identificar las necesidades de negocio de los usuarios, los indicadores y dimensiones con las que se trabajan. Conocer la estrategia y objetivos de la empresa, ya que los indicadores que permitan su gestión y seguimiento deben estar contemplados y perfectamente definidos dentro del proyecto. Determinar las limitaciones actuales y aquellos aspectos en los que se desea mejorar.
• Proyecto Datawarehouse. El DWH es una pieza clave del proyecto. Es la base de datos donde se centralizará la información corporativa y será el origen de todas las consultas y necesidades analíticas. Debería diseñarse con independencia de la herramienta de explotación, ya que el mismo DWH será explotado progresivamente por distintas soluciones analíticas (reporting, OLAP, CdM, etc.). A partir de este DWH único, es posible que sea aconsejable diseñar distintos “datamarts” con el objetivo de asegurar el rendimiento en aplicaciones críticas (por ejemplo, el CdM).
• Proyecto Herramienta. En el mercado existen diferentes aplicaciones de BI que permiten la explotación del DWH corporativo. Cada solución tiene unas características y cubre necesidades diferentes. Lo habitual es comenzar con un proyecto de reporting y posteriormente completar el sistema añadiéndole soluciones de OLAP, CdM y data mining.

En la publicación AltoNivel señalan una serie de puntos clave para conseguir que los proyectos de BI sean exitosos:

• Aunque el área de tecnología es actor fundamental en el proyecto, no debe ser responsable del aprovechamiento del mismo, pues cada área es la que conoce su propio negocio y debe aprovechar al máximo las ventajas de manejo de información y herramientas de análisis que le provee la Inteligencia de Negocios. Por ejemplo, los analistas financieros, los comerciales deben hacer sus propios análisis porque son ellos quienes tienen la experiencia.
• Antes de pensar en herramientas tecnológicas, se debe ser una estructura al proyecto y conocer mejores prácticas. Comprar una excelente tecnología de apoyo es indispensable, pero es un paso posterior.
• El proyecto de Inteligencia de Negocios debe responder a la estrategia corporativa de crecimiento, optimización, productividad, competitividad, entre otros aspectos; no debe hacerse porque sí, porque está de moda o porque la competencia ya lo desarrolló.
• Evalúe la calidad de la información que su compañía maneja. Haga esto como un proyecto paralelo o previo al de Inteligencia de Negocios, pues de nada valdrá la inversión en este tipo de iniciativa, si el sistema no tiene como insumo información correcta, completa y oportuna.
• En cuanto a la infraestructura de hardware analice con cuidado aspectos como capacidad de procesamiento y de almacenamiento, a mediano plazo. Adquiera plataformas robustas, acordes a sus necesidades. Piense en la capacidad de crecimiento que seguramente va a necesitar según la demanda de las diferentes unidades del negocio.
• Como último punto apóyese en quienes ya han vivido este proceso, aliméntese de sus experiencias y consúlteles sus inquietudes. El aporte de quienes ya recorrieron el camino, le ahorrará tiempo, le permitirá tomar mejores decisiones, minimizar los errores y sacar el mayor provecho de la Inteligencia de Negocios.
• A propósito de la inversión en tecnología, específicamente en el software, debe evaluar de forma detallada las opciones disponibles en el mercado. Además de los resultados que puede brindar, pregunte cuáles compañías la usan, averigüe la experiencia de ellas, revise las opciones de capacitación, consultoría y soporte técnico en el país.Revise sus características técnicas, por ejemplo.

El datawarehouse (DWH) es una pieza básica, fundamental e indispensable de todo sistema Business Intelligence. Tal vez alguien no comparta la anterior afirmación, y crea que se puede construir un cuadro de mando, o un sistema de reporting, a partir de un datamart o unos cubitos. Perdónales, porque no saben lo que dicen... :-)

La pieza fundamental de un sistema Business Intelligence es el DWH porque todos los listados y análisis que se hagan se harán a partir de esta única base de datos. En el DWH la información está limpia, unificada y verificada, y gracias a esto todo lo que hagamos después cuadrará.

Tal como decía en mi anterior mensaje, voy a analizar los 12 errores más comunes que enumera el gurú Ralph Kimball. Tal como hace él, haré la cuenta regresiva del 12 al 1, aunque intentaré hacerlo en positivo, añadiendo ejemplos y experiencias personales, y explicando las bases sobre cómo construir un datawarehouse:

Error 12: Incluir atributos de texto en una tabla de hechos, si se hace con la intención de filtrar o agrupar.

En un modelo dimensional se deben diferenciar claramente las tablas de hecho de las tablas de dimensiones.

• Las tablas de hecho contienen los indicadores numéricos provenientes de los orígenes transaccionales.
• Las tablas de dimensión contienen los atributos (normalmente textuales) que nos permiten filtrar y agrupar los indicadores.

En ocasiones no es evidente si un dato es dimensional o si se trata de un indicador. Por ejemplo, la hora de la venta (hh:mm:ss) puede considerarse un dato mas del hecho de venta (como el precio, o las unidades vendidas), o una dimensión temporal muy detallada. O la matrícula del camión que subcontratamos para realizar los transportes. Si no tenemos un maestro de los miles de camiones que utilizan nuestros transpostistas, ni queremos analizarlo por las características del camión, podríamos considerar la matrícula como una especie de indicador e incluirlo en la tabla de hechos.

En caso de duda:

• Evita colocar texto largos (como comentarios, o nombres de ciudades o personas) en las tablas de hecho. Estos campos ocuparían un espacio precioso de nuestras tablas de hechos, que pueden tener cientos de millones de registros, y que por lo tanto ocuparían mucho espacio en disco y las consultas serían lentas por el IO generado. Hoy en día, los gigas son baratos, pero el tiempo para leerlos, no.
• Si el “dato” es compartido entre varias tablas de hecho, ponlo siempre como una dimensión. Por ejemplo, un mismo cliente puede tener pedidos, ventas, devoluciones, quejas, …

A través de TodoBI he encontrado un artículo muy interesante de Ralph Kimball (¿Algún despistado que no lo conoce?) donde detalla los 12 errores más comunes en la construcción de un datawarehouse.

Se trata de un artículo excelente. Cada vez que he cometido alguno de estos errores, he tenido que rectificar al poco tiempo. No valen los atajos, hay que hacer las cosas bien desde el principio.

Los doce errores más comunes en la construcción de un datawarehouse son:

• Error 12: Incluir atributos de texto en una tabla de hechos, si se hace con la intención de filtrar o agrupar.
• Error 11: Abreviar las descripciones en las tablas de dimensión con la intención de reducir el espacio requerido.
• Error 10: Dividir las jerarquías y los niveles de las jerarquías en múltiples dimensiones.
• Error 9: No afrontar el tratamiento de las dimensiones lentamente cambiantes.
• Error 8: Crear “smart keys” para relacionar una tabla de dimension con una tabla de hechos.
• Error 7: Añadir dimensiones en una tabla de hechos antes de definir su granularidad.
• Error 6: Crear un modelo dimensional para resolver un informe en particular.
• Error 5: Mezclar hechos de diferente granularidad en una misma tabla de hechos.
• Error 4: Olvidarse del máximo nivel de detalle en el modelo entidad-relación.
• Error 3: Omitir las tablas agregadas y comprimir las tablas de dimension para afrontar los problemas de rendimiento.
• Error 2: No unificar los hechos entre distintas tablas de hechos
• Error 1: No compartir dimensiones entre diferentes tablas de hechos.

En mi vida laboral he participado en la construcción de varios datawarehouses, y he visto muchos de estos errores. Durante los próximos días, analizaré una a una estas recomendaciones de Kimball, e intentaré justificar por que son errores graves y cómo debemos evitarlos.

A mis lectores menos "tekies", os pido perdón porque los próximos mensajes no los escribo pensando en vosotros. Van dirigidos al lado oscuro... :-)

Las dimensiones se agrupan en jerarquías mediante relaciones uno-a-muchos. Una población agrupa a muchos clientes. Una provincia agrupa a muchas poblaciones. Una región está formada por varias provincias. Etcétera. Las jerarquías típicas, que aparecen en cualquier sistema Business Intelligence, son:

• Jerarquía geográfica o de clientes (país del cliente/región/ciudad/cliente)
• Jerarquía de producto (marca/familia/producto/presentación)
• Jerarquía comercial (país/zona/punto de venta)
• Jerarquía temporal (año/trimestre/mes/día)

Evidentemente, pueden existir jerarquías adicionales, o incluso puede haber diferentes maneras de jerarquizar una misma información. En particular, es habitual la existencia de diferentes jerarquías de producto (lo que es una "pesadez" muchas veces necesaria, otro día lo comentaré…).

Esta manera de visualizar jerárquicamente la información resulta muy natural y cómoda para los usuarios de negocio.

Y, como siempre, podemos cometer errores modelizando las jerarquías. Éste es el error número 10 de esta serie sobre cómo construir un datawarehouse:

Error 10: Dividir las jerarquías y los niveles de las jerarquías en múltiples dimensiones

Existen dos maneras principales de modelizar las jerarquías:

• Modelo en estrella: Donde una única tabla contiene toda la información de la jerarquía.
• Modelo copo de nieve: Donde se crea una tabla para cada nivel de la jerarquía

En la base de datos de presentación (también llamado modelo dimensional) del DWH debe preferirse siempre el modelo en estrella. Es decir, debe crearse una única tabla para cada jerarquía. La misma tabla de PRODUCTOS debe tener toda la información relativa a los productos (presentación, producto, familia, marca).

El modelo dimensional es el que ataca nuestra herramienta de Business Intelligence, por lo que interesa que las consultas generadas sean sencillas (con pocas tablas y pocas relaciones). El modelo en estrella es perfecto para conseguir este objetivo. Además, desaparece el problema que generan las diferentes jerarquías en que se pueden agrupar los productos.

Sin embargo, por desgracia, no siempre es posible tener un modelo en estrella perfecto. La herramienta de explotación puede requerir normalizar parte de una jerarquía en una tabla independiente. Esta limitación aparece cuando diferentes "hechos" están definidos con diferente granularidad. Por ejemplo, las ventas están a nivel de "producto", pero los objetivos de venta se marcan a nivel de "familia". En este caso, muchas herramientas BI exigirán la existencia de una tabla de FAMILIAS.

Finalmente, es importante destacar que además del "modelo dimensional" el DWH debe mantener un modelo normalizado de la información (llamado "modelo relacional"). En este otro modelo, la información sí que debe estar normalizada, unificada y limpia.

Denominamos dimensiones a aquellos datos que nos permiten filtrar, agrupar o seccionar la información. El término "dimensión" sigue teniendo un cierta connotación técnica, por lo que muchas personas lo siguen denominando "atributo", "característica", "propiedad", "campo", o incluso "cuadradito azul" (en el caso de una instalación de BO).

Algunas aplicaciones Business Intelligence utilizan el término "dimensión" como equivalente a "jerarquía" (especialmente en bases de datos multidimensionales). De esta manera, se habla de la dimensión geográfica que agrupa los diferentes niveles de continentes, países, regiones, provincias y localidades.

Personalmente, prefiero reservar el término "dimension" para referirme a cada uno de los niveles de la jerarquía.

En el modelo relacional del datawarehouse las dimensiones se almacenan en las "tablas de dimensión", lo que nos lleva al error número 11 de nuestra serie:

Error 11: Abreviar las descripciones en las tablas de dimensión con la intención de reducir el espacio requerido.

El espacio requerido por las tablas de dimensión es despreciable frente a lo que ocupan los hechos. Por ejemplo, una cadena como Zara puede tener unas 5000 tiendas, y debe generar unos 3 o 4 millones de registros de venta diarios. En este y otros ejemplos que podríamos citar, también las dimensiones de cliente o producto son despreciable frente a las ventas, los envíos o la producción diaria.

Por lo tanto, no debemos considerar el espacio como un aspecto determinante para modelizar las dimensiones. En particular, cada código debe tener su descripción. Las dimensiones son la interfaz que tendrán los usuarios para navegar por la información, por lo que conviene que sean lo más explícitas y claras posible.

Incluso debemos plantearnos la necesidad real de introducir los códigos en la capa de presentación a los usuarios. Aunque algunos trabajadores pueden estar acostumbrados a trabajar con los códigos de familia, las referencias o los códigos de proveedor, nadie los conoce todos, y especialmente los nuevos empleados pueden tener dificultades para reconocerlos. Siempre son preferibles las descripciones.

Personalmente, omito por defecto todos los códigos de la capa de presentación, y sólo cuando algún usuario lo solicita explícitamente lo añado en el sistema. Esta manera de actuar nunca me ha generado un problema. De hecho, es sorprendente lo rápido que se acostumbran los usuarios a trabajar con las descripciones y lo rápido que se olvidan de los códigos con los que han trabajado toda la vida... (una causa de esto es que con una herramienta Business Intelligence raramente se ha de teclear un código, ya que se trabaja con clics de ratón y con listas de valores).

En los anteriores comentarios de esta serie sobre cómo construir un datawarehouse, explicaba las características de las dimensiones y las jerarquías. Sin embargo, estaba omitiendo un aspecto principal de estas tablas.

La información de las dimensiones no es estática, ya que puede modificarse en el operacional por diferentes motivos. Por ejemplo, puede corregirse la fecha de nacimiento de un cliente, o éste puede cambiar de ciudad, o una delegación puede asignarse a un delegado diferente, etc. ¿Cómo debe gestionarse esta información?

En primer lugar, debe tenerse en cuenta que el tratamiento que se realizará dependerá de cada dimensión y de las necesidades del negocio. Por ejemplo, si se actualiza la fecha de nacimiento de un cliente se puede asumir que ese cambio aplica a toda la historia de ese cliente. Sin embargo, existen casos donde la información dimensional histórica es importante. Considera estas dos situaciones:

Previsión de ventas: Para realizar una previsión de ventas para el próximo año, deberemos considerar las ventas históricas de las tiendas que actualmente tiene asignado cada delegado.

Análisis de márgenes: Si queremos analizar los descuentos que aplica cada delegado, deberemos considerar las ventas de aquellas tiendas que han tenido asignadas a lo largo del tiempo.

Por lo tanto, en este ejemplo, deberemos modelizar la información de tal modo que seamos capaces de conocer el "delegado actual" y el "delegado/s histórico/s".

Para conseguir este objetivo se introducen las "claves subrogadas", que son identificadores sin ningún significado específico para el negocio. Aunque existen diferentes maneras de modelizar estos datos, lo habitual es trabajar con las "fechas de vigencia". Por ejemplo, esta sería la estructura de la tabla de DELEGACIONES en el modelo relacional:

Ampliar imagen

Analizando cuidadosamente los valores de esta tabla, puede observarse que Pedro era el responsable de las delegaciones de Madrid y Barcelona, y que sus funciones fueron asumidas posteriormente por Juan y María. En el modelo dimensional, la tabla podría modelizarse de este modo:

El sistema funcionaría de manera similar con cualquier otra dimensión que pudiese tener la jerarquía de delegaciones, o cualquier otra jerarquía. Evidentemente, se trata de un tema complejo y que debe considerarse, o caeríamos de lleno en el error número 9:

Error 9: No afrontar el tratamiento de las dimensiones lentamente cambiantes

En cualquier definición del término datawarehouse se menciona que es un repositorio de información histórica, y con ello se pretende enfatizar que contiene:

• Historia de los hechos: En el operacional existe registro de los "hechos" del negocio de los últimos meses o de unos pocos años. Sin embargo, en el DWH se intenta que exista un histórico mucho mayor.
• Historia de las dimensiones: El operacional sólo suele guardar la situación actual de las dimensiones. En el DWH, sin embargo, debe mantenerse toda la evolución de los cambios dimensionales.

Pues bien, este segundo punto se suele olvidar (o ignorar) en algunas implantaciones de DWH por las siguientes razones:

• La "visión actual" parece suficiente. Al fin y al cabo, es lo que siempre se ha hecho en el sistema operacional.
• El usuario no siempre entiende la diferencia entre la "visión actual" y la "visión histórica". Y por lo tanto no sabe concretar sus necesidades reales.
• La gestión de cambios en las dimensiones nunca aparece en los requerimientos que motivaron el proyecto. De entrada, no parece importante (pero lo es).

No nos dejemos engañar. A pesar de todo esto, la gestión de dimensiones lentamente cambiantes es imprescindible. Personalmente, acostumbro a guardar toda la historia de las dimensiones en el modelo relacional (incluso algunos datos que inicialmente no parecen necesarios como la "fecha de nacimiento"). En el modelo dimensional, de entrada, sólo publico la visión actual, y sólo cuando lo solicita explícitamente el usuario de negocio, añado la visión histórica de esa dimensión.

En la anterior entrega de esta serie sobre cómo construir un datawarehouse ya introducía el concepto de las “claves subrogadas”.

Una clave subrogada es un identificador único que se asigna a cada registro de una tabla de dimensión. Esta clave, generalmente, no tiene ningún sentido específico de negocio. Son siempre de tipo numérico. Preferiblemente, un entero autoincremental.

Habitualmente, el sistema operacional ya utiliza sus propias claves, aunque suelen ser de tipo carácter y tienen un sentido específico para los empleados de la compañía. Por ejemplo, el código BCN puede utilizarse para referirse a Barcelona, o el DNI de cada empleado puede ser la clave única de la tabla de empleados. O el código de barras para referirse a un producto. ¿Por qué necesitamos, entonces, crear unos nuevos identificadores en el sistema Business Intelligence? Por varios motivos:

• Fuentes heterogéneas. El DWH suele alimentarse de diferentes fuentes, cada una de ellas con sus propias claves, por lo que es arriesgado asumir un código de alguna aplicación en particular. ¿Qué ocurriría si en el futuro se añade información de una aplicación que tiene su propio maestro de ciudades? Seguro que nos generará un problema, aparecerán ciudades que no existían en nuestro maestro…¿Cómo lo gestionaríamos? No sé. Lo mejor es crear nuestras propias claves subrogadas desde el inicio del proyecto.
• Cambios en las aplicaciones origen. Puede ocurrir que cambie la lógica operacional de alguna clave que hubiésemos supuesto única, o que siempre debería estar informada. ¿Qué pasará cuando llegue un empleado sin DNI? ¿Qué pasará cuando se de de alta una ciudad extranjera con el código BCN? Prefiero no saberlo. Lo mejor es crear nuestras propias claves subrogadas desde el inicio del proyecto.
• Rendimiento. En la base de datos, ocupa menos espacio un entero que una cadena. Identificar una ciudad con 5 bytes, o una persona con 9 bytes es un desperdicio considerable de espacio. De hecho, no debe preocuparnos el espacio que ocupa, sino el tiempo que se pierde en leerlo… Recordad que las claves subrogadas las llevaremos a las tablas de hechos, por lo que cada código es susceptible de repetirse cientos de millones de veces. Conviene optimizarlo al máximo. Lo mejor es crear nuestras propias claves subrogadas desde el inicio del proyecto.

Por supuesto, también se pueden cometer errores al generar una clave subrogada…

Error 8: Crear “smart keys” para relacionar una tabla de dimension con una tabla de hechos.

En ocasiones, nos puede parecer útil aprovechar la lógica que subyace a los elementos para generar nuestras propias claves. Por ejemplo, si queremos crear una jerarquía de ciudades, nunca debemos caer en la tentación de crear una simple concatenación (y generar el código ESP-CAT-BCN para referirnos a Barcelona)… También es un error crear una clave compuesta de varios campos. Aunque en el operacional la terna país-CCAA-ciudad sea única, en el DWH debemos crear una clave subrogada formada por un solo campo entero autoincremental.

Recuerda: Sustituye cualquier clave física por una clave entera numerada secuencialmente desde 1 hasta N.

Denominamos “hechos” a los indicadores de negocio. Por ejemplo, son “hechos” las ventas, los pedidos, los envíos, las reclamaciones, las compras, etc. Es decir, son todas aquellas medidas numéricas que incluiremos en nuestro sistema Business Intelligence.

Técnicamente, una tabla de hecho es la tabla central de un modelo en estrella. En el siguiente diagrama, la tabla de ventas es la tabla de hechos:

Una característica importante de las tablas de hecho es el “nivel de detalle” de la información que se almacena. En el anterior ejemplo, las ventas están guardadas a nivel de cliente, producto, almacén, promoción y fecha.

La tabla de hechos contiene las claves subrogadas de aquellas dimensiones que definen su nivel de detalle, y los indicadores. Nada más.

Por lo tanto, antes de crear la tabla de hechos debe entenderse perfectamente la información que se guardará, o se estará cometiendo el error número 7 de esta serie sobre cómo construir un datawarehouse…

Error 7: Añadir dimensiones en una tabla de hechos antes de definir su granularidad.

De hecho, la creación de una tabla de hechos es una tarea con poco margen a la imaginación. Antes que nada, debe localizarse el origen de la información que se quiere cargar, debe entenderse perfectamente el significado de estos indicadores, y debe determinarse el nivel de detalle de estos datos. Una vez hecho esto, la creación de la estructura de la tabla es inmediata. Tal y como comentaba anteriormente:La tabla de hechos contiene las claves subrogadas de aquellas dimensiones que definen su nivel de detalle, y los indicadores. Nada más. Y nada menos.

En particular, es un error desnormalizar cualquier dimensión en la tabla de hechos. Por ejemplo, si la información está a nivel de cliente, no necesitamos poner la población o el país en la tabla de hechos. Resultaría redundante e impactaría directamente en el tamaño de la tabla (y en los tiempos de respuesta).

Otra de las características importantes que debe tener un DWH es estar "organizado por temas" (subject-oriented). Bill Inmon es considerado uno de los padres del concepto DWH, y fue el quien introdujo esta característica en su definición:

"A warehouse is a subject-oriented, integrated, time-variant and non-volatile collection of data in support of managements decision making process" (Bill Inmon, 1990)

La organización temática de la información se refiere a que los datos que están cargados incluyen los indicadores relevantes de diferentes áreas de información de la compañía. Además, deben poder cruzarse los indicadores relativos al mismo objeto o evento del mundo real.

Esta organización temática de la información facilita posteriormente la construcción de informes ad-hoc, ya que permite obtener y cruzar información que se generó en procesos de negocio muy diferentes (aunque de una misma temática). Observad que esta manera de organizar la información es muy distinta de la existente en un sistema OLTP tradicional, donde la información está organizada por transacciones y procesos.

Modelizar adecuadamente la estructura del sistema Business Intelligence es fundamental para que posteriormente el usuario puede generarse cualquier informe que necesite. En particular, es un error grave y frecuente el error número 6 de esta serie sobre cómo construir un datawarehouse

Error 6: Crear un modelo dimensional para resolver un informe en particular.

Efectivamente, el modelo dimensional debe ser independiente de cualquier informe en particular. Una de las razones que habitualmente justifica la creación de un sistema Business Intelligece es la necesidad de otorgar a los usuarios la capacidad de realizar informes ad-hoc. No tendría sentido, por lo tanto, que el equipo de IT tuviese que adaptar el datawarehouse para cada informe necesario.

Al iniciar un proyecto de datawarehouse, muchas veces he visto cómo se gastan demasiados esfuerzos en definir los informes que se necesitan, y se hacen interminables reuniones con los usuarios de negocio con este objetivo. Es un error que puede costar muy caro. Me explico: Esas reuniones son necesarias, pero el objetivo debería ser entender los indicadores y los conceptos con los que trabajan los usuarios de negocio, y no conocer particularidades intrascendentes de informes determinados.

En particular, si se trabaja con consultores externos, conviene evitar que la aceptación del proyecto esté vinculada a la realización de unos informes en particular. Si esos son los términos de tu contrato, existe el riesgo de que los esfuerzos se focalicen en la construcción de esos informes, cuando lo correcto sería modelizar el DWH de tal forma que fuese viable consturir cualquier informe.

No digas que no te lo advertí :-)

El datawarehouse tiene, y debe tener, todo el detalle de información en su nivel atómico. Así, las ventas estarán detalladas por fecha, cliente, producto y punto de venta. Rápidamente nos daremos cuenta que estaremos trabajando con un volumen muy importante de información. Por poner algún ejemplo, en los sectores de distribución retail, telecomunicaciones o banca es habitual encontrarse con datawarehouses con miles de millones de registros.

Sin embargo, la mayoría de consultas no necesitan acceder a tanto detalle. Un "product manager" puede estar interesado en los totales de venta de sus productos mes a mes, mientras que el "area manager" consulta habitualmente la evolución de ventas de sus zonas.

Incluso con el uso de índices, la compresión de las tablas, o con una inversión millonaria en hardware, estas consultas habituales deberían leer, agrupar y sumar decenas de millones de registros, lo que repercutiría directamente en el tiempo de respuesta y en el descontento de los usuarios.

La solución ante estas situaciones pasa siempre para la preparación de tablas agregadas. Las tablas agregadas sumarizan los indicadores de las tablas de detalle a un nivel superior. Por ejemplo, las ventas podrían precalcularse a nivel mensual, o por cliente, o por producto. De esta manera, las consultas típicas del "product manager" o del "area manager" podrían ejecutarse en pocos segundos, sin necesidad de acceder a la tabla de ventas detalladas.

La existencia de estas tablas agregadas debe ser completamente transparente para el usuario de negocio. Es decir, tanto el "area manager" como el "producto manager" trabajarán con el indicador "Ventas", y la herramienta Business Intelligence hará el resto.

En mi opinión, lo más complicado es definir las tablas agregadas necesarias. De nada sirve crear muchos agregados si estos no se utilizan. Es necesario conocer las consultas habituales de los usuarios. Y, desde luego, lo que no debe hacerse es lo que indica el error 5 de esta serie sobre cómo construir un datawarehouse:

Error 5: Mezclar hechos de diferente granularidad en una misma tabla de hechos.

Calcular los agregados en la misma tabla de ventas es un error muy grave e injustificable. Aunque puede parece adecuado en algunas situaciones, será sin duda una fuente de problemas e incoherencias futuras. Este tipo de construcciones erróneas suelen aparecer ante la falta de funcionalidad de las herramientas BI, lo que obliga al técnico a crear modelos extraños.

Personalmente, he visto este tipo de tablas (que mezclan información a diferente nivel de detalle) en sistemas operacionales, donde resulta prohibitivo calcular los totales en el momento de generación del informe. De esta manera, el operacional apunta el detalle y los totales en el mismo momento, y de esta manera los listados predefinidos del host se ejecutan de manera rápida y sencilla. En un entorno datawarehouse, evidentemente, todo esto es innecesario y contraproducente.

Recuerda: Cada "granularidad" requiere su propia tabla de hechos.

Aunque existen varias opiniones al respecto, yo soy de los que cree firmemente que en el DWH debe estar disponible el máximo nivel de detalle de la información. Se debe guardar cada ticket, cada venta, cada transacción.

Si se dispone la información detallada, cualquier consulta posterior podrá resolverse en cualquier de las agrupaciones disponibles. Tal vez, de entrada, puede parecer suficiente ver las ventas diarias de cada familia, sí, ¿Pero y si luego quiero verlo por grupo social? ¿O por hora de venta? ¿O si lo quiero segmentar por precio de venta? ¿O por tipo de subfamilia? Sólo si inicialmente se diseñó y cargó el datawarehouse con la información detallada podrán contestarse estas preguntas.

En general, dentro del DWH se distinguen tres áreas principales:

• Área de staging: Que contiene las información bruta extraída de los sistemas operacionales. Es un área temporal donde los datos se preparan y normalizan antes de cargarse definitivamente en el DWH.
• Modelo relacional: Es una base de datos donde la información se encuentra normalizada. Contiene todo el detalle de información. Y toda la historia posible. No hay tablas agregadas. En este punto la información ya está limpia e integrada, y ya se han creado las claves subrogadas. Es preferible un modelo en "copo de nieve" o incluso normalizado totalmente.
• Modelo dimensional: Es la base de datos que utilizan las herramientas de Business Intelligence para obtener la información y hacer los informes o análisis. El modelo dimensional está optimizado para conseguir un buen rendimiento. Existen tablas agregadas. Se prefiere el modelo en estrella. Y, en mi opinión, también debe tener todo o casi todo el detalle de información.

Soy consciente que el máximo nivel de detalle implica cargar muchos datos, y hacerlo por triplicado, lo que requiere tiempo de carga y espacio en disco. Ya. Conozco las desventajas. Y debemos asumirlas si queremos un datawarehouse que se útil para las necesidades actuales y para las necesidades futuras.

El error 4 de esta serie sobre cómo construir un datawarehouse trata este asunto:

Error 4: Olvidarse del máximo nivel de detalle en el modelo entidad-relación.

Efectivamente, el máximo detalle no lo debemos dejar ni en el operacional, ni en la staging, ni en el modelo relacional. Todo el detalle debe propagarse hasta el modelo dimensional. Sólo de esta manera el sistema Business Intelligence superará el ataque de las consultas ad-hoc.

Habitualmente, esta manera de trabajar sólo la cuestionan los consultores que han intervenido en excesivos proyectos de cuadro de mando. Es habitual que las empresas soliciten un cuadro de mando sin tener antes un datawarehouse ni un sistema de reporting aceptable. En estos casos, cargar todo el detalle puede parecer difícil de justificar. ¿Cómo voy a proponer un DWH de 500Gb si el gerente sólo quiere 4 pantallitas para hacer el seguimiento mensual de un puñado de indicadores? En mi opinión, hay que proponerlo. Sólo disponiendo de un buen DWH podrá asegurarse la continuidad del proyecto BI.

Recuerda: Por lo menos carga el máximo nivel de detalle en el modelo relacional, y podrás mostrarlo cuando te des cuenta de que también lo necesitas en el modelo dimensional.

En primer lugar, reconozcamos que tenemos un problema de rendimiento. Todos los datawarehouse tienen un problema de rendimiento. Ninguno va excesivamente rápido. Siempre se puede mejorar. Es más, la falta de problemas de rendimiento suele esconder un problema mucho mayor y de más difícil solución… la falta de uso del sistema.

Si has llegado hasta esta página intentando resolver los problemas de rendimiento de tu sistema Business Intelligence, lamento decirte que no encontrarás la respuesta en este post. La respuesta está en todos los demás: Modeliza correctamente, y el sistema funcionará como debe.

Personalmente, creo que la mejor estrategia para afrontar los problemas de lentitud pasa por monitorizar continuamente el sistema. Debemos conocer cuantas consultas se están ejecutando diariamente, y cuanto tiempo requiere cada consulta. Si hacemos esto, sabremos como de mal va el sistema, y podremos fijarnos objetivos. En el último proyecto datawarehouse que he participado, hubo un momento en el que 85 % de las consultas tardaban menos de 1 minuto, y sin embargo muchos usuarios se quejaban de la lentitud del sistema. El 5% de las consultas tardaban más de 30 minutos. Para mejorar la situación, analizamos diariamente estas consultas… en ocasiones eran problemas en la manera de hacer las consultas por parte de los usuarios, y otras veces era un problemas de modelización. Educando a los usuarios, y con pequeños cambios en el modelo dimensional pudimos ofrecer una mejora significativa a los usuarios. Menos del 1 % de las consultas seguían tardando más de 30 minutos. Afortunadamente, seguíamos teniendo problemas de rendimiento, porque lo contrario sería señal de que dejaron de utilizar el sistema :-)

Los problemas siempre son del software, del hardware, o del informático. El usuario nunca se equivoca. Distingo, pues, estas 3 causas de problemas de rendimiento:

• Dificultad de uso de la herramienta Business Intelligence, lo que provoca consultas incorrectas o sin sentido por parte de los usuarios
• Modelización deficiente (falta de agregados, falta de índices, etc.)
• Hardware insuficiente (el sistema debe dimensionarse en función del volumen a información a gestionar y el número de usuarios activos)

En particular, ante un problema de rendimiento, debe evitarse cometer el error número 3 de esta serie sobre cómo construir un datawarehouse:

Error 3: Omitir las tablas agregadas y comprimir las tablas de dimension para afrontar los problemas de rendimiento.

Efectivamente, las tablas agregadas proporcionan una mejora inmediata (y en muchas ocasiones espectacular) en el rendimiento (siempre y cuando la herramienta de BI sea capaz de aprovecharse de estos agregados, que debe serlo). En primer lugar, deben considerarse mejoras en la modelización y descartar nuevas y caras inversiones en hardware.

Si el sistema no está bien modelizado, seguirá funcionando mal después de una ampliación de discos, de RAM o de CPU. La ampliación de hardware sólo puede justificarse ante un aumento del volumen de información a gestionar y/o en el número de usuarios del sistema.

También debo decir que el uso de tablas agregadas tiene un coste. Las tablas agregadas añaden complejidad al sistema, ya que son nuevos elementos que deberán mantenerse y actualizarse indefinidamente. Las tablas agregadas sólo son útiles si efectivamente se usan, y reducen considerablemente el número de registros de la tabla detallada.

En la definición de datawarehouse de Bill Inmon (y en todas las definiciones posteriores de cualquier menda aficionado al BI, como el autor de este blog de Business Intelligence en español) se señala que un DWH es un repositorio donde la información corporativa se encuentra "integrada".

A warehouse is a subject-oriented, integrated, time-variant and non-volatile collection of data in support of managements decision making process (Bill Inmon, 1990)

Efectivamente, cualquier empresa tiene múltiples sistemas operacionales, cada uno de ellos con sus propios maestros y su propia información. Uno de los objetivos del DWH es unificar toda esa información dispersa en un único repositorio. Sin embargo, no se trata sólo de juntar todos estos datos, el objetivo es unificarlos, integrarlos y conformarlos, es decir, dar la misma forma y el mismo significado a dimensiones y hechos aparentemente distintos (en inglés dicen "conform information").

Por ejemplo, una empresa de distribución puede tener dos canales de ventas a través de los cuales vende los mismos productos (venta al mayor y venta retail). Habitualmente, la gestión de estos dos negocios la realizarán personas diferentes de diferentes departamentos, y cada uno de ellos tendrá sus sistemas informáticos con diferencias significativas entre ellos. Es muy diferente el negocio minorista del negocio mayorista.

Pues bien, en este ejemplo, uno de los retos de la creación del DWH sería la unificación de estos dos negocios, porque sin duda existirán usuarios que querrán conocer la "facturación", y la facturación evidentemente incluye las ventas al mayor y al ventas retail. Para realizar esta unificación, las dos tablas de hechos deberán compartir las mismas dimensiones, y deberán definirse con precisión los términos de cada negocio para que resulten agregables entre sí… Incluso, podría ser recomendable unificar los dos hechos en una misma tabla de hechos, donde la dimensión "tipo de venta" permitiese diferenciar las ventas al mayor de las ventas retail.

A esta unificación se refiere el penúltimo error de esta serie sobre cómo construir un datawarehouse:

Error 2: No unificar los hechos entre distintas tablas de hechos

Tal como comentaba, independientemente de que los hechos se modelicen en una o varias tablas de hechos, estos deben tener la misma forma. Deben tener dimensiones compartidas que permitan la comparación y/o agregación entre sí. Si se quiere sumar o dividir la información de distintos hechos, estos deben tener la misma forma y deben haberse cargado aplicando los mismos criterios.

Otro ejemplo de "conformar" adecuadamente los hechos sería aplicar los mismos criterios al cargar las compras y las ventas. Si se quiere calcular el cociente de ventas sobre compras, deberemos asegurarnos que en los dos indicadores se están considerando los mismos productos. No debemos, por ejemplo, olvidarnos de aquellos productos que sólo se venden por Internet o que forman parte de un negocio secundario de la compañía. Si estos productos se incluyen en las ventas, deben incluirse también en las compras (aunque provengan de fuentes distintas).

Finalmente, he terminado de recorrer la lista de Ralph Kimball sobre cómo no construir un datawarehouse. A lo largo de estos artículos he intentado introducir los conceptos más importantes relativos a la modelización de un datawarehouse (base de cualquier entorno Business Intelligence).

Para finalizar esta serie, incluyo el índice de todas las entradas:

• Introducción: Cómo no construir un datawarehouse
• Artículo 1: Datawarehouse
• Artículo 2: Dimensiones
• Artículo 3: Jerarquías
• Artículo 4: Dimensiones lentamente cambiantes
• Artículo 5: Claves subrogadas
• Artículo 6: Tablas de hecho
• Artículo 7: DWH organizado por temas
• Artículo 8: Tablas agregadas
• Artículo 9: Máximo nivel de detalle
• Artículo 10: Rendimiento
• Artículo 11: Unificar los hechos
• Artículo 12: Unificar las dimensiones

Cada artículo, analiza uno de los 12 errores que justificaron esta serie:

• Mistake 12: Place text attributes in a fact table if you mean to use them as the basis of constraining and grouping.
• Mistake 11: Limit the use of verbose descriptive attributes in dimensions to save space.
• Mistake 10: Split hierarchies and hierarchy levels into multiple dimensions.
• Mistake 9: Delay dealing with a slowly changing dimension (SCD).
• Mistake 8: Use smart keys to join a dimension table to a fact table.
• Mistake 7: Add dimensions to a fact table before declaring its grain.
• Mistake 6: Declare that a dimensional model is "based on a specific report."
• Mistake 5: Mix facts of differing grain in the same fact table.
• Mistake 4: Leave lowest-level atomic data in E/R format.
• Mistake 3: Eschew aggregate fact tables and shrunken dimension tables when faced with query performance concerns
• Mistake 2: Fail to conform facts across separate fact tables.
• Mistake 1: Fail to conform dimensions across separate fact tables.

Y que traduje de esta manera...

• Error 12: Incluir atributos de texto en una tabla de hechos, si se hace con la intención de filtrar o agrupar.
• Error 11: Abreviar las descripciones en las tablas de dimensión con la intención de reducir el espacio requerido.
• Error 10: Dividir las jerarquías y los niveles de las jerarquías en múltiples dimensiones.
• Error 9: No afrontar el tratamiento de las dimensiones lentamente cambiantes.
• Error 8: Crear "smart keys" para relacionar una tabla de dimension con una tabla de hechos.
• Error 7: Añadir dimensiones en una tabla de hechos antes de definir su granularidad.
• Error 6: Crear un modelo dimensional para resolver un informe en particular.
• Error 5: Mezclar hechos de diferente granularidad en una misma tabla de hechos.
• Error 4: Olvidarse del máximo nivel de detalle en el modelo entidad-relación.
• Error 3: Omitir las tablas agregadas y comprimir las tablas de dimension para afrontar los problemas de rendimiento.
• Error 2: No unificar los hechos entre distintas tablas de hechos
• Error 1: No compartir dimensiones entre diferentes tablas de hechos.

En la anterior entrada de esta serie sobre cómo construir un datawarehouse se describía la importancia de unificar los hechos. Ahora hablaremos de unificar las dimensiones. No es más importante una cosa que la otra. Las dos son imprescindibles.

Sabemos que es normal que dentro de una compañía convivan muchas aplicaciones informáticas, cada una de ellas con sus propios maestros. Una función importante del DWH es la unificación de estas aplicaciones en unos maestros únicos.

Por ejemplo, la aplicación de recursos humanos puede utilizar los códigos "M" y "F" para indicar el sexo de los empleados, mientras que la aplicación de CRM puede estar utilizando los códigos "H" y "M". Es sólo un ejemplo tonto, pero es la realidad de todas las empresas. Incluso puede haber diferencias entre los códigos de las tiendas y productos que utilizan las distintas aplicaciones o módulos del ERP.

En el DWH, evidentemente, debe existir un solo maestro de género. Y un solo maestro de tiendas. Y un solo maestro de productos. Y un solo maestro de cualquier cosa. En el proceso de carga del datawarehouse, deben identificarse los códigos equivalentes, y asignarles una única clave subrogada.

Un caso especial, y muy problemático, es el maestro de clientes. Se puede captar información de los clientes a partir de un formulario en la página web, o un carnet de afiliación que solicita el cliente en la tienda, o una llamada al departamento de reclamaciones… Es importante identificar las personas entre distintos aplicativos. Ni el nombre y los apellidos del cliente, ni el email, ni la dirección, ni siquiera el DNI son métodos fiables para detectar una misma persona en diferentes aplicaciones. Para identificar adecuadamente un cliente debe utilizarse una combinación de todos los anteriores e incluso puede ser necesaria la intervención manual. Existen herramientas y compañías especializadas en esta tarea, y no suele considerarse una responsabilidad del modelizador del DWH. Normalmente, para realizar una identificación fiable resulta necesario modificar las aplicaciones orígen, para realizar el "matching" cuanto antes.

En todos los demás casos, el equipo del DWH debe estar obsesionado por entender y unificar todos los maestros de la compañía.

El primer error, el más grave según Raplh Kimbal, se refiere precisamente a este aspecto de la modelización:

Error 1: No compartir dimensiones entre diferentes tablas de hechos.

Efectivamente, por falta de tiempo y recursos, se pueden cargar los diferentes maestros tal cual llegan de los distintos operacionales. Es un error muy grave. Las dimensiones compartidas entre diferentes hechos permiten navegar por la información, o cruzar información de distintos orígenes.

Si se realiza correctamente, daremos mucha potencia y funcionalidad a los usuarios de negocio, el mantenimiento del sistema será más sencillo, y podrá añadirse nueva información al sistema Business Intelligence de manera paulatina y harmoniosa.

Si no se realiza correctamente, el datawarehouse perderá mucha de su utilidad y sentido.

La entrada de hoy es un poco especial. Tengo el placer de anunciar que el blog ha cambiado de dirección, y que probablemente dentro de unos días cambiará también de estrucutra y/o formato. Estad atentos :-)

La nueva dirección creo que es más fácil de recordar y representa mejor lo que este blog quiere ser... Un blog de Business Intelligence para seres humanos...

http://www.businessintelligence.info/

Por otra parte, el contenido del blog seguirá siendo el de siempre. En este blog encontrarás mis impresiones personales sobre el mundo Business Intelligence y las tecnologías y las no-tecnologías que giran a su alrededor: DWH, OLAP, informes dinámicos, cuadros de mando, software BI, tendencias BI, etc.

Con este blog quiero obligarme a mi mismo a estar al día de lo que ocurre en el mundo BI, y estaría encantado de que fuese un punto donde cualquier interesado en el BI pueda también mantenerse informado.

Recuerda: BUSINESS INTELLIGENCE (punto) INFO

Como siempre, intentaré no aburriros demasiado :-)

Un saludo,

BI fácil

He encontrado este vídeo de Microsoft donde explica brevemente la evolución del Business Intelligence desde sus orígenes hasta ahora. El vídeo es simpático y no tiene carácter comercial (no mucho, por lo menos). La presentación dura 10 minutos.

Si no dispones de 10 minutos para ver el vídeo, aquí tienes un resumen:

El vídeo comienza hablando sobre la confusión que genera el término BI, y explica que el Business Intelligence hace referencia a la toma de decisiones por parte de las personas a partir de la información. Esas son las tres palabras claves según Microsoft: Personas, información y decisiones.

Luego, hace un recorrido sobre los distintos hitos históricos que nos han llevado hasta la situación actual. Menciona los siguientes:

• 1969: Creación del concepto de base de datos (Codd)
• 1970’s: Desarrollo de las primeras bases de datos y las primeras aplicaciones empresariales (SAP, JD Edwards, Siebel, PeopleSoft). Estas aplicaciones permitieron realizar “data entry” en los sistemas, aumentando la información disponible, pero no fueron capaces de ofrecer un acceso rápido y fácil a dicha información.
• 1980s: Creación del concepto Datawarehouse (Ralph Kimball, Bill Inmon), y aparición de los primeros sistemas de reporting. A pesar de todo, seguía siendo complicado y funcionalmente pobre. Existían relativamente potentes sistemas de bases de datos pero no había aplicaciones que facilitasen su explotación.
• 1989: Introducción del término Business Intelligence (Howard Dresner).Ejem.
• 1990s: Business Intelligence 1.0. Proliferación de múltiples aplicaciones BI. Estos proveedores resultaban caros, pero facilitaron el acceso a la información, y en cierto modo agravaron el problema que pretendían resolver (¡Había aún más versiones de la verdad!)
• 2000s: Business Intelligence 2.0. Consolidación de las aplicaciones BI en unas pocas plataformas Business Intelligence (Oracle, SAP, IBM, Microsoft). A parte de la información estructurada, se empieza a considerar otro tipo de información y documentos no estructurados.

Pero, a pesar de todos los “fracasos”, sigue siendo un buen momento para el Business Intelligence, es una prioridad en todas las empresas, que mueve mucho dinero.

Según Microsoft, el BI se ha preocupado poco de las personas, y muchos de los sistemas y la tecnología (opinión que comparto, por cierto).

Espero tener otro día la posibilidad de hacer una pincelada sobre la oferta de Microsoft en el ámbito Business Intelligence. Según dicen, las herramientas ya las tenemos, ¿Se referirán al Excel?...

He cambiado la estructura del blog. Ahora está organizado por pestañas y la pantalla queda algo más "limpia". Espero que os guste y que facilite la lectura de los artículos.

Entre las novedades, he creado el apartado de "software BI", y durante los próximos días espero hacer un repaso sobre los diferentes productos de cada proveedor Business Intelligence, indicando sus fortalezas y debilidades.

He dado de alta este blog de Business Intelligence en español en la web de Technorati. Technorati es un agregador de blogs, tal vez el más importante. En teoría, esto sirve para dar más visibilidad al blog, ya que mucha gente accede a este agregador, y además puede repercutir en el posicionamiento que hace Google.

No sé. Ya veremos. A mi me da la impresión que contiene demasiada publicidad y que es demasiado generalista. ¿conocéis Technorati? ¿Lo utilizáis? ¿Qué impresión os merece?

Por cierto, sigo mejorando la apariencia del blog. Hoy Business Intelligence fácil estrena una nueva cabecera flash (aunque no será la definitiva). Espero que os guste.

7x4wus9vbm