Hemos dicho antes, en las tablas de hecho además de las medidas vamos a almacenar las claves de acceso a las dimensiones asociadas. Aquí tenemos un ejemplo de tablas dentro de un Data Warehouse que cumplen con el Modelado Dimensional.

Hoy vamos a comentar qué son las dimensiones.

Las dimensiones son la base de este tipo de modelado, describen los objetos del negocio que son los que crean o reciben los eventos que controlan los hechos. La información se clasifica en base a los aspectos que son de interés para el negocio. Los procesos de negocio (hechos) son los verbos de las acciones de negocio en los que participan los sujetos u objetos (dimensiones). Por eso cada tabla de dimensiones se relaciona con cada hecho o acción en la que participa, siendo lo normal que en el proceso de modelado nos encontremos con una matriz que relaciona los hechos con las dimensiones. Esta matriz, simplificada para una única tabla de hechos, se puede expresar de esta forma

Vamos a detenernos un momento, para recordar algo sobre las características del Data Warehouse: datos integrados, orientados a temas, variantes en el tiempo y lo que es muy importe, no volátiles.

Dicho esto, vemos que las dimensiones son tablas de una BBDD relacional que contienen atributos que son como columnas homogéneas en cuanto al tema: productos, pacientes. Es el punto de entrada de los datos sobre estos objetos o sujetos que pueden presentarse en varios estados, que varían con el tiempo; pero siempre habrá un único estado activo de cada instancia. Un producto en cada momento pertenece a una única categoría, tiene un único precio unitario y un único IVA.

Al crear dimensiones, ocurre un proceso de de-normalización al recombinar los atributos de una dimensión, desde las distintas tablas normalizadas, en una tabla de dimensión para simplificar el modelo a ojos del usuario y eliminar JOINS.

Veamos, por ejemplo, la transformación que ocurre con el tratamiento de los Productos desde AdventureWorks.

Si miramos la Base de datos AdventureWorks2008R2 que contiene el relacional transaccional nos encontramos con todas estas tablas para el tratamiento de los datos relativos a Productos.

Mientras que si vemos en AdventureWorksDW2008R2, que contiene el relacional DW, vemos que ha disminuido considerablemente en cantidad de tablas y en cantidad de columnas también.

Aquí se cumple la de-normalización y eliminación de muchos JOINs y además la diferencia entre las columnas está dada porque en el Data Warehouse se excluye la información que no será usada por el proceso de sistemas de soporte de decisiones, mientras que la información de las orientadas a las aplicaciones, contiene datos para satisfacer de inmediato los requerimientos funcionales y de proceso, que pueden ser usados, o no, por el analista de soporte de decisiones.

Hemos dicho que en las tablas de Dimensiones hay columnas que son candidatas a convertirse  en atributos. Veamos las columnas de DimProduct.

Vamos a ver los tipos de atributos que nos encontramos en este modelo.

Atributo clave

Existe una columna o atributo clave, ProductKey, que tiene estas características.

Todos los demás atributos en principio se relacionan con el atributo clave.

Atributos descriptivos de tipo cadenas

Nos sirven para filtrar o segmentar el análisis, por ejemplo:

Atributos descriptivos de tipo numérico

Cumplen las mismas funciones de filtrado y segmentación de datos. El tratamiento de datos numéricos continuos en las dimensiones, carece de utilidad cuanto mayor sea el número de posibles valores, por lo que hay que emplear técnicas para discretizar estos datos. Ya veremos este tema, de momento nos quedamos con ejemplos de columnas de la tabla DimProduct.

Atributos descriptivos para trabajar con varios idiomas      

Una funcionalidad importante que añade valor a los datos multidimensionales es la posibilidad de mostrar datos y metadatos en un idioma en particular. Sobre los metadatos hablamos otro día, ahora veamos que estas columnas muestran los mismos datos una y otra vez en idiomas diferentes.

 

Atributos de enlace con otras tablas

En el modelado dimensional es imprescindible establecer correctamente las relaciones entre tablas, ya sea entre hechos y dimensiones, como entre dimensiones.

En el caso de los atributos de enlace han de ser de tipo numérico si van a formar parte del cubo (ProductKey para enlazar con la tabla de hechos y ProductSubcategoryKey para enlazar con la tabla de dimensiones DimProductSubcategory).

Además, hay un tipo de relación muy importante que es la que hay que mantener con el Modelo de Negocio relacional transaccional. En este caso, la clave se mantiene caso excepcional, del tipo que sea, para el  del atributo clave en el negocio (ProductAlternateKey).

Por tanto, en una tabla de dimensiones nos encontramos con atributos que sirven de enlace con otros componentes del modelo (otras tablas de hechos y/o dimensiones) o son utilizados por el cliente final como elementos para filtros o como etiquetas de filas y/o columnas de informes, estos últimos tienen igual valor y utilidad si son numéricos o de cadena.

Algunos atributos se diseñan de tal forma que ya desde el DataWarehouse se relacionan entre sí, estableciendo dependencias funcionales. Este aspecto del modelado es de gran importancia, por lo que será descrito utilizando como ejemplo la tabla DimProduct de la Base de datos AdventureWorksDW en cualquiera de sus versiones, siempre que sea DW. Es nuestra misión conseguir que los atributos no se relacionen únicamente con el atributo clave por temas de rendimiento en el procesado de las dimensiones… esto ya es tema aparte… Ahora estamos hablando de diseño y durante el diseño, veremos cómo mejorar el modelo haciendo que algunos atributos se relacionan con atributos no clave. Regresaremos a este ejemplo para ver distintos escenarios.

En la próxima entrada continuaremos describiendo temas relativos al Modelado dimensional de datos.