1 deJuliode 2000 Vol. 1 No.1


CÓMO DISEÑAR GRANDES VARIABLES EN BASES DE DATOS MULTIDIMENSIONALES
Manuel de la Herrán Gascónhttp://www.eside.deusto.es/profesores/mherran/
Ingeniero Informático por la Universidad de Deusto

Vicent Castellar-Busó http://www.uv.es/~buso/
Doctor en Matemáticas por la Universidad de Valencia

(continuación...)

Cálculo del tamaño de una variable multidimensional

En lo que sigue supondremos que trabajamos con un sistema M-OLAP. Durante el diseño de la base de datos multidimensional, antes de la creación de los objetos, es interesante predecir, para cada una de las variables que se espera utilizar, y cuyo tamaño se supone importante:

  • El tamaño en disco ocupado por la variable
  • El tiempo que tardará el proceso de agregación de los valores acumulados

Sin tener en cuenta el uso de técnicas de compresión, el tamaño de una variable multidimensional dependerá del número de valores de cada una de las dimensiones por las que "se mueva" la variable, incluyendo los valores acumulados.

Dada una variable multidimensional V dimensionada por D1, D2,... Dn

V(D1 D2 ... Dn)

Siendo N[Di] el número de valores de cada dimensión, el número de celdas de la variable multidimensional NC[V] será el producto de estos valores, es decir:

Por ejemplo, dada la variable multidimensional

V.Ventas (<Artículo>, <Geografía>, <Tiempo>)

Siendo

N[<Artículo >] = 10

N[<Geografía>] = 50

N[<Tiempo>] = 20

Podemos calcular el número de celdas de la variable de la forma:

NC[V] = N[<Artículo >] * N[<Geografía>] * N[<Tiempo>] = 10 * 50 * 20 = 10000

Para los análisis posteriores nos será de gran utilidad distinguir cuántas de estas celdas representan información acumulada y cuántas representan un detalle. Entendemos como celdas de detalle aquellas que son hojas en todas las dimensiones. Normalmente las variables multidimensionales como V.Ventas y sus dimensiones se definen de forma que las celdas de detalle de la variable puedan ser cargadas mediante la asignación directa de cada una de las líneas de datos contenidas en el fichero de entrada. Un fichero que cargue nuestra variable de ejemplo podría tener el siguiente aspecto:

// Las lineas 1,2 y 3 son de cabecera, y los datos reales comienzan en la linea 4
// La linea 3 es un comentario que describe el formato de los datos
// "<Artículo >";"<Geografía>";"<Tiempo>";"Unidades Vendidas"
"1";"32";"199912";"325"
"1";"48";"200001";"222"
"3";"32";"200001";"125"
"3";"48";"200001";"1235"

Cada una de las líneas leídas de este fichero se imputará, en principio, a una celda de detalle. Asignaremos cada dato (el campo Unidades Vendidas) a una celda del cubo de V.Ventas, identificada por un valor de artículo, un valor de geografía y un valor de tiempo.

Como ya se ha dicho, las celdas de detalle son aquellas que son hojas en todas las dimensiones. Las celdas de acumulados (o las celdas que no son de detalle) serán aquellas que no son hojas en todas las dimensiones, o lo que es lo mismo, que son celdas de acumulados por al menos una de las dimensiones.

Aunque se trabaje con un número de dimensiones mayor que tres, las variables n-dimensionales se suelen representar mediante cubos, ya que estas figuras ofrecen una aproximación intuitiva útil a la n-dimensionalidad. Otra forma de ofrecer una visión intuitiva de las variables multidimensionales, esta vez incidiendo en el aspecto de las jerarquías de las dimensiones, es mediante pirámides.

 

Fig. 2.- Analogía piramidal de los datos

En esta representación, las caras de la pirámide que no son su base representan dimensiones, destacándose en ellas las jerarquías. Los valores de detalle corresponden con los bloques inferiores, que soportan al resto. Esta analogía tiene el inconveniente de ocultar el hecho de que existen datos indexados por cualquier valor de cualquier dimensión relacionado con cualquier otro de cada una de las demás, y no sólo cada valor de dimensión con los de su mismo nivel jerárquico, como ocurre en la pirámide.

Aunque pudiera parecer extraño, existen muchos casos en los que el número de datos calculados mediante agregación es muy superior al de los datos simplemente cargados directamente en la base de datos. Es decir, es posible que el número de celdas de acumulados sea superior al número de celdas de detalle, y tengamos una "pirámide invertida".

Si suponemos que cada dimensión tiene una única jerarquía, el número total de valores de una dimensión (Dt) será la suma de los valores que sean padres, es decir, que tengan hijos (Dp) más aquellos que no los tengan y sean por tanto nodos hoja (Dh).

En la primera dimensión
Dt1 = Dp1 + Dh1

En la segunda
Dt2 = Dp2 + Dh2

En general
Dti = Dpi + Dhi

Ya que para que una celda se considere detalle, ha de serlo por todas las dimensiones, el número total de celdas de detalle (NCD) de una variable multidimensional será el producto del número de valores hoja de cada dimensión

Podría parecernos que el número total de celdas acumuladas (NCA) sería el producto del número de valores acumulados por cada dimensión, pero esto no es así, ya que basta con que un valor de una dimensión no sea detalle para que todas las celdas referenciadas por ese valor de dimensión tampoco sean detalle.

El número total de celdas acumuladas (NCA) lo podemos calcular restando del total de celdas (NC), las que son de detalle (NCD).

NC[V] = NCD[V] + NCA[V]
NCA[V] = NC[V] - NCD[V]

El número de celdas acumuladas (NCA) será mayor que el número de celdas de detalle (NCD) cuando:

NCA[V] > NCD[V]
NC[V] - NCD[V] > NCD[V]
NC[V] > 2 * NCD[V]

Mediante una combinación de medidas analíticas y estimaciones obtenidas de la experiencia, es posible predecir con suficiente calidad la ocupación de una variable en cuanto a espacio en disco, así como el tiempo requerido para la agregación de los valores de detalle.

Ya que el tamaño de las cargas no suele variar mucho de un mes a otro, es habitual realizar experimentos de carga y agregación con algún reducido conjunto de valores de la dimensión <Tiempo>, y extrapolarlos. Por ejemplo, si la carga del detalle de un mes ocupa 5 Mb, la agregación de estos valores dura 1 hora y el tamaño de la base de datos una vez agregados los datos se ha incrementado en 50 Mb, podemos multiplicar estos valores por 12 para una estimación anual grosso modo.

Una vez que hemos estimado el espacio en disco necesario para el almacenamiento de los datos, y el tiempo requerido para las agregaciones, es posible que estos valores superen los recursos disponibles. A continuación se van a mostrar algunas posibles soluciones a estos problemas, aplicables en tiempo de diseño y en la gran mayoría de casos. Para ello, se aprovecharán algunas particularidades del uso que se hace de estas variables.

 


Dirección General de Servicios de Cómputo Académico-UNAM
Ciudad Universitaria, M
éxico D.F.