Diseño Multidimensional (para dummies)

INTRODUCCIÓN

Hasta ahora, el modelo más usado para la implementación de bases de datos ha sido el modelo relacional, orientado al procesamiento de transacciones (inserción, actualización y borrado de datos) relaciona dos tablas de datos por alguno de sus campos de forma que todos ellos son igualmente importantes.

Ver el esquema de una transacción...

De la necesidad de buscar un esquema no homogéneo (nos tienen que decir qué es lo importante) y orientado a consultas (el análisis de datos es su principal objetivo) surge el modelo de datos multidimensional o Data Warehouse. Ahora debemos hablar de un esquema que implementa un almacén de datos, donde los datos sólo se entienden en relación a un dominio definido por la decisiones de la empresa.

Más información sobre Data Warehousing...

DISEÑO MULTIDIMENSIONAL

Para realizar el diseño multidimensional de un conjunto de datos deberemos comprender los diferentes pasos o fases del diseño. En ellas se verán siempre dos puntos de vista: un primer diseño al nivel más bajo de detalle y otro a alto nivel determinado por el usuario decisor de alto cargo en una empresa.

Diseño Conceptual

Sería similar al esquema E/R en un modelo relacional, se trata de definir y llegar a un consenso de los elementos que se tratarán.

Definición

Usuario: es importante que determinemos para qué tipo de usuario se hará el diseño, es decir, qué tipo de usuario es el que tomará las decisiones en cuanto a qué y cómo tratar los datos.
Podría considerarse a bajo nivel de detalle a cualquier técnico informático y a alto nivel el directivo de la empresa para la que se trabaja.

Decisiones: deberíamos hacer una lista de las decisiones que cada uno de los usuarios tomarían con los datos. Estas decisiones determinarán todo el diseño. Se trata de dar relevancia a los datos.

A bajo nivel debería de detallarse al máximo pero a alto nivel sólo debe considerarse lo estrictamente necesario. Este es uno de los principales problemas del modelado multidimensional ya que la única manera de obtener otra nueva visión abstracta de los datos y diferente es partiendo de la implementación de más bajo nivel donde la anterior podría considerarse inútil.
Este "cambio de decisiones" se resuelve en base a las operaciones ROLL-UP o DRILL-DOWN, algo así como agrupar y descomponer, respectivamente.

Granularidad

En esta etapa debemos definir los hechos y las dimensiones. Los hechos son el foco de atención, es decir, lo que queremos medir: nº ventas; y las dimensiones será la "manera" de contar: nº de ventas en una tienda, bajo una promoción, en un año, de un producto.

Hechos

Los hechos serán por tanto aspectos cuantitativos y representativos, las dimensiones serán los aspectos que definen el cuándo, el cómo, el qué, el dónde o el quién. Obtendremos tantos esquemas en estrella como hechos haya de manera que cada hecho será el centro y las dimensiones serán las puntas de la estrella.

Para cada hecho se pueden considerar diferentes mediciones derivadas, por ejemplo, beneficio de una venta, coste, nº unidades, etc.

Dimensiones

Para las dimensiones también tendrán que ser definidas en detalle: por sus niveles y sus descriptores. En el ejemplo, si tenemos la dimensión Cuándo definida como fecha, los niveles de abajo a arriba podrían ser: día, mes, trimestre, año, TODO. Sería una agregación. Como ejemplo de descriptor para el nivel día podríamos tener día de la semana.

La idea es identificar todos los posibles niveles de abstracción donde la información podría sernos de utilidad así como sus atributos (descriptores) que os permitan obtener dicha información. Cuanto más detallemos a un nivel bajo de abstracción más posibilidades tendremos en el futuro para ejecutar ROLL-UP.

Validación

Por supuesto, habrá que validar si podemos obtener los datos de alguna manera, si ya existen, si los proporcionamos nosotros o alguna empresa externa, si hay que recogerlos mediante alguna aplicación o si podemos generarlos.

Diseño Lógico

Tablas

Cada hecho es una tabla y cada dimensión también. En la tabla de los hechos además de los identificadores (que deberían ser autogenerados para optimizar las consultas) de las dimensiones irán las mediciones que se hayan considerado. Para esta tabla se deberán definir las bases, o sea, las dimensiones que identifican a un hecho de manera unívoca.

En las tablas de las dimensiones se esperan que aparezcan los niveles y los descriptores como campos además de las claves primarias o identificadores.

Estabilidad de las dimensiones

Existe un problema común en este tipo de esquemas multidimensionales llamado el Problema de las Dimensiones Cambiantes (Slowly Changing Dimension). Esto sucede cuando, tras haber considerado una dimensión, tenemos en uno de sus registros un atributo que cambia de valor y que no podemos sobreescribir porque toda la información relativa a ese registro con el antiguo valor se perdería. Por ejemplo, es posible que a nosotros nos interese conocer información de los empleados de nuestra empresa, si uno de nuestros empleados cambiase de su residencia A a otra B y "machacamos" el registro jamás sabremos con certeza cuáles de nuestros empleados llegaron a vivir en la ciudad A.

Para ello hay que considerar qué dimensiones son susceptibles a estos cambios y analizar la forma más razonable de abordar el problema.

Estimación del tamaño

Finalmente debe considerarse una estimación del tamaño de nuestra base de datos multidimensional analizando dimensión a dimensión el máximo de registros que podría llegar a alcanzar de una forma razonada.