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, …