Sistemas OLAP

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


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


Matriculas

El entornos MOLAP, debe disponer de la información agregada en el cubo correspondiente:


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


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).


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.