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.
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.
