¿Qué es un Modelo Dimensional? Básicamente el Modelo Dimensional es el nombre que se le da a una técnica utilizada especialmente en Data Warehouses. Este modelo difiere bastante del modelo Entidad-Relación que normalmente conocemos. El Modelo Dimensional busca presentar la información de una manera estándar, sencilla y sobre todo intuitiva para los usuarios, además de que permite accesos a la información mucho más rápida por parte de los manejadores de bases de datos. Cada Modelo Dimensional esta compuesto por una tabla llamada "de hechos" y por un conjunto de pequeñas tablas llamadas "dimensiones". Cada dimensión contiene una llave primaria que se "conecta" a la tabla de hechos manteniendo una relación de 1 a muchos (1 a N).
Viendo la figura anterior comprendemos porque en los inicios este modelo también se le conoció como Modelo de Estrella . La tabla de hechos contiene incluso varias llaves foráneas, cada una de ellas hacia una dimensión, es por eso que contiene una llave primaria compuesta, es decir, que se compone de varias columnas. Además las tablas de hecho típicamente incluyen otras columnas numéricas llamadas " métricas" o "hechos", por ejemplo en la figura anterior las métricas son " Ventas en Pesos" y "Ventas en Cantidad ". ".
La información contenida en una tabla de hechos por si sola no nos dice nada, la mayoría de las veces contiene únicamente números. Por otro lado las dimensiones comúnmente contienen información descriptiva. Los atributos de las dimensiones muchas veces serán los encabezados de las columnas en los reportes. Lo bonito del modelo dimensional es que fácilmente los usuarios pueden intuir el contenido de la información y sobre todo permite a las aplicaciones de inteligencia de negocios extraer la información increíblemente rápido.
El modelo estrella 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 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 presentación (botella de cristal, PET no retornable, aluminio, etc.), la familia (bebidas), la subfamilia, la categoría, la subcategoría, 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) porque producto (product) es el elemento más abajo en la jerarquí a o más granular. Véalo 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 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 subcategoría, el departamento, la familia, la categoría. 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 región y el país al que pertenece. Entonces país 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 vendió (producto_id), en que tienda (store_id) y en que día (time_id).
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 .
Cuando estamos construyendo nuestro Data Warehouse tenemos que diseñar la tabla central que es la que guardará los hechos. A diferencia de un sistema transaccional donde en una tabla tenemos el total de la factura, en otra el total de la orden de compra, en otro el tipo de cambio (y así sucesivamente) en un Data Warehouse (DWH) los hechos (las cosas que sucedieron) están en una única tabla. Para aclarar la palabra hechos: ¿qué sucedió en mi compañia? Pues vendí, compré, vendí en unidades, tuve un # de empleados. Entonces en la tabla de hechos se guardan las ventas, las ventas en unidades, las compras, etc.. Todo lo que sean indicadores. Tampoco se trata de hacer una tabla gigantesca que tenga lo de recursos humanos + lo de ventas + lo de produccion + lo de telemarketing + ¡todo! No hay que exagerar… Normalmente las cosas que están en la tabla de hechos tienen afinidad entre sí. De esta forma tendremos una tabla de Hechos de Ventas, una de inventario, una de Recursos Humanos, una de produccion, etc. No todas las herramientas de explotación de Data Warehouse permiten hacer reportes o informes tomando información de 2 o más tablas de hechos ; es por esto que a veces en un DWH se suelen encontrar cosas extrañas como las ventas y el # de empleados en la misma tabla de hechos ( para hacer el calculo de Ventas/#Personas). El problema de esto es que el DWH vuelve caótico: cada vez que necesite hacer un calculo entre 2 tablas de hechos hago un nueva table de hechos que junte las 2 y entonces me lleno de tablas de hechos o cubos ( si trabaja con cubos Rolap a esto se le llama cubitis). Mejor encuentre una herramienta que permita tomar información de multiples tablas de hechos. Artus soporta crear indicadores calculados con columnas de 2 o más tablas de hechos . No solo eso, si no que también permite mezclar en el tablero de control información de diferentes proveedores de cubos: SAP, Analysis Services, Rolap ( Oracle, Sybase, DB2, Redbrick ).
