
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:
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.
Categoría: Serie DWH
Palabras clave: DWH
Comentarios: Este artículo tiene 2 comentarios.
¡Deja un comentario!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).
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).
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.