Business Intelligence
jueves, 18 de junio de 2009

Máximo nivel de detalle

El máximo nivel de detalle debe estar contemplado en un sistema Business Intelligence

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.

  1. Cristianviernes, 04 de diciembre de 2009

    Concuerdo contigo, ya que mantener la mayor granularidad en el modelo dimensional nos permite extender fácilmente este mismo ante nuevos requerimientos.

    En los proyectos en los que he participado, eso sí, el modelo relacional normalizado que colocas como área principal del DWH no lo implementamos, pasamos directo desde el staging al dimensional requiere un poco más de trabajo con ETL pero sumando y restando el tiempo de desarrollo tiende a ser menor que si se hiciera un modelo relacional normalizado (a la Inmon).

  2. BI FACILviernes, 04 de diciembre de 2009

    Es un debate muy interesante. ¿Realmente es necesario un "modelo relacional" independiente del "modelo dimensional" que atacan las herramientas de BI?

    Como dices, esta estructura es voluminosa, y sólo por ello es posible que el primer proyecto sea más largo que si omitésemos este repositorio.

    Sin embargo, el "modelo relacional" aporta alguna ventajas que nos pueden facilitar el mantenimiento del proyecto. Particularmente, me transmite "seguridad" el hecho de tener localizado y perfectamente identificado todo el detalle de información. En el "modelo relacional" está toda la información sin duplicidades, y seré capaz de responder cualquier pregunta que me hagan ahora o en el futuro. En el modelo relacional SOLO debo preocuparme de guardar e integrar la información.

    En cambio, en el "modelo dimensional" me preocupan otros aspectos. Me preocupa el rendimiento de las consultas, y la facilidad que tendrá el usuario para acceder y consultar la información. Por lo tanto, crearé agregados, y precalcularé KPI, y...

    Si unificásemos estos dos repositorios en uno único, tarde o temprano me encontraré con el problema de escoger una solución de compromiso. ¿normalizo u optimizo? ¿Guardo este dato que tal vez algún día lo necesiten o lo omito para que vaya más rápido?

    Existen otros pros y otros contras, pero para mi eso sólo ya justifica la existencia del "modelo relacional". En cualquier caso deben valorarse también otros aspectos, como si el operacional es fácilmente accesible y guarda suficiente historia (por si en el futuro la necesitamos).

¿Qué es BI?

Las metodologías Business Intelligence utilizan la información para mejorar la gestión de las empresas.

Gracias al software de BI, los usuarios pueden acceder y analizar los datos con facilidad, y tomar mejores decisiones.

Últimos comentarios

Valid XHTML 1.1