Buenas
aunque no lo parezca, hay cosas mas dificiles que el cubo de Bedlam; una de ellas puede llegar a ser comprender algunos conceptos de los otros cubos.
Supongamos una Base de Datos de Producción de una solución; usualmente estas bases de datos, han sido normalizadas y si tenemos un dato como la descripción de un producto (en la tabla Produto); lo normal es que si actualizamos esta información la misma se refleje (a través de joins) en todas las relaciones que posea en la base de datos para poder trabajar con la información correcta.
Cuando necesitamos consultar esa información cruzando diferentes entidades, un JOIN que utilice las claves correspondientes en cada entidad nos devolverá los resultados actualizados que necesitamos.
En una Base de Datos de DataWareHouse, dentro de una dimensión existen muchos atributos relacionados entre sí que forman una jerarquía (hierarchy, paso de poner los nombres en castellano); por ejemplo un producto que pertenece a una categoría; que a su vez es parte de un grupo.
Producto <--> Categoría <--> Grupo
Cuando necesitamos consultar esa información, usualmente necesitamos realizar demasiados JOINS que suelen afectar el rendimiento de las aplicaciones. Por ejemplo, si deseamos consultar un Producto en particular relacionado con un Año, la relacion se hace por cada registro de la tabla Producto con cada registro de la tabla Año; luego también deberemos agregar las relaciones correspondientes con Categoria y con Grupo. Y sobre este total de registros ademas tendremos que filtrar sobre un año en particular.
Año <--> (Grupo <--> Categoria) <--> Producto
Esto hace que los querys contra una base de datos multidimensional (toma palabra del futuro !!!) sean mucho mas lentos que las consultas comunes contra una base de datos relacional. Pero y este es un gran PERO un detalle importante en las base de datos de DataWareHouse es que los datos no cambian dinámicamente como en producción, por lo que tenes datos "redundantes" o repetidos no afecta a la perfomance de la misma (si al tamaño, pero hoy los discos son baratos y sql es cada vez mas rápido).
Esto nos lleva a una práctica comun en BI, donde todos los atributos de una tabla (antes llamados filas) se almacenan en una única dimensión (y se comienza a repetir la información como churros). El concepto se basa en que las tablas de dimensiones son pequeñas, en comparacion con las tablas de hecho (Fact Tables), y cuando cruzamos informacion entre dimensiones las mismas suelen tener una performance de respuesta muy buena.
Almacenar todos los atributos desnormalizados no se si esta palabra existe en una tabla es lo que se conoce como STAR SCHEMA, porque usualmente se trabaja con una única tabla con toda la información "rodeada" de una tabla para cada dimensión que sea necesaria.
Nota: Una imagen vale mas que mil palabras -->
Luego cuando comenzamos a normalizar las tablas de dimensiones nuestra STAR se comienza a parecer mas a un SNOWFLAKE SCHEMA (copo de nieve).
Nota: No conseguí una imagen buena :(
Y para finalizar, nuevamente hago un llamado al Sentido Común en el diseño de las bases de datos; es poco recomendable que los cubos tiren directamente de la Base de Datos de Producción; por lo general se recomienda crear una nueva Base de Datos de DataWareHouse no mezclar las bebidas en este proceso e implementar algun proceso de ETL para completar los datos de DataWareHouse a partir de los datos de Producción.
Saludos
El Bruno
PD: los animo a sentarse un rato con el cubo de Bedlam; verán que no es tan fácil :P.