Las soluciones de OLAP son
típicamente usadas para presentar la agregación de datos de manera eficiente,
mientras otras tareas son atendidas por el mismo servicio. Los cálculos y
almacenamiento de los datos agregados permiten 
para que los usuarios finales puedan cruzar grandes volúmenes de información con tiempos
de respuestas muy efectivos.

 

Existen dos puntos esenciales a ser  considerados
en el diseño de una solución de OLAP: DATA EXPLOSION y SPARSITY.

 

DATA EXPLOSION

Este término se entiende como la
tendencia de los cubos a crecer exponencialmente debido al uso de agregaciones
excesivas. Esto ocurre porque muchas veces son la idea de aumentar el desempeño
se hacen muchos precálculos de agregaciones para que al momento de consultarlas
los tiempos de respuesta sean mínimos. El problema es que esto consume mucha
capacidad de almacenamiento.

 

SPARSITY

Es una medida de la densidad de
datos dentro de un cubo o de una dimensión. 
Idealmente los cubos no deben contener celdas vacías, en la realidad los cubos
contendrán celadas bases vacías en sus dimensiones para posteriores recálculos
del cubo.

 

DIMENSION SPARSITY, de manera
análoga, es la medida de la cantidad de miembros vacíos dentro de una
dimensión. Esto quiere decir miembros de la dimensión que no tiene datos
asociados en ninguna FACT TABLE. Mientras más miembros vacíos
tenga
una dimensión, más probable es que produzca SPARSITY en los cubos en los cuales
esa dimensión se usa.

 

La causa principal de SPARSITY es
el uso de dimensiones con espacios o datos no relacionados. Esto parece poco
importante en términos de tamaño, pero usado en grandes volúmenes de datos  puede
producir un crecimiento exponencial del tamaño de los cubos.

 

Diseño de dimensiones

 

El diseño de las dimensiones es la llave de cubos de gestión
eficientes y de valor porque en rigor las FACT TABLE son medidas agregadas de
estas dimensiones. La clave del diseño de una dimensión efectiva es la
estructuración de los datos subyacentes.

 

Existen dos preguntas básicas que
deben ser consideradas en el diseño de las dimensiones de un cubo. La primera
es que modelo se usará, las opciones son “estrella”
o “copo de nieve”.

 

 

El modelo estrella tiene dos
características principales:

 

1. Una o más tablas de dimensiones, cada una con su llave primaria, con uno o más
   campos descriptivos que se usan para determinar el nivel de atributos de cada
   dimensión. Cada dimensión se encuentra en una sola tabla.

 

2. Una FACT TABLE que contiene campos numéricos que están
   mapeados
   con las llaves primarias de las dimensiones.

 

 

El siguiente diagrama muestra un
ejemplo del modelo estrella.

 

 

 

El modelo de copo de nieve es
caracterizado por:

 

1. Una o más tablas de dimensiones, cada una con su llave primaria, con uno o más
   campos descriptivos que se usan para determinar el nivel de atributos de cada
   dimensión. La diferencia es que las dimensiones pueden tener más de una tabla
   que le suministran más atributos a los miembros de la dimensión.

 

2. Una FACT TABLE que contiene campos numéricos que están
   mapeados
   con las llaves primarias de las dimensiones.

 

El siguiente diagrama muestra un
ejemplo del modelo copo de nieve.

 

 

 

La razón más común para usar el
modelo de copo de nieve es reducir el espacio de almacenamiento requerido para
dimensiones de gran tamaño. Los atributos de menor
cardinalidad
son sacados de la tabla principal de la dimensión, para ser puestos en una
tabla secundaria que se relaciona con la principal a través de una llave de la
segunda. Esto reduce notablemente el requerimiento de almacenamiento pero
aumenta la complejidad del modelo.

 

Una segunda razón para utilizar el
modelo de copo de nieve es habilitar 
el análisis de los atributos de segundo nivel sin presentar los primeros. Esto es una
razón desde el punto de vista de uso de la información más que desde la
perspectiva del desempeño.

 

 

La segunda pregunta básica del
diseño de dimensiones es ¿Dimensiones
privadas o compartidas? Aquí el punto es decidir si la dimensión que se
está diseñando será exclusiva de un cubo o será compartida por más de uno.

 

Además las dimensiones  privadas
no pueden ser usadas como fuentes de datos para crear
dimensiones virtuales.

 

Las dimensiones privadas tienen una
ventaja en términos de administración porque siempre son procesadas cuando el
cubo es recalculado.  Además este
tipo de dimensiones provee un nivel de seguridad para datos sensibles porque
sólo es usada en el cubo para lo cual fue diseñada.

 

Las dimensiones privadas proveen
una ventaja en desempeño porque hacen un uso más eficiente de la memoria, los
miembros de estas dimensiones sólo son cargados una vez y puestos en CACHE.
Esto permite tiempos de respuesta más rápidos para consultas que involucran
este tipo de dimensiones.

 

Está decisión debe ser tomada con
cuidado ya que las dimensiones definidas inicialmente compartidas pueden ser
convertidas en privadas mientras que al revés no es posible hacer una
transformación.