QUE ES OLAP?

(PROCESAMIENTO ANALTICO
EN LNEA)

OLAP, R-OLAP y M-OLAP.
OLAP es la sigla de On-line Analytical Processing, para diferenciar de
OLTP (On-line Transation Processing).

Un sistema OLAP se puede entender como la generalizacin de un
generador de informes. Las aplicaciones informticas clsicas de consulta,
orientadas a la toma de decisiones, deben ser programadas. Atendiendo a
las necesidades del usuario, se crea una u otra interfaz. Sin embargo,
muchos desarrolladores se dieron cuenta de que estas aplicaciones eran
susceptibles de ser generalizadas y servir para casi cualquier necesidad,
esto es, para casi cualquier base de datos. Los sistemas OLAP evitan la
necesidad de desarrollar interfaces de consulta, y ofrecen un entorno nico
valido para el anlisis de cualquier informacin histrica, orientado a la toma
de decisiones. A cambio, es necesario definir dimensiones, jerarquas y
variables, organizando de esta forma los datos.

Para los desarrolladores de aplicaciones acostumbrados a trabajar con
bases de datos relacionales, el diseo de una base de datos
multidimensional puede ser complejo o al menos, extrao. Pero en general,
nuestra experiencia nos dice que el diseo de dimensiones y variables es
mucho ms sencillo e intuitivo que un diseo relacional. Esto es debido a
que las dimensiones y variables son reflejo directo de los informes en papel
utilizados por la organizacin.

Una vez que se ha decidido emplear un entorno de consulta OLAP, se ha de
elegir entre R-OLAP y M-OLAP.

R-OLAP es la arquitectura de base de datos multidimensional en la que los
datos se encuentran almacenados en una base de datos relacional, la cual
tiene forma de estrella (tambin llamada copo de nieve o araa). En R-OLAP,
en principio la base de datos slo almacena informacin relativa a los datos
en detalle, evitando acumulados (evitando redundancia).

En un sistema M-OLAP, en cambio, los datos se encuentran almacenados en
archivos con estructura multidimensional, los cuales reservan espacio para
todas las combinaciones de todos los posibles valores de todas las
dimensiones de cada una de las variables, incluyendo los valores de
dimensin que representan acumulados. Es decir, un sistema M-OLAP
contiene precalculados (almacenados) los resultados de todas las posibles
consultas a la base de datos.

M-OLAP consigue consultas muy rpidas a costa de mayores necesidades
de almacenamiento, y retardos en las modificaciones (que no deberan
producirse salvo excepcionalmente), y largos procesos batch de carga y
clculo de acumulados. En R-OLAP, al contener slo las combinaciones de
valores de dimensin que representan detalle, es decir, al no haber
redundancia, el archivo de base de datos es pequeo. Los procesos batch
de carga son rpidos (ya que no se requiere agregacin), y sin embargo, las
consultas pueden ser muy lentas, por lo que se aplica la solucin de tener al
menos algunas consultas precalculadas.
OLAP describe una clase de servidores de bases de datos que estn
diseados para permitir acceso y anlisis ad-hoc de los datos. Mientras que
las transacciones residen en Bases de Datos Relacionales (BDR) o en otro
tipo de archivos, OLAP logra su mxima flexibilidad y poder utilizando la
tecnologa de Bases de Datos Multidimensionales (BDM). Es por esto que
ltimamente BDM y OLAP se los utiliza como sinnimos.
Esta nueva y sofisticada tecnologa provee a los usuarios con poderosas
funciones para el anlisis, sntesis y consolidacin de datos (anlisis de
datos multidimensional) con un mnimo conocimiento de la estructura de los
mismos.


Las aplicaciones OLTP estn caracterizadas por varios usuarios creando,
actualizando o recuperando registros individuales. Las aplicaciones OLAP
son usadas por analistas y gerentes que frecuentemente quieren altos
grados de agregacin de los datos y desde distintas perspectivas y focos
(totales de ventas por regin, por lnea de producto, ver la tendencia de lo
presupuestado vs. Lo real, etc.). Las bases de datos OLAP son normalmente
actualizadas como ya se mencion anteriormente en forma batch, y en
general desde distintas fuentes de datos, y proveen un poderoso back-end
analtico para mltiples aplicaciones de usuarios.

Mientras que las BDR son buenas recuperando una pequea cantidad de
registros rpidamente, no son buenas para recuperar grandes volmenes y
haciendo sumarizaciones al vuelo. Bajos tiempos de respuesta y un abusivo
uso de los recursos de los sistemas son las caractersticas comunes de las
Aplicaciones de Soporte de Decisin desarrolladas con tecnologa
relacional.

Muchos de los problemas analticos que se tratan de resolver con tecnologa
relacional, son en s mismos de naturaleza multidimensional. Por ejemplo,
los queries SQL para crear totales de productos vendidos por regin, ventas
de regiones por producto, etc.; involucran el barrido de todos o casi todos
los registros en una base de datos de marketing y puede tomar horas de
proceso. Un server OLAP puede resolver estos queries en segundos.

OLTP OLAP

o Atomizado Sumarizado
o Datos Actuales Datos Histricos
o Un Registro a la Vez Muchos Registros a la vez
o Orientado a lo Operativo Orientado a un Tema
o Datos Operativos Datos Multidimensionales
o Datos Actualizables Datos Histricos (Solo Lectura)

Qu son Datos Multidimensionales?

Las BDR estn organizadas en listas de registros, cada grupo de listas
constituyen una Tabla, que en la terminologa relacional se denomina matriz
plana de tem de datos. Cada registro contiene informacin relativa al
mismo la cual est organizada en campos. Un ejemplo tpico podra ser
una lista de clientes con campos para el nombre, el nmero de cliente, su
telfono y su direccin:

Una tabla relacional est basada en un formato simple de filas y columnas.

En el ejemplo precedente, la tabla contiene cuatro columnas (llamadas
campos) y cuatro filas (llamadas registros). Si bien la tabla contiene
varias columnas de informacin, cada pieza de informacin se refiere slo a
un cliente en particular. En esencia, esta tabla posee una nica dimensin. Si
se tratara de crear una matriz de dos dimensiones donde el nombre del
cliente se describe hacia abajo y cualquier otro campo (ej.: cdigo) se
describe a la derecha, se podr ver rpidamente que slo existe una
correspondencia biunvoca (1 a 1):


Viendo Cliente por nmero de Telfono o Nmero de Telfono por
Cliente slo produce una correspondencia uno-a-uno. Es por eso que este
tipo de estructura no responde a una representacin multidimensional.

Se puede poner cualquier campo en sentido descendente, y cualquier otro
campo en sentido transversal, y la correspondencia seguir siendo 1 a 1.
Este tipo de tabla nos indica que sus datos no son multidimensionales y no
se prestan para ser incluidos en una base de datos multidimensional.

Observemos el siguiente caso en donde la correspondencia entre los
campos de la tabla relacional no son 1 a 1:


Esta Tabla Relacional tiene ms de un producto por regin y ms de una
regin por producto. Por lo tanto se presta a una representacin
multidimensional.

Una forma ms clara de ver estos datos, podra ser en un formato de una
matriz bidimensional:




Una matriz bidimensional es una forma mucho ms clara para representar
los datos que la tabla anterior.

Estos datos de ventas son inherentemente determinados por dos
dimensiones: Productos y Regiones. Si bien pueden ser expuestos en una
tabla relacional en tres columnas, se representan en una forma ms clara y
natural en una matriz de dos dimensiones. En la jerga multidimensional
podemos decir que esta tabla representa las Ventas dimensionadas por
Productos y Regiones.

Ahora veamos de qu manera se diferencian lo queries en estos dos tipos de
tablas. Si todo lo que uno va a contestarse son preguntas del tipo Cules
fueron las ventas de afeitadoras en el este?, Cuales fueron las ventas de
planchas en el Oeste?, y cualquier otro query que slo recupere un nico
nmero, entonces necesitaremos colocar estos datos en una BDM. Si por
otro lado lo que necesitamos es respondernos preguntas del tipo Cules
fueron las ventas totales de afeitadoras? o Cules fueron las ventas
totales en el este?, entonces entramos en los terrenos de los queries que
involucran mltiples valores y sumarizarlos.

Si se empieza a hablar sobre grandes bases de datos donde se deben
recuperar cientos o miles de productos, el tiempo de proceso que se
requiere en una BDR para barrer todos los registros y acumular un total,
comienza a ser inaceptable. Una BDR tpica puede barrer unos pocos cientos
de registros por segundos. Una BDM tpica puede acumular totales por filas
o por columnas en un promedio de 10.000 por segundo o ms. Como
podemos ver en un simple ejemplo, es fcil generar queries que puedan
tomarse minutos u horas para completar su proceso usando tecnologa
relacional, pero slo segundos usando tecnologa OLAP multidimensional.

Queries del tipo Cules son las ventas totales de afeitadoras? o
Determine el total de ventas para el Oeste involucra aritmtica de filas y
columnas, tal es el mtodo de resolucin en las planillas de clculo. Para
obtener respuestas al Total de ventas para el Este, la base de datos de dos
dimensiones simplemente encuentra la columna llamada Este y sumariza
todos lo nmeros en la columna. El mismo query en una BDR debe buscar y
recuperar cuatro registros individuales donde regin sea igual a Este y
realizar la acumulacin. Una BDM puede encontrar una columna completa
llamada Este y sumar todo su contenido mucho ms rpido de lo que le
llevara a una base de BDR encontrar todos los registros correspondientes al
Este. En esta clase de query una BDM posee una diferencial ventaja en
performance respecto de una BDR.

Consolidacin: La Clave para obtener Tiempos de Respuesta Rpidos y
Consistentes

El tiempo de respuesta de un query en una BDM, a pesar de su velocidad,
tambin depende de cuantos nmeros estn involucrados en un clculo al
vuelo. Lo que la mayora de los usuarios requieren es un rpido tiempo de
respuesta con independencia del tipo de query. Por lo tanto, la nica forma
de obtener en forma consistente tiempos de respuesta rpidos es pre-
calculando (consolidando) todos los totales y subtotales lgicos. Esto es de
hecho lo que la mayora de los Sistemas de Informacin realizan con sus
tablas relacionales. La diferencia es que una BDM puede realizar
operaciones aritmticas por filas y columnas utilizando lgebra matricial y
vectorial, mientras que una BDR debe ser barrida (por algn criterio de
seleccin, columna o ndice). Una BDM consolida cientos o miles de veces
ms rpido que una BDR, lo que le posibilita no slo una notable
superioridad en la performance, sino que tambin (y como consecuencia de
lo anterior) incluir situaciones en las que por el gran volumen de datos no se
resolvan en el entorno relacional, o que por dicha limitacin se le buscaba
una solucin parcial.

Volviendo a nuestro ejemplo anterior, asumamos que queremos obtener
indefectiblemente, elevados tiempos de respuesta independientemente del
query que realicemos. Veamos que ocurre en ambos entornos :

a) En una BDR el tiempo de respuesta es proporcional a la cantidad de
registros que se lean. Si efectuamos un query que obtenga un total como
Total de Ventas para el Este llevar cuatro veces ms tiempo que obtener
el total de Planchas Vendidos en el Este (obviamente en el primer caso
tiene que leer cuatro registros y en ste ltimo slo uno). Y si queremos
saber Cul es el total de Ventas para todas las Regiones se deben
acumular los doce totales parciales (de cuatro Productos por tres Regiones).
Con lo cul llevar doce veces ms de tiempo que la obtencin de un total
parcial de un producto determinado en una regin dada.

Para resolver esta problemtica la mayora de los diseadores de sistemas
consolidan previamente los totales y los agregan en la base de datos:


En esta Tabla Relacional la consolidacin elimina la necesidad de calcular al
vuelo los totales, ya que todos estn previamente calculados. Como
consecuencia se obtienen rpidos tiempos de respuesta.

Con todos los totales consolidados podemos responder cualquier tipo de
query que involucre conocer totales por Producto y/o Regin recuperando
un slo registro. Esta es una solucin adecuada mientras la cantidad de
registros sean pocos. Pero, cmo resolvemos el problema cuando el
volumen de informacin es elevado y el pre-clculo puede tardar ms horas
de las que contiene un da ?
En nuestro ejemplo computar los totales involucra:

- 28 lecturas a la Base de Datos: 12 para obtener el total por Producto, 12
para obtener el total por Regin, 4 para el total general
- 8 grabaciones a la Base de Datos: 4 para totales por Producto, 3 para
totales por Regin y 1 para el total general
Una BDR tpica puede leer alrededor de 200 registros por segundo y grabar
unos 20 nuevos registros por segundo. Por lo que en nuestro pequeo
ejemplo el proceso de generacin de los totales mencionados puede tomar
menos de un segundo.

b) Con un servidor OLAP multidimensional, podemos realizar las mismas
consolidaciones utilizando la ventaja del servidor de realizar operaciones
entre filas y columnas. Mientras que una BDR puede acceder unos cientos
de registros por segundo, una buena BDM debe tener la capacidad de
consolidar de veintemil a treintamil celdas de datos por segundo, incluyendo
la grabacin de los totales en la Base. Justamente es la capacidad de realizar
consolidaciones a altas velocidades donde reside principalmente el poder de
esta sofisticada tecnologa ( las celdas tambin se denominan
combinaciones, por ser el resultado de las combinaciones de Productos y
Regiones, es decir de los miembros entre distintas dimensiones).

En una Base de Datos OLAP Multidimensional (BDOM) un usuario no tiene
que saber nada respecto de la tecnologa de la bases de datos para poder
observar esta representacin bidimensional de los datos con totales
generales por filas y columnas ya que es la forma ms natural, clara y
resumida como se podra representar la informacin (ver matriz ms abajo).
Y as de resumida como se puede observar en esta hoja es igualmente
menor el espacio que ocupa en disco, ya que por su naturaleza de ser una
matriz plana de tems de datos debe repetir las descripciones (o cdigos)
para representar cada una de las instancias de las combinaciones de
Productos y Regiones, mientras que en una BDOM los valores resultan de la
interseccin de los miembros de cada dimensin. El almacenamiento fsico
de los datos en disco y el esquema de indexacin para localizar los datos
son la clave de la velocidad de las bases de datos multidimensionales.


Veamos algunas de las terminologas multidimensionales empleadas :

- Las celdas (Cells) que contienen los datos fuente originales (en cursiva) se
denominan Inputs.
- Los totales calculados (en cursiva negrita) son llamados Outputs
- Este, Oeste y Centro son Input Members de la Dimensin Regin
- El Total de la Regin es el Output Member de la Dimensin Regin
- Televisor, Video, Afeitadora y Plancha son Input Members de la Dimensin
Producto
- El Total de Productos es el Output Member de la Dimensin Producto
- Los valores representados corresponden a una Variable. Para este caso la
variable es Ventas y est dimensionada por Producto y Regin.
- Las Variables representan tpicamente mediciones/indicadores numricos
tales como Ventas, Costos, Ingresos, Gastos, Margen, etc.
- El valor hallado en la interseccin de cada regin y producto ocupa una
celda, tal como ocurre en una planilla de clculo.
- Las celdas son a veces denominadas indistintamente como
combinaciones. En nuestro ejemplo hay 20 combinaciones (celdas).

En una BDR, las columnas pueden representar tanto dimensiones como
variables, por lo que, para representar las 20 combinaciones necesita
informacin redundante.
Jerarquas simples dentro de las Dimensiones

En nuestro ejemplo existe una Jerarqua Simple en ambas dimensiones, las
que podemos representar de la siguiente manera:


Productos individuales hacen roll up en el Total de Productos y las regiones
individuales hacen roll up en el Total de al Regin.

El trmino roll up indica que el Miembro Padre recibe (en los casos de
corresponder, las acumulaciones o el tipo de clculo especificado de los
Miembros que dependen de l. Dado que la terminologa difundida es dicha
expresin en ingls, su traduccin literal no responde al concepto y por ser
breve, la mantendremos.

La jerarqua representada es simple porque cada input hace roll up en un
nico total. Es posible que una dimensin como Producto pueda tener
distintas formas de hacer roll up para ms de un total. Por ejemplo Producto
puede tener roll up por Planta de Embalaje, Responsable de Produccin,
Tipo de Embalaje, etc.. En la seccin Todas las Dimensiones no se crean
igual, veremos ejemplos de estructuras algo ms complejas.


En este ejemplo las Ciudades hacen roll up en Provincias, las Provincias en
Regiones y las regiones en el Total de Regiones. Si un servidor OLAP no
puede soportar mltiples niveles de jerarqua dentro de una misma
dimensin, se debern (para nuestro caso) definir dimensiones separadas
para las Ciudades, Provincias y Regiones.

La razn por la que se necesitan mltiples niveles de jerarqua o
dimensiones adicionales es que no se pueden mezclar Ciudades, Provincias
y Regiones en una misma dimensin a menos que se las puedan tratar en
una dimensin jerrquica. Si no se poseen jerarquas en una dimensin, se
tratara de crear una base de datos bidimensional como la que sigue:


Obtener el total por filas funciona bien, los totales que se obtendran seran
los correctos. Pero los totales para un producto particular sera incorrecto ya
que se sumaran los de cada Ciudad, con los de cada Provincia (que ya
incluye las Ciudades ), con los de cada Regin (que ya incluyen los de cada
Ciudad).

En una BDM sin jerarquas, la solucin a este problema es tener
dimensiones separadas para Ciudades, Provincias y Regiones. Para
simplificar la representacin visual slo tomemos Ciudades y Provincias:


Ahora podemos obtener totales de un producto por Ciudad o por Provincia
obteniendo un resultado correcto. Pero qu pasara si las Ciudades se abren
en otros niveles de detalle, y que a su vez los productos se agrupan en
familias, subfamilias y otros niveles de desagregacin. Y as que se siga
propagando a las distintas dimensiones propias de cada variable. Se
alcanzara una alta complejidad y las ventajas competitivas de una BDM
empezaran a desvanecerse y slo tendra aplicacin para soluciones
elementales, simples y acotadas.

Otro problema que ocurrira con la solucin precedente es que muchas
celdas no contendran datos (por ej. Bariloche no pertenece al Chaco con lo
cual todas celdas que pertenezcan a estas coordenadas no poseern
informacin). La forma correcta de resolver ste problema es usando
Dimensiones Jerrquicas.

Las Ciudades de Santa Fe estn en el nivel siguiente a dicha ciudad (en la
jerga OLAP just below Santa Fe), las Provincias estn just below las
Regiones y as segn se vayan componiendo las jerarquas:


Con dimensiones geogrficas que contienen Regiones y Provincias en una
estructura jerrquica, podemos acceder a la base para obtener totales de
ventas de productos por regiones o provincias o ciudades, y los totales
sern siempre correctos. La base de datos sabe que la aritmtica de
columnas no combina miembros de la dimensin Regin que corresponden
a diferentes niveles de jerarqua.

El BDM tiene la inteligencia propia para acumular todas las Ciudades
correspondientes por Provincia, todas las Provincias por Regiones; pero
para el total general no acumular Ciudades, Provincias y Regiones porque
producir un resultado incorrecto ya que cada nivel superior incluye los
datos del inmediato inferior. El Total general surgir de las acumulaciones
de cada una de las Regiones.

Desde el punto de vista aplicativo, el uso de dimensiones jerrquicas nos
provee de la funcionalidad del drill down (perforar para abajo) facilidad que
nos posibilita descender a sucesivos niveles de detalle (funcionalidad
necesaria para el desarrollo de cualquier EIS). Otra funcionalidad que
potencia la aplicacin del drill down, es la posibilidad de posicionamiento
dentro de una jerarqua : en la dimensin geogrfica podemos posicionarnos
directamente justo debajo (just below) de Oeste y obtener las ventas
realizadas por todas las Provincias de la Regin Oeste.
Frecuentemente estas facilidades son implementadas de manera tal de que
el usuario simplemente hace click en un tem de la pantalla y la aplicacin
despliega los datos del siguiente nivel de detalle. En la seccin titulada
Drilling to Relational veremos porqu esto tiene sentido de ser usado en
un server OLAP para realizar consolidaciones, pero sin embargo se
mantiene el menor nivel de datos de detalle en una BDR.

Variables

Las Variables son medidas numricas : Ventas, Costos, Precios,
Facturaciones, etc.. Algunos servers OLAP tratan a las variables como una
dimensin especial, y hay varias buenas razones para esto. Pensemos
variables como dimensionada por cierta dimensin en la base de datos. Por
ejemplo Ventas puede estar dimensionada por Regin, Producto y Tipo de
Cliente. Por otro lado Precio (supongamos que as sea en nuestro modelo)
debe ser idntica para todas las Regiones y Tipo de Cliente, entonces slo
necesitamos dimensionarla por Producto. Si las variables son tan solo una
dimensin normal , nos veramos forzados a dimensionar Precio por todas
las otras dimensiones, y por lo tanto tendramos una cantidad innecesaria de
celdas en nuestra base de datos. Tratando a la Variables como un caso
especial de dimensiones, slo se seleccionan las dimensiones relevantes
para cada variable.

Este concepto se denomina Variables Dimensionadas Independientemente y
es una herramienta esencial para optimizar la performance en una BDM
reduciendo su tamao al mnimo lgico, como tambin la complejidad de su
carga. No todos los servers OLAP soportan variables dimensionadas en
forma independiente.

Otra caracterstica que no todos los servers OLAP poseen es la posibilidad
de definir variables a travs de operaciones matemticas complejas entre
otras variables. Este tipo de variable se denominan variables complejas. En
general la relacin entre los miembros de una dimensin se establece slo
con adiciones (ej. El Total de Ventas de Formosa es la suma de las ventas de
cada una de las Ciudades correspondientes a su jerarqua). En determinados
modelos (tanto en la misma estructura de una dimensin, como entre
distintas variables) podemos requerir : diferencias, promedios, promedios
ponderados, frmulas financieras o cualquier otra expresin aritmtica
compleja. Podemos tener en nuestra BDM las Unidades Vendidas, el Precio
Unitario, el Costo Unitario y podemos calcular :

Costo = (Unidades Vendidas) * (Costo Unitario) Ventas = (Unidades
Vendidas) * (Precio Unitario) Margen = Ventas - Costo

Que un servidor OLAP posea estas capacidades en la mayora de los casos
representa una enorme ventaja en tiempo y costo, ya que de tener que hacer
externamente los clculos puede representar la elaboracin y corrida de
varios programas complejos ms la transmisin y carga de los datos
resultantes.

Las Variables son tambin especiales porque pueden incorporar distintas
reglas de consolidacin. Por ejemplo cuando las ventas de cada Regin
tienen roll up en el Total de Regin, los valores son sumados
aritmticamente. Pero el Precio no tiene un comportamiento aditivo, puede
ser ponderado o computado a partir de alguna frmula compleja. Un caso
similar es cuando se convierten los datos de una periodicidad en otra (diaria
a semanal), distintos tipos de variables deben ser tratadas en forma distinta.
Convertir Ventas diarias en Ventas semanales se logra simplemente
sumando cada uno de los das de cada semana, pero convertir Precios
diarios en semanales seguramente no se obtendr de la misma manera.

Las Variables tambin pueden contener informacin de cmo convertir una
divisa en otra, si posee una leyenda descriptiva larga, unidad en que se
define, etc.. Todos estos Atributos de las Variables son normalmente
almacenados en un diccionario de datos.

Otro concepto que quisiramos introducir en este punto es el de variable
virtual. Esta tipo de variable es requerida desde el punto de vista del usuario
y es calculada al vuelo en tiempo de ejecucin. Por ejemplo una base de
datos puede contener variables para Ingresos y Egresos, y se necesita crear
una variable Margen Bruto que sea la resta de Egresos sobre Ingresos y
almacenarla en la base de datos. Alternativamente se puede definir Margen
Bruto como una variable virtual, lo que significa que es calculada al vuelo
usando la frmula: Margen Bruto = Ingresos - Egresos. No todos los
servidores OLAP soportan este tipo de variables. Una variable virtual no
ocupa espacio en la base, por lo que es extremadamente til para reducir el
tamao de la base de datos y los tiempos de consolidacin de todas las
combinaciones (desde ya con el precio de un pequeo incremento de
overhead en el tiempo de ejecucin de query que la involucre). Es
responsabilidad del diseador determinar en qu casos conviene usar esta
facilidad. Desde el punto de vista del usuario este tipo de variable es como
cualquier otra. Es importante tener presente que aquellas bases de datos
que no traten a las variables como una dimensin especial con las
capacidades antes mencionadas, probablemente requerirn ms trabajo en
el desarrollo de aplicaciones y la performance de los tiempos de corrida
pueden ser seriamente comprometidos.

Vector Aritmtico

Datos que son inherentemente organizados en vectores pueden ser
manipulados ms rpido que los mismos datos en una tabla relacional. Por
ejemplo, podemos fcilmente restar el plano para Actual del plano para
Presupuestado para crear el plano para la Variacin :


En un servidor de datos OLAP Multidimensional, este vector aritmtico
puede ser expresado en una operacin. En el caso de una representacin
relacional:

- cada registro de la base debe ser accedido - el actual debe ser restado del
presupuestado
- y cada diferencia debe ser grabada como un nuevo registro

Obviamente resulta claro que en el entorno relacional el proceso es bastante
ms largo.

El vector aritmtico permite consistentemente rpidas computaciones de
variables virtuales. Con esta facilidad la Variacin se podra definir como una
variable virtual.
Bases de Datos N-Dimensionales

Una base de datos bidimensional es fcil de entender y visualizar. Ahora
extenderemos el concepto a tres o ms dimensiones. Supongamos que en
nuestro ejemplo original incorporemos valores presupuestados para cada
combinacin de producto y regin.

En una Tabla Relacional agregaramos una columna
Actual/Presupuestado, donde para cada tem de datos aclararamos (con
cdigo o descripcin) el tipo de valor. Esta nueva columna duplicara la
cantidad de registros :


Con la representacin multidimensional pasamos de una matriz de dos
dimensiones a una de tres :

Esta matriz tiene 24 celdas ( 4 productos X 3 regiones X 2 tipos de valores)
corresponde a los 24 registros en la representacin relacional.

En este caso particular de tres dimensiones, se puede ver claramente que de
acuerdo a la combinacin de dimensiones que se quieran analizar, el cubo
se puede rotar para presentar la vista de datos requerida:

Justamente esta es una de las habilidades principales en la navegacin y
manipulacin de estructuras de datos en una BDM: el cubo se puede rotar,
girar, cortar porciones o extraer parte de su estructura.

Como vemos en la figura anterior, al rotar el cubo 90 grados vemos
Productos Vs. Actual/Previsto. Si lo rotamos nuevamente tenemos los datos
presentados como Actual/Previsto Vs. Regin .
Un arreglo 3-dimensional tenemos la posibilidad de obtener seis caras o
vistas. Un arreglo 4-dimensional tiene doce vistas. Un arreglo n-dimensional
tiene n*(n-1) vistas.
La habilidad de rotar el cubo de datos es la tcnica principal para la
generacin de reportes multidimensionales y en la jerga se la denomina
slice and dice.
Limitacin Prctica en el Tamao de una Base de Datos
Existe un concepto errneo comn en el mercado que el tamao de una base
de datos OLAP est limitada primariamente por el mximo nmero de
dimensiones que soporta. La real limitacin es casi siempre el nmero de
celdas, no la cantidad de dimensiones. Adems, no todas las dimensiones
son creadas de la misma manera. Algunos productos slo soportan simples
jerarquas dentro de las dimensiones, mientras que otros soportan mltiples
jerarquas complejas. Entraremos en ms detalle en la seccin Todas las
Dimensiones no son creadas iguales. Basta decir que una base de datos de
ocho dimensiones en un producto OLAP, se puede reducir a tres o cuatro
con otro.
En general, a medida que el nmero de dimensiones se incrementa, el
nmero de celdas aumenta exponencialmente. Por ejemplo , una base de
datos bidimensional con 100 Productos y 100 Regiones generar 10.000
celdas (combinaciones). Si agregamos una tercera dimensin con 52
semanas llegamos a 520.000 celdas (100 X 100 X 52). Agregndole una
cuarta dimensin para Actual, Presupuestado, Variacin y Proyectado; nos
da 2.080.000 celdas (100 X 100 X 52 X 4). Y si agregamos una quinta
dimensin para almacenar 10 Tipos de Clientes nos da un total de
20.800.000 celdas. Y as sucesivamente. Con base de base de datos de 16
dimensiones con slo 5 miembros en cada dimensin alcanzamos cerca de
los 152 billones ( 152.587.890.625) celdas !
La mayora de los servers OLAP que se ofrecen en un determinado valor
mximo de celdas sin tener en cuenta si el mximo de dimensiones que
ofrecen es coherente con dicho lmite. Por ejemplo, un proveedor OLAP
declara que su tecnologa soporta 32 dimensiones, y que tiene un lmite de
alrededor de dos billones de celdas. Con slo dos miembros en cada
dimensin, una base de datos de 32 dimensiones deber soportar 232 (o sea
4,3 billones ) de celdas. Es obvio que un producto de estas caractersticas
tiene una seria limitacin en la cantidad de dimensiones y no slo en la
cantidad de celdas. En la prctica ocurre que la mayora de las dimensiones
(ej. Productos y Regiones) poseen ms de dos miembros.
Al presente de esta edicin el mximo de combinaciones (153 trillones) es
soportado por LightShip Server de Pilot Software.
Tipo de Datos Times-Series. (Datos Serie de Tiempo)
El tiempo es probablemente la dimensin ms comn en Bases de Datos
Multidimensionales. De hecho todos quieren ver las tendencias -- de ventas,
de finanzas, de mercado y dems. Los usuarios quieren ver las tendencias
en todos los aspectos de sus negocios, comparar resultados actuales con
los de aos anteriores, convertir el perodo actual en perodo year-to-date (lo
que va del ao). Una serie de nmeros representando una variable en
particular (como ventas) a travs del tiempo se llama una Time-Series. Por
ejemplo, los nmeros de ventas de 52 semanas es una Time-Series, como lo
son los nmeros de las ganancias correspondientes a 12 meses, 5 das de
balance de caja y dems. En una celda de una planilla electrnica de clculo
se puede almacenar un nico nmero. Supongamos que se pueda almacenar
10 aos de historia diaria en cada celda. Esta es la idea del tipo de datos
Time-Series. La incorporacin del tipo de datos Time-Series le permite
almacenar una serie entera de nmeros (representando, por ejemplo,
informacin totalizada para periodicidad diaria, semanal o mensual) en cada
celda. Si el server OLAP tiene un tipo de datos Time-Series, se puede
almacenar toda su informacin histrica en una celda en lugar de tener que
especificar una dimensin separada para el tiempo.

Colocando una Time-Series en cada celda elimina la necesidad de una
dimensin separada para el tiempo.

A diferencia de otras dimensiones, el tiempo tiene algunas cualidades y
reglas especiales. Antes que nada, el tiempo siempre tiene una particular
periodicidad, esto es el intervalo de tiempo entre los nmeros de la serie.
Periodicidades comunes son: diaria, semanal, mensual, cuatrimestral, etc..
Secundariamente, los datos de tipo Time-Series deben incluir reglas de
conversin a otras periodicidades. Estos son los llamados Atributos de las
Time-Series.

Antes de entrar en detalle sobre el tipo de datos Time-Series miremos cmo
tendramos que tratar con datos de una Time-Series si no existiera un
especial tipo de datos Time-Series.

Al no poseer un tipo de datos Time-Series, se debe definir explcitamente al
Tiempo como una de sus dimensiones en la Base de Datos. Como se
querr trabajar aritmticamente su fila y columna en forma correcta, se
tendr que tomar una periodicidad para toda la Base de Datos (como
mensual) y expresar todo en esta periodicidad. Los miembros de la
dimensin meses deberan ser nombrados explcitamente -- como Enero,
Febrero, Marzo, ...., Diciembre.

En ausencia de un tipo especial de datos Time-Series, usted debe declarar
una de sus variables como tiempo y nombrar explcitamente los miembros.

No debe haber mezcla de mensuales, semanales y otras periodicidades.
Si se necesita utilizar mltiples periodicidades, como mensual y semanal, se
necesitar definir dos diferentes dimensiones -- una para los meses y otra
para las semanas. De esta forma se estn realmente almacenando los datos
dos veces -- una vez en la forma semanal y otra para la forma mensual.
Adems de la complejidad agregada, esto puede incrementar el tamao de la
Base de Datos en la magnitud de cada dimensin o ms.

Si usted quiere tener datos mensuales y semanales, necesitar poner meses
en una dimensin y semanas en otra.

Convirtiendo todos los datos a una sola periodicidad tambin puede ser una
solucin no satisfactoria. Primero, si se convierten semanas a meses antes
de cargar la Base de Datos, por ejemplo, se pierde para siempre la
posibilidad de mirar los datos semanales. Segundo, tal conversin de datos
es complicada y agrega un paso extra en la preparacin de los datos.
Tercero, como nuevos puntos de datos (data points) son agregados, se
necesitarn ms columnas en la matriz y eventualmente la matriz crecer
demasiado.

Se pueden mezclar diferentes periodicidades en una dimensin. Por ejemplo,
en la siguiente tabla multidimensional, hemos intentado poner datos
mensuales y semanales en una sola dimensin. Para el primer producto,
tenemos solo datos mensuales. Para el segundo producto, tenemos datos
mensuales y semanales. Para los ltimos dos productos tenemos solo datos
semanales. La primera cosa que notar es la adicin a travs de las filas
(para seguir un total year-to-date) produce un total errneo para la
segunda fila (tendr los meses y las semanas sumadas).
Segundo, si se quisiera preguntar por el total de ventas de Enero, esos
productos para los cuales solo hubo datos semanales, no pueden estar
incluidos en el total, por lo que la respuesta sera nuevamente errnea.

Cuando se mezclan periodicidades diferentes en una dimensin las
operaciones aritmticas entre filas producen respuestas errneas.

En el ejemplo anterior, sera necesaria una programacin intensiva para
comparar resultados por perodos cuando algunas ventas de producto estn
grabadas slo mensualmente y otras slo semanalmente. Un programa
externo a la Base de Datos debera tener total conocimiento del calendario,
incluyendo irregularidades como feriados, aos bisiestos y dems. La
solucin al problema del tiempo no es utilizar al tiempo como una
dimensin., sino utilizar un tipo de datos Time-Series lo que le permitir
guardar ms de un nmero en cada celda. La ventaja de este avance radica
en que se puede almacenar una serie de puntos de datos diarios en cada
celda, una serie de puntos de datos semanales en una celda adyacente y as
otras.

En el ejemplo siguiente, hay combinaciones de productos y regiones cuyos
datos son ingresados diariamente, y otras cuyos datos son ingresados
semanalmente. Todos los datos para cada combinacin de producto y regin
son almacenados como una serie en la celda. Por ejemplo, donde
Producto=Nueces y Regin=Este, hay dos semanas de datos diarios
(semanas de cinco das). Donde Product=Bolts y Regin=Este, hay
solamente dos semanas de puntos de datos en la celda. En este ejemplo,
nosotros queremos ver Regin en lo que va del ao como datos semanales,
y Producto en el ao en curso como datos diarios. Por lo tanto cuando la
Base de Datos suma una fila, la Base de Datos alinea todos los puntos de
fecha., automticamente convirtiendo los das a semanas, para producir una
serie de totales semanales exacto.
Cuando suma columnas, los datos semanales son convertidos a diarios y el
resultado es mostrado como datos diarios.

El tipo de datos Time-Series elimina la necesidad de una dimensin tiempo
en la Base de Datos.

Una celda con dato Time-Series puede contener una gran sarta de
informacin comparada con una sola celda numrica, o an un registro
completo de una Base de Datos Relacional. Por ejemplo, La informacin
contenida en la celda en la interseccin de Nueces y Este en la tabla
anterior puede contener los siguientes atributos:

Fecha = 01/11/92
Periodicidad = Diaria, Semanal, Mensual, bimestral, etc.
Conversin = Suma, Promedio, etc.
Descripcin = Variable=Ventas, Producto=Nuts, Region=Este
Tipo de Dato = Numrico, simple precisin
Dispersin = No Dispersa (Non-sparse)
Calendario= Ao Fiscal
Datos = 708,800,821,743,779,856,878,902,799, y as siguiendo.

Cualquier server OLAP que utilice tipo de datos Time-Series debe tener un
completo tratamiento y comprensin de calendarios.

No solamente por la habilidad de convertir, digamos, semanas en meses,
sino que debe ser capaz de saber cuando realizar una conversin inversa,
como convertir meses a semanas, cundo y cmo ponderar. Este debe
entender la diferencia entre ao calendario y ao fiscal. Debe conocer sobre
perodos contables.

Debe saber sobre aos bisiestos y feriados. Debe saber pasar de meses a
semanas, semanas a das, das a horas trabajables, y otras reglas para
conversin de perodos de tiempo de forma precisa. Por ejemplo, convertir
datos semanales a diarios requiere conocer si se est trabajando con
semanas de cinco o seis das de trabajo, y as. Y necesita saber si los das
del fin de semana tienen el mismo peso que los das de semana.

Aunque esto parezca superficialmente sencillo, un robusto y consistente
algoritmo de conversin requiere de un extensivo conocimiento de las reglas
del calendario lo cual es una compleja pieza de software. Una vez que lo
tiene, sin embargo, se simplifican enormemente el desarrollo de aplicaciones
futuras y el almacenamiento de datos dado que toda la informacin se puede
ingresar con su periodicidad original y luego ser inmediatamente utilizada en
cualquier otra. Esto elimina la necesidad de construir dimensiones de tiempo
desde el comienzo y desarrollar rutinas externas de conversin de
periodicidades.

Esta es probablemente la caracterstica ms significativa para ahorrar
tiempo desde el punto de vista del desarrollador que se puede tener con un
robusto producto OLAP Multidimensional.
Datos de tipo Sparse (Dispersos)

A medida que agregamos dimensiones a una Base de Datos
Multidimensional, el nmero de puntos de datos o celdas crece
rpidamente. Por ejemplo, si nosotros agregamos una dimensin tiempo a
una base de datos para su registro diario por sucursal de venta sin embargo,
que no se venden todos los productos en todas las sucursales todos los
das y para el registro de estas sucursales una gran cantidad de las celdas
estarn vacas. En la prctica, muchas Bases de Datos, como las de
Marketing, tienen el 95 % de las celdas vacas o en cero. En situaciones
donde menos del 10 % de las celdas tiene algn dato, las Bases de Datos
son denominadas sparsely populated (poblados dispersos) o simplemente
sparse.

Otro tipo de datos sparse es creado cuando varias celdas contienen el
mismo nmero. Si en nuestra matriz tuvisemos la dimensin precio, por
ejemplo, el mismo precio debera aplicarse a las 1.200 sucursales. Por lo
tanto, por cada uno de nuestros productos, habra 1.200 puntos de datos
iguales.

En lugar de repetir el mismo nmero una y otra vez, es preferible almacenar
una sola vez el valor junto con la cantidad de das que el mismo valor es
secuencialmente repetido.

Mirando a la variable precio, un producto puede tener el mismo precio en
todas las sucursales por mucho das.
Esta es una forma de datos sparse
Una tabla relacional no sabra si el mismo precio se mantiene invariante por
200 das consecutivos porque no est organizado a travs de dimensiones.
As, se llenaran ciegamente registro tras registro con informacin duplicada.
Esto produce un efecto de llenado de disco, pero ms importante es la
lentitud que provoca para la ejecucin de queries. Un server OLAP que
reconoce datos sparse puede saltear lo ceros, datos nulos y grandes
cantidades de datos duplicados.
Todas las Dimensiones no son creadas Igual

Entre los proveedores de servers OLAP, se ofrecen algunos con
dimensiones simples, sin jerarquas ni tipos de datos especiales. Otros
ofrecen dimensiones muy sofisticadas con mltiples jerarquas, ricos tipos
de datos, y algunas funciones ms. Es importante asegurarse de que sus
datos se adaptarn fcilmente a las caractersticas de su server OLAP con la
necesidad de un importante trabajo de programacin externa. Estas tareas
pueden ser complicadas porque las especificaciones para algunos servers
OLAP pueden ser confusas. Por ejemplo, tomemos la especificacin para el
tamao de la Base de Datos. Esta se puede referir al mximo de nmeros de
celdas en la Base de Datos o al espacio mximo de disco ocupado por la
Base de Datos. Como discutimos anteriormente en la seccin llamada
Limitacin Prctica en el Tamao de una Base de Datos, el nmero
mximo de celdas en una Base de Datos es el criterio ms importante para la
eleccin de un server OLAP. Pero an esta especificacin puede ser
confusa. Digamos que se comercializan dos Bases de Datos, ambas con una
capacidad de 100 mil millones de celdas. Si una soporta tipos de datos Time-
Series y la otra no, la comparacin no tiene sentido. Mientras que un tipo de
dato Time-Serie puede almacenar miles de nmeros en cada celda, una Base
de Datos que contiene tipos da datos Time-Series puede tener una
capacidad 1.000 veces o ms superior a una que no lo posee.

Hay otros dos temas relacionados con el tamao de una Base de Datos: 1)
Dependiendo de la velocidad de consolidacin de los datos, el tamao de la
Base de Datos puede ser un factor poco prctico. Una Base de Datos con
mucha capacidad y lenta velocidad de consolidacin puede ser menos til
que otra con capacidad limitada. 2) Puede haber una enorme diferencia entre
el nmero de celdas en una Base de Datos y el nmero de celdas que
realmente contienen datos. Una Base de Datos puede tener 100 mil millones
de posibles combinaciones (o celdas) de productos, regiones y dems, pero
solo un porcentaje de stas puede realmente contener datos. Esto es
llamado sparsity (o dispersin) como se mencion anteriormente. Se puede
decir que una Base de Datos multidimensional OLAP puede tener dos
limitaciones: 1) el nmero de combinaciones y 2) el nmero de
combinaciones que contenga datos (lo cual se reduce al problema del
tamao del disco).

Una advertencia con respecto al tamao de las Bases de Datos: algunos
proveedores intentan eludir el problema de limitacin de tamao proveyendo
un run-time para uniones o consolidaciones de mltiples tablas. Como en la
tecnologa relacional, una operacin run-time implica un serio compromiso
de performance. El tamao de la Base de Datos debiera referirse a una sola
tabla con un solo ndice.

Las dimensiones son an ms confusas. Todo intento de igualar el nmero
de dimensiones soportado por una Base de Datos con la capacidad de la
misma, no tiene sentido debido a las diferentes definiciones para las cuales
una dimensin deba hacer. Una Base de Datos de un proveedor A puede
requerir 8 dimensiones para una variable determinada, mientras que la Base
de Datos de un proveedor B slo requiera de una o dos dimensiones para la
misma variable.

He aqu una lista de las caractersticas ms importantes soportadas en los
servers OLAP que pueden reducir la complejidad del diseo de la Base de
Datos y simplificar el desarrollo de aplicaciones para usuarios:

Tipos de datos Time-Series.
Dimensiones especiales para variables.
Mltiples jerarquas dentro de una dimensin.
Clases dentro de una dimensin.
Variables virtuales.
Variables independientemente dimensionadas.
Alias
Velocidad de consolidacin.

Por ejemplo, una Base de Datos que no contiene tipos de datos Time-Series
podra usar tres diferentes dimensiones para almacenar datos diarios,
semanales y mensuales. Si la Base de Datos contiene tipos de datos Time-
Series y tiene funcionalidad inteligente para el tratamiento de tiempo (por
ejemplo, la habilidad de convertir automticamente una periodicidad en
otra), esas tres dimensiones podran no ser necesarias.

Algunas Bases de Datos poseen un nmero mximo absoluto de
dimensiones. Otras poseen un nmero mximo de dimensiones para cada
variable (en otras palabras, Ventas puede ser dimensionada por un conjunto
de dimensiones diferentes al Precio).

Algunos softwares de Bases de Datos requieren que subconjuntos de
miembros de dimensiones, como el tamao de producto, color y dems,
deban ser definidos en dimensiones separadas. Otras Bases de Datos
soportan clases de miembros dentro de una dimensin, eliminando as la
necesidad de dimensiones adicionales.

Como ver en la seccin siguiente Mltiples jerarquas dentro de una
Dimensin puede eliminar la necesidad de poner diferentes niveles de
detalles en dimensiones diferentes.

Mltiples Jerarquas y Clases dentro de una Dimensin

El principal factor en determinar cuntas dimensiones se necesitarn para
una Base de Datos en particular es la existencia de jerarquas mltiples y
clases dentro de una dimensin. Por ejemplo, una Base de Datos de ventas
de shampoo, debe querer agruparse informacin de ventas por tamao (6
oz., 15 oz., y as), por tipo, (cabello seco, cabello graso, cabello normal), y
posiblemente por otros atributos, como perfumado / no perfumado, marca, y
otros. Si su server OLAP soporta jerarquas mltiples dentro de una
dimensin, todas estas relacionas pueden ser expresadas con una sola
dimensin. Una jerarqua podra agrupar ventas por tamao, una por tipo,
etc.. Si no se tiene la capacidad de mltiples jerarquas, tendra que haber
dimensiones separadas por tamao, tipo, etc., lo cual complicara
conceptualmente la Base de Datos y multiplicara el tamao (nmero de
combinaciones) de la Base. Otro uso comn de las jerarquas mltiples es la
dimensin geogrfica. Supongamos que los datos de ventas son
almacenados por cliente. Clientes individuales podran agruparse en
ciudades, provincias, etc. Estas podran agruparse por representantes de
venta, distritos de ventas y regiones de venta donde estos distritos y
regiones no tengan nada que ver con las ciudades o lmites de provincias.


Algunos servers OLAP soportan mltiples jerarquas dentro de una
dimensin. Un hijo puede tener muchos padres.

Sin mltiples jerarquas, esta Base de Datos puede ser representada con
dimensiones separadas para cada agrupacin:

Sin mltiples jerarquas dentro de una dimensin, usted necesita ms
dimensiones.

En este ejemplo, se necesitan dos donde de otro modo una podra ser
suficiente.

Una de las herramientas ms poderosas para simplificar una Base de Datos
Multidimensional y reducir el nmero de dimensiones es clases dentro de
una dimensin. Clases son atributos tales como tamao, color y otras
caractersticas que definen un subconjunto de miembros de una dimensin.

Perforando hacia lo Relacional (Drilling)

La mayora de las organizaciones se han estandarizado sobre Bases de
Datos relacionales para su warehousing de datos. Hay casos donde no es
necesario ni deseable duplicar o replicar todos los datos de una base
detallada en una Base de Datos Multidimensional. Por ejemplo, supongamos
que tenemos una Base de Datos de ventas en un DBMS relacional para
50.000 clientes. Y supongamos que 50.000 clientes se agrupan en 500
ciudades, 50 provincias, cinco regiones y un total.


Nivel de sumatoria de datos pueden ser guardados en una Base de Datos
Multidimensional mientras que la informacin detallada puede ser guardada
en una Base de Datos Relacional.

Extraer un nico nmero no consolidado de una Base de Datos
Multidimensional no es ms rpido que extraerlo de una Relacional. As, no
es el punto almacenar clientes individualmente en una Base de Datos
Relacional. Extraer el Total agregar 50.000 registros -- claramente algo que
no querramos hacer con Bases de Datos relacionales. Recuperar totales por
regin requerira agregar 10.000 clientes por regin -- an demasiado pedir
para una Base de Datos relacional. Cuando se baje de nivel (drill down) hasta
ciudades, probablemente se estara accediendo 100 clientes por ciudad --
an peor que hacerlo en Bases de Datos multidimensionales. En cambio si
se quiere ver las ventas de un determinado cliente, slo se debera acceder a
un nico registro, por lo que sera tan rpido recuperarlo desde una Base de
Datos relacional que de una multidimensional. Por lo tanto, en esencia, usted
querra poder perforar (drill) por el fondo de su Base de Datos
Multidimensional hasta dentro de los detalles de la Base de Datos relacional.
Algunos servers comerciales OLAP soportan esta caracterstica.
Seguridad y Robustez

Seguridad es una importante caracterstica para cualquier Base de Datos
que va a ser compartida por mltiples usuarios. Seguridad de una Base de
Datos tiene dos principales propsitos: 1) Mantener a usuarios no
autorizados fuera del alcance de los datos, y 2) controlar el acceso de
porciones de la Base de Datos en la base de perfiles de usuario. Un sistema
de seguridad de Base de Datos esta protegida por passwords y cada usuario
tiene una nica contrasea. Los usuarios pueden agruparse y privilegios
para la base pueden ser controlados para un grupo entero facilitando as la
tarea del DBA (Administrador de Base de Datos). Usuarios individuales o
grupos de usuarios pueden tener acceso limitado a cualquier subconjunto
de la Base de Datos. En el server OLAP LightShip de Pilot, esta vista
restringida es determinada usando el mismo lenguaje de query que se utiliza
para recuperar datos. Por ejemplo, si yo fuera el Gerente de Ventas de la
regin Este, la seguridad de mi Base de Datos podra estar restringida a
Seleccionar Regin por debajo de Este. De este modo cuando yo me
identifico al sistema, mi vista est restringida a los datos de la Regin Este.

Robustez cubre un rango de caractersticas para el backup, recuperacin y
mantenimiento de la Base de Datos. Por ejemplo, si alguien desenchufa su
computadora en medio de la carga de la Base de Datos, quedara sta
corrupta?, Podra recuperar la informacin a partir de este punto?.

En general, las transacciones de Bases de Datos deberan poder ser aisladas
de modo tal que su ejecucin sea satisfactoria en su totalidad o ningn
cambio deba hacerse. Si una falla de algn tipo ocurriese, la Base de Datos
debiera ser capaz de deshacer cualquier cambio producido por una
transaccin incompleta y volver al estado anterior al comienzo de la
transaccin.

Si su server OLAP tuviera real robustez, la nica cosa que pudiera provocar
corrupcin en la Base de Datos debiera ser una falla fsica del disco.

El Mantenimiento Automtico de Dimensin es muy importante a medida que
la base crece. Si, por ejemplo, tenemos una Base de Datos con 30.000
clientes, la asignacin de esos clientes a distritos, regiones o lo que fuere,
no debiera ser una tarea manual. Si la transaccin de la Base de Datos desde
donde el server OLAP es cargado, contiene el nombre del distrito o regin al
cual pertenece (como siempre es el caso), entonces el server OLAP debiera
ser capaz de leer esa informacin y armar automticamente las jerarquas
OLAP y guardarlas sincronizadamente con la Base de Datos transaccional.

Herramientas de mantenimiento manual de dimensiones que permitan dragar
miembros desde un lugar de la jerarqua a otro, son buenas para mantener
Bases de Datos muy pequeas. Sin embargo, agrupando 30.000 miembros
en la pantalla de su computadora puede ser muy tedioso por decir poco, por
lo que estas herramientas no lo son mucho para extensas Bases de Datos.

Para sumarizar este punto, agregar, borrar o reasignar miembros a
diferentes padres deber ser un proceso automtico y no una tarea manual.
La sincronizacin de la Base de Datos OLAP con la base de datos productiva
debera estar asegurada por tal proceso automtico.

Arquitectura abierta es diferente de Cliente / Servidor. Muchos softwares
Cliente / Servidor no son abiertos. Estos deben tener una pieza cliente y otra
servidor pero estas piezas deben trabajar una con la otra y no pueden ser
remplazadas por piezas de software de terceras partes. Un producto abierto
cliente / servidor permite trabajar al cliente con diferentes servidores y
viceversa.

Hay algunos beneficios para los usuarios de arquitecturas abiertas,
incluyendo la habilidad de mezclar las mejores marcas de herramientas.
MDSQL - Lenguaje de Query Multidimensional

Solo una Base de Datos relacional tiene un lenguaje de query estructurado;
Bases de Datos Multidimensionales, requieren un lenguaje que permitan
expresar queries multidimensionales.

Pilot ha propuesto su lenguaje MDSQL con la base de un estndar en la
industria del lenguaje. Mientras que varios comits no han dudado en optar
por alguna modificaciones antes de bendecir (Dar el visto bueno) una
industria estndar MDSQL, el MDSQL de Pilot (usado en su LightShip
Server Multidimensional Database) provee un buen ejemplo de total
funcionalidad en lenguaje de query multidimensional. Como en el caso del
SQL relacional, este lenguaje de query multidimensional es English-Like.
Conclusin

La esencia de la tecnologa del server OLAP es rapidez, flexibilidad para
sumarizar datos y anlisis. Mientras que las bases de datos SQL continan
dominando OLTP (por la necesidad del proceso registro a registro), los
servers OLAP son una tecnologa superior para el proceso cliente / servidor
el anlisis de sistemas. Eficiencia y flexibilidad en el anlisis requiere la
habilidad de sumarizar datos en mltiples formas y determinar tendencias a
lo largo del tiempo. Los servers OLAP y las Bases de Datos Relacionales
pueden trabajar en armona para crear un ambiente server que entregue
datos a usuarios rpidamente y en al forma en que ellos los necesiten.