DataWarehouse

DataWarehouse
UNIVERSIDADES ANDALUZAS Y CONSEJERÍA
DE EDUCACIÓN Y CIENCIA DE LA JUNTA DE
ANDALUCÍA
Sistemas OLAP
INDICE
INDICE ................................................................................................................................................ 2
SISTEMAS OLAP................................................................................................................................ 3
Sistemas MOLAP ................................................................................................................................ 4
Sistemas ROLAP ................................................................................................................................ 5
Sistemas HOLAP ................................................................................................................................ 6
ROLAP vs. MOLAP (Comparativa) ..................................................................................................... 7
MicroStrategy vs. Discoverer (Comparativa) .................................................................................... 10
SISTEMAS OLAP
La explotación de sistemas DataWarehouse a través de datos obtenidos directamente de sistemas
transaccionales, OLTP (On-line Transaction Processing), se basa fundamental y básicamente en
estructuras agrupadas o información previamente pre-calculada y procesada. La información
reportada está compuesta y gestionada desde conceptos basados en datos agregados y
coeficientes de gestión, que los cuadros directivos de la organización pueden definir y consultar
según las dimensiones de negocio que se definan o el área a la que pertenezca.
Implementar un sistema de business intelligence significa encontrar el punto de equilibrio entre dos
extremos: implementación independiente de las unidades de la organización y la arquitectura de
almacenamiento de datos definida por los IT departamentales. Por un lado los IT departamentales
deben aceptar que el hecho de que ellos no puedan suministrar las visiones del usuario final con la
premura requerida sin incorporar tecnología OLAP. Por otro lado los directivos deben aprender a
reconocer el valor de tener un ‘repositorio común’ del que leer todos los indicadores y toda la
terminología que cruza todos los datos de todos los departamentos. Únicamente un
DataWarehouse puede proveer esta consistencia.
La información es gestionada y procesada en grandes bloques organizativos, como puede ser la
estructura geográfica o académica, llamados dimensiones. Dichas dimensiones de negocio se
estructuran a su vez en distintos niveles de detalle (por ejemplo, la dimensión geográfica puede
constar de los niveles país, comunidad autónoma, provincia, población y código postal).
Este tipo de sistemas ha existido desde hace tiempo, en el mundo de la informática, bajo distintas
denominaciones: cuadros de mando, MIS, EIS, etc. Aunque su implementación, al margen del
entorno DataWarehouse, puede repercutir sobre estos sistemas en una mayor rigidez, dificultad de
actualización y mantenimiento, tiempos de respuesta inaceptables, incoherencias de la
información, falta del dato agregado, etc.
Los sistemas de soporte a la decisión usando tecnologías de DataWarehouse, se llaman sistemas
OLAP (On Line Analytical Processing). En general, estos sistemas OLAP deben:
•
Soportar requerimientos complejos de análisis
•
Analizar datos desde diferentes perspectivas
•
Soportar análisis complejos contra un volumen ingente de datos
La principal características de los sistemas OLAP es que son entornos especialmente diseñados
para la ejecución de análisis multidimensionales de los datos corporativos, que soportan
amigablemente los análisis de cualquier usuario así como las posibilidades de navegación,
seleccionando la información a obtener, permitiendo el análisis de datos segmentados y que
permiten ir reduciendo el conjunto de datos reportados. Este tipo de selecciones se refleja en la
visualización de la estructura multidimensional, mediante unos campos de selección que nos
permitan elegir el nivel de agregación (jerarquía) de la dimensión, y/o la elección de un dato en
concreto, pudiendo con ello realizar, entre otras, las acciones de rotar, bajar atributos, navegar,
expandir o colapsar los datos mostrados.
Sistemas MOLAP
La arquitectura de sistemas MOLAP se fundamenta, para proporcionar el análisis, en bases de
datos multidimensionales. Su principal premisa es que se trata del entorno OLAP mejor implantado
y adaptado para el almacenamiento y gestión de datos multidimensionalmente. Por el contrario, la
arquitectura y gestión de entornos ROLAP presupone que las capacidades OLAP están
perfectamente implantadas y reflejadas sobre bases de datos relacionales.
Un sistema MOLAP usa una base de datos multidimensional, en la que la información se almacena
multidimensionalmente, para ser visualizada multidimensionalmente (valga la redundancia). El
sistema MOLAP utiliza una arquitectura de dos niveles: La bases de datos multidimensionales y el
motor analítico.
•
La base de datos multidimensional es la encargada del manejo, acceso y obtención del
dato.
•
El nivel de aplicación es el responsable de la ejecución de los requerimientos OLAP. El
nivel de presentación se integra con el de aplicación y proporciona un interfaz a través del
cual los usuarios finales visualizan los análisis OLAP. Una arquitectura cliente/servidor
permite a varios usuarios acceder a la misma base de datos multidimensional.
La información procedente de los sistemas transaccionales, se carga en el sistema MOLAP,
mediante una serie de rutinas o procedimientos batch. Una vez cargado el dato elemental en la
Base de Datos multidimensional (MDDB), se realizan una serie de cálculos en batch, para obtener
los datos agregados, a través de las dimensiones de negocio, rellenando la estructura MDDB y
generando los cubos multidimensionales que darán cobertura a los informes implementados en el
nivel de aplicación.
Tras cargar esta estructura, se generan unos índices y algoritmos de tablas hash para mejorar los
tiempos de acceso a las consultas.
Una vez que el proceso de compilación ha finalizado, la MDDB está lista para su uso. Los usuarios
solicitan informes a través del interface, y la lógica de aplicación de la MDDB obtiene el dato.
La arquitectura MOLAP requiere unos cálculos intensivos de compilación. Lee de datos
precompilados, y tiene capacidades limitadas de crear agregaciones dinámicamente o de hallar
ratios que no se hayan precalculados y almacenados previamente.
Sistemas ROLAP
En una arquitectura ROLAP, el sistema accede directamente a los datos almacenados en un
DataWarehouse para proporcionar los análisis OLAP solicitados. La premisa de estos sistemas es
que las capacidades OLAP se soportan mejor contra las bases de datos relacionales, más que
tenerlas directamente implementadas en la base de datos (como en entornos MOLAP). La esencia
de estos entornos es las acciones de filtrado y agregación es equivalente a la inclusión de una
cláusula “WHERE" en una sentencia SQL.
El sistema ROLAP utiliza una arquitectura de tres niveles. La base de datos relacional maneja los
requerimientos de almacenamiento de datos, y el motor ROLAP proporciona la funcionalidad
analítica.
•
El nivel de base de datos usa bases de datos relacionales para el manejo, acceso y
obtención del dato.
•
El nivel de aplicación es el motor que ejecuta las consultas multidimensionales de los
usuarios.
•
El motor ROLAP se integra con niveles de presentación, a través de los cuales los usuarios
realizan los análisis OLAP.
Después de que el modelo de datos para el DataWarehouse se ha definido, los datos se cargan
desde el sistema transaccional. Se ejecutan rutinas de bases de datos para agregar el dato, si así
es requerido por los modelos de datos.
Se crean entonces los índices para optimizar los tiempos de acceso a las consultas.
Los usuarios finales ejecutan sus análisis multidimensionales, a través del motor ROLAP, que
transforma dinámicamente sus consultas a consultas SQL. Se ejecutan estas consultas SQL en las
bases de datos relacionales, y sus resultados se relacionan mediante tablas cruzadas y conjuntos
multidimensionales para devolver los resultados a los usuarios.
La arquitectura ROLAP es capaz de usar datos precalculados si estos están disponibles, o de
generar dinámicamente los resultados desde los datos elementales si es preciso. Esta arquitectura
accede directamente a los datos del DataWarehouse, y soporta técnicas de optimización de
accesos para acelerar las consultas. Estas optimizaciones son, entre otras, particionado de los
datos a nivel de aplicación, soporte a la desnormalización y múltiples joins entre tablas.
Sistemas HOLAP
OLAP Hibrido (HOLAP) se refiere a tecnologías que combinan MOLAP y ROLAP.
La tecnología HOLAP intenta combinar las ventajas de MOLAP y ROLAP implementando
tecnologías basadas en cubos para obtener rendimientos lo más rápidos posible y cuando se
necesita detalle de la información, HOLAP puede realizar "drill through" desde los cubos a la capa
de datos relacional
ROLAP vs. MOLAP (Comparativa)
Cuando se comparan las dos arquitecturas, se pueden realizar las siguientes observaciones:
•
El ROLAP delega la negociación entre tiempo de respuesta y el proceso batch al diseño
del sistema. Mientras el MOLAP suele requerir que sus bases de datos se precompilen
para conseguir un rendimiento aceptable en las consultas, incrementando, por tanto los
requerimientos batch.
•
Los sistemas con alta volatilidad de los datos (aquellos en los que cambian las reglas de
agregación y consolidación), requieren una arquitectura que pueda realizar esta
consolidación ad-hoc. Los sistemas ROLAP soportan bien esta consolidación dinámica,
mientras que los MOLAP están más orientados hacia consolidaciones batch.
•
Los ROLAP soportan análisis OLAP contra grandes volúmenes de datos elementales,
mientras que los MOLAP se comportan razonablemente en volúmenes de datos
controlados. El volumen de datos con los que se trabaja son los que están implementados
en el cubo de análisis, mientras que en los entornos ROLAP en todo momento se dispone
de la totalidad de la base de datos.
•
Los entorno MOLAP almacenan los datos en estructuras con formato de matrices
multidimensionales, mientras que los ROLAP gestionan la información mediante metadatos
que mapean esquemas de base de datos, en estrella, en vistas multidimensionales.
•
Igual que las organizaciones usan variedad de herramientas, para el trabajo cotidiano,
pueden ser requeridos diferentes tipos de herramientas OLAP dependiendo del nivel o
área de análisis. Entornos de planificación tales como ‘forecasting’, análisis financieros y
localización de recursos pueden requerir entornos MDDB. Mientras entornos de análisis de
ventas o campañas de marketing que requieren datos con millones de continuos cambios,
tanto de productos como de clientes o atributos requieren entornos ROLAP.
•
El rendimiento puede ser mas lento, pues cada informe ROLAP, fundamentalmente, es una
sentencia SQL (o múltiples sentencias SQL) en la base de datos relacional, por lo que el
tiempo de respuesta puede ser grande si la cantidad de datos a manejar es grande. En
entornos MOLAP el rendimiento es excelente pues los cubos que dan respuesta a los
informes están previamente generados y realizar las consultas de filtrado de manera
inmediata.
•
En sistemas ROLAP las consultas están limitadas por el propio SQL, por lo que la
resolución de informes mediante sentencias SQL puede ser de mayor o menor
complejidad, esta limitación se ha intentado mitigar con la inclusión de funciones más o
menos complejas o mediante ejecuciones multipaso. Se pueden realizar cálculos todo lo
complejos que estimemos oportunos pues se pre-generan cuando se crea el cubo.
Universidad
Campus
Centro
Universidad
Campus
Centro
A
l
u
m
n
o
P
l
a
z
a
s
Nº PAS TC
Nº Doctores
Notas
Nº PDI
ROLAP
Matriculas
Créditos
MOLAP
Alum.
Tit.
Plazas
Matricula
centro
Asig.
CCAA
Colec.
Campus
Univ
CCE
Notas
Créditos
Hombre
Mujer
100
100
400
350
50
65
90
98
100
110
320
295
400
430
120
125
100
105
Matriculas
Universidad
sexo
Cádiz
Sevilla
Pablo Olavide
Jaén
Almería
Málaga
Granada
Córdoba
Huelva
Créditos
Un entorno MOLAP, como se aprecia en el dibujo anterior genera previamente los cubos
multidimensionales que le permitirán los análisis que se estimen necesarios. Esto significa que p.e.
al realizar análisis de créditos, matrícula o notas, por cualquier atributo organizativo (universidad,
campus, centro) sobre un atributo característico del alumno (sexo, edad, provincia) el sistema
accederá al primer cubo y resolverá la consulta agregando lo datos directamente de dicho cubo
multidimensional:
Universidad
Campus
Centro
A
l
u
m
n
o
Como el dato está previamente agregado los tiempos de respuesta son prácticamente inmediatos.
Un entorno ROLAP, como se aprecia en el dibujo anterior se basa directamente en esquemas en
estrella típicos de bases de datos relacionales, esto significa que al realizar análisis de créditos,
matrícula o notas, por cualquier atributo organizativo (universidad, campus, centro) sobre un
atributo característico del alumno (sexo, edad, provincia) el sistema generará la sentencia SQL que
de respuesta al informe solicitado:
Alum.
Universidad
sexo
Cádiz
Sevilla
Pablo Olavide
Jaén
Almería
Málaga
Granada
Córdoba
Huelva
Créditos
Hombre
Mujer
100
100
400
350
50
65
90
98
100
110
320
295
400
430
120
125
100
105
Tit.
Select Universidad,sexo,
sum(creditos)
From matriculas, alumno
Where
matricula.dni=alumno.dni
group by Universidad, sexo
Univ
Campus
Matricula
CCAA
Asig.
centro
Como la consulta se calcula y ejecuta en tiempo real el dato NO está previamente agregado y el
tiempo de respuesta dependerá de la complejidad, volumen de datos y número de tablas
involucradas en la consulta.
Situación diferente nos encontramos cuando la consulta solicitada aglutina datos de áreas de
análisis diferentes:
Hombre
Créditos
Nº PDI
100
11
400
31
50
6
90
12
100
11
320
15
400
30
120
17
100
10
Universidad
sexo
Cádiz
Sevilla
Pablo Olavide
Jaén
Almería
Málaga
Granada
Córdoba
Huelva
Mujer
Créditos
Nº PDI
100
10
400
35
50
7
90
14
100
10
320
16
400
34
120
15
100
10
Nº PAS TC
Nº Doctores
Nº PDI
Notas
Créditos
Universidad
Campus
Centro
Matriculas
El entornos MOLAP, debe disponer de la información agregada en el cubo correspondiente:
Universidad
Campus
Centro
A
l
u
m
n
o
Nº PDI
Créditos
P
l
a
z
a
s
Universidad
Sexo
El entornos ROLAP, no se debe realizar ninguna modificación en el modelo de datos
implementado, el motor de consultas de la herramienta resuelve la consulta directamente,
mediante una resolución SQL:
Alum.
Tit.
Univ
Asig.
Create table TT1 as
Select Universidad, sexo,
sum(dni) as PDI
From Plazas, empleado
Where matricula.dni=
empleado.dni and tipo=’3’
group by Universidad, sexo
Plazas
Matricula
CCAA
Colec.
Campus
centro
CCE
Create table TT2 as
Select Universidad, sexo,
sum(creditos) as creditos
From matriculas, alumno
Where
matricula.dni=alumno.dni
group by Universidad, sexo
Select Universidad, sexo,
sexo, PDI, creditos
From TT1, TT2
Where TT1.universidad =
TT2.universidad and
TT1.sexo = TT2.sexo
group by Universidad, sexo
MicroStrategy vs. Discoverer (Comparativa)
MicroStrategy es un entorno fundamentalmente ROLAP, aunque en las últimas versiones han
incorporado funcionalidades MOLAP utilizando los informes guardados en la caché a la hora de
ejecutar un informe, es decir cualquiera de los informes que se ejecutan, mediante el sistema
ROLAP, es guardado en forma de cubo multidimensional y se puede utilizar en consultas
posteriores si la información a suministrar está incluida directamente en uno de estos cubos
generados de forma dinámica en el transcurso del tiempo.
Discoverer es un entorno que se podría considerar HOLAP puesto que en el momento de
suministrar datos su filosofía es fundamentalmente MOLAP aunque se basa en un Gestor de Base
de Datos Relacional, es decir desde el nivel de usuario el sistema el Multidimensional, por lo que
cuando se solicita un informe se genera ‘dinámicamente’ el cubo dimensional con el que va a
trabajar, este cubo se debe gestionar mediante una sentencia SQL, a semejanza de un entorno
ROLAP, (esta es una diferencia con los entornos puramente MOLAP, en los que el cubo debe
estar previamente generado). Esto permite generar informes con información dinámica pero tiene
la limitación que el motor que genera las sentencias SQL se limita a proporcionar sentencias
basadas en tablas previamente agregadas y que el cruce de datos con diferentes niveles de
agregación dimensional deben ser previamente implementados en tablas independientes que
unifique el espacio dimensional de análisis. Es decir se trata de un entorno con las ventajas y
limitaciones de los dos sistemas.
Nº PAS TC
Nº Doctores
Nº PDI
Notas
Matriculas
Universidad
Campus
Centro
Créditos
Esto significa que al basarte en filosofía MOLAP, para dar soporte a la mayoría de los informes
analíticos solicitados por los diferentes organismos externos, se requieren cruces de información
entre áreas de gestión diversas, para lo que, como se ha visto anteriormente se deben generar
cubos que agreguen dicha información y que en nuestro caso se han implementado tablas
agregadas que dan dicha cobertura. Esto significa que es inviable generar la totalidad de cruces
entre el conjunto de atributos de todos los Datamart con la totalidad de indicadores implementados,
por lo que siempre pueden encontrarse cruces que en la actualidad no estén contemplados
(aunque su inclusión en el sistema es sumamente sencilla y directa).
Universidad
Campus
Centro
A
l
u
m
n
o
Universidad
Sexo
Nº PDI
Créditos
P
l
a
z
a
s
Universidad sexo
Cádiz
Sevilla
Pablo Olavide
Jaén
Almería
Málaga
Granada
Córdoba
Huelva
Hombre
Créditos
Nº PDI
100
11
400
31
50
6
90
12
100
11
320
15
400
30
120
17
100
10
Mujer
Créditos
Nº PDI
100
10
400
35
50
7
90
14
100
10
320
16
400
34
120
15
100
10
Al tratarse de una herramienta MOLAP sobre un Gestor de Base de Datos Relacional nos
encontramos con otra limitación adicional, se trata de la implementación dinámica de los cubos de
análisis. Los atributos se administran en carpetas desde las cuales, en el interfase de usuario, se
utilizan para su incorporación en los informes dinámicos, dado que la herramienta de análisis
debería ser capaz de trabajar con cualquiera de los atributos de la dimensión incluida en el informe
el motor de base de datos genera un SQL para obtener un cubo con todos los atributos incluidos
en la carpeta de análisis independientemente de los atributos realmente utilizados en el informe,
circunstancia que penaliza los tiempos de respuesta al generarse sentencias SQL sumamente
complejas.
Alumno
Sexo
Edad
Provincia
Pais
Organización
Universidad
Centro
Campus
Docencia
Titulación
Asignatura
Area
Departamento
Tipo Crédito
Créditos
Universidad
sexo
Tipo Crédito
Cádiz
Teóricos
Prácticos
Laboratorio
Sevilla
Teóricos
Prácticos
Laboratorio
Hombre
Mujer
100
400
100
100
400
100
200
1200
230
230
1400
310
Select sexo, edad, provincia, pais,
universidad, centro, campus,
titulación, asignatura, area,
departamento, tipo credito,
sum(creditos)
From lk_alumno. lk_sexo,
lk_provincia, lk_pais, lk_universidad,
lk_centro, lk_campus,
lk_departamento, lk_tipo_credito,
dt_matriculas,
Where
dt_matriculas.dni=lk_alumno.dni and
:
:
Group by sexo, edad, provincia, pais,
universidad, centro, campus,
titulación, asignatura, area,
departamento, tipo credito
Para solventar esta problemática se generan unas tablas desnormalizadas con todas la
información plana, es decir con se trata de tablas de hechos con la incorporación de toda la
información descriptiva de los atributos incluidos en la misma así como de todas las ramas
jerárquicas de las que proceden. Con esta estrategia se dispone de tablas que incorporan toda la
información analítica necesaria a partir de la cual poder generar las sentencias SQL que dan
cobertura a los informes solicitados.
Tras la introducción expuesta, las diferencias entre los dos entornos se pueden resumir en los
siguientes puntos:
•
Si se trabaja y realizan informes sobre el mismo espacio dimensional y sobre la misma
área de gestión, como puede ser Recursos Humanos, Discoverer suministra el mismo nivel
de análisis que MicroStrategy, con el mejor rendimiento teórico y un mismo nivel de
profundidad.
•
Al cruzar en un mismo informe datos, previamente tipificados, de ámbitos de análisis
diferentes (como puede ser Recursos Humanos y Gestión Económica), tanto Discoverer
como MicroStrategy suministraría el mismo nivel de análisis, con la diferencia de que
Discoverer, al trabajar con tablas agregadas, proporcionaría un mayor rendimiento en los
tiempos de respuesta que MicroStrategy.
•
Al cruzar en un mismo informe datos de ámbitos de análisis diferentes, sin que hayan sido
previamente definidos, Discoverer no podría generar la sentencia SQL requerida para la
resolución de dicho informe, y únicamente herramientas como MicroStrategy (herramientas
que son capaces de generar sentencias SQL multipaso) sería capaz de resolver consultas
de este estilo. Si se genera la tabla de agregación correspondiente y se registra en el
entorno de análisis, Discoverer suministrará resultados inmediatamente.