Hay 2 modelos para crear un Data Warehouse, el modelo estrella o el copo de nieve. Yo prefiero el modelo estrella, ya que el tiempo de respuesta que provee es más rápido y hace que el servidor trabaje menos.
El concepto de Estrella es bastante sencillo. Hay que diseñar las tablas usando una tabla central para los hechos, tablas para los los catálogos y una tabla de tiempo.
El meollo del diseño de las tablas en el modelo estrella está en los catálogos. Tiene que poner en una sola tabla todo aquello que se pueda deducir del elemento más granular de la tabla y que está más abajo en la jerarquía.
Por ejemplo, si usted tiene un catálogo de productos, el elemento más granular es el producto ¿qué se puede deducir del producto? Pues la marca, el empaque, la presentacion (botella de cristal, PET no retornable, aluminio, etc.), la familia (bebidas), la subfamilia, la categoría, la subcategoria, el color, la talla si aplica, etc.
Bueno pues todo esto se coloca en la misma tabla.
El campo llave de esa tabla es el product_id (la llave de producto) por que producto (product) es el elemento más abajo en la jerarquía o más granular. Vealo de esta forma: una marca tiene productos, la familia agrupa productos, la subfamilia igual, la categoría igual, el color igual. El producto es el único que no agrupa a nadie, entonces esa es la la llave.
Si usted le hiciera un select a ese catálogo de productos el resultado sería el siguiente.
Puede ver que en el mismo registro se almacena el producto, la marca, la subcategoria, el departamento, la familia, la categoria. Todo lo que se puede deducir del producto está ahí.
Lo mismo pasa con las tiendas. De la tabla de tiendas (ver tabla Stores en el diagrama) se puede deducir la region y el pais al que pertenece. Entonces pais y región los pongo en la misma tabla que tienda.
Para mejorar todavía más el tiempo de respuesta coloque en la tabla el campo llave y el descriptor como se muestra en la siguiente imagen.
Si hace esto en el query SQL que escriba para obtener datos de la estrella podrá usar:
where
IdBrand = 15
en véz de:
where
Brand = ‘Washington’
Tendrá un mejor tiempo de respuesta si usa llaves. Entonces siempre en los catálogos ponga además de los descriptores el campo llave de cada descriptor.
TIP: Si está pensando crear un cubo con los Analysis Services de Microsoft usando esta estrella, el poner la llave en la estrella hace que el cubo se reduzca de tamaño y el tiempo de respuesta se acelere. Solo tenga cuidado de que al crear la dimensión, en propiedades de la dimensión ubique y use la propiedad “llave de la dimensión”.
TIP: Para las llaves trate de que siempre sean numéricas y de no usar llaves compuestas.
TIP: Si va a seguir el tip anterior, puede ayudarse poniendo en los catálogos además de la nueva llave inventada por usted, la llave original para la dimensión. Yo siempre las identifico con Id y Cve, la que termina en ID es inventada por mí y la que termina o comienza en CVE es la original.
¿A partir del producto yo puedo deducir en que tienda se vendió? Suponiendo que hablamos de supermercados y en cada tienda se pueden vender los mismos productos entonces la respuesta es NO, no se puede deducir qué tienda vendió qué producto. Esto se resuelve en la tabla de hechos poniendo ahí que producto se vendio (producto_id), en que tienda (store_id) y en que día (time_id).
Esto es el modelo estrella.
IMPORTANTE: No se quede con la idea que al hacer los catálogos redundantes va a desperdiciar todo el disco duro. La redundancia es solo en los catálogos no en los hechos, usted puede tener un catálogo de 100,000 productos pero millones y millones de transacciones. Lo que hace que un datawarehouse crezca normalmente es la tabla de hechos. Si todavía está renuente y saca a relucir las reglas de Codd de normalizacion, para no entrar en polémica digamos que este es uno de los extraños casos donde lo que aprendió en la universidad lo puede tirar a la basura
.
Para complentar esto puede consultar los posts La tabla de hechos y Algunas recomendaciones para la tabla de hechos. Respecto a la tabla de tiempo (TimeDim) puede leer La dimensión tiempo y los otros campos de la tabla de tiempo.
Si quiere ver como convertir una estrella a un cubo puede consultar como hacer un cubo con Artus.


[...] que contenga la información. Es decir, usted debe de construir unas tablas siguiendo el modelo estrella y llenarlo con datos. Un modelo estrella no es otra cosa que una tabla con [...]
[...] maneras especiales o modelos son el copo de nieve y estrella. Cada uno tiene sus ventajas y [...]
el modelo estrella no es para hacer datawarehouse.
El modelo estrella es para hacer cubos, ya sea olap, rolap, o molap.
para hacer datawarehouse se puede ocupar un modelo relacional cualquiera ya qe al dw se conectan distintos dispostivos analiticos; mineria, consultas adhoc, softwares analiticos, cubos olap, se alimentan datamart, etc, etc.
creo existe un error al respecto en este concepto, ahora si deseas hacer un datawarehouse solamente para hacer funcionar un cubo lo puedes hacer, pero seria solamente para el cubo, lo limitarias al dw a que sea utilizado solamente por el cubo.
quien mejor que Kimball para dirimir el asunto…
Drawing the line between Dimensional Modeling and ER Modeling Techiques by Ralph Kimball
hay harto que aprender
Juan, con todo respeto me parece que estás equivocado. Si es copo de nieve o estrella no tiene nada que ver con los cubos. De hecho puedes hacer cubos a partir de un modelo “snowflake” y no habrá gran diferencia.
Esta elección se trata más bien de otros asuntos:
1) Facilidad de comprensión del modelo
2) Planes de ejecución del motor de base de datos
3) Espacio para almacenamiento
4) Adaptabilidad a cambios del modelo
5) Transformación de datos transaccionales en información estratégica
El punto 5 es el más importante. Cuando has conseguido convertir datos en información, definitivamente estamos hablando de un Datawarehouse y aquí, los modelos de estrellas son sin duda la mejor elección.
El tema de los cubos es otro asunto. Ahora bien, que un Datawarehouse normalmente suele convenir montarlo sobre OLAP y cualquiera de sus variaciones (ROLAP, MOLAP, HOLAP), es otro tema.
Saludos.
Excelente blog, he comprendido mas sobre el modelo estrella, pues soy un completo novato en este tema. Segun entiendo una dimension es una tabla ( para este caso, storage, promotions, product, timeDim)? es lo mismo que decir catalogo?. Agradezco la aclaracion.
Saludos
Hola Hugo,
si, se puede decir así. Las dimensiones son los catálogos
saludos
Adrian
Si todavía está renuente y saca a relucir las reglas de Codd de normalizacion, para no entrar en polémica digamos que este es uno de los extraños casos donde lo que aprendió en la universidad lo puede tirar a la basura
Estas loco?
explicate mejor
hnx. Significa que en las dimensiones no se utiliza la 3 normalización!