Contribución a las tecnologías de representación de datos ...

Contribución a las tecnologías derepresentación de datos

para sistemas eficientes deinteligencia de negocio

Autor

Pablo Sendín RañaDirector

Francisco Javier González Castaño

Departamento de Enxeñería Telemática

Tesis doctoral

Contribución a las tecnologías derepresentación de datos para

sistemas eficientes de inteligencia denegocio

Pablo Sendín RañaDirector: Francisco Javier González Castaño

Departamento de Ingeniería Telemática

Universidade de Vigo

2015

Departamento de Enxeñería TelemáticaEscola Enxeñería Telecomunicación

Universidade de VigoCampus Lagoas-Marcosende36310 Vigo, Galicia, Spain

Tesis doctoral

Contribución a las tecnologías derepresentación de datos para

sistemas eficientes de inteligencia denegocio

Director: Pablo Sendín RañaIngeniero de Telecomunicación

Director: Francisco Javier González CastañoCatedrático de universidad del Área de Ingeniería Telemática

2015

Para meus avós, aos que xa non están e a que me queda.

I

“ipsa scientia potestas est”, Francis Bacon, Meditationes Sacrae (1597)

“Knowledge is power. Information is power. The secreting or hoarding of knowledgeor information may be an act of tyranny camouflaged as humility”, Robin Morgan.

III

Abstract

For a long time, relational databases have been used to obtain information in Bu-siness Intelligence systems. As the amount of data increases, new analysis paradigmsand tools are needed. Nowadays on-line analytical processing (OLAP) systems hand-le strategic information and enable fast, multidimensional, interactive and consistentinformation analysis of data warehouses. In addition, the Associative Query Logic(AQL) paradigm allows in-memory Business Intelligence tools, which can representlarge amounts of data in a way that allows extremely fast analysis.

In this thesis we present contributions in two areas of Business Intelligence sys-tems. First, we describe our experience in the migration from a real and large rela-tional database management system to an OLAP system on top of a relational layer(the data warehouse), and the resulting contributions in open-source ROLAP opti-mization. We exploit cache memory instead of cumbersome summarized tables toimprove system performance (in terms of response time). A cold start process bringssummarized data from the data warehouse to cache memory reducing the responsetime. We ensure concurrent access to the summarized data, as well as consistencyin data warehouse updates. We also improve the OLAP functionality by definingcalculated dimensions, making possible to define new measures on the fly, withoutre-designing the multidimensional cube.

Second, we present a web-based business intelligence tool following the AQL pa-radigm, developed as an open-source, multi-platform software, relying on data com-pression techniques for the storage of large amounts of data in main memory. Theperformance of our solution in terms of compression, load time and response timeis close to that of the commercial tool of reference, QlikView. Moreover, we providesolutions to some open problems in QlikView published description, which may bebeneficial to assist in the development of other open or proprietary tools.

Keywords: Business Intelligence, On-Line Analytical Processing, data warehou-ses, Associative Query Logic.

V

Resumen

Tradicionalmente, las bases de datos relacionales se han utilizado para obtenerinformación en los sistemas de Inteligencia de Negocio (Business Intelligence). Amedida que dichos sistemas utilizaban mayor volumen de datos, han sido necesa-rios nuevos paradigmas y herramientas de análisis. Hoy en día, los sistemas OLAP(On-Line Analytical Processing) se encargan de gestionar información estratégica yde proporcionar un análisis rápido, multidimensional, interactivo y consistente dela información contenida en los almacenes de datos. Además, el paradigma AQL(Associative Query Logic) aplicado a Inteligencia de Negocio permite definir he-rramientas que gestionan todos los datos en memoria, lo que permite un análisisextremadamente rápido de grandes cantidades de datos.

En esta tesis se presentan contribuciones en dos áreas de los sistemas de Inteli-gencia de Negocio. Primero, describimos nuestra experiencia en la migración de unsistema de gestión de base de datos relacional real y de gran tamaño, a un sistemaOLAP que se apoya en una capa relacional subyacente que conforma un almacénde datos. Como resultado, se han generado contribuciones en la optimización delsistema ROLAP de código abierto. Hemos desarrollado una memoria cache que evi-ta los problemas de diseño y mantenimiento de soluciones tradicionales que utilizantablas agregadas para mejorar el rendimiento del sistema (en términos de tiempo derespuesta). En nuestra solución, el proceso cold start genera datos agregados paraalimentar la memoria cache, obtenidos a partir del almacén de datos relacional, conlo que se reducen los tiempos de respuesta. Con este procedimiento se asegura elacceso concurrente a los datos y la consistencia de los mismos, cuando se efectúanmodificaciones en el almacén de datos. Además, se mejora la funcionalidad del siste-ma OLAP con la definición de dimensiones calculadas, que permiten definir nuevasmedidas en tiempo real, sin la necesidad de rediseñar el cubo multidimensional.

En segundo lugar, presentamos nuestra experiencia en el desarrollo de una herra-mienta de Inteligencia de Negocio para entorno web, según el paradigma AQL. Lahemos desarrollado como herramienta de código abierto multiplataforma. Se utilizantécnicas de compresión de datos para el almacenamiento de grandes cantidades dedatos en memoria principal. El rendimiento de nuestra solución es comparable alde herramientas comerciales (tomando a QlikView como referencia) en términos decompresión, tiempo de carga y tiempo de respuesta. Además se proponen soluciones

VII

para solucionar algunos problemas detectados en la descripción de las patentes deQlikView, las cuales pueden ayudar en el desarrollo de otras herramientas propieta-rias o de código abierto.

Palabras clave: Inteligencia de Negocio, On-Line Analytical Processing, almace-nes de datos, Associative Query Logic.

VIII

Agradecimientos

Esta tesis es el producto de la ayuda y el apoyo de mucha gente. Es mi deberintentar reconocérselo en unas pocas líneas.

Javier, mi director, ha sido fundamental para poder llevar a buen término estetrabajo doctoral. Dar las gracias a mis amigos y compañeros de la Escuela de Tele-comunicación, en especial a Nico, Rubén, Eduardo y todos los miembros del grupoGTI del Departamento de Telemática. Ellos han contribuido a mi formación acadé-mica y personal. También han aportado a ese proceso mis actuales compañeros delCentro Universitario de la Defensa, los que corren y los que no. Gracias a Chemapor su persistencia en el proceso de escritura.

Gracias también a todo el desarrollo personal y profesional que he experimentadodesde que entré, por primera vez, en la Escuela de Telecomunicación. A todos miscompañeros del SPTV, del Foro Tecnolóxico de Emprego, a mi paso por Adianta,etc. Es cierto que de todas las experiencias, buenas o malas, se aprende y se pue-den extraer cosas positivas. Además, he de agradecer a Saec Data por su ayuda ycolaboración, en particular a Pablo, Marta y Enrique.

Gracias a mis amigos de la infancia. Con ellos se compartieron aficiones y secrearon las revistas Arroto y Alquimia.

Por supuesto mi agradecimiento a mi familia, a mis padres por su constante so-porte, a mi hermana Marta, a mis sobrinos, y a Manola por aguantarme y dejarmequererla. A mis dos princesas, Leia y Arwen, por ser la causa de continuas interrup-ciones, y por ofrecerme una perspectiva diferente de lo que es la vida y el sufrimiento.

Disculparme por todas aquellas personas que seguro olvido y que merecen sermencionadas. También para ellas mi agradecimiento.

IX

Índice general

1. Introducción 11.1. Perspectiva . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2. Motivación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.3. Panorama actual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.3.1. Antecedentes de la Inteligencia de Negocio . . . . . . . . . . . 61.3.2. Evolución de las tecnologías de Inteligencia de Negocio . . . . 71.3.3. Ámbito de aplicación de las tecnologías Inteligencia de Negocio 10

1.4. Tecnologías de Inteligencia de Negocio . . . . . . . . . . . . . . . . . 111.5. Arquitectura de los sistemas de Inteligencia de Negocio . . . . . . . . 15

1.5.1. Recolección de Datos . . . . . . . . . . . . . . . . . . . . . . . 151.5.2. ETL (Extract, Transform and Load) . . . . . . . . . . . . . . 151.5.3. Data Warehouse . . . . . . . . . . . . . . . . . . . . . . . . . 15

1.5.3.1. Almacenamiento de los datos . . . . . . . . . . . . . 171.5.4. Servidores intermedios . . . . . . . . . . . . . . . . . . . . . . 181.5.5. Presentación . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

1.6. Retos de las tecnologías Inteligencia de Negocio . . . . . . . . . . . . 181.7. Contenido . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2. Estado del arte 232.1. Sistemas OLAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

2.1.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242.1.2. Tecnologías OLAP . . . . . . . . . . . . . . . . . . . . . . . . 262.1.3. Soluciones OLAP . . . . . . . . . . . . . . . . . . . . . . . . . 292.1.4. Solución basada en Mondrian . . . . . . . . . . . . . . . . . . 31

2.1.4.1. Arquitectura de Mondrian . . . . . . . . . . . . . . 342.1.4.2. Extensibilidad de Mondrian . . . . . . . . . . . . . 36

2.2. Sistemas de Inteligencia de Negocio en-memoria . . . . . . . . . . . . 392.2.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392.2.2. AQL y Data Clouds . . . . . . . . . . . . . . . . . . . . . . . . 39

2.2.2.1. Ventajas y desventajas de este enfoque . . . . . . . . 402.2.2.2. Dentro del AQL y de los Data Clouds . . . . . . . . 412.2.2.3. Proceso de filtrado . . . . . . . . . . . . . . . . . . . 45

XI

Índice general

2.3. Plataformas para aplicaciones distribuidas . . . . . . . . . . . . . . . 462.3.1. Apache Hadoop en sistemas de Inteligencia de Negocio . . . . 48

2.3.1.1. Descripción de Apache Hadoop . . . . . . . . . . . . 482.3.1.2. Integración de Apache Hadoop en sistemas de Inteli-

gencia de Negocio . . . . . . . . . . . . . . . . . . . 492.3.2. Apache Spark en sistemas de Inteligencia de Negocio . . . . . 50

2.3.2.1. Descripción de Apache Spark . . . . . . . . . . . . . 502.3.2.2. Integración de Apache Spark en sistemas de Inteli-

gencia de Negocio . . . . . . . . . . . . . . . . . . . 51

3. Contribuciones 533.1. Mejora del rendimiento y funcionalidad de sistemas OLAP . . . . . . 54

3.1.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . 543.1.2. Diseño multidimensional . . . . . . . . . . . . . . . . . . . . . 553.1.3. Mejora de funcionalidad: el uso de dimensiones calculadas . . 593.1.4. Mejora de rendimiento en los coldstarts . . . . . . . . . . . . . 653.1.5. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

3.2. Sistemas de Inteligencia de Negocio basados en Associative Query Logic 773.2.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . 773.2.2. Solución web de Inteligencia de Negocio basada en AQL . . . 77

3.2.2.1. Cuadro de mando integral . . . . . . . . . . . . . . . 773.2.2.2. Arquitectura orientada a servicio . . . . . . . . . . . 783.2.2.3. Diseño . . . . . . . . . . . . . . . . . . . . . . . . . . 823.2.2.4. Mejoras del algoritmo: Carga y almacenamiento de

datos eficiente . . . . . . . . . . . . . . . . . . . . . . 873.2.2.5. Mejoras del algoritmo: Establecimiento de un orden

en la comprobación de tablas . . . . . . . . . . . . . 893.2.2.6. Uso del algoritmo mejorado para la extracción de

resultados . . . . . . . . . . . . . . . . . . . . . . . . 953.2.3. Resultados numéricos . . . . . . . . . . . . . . . . . . . . . . . 993.2.4. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

3.3. Mejora en el proceso de recarga de datos en soluciones web AQL . . . 1063.3.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1063.3.2. Funcionamiento del algoritmo de recarga optimizado . . . . . 1073.3.3. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

4. Conclusiones 1174.1. Mejora de sistemas ROLAP . . . . . . . . . . . . . . . . . . . . . . . 1174.2. Solución web basada en AQL . . . . . . . . . . . . . . . . . . . . . . 1194.3. Líneas futuras . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120

XII

Índice general

A. Esquema multidimensional 121

B. Script de carga 125B.1. Clientes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125B.2. Proveedores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126B.3. Facturas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126B.4. Especies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129B.5. Vales y cobros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129B.6. Pagos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

C. Glosario 133

Bibliografía 139

XIII

Índice de figuras

1.1. Línea temporal de la historia del Business Intelligence. . . . . . . . . 81.2. Las cinco capas de una implementación de inteligencia de negocio

tradicional. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.1. Descomposición de una sentencia MDX en varias sentencias SQL. . . 282.2. Ejemplo de cubo multidimensional. . . . . . . . . . . . . . . . . . . . 322.3. Capas en la arquitectura de Mondrian (tomado de [Mondrian, WWW]). 352.4. Modo de operación de Mondrian como proveedor XML/A (tomado

de [Sendin-Raña et al., 2009]). . . . . . . . . . . . . . . . . . . . . . . 372.5. Ejemplo de petición SOAP. . . . . . . . . . . . . . . . . . . . . . . . 382.6. Vista de un panel de control de QlikView (tomado de [Sendin-Raña et al., 2010]). 402.7. Representación gráfica de los vectores de estado y selección (tomado

de [Sendin-Raña et al., 2010]). . . . . . . . . . . . . . . . . . . . . . . 452.8. Diagrama de flujo que representa el algoritmo AQL para el proceso

de filtrado (tomado de [Sendin-Raña et al., 2010]). . . . . . . . . . . . 472.9. Funciones map y reduce. . . . . . . . . . . . . . . . . . . . . . . . . . 49

3.1. Modelo de la estructura relacional subyacente (tomado de [Sendin-Raña et al., 2009]). 563.2. Esquema multidimensional para la definición del cubo en Mondrian. . 583.3. Fragmento de esquema multidimensional para la definición de una

dimensión calculada. . . . . . . . . . . . . . . . . . . . . . . . . . . . 613.4. Sentencia MDX con uso de dimensión calculada. . . . . . . . . . . . . 613.5. Sentencia MDX sin uso de dimensión calculada. . . . . . . . . . . . . 623.6. Definición de dimensión calculada. . . . . . . . . . . . . . . . . . . . . 643.7. Sentencia MDX que combina tres medidas con los miembros de una

dimensión calculada. . . . . . . . . . . . . . . . . . . . . . . . . . . . 643.8. Informe utilizando JPivot (tomado de [Sendin-Raña et al., 2009]). . . 653.9. Tiempos de respuesta ante peticiones MDX complejas (tomado de

[Sendin-Raña et al., 2009]). . . . . . . . . . . . . . . . . . . . . . . . . 683.10. Acciones que lleva a cabo la clase ServletColdStart (tomado de [Sendin-Raña et al., 2009]). 723.11. Proceso de obtención de datos de las diferentes cachés (tomado de

[Sendin-Raña et al., 2009]). . . . . . . . . . . . . . . . . . . . . . . . . 73

XV

Índice de figuras

3.12. Tiempo necesario para construir la cache de Mondrian mediante elproceso cold start (tomado de [Sendin-Raña et al., 2009]). . . . . . . . 75

3.13. Esquema que define las peticiones SOAP. . . . . . . . . . . . . . . . . 803.14. Esquema que define las respuestas SOAP. . . . . . . . . . . . . . . . . 813.15. Diseño global de la solución web de BI con almacén de datos en memoria. 823.16. Diseño detallado de la solución web de BI con almacén de datos en

memoria. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 833.17. Diseño de la metodología para la reducción del tiempo de carga y del

consumo de espacio en memoria principal (tomado de [Sendin-Raña et al., 2010]). 883.18. Ejemplo de un script para la carga de datos desde una fuente de datos

a la memoria principal (tomado de [Sendin-Raña et al., 2010]). . . . . 963.19. Ejemplo de un cuadro de mandos con tres listas para filtrado y tres

gráficas (tomado de [Sendin-Raña et al., 2010]). . . . . . . . . . . . . 973.20. Ejemplo de cuadro de mandos con filtrado por producto (tomado de

[Sendin-Raña et al., 2010]). . . . . . . . . . . . . . . . . . . . . . . . . 973.21. Ejemplo de cuadro de mandos con filtrado por tienda. Se muestran

en las gráficas la información de ventas asociada a esa tienda (tomadode [Sendin-Raña et al., 2010]). . . . . . . . . . . . . . . . . . . . . . . 98

3.22. Comparación entre los tiempos de carga entre nuestra propuesta yQlikView (tomado de [Sendin-Raña et al., 2010]). . . . . . . . . . . . 100

3.23. Comparación del consumo de memoria principal entre nuestra pro-puesta y QlikView (tomado de [Sendin-Raña et al., 2010]). . . . . . . 101

3.24. Consumo de memoria principal durante el proceso de carga de da-tos. El eje horizontal representa el tiempo consumido (tomado de[Sendin-Raña et al., 2010]). . . . . . . . . . . . . . . . . . . . . . . . . 102

3.25. Comparación entre nuestra propuesta y QlikView del consumo dememoria principal cuando se utilizan los alias en el proceso de cargade datos (tomado de [Sendin-Raña et al., 2010]). . . . . . . . . . . . . 103

3.26. Tiempo de filtrado (tomado de [Sendin-Raña et al., 2010]). . . . . . . 1043.27. Tiempos de respuesta ante acciones de filtrado para la representación

en forma de tablas o de gráficos en el panel de control del usuario(tomado de [Sendin-Raña et al., 2010]). . . . . . . . . . . . . . . . . . 105

XVI

Índice de cuadros

2.1. Comparativa de las soluciones OLAP open source más relevantes. . . 302.2. Estructura X, asociada con la estructura Y por medio de lugar de

nacimiento. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 422.3. Estructura Y, asociada con la estructura X por medio de lugar de

nacimiento. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 422.4. Tabla de correspondencia binaria para Nombre. . . . . . . . . . . . . 422.5. Tabla de correspondencia binaria para Edad. . . . . . . . . . . . . . . 432.6. Tabla de correspondencia binaria para Lugar de nacimiento. . . . . . 432.7. Tabla de correspondencia binaria para País. . . . . . . . . . . . . . . 432.8. Tabla binaria para la estructura X. . . . . . . . . . . . . . . . . . . . 442.9. Tabla binaria para la estructura Y. . . . . . . . . . . . . . . . . . . . 44

3.1. Tablas nombre y edad. . . . . . . . . . . . . . . . . . . . . . . . . . . 893.2. Tabla de correspondencia binaria para los valores de ID. . . . . . . . 893.3. Tabla de correspondencia binaria para los valores de nombre. . . . . . 893.4. Tabla de correspondencia binaria para los valores de edad. . . . . . . 903.5. Tabla para un ejemplo de operación del nuevo algoritmo. . . . . . . . 943.6. Valores finales de los vectores de estado. . . . . . . . . . . . . . . . . 943.7. Tabla A. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1083.8. Tabla B. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1083.9. Tabla C. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1083.10. Tablas de correspondencias binarias para Nombre. . . . . . . . . . . . 1093.11. Tablas de correspondencias binarias para Viaje. . . . . . . . . . . . . 1093.12. Tablas de correspondencias binarias para Dinero. . . . . . . . . . . . 1093.13. Tablas de correspondencias binarias para Fechas. . . . . . . . . . . . 1093.14. Tablas de correspondencias binarias para Estado. . . . . . . . . . . . 1103.15. Tablas de correspondencias binarias para Dirección. . . . . . . . . . . 1103.16. Tablas de correspondencias binarias para Ciudad. . . . . . . . . . . . 1103.17. Tablas de correspondencias binarias para País. . . . . . . . . . . . . . 1103.18. Tabla binaria A. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1113.19. Tabla binaria B. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1113.20. Tabla binaria C. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

XVII

Índice de cuadros

3.21. Tabla binaria. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

XVIII

Capítulo 1Introducción

Índice1.1. Perspectiva . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2. Motivación . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.3. Panorama actual . . . . . . . . . . . . . . . . . . . . . . . . 4

1.3.1. Antecedentes de la Inteligencia de Negocio . . . . . . . . . 61.3.2. Evolución de las tecnologías de Inteligencia de Negocio . . 71.3.3. Ámbito de aplicación de las tecnologías Inteligencia de

Negocio . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101.4. Tecnologías de Inteligencia de Negocio . . . . . . . . . . 111.5. Arquitectura de los sistemas de Inteligencia de Negocio 15

1.5.1. Recolección de Datos . . . . . . . . . . . . . . . . . . . . . 151.5.2. ETL (Extract, Transform and Load) . . . . . . . . . . . . 151.5.3. Data Warehouse . . . . . . . . . . . . . . . . . . . . . . . 151.5.4. Servidores intermedios . . . . . . . . . . . . . . . . . . . . 181.5.5. Presentación . . . . . . . . . . . . . . . . . . . . . . . . . 18

1.6. Retos de las tecnologías Inteligencia de Negocio . . . . . 181.7. Contenido . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

1.1. Perspectiva

La idea de que la información es poder no es nueva en absoluto, y está ampliamenteextendida en todo el mundo. La posesión de información relevante permite unavisión real de situaciones o estados, y tomar decisiones que con mayor probabilidadtendrán como consecuencia un cambio en la dirección deseada. Los centros de poder

1

1. Introducción

(económicos, políticos o sociales) demandan que esta información tenga las siguientescaracterísticas:

Clara, precisa y relevante.Disponible en todo momento.Actualizada.

La necesidad de obtención de información ha sido tan significativa históricamen-te que se han creado agencias u organismos encargados de su obtención mediantemétodos lícitos o ilícitos.

El término Business Intelligence (BI), o Inteligencia de Negocio, se refiere a lainteligencia generada a partir de una información que es valiosa por su relevanciay vigencia. Hace referencia al conocimiento obtenido a partir de aplicaciones o tec-nologías que analizan un gran conjunto de datos, y se ha convertido en las últimasdécadas en un arma fundamental que permite mejorar la toma de decisiones. Porponer un ejemplo paradigmático, el conocimiento toma una vital importancia enel ámbito de los negocios, en la toma de decisiones estratégicas, para situar a unaempresa en una situación dominante sobre la competencia.

Formalmente, los términos inteligencia empresarial, inteligencia de negocio o BIdenominan al conjunto de estrategias y herramientas enfocadas a la administración ycreación de conocimiento mediante el análisis de datos existentes en una organizacióno empresa. Cuando hablamos de sistemas de inteligencia de negocio o inteligenciaempresarial nos referimos a sistemas software que asisten a la toma de decisiones enmuchos ámbitos, a la agregación de datos relevantes, a la correlación entre ellos, ya métricas utilizadas para su monitorización y análisis. Como resultado se obtieneconocimiento.

El éxito de una organización no depende tan sólo de la calidad del objeto de suactividad, sea producto, acción o servicio. También depende de la toma de decisionesestratégicas que permitan evolucionar en la dirección correcta. La toma de decisio-nes efectivas, y dirigidas correctamente, viene marcada por el conocimiento previodel tipo de usuario al que va dirigido, de los procesos internos, de la efectividad enlas operaciones, de los competidores, de las posibles alianzas y del marco socioeco-nómico, entre otros. El único medio para conocer estas variables es disponer de lainformación adecuada en tiempo y forma. Gracias a las tecnologías de inteligenciade negocio esto es posible.

El resto de este capítulo está organizado del siguiente modo. El apartado 1.2presenta las motivaciones de las contribuciones que forman parte de este trabajodoctoral. El apartado 1.3 analiza el panorama actual de los sistemas de inteligenciade negocio, describiendo los antecedentes históricos de estas tecnologías, su evoluciónde las últimas décadas, y los ámbitos donde se aplican. El apartado 1.4 introduce

2

1.2. Motivación

las diferentes tecnologías de inteligencia de negocio, y el apartado 1.5 presenta lascapas más comunes de los sistemas de BI. A continuación, el apartado 1.6 describe losprincipales retos a los que se enfrentan actualmente estas tecnologías. Para concluir,el apartado 1.7 presenta el contenido de este trabajo doctoral, desarrollado en lossiguientes capítulos.

1.2. Motivación

Como se presentará en las siguientes secciones de este capítulo introductorio, lossistemas de inteligencia de negocio son relativamente recientes y, más importante,evolucionan rápidamente, aprovechándose de los avances técnicos de los sistemashardware en los que se apoyan. Los productos comerciales de BI, tanto propietarioscomo de tipo open source o código abierto, son generalistas y no están ideados paraproblemas particulares. Es por ello que, en ocasiones, las empresas que demandansoluciones concretas no encuentran en el mercado un producto de inteligencia denegocio que las satisfaga completamente.

Esta tesis doctoral nace de las necesidades concretas de una plataforma tecnológicagallega de gestión de capturas de pescado, llamada Pesca Fresca. Esta plataformase creó como una colaboración entre el Ministerio de Agricultura de España, laSecretaría General de Pesca y Asuntos Marítimos y la Consellería do Medio Rural edo Mar de la Xunta de Galicia. Esta plataforma mantiene información estadística delas capturas de pescado (precio de venta diario y auditoría -aution data-), informesde los barcos pesqueros y otras informaciones comerciales relacionadas. El volumende los datos generados diariamente era y es inmenso: Galicia tiene 1.498 km decosta, actualmente cuenta con 61 lonjas en sus numerosos puertos pesqueros, y unode estos puertos, el de Vigo, es el puerto de pesca más importante de Europa. Entreenero y mayo del año 2015, el puerto pesquero de Vigo registró 25.281 toneladas dedescarga de pesca fresca.

La plataforma utilizaba una base de datos relacional (también llamada PescaFresca) de tamaño muy elevado. Pesca Fresca soportaba unos análisis muy limitados,y fallaba en aspectos clave como la generación de resúmenes y consolidación dedatos. Implantar un sistema OLAP parecía la aproximación natural para resolverestas limitaciones y proporcionar soluciones de generación de informes y extracciónmanual de conocimiento.

En el apartado 3.1 se presenta en detalle la solución que se adoptó. El volumende información generada por las lonjas de los puertos pesqueros de Galicia, sumadoa las necesidades de disponibilidad y actualización en tiempo real de los datos enla plataforma de control, hicieron necesaria la implantación de una solución que noexistía en aquel momento en el mercado. Esta solución cubría las necesidades identi-

3

1. Introducción

ficadas con unos costes de desarrollo razonables, a partir de código abierto existente:Mondrian [Mondrian, WWW]. Este sistema siguió manteniendo la información ge-nerada por cada lonja en una base de datos relacional (se utilizó, por tanto, unasolución ROLAP, Relational OLAP), lo que permitió una migración natural y unatransición no traumática al sistema de análisis multidimensional.

Más tarde las necesidades variaron, y se planteó la migración de aquel sistema deinteligencia de negocio tradicional a otro más novedoso. Concretamente se propusoun sistema que utilizase la memoria principal, y no memorias secundarias, paraconstituir el almacén de datos. Ya existían en el mercado soluciones comerciales ypropietarias que con éxito habían emprendido este camino. Sin embargo, la filosofíadel proyecto financiador era utilizar código abierto, y su visión era construir unservicio web. Por tanto, se emprendió el desarrollo de una solución de inteligenciade negocio basada en AQL (Associative Query Logic) que cumpliese con esas dospremisas. El resultado fue la contribución presentada en el apartado 3.2.

Por último, en el capítulo 3.3 se presenta una solución para que esta soluciónbasada en AQL pueda resolver el problema de la recarga de datos de manera asín-crona. Se trata de un problema habitual de los sistemas de inteligencia de negocio:disponer de una visión actualizada de los datos en el sistema que permita el análisis,pero sin penalizar la disponibilidad de los mismos.

1.3. Panorama actual

Hoy en día existen repositorios donde se almacenan enormes cantidades de datos.Las trazas resultan constantemente de nuestras operaciones bancarias, de los recur-sos que visitamos en la red, de los flujos de tráfico en la red viaria, o de las variablesmeteorológicas [Radar O’Reilly, WWW]. Se monitorizan los consumos eléctricos, delas redes de voz y datos, y de suministro de agua y gas. Se indexan estos datospor rangos de edades de los consumidores, nivel educativo, rango temporal, o lo-calización geográfica. El reto tecnológico es obtener conocimiento a partir de estaingente cantidad de datos generados, y para ello se utilizan diferentes tecnologías deinteligencia de negocio. De acuerdo con un estudio de empresa IBM [IBM, WWW],más de 2.5 quintillones de bytes de datos se generan actualmente cada día.

Normalmente, estos sistemas de adquisición de datos son dispersos y en la mayoríade los casos heterogéneos. Distintas fuentes de datos normalmente implican diferen-tes mecanismos de representación. Cuanto más integrados estén estos sistemas deinformación en una organización, más sencillo será el mantenimiento, la actualiza-ción, y la obtención de conocimiento. De este modo los gestores estarán en una mejorposición para la toma de decisiones.

4


El BI se beneficia de la revolución tecnológica ya que se presentan dos hechosfundamentales:

El aumento de estándares, de procesos automáticos y de tecnologías para lacaptura de datos genera una gran cantidad de datos en bruto. En realidad, estocausa el problema de la avalancha de datos presentado [Miller, 2010], y sólomediante las tecnologías de Extract, Transform and Load (ETL) y los alma-cenes de datos (Data Warehouses, DWs), es factible alimentar de informacióna las tecnologías encargadas del análisis.La aparición de las tecnologías de análisis de datos, como por ejemplo On-LineAnalytical Processing (OLAP), que permiten la generación rápida de informespara la toma de decisiones. Estas tecnologías se benefician de los avances quepermiten mayores velocidades de cómputo, mayores tamaños de memorias, dealmacenamiento, y menores costes.

Las principales actividades del BI, o los diferentes niveles que existen en un sistemade inteligencia de negocio, se pueden resumir en:

Recolección de datos. Estos datos provienen de diferentes fuentes (heterogé-neas) y pueden estar distribuidas.Extracción, transformación, preparado y carga de los datos. Los datos se trans-forman, se filtran y se cargan en los almacenes de datos (Data Warehouses).Almacenamiento de datos en Data Warehouses, almacenes de información op-timizados para suministrar de forma eficiente datos agregados a las capas su-periores.Análisis de los datos, motores analíticos. Los datos se proporcionan a los usua-rios mediante sofisticadas herramientas que permiten su análisis, la generaciónde informes, el modelado y la planificación.Presentación. Se le proporcionan a los usuarios paneles de control, que sonaplicaciones que permiten visualizar, filtrar y navegar en diferentes niveles deprofundidad.

Las contribuciones presentadas en este trabajo doctoral se centran en las capasde Data Warehouse y análisis de datos.

Hoy en día el BI se ha convertido en el arte de gestionar enormes cantidades dedatos, extraer información relevante, y convertir esa información en conocimiento.

5

1. Introducción

1.3.1. Antecedentes de la Inteligencia de Negocio

La inteligencia de negocio permite a las organizaciones tomar decisiones en basea un conocimiento bien informado, actual y relevante. También permite realizarprevisiones sobre tendencias futuras y escenarios posibles.

La Real Academia Española define información como la “adquisición de conoci-miento que permite ampliar o procesar los datos que se poseen sobre una materiadeterminada”. Sin embargo dato es definido como “antecedente necesario para llegaral conocimiento”. Del antecedente a la propia adquisición existe un paso intermedioque tradicionalmente el razonamiento humano, basado en conocimientos y experien-cias previas, se encargaba de salvar. Sin embargo, el criterio personal es subjetivoe influenciable por variables externas. Además, el volumen de datos que un sujetopuede manejar es reducido. En la actualidad este modelo es impracticable por elingente volumen de datos que cualquier empresa u organización maneja. La inte-ligencia de negocio permite abordar la adquisición de conocimiento evitando estosproblemas; por lo que era necesario formalizar la extracción de información parauna toma de decisiones eficiente.

“The Functions of the Executive” [Barnard, 1938] es quizá uno de los libros másinfluyentes del pasado siglo XX sobre gestión empresarial y liderazgo. Su autor,Chester Barnard, cambió el modo en el que los ejecutivos dirigían las grandes com-pañías, formalizando sus funciones, y de este modo mejorando la eficiencia de susorganizaciones. El sistema propuesto incorporaba el termino toma de decisiones,importado de la administración pública al mundo de los negocios.

Chester Barnard expuso la necesidad de minimizar la influencia de parámetrosinformales en la toma de decisiones. Los ejecutivos no debían optar por una u otrapolítica en base a intuiciones o impulsos. Decidir es una habilidad de “racionalidadrestringida” debido en gran parte a circunstancias complejas, tiempos acotados enla elección y un poder computacional mental limitado. Aun con la suficiente infor-mación la decisión puede no ser la óptima.

Además, se cambia el modelo de deliberación continua (Hamlet y el “ser o no ser”)por una serie de pasos que finalizan con la obtención de una serie de conclusiones,una decisión que implica el fin de la deliberación y el inicio de la acción a tomar.Es un nuevo estilo de acción y deseo de resolución: las formulaciones no puedenprolongarse indefinidamente, los recursos han de asignarse.

A escala corporativa o gubernamental, las implicaciones de toma de decisionespueden involucrar costos enormes, incluso en situaciones de acierto, ya que posiblesrumbos descartados pueden implicar costos de oportunidades perdidas. Las organi-zaciones deben ser capaces de calcular y gestionar riesgos en base a posibles tomasde decisión. Las herramientas que la era tecnológica pone a nuestro alcance, en for-

6


ma de herramientas de inteligencia de negocio, pueden asistir en la toma objetivade decisiones.

Algunas de las bondades del BI son la eliminación de las conjeturas en el procesode toma de decisiones, la mejora en la comunicación y coordinación entre depar-tamentos, y la rapidez de respuesta ante cambios de condiciones en el campo encuestión (financiero, medioambiental, etc.). Las compañías y organizaciones mejo-ran su desempeño gracias a las decisiones basadas en ese conocimiento certero yrápidamente adquirido.

1.3.2. Evolución de las tecnologías de Inteligencia de Negocio

Existen numerosas aproximaciones en el universo de los sistemas de inteligencia denegocio, desde los sistemas más simples de petición y generación de informes, hastalos sistemas de BI más complejos, por ejemplo los modelos predictivos del tiempometeorológico. En [Power, WWW] se ofrece una visión profunda y reveladora dela evolución de los sistemas de toma de decisión, desde los inicios de los años 60,con los model-driven DSSs, hasta los sistemas OLAP y de Data Warehousing quecomenzaron a triunfar en los 90.

El termino BI se popularizó a finales del siglo pasado, como ilustra la figura 1.1.Hans Peter Luhn, ingeniero de IBM, lo definió en 1958 como “the ability to apprehendthe interrelationships of presented facts in such a way as to guide action towards adesired goal”. A mediados de los años 70 se empezaron a fundar empresas cuyoobjetivo era crear soluciones para la inteligencia de negocio. Las primeras llegaronal mercado en los años 80. Howard Dresner, que más tarde entraría a formar parte delfamoso Gartner Group como analista, propuso en 1989 que el término BI se podríadefinir como “concepts and methods to improve business decision making by usingfact-based support systems”. En la década de los 90 ya existían en el mercado variasherramientas comerciales para inteligencia de negocio, como por ejemplo CrystalReports, de Microsoft.

Se pueden considerar como principales contribuciones al área de inteligencia denegocio los trabajos de Kimbal [Kimbal, 2008], en 1996, e Inmon [Inmon, 2005], quepublica su trabajo en 1992. El término cubo, esa estructura de datos multidimen-sional tan omnipresente en el BI, fue acuñado por Kimball. Inmon introduce unaarquitectura para el datawarehousing, donde los datos, inicialmente almacenados enbases de datos u otros sistemas similares, son transformados y trasladados a los Da-ta Warehouses. Esto se realiza mediante herramientas ETL. Más tarde, estos datosson transformados y movidos de nuevo a un conjunto de Data Marts (colecciones dedatos, específicas para aplicaciones, optimizadas para alto desempeño). Actualmen-te este modelo no se sigue estrictamente, siendo más extendido el acceso directo al

7

1. Introducción

Figura 1.1.: Línea temporal de la historia del Business Intelligence.

8


Data Warehouse para el análisis de datos.Las primeras aplicaciones para entornos web surgieron a finales de los años 90. Los

móviles se convirtieron en terminales adecuados para las herramientas de inteligenciade negocio a inicios del nuevo milenio, aunque esto no ganó popularidad hasta ellanzamiento del iPhone y de los móviles con sistema Android.

El crecimiento de los sistemas de inteligencia de negocio ha sido espectacular:en el año 2009 dobló los resultados del año anterior (de un 7 % a un 15 %), y elcrecimiento actual está en torno a un 20 %.

Los primeros sistemas de inteligencia de negocio tenían el inconveniente de noser intuitivos, por lo que los usuarios que los manejaban normalmente debían serexpertos en el uso de ese software, y al mismo tiempo en el tipo de datos que estabanmanejando. Eran los llamados analistas. Por tanto, un analista manejaba con solturaeste complejo software, y conocía y comprendía la naturaleza de los datos con losque trabajaba, pero no la audiencia a quién iba dirigido el resultado. Era, de hecho,un intermediario entre el software de inteligencia de negocio y el sujeto que debíaconsumir los análisis e informes. Este sujeto consumidor no poseía los conocimientosnecesarios para manejar el sistema de inteligencia de negocio.

Este esquema tiene claras desventajas, e incurre en costes adicionales derivadosde la necesidad de que los analistas y los consumidores finales estén coordinados.La solución pasa por que el consumidor final pueda adoptar el rol de analista, y ellopasa por simplificar y dotar a las aplicaciones de inteligencia de negocio de facilidadde uso.

Debido a la simplicidad de las nuevas interfaces gráficas y de la facilidad paraentender los nuevos sistemas de inteligencia de negocio, actualmente la audiencia seha democratizado y ya no es necesario contar con un personal especialista. Ya noes necesario escribir complejos scripts, macros o funciones para generar informes oresolver preguntas: ahora se pueden resolver con simples controles visuales (filtros,barras de desplazamiento, selección, etc.).

Otra de las características iniciales de los sistemas de inteligencia de negocio erasu rigidez y su falta de estandarización. Esto era debido a que los sistemas eranpropietarios, y que las arquitecturas eran cerradas. Este modelo ha ido cambiando,adoptando nuevas metodologías de desarrollo y utilizando SOA (Service-OrientedArchitecture). De este modo han disminuido los tiempos de desarrollo y los costesde los sistemas de inteligencia de negocio, y el software es ahora más flexible. Enla actualidad, los nuevos sistemas BI suelen proporcionar una API abierta paraconectarla con otras aplicaciones.

También se ha dado una evolución en el modelo de implementación. Las primerasaplicaciones fueron ideadas para estaciones de trabajo, desarrolladas en lenguajes de

9

1. Introducción

programación de alto nivel (como C++, Java o VisualBasic). Aparecieron algunasaplicaciones más populares, como las hojas de cálculo, pero el modelo fue derivandohacia aplicaciones web. Inicialmente, utilizando plug-ins de Java o ActiveX parasimular el comportamiento de las aplicaciones ya consolidadas. Sin embargo, supenetración no fue muy buena debido a las carencias de su interfaz. Pero con losrecientes avances de las tecnologías web, ya maduras, las siguientes versiones fueronganando terreno. La Web 2.0 ha mejorado sensiblemente el aspecto y la respuestade las aplicaciones web de inteligencia de negocio.

El modelo de las aplicaciones web soluciona los problemas de anteriores modelos,donde los usuarios guardaban localmente datos, y debían posteriormente compar-tirlos. Con las plataformas web los datos están localizados en un servidor central, ycualquier terminal puede convertirse en un cliente desde donde generar informes orealizar análisis.

Microsoft SQL Server 2008 [Larson, 2009] puede ser un buen ejemplo de una apli-cación de inteligencia de negocio tradicional. Proporciona herramientas que permi-ten automatizar la actualización y traslado de los datos al Data Warehouse. Utilizaqueries (peticiones) MDX (MultiDimensional eXpression) para realizar peticionesal cubo multidimensional generado y UDM (Unified Dimensional Model) para sliceand dice y agregar datos. Proporciona herramientas de Data Mining para encon-trar patrones y presentar predictores de comportamiento, y permite una generaciónsencilla de informes mediante Reporting Services.

En cuanto a los nuevos sistemas visuales de análisis de datos (visual analytics, VA),su crecimiento ha sido exponencial, y esto ha provocado que las grandes compañíasde software (IBM o SAP, por ejemplo) hayan adquirido nuevas compañías de VA ylas hayan integrado en sus soluciones de inteligencia de negocio.

1.3.3. Ámbito de aplicación de las tecnologías de Inteligenciade Negocio

Es habitual hablar del uso o aplicación de las herramientas de inteligencia de ne-gocio en el ámbito empresarial, especialmente en el mundo financiero. Sin embargo,el ámbito de actuación es mucho mayor, extendiéndose a casi cualquier actividad.Desde la administración pública (gobiernos locales, regionales, estatales, pasandopor observatorios, consorcios, etc.) a las empresas (públicas o privadas), universida-des, etc. En todos estos sectores se considera esta tecnología de vital importancia[Williams y Williams, 2003, Watson y Wixsom, 2007, Lönnqvist y Pirttimäki, 2006].

El ámbito de aplicación de las tecnologías de inteligencia de negocio es tan ex-tenso que incluso engloba a las fuerzas armadas. Un ejemplo de aplicación es elpropuesto en [Oren et al., 2011]. Los datos generados por los C2IS (Command and

10

1.4. Tecnologías de Inteligencia de Negocio

Control Information System), y almacenados en bases de datos, se obtienen de losCOP (Common Operational Picture, conjunto de datos que describen situaciones demisiones militares, incluyendo estado y posiciones de unidades propias y enemigas,acciones y eventos [Ferris, 2013]). Esta información, normalmente obtenida median-te sensores, se procesan con herramientas de inteligencia de negocio (en el caso de[Oren et al., 2011] integrando AQL y GIS).

1.4. Tecnologías de Inteligencia de Negocio

Las herramientas utilizadas en inteligencia de negocio permiten recolectar, alma-cenar, analizar y presentar información útil al usuario en un entorno amigable.

Los sistemas BI deben cumplir una serie de requerimientos [Czernicki, 2010]:Seguridad: el acceso a los sistemas de inteligencia de negocio debe estar res-tringido a un conjunto de usuarios.Capacidad: los almacenes de datos han de proporcionar un volumen de datossuficiente para los propósitos para los que fueron diseñados.Retención de datos: los datos estarán almacenados de forma permanente hastauna actualización de los mismos.Desempeño: el análisis de los datos almacenados en los Data Warehouses debecumplir unos límites temporales y de espacio consumido.

Sin embargo las necesidades fundamentales de las tecnologías de inteligencia denegocio son dos. En primer lugar, la carga de datos ha de ser eficiente. Esto seresuelve habitualmente con cargas incrementales, a medida que se reciben nuevosdatos. Esta técnica permite realizar la carga de datos de forma escalable, y propor-ciona capacidades de refresco de datos. La segunda es que el análisis de los datosdebe ser rápido y veraz. La información mostrada ha de ser fidedigna, y los tiemposnecesarios para mostrar esta información han de ser relativamente cortos. Sin estosrequisitos temporales, la experiencia del usuario se ve gravemente mermada.

La mayor parte de las herramientas de inteligencia de negocio pueden incluirse enalguna de las siguientes categorías:

Análisis de tendencias.Associative Query Logic (AQL).Business Planning.Customer Relationship Management (CRM) y marketing.Data Mining (DM).

11

1. Introducción

Data Warehouse (DW).Decision Support System (DSS).Mapping, visualización de información y dashboarding.Geographical Information Systems (GIS).On-Line Analytical Processing (OLAP) y análisis multidimensional.Real time business intelligence.Reporting (generación de informes).

Los Decision Support Systems (DSSs) fueron las primeras herramientas que, dadoel imparable avance de la computación, nacen por la necesidad de tomar mejoresdecisiones. Este software debe ser interactivo y ayudar a la toma de decisiones me-diante la agregación de información útil a partir de datos en bruto. Los primerosDSSs se encontraron con:

Problemas de reutilización: los DSSs eran herramientas software ad-hoc, de-masiado personalizadas, e imposibles de utilizar de un modo diferente al quefueron diseñados.Largos desarrollos: cada proyecto para desplegar un DSS ad-hoc implicabalargos tiempos de desarrollo.Múltiples vendedores: el sistema DSS no podía ser desarrollado por una solacompañía, ya que no existía ninguna con la capacidad necesaria (implicabahardware, software, networking, servidores, servicios).Altos costes: los sistemas eran muy caros debido a los puntos anteriores.

A medida que estos DSSs tuvieron más éxito, las empresas los dotaron de nuevasextensiones y al mismo tiempo el software se homogeneizó. A finales del siglo XXya se utilizaba el término BI como una categoría de productos: ”data analysis,reporting, and query tools can help business users wade through a sea of data tosynthesize valuable information from it - today these tools collectively fall into acategory called Business Intelligence” (informe de la compañía Gartner Groupen Septiembre de 1996).

Más tarde aparecieron las tecnologías OLAP, que proporcionaban vistas multidi-mensionales y agregaciones de datos. Se utilizan fundamentalmente para el análisis,modelado, planificación y generación de informes. Permiten navegar a través dejerarquías y dimensiones para examinar y estudiar los datos, desagregándolos me-diante slice and dice. Las herramientas OLAP pueden trabajar con Data Marts oData Warehouses.

Actualmente las tecnologías de almacenamiento de datos en-memoria, y que uti-

12

1.5. Arquitectura de los sistemas de Inteligencia de Negocio

lizan AQL, están teniendo gran auge debido a su elevado rendimiento. Esto se debea que se benefician de la posibilidad de trabajar directamente en memoria princi-pal. Sin embargo se debe tener en cuenta que, aunque el tamaño de los datos quese puedan cargar en memoria es muy elevado, aún no se consigue trabajar con losvolúmenes de datos de los sistemas OLAP tradicionales. Al tener estos datos enmemoria principal, no obstante, el usuario experimenta la sensación de respuestasinstantáneas a cualquier tipo de análisis.

1.5. Arquitectura de los sistemas de Inteligencia deNegocio

Es importante entender e identificar cada una de las partes que componen los siste-mas de inteligencia de negocio, además de entender conceptualmente el BI. Podemosidentificar cinco niveles en la implementación típica de un sistema de inteligenciade negocio: las fuentes de datos, los procesos ETL, el almacén de datos (Data Wa-rehouse), la capa de servidores intermedios y la capa de presentación (Figura 1.2).

En los siguientes puntos se explican en cada una de estas capas.

1.5.1. Recolección de Datos

Cualquier sistema de inteligencia de negocio necesita definir de dónde obtienelos datos para el posterior análisis. Estas fuentes de datos (llamadas también datafeeds) pueden ser internas o externas, y de diferentes tipos y formatos (bases de datosrelacionales o operacionales, documentos XML o CSV, llamadas a APIs, etc.). Endefinitiva, estas fuentes de datos son heterogéneas. Además de ello también puedenestar distribuidas.

1.5.2. ETL (Extract, Transform and Load)

Los procesos encargados de convertir las fuentes de datos en algo utilizable por elsistema de inteligencia de negocio son llamados procesos ETL (Extract, Transformand Load). Conectan las fuentes de datos con los Data Warehouses. Como cabríaesperar, se pueden desglosar en tres procesos:

Extract. Proceso encargado de obtener los datos de la fuente correspondiente.Si hablamos de bases de datos relacionales, este proceso lanzaría órdenes selectcontra el motor de la base de datos para recuperar la información necesaria.Transform. Normalmente, la fuente de datos y el Data Warehouse no com-

13

1. Introducción

Figura 1.2.: Las cinco capas de una implementación de inteligencia de negociotradicional.

14


parten el mismo diseño. El proceso de transformación se encarga de adecuaruno a otro. Es la parte más costosa del proceso ETL, debido a que las trans-formaciones típicamente implican particiones verticales (aplicación de filtros),horizontales (selección de columnas) y agregaciones.Load. Corresponde al último paso, el de llevar la salida de la fase de trans-formación al Data Warehouse, que puede ser a su vez una base de datos, unaestructura de datos en-memoria, u otro sistema de almacenamiento de infor-mación.

Existen también otro tipo de procesos, llamados CEP (Complex Event Proces-sing), que soportan la toma de decisiones en base a datos operacionales, pero estosprocesos están íntimamente relacionados a otro tipo de soluciones: las soluciones OI(Operational Intelligence).

1.5.3. Data Warehouse

Las tecnologías de almacenes de datos (Data Warehouses) fueron desarrolladascomo repositorios utilizados por los sistemas de inteligencia de negocio. Su propósitofundamental es integrar las diferentes fuentes de datos de información, ya que estasfuentes son heterogéneas. Los datos se almacenan en los Data Warehouses de modooptimizado para el análisis posterior.

Tradicionalmente se han asociado los Data Warehouses a enormes almacenes dedatos con históricos de gran volumen. Es por ello que normalmente se suponenpotentes sistemas, como son los casos de Oracle Database, Microsoft SQL Server, uotros RDBMS (Relational DataBase Management System) del estilo. Sin embargo,esta visión no es única y es posible otro tipo de Data Warehouses: almacenes dedatos con arquitecturas de bajo coste pero que soportan un volumen de datos muyimportante. Es el caso de los sistemas que residen únicamente en memoria.

Además de descansar sobre fuentes de datos, como es el caso de las bases de datosoperacionales o relacionales, existen otras características importantes en los sistemasde Data Warehouse que se deben subrayar [Giorgini et al., 2007]:

Los requerimientos de usuario son costosos de identificar y normalmente cam-bian durante el proyecto. El ciclo de vida de un Data Warehouse se divideen:

• La planificación.• El diseño e implementación.• El mantenimiento y la evolución.

Es usualmente en el segundo paso cuando los requerimientos de usuario cam-

15

1. Introducción

bian.Los gestores demandan resultados confiables y compatibles con estrictos re-querimientos temporales. Ésta es una característica que se hereda de las nece-sidades de los servidores intermedios y de la capa de presentación.

Desde el punto de vista de requerimientos funcionales, se pueden identificar tresdiferentes principios de diseño en los Data Warehouse:

supply-driven [Golfarelli et al., 1998, Jensen et al., 2004]. También llamado data-driven, es una técnica de diseño bottom-up que se inicia con un análisis de lasdiferentes fuentes de datos para identificar toda la información posible.user-driven [Winter y Strauch, 2003]. Es otra técnica de diseño bottom-up, quese inicia determinando los requerimientos de información de diferentes usuariosde la organización. Estos diferentes puntos de vista se integran de maneraconsistente para obtener una única visión de la que pueda resultar un esquemamultidimensional.goal-driven [Boehnlein y Ulbrich vom Ende, 2000]. Se enfoca en la estrategiade la organización, que se extrapola de la información obtenida de los gestoresde alto nivel. Estrategia top-down.

Aunque los usuarios agradecen el enfoque user-driven, ya que se diseña teniendoen cuenta su visión, y al mismo tiempo los hace partícipes del diseño, normalmente esmuy lento, ya que en muy contadas ocasiones se tienen claros los objetivos, procesosy organización global.

Las fuentes de información de donde se extraen los datos son cada vez más au-tónomas, cambiando su contenido de forma continua. Estos cambios, además demodificar el contenido de los Data Warehouses, también pueden afectar a su esque-ma. Uno de los mayores retos es la evolución de los Data Warehouses a medida quelas fuentes de información modifican su contenido y diseño. Este problema se haabordado desde tres diferentes perspectivas [Oueslati y Akaichi, 2010]:

Schema evolution, o evolución del esquema. Se proporcionan operaciones parapoder modificar dimensiones, atributos, estructura, jerarquía, etc.Schema versioning, o versionado de esquema. Se transfieren los datos antiguosa un nuevo esquema, donde son renovados. Se mantiene un histórico de todaslas versiones mediante una extensión temporal, o mediante el almacenamientofísico de varias versiones.View maintenance, o mantenimiento de la vista materializada. Se centra enmantener las fuentes de datos y responder a sus cambios, adaptando las vistasmediante la agregación de metadatos, o reescribiendo las vistas.

16


1.5.3.1. Almacenamiento de los datos

Para soportar las peticiones de los servidores intermedios (operaciones típicamentede filtrado, agregación o unión), las estructuras de datos de los Data Warehousesnormalmente incluyen:

Estructuras índice, para permitir acceso asociativo utilizando los valores decolumna. Estas estructuras aceleran significativamente las operaciones de fil-trado, ya que se evita la necesidad de acceder a las tablas base.Vistas materializadas. Son tablas pregeneradas de agregación de datos de ta-blas base. Las peticiones a los Data Warehouse normalmente son de un tipoque hace necesaria alguna técnica de agregación de los datos. Si ya se dis-pone de estas tablas de agregación precomputadas, se reduce drásticamenteel tiempo de respuesta. La principal dificultad de este tipo de estructuras esidentificar las vistas materializadas que son necesarias, ya que la generaciónde demasiadas tablas precomputadas sería contraproducente. Además, la car-ga de nuevos datos en el Data Warehouse, en las tablas base, por ejemplo,implica precomputar de nuevo todas las vistas materializadas asociadas a esoscambios.Particionado. Se trata de otra de las técnicas para mejorar el rendimiento.La división de tablas permite que las operaciones de mantenimiento, comola recarga de datos o las copias de seguridad, se puedan realizar de formamás eficiente. Esto es debido a que a menudo no es necesario realizar estasoperaciones de mantenimiento sobre toda la estructura de datos, sino sólosobre una fracción de ella.

La compresión de datos en las Data Warehouses es otra característica que puedebeneficiar a los sistemas de inteligencia de negocio [Chaudhuri et al., 2011]:

La compresión reduce el tamaño de los datos que tienen que consultarse encada petición.El coste del almacenamiento y del backup para las copias de seguridad esmenor.Incrementa la disponibilidad de los datos que quedan almacenados en memoriacache tras peticiones de los servidores intermedios.Reduce el ancho de banda necesario cuando los datos han de viajar por la red.

Sin embargo, esta compresión no debe afectar significativamente a los tiempos derecuperación de datos. Al recuperar datos de un Data Warehouse será necesario unproceso de descompresión de los datos para suministrarlos al servidor intermedioque los esté solicitando. Los requisitos de tiempo de respuesta se deberán mantener

17

1. Introducción

con este nuevo proceso de descompresión.

1.5.4. Servidores intermedios

Los Data Warehouses se complementan con un conjunto de servidores interme-dios que actúan proporcionando funcionalidad específica de inteligencia de negocio.Algunos ejemplos de ellos son:

On-Line Analitycal Processing (OLAP). Proporcionan una visión multidimen-sional de los datos. Permiten operaciones de agregación, filtrado, drill-down ypivotado.Motores analíticos de datos en-memoria. Nuevo paradigma que explota lasmemorias RAM para proporcionar unos tiempos de respuesta ante peticionesdel usuario extremadamente rápidos.Servidores de generación de informes. Proporcionan herramientas para la de-finición, ejecución eficiente y consulta de informes.Motores de Data Mining. Proporcionan modelos predictivos con análisis enprofundidad de los datos.

1.5.5. Presentación

La capa superior del sistema de inteligencia de negocio es la capa de presentación(también llamada capa de presentación del conocimiento). Es la capa que propor-ciona la interfaz a los usuarios. Normalmente los sistemas de inteligencia de negocioposeen varios tipos de capas de presentación: para cuadro de mando (dashboard),para generación de informes, para visualización en formato de hoja de datos, etc., ya diferentes niveles de detalle. Además, estas capas de presentación están preparadaspara trabajar sobre diferentes plataformas, aplicaciones, entornos web, dispositivosmóviles, etc.

1.6. Retos de las tecnologías de Inteligencia deNegocio

El reto principal al que se enfrentan las arquitecturas de inteligencia de negocio escontribuir al impulso y crecimiento de las empresas u organismos, alineándose consus objetivos. Para ello deben mantener un entorno eficiente que permita realizartareas de análisis con tiempos de respuesta aceptables, y gestionar los cambios que se

18

1.6. Retos de las tecnologías de Inteligencia de Negocio

producen en las fuentes de datos, de tal manera que estos cambios se vean reflejadosen los Data Warehouses en unos intervalos de tiempo razonables.

Con respecto al primer punto, contar con un entorno de inteligencia de negocioeficiente, el reto consiste en trabajar con fuentes de datos de un tamaño muy elevado,dado que los procesos automatizados y el uso de sensores generan un volumen dedatos enorme. Aún con los avances tecnológicos actuales, en cuanto a tiempos deacceso a memoria y a velocidades de procesador, se presentan dos puntos críticospara los sistemas de inteligencia de negocio:

Tiempo de carga de fuentes de datos masivas en almacenes de datos, quecontendrán la información a la que accederán los sistemas de inteligencia denegocio.Tiempo de acceso de datos agregados en los almacenes de datos, cuando estasoperaciones involucren decenas y centenares de millones de registros.

El tiempo de acceso a los datos agregados puede ser excesivamente elevado. Estose produce cuando el motor analítico no es muy eficiente, cuando la información a laque se desea acceder está almacenada en memorias secundarias o cuando involucraa un número muy elevado de operaciones sobre registros. Los problemas se deri-van habitualmente de estas dos últimas razones. Los métodos de tablas agregadasprecomputadas intentan paliar este problema, pero se derivan otros. Otros métodosabogan por utilizar almacenes de datos más rápidos, pero normalmente son máscaros y de menor capacidad.

El problema de la carga de datos cuando se actualiza la información de las fuentesde datos cuenta con dos vertientes diferentes:

El tiempo de recarga de los nuevos datos en el Data Warehouse implica unasuspensión del servicio, problemas con la consistencia de los datos, o la posibleadopción de arquitecturas más complejas.La actualización puede ser bien mediante recargas de datos periódicas, o bienante detección de cambios en los orígenes de datos. Las recargas de datosperiódicas presentan los siguientes problemas:

• Si la información en la fuente de datos no ha cambiado, supone unaoperación que sobrecarga el sistema sin aportar ningún beneficio.

• Si la fuente de datos ha cambiado, el usuario no es consciente de elloshasta que la tarea periódica de recarga se ejecuta. Hasta ese momento,el usuario trabaja con información desactualizada.

Actualmente los problemas más habituales con los que se encuentran los consu-midores de soluciones de inteligencia de negocio son:

19

1. Introducción

Proliferación de soluciones de inteligencia de negocio, pero ninguna cumple losestándares deseados.Costos elevados, sumando el costo de la implementación al costo de manteni-miento (en ocasiones, es necesario un perfil muy específico).Redundancia en las soluciones implementadas en la misma organización o com-pañía.Creación de verdaderos “silos” de información, y problemas derivados de re-dundancia y compartición.

1.7. Contenido

Este trabajo doctoral se centra en dos tecnologías de inteligencia de negocio:tecnología OLAP basada en cubos y tecnología de DataWarehouse en memoria.Estas dos vertientes tienen ventajas e inconvenientes.

La tecnología tradicional OLAP basada en cubos multidimensionales está amplia-mente extendida, tiene una gran implantación, y es muy adecuada para aplicacionesque generan informes predefinidos. Su potencia frente a otras soluciones es muchomayor. Y, sin embargo, presenta problemas para cumplir con requisitos habitualesde velocidad en la generación de información. Este trabajo doctoral presentará laimplementación de una herramienta OLAP de código abierto que soluciona algunosde los problemas de las herramientas de análisis clásicas [Sendin-Raña et al., 2009].

Por otro lado, las tecnologías en-memoria de Data Warehouse permiten ejecutaranálisis adhoc complejos sobre estructuras de datos de gran tamaño, en tiemposincreíblemente cortos. El tiempo de respuesta es mucho menor que los sistemastradicionales debido a que los datos están cargados en memoria RAM, no en disco.La carga de datos en memoria RAM es posible en la actualidad gracias a dos razones:precios mucho menores y espacios mucho mayores.

En particular, nos centramos en AQL (Associative Query Logic), una tecnologíaen-memoria de Data Warehouse patentada por QlikView [QlikView, WWW]. Exis-ten otras tecnologías con ventajas similares. Sin embargo AQL se ha posicionadocomo una tecnología con un rápido desarrollo y una amplia base de herramientas yproductos comerciales que la emplean.

Nuestra propuesta [Sendin-Raña et al., 2010] aplica una versión del algoritmoAQL a una solución web que soluciona problemas presentes en las publicaciones rela-cionadas con los algoritmos utilizados por QlikView [QlikTech:1, 2000, QlikTech:2, 2001,QlikTech:3, 2006]. Además, esta propuesta se complementa con una mejora en elproceso de recarga de datos, que permite solucionar el problema de actualización de

20

1.7. Contenido

datos sin afectar a su disponibilidad en soluciones web AQL.El resto de este trabajo doctoral está organizado como sigue. El capítulo 2 pro-

porciona el estado del arte de los campos de trabajo: la sección 2.1 se centra en lossistemas OLAP, y más concretamente en el motor ROLAP Mondrian, y la sección2.2 aborda los sistemas de inteligencia de negocio en-memoria, y AQL y los DataClouds. Se explican las diferencias de estos sistemas frente a los tradicionales, y lasventajas y desventajas que presentan. El capítulo 3 presenta las contribuciones deeste trabajo doctoral: en el apartado 3.1 se explica la mejora de rendimiento de sis-temas OLAP, en el apartado 3.2 la implementación de una aplicación web basada enAQL, y el apartado 3.3 la mejora del proceso de recarga de datos para la aplicaciónweb AQL. Se cierra este trabajo doctoral con el capítulo 4, que extrae conclusionesy presenta líneas futuras.

21

Capítulo 2

Estado del arte

Índice2.1. Sistemas OLAP . . . . . . . . . . . . . . . . . . . . . . . . 24

2.1.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . 242.1.2. Tecnologías OLAP . . . . . . . . . . . . . . . . . . . . . . 262.1.3. Soluciones OLAP . . . . . . . . . . . . . . . . . . . . . . . 292.1.4. Solución basada en Mondrian . . . . . . . . . . . . . . . . 31

2.2. Sistemas de Inteligencia de Negocio en-memoria . . . . 392.2.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . 392.2.2. AQL y Data Clouds . . . . . . . . . . . . . . . . . . . . . 39

2.3. Plataformas para aplicaciones distribuidas . . . . . . . . 462.3.1. Apache Hadoop en sistemas de Inteligencia de Negocio . . 482.3.2. Apache Spark en sistemas de Inteligencia de Negocio . . . 50

En este capítulo presentaremos el estado del arte de los campos de estudio de estetrabajo doctoral. En primer lugar, el estado del arte de los sistemas OLAP (On-LineAnalytical Systems), centrándose en los sistemas de código abierto. El apartado 2.1.2presenta los diferentes tipos de tecnologías OLAP, sus ventajas y sus inconvenientes.El apartado 2.1.3 aborda diferentes soluciones OLAP, tanto comerciales como opensource. Se concluye el capítulo con el apartado 2.1.4, con una justificación de laelección de Mondrian como motor OLAP más adecuado para nuestros propósitos.En segundo lugar, presentaremos el estado del arte de los sistemas de inteligenciade negocio que utilizan la memoria principal como almacén de datos. Se explica-rá en detalle AQL y el Data Cloud1. El apartado 2.2.1 explica las diferencias de

1Nube de datos, colección de datos almacenados en memoria principal enlazados entre sí a tra-vés de asociaciones lógicas. No confundir este término con la computación en la nube (CloudComputing), tratada en el subapartado 2.3.

23

2. Estado del arte

estos sistemas frente a los tradicionales. El apartado 2.2.2 presenta las ventajas ydesventajas, y su funcionamiento.

2.1. Sistemas OLAP

2.1.1. Introducción

Tradicionalmente el diseño de las bases de datos relacionales se ha enfocado haciala optimización de las transacciones para obtener datos y para insertar, modificar oeliminar registros. Actualmente, las bases de datos relacionales tienen gran impor-tancia, ya que almacenan información táctica de los Data Warehouses de los sistemasde inteligencia de negocio. Estas bases de datos relacionales soportan principalmenteoperaciones de obtención de datos (select-like).

Los sistemas OLAP [OLAP Council, WWW, OLAP Report, WWW], ampliamen-te utilizados como herramientas de análisis en sistemas de inteligencia de negocio,emplean dichos almacenes de datos para disponer de información de forma rápida,interactiva y consistente. A diferencia de los sistemas OLTP (On-Line TransactionSystems), los sistemas OLAP proporcionan respuestas rápidas a preguntas de tipoanalítico. Para ello se realizan operaciones de lectura sobre almacenes de datos quealbergan normalmente grandes cantidades de datos. Si comparamos los tiempos derespuesta de los motores analíticos frente a los transaccionales ante complejas que-ries (peticiones), los sistemas OLAP tardan un 0.1 % del tiempo que necesitaríanlos sistemas OLTP.

El libro blanco de los sistemas OLAP [Codd et al., 1993] describía las famosasdoce reglas de un sistema OLAP deseable. Pendse [Pendse, 2003] resumió estas docereglas en cinco, y acuño el término FASMI (Fast Analysis of Shared MultidimensionalInformation) como definición alternativa. Esta definición está ampliamente aceptadapor toda la comunidad y es la que seguimos en este trabajo. Afirma que un sistemaOLAP debe satisfacer cinco características:

Rapidez (Fastness). El sistema OLAP debe proporcionar la mayoría de lasrespuestas a los usuarios finales en menos de 5 segundos (los análisis mássimples en 1 segundo o menos, y sólo algunos de los análisis más complejosunos 20 segundos).Capacidad de análisis (Analysis capability). El sistema debe adaptarse a cual-quier lógica de negocio y a cualquier análisis estadístico por sí mismo, sin queel usuario final perciba cualquier cambio.Compartición de recursos (Resource Sharing). Se deben proporcionar en lamedida adecuada seguridad y bloqueo de los registros que se estén modificando

24

2.1. Sistemas OLAP

de forma concurrente.Multidimensionalidad (Multidimensionality). Es quizá la característica clavey fundamental de un sistema OLAP. El sistema debe proporcionar una vistamultidimensional de los datos almacenados en el Data Warehouse. La multidi-mensionalidad viene definida por la posibilidad de acceder a los datos medianteel uso de dimensiones, jerarquías y niveles.Generación de información (Information generation). Esta característica afir-ma que tanto los propios datos como la información relacionada en ellos (ejes,niveles, miembros, etc.) deben proporcionarse a la capa de presentación.

El usuario final de los sistemas OLAP debe poseer la capacidad de obtener unpanel de control (o cuadro de mandos) que le proporcione una vista intuitiva delenorme conjunto de datos subyacente, usualmente almacenados en un Data Wa-rehouse [Chaudhuri y Dayal, 1997]. El mantenimiento de esa información tambiénes responsabilidad del Data Warehouse. Hay dos aspectos clave para mejorar la ex-periencia del usuario: la capacidad de soportar peticiones complejas y el tiempo derespuesta [Oliveira y Bernardino, 2006, da Silva et al., 2006].

Las soluciones OLAP proporcionan al usuario herramientas interesantes de nave-gación sobre datos:

slice and dice: selección y proyección.rollup: decremento progresivo del nivel de detalle.drill-down: incremento del nivel de detalle.pivotado: redefinición de los ejes multidimensionales, modificando la vista delos datos.

Los sistemas OLAP, como otros DSSs, soportan complejas peticiones de agrega-ción de datos sobre Data Warehouses que alojan enormes cantidades de registros.Como ya se explicó en la sección 1.5.3, las capas inferiores encargadas de la gestiónde esta información (los Data Warehouses) típicamente construyen un conjunto detablas con vistas materializadas (tablas con la información agregada, o resumida),para acelerar la ejecución de las peticiones y, por tanto, acelerar el tiempo de res-puesta [Gupta et al., 1995, Agarwal et al., 1996]. Sin embargo, el diseño de estastablas es complejo (es necesario un análisis estadístico de las peticiones más utiliza-das, y este comportamiento va variando en el tiempo). Además, el mantenimientode estas tablas es complicado, ya que se debe garantizar la consistencia cuando seguarda o se modifica información en el almacén de datos. Si se modifica un sóloregistro particular del Data Warehouse que esté relacionado con una o más tablasde vistas materializadas, será necesario recomputar estas tablas y, al mismo tiempo,no permitir consultas hasta que esta actualización esté finalizada para impedir re-

25

2. Estado del arte

sultados incongruentes. Esta técnica también implica un mayor consumo de espacioen memoria.

Existe una solución más limitada, que es el uso de una cache de vistas agrega-das: puede contener menor información, y no permite un diseño tan eficiente, peroresuelve los problemas de mantenimiento. El mecanismo permite almacenar en unamemoria cache los resultados de las últimas peticiones, de tal modo que si una peti-ción se utiliza con frecuencia, se mantendrá en la memoria cache, y si una peticiónno vuelve a utilizarse, se eliminará de la memoria cache siendo sustituida por unarespuesta a una petición más actual. Los problemas de mantenimiento se resuelven,ya que el almacén de datos proporcionará una nueva respuesta (que sustituirá a laanterior en la memoria cache) si se detecta un cambio en algún registro relacionado.

Nuestra solución prescinde de la generación de tablas de vistas materializadas enel almacén de datos y utiliza la solución de cache de vistas agregadas por ser másadecuada, como se explica en el apartado 3.1.2.

Sin embargo, la cache de vistas agregadas también tiene desventajas. Cuando elsistema se reinicia debido a caídas inesperadas o apagados programados, la memoriacache desaparece y es necesario reconstruirla a medida que se van produciendo laspeticiones de los usuarios finales. Esto provoca una fase de peticiones iniciales contiempos de respuesta inusualmente altos y completamente inaceptables. La soluciónpropuesta explicada en el apartado 3.1 permite, mediante un mecanismo de coldstart propio, una rápida recuperación del sistema OLAP tras reinicios accidentaleso programados. Esta solución permite respuestas rápidas, que satisfacen las reglasFASMI, después de un reinicio del sistema. El tiempo de respuesta es un 10 % deltiempo que tardaría el sistema original en generar una respuesta al usuario final.Nótese que no estamos utilizando ninguna técnica de vista sumarizada en el almacénde datos subyacente. Este mecanismo de cold start propio no existía en ningúnsistema OLAP de código abierto durante nuestras investigaciones.

Además, debido a la necesidad del proyecto Pesca Fresca de crear miembros cal-culados en el cubo multidimensional, se introdujo una nueva funcionalidad en el sis-tema OLAP. Consistió en la definición de un tipo especial de dimensiones virtuales,que denominamos “dimensiones calculadas”. Con ellas ha sido posible crear dinámi-camente miembros calculados sin definir información redundante en cada peticiónmultidimensional, y sin definir un nuevo miembro calculado cuando la estructuradel cubo multidimensional cambia.

2.1.2. Tecnologías OLAP

Los sistemas OLAP permiten operaciones sobre cubos multidimensionales, talescomo filtrado, agregación, pivotado o drill-down. Existen tres tipos de de motores

26

2.1. Sistemas OLAP

OLAP que permiten un procesado analítico de los datos:MOLAP (OLAP multidimensional). Utilizan vistas multidimensionales sobreun motor que utiliza arrays (matrices) multidimensionales en memoria. Estemodelo es excelente en cuanto a indexado y velocidad de resolución de consul-tas, pero su gran problema es la falta de eficiencia en el almacenamiento.ROLAP (OLAP relacional). Estos motores utilizan una base de datos relacio-nal que se asocia con el cubo multidimensional, de tal forma que para realizarpeticiones, se lanzan queries SQL contra la base de datos relacional. La mayo-ría de los motores ROLAP utilizan el star schema para representar el modelode datos multidimensional. Este modelo es más eficiente que MOLAP en cuan-to a almacenamiento, pero sin embargo es más lento en cuanto a tiempo derespuesta, ya que las peticiones las tiene que resolver un RDBMS.HOLAP (OLAP híbrido). Combinación de los dos motores anteriormente pre-sentados, para mejorar el rendimiento global. Existen dos aproximaciones ma-yoritarias:

• Almacenar la información agregada (vistas materializadas) en un motorMOLAP, y dejar la información detallada en el motor ROLAP.

• Almacenar sólo la información más reciente en el motor MOLAP, y lamás antigua en ROLAP.

Los motores MOLAP escalan peor que los motores ROLAP, ya que tradicional-mente las bases de datos relacionales trabajan mejor sobre mayores volúmenes dedatos [Moorman, 1999]. Esta es la razón principal del mayor éxito de los motoresROLAP en el desarrollo de soluciones de BI.

La característica más común de las órdenes lanzadas sobre los almacenes de datoses la petición de la agregación de un conjunto de datos. Esto quiere decir que setratan operaciones que implican cálculos sobre un gran volumen de datos para ob-tener una serie de resultados más resumidos. Las vistas agregadas en el almacén dedatos son necesarias para satisfacer unos requisitos temporales que hagan al sistemapráctico desde el punto de vista del usuario [Chaudhuri et al., 2001]. Sin embargo,esta técnica supone:

La necesidad de identificar correctamente las vistas agregadas.Un mecanismo que permita asociar las peticiones a esas vistas agregadas.Problemas a la hora de mantener la consistencia de los datos en la cargade nuevos datos o modificación de datos existentes que afecten a las vistasmaterializadas.

27

2. Estado del arte

El esquema tradicional se basa en una herramienta OLAP que utiliza un almacénde datos pasivo para obtener la información que conformará el cubo multidimen-sional [Madeira et al., 2003]. Aun así existen alguna propuestas relacionadas en laliteratura que no siguen este modelo. Es el caso de Grid MOLAP [Fiser et al., 2004],o del DSS propuesto por [Thalhammer y Schrefl, 2002], que permite automatizar latoma de decisiones y extender los almacenes de datos convencionales con reglas deanálisis.

En los servidores ROLAP, cada petición multidimensional es analizada y traduci-da en varias peticiones que soporta la capa relacional subyacente. Es el mecanismonatural de comunicación con el almacén de datos. Una petición MDX normalmentese traduce en varias peticiones SQL de tipo select, si el almacén de datos al que vandirigidas es una base de datos relacional, como se ilustra en la figura 2.1. Tambiénse da el procedimiento inverso: existen propuestas que analizan peticiones relacio-nales y las traducen en sentencias multidimensionales para obtener información decubos multidimensionales [Zaman y Schneider, 2005], aunque este procedimiento noes común.

Figura 2.1.: Descomposición de una sentencia MDX en varias sentencias SQL.

Por último, otro punto importante en los sistemas OLAP es la interoperabilidadcon otros sistemas. Existen numerosas propuestas: MDAPI [MDAPI, WWW], OLEDB para sistemas OLAP [OLE DB, WWW], JOLAP [JOLAP, WWW] y otras me-nos extendidas [Fildalgo et al., 2002]. Aún cuando algunas son bastante populares,ninguna de ellas se ha convertido en un estándar comúnmente aceptado para la co-municación con otros sistemas. Por lo tanto, tan sólo XML for Analysis (XML/A)[XML/A:1, WWW, XML/A:2, WWW, Chu, 2004] puede considerarse un estándarde facto para sistemas OLAP.

28

2.1. Sistemas OLAP

2.1.3. Soluciones OLAP

Existen numerosas suites de BI que emplean herramientas OLAP para el análisisde grandes conjuntos de datos. Las más relevantes dentro del ámbito comercial sonSAP Business Information Warehouse (SAP/BW), Hyperion Essbase y MicrosoftSQL Server Analysis Services (SSAS).

SAP/BW [SAP/BW, WWW] cuenta con un motor OLAP que proporcionaacceso directo a las bases de datos relacionales que utiliza como almacenes dedatos. Esto lo realiza mediante una tecnología DB Connect. Efectivamente,SAP/BW utiliza como capa subyacente un RDBMS, pero cuenta con un dise-ño propietario para el análisis multidimensional. El esquema de estrella (starschema) permite conectar el InfoCube con las Master Data Tables, para crearun enlace entre el mundo multidimensional y el relacional.La familia de productos Hyperion Essbase [Essbase, WWW], integrada en Ora-cle Business Intelligence, incluye Hyperion Essbase OLAP Server. Este motoranalítico se beneficia de una característica especial del espacio multidimen-sional, denominada sparsity, para minimizar el tamaño de la memoria físicay el espacio en disco necesario para representar grandes cantidades de datosmultidimensionales. Essbase cuenta con un método propietario para reducirel tamaño de la memoria física necesaria para almacenar estos datos multidi-mensionales sin incrementar el tiempo de procesado.SSAS [SSAS, WWW] cuenta con la posibilidad de utilizar varios modos dealmacenamiento, dependiendo del modelo utilizado. Permite así motores MO-LAP, ROLAP y HOLAP. La arquitectura de servicios de análisis sigue la filoso-fía del modelo dimensional unificado (Unified Dimensional Model, UDM). Estoproporciona un método para encapsular el acceso a múltiples fuentes de datosheterogéneas en un único modelo. Para conseguir altos niveles de rendimiento,UDM utiliza una cache MOLAP.

Estas tres soluciones presentadas utilizan motores OLAP que, aún optimizadospara aportar un alto rendimiento, están basados en tecnologías cerradas, patentadasy propietarias. Por otro lado, las tecnologías OLAP de código abierto consiguen unosrendimientos más que aceptables, incluso para almacenes de datos de gran tamaño,y aportan soluciones flexibles. Por ejemplo, Mondrian [Mondrian, WWW] admitenumerosos add-ins (como es el caso de JPivot [JPivot, WWW] para la integracióncon web) que le aportan valor añadido. Por estas razones, y por la decidida apuestade las administraciones públicas europeas por el uso y potenciación de las herra-mientas de código abierto, nuestra búsqueda de soluciones se centró en los sistemasOLAP de código abierto. Se pueden identificar las siguientes herramientas OLAPde código abierto como las más relevantes:

29

2. Estado del arte

Característica Mondrian PALO OpenOLAPIndependencia de RDBMS SI NO NOSoporte para bases de datos de gran tamaño SI NO SIBuena documentación SI SI NOROLAP SI SI SIMOLAP NO SI SI

Cuadro 2.1.: Comparativa de las soluciones OLAP de código abierto más relevantes.

Mondrian [Mondrian, WWW] es un servidor ROLAP desarrollado en Java,integrado dentro de la suite Pentaho [Pentaho, WWW]. Incluye algunas he-rramientas de desarrollo, como Cube Designer y un workbench. Aunque Penta-ho proporciona un completo dashboard donde consultar informes, ver gráficosinteractivos y actuar sobre los cubos multidimensionales, Mondrian tambiénpuede emplear JPivot [JPivot, WWW]. JPivot es una biblioteca escrita en JSPpara representar cubos OLAP y efectuar las típicas operaciones de navegaciónsobre cubos multidimensionales.PALO [Palo, WWW] es un servidor MOLAP de 64 bits de Jedox, un softwarecliente-servidor para BI. Es un sistema en tiempo real, basado en el uso dela memoria para el almacenamiento de los datos en celdas. Está diseñadoespecíficamente para el almacenamiento y análisis de datos de hojas de cálculo.Esta característica lo limita, ya que no trabaja bien con bases de datos grandes.Otra limitación es su dependencia tecnológica (de Microsoft). Proporciona unaAPI para varios lenguajes de programación (C, PHP, .NET, Java) y posee unplug-in para EXCEL, para acceso a los datos. PALO además cuenta con unacaracterística no habitual en los sistemas OLAP: permite el acceso en modoescritura al almacén de datos.OpenOLAP [Open OLAP, WWW] es un servidor ROLAP y MOLAP escritoen Java. No soporta algunas de las bases de datos relacionales más relevantescomo almacenes de datos (como es el caso de SQL Server), y es un proyectoque no cuenta con una buena documentación.

El cuadro 2.1 muestra un resumen de las ventajas y desventajas de estas tres he-rramientas OLAP de código abierto. Además de las justificaciones de las ventajas delos motores ROLAP sobre los MOLAP presentadas en el apartado 2.1.2, la elecciónde un sistema ROLAP también deriva de las características de la plataforma PescaFresca (ver apartado 1.2).

30

2.1. Sistemas OLAP

2.1.4. Solución basada en Mondrian

Mondrian, una herramienta ROLAP que forma parte del Pentaho Project (suiteBI de código abierto) desde el año 2005, fue seleccionada para el proyecto PescaFresca. Mondrian es libre, portable, fácil de integrar, proporciona un refresco de ca-che eficiente y soporta numerosos RDBMS, entre los que podemos encontrar Oracle,SQL Server o mySQL.

Como se ha dicho, aunque las herramientas comerciales son mucho más poten-tes que las de código abierto, éstas últimas pueden ofrecer rendimientos más queaceptables. Teniendo en cuenta esta diferencia, hemos podido comparar, mediantepruebas relacionadas directamente con la naturaleza de la plataforma Pesca Fresca,la solución comercial de Microsoft Analysis Services con Mondrian. Más específica-mente, hemos realizado pruebas con el mismo cubo multidimensional y con el mismovolumen de datos en los dos sistemas OLAP. Sin embargo, se ha de resaltar que:

Mondrian y Analysis Services no utilizaron el mismo motor de almacén dedatos: Mondrian utilizó mySQL Server y Analysis Services a SQL Server.Las soluciones con Analysis Services normalmente utilizan algún tipo de téc-nica MOLAP o HOLAP, más que un ROLAP puro.Analysis Services interactúa con el almacén de datos directamente (el motorOLAP y el motor del almacén de datos están ubicados en el mismo equipo).Sin embargo la implementación de la solución con el motor Mondrian envíapeticiones vía XML/A a un almacén de datos situado en una ubicación dife-rente.

Teniendo estas diferencias en mente, las pruebas demostraron que Microsoft Analy-sis Services era cuatro veces más rápido que la solución basada en Mondrian. Unalmacén de datos menos potente y los retardos derivados del uso de XML/A penali-zan a la solución basada en Mondrian. Pero la diferencia es tolerable si se consideranlas ventajas de utilizar el modelo de código abierto.

La solución propuesta, basada en Mondrian, es además compatible con futurasversiones que Pentaho libere en el futuro. Es posible que, como ha sucedido conalternativas de código abierto a productos comerciales consolidados, el desarrollode Mondrian consiga reducir la diferencia de rendimiento e incluso quizá superar aotros sistemas comerciales.

Volviendo a la descripción del motor ROLAP que proporciona Mondrian, éstecuenta con otras ventajas sobre los motores MOLAP, además de la mayor escalabi-lidad. Mondrian accede directamente a los datos almacenados en las bases de datosrelacionales (como es el caso de las utilizadas en la plataforma Pesca Fresca), ge-nerando peticiones SQL para obtener la información necesaria. Además no requiere

31

2. Estado del arte

ningún tipo de preprocesado de información ni de almacenamiento de informaciónpreprocesada.

Los esquemas declarados en Mondrian definen una base de datos multidimen-sional que se apoya en una capa subyacente constituida por una base de datosrelacional. El esquema se compone de un modelo lógico y una asignación sobreun modelo físico. El modelo lógico consiste en cubos multidimensionales, jerar-quías, dimensiones, niveles y miembros. Este modelo lógico acepta peticiones MDX[MDX, WWW, Thomsen et al., 1999, Spofford et al., 2006]. MDX es un lenguajeque permite a los sistemas OLAP obtener información multidimensional. Es el equi-valente al lenguaje SQL utilizado en los RDBMS. Una petición MDX generada porMondrian se traduce en varias peticiones SQL, que imponen fuertes cargas de tra-bajo a las bases de datos relacionales de las que el sistema OLAP depende, yaque típicamente implican acceso a millones de registros, operaciones de tipo join yagregaciones.

Figura 2.2.: Ejemplo de cubo multidimensional.

Los esquemas utilizados en Mondrian se definen en un fichero XML [XML, WWW](eXtensible Markup Language). En estos ficheros XML se definen los cubos OLAPdel modelo lógico (llamados también cubos multidimensionales o hipercubos). Los

32

2.1. Sistemas OLAP

metadatos asociados pueden seguir el esquema en estrella (star schema) o en copo denieve (snowflake schema). Los cubos definen medidas, conjuntos de datos numéricos,categorizadas por dimensiones. Estas dimensiones cuentan con jerarquías, niveles ymiembros.

La figura 2.2 muestra un ejemplo de un cubo con tres dimensiones (Lonjas, Es-pecies y Temporal) y dos medidas (Ventas, en miles de euros, y Capturas, en to-neladas). La dimensión Lonjas cuenta con una jerarquía de un nivel que clasificalas lonjas por provincia. La dimensión Temporal cuenta con otra jerarquía de dosniveles, que permite acceder a los resultados por semestres o por trimestres. En unamisma dimensión pueden coexistir varias jerarquías.

Existen tres métodos para construir dimensiones:

A partir de tablas especiales de la base de datos relacional subyacente, llamadastablas de dimensión.A partir de la tabla de hechos.Directamente definiendo los miembros en la propia definición que se hace enel fichero XML del esquema.

Las medidas se definen siempre a partir de la tabla de hechos, que es la tablaprincipal de la base de datos relacional subyacente.

El rendimiento de los sistemas OLAP viene determinado típicamente por el meca-nismo de agregación de información. Este mecanismo consiste en construir diferentesmedidas a partir de una misma tabla de hechos con diferentes granularidades, porejemplo con diferentes niveles de jerarquía en una misma dimensión. Cualquier pe-tición MDX podría ser contestada directamente a partir de los datos almacenadosen la base de datos relacional o de la combinación de todas las posibles agregacionesasociadas.

Como se ha afirmado anteriormente, Mondrian cuenta con un modelo lógico yuna correspondencia con un modelo físico. Mondrian no almacena datos: lo delegaen los RDBMS con los que trabaja. Únicamente cuenta con una pequeña cache quese va construyendo a partir de los resultados que arrojan las sentencias MDX, apartir de los datos de la tabla de hechos. Obviamente, acceder a la base de datosrelacional para obtener información afecta al rendimiento, sobre todo en los casosde peticiones que necesitan agregar muchos datos. Los sistemas OLAP que tienenestos problemas normalmente utilizan técnicas que se aplican en las capas subya-centes: para agilizar las consultas, se generan tablas de vistas materializadas (vistasagregadas de partes de la base de datos) para diferentes dimensiones (Mondrian,por ejemplo, puede definir que se utilizarán vistas materializadas con dimensionesde tipo lost y collapsed).

33

2. Estado del arte

Esta técnica permite mejorar el rendimiento, pero a costa de agravar la com-plejidad del mantenimiento del RDBMS para garantizar consistencia de datos. Lastablas de vistas agregadas son difíciles de diseñar y mantener, además de albergarinformación redundante que consume espacio de forma permanente. Para asegurarla consistencia de los datos, el administrador de la base de datos relacional debeactualizar estas tablas en cuanto la información se modifique o se añada. Las ta-blas agregadas y los procedimientos almacenados pueden derivar en problemas deintegridad de datos.

Los datos agregados también se almacenan en la cache de Mondrian, que no esmás que un espacio especial de memoria principal donde el sistema almacena lasúltimas respuestas generadas. Cuando se genera una respuesta ante una peticiónMDX, ésta también se almacena en la cache de Mondrian, liberando espacio derespuestas anteriores. Si el resultado de una petición está relacionado con datos quese han modificado o añadido en el almacén de datos, automáticamente se vuelve aenviar la petición al RDBMS para que se vuelva a recalcular. Este método asegurala integridad, previniendo resultados inconsistentes.

2.1.4.1. Arquitectura de Mondrian

La arquitectura de Mondrian define cuatro capas, como se representa en la figura2.3:

La capa de presentación: Encargada de presentar la información multidimen-sional (tablas, gráficas, herramientas avanzadas de visualización, etc.). Com-parte con el resto de las capas las referencias de dimensiones, medidas y celdas.La capa dimensional: Interpreta, evalúa y ejecuta las peticiones MDX. Para elproceso de ejecución, se envían peticiones al gestor de agregaciones. El esquemamultidimensional contiene los metadatos que describen el modelo dimensional,y cómo se traduce en el esquema relacional subyacente.La capa de star schema: Responsable de mantener la cache de Mondrian,donde se almacenan los datos agregados. La capa dimensional envía peticionesde conjuntos de celdas: si no se encuentran en la cache, el gestor de agregacionesenvía la petición a la capa de almacenamiento.La capa de almacenamiento: RDBMS responsable de proporcionar informaciónpara las medidas y para los miembros de las dimensiones.

Únicamente la capa dimensional y la capa de star schema han de ubicarse físi-camente en la misma máquina, ya que se trata de las capas propias del servidorMondrian. La comunicación con la capa de almacenamiento puede efectuarse me-diante una conexión JDBC remota. Si el sistema cuenta con una interfaz gráfica web

34

2.1. Sistemas OLAP

Figura 2.3.: Capas en la arquitectura de Mondrian (tomado de [Mondrian, WWW]).

35

2. Estado del arte

multiusuario, la capa de presentación consistirá en el resultado de la generación delas páginas JSP del servidor.

Mondrian proporciona una API con un conjunto de clases que permiten caracte-rizar los elementos más comunes de un esquema multidimensional: Schema, Cube,Dimension, Hierarchy, Level y Member.

2.1.4.2. Extensibilidad de Mondrian

Mondrian es muy flexible: permite añadir nuevos módulos e integrar otras herra-mientas con gran facilidad. Además su diseño admite que el usuario pueda incorporarfunciones propias, como plug-ins, que se añaden a la aplicación original.

Mondrian puede configurarse como un proveedor de XML/A, dotándose de unagran interoperabilidad. Microsoft y Hyperion anunciaron en 2011 la especificaciónXML/A [XML/A:1, WWW, XML/A:2, WWW, Chu, 2004], proporcionando unaAPI OLAP estandarizada. La mayor parte de los sistemas OLAP la respaldaron,convirtiéndose en un estándar de facto.

XML/A emplea MDX como lenguaje para lanzar peticiones y obtener datosde un cubo multidimensional. La comunicación en XML/A utiliza lenguajes am-pliamente conocidos: HTTP [HTTP, WWW] (Hypertext Transfer Protocol), SOAP[SOAP, WWW] (Simple Object Access Protocol) y XML [XML, WWW]. La especi-ficación XML/A define dos métodos:

Discover : Método necesario para encontrar los datos y metadatos indispensa-bles para las peticiones MDX.Execute: Método para lanzar las peticiones MDX.

Una implantación típica de un sistema Mondrian implica la instalación de unservlet engine para proporcionar un proveedor de servicios XML/A.

La figura 2.4 ilustra el modo de operación de Mondrian como proveedor de servicioXML/A. El usuario, desde un terminal remoto, envía peticiones MDX al servidorMondrian por medio de mensajes SOAP (utilizando el protocolo XML/A). El servi-dor Mondrian recibe la petición, y si es necesario, traduce la petición MDX a variaspeticiones SQL para lanzarlas contra la base de datos relacional subyacente. En otrocaso, obtiene los datos de la cache donde están almacenados. El resultado se envía alusuario también en un mensaje SOAP. Los ficheros de configuración de Mondrian (esdecir, los esquemas que definen los cubos multidimensionales, las fuentes de datos,la configuración XML/A y otros) se declaran en formato XML.

Por ejemplo, si un usuario quisiese los valores agregados de todas las medidasdefinidas para el año 2014, el formato del mensaje sería el que muestra la figura 3.13

36

2.1. Sistemas OLAP

Figura 2.4.: Modo de operación de Mondrian como proveedor XML/A (tomado de[Sendin-Raña et al., 2009]).

37

2. Estado del arte

<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"><SOAP-ENV:Header/><SOAP-ENV:Body>

<Execute><Command>

<Statement>SELECT [Measures].Members ON COLUMNS FROM PescaFresca WHERE [Time].[2007]

</Statement></Command><Properties>

<PropertyList><DataSourceInfo>

Provider=ExampleProvider;Data Source=local;</DataSourceInfo><Catalog>PescaFresca</Catalog><Format>Multidimensional</Format><AxisFormat>ClusterFormat</AxisFormat>

</PropertyList></Properties>

</Execute></SOAP-ENV:Body></SOAP-ENV:Envelope>

Figura 2.5.: Ejemplo de petición SOAP.

38

2.2. Sistemas de Inteligencia de Negocio en-memoria

2.2. Sistemas de Inteligencia de Negocioen-memoria


Aunque es innegable el hecho de que las aplicaciones de BI han experimentado unavance y una evolución espectacular en las últimas décadas [Negash y Gray, 2003],también es cierto que los usuarios expertos de estos sistemas experimentan diversosinconvenientes con los sistemas actuales. Algunos de ellos son los siguientes:

Son sistemas difíciles de desplegar y de mantener.Son sistemas que tardan un tiempo excesivo en iniciarse y situarse en un estadoque les permita aceptar peticiones de usuarios.Normalmente requieren de unas interfaces demasiado complejas para mostrarlos resultados de los análisis que ejecutan.

Las limitaciones de los sistemas OLAP, debido a su inherente complejidad, tiemposexcesivamente largos para su implantación y largos periodos de adaptación, los hacenen ocasiones inadecuados para los usuarios finales. Esto ha provocado un esfuerzo deinvestigación que busca nuevas vías de desarrollo para sistemas de BI, centrándoseen mejorar la experiencia del usuario. Es el caso de AQL y Data Clouds. Son sistemasde BI que trabajan con almacenes de datos en-memoria (memoria principal).

Se toma como referencia la solución patentada de la empresa QlikTech, QlikView[QlikView, WWW], tanto por sus magníficos resultados de rendimiento como por lafacilidad de uso de su panel de control (dashboard).

En el mercado existe una herramienta comercial similar, Tableau [Tableau, WWW].Aunque su comunidad es mayor, tiene algunas desventajas frente a QlikView:

Proporciona menor libertad a la hora de crear nuevas relaciones entre los datos.Tiene menor rendimiento que QlikView cuando tiene que realizar cálculos conlos datos contenidos en memoria.

Los paneles de control de QlikView son muy visuales (como se ilustra en la figura2.6), y poseen una gran interactividad con capacidades drill-down y tiempos derespuesta muy bajos debido a la arquitectura de datos en-memoria.

2.2.2. AQL y Data Clouds

La solución patentada por QlikTech consiste en enlazar todos los datos almace-nados a través de asociaciones lógicas. Esta colección de datos, denominada Data

39

2. Estado del arte

Figura 2.6.: Vista de un panel de control de QlikView (tomado de[Sendin-Raña et al., 2010]).

Cloud, permite a los usuarios obtener información de manera muy rápida. Las aso-ciaciones establecidas entre las estructuras de datos de diferente tipo de la DataCloud configura una AQL.

2.2.2.1. Ventajas y desventajas de este enfoque

Desde el punto de vista tecnológico, el enfoque basado en AQL y Data Cloudstiene las siguientes ventajas:

Permite la creación de peticiones potentes y al mismo tiempo flexibles, facul-tando al usuario para que desarrolle y cumpla sus objetivos de gestión.Permite respuestas a peticiones realmente rápidas. Esto se debe a que las AQLy Data Clouds permiten la recuperación de la información deseada a travésde los datos de varias tablas almacenadas en memoria principal. El tiempo debúsqueda de datos depende linealmente del tamaño de los datos deseados.Minimiza el uso de memoria principal necesaria para almacenamiento, por dosmotivos:

• Este método no posee los problemas de sobrecarga de datos debido aíndices o tablas agregadas De otros sistemas de BI.

• Los datos que originalmente se localizan en memorias secundarias soncomprimidos y codificados en memoria principal. Cada valor de dato se

40


almacena únicamente una vez, y su valor binario asociado se emplea parareferenciarlo tantas veces como sea necesario.

Permite la integración de datos de diferentes fuentes. Soporta diferentes tiposde motores de bases de datos relacionales, ficheros en texto plano, con formatocsv, ficheros de hoja de cálculo, etc. Todos estos diferentes tipos de fuentes dedatos pueden converger en una misma Data Cloud.

La desventaja más evidente de este enfoque es la falta de persistencia. Si lasfuentes de datos cambian durante la ejecución de esta herramienta, este cambiono se ve reflejado en los datos cargados en memoria principal. Sin embargo, estadesventaja no es demasiado grave en la mayor parte de los escenarios de BI, ya queun retardo de 24 horas en actualizar la adquisición de nuevos datos no se consideraun problema. En todo caso, se puede establecer un proceso periódico en backgroundque cargue la información de las fuentes de datos en la memoria principal: el tiempoempleado para esta carga es razonable comparándolo con los tiempos de carga deotras aplicaciones de BI.

2.2.2.2. Dentro del AQL y de los Data Clouds

Tecnológicamente, nos interesa profundizar en la velocidad de generación de res-puestas ante peticiones relativamente complejas y que demandan agregaciones de unnúmero elevado de datos. Los tiempos de respuesta son bajos gracias a la capacidadde gestionar datos codificados, que equivalen a gigabytes de datos originales almace-nados en memorias secundarias. Las peticiones se ejecutan accediendo a estructurasde datos que residen en memoria principal en vez de disco duro. Esta diferenciareduce sensiblemente el tiempo necesario para localizar, agregar y presentar la in-formación. Para ello:

En primer lugar, el diseño de las estructuras de datos debe permitir responder apeticiones tan potentes como las que se realizan a los sistemas OLAP, flexiblespero al mismo tiempo complejas.En segundo lugar, es necesario implementar algoritmos que permitan compri-mir decenas o centenares de gigabytes de datos (tamaños típicos en memoriassecundarias) en megabytes, para poder almacenarlos en memoria principal.

La solución a estos dos problemas debe ser mutuamente compatible. Esto es, lacompresión de los datos no ha de afectar a los tiempos necesarios para localizar yagregar datos.

Centrándonos en los almacenes de datos de tipo RDMBS (como los utilizadosen los sistemas ROLAP), sabemos que estas bases de datos relacionales siguen unaestructura de tablas. Las tablas se organizan en columnas (los tipos de elementos

41

2. Estado del arte

ID Nombre Edad Lugar de nacimiento1 John 35 Paris2 Joan 36 Rome3 John 27 Rome

Cuadro 2.2.: Estructura X, asociada con la estructura Y por medio de lugar denacimiento.

Lugar de nacimiento PaísParis FranceRome Italy

Cuadro 2.3.: Estructura Y, asociada con la estructura X por medio de lugar denacimiento.

de los datos que contendrán) y en filas (una entrada para cada nuevo registro). Lastablas se enlazan entre sí mediante relaciones entre sus columnas. El objetivo delData Cloud es replicar esta estructura de forma eficiente en memoria principal.

Consideremos los cuadros 2.2 y 2.3, que representan tablas que residen en unafuente de datos. Supongamos la aplicación las ha cargado en memoria principal.Las tablas cuentan con múltiples columnas, identificadas por sus nombres. Los da-tos extraídos de la fuente de datos se introducen en los registros de los camposcorrespondientes.

Las relaciones entre las tablas que residen en la memoria principal vienen defi-nidas por las columnas de datos que comparten el mismo nombre. Estas relacionesrepresentan la asociación lógica entre las tablas y servirán para simplificar los pro-cesos de búsqueda y filtrado. Dos tablas, cada una de ellas con una columna conel mismo identificador, comparten estructuras con información que permite conocersu estado en el sistema. Más tarde, en este apartado, se describirán en detalle estasestructuras.

Se utiliza un mecanismo de compresión para reducir el tamaño de estas estructu-ras de datos. Este mecanismo transforma los valores originales (los extraídos de lafuente de datos) por valores codificados en binario. Esta transformación es unívoca:cada valor se transforma en un valor binario único. Los cuadros 2.4, 2.5, 2.6 y 2.7

NombreJohn 0Joan 1

Cuadro 2.4.: Tabla de correspondencia binaria para Nombre.

42


Edad35 036 127 2

Cuadro 2.5.: Tabla de correspondencia binaria para Edad.

Lugar de nacimientoParis 0Rome 1

Cuadro 2.6.: Tabla de correspondencia binaria para Lugar de nacimiento.

representan las tablas de correspondencia entre los valores originales y los valoresbinarios. El cuadro 2.8 representa la tabla codificada que corresponde a la tabla delcuadro 2.2, y el cuadro 2.9 representa a la codificación binaria de la tabla del cuadro2.3.

El proceso de carga de datos implica una serie de pasos:

Lectura de datos de las tablas de la fuente de datos (supondremos que la fuentede datos es una base de datos relacional).Creación de una estructura interna asociada en la memoria principal.Codificación de los datos leídos en valores binarios.

Una vez todos los datos hayan sido leídos, se crea una nueva estructura, quedenominaremos tabla interna, en memoria principal. La tabla interna posee tantascolumnas como el proceso de carga haya seleccionado en la tabla de la fuente dedatos. Cuando la estructura de la tabla interna está finalizada, se transfieren losdatos de los registros de la tabla de la fuente de datos a la memoria interna. Esteproceso consiste en lecturas de valores desde los campos de la fuente de datos y encomprobaciones de si un valor aparece por primera vez en la tabla interna o si estárepetido. La comprobación se realiza mediante una tabla creada a tal efecto, la tablade asociación, donde se define la correspondencia entre los valores originales y losvalores codificados en binario. Si el valor leído ya existe en la tabla de asociación, secopia el valor binario asignado dentro del campo correspondiente de la tabla interna.

PaísFrance 0Italy 1

Cuadro 2.7.: Tabla de correspondencia binaria para País.

43

2. Estado del arte

Nombre Edad Lugar de nacimiento0 0 01 1 10 2 1

Cuadro 2.8.: Tabla binaria para la estructura X.

Lugar de nacimiento País0 01 1

Cuadro 2.9.: Tabla binaria para la estructura Y.

En caso contrario, es decir, si el valor leído no se encuentra en la tabla de asociación,se genera una nueva entrada que asocie este nuevo valor original con un nuevo valorgenerado codificado en binario. Este nuevo valor binario se introducirá en el campocorrespondiente de la tabla interna. Para cada columna de la tabla interna se creauna tabla de asociación diferente.

El algoritmo debe filtrar los datos rápidamente. El proceso de búsqueda de da-tos necesita tres nuevas estructuras de datos, además de las tablas anteriormentemencionadas. Estas estructuras serán tres vectores:

Vector de estado.Vector de selección.Vector de frecuencia.

Cada tipo de dato (cada tabla asociada) cuenta con una instancia de estos tresvectores. El vector de estado y el vector de selección son vectores booleanos con tantasposiciones como diferentes valores tenga la tabla asociada a la que estén ligados.Cada posición de estos vectores está ligada a su valor binario correspondiente. De estemodo, la posición cero del vector estado está ligada al valor binario cero de la tablaasociada correspondiente. El vector frecuencia cuenta con la misma dimensión quelos otros dos vectores (es decir, de nuevo tiene tantos valores como diferentes valoresbinarios tenga la tabla asociada correspondiente), pero su contenido es numérico.

Los vectores de selección representan la elección que, por medio de una interfazgráfica (por ejemplo, mediante un panel de control), realiza el usuario. Los camposcorrespondientes a los datos que el usuario selecciona tomarán un valor true (1),mientras que el resto del vector tomará el valor false (0).

Los vectores de estado representan el estado actual del sistema. Con el conjuntode todos los vectores de estado es posible identificar qué campos (de diferentes

44


columnas) están relacionados con los que selecciona el usuario a través de la interfazgráfica. Los vectores de estado se modifican mediante el proceso de búsqueda. Comoen el caso de los vectores de selección, existe un vector de estado por cada tipo deelemento de la tabla interna, y en cada vector de estado existe una relación directaentre sus posiciones y el número de valores diferentes en las tablas de asociación.

La figura 2.7 muestra un conjunto de vectores selección y estado con diferentesvalores, asociados al escenario descrito en las tablas de los cuadros 2.2 y 2.3. Másconcretamente, se ven tres vectores estado y tres vectores de selección, que corres-ponden a tres tipos de datos distintos: nombres, edades, y países. Los valores quetoman son el resultado de una selección en la interfaz del usuario de los valores Johny 36.

Figura 2.7.: Representación gráfica de los vectores de estado y selección (tomado de[Sendin-Raña et al., 2010]).

Los vectores frecuencia permiten gestionar información interna necesaria para elproceso de búsqueda.

2.2.2.3. Proceso de filtrado

El proceso de filtrado comienza con la acción de selección en la interfaz gráficapor parte del usuario. El sistema define la selección mediante el conjunto de vectoresselección, asignando el valor true (1) al campo seleccionado y el valor false (0) alos campos no seleccionados (el resto de los campos). Si la selección es la primerarealizada, o bien implica un reinicio del vector de estado (puede ser menos restrictivaque una selección anterior), todos los componentes del vector de estado toman elvalor true, y todos los vectores de frecuencia vacían su contenido.

45

2. Estado del arte

En el siguiente paso, los valores de los vectores selección que han cambiado secopian en los vectores de estado correspondientes. Después se comprueban todos losregistros de la tabla interna. Por cada campo de registro, el algoritmo compruebasi el valor binario está activado con su correspondiente vector de estado. Si esto esasí para todos los campos de ese registro, el algoritmo determina que se cumplenlos requisitos (match), e incrementa en una unidad la posición correspondiente delvector de frecuencia asociado. Una vez todos los registros de la tabla de datos hansido comprobados, los vectores de estado se modifican de acuerdo con los valorespresentes en los vectores de frecuencia. Si una posición de un vector de frecuenciadado tiene una valor distinto de cero, la posición asociada del vector de estadocorrespondiente toma el valor true. En otro caso, la posición toma el valor false.Después de estas modificaciones, se liberan los vectores frecuencia.

Este proceso continúa para las restantes tablas internas del sistema. Un vector deestado modificado en una tabla dada afecta a otras tablas que comparten ese vector.Una vez revisadas todas las tablas, el algoritmo comprueba si al menos un vector deestado ha modificado sus valores iniciales. Si esta situación se produce, el procesocomienza de nuevo, volviendo a comprobar la primera tabla interna visitada. En casocontrario, el algoritmo finaliza y el conjunto de los vectores de estado representa elestado actual del sistema.

La figura 2.8 muestra el diagrama de flujo que representa este algoritmo. Parauna descripción detallada, se pueden consultar las referencias [QlikTech:1, 2000,QlikTech:2, 2001]

2.3. Plataformas para aplicaciones distribuidas

En los últimos años se han consolidado diferentes plataformas para la implementa-ción de aplicaciones distribuidas. El concepto de cloud computing permite solucionarlos problemas de demanda de procesamiento de datos mediante infraestructuras decomputación distribuidas y compartidas [Dutta et al, 2011]. Estas plataformas per-miten desarrollar aplicaciones que se pueden distribuir en un conjunto de equipos(clusters) y que, además, son escalables y resistentes a fallos.

Nos centraremos en las dos plataformas que mayor éxito han tenido, las dos liga-das a la Apache Foundation [Apache, WWW]. De nuevo, nos centraremos en ellaspor ser plataformas de código abierto, ya que ésta es una característica primor-dial impuesta para todas las soluciones desarrolladas en este trabajo doctoral. Laprimera es Apache Hadoop [Apache Hadoop, WWW], orientada principalmente adistribución de procesos y construcción de un sistema de ficheros distribuido (uti-lizando las memorias secundarias de un conjunto de computadoras). Es interesantepara sistemas OLAP, ya que permite crear y gestionar los almacenes de datos de

46


Figura 2.8.: Diagrama de flujo que representa el algoritmo AQL para el proceso defiltrado (tomado de [Sendin-Raña et al., 2010]).

47

2. Estado del arte

forma distribuida. La segunda es Apache Spark [Apache Spark, WWW], orientadaa distribuir aplicaciones en memoria, con unas mejoras de rendimiento de hasta dosórdenes de magnitud.

2.3.1. Apache Hadoop en sistemas de Inteligencia de Negocio

2.3.1.1. Descripción de Apache Hadoop

Hadoop, proyecto fundado por Apache, es una plataforma de código abierto escritaen Java, orientada a optimizar el uso masivo de datos mediante su compresión y dis-tribución. Permite definir un conjunto de equipos donde distribuir el procesamientode enormes conjuntos de datos.

Hadoop está compuesto por múltiples productos, como Pig, Hive, HBase, HCata-log, Ambari, Mahout y Flume, pero las herramientas que destacan son Hadoop Dis-tributed File System (HDFS) para almacenamiento distribuido, y la implementaciónde MapReduce [Dean y Ghemawat, 2008] (tecnología de Google) para el procesado.

Debemos dejar claro que Hadoop es un complemento de sistemas de BI (OLAP,Data Warehouses, RDBMS), no un competidor. Permite paralelismo, y eso se traduceen mayor eficiencia y rapidez.

Las principales características de Hadoop son:

Escalabilidad. Una vez conformado el cluster, se pueden añadir más equipossin cambiar el modelo.Flexibilidad. Hadoop es compatible con cualquier tipo de datos, estructuradoo no.Tolerante a fallos. Si falla un equipo del cluster, el sistema redirige el trabajoa otro equipo y continúa el proceso sin pérdida de información. Esto siempreque se trate de un equipo esclavo.Coste. Mediante el paralelismo se consiguen rendimientos a un coste muchomenor que el del servidor equivalente.

El sistema de ficheros distribuido de Hadoop (HDFS) permite gestionar y pro-cesar enormes volúmenes de datos en ficheros. Está diseñado con una arquitecturacliente-servidor, y esto provoca que, aunque sea resistente a fallos en los equipos queactúan como esclavos (slaves), el fallo del equipo que actúa como maestro (master)implica un fallo general.

El nodo maestro, llamado NameNode, gestiona el árbol de directorio de todos losarchivos del sistema de ficheros distribuido en el cluster. La pérdida de cualquierotro nodo (nodos esclavos, llamados DataNodes) no genera pérdida de datos.

48


Actualmente se está trabajando en un nodo que solucione los problemas de dispo-nibilidad, denominado BackupNameNode. Sin embargo, el proyecto Apache aún noha conseguido hacerlo operacional. También existen otras opciones, como parchesde terceros, o nodos de tipo SecondaryNameNode, pero no proporcionan un sistemareal de alta disponibilidad.

MapReduce define un modelo de gran simplicidad para el procesado. La aplicaciónse divide en pequeños fragmentos, cada uno de los cuales se ejecuta en alguno de losnodos del cluster. Esto permite paralelismo y distribución de tareas que requierentiempos de computación elevados. Se alcanzan altos rendimientos en clusters de grantamaño. La biblioteca MapReduce permite al usuario definir dos funciones:

Map. Toma como entrada un conjunto de pares clave/valor y produce cero, unoo más pares clave/valor, que serán valores intermedios y que se le proporcio-narán más tarde a la función Reduce. Todos los valores intermedios asociadosa la misma clave se agruparán.Reduce. Esta función recibe una clave y todos los valores asociados a esa clave.Su propósito es reducir al máximo estos valores.

map (k1,v1) -> list(k2,v2)reduce (k2,list(v2)) -> list(v2)

Figura 2.9.: Funciones map y reduce.

El reto actual con HDFS y las herramientas de Hadoop es el desarrollo que sedebe realizar en lenguajes poco familiares para los profesionales del sector de las BI,como es el caso de R y Hive.

2.3.1.2. Integración de Apache Hadoop en sistemas de Inteligencia deNegocio

Actualmente, el proyecto Pentaho cuenta con soporte Hadoop. Esto quiere decirque un servicio Mondrian podría distribuirse en varios clusters Hadoop, mejorandosu rendimiento. Además, su configuración se efectúa mediante herramientas visua-les que facilitan el trabajo. Pentaho se conecta de forma nativa a las siguientesherramiendas de Hadoop:

HDFS.MapReduce.HBase.Hive.

49

2. Estado del arte

Las tareas ejecutadas mediante Pentaho MapReduce son varias veces más rápidasque otros métodos. La integración de la contribución que se presentará en el apartado3.1 podría utilizar de igual modo las ventajas de Apache Hadoop.

[Tian, 2008] describe un servicio OLAP basado en MapReduce, que permite análi-sis en paralelo. [Jinguo et al., 2008] propone optimizar el rendimiento de un sistemaOLAP con un algoritmo de peticiones basado en MapReduce. [Song et al., 2015]también propone un sistema MOLAP que utiliza Hadoop para mejorar los tiemposde carga y el rendimiento para atender peticiones de los usuarios.

En la literatura también se reportan buenos resultados de la aplicación de ApacheHadoop a sistemas OLAP ya existentes. [Wang et al., 2014] describe una aplicaciónde gestión de alquiler de bicicletas en la ciudad de Dublín. La herramienta OLAPque se utiliza proporciona información tanto para los usuarios de este servicio comopara los gestores de la aplicación.

Actualmente existe soporte para que los usuarios de QlikView o Tableau puedanconectarse a grandes volúmenes de datos gestionados por Apache Hadoop, por ejem-plo utilizando Hive [Thusoo et al., 2009]. De este modo se soportan las peticionesSQL sobre HDFS.

Para permitir el acceso a tales volúmenes de datos, QlikView añade una nuevacaracterística: Direct Discovery (DD). DD combina los datos cargados en memoriacon el acceso a datos almacenados en memorias externas. Las peticiones a estasmemorias externas se formulan de forma dinámica desde la propia aplicación, sintener que ingestar previamente esa información en memoria. Obviamente, ApacheHadoop, y más concretamente su sistema de ficheros distribuidos (HDFS), se utilizancomo memoria externa. Además es posible emplear MapReduce para el proceso decarga desde datos almacenados en HDFS.

2.3.2. Apache Spark en sistemas de Inteligencia de Negocio

2.3.2.1. Descripción de Apache Spark

Apache Spark en una plataforma para crear clusters de memoria principal. A dife-rencia de Apache Hadoop, no ha sido ideada para acceder a información almacenadaen memorias secundarias de manera distribuida. La mejora del rendimiento frente asistemas monomáquina es muy alta. Aun así, Spark necesita un sistema de ficherosdistribuido, que bien puede ser HDFS, para operar.

Apache Spark cuenta con las mismas características que Apache Hadoop: es es-calable, es flexible, es tolerante a fallos, y su coste es menor que el de un servidorequivalente en términos de rendimiento. El núcleo de Apache Spark, denominado Re-silient Distributed Datasets (RDDs), permite particionar los datos entre los nodos

50


que conforman el cluster y tareas de planificación.Dado que Spark está dentro del Proyecto Apache sólo desde 2014, es una tecnología

relativamente poco madura. De nuevo, Apache Spark no es competencia directa delos sistemas de BI en-memoria. Al contrario, es un complemento que permite mejorarsu rendimiento sensiblemente.

Al igual que Apache Hadoop cuenta con Hive para soporte a peticiones SQL,Apache Spark dispone de Shark como sistema de análisis de datos (proporcionandocapacidades de procesado de peticiones estructuradas y relacionales).

2.3.2.2. Integración de Apache Spark en sistemas de Inteligencia deNegocio

Existen experiencias de integración de sistemas OLAP con Apache Spark, comoes el caso de [Wang y Ye, 2014], que compara su propuesta con otras herramientasROLAP, con Hive y con Spark, obteniendo mejores resultados.

Sin embargo es en las soluciones de BI en-memoria donde tiene más sentido adop-tar Apache Spark. En particular, QlikView, con su modelo DD que ya permitía utili-zar Apache Hadoop para trabajar con volúmenes de datos mucho mayores, tambiéntiene capacidad para trabajar con la API RDD de Spark (QlikView tiene la certifi-cación de Apache Spark). Con Spark los tiempos de carga de datos desde HDFS sereducen drásticamente.

Ya que uno de los lenguajes de programación de Apache Spark es Java, resultaintuitivo, como se verá en el apartado 3.2, que se puede adoptar esta plataformapara mejorar el rendimiento de la solución propuesta de BI en-memoria, tanto entérminos de rapidez del proceso de carga y recarga (ver apartado 3.3) como en elvolumen de datos que pueden almacenarse en memoria.

51

Capítulo 3

Contribuciones

Índice3.1. Mejora del rendimiento y funcionalidad de sistemas

OLAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 543.1.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . 543.1.2. Diseño multidimensional . . . . . . . . . . . . . . . . . . . 553.1.3. Mejora de funcionalidad: el uso de dimensiones calculadas 593.1.4. Mejora de rendimiento en los coldstarts . . . . . . . . . . 653.1.5. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . 76

3.2. Sistemas de Inteligencia de Negocio basados en Asso-ciative Query Logic . . . . . . . . . . . . . . . . . . . . . . 77

3.2.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . 773.2.2. Solución web de Inteligencia de Negocio basada en AQL . 773.2.3. Resultados numéricos . . . . . . . . . . . . . . . . . . . . 993.2.4. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . 104

3.3. Mejora en el proceso de recarga de datos en solucionesweb AQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

3.3.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . 1063.3.2. Funcionamiento del algoritmo de recarga optimizado . . . 1073.3.3. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . 115

En este capítulo se presentan las contribuciones de este trabajo doctoral. El apar-tado 3.1 aborda la contribución a sistemas OLAP. En el subapartado 3.1.2 se con-textualiza el proyecto de Pesca Fresca y el diseño multidimensional sobre bases dedatos relacionales. El subapartado 3.1.3 explica el concepto de dimensión calculada,que permite crear miembros calculados en un cubo multidimensional en tiempo de

53

3. Contribuciones

ejecución. El subapartado 3.1.4 propone la solución para el problema de carga ini-cial en cold start, cargando vistas agregadas en memoria cache en el arranque delsistema. El subapartado 3.1.5 resume las conclusiones de esta contribución.

El apartado 3.2 aborda el desarrollo de una solución web de BI con datos en-memoria. En el subapartado 3.2.2 se describe dicha contribución desde una perspec-tiva práctica. Consiste en una serie de mejoras sobre el algoritmo AQL de QlikTech[QlikView, WWW]. El rendimiento de nuestra solución (que a diferencia de QlikViewes una solución web) es comparable. En el subapartado 3.2.3 se realiza la evaluacióncorrespondiente. El subapartado 3.2.4 resume las conclusiones del desarrollo de estasolución.

El apartado 3.3 presenta la solución para recargas rápidas y eficientes de datos ennuestra propuesta de BI con datos en-memoria. Esta solución permite unos tiemposde indisponibilidad muy reducidos que se traducen en la posibilidad de realizarrecargas frecuentes para disponer de información actualizada. El subapartado 3.3.1presenta los problemas detectados en las recargas de nuevos datos en este tipo desistemas, y en el subapartado 3.3.2 se describe la solución propuesta. El subapartado3.3.3 resume las conclusiones sobre la mejora en el proceso de recarga.

Las contribuciones del trabajo doctoral se recogen en las referencias [Sendin-Raña et al., 2009,Sendin-Raña et al., 2010].

3.1. Mejora del rendimiento y funcionalidad desistemas OLAP


En este apartado se presentará la solución propuesta para mejorar un servidorMondrian con una cache especializada y funcionalidades adicionales para obtenerdimensiones calculadas. Estas mejoras proporcionan soluciones para:

Prevenir inconsistencias utilizando sólo los datos agregados almacenados en lacache de Mondrian. La solución propuesta carga los datos preagregados tanpronto como el sistema OLAP se inicia, en un proceso denominado cold start.Obtener de forma dinámica y en tiempo de ejecución medidas calculadas apartir de operaciones con un tipo de dimensión especial: las dimensiones cal-culadas.

Cuando el servidor Mondrian se arranca e inicia, realiza peticiones SQL para ob-tener las listas de miembros del cubo multidimensional y determinar la cardinalidad,para más tarde cargar los segmentos en la cache. Esto es necesario para procesar las

54

3.1. Mejora del rendimiento y funcionalidad de sistemas OLAP

peticiones MDX originadas por los usuarios. Este proceso llamado cold start puedeconsumir un tiempo muy significativo, dependiendo del tamaño del cubo multidi-mensional. Cuando el servidor Mondrian finaliza (de manera programada o abrupta)y se vuelve a arrancar, el cold start se vuelve a iniciar. El diseño de los cubos multi-dimensionales está optimizado para peticiones del orden de 55 millones de registrosen la tabla de hechos, ante las que se tarda alrededor de 15 minutos en generar unresultado simple como un group by para la primera petición. Aun así, este tiempoes inaceptable.

En el proceso de cold start es necesaria la carga rápida de datos agregados enla cache de Mondrian, para atender las peticiones de los usuarios cumpliendo lasreglas FASMI. Mondrian, como servidor ROLAP, obtiene los datos de la base dedatos relacional que subyace en el modelo cuando no tiene esa información en lacache. Y tras el proceso de cold start la cache está vacía. Las peticiones iniciales alRDMBS tras una caída del sistema y un cold start tardan normalmente demasiado,dado que abarcan millones de accesos a registros. Si se evita que la cache esté vacía,cargando la información de datos agregados adecuada, las respuestas iniciales veránmejorado su tiempo de respuesta sensiblemente. La solución presentada incluye unprocedimiento de carga rápida de cache ante caídas inesperadas del sistema.

3.1.2. Diseño multidimensional

Nuestro punto de partida es la base de datos relacional utilizada por la plataformaPesca Fresca. La estructura de esta base de datos no se ha modificado desde suconcepción y no está optimizada para el acceso desde una herramienta de análisismultidimensional. La figura 3.1 muestra el modelo simplificado de su estructurarelacional.

La tabla de hechos es en este caso sep_gdia, ligada a las tablas de dimensiónsep_fishery y sep_species:

sep_fishery define la dimensión de localización geográfica.sep_species define la dimensión de especies pesqueras.

Las dimensiones restantes definidas en el cubo multidimensional (dimensiones parael eje temporal y para el estado) se obtienen directamente de la tabla de hechos(este tipo de dimensiones se denominan degeneradas). Podemos por tanto resumirlas relaciones como sigue:

Tabla de hechos: sep_gdia.Dimensiones:

• Temporal (degenerate dimension), definida por la columna date de la

55

3. Contribuciones

Figura 3.1.: Modelo de la estructura relacional subyacente (tomado de[Sendin-Raña et al., 2009]).

tabla de hechos.• Estado (degenerate dimension), definida por la columna data_state de la

tabla de hechos.• Localización geográfica, definida por sep_fishery y enlazada a la tabla de

hechos.• Especies pesqueras, definida por sep_species (junto con sep_species_group

y sep_fao) y enlazada a la tabla de hechos.

La tabla de hechos contiene las columnas que permiten definir las siguientes me-didas:

Columna notes, notas de ventas.Columna quantity, cantidad.Columna price, precio.Columna pmin, precio mínimo.Columna pmax, precio máximo.Medidas calculadas: Precio medio, calculado a partir de la media de las medi-das de cantidad y precio.

56


Número de días, obtenido con agregadores de cuenta a partir de la columnadata.Número de especies de pesca, obtenido con agregadores de cuenta a partir dela columna species_id.Número de lonjas, obtenido con agregadores de cuenta a partir de la columnafishery_id.

En la figura 3.2 se muestra el esquema del cubo multidimensional que se utiliza enel proyecto de Pesca Fresca y que emplea la estructura tablas presentadas anterior-mente. En este esquema se declaran funciones de agregación para cada medida, ylas dimensiones correspondientes. Para facilitar la lectura y mejorar la comprensiónde este esquema, se reemplazan deliberadamente algunas definiciones de jerarquías,niveles y definiciones SQL por notas. No son necesarias para entender conceptual-mente el modelo. En el apéndice A se muestra el esquema completo.

<?xml version="1.0"?><Schema name="PescaFrescaSchema" measuresCaption="Data Analysis">

<Cube name="PescaFresca">

<Table name="sep_gdia"/>

<Dimension name="Time" type="TimeDimension" caption="Time Dimension">Hierarchy and Level definitions

</Dimension><Dimension name="Time.byQuarters" type="TimeDimension"caption="Time by Quarters">Hierarchy and Level definitions

</Dimension><Dimension name="Time.byMonths" type="TimeDimension" caption="Time by Months">Hierarchy and Level definitions

</Dimension><Dimension name="Time.byDays" type="TimeDimension" caption="Time by Days">Hierarchy and Level definitions

</Dimension>

<Dimension name="Geographic location " foreignKey="fishery_id"><Hierarchy name="byRegions" ... allMemberName="All regions"primaryKey="fishery_id">Hierarchy and Level definitions

</Hierarchy><Hierarchy name="byZones" ... allMemberName="All zones" primaryKey="fishery_id">Hierarchy and Level definitions

</Hierarchy></Dimension>

57

3. Contribuciones

<Dimension name="Fishing species" foreignKey="species_id"caption="Fishing Species Dimension"><Hierarchy name="Fishing Species" hasAll="true" allMemberName="All species"primaryKey="species_id" primaryKeyTable="species_table">SQL definition<Level name="Group" column="group_description" uniqueMembers="true"/><Level name="FaoSpecie" column="fao" uniqueMembers="true"/><Level name="Species" column=" species_description" uniqueMembers="false"/>


<Dimension name="Data State" caption="Data State Dimension">Hierarchy and Level definitions

</Dimension><Dimension name="Calculated Dimension" caption="Calculated Dimension"foreignKey="gdia_id"><Hierarchy hasAll="true" memberReaderClass="mondrian.rolap.MiscHierarchy"><Level name="Calculated Dimension" uniqueMembers="true"/>


<Measure name="Sales Notes" column="notes" aggregator="sum" datatype="Numeric"formatString="#,###"/><Measure name="Quantity" column="quantity" aggregator="sum" datatype="Numeric"formatString="#,###.##"/><Measure name="Sales" column="price" aggregator="sum" datatype="Numeric"formatString="#,###.##"/><Measure name="Maximum Price" column="pmax" aggregator="max" datatype="Numeric"formatString="#,###.##"/><Measure name="Minimum Price" column="pmin" aggregator="min" datatype="Numeric"formatString="#,###.##"/><Measure name="Days Number" column="date" aggregator="distinct count"datatype="Numeric" formatString="#,###"/><Measure name="Species Number" column="species_id" aggregator="distinct count"datatype="Numeric" formatString="#,###.##"/><Measure name="Fisheries Number" column="fishery_id" aggregator="distinct count"datatype="Numeric" formatString="#,###"/>

<CalculatedMember name="Average Price" dimension="Measures"caption="Average Price"><Formula> [Measures].[Price] / [Measures].[Quantity] </Formula><CalculatedMemberProperty name="FORMAT_STRING" value="#,###.##"/>

</CalculatedMember>

</Cube></Schema>

Figura 3.2.: Esquema multidimensional para la definición del cubo en Mondrian.

58


Algunas aclaraciones:

La definición de la dimensión temporal no es óptima. El diseño de la estruc-tura relacional subyacente debería contar con una tabla que definiese estadimensión (es decir, una tabla para la información temporal). Sin embargo,los requerimientos de los que se partían (la estructura original de la base dedatos relacional de la plataforma Pesca Fresca) forzaron a utilizar esta alter-nativa: utilizar una columna de la tabla de hechos. Este tipo de diseño generaineficiencias y aumenta el tiempo de respuesta de cualquier petición que utiliceesta dimensión.La dimensión temporal se define con cuatro jerarquías. Con esta configuraciónpodemos permitir peticiones que utilicen el eje temporal en dos dimensiones.Por ejemplo, se podría pedir un informe de ventas que contase con un ejevertical por años, y desglosase la información por meses en el eje horizontal.Definimos dos jerarquías para la dimensión de localización geográfica, con di-ferentes niveles. De este modo, el usuario podrá acceder a los miembros deesta dimensión desde diferentes caminos.La dimensión encargada de las especies pesqueras necesita definir unas senten-cias SQL dentro del cubo para poder crear niveles. De nuevo esta imposiciónno óptima viene dada por la base de datos relacional de la plataforma PescaFresca, para obtener información del modelo de datos subyacente. No es posibleutilizar las etiquetas join de Mondrian, lo que sería la opción más adecuada.

Cada medida corresponde a una función de agregación de Mondrian (como porejemplo sum para suma, avg para el cálculo de la media, distinct count para la cuentade elementos distintos, etc.), exceptuando la medida para el cálculo de precio medio,calculada mediante una fórmula definida en el propio esquema.

3.1.3. Mejora de funcionalidad: el uso de dimensionescalculadas

El objetivo es proporcionar una solución para la definición y uso de dimensionescalculadas para sistemas de BI que utilicen Mondrian como motor OLAP, siguiendouna concepción similar al concepto de miembro calculado. Los miembros calculadosson unos miembros especiales cuyos valores, o bien son declarados en las sentenciasMDX en tiempo de ejecución, o bien se declaran en el esquema de Mondrian.

Normalmente los miembros toman valores directamente de la agregación de datos,pero los miembros calculados usan una fórmula para este propósito. Los miembroscalculados permiten añadir medidas a los cubos multidimensionales sin incrementarsu tamaño, ya que se calculan en tiempo real, y éste es un método muy potente de

59

3. Contribuciones

definición de expresiones. Por ejemplo, pueden utilizarse para calcular porcentajeso operaciones más complejas.

Sin embargo, si el usuario quiere definir varios miembros calculados para cada me-dida de un cubo multidimensional, el esquema crece exponencialmente y aparecenproblemas para su mantenimiento. Si el usuario quiere evitarlos y definir los miem-bros calculados en cada sentencia MDX, será necesario entonces declarar la fórmulaasociada para cada uno de ellos en cada ocasión. Además, cada vez que el usuarioquiera definir una nueva medida, y desee establecer una equivalencia de miembroscalculados para esa nueva medida, tendrá que declarar de nuevo los miembros cal-culados asociados.

Por este motivo se introduce la dimensión calculada. Esta contribución proporcio-na la creación dinámica de miembros calculados en tiempo de ejecución, evitandolos problemas presentados anteriormente. Esta característica mejora la experienciadel usuario, ya que proporciona un método intuitivo para construir peticiones mul-tidimensionales. Además, el rendimiento del motor ROLAP de Mondrian no se veafectado.

Proponemos, por tanto, un nuevo tipo de dimensiones para el cubo Mondrian.En los esquemas originales, cada dimensión se define a partir de tablas de dimen-sión (bien a partir de tablas de la base de datos relacional, tablas en línea, o tablasgeneradas por clases de Java). Estas dimensiones están ligadas a las medidas quecontienen datos. El nuevo tipo de dimensión propuesta, la dimensión calculada, nocuenta con este tipo de relaciones. Tan sólo especifica el comportamiento que segenerará cuando se cruce con algún miembro de una o más medidas definidas en elcubo Mondrian. Este cruce entre dimensión calculada y medida produce automáti-camente un conjunto de miembros calculados, lo que evita tener que definirlos bienen el esquema multidimensional o bien en cada petición MDX.

Las medidas tienen normalmente asociadas varias expresiones comunes. Nosotrospersonalizamos esta característica y creamos una dimensión (la dimensión calculada)cuyos miembros son definidos como interfaz. De este modo, cuando un miembro deuna dimensión calculada se cruzan con cualquier medida, el resultado es un miembrocalculado definido con las reglas y operaciones definidas en esa interfaz.

Como se afirmó anteriormente, existen dos métodos para definir miembros calcu-lados en Mondrian:

Mediante la etiqueta CalculatedMember en el esquema Mondrian. Se define elnombre del miembro calculado y la fórmula con la que obtiene su valor.En las sentencias MDX, mediante las cláusulas with member. La expresiónMDX define las medidas necesarias y los miembros de dimensión requeridospara el cálculo del miembro calculado.

60


<Dimension name="Calculated Dimension" caption="Calculated Dimension"foreignKey="gdia_id"><Hierarchy hasAll="true" memberReaderClass="mondrian.rolap.MiscHierarchy"><Level name="Calculated Dimension" uniqueMembers="true"/>


Figura 3.3.: Fragmento de esquema multidimensional para la definición de una di-mensión calculada.

SELECT Crossjoin ( {[Measures].[Sales]} ,{[Calculated Dimension].[Data],[Calculated Dimension].[Absolute Variation],[Calculated Dimension].[Relative Variation],[Calculated Dimension].[Percent]}

) ON COLUMNS, NON EMPTY {[Time.byYears].Members} ON ROWSFROM [PescaFresca]

Figura 3.4.: Sentencia MDX con uso de dimensión calculada.

La figura 3.2 muestra un ejemplo de miembro calculado. La medida que nos dael precio medio es un miembro calculado asociado a dos medidas. Una dimensióncalculada automáticamente genera miembros calculados similares sin más que cruzarsus miembros con otra medida definida en el esquema en estrella de Mondrian.

Consideremos el fragmento de esquema mostrado en la figura 3.3. La dimensióncalculada llamada Calculated Dimension viene definida por la clase de Java llamadaMiscHierarchy, que a su vez es una subclase de MemberReader de la especifica-ción de Mondrian. Cuenta con un único nivel, y sus datos no residen en ningúnRDBMS. La clase MiscHierarchy se encarga de proporcionar la lista de miembrosde la dimensión. Y, a diferencia de las tradicionales dimensiones, ésta tan sólo esútil cuando se combina (cruza) con alguna medida en la sentencia MDX. Sin estecruce, la dimensión no produce ningún resultado: la clase MiscHierarchy tan sólodefine la semántica de la dimensión.

La clase MemberReader implementa operaciones comunes para obtener miembrosde una jerarquía. Sin embargo, estas operaciones son restrictivas para nuestro pro-pósito, por lo que empleamos una técnica de pre-filtrado MDX.

Podemos describir un ejemplo de una aplicación de esta nueva funcionalidad. Siel usuario quiere consultar las ventas del año 2007, y al mismo tiempo consultar suvariación y el porcentaje de variación sobre años anteriores, la dimensión calculadanos proporcionaría la capacidad de utilizar una sentencia MDX como la mostradaen la figura 3.4.

61

3. Contribuciones

WITHMEMBER [Measures].[Data absolute variation]AS [Measures].[Sales] -([Measures].[Sales],

[Time.byYears].CurrentMember.PrevMember)MEMBER [Measures].[Data relative variation]AS ([Measures].[Sales] ([Measures].[Sales],

[Time.byYears].CurrentMember.PrevMember))/([Measures].[Sales],[Time.byYears].CurrentMember.PrevMember),

FORMAT_STRING=#.###.## %MEMBER [Measures].[Data percent]AS [Measures].[Sales]/([Measures].[Sales],

[Geographic location.byRegions].CurrentMember.Parent),FORMAT_STRING=#.###.## %

SELECT Crossjoin ({[Measures].[Sales], [Measures].[Data absolute variation],[Measures].[Data relative variation],[Measures].[Data percent] } ) ON COLUMNS,

NON EMPTY {[Time.byYears].Members} ON ROWSFROM [PescaFresca]

Figura 3.5.: Sentencia MDX sin uso de dimensión calculada.

Debemos resaltar que en esta sentencia MDX no se ha definido ningún miembrocalculado. Si necesitamos más miembros calculados de cualquier otra medida, tansólo debemos incluirlos en la función crossjoin. Por otro lado, la figura 3.5 muestrauna sentencia MDX que no utiliza la funcionalidad de dimensión calculada. En estasentencia es necesario declarar tres nuevos miembros calculados, tan sólo para lamedida deseada. Si se quisiese aplicar a otra medida serían necesarios tres nuevosmiembros calculados.

La clase Java RolapConnection definida en el proyecto Mondrian se encarga dedefinir el método que gestiona las peticiones MDX. La solución propuesta desarrollauna subclase llamada RolapConnectionSIP, que implementa un método de prefil-trado para la generación de los miembros calculados necesarios. Cruzando cualquiermedida con cualquier miembro de una dimensión calculada en la sentencia MDX,se genera un miembro calculado con esta técnica de prefiltrado. El patrón para lageneración de los miembros calculados es siempre el mismo. La clase RolapCon-nectionSIP carga los valores de configuración para esta nueva funcionalidad de undocumento XML cada vez que Mondrian se inicia. Cuando se recibe una peticiónMDX de un usuario, y se detecta el uso de dimensiones calculadas, se traduce es-ta sentencia en una petición MDX equivalente, con los miembros calculados. Estapetición es una sentencia MDX válida.

El documento XML de configuración declara la dimensión calculada, sus miembros

62


y los elementos necesarios para la generación de los miembros calculados (cuandose combina con la función especial crossjoin). La figura 3.6 muestra un ejemplo dedocumento XML para el cubo de Pesca Fresca, con seis miembros:

All Member designa a todos los miembros de la dimensión. Contiene el atributoisAll que permite definirlo de este modo, de forma semejante a las dimensionestradicionales de Mondrian.Data hace referencia al valor de la medida que se definirá en la función crossjoinde la sentencia MDX.Past hace referencia al valor pasado.Absolute variation define la variación absoluta del valor respecto a otro ante-rior.Relative variation define la variación relativa del valor respecto a otro anterior.Percentage define el porcentaje del valor de la medida.

Los últimos cuatro miembros tienen asociada una fórmula para generar los miem-bros calculados. Si se aplica el atributo formatString a alguno de estos miembros, elformato de la celda resultante viene determinado por la expresión que acompaña aeste atributo.

Los elementos baseMember y baseSliceDimension son constantes útiles para tra-ducir la sentencia MDX. Permiten generar miembros calculados automáticamentegracias a la clase RolapConnectionSIP. De forma semejante, el elemento related-Dimensions permite traducir la sentencia MDX cuando otras dimensiones estánrelacionadas en la expresión multidimensional. Esta entrada cuenta con múltipleselementos de tipo dimensión, que corresponden a todos los posibles valores parapoder visualizar los datos desde diferentes puntos de vista.

La figura 3.7 muestra una sentencia MDX que utiliza una dimensión calculadapara, en combinación con tres medidas, generar doce miembros calculados.

La figura 3.8 muestra el resultado de la combinación de una de las medidas (ventas)con todos los miembros de la dimensión calculada. Se utiliza JPivot para generar elinforme.

El servidor Mondrian comprueba las sentencias MDX recibidas. Si se detecta eluso de al menos un miembro de una dimensión calculada dentro de una funcióncrossjoin, se llama a un método específico que traduce la sentencia MDX y generalos miembros calculados. El fichero de configuración XML define el proceso de tra-ducción y generación, y los miembros calculados resultantes se añaden a la sentenciaMDX. De este modo se reformula la petición y se consigue una sentencia MDX com-pletamente compatible. Esta sentencia MDX resultante se procesa continuación y

63

3. Contribuciones

<?xml version="1.0" encoding="UTF-8"?><!DOCTYPE calculatedDimension SYSTEM "dimconfiguration.dtd"><calculatedDimension><baseMember>BASE_MEMBER</baseMember><baseSliceDimension>BASE_SLIDE_DIMENSION</baseSliceDimension><members><member isAll="true" name="All"/><member name="Data"/><member name="Past">(BASE_MEMBER,[Time].CurrentMember.PrevMember)

</member><member name="Absolute variation">(BASE_MEMBER-(BASE_MEMBER,[Time].CurrentMember.PrevMember))

</member><member name="Relative variation" formatString="#,###.## %">(BASE_MEMBER-(BASE_MEMBER,[Time].CurrentMember.PrevMember))/(BASE_MEMBER,[Time].CurrentMember.PrevMember)

</member><member name="Percentage" formatString="#,###.## %">BASE_MEMBER/(BASE_MEMBER BASE_SLIDE_DIMENSION)

</member></members><relatedDimensions><dimension>Fishing Species. Fishing Species</dimension><dimension>Geographic location.byRegions</dimension><dimension>Time.byYears</dimension>

</relatedDimensions></calculatedDimension>

Figura 3.6.: Definición de dimensión calculada.

SELECT Crossjoin {[Measures].[Sales Notes], [Measures].[Quantity],[Measures].[Sales]},

{[Calculated Dimension].Members) ON COLUMNS,NON EMPTY {[Time.byYears].Members} ON ROWSFROM [PescaFresca]

Figura 3.7.: Sentencia MDX que combina tres medidas con los miembros de unadimensión calculada.

64


Figura 3.8.: Informe utilizando JPivot (tomado de [Sendin-Raña et al., 2009]).

la respuesta contiene el informe con los valores de los miembros calculados. Esteinforme es el resultado que se envía al usuario que generó la sentencia MDX.

Esta nueva funcionalidad, que permite el uso de dimensiones calculadas, puedeaplicarse a cualquier solución Mondrian. El administrador del sistema debe definirel fichero de configuración XML declarando las dimensiones calculadas, del mismomodo que debe diseñar el fichero de configuración XML que permite definir el cuboMondrian.

3.1.4. Mejora de rendimiento en los cold starts

Los tablas definidas en los almacenes de datos, que sirven de capa relacional sub-yacente a los sistemas OLAP, comprenden la tabla de hechos (típicamente paraalmacenar medidas) y tablas auxiliares que normalmente se utilizan para almacenarla información asociada a las dimensiones de los cubos. Las tablas de vistas agre-gadas de los almacenes de datos y la cache (el último elemento de la estrategia deagregación) soportan el precómputo de agregaciones para conjuntos muy extensosde datos. La cache adaptativa de Mondrian mantiene estas agregaciones precompu-tadas en memoria, de tal modo que las sentencias MDX posteriores puedan accedera esta información y beneficiarse de una mayor rapidez de respuesta, evitando laconsulta en la base de datos relacional.

Mondrian sigue una estrategia de vistas agregadas como ya hemos presentadopara mejorar su rendimiento, como la mayor parte de los sistemas ROLAP. El cubomultidimensional utiliza automáticamente la tabla de hechos o las tablas de vistasagregadas para obtener información de la base de datos relacional. Si las tablas devistas agregadas proporcionan directamente la información requerida, sin necesidadde consultar la tabla de hechos, las respuestas a las peticiones SQL son mucho másrápidas. Esto sucede debido a que se evita trabajar con un número muy elevado de

65

3. Contribuciones

registros, y a que las operaciones de agregación ya están realizadas. Para utilizareste esquema se deben definir algunas reglas en el esquema multidimensional.

Se imponen una serie de requerimientos a las tablas de vistas agregadas definidasen la base de datos relacional:

El diseño ha de ser adecuado para que estas tablas proporcionen una mejoraen el rendimiento de Mondrian.Cuando cambia la tabla de hechos (debido, por ejemplo, a una modificaciónde un dato, o a la introducción de uno nuevo), las tablas de vistas agregadasdeberán actualizarse, dependiendo de los datos que contengan. Normalmentelos cambios se producen de forma periódica, no de forma continua (por ejemplo,una vez al día), y los ejecutan procedimientos almacenados. Mientras estaactualización de tabla de hechos y tablas de vistas agregadas se realiza, elalmacén de datos permanece inutilizable.Si el almacén de datos debe estar permanentemente disponible (por razonesde operatividad), los cambios antes mencionados en la tabla de hechos, queafectan a las tablas de vistas agregadas (actualización de estas tablas), com-prometerán la consistencia del modelo. Podría, por ejemplo, suceder que unasentencia MDX (que se descompone en varias sentencias SQL) accediese a da-tos ya actualizados de la tabla de hechos pero al mismo tiempo a datos noactualizados de las tablas de vistas agregadas.

A mayor número de tablas de vistas agregadas a mantener, más críticos sonla gestión y mantenimiento eficiente de las tablas de vistas agregadas en los al-macenes de datos, y también se precisa más memoria para su almacenamiento[Gupta y Mumick, 1999]. Además, el tiempo de actualización también se convierteen un factor crítico, ya que típicamente este tiempo es limitado. En los requeri-mientos de diseño de la plataforma Pesca Fresca se especifica que los datos debenestar permanentemente disponibles. Y, sin embargo, sabemos que las actualizacionespueden efectuarse mientras el motor Mondrian atiende peticiones MDX de los usua-rios. Las tablas de vistas agregadas dependen de la tabla de hechos, y por tanto elprocedimiento almacenado debe también actualizar estas tablas de datos agregados.En nuestro sistema se puede dar la situación de que una petición MDX se atiendadespués de que se actualice la tabla de hechos, pero antes de que se efectúen esoscambios en las tablas de vistas agregadas. Esta situación produce una respuesta in-consistente: el resultado de la sentencia MDX combina información actualizada coninformación desfasada.

Para resolver estas situaciones se puede utilizar un diseño que contemple servido-res Mondrian replicados, con un servidor maestro y otro actuando de backup, detrásde un equipo de equilibrado de carga. Cuando los nuevos datos están disponibles, el

66


servidor que actúa como backup deja de estar disponible, actualiza toda la informa-ción en la tabla de hechos y tablas agregadas, y conmuta con el servidor maestro.Éste actúa de modo equivalente. Además de tratarse de un modelo costoso, no pue-de aplicarse a la plataforma Pesca Fresca, ya que en dicha plataforma era necesarioutilizar la infraestructura original de hosting que alberga la base de datos relacional.Esta base de datos contiene toda la información multidimensional del cubo OLAP,y no cuenta con ningún tipo de replicación. El administrador del sistema puedeintroducir nueva información o gestionar la base de datos relacional en cualquiermomento. El almacén de datos, además, ha de estar permanentemente disponible,y cualquier cambio en las dimensiones o tabla de hechos ha de ser consistente.

Para evitar problemas de consistencia en los datos, y de indisponibilidad de datos,tomamos la decisión de diseño de no utilizar tablas de vistas agregadas en la basede datos relacional que actúa como almacén de datos del servidor Mondrian. Hemosoptado por utilizar la cache de Mondrian para resumir la información presente enla tabla de hechos de la base de datos relacional en las agregaciones más comunesy que más demandan las peticiones MDX. El propósito original de la cache deMondrian es mantener datos agregados en memoria, resultado de las respuestas delas últimas peticiones MDX recibidas. Nosotros extendemos este mecanismo paraque contenga información de vistas agregadas de las tablas de la base de datosrelacional. Sin embargo, cuando el servidor Mondrian se inicia, no existe ningunainformación agregada en la cache. Por tanto, un proceso adicional debe encargarse deagregar los datos almacenados en la tabla de hechos de la base de datos relacional yalmacenarlos en memoria, tan pronto como sea posible, sin esperar que los usuariosempiecen a generar peticiones MDX. Como se ha dicho, llamamos a este procesoespecial proceso cold start.

Como se comentó anteriormente, cuando el servidor Mondrian se inicia, la cacheestá vacía. Cuando el servidor empieza a recibir y procesar peticiones MDX, y cuan-do genera sentencias SQL que envía a la base de datos relacional (tras traducir MDXen sentencias SQL), recibe los segmentos de información que almacena en su cache.Cuando el servidor se reinicia de forma programada o sufre apagados abruptos, sucache vuelve a estar vacía y es necesario volver a cargar todos los segmentos de in-formación en ella. Esto puede implicar tiempos de espera muy elevados dependiendodel tamaño del cubo (la base de datos ha de ejecutar en ocasiones muchas opera-ciones sobre un volumen de registros muy elevado para obtener agregaciones). Porejemplo, en una de nuestras pruebas, una petición MDX sobre un cubo que conteníainformación multidimensional almacenada en una base de datos de 4 gigabytes tardó6 minutos en obtener los resultados esperados.

La figura 3.9 muestra una comparativa de los tiempos de respuesta dependien-do de si el sistema cuenta con la información agregada en la cache de Mondrian ono. Con información agregada mejora el tiempo de respuesta. Sin esta información

67

3. Contribuciones

Figura 3.9.: Tiempos de respuesta ante peticiones MDX complejas (tomado de[Sendin-Raña et al., 2009]).

68


en memoria, los tiempos de respuesta para peticiones MDX complejas son inacep-tablemente altos. Y esto es debido a que dichas peticiones normalmente implicanvarias peticiones SQL, y cada una de ellas implica el acceso a miles o a millones deregistros de la base de datos relacional, utilizan operaciones de agregación, utilizanoperadores join, etc.

La solución propuesta para el proceso de cold start es rápida y el impacto aefectos de mantenimiento del sistema Mondrian es despreciable. Los datos agregadosresiden en la cache de Mondrian, y las operaciones de refresco de datos utilizan unasfunciones de control específicas, asegurando de este modo la integridad de los datos.La solución se divide en dos fases:

Creación, carga y almacenamiento de una fuente de datos que denominaremosparallel cache. Esta parallel cache contiene todos los datos para el proceso decold start y los datos generados para atender las peticiones de los usuarios.La parallel cache, o cache de nivel secundario, es por tanto la fuente de datospara el proceso de cold start.Creación de un script de peticiones MDX para iniciar la cache de Mondrian. Alinicio del sistema, Mondrian carga la cache de segundo nivel (parallel cache)y ejecuta el script de peticiones MDX en background. Cada petición MDXencuentra los datos en la parallel cache, y Mondrian construye su propia cachede forma automática y totalmente transparente al usuario. Este método esmás rápido que la obtención de los mismos datos agregados a partir de la basede datos relacional.

Esta solución requiere que introduzcamos en el código encargado de la cache deMondrian, más específicamente en la parte encargada de la generación de los seg-mentos de datos. Esto se debe a que es necesario cargar en estos segmentos de datos(como por ejemplo, áreas multidimensionales definidas por uno o más miembros)información de la parallel cache, además de la propia base de datos relacional queactúa como almacén de datos. La implementación de estos cambios se ha realizadode tal modo que la migración a futuras versiones de Mondrian sea sencilla.

La versión 2.3 de Mondrian cuenta con una API para el control de la cache. EstaAPI proporciona un control fino de los datos de cache y mantiene la consistenciade los datos en peticiones concurrentes. Este control utiliza segmentos de cache yposee la capacidad de refrescar tan sólo regiones específicas de estos segmentos. Lasanteriores versiones de Mondrian únicamente permitían refrescos completos de lacache, y eran muy ineficientes. Con la posibilidad de refrescos selectivos, en casode algún cambio en la base de datos relacional, sólo será necesario refrescar lossegmentos de cache que contengar los datos agregados relacionados con el cambio.Esto permite mantener los datos agregados válidos en la cache de Mondrian parafuturas peticiones MDX.

69

3. Contribuciones

Cuando el motor de Mondrian realiza una tarea de refresco, ésta también deberárepercutir en la información almacenada en la parallel cache. Si un segmento dela cache de Mondrian se elimina, el correspondiente elemento de la parallel cachetambién deberá eliminarse.

En la búsqueda de soluciones a nuestro problema también se consideraron otrasopciones, como las serializaciones de la cache de Mondrian, o la asignación (map-ping) de los segmentos de la cache. Sin embargo, nos encontramos con los siguientesproblemas al intentar alguna de estas aproximaciones:

Los procesos de carga y almacenamiento resultan demasiado costosos en tér-minos temporales, y el consumo de recursos es alto. Resultan comunes lasexcepciones de Java por exceder el tamaño de memoria asignado.Los ficheros generados son demasiado grandes, del orden de varios gigaby-tes. El tiempo necesario para la carga y almacenamiento de estos ficheros esinaceptable.Para implementar cualquiera de estas dos opciones, las modificaciones en elcódigo de Mondrian serían demasiado intrusivas. Esto haría imposible la mi-gración a nuevas versiones.

Como afirmamos anteriormente, el proceso cold start lanza y ejecuta múltiplessentencias MDX para construir la cache de Mondrian. Esta secuencia de sentenciasMDX está especificada en un fichero XML denominado mdxgenerator.xml.

Para nuestra solución, además de cambiar la generación de segmentos en la cachede Mondrian, añadimos dos nuevas clases Java al código del proyecto Mondrian.Estas clases son:

ServletColdStart. Esta clase de tipo servlet se utiliza para• iniciar el proceso cold start.• lanzar el proceso cold start.• cargar los datos de la parallel cache del disco duro, utilizando la clase

CacheStore.• almacenar los datos de la parallel cache en un fichero del disco duro,

utilizando la clase CacheStore.• liberar la cache de Mondrian, utilizando la API de control de cache, y

refrescar la parallel cache.El servidor web Java que alberga el sistema (como por ejemplo Apache Tomcat[Tomcat, WWW]) recibirá una petición dirigida a ServletColdStart y ejecutarálas acciones correspondientes.

70


CacheStore. Se encarga de gestionar la parallel cache. Permite añadir y eliminarentradas, y cargar la parallel cache del disco duro o almacenarla en él. Estaclase tiene los siguientes atributos:

• Una lista llamada Rowset, que contiene los datos de los segmentos decada zona de la cache de Mondrian.

• Una lista llamada idSegment, que contiene los identificadores de los seg-mentos de la cache de Mondrian.

• Una lista llamada listHashQueries, que contiene el hash de cada peticiónSQL utilizada para obtener los segmentos de la cache de Mondrian.

Estos atributos permiten modelar la parallel cache. El proceso que almacenalos datos de la parallel cache en disco se encarga de serializarlos en primerlugar para más tarde poder efectuar las operaciones de escritura en memo-ria secundaria. El proceso de carga de datos del disco realiza las operacionesopuestas.

La clase ServletColdStart toma sus parámetros de entrada de peticiones de tipoGET. Estos parámetros de entrada son necesarios para el reconocimiento de laacción, además de para la carga de otras variables. ServletColdStart puede realizarcuatro posibles acciones (la figura 3.10 ilustra estos procesos):

Start. Iniciación del proceso de cold start. Se carga el documento XML quecontiene las sentencias MDX para generar la cache de Mondrian. El motorOLAP ejecuta estas sentencias y va generando su cache. Esto no impide que, enparalelo, Mondrian atienda otras peticiones de los usuarios y envíe respuestas.Si las peticiones corresponden a datos consistentes ya cargados en la cachede Mondrian, ya no será necesario acudir a la base de datos relacional paraefectuar operaciones de agregación.Load. Carga del disco. Se lee la información de la parallel cache del disco duropara cargarla en la clase CacheStore.Store. Almacenamiento en disco. La información contenida en los atributos dela clase CacheStore, que contienen los datos de la parallel cache, se guarda enel disco duro.Flush. Recarga de elementos de la parallel cache. Para ello, el método de la cla-se ServletColdStart debe recibir como parámetros de entrada información queidentifique los elementos a recargar. Es necesario construir la definición de lossegmentos de cache para poder liberar estas regiones de memoria con la APIde control de cache que incorpora Mondrian. Después, una vez eliminados lossegmentos de la cache de Mondrian, se eliminan los elementos correspondien-tes de la parallel cache. Finalmente, se lanza de nuevo el proceso encargado

71

3. Contribuciones

de agregar y cargar los datos de la base de datos relacional en la cache deMondrian: si estos datos ya residen en la cache (no han sido eliminados), noes necesario efectuar ninguna operación. Además de cargar estos datos en lacache de Mondrian, también se guardan en la parallel cache, y se almacenanen memoria secundaria mediante el proceso Store.

Figura 3.10.: Acciones de la clase ServletColdStart (tomado de[Sendin-Raña et al., 2009]).

Existen dos métodos para obtener los datos necesarios para crear la parallel cache:

leer los datos de la cache de Mondrian.leer los datos de memorias secundarias (disco duro).

La primera opción es la manera natural de construir la parallel cache, y la únicaopción válida cuando no existe información almacenada en memorias secundarias.

Mondrian cuenta con una compleja estructura para gestionar su cache, con dife-rentes clases para gestionar segmentos y agregaciones, y con distintos métodos paraobtener la información. En caso de que no encuentre la información que el usuariodemanda por medio de una petición MDX en la cache, se generan peticiones SQLque obtienen la información de la base de datos relacional subyacente (y se incor-pora esta nueva información a la cache). Nuestra propuesta modifica este esquema.Cuando Mondrian obtiene estos nuevos datos de la base de datos relacional y creaun nuevo segmento para la cache, nuestra propuesta incorpora esta información ala parallel cache, junto con un identificador y un código hash generado a partir de

72


la sentencia SQL. Este procedimiento se emplea en la iniciación del proceso de coldstart cuando de lanzan las sentencias MDX del fichero XML, pero también se aplicaa cualquier petición generada por los usuarios.

Tras la carga de la parallel cache con datos de la memoria secundaria, el procesocold start no generará peticiones SQL a la base de datos relacional para obtener lossegmentos de la cache de Mondrian (en caso de que esta cache esté vacía). El procesocold start creará los segmentos a partir de los datos almacenados en la parallel cache.Esto reducirá dramáticamente los tiempos necesarios para la reconstrucción de lacache de Mondrian. En la figura 3.11 se muestra el proceso descrito: la primerapetición obtiene datos de la cache de Mondrian, y los datos se generan a partir deella. Sin embargo, la segunda lectura no encuentra la agregación buscada en la cachede Mondrian, y los datos se obtienen mediante una petición a la parallel cache.

Figura 3.11.: Proceso de obtención de datos de las diferentes memorias de tipo cache(tomado de [Sendin-Raña et al., 2009]).

Cuando el servidor Mondrian se inicia como proveedor de servicio XML/A, laparallel cache carga los datos de la memoria secundaria y el proceso cold start seinicia en un segundo plano, construyendo la cache de Mondrian. Los usuarios pue-den acceder al servidor Mondrian de manera concurrente y lanzar peticiones MDX

73

3. Contribuciones

para la obtención de información multidimensional. Si estos datos agregados no seencuentran ni en la cache de Mondrian ni en la parallel cache, se generan peticionesSQL para obtenerlos de la base de datos relacional subyacente. Estos datos, ademásde constituir la respuesta a la petición del usuario, también se guardan en la parallelcache para futuras peticiones. El administrador del sistema Mondrian puede invocaren cualquier momento el proceso Store para guardar el contenido actual de la para-llel cache en la memoria secundaria. Una posible extensión de esta implementaciónpodría ser incorporar una tarea periódica que automáticamente llevase a cabo elalmacenamiento en memoria secundaria (por ejemplo, guardar en disco la parallelcache diariamente).

Esta técnica mejora notablemente el rendimiento del proceso cold start. Reduce eltiempo de ejecución del script XML de sentencias MDX en un orden de magnitud.Ante la ausencia de información en la cache de Mondrian, el proceso de cold start,que implica la ejecución de dicho conjunto de peticiones MDX, tarda del ordende horas (incluso días para almacenes de datos excepcionalmente grandes). Con latécnica de parallel cache, el tiempo se reduce a minutos. La figura 3.12 compara eltiempo de respuesta utilizando o no la técnica de parallel cache, para un conjuntode sentencias MDX, por años.

El consumo de memoria principal del servidor Mondrian es una cuestión crítica.Mondrian necesita un gran espacio en memoria principal para albergar la cache, yen nuestro caso también para la parallel cache. Si se utiliza Mondrian con servidoresweb como Tomcat [Tomcat, WWW] o JBoss [Jboss, WWW], el administrador hade dimensionar correctamente el espacio de la pila de memoria Java (java heapspace), tanto sus valores iniciales como el valor máximo que se puede alcanzar. Unabuena estrategia para establecer estos valores es tomar como referencia el tamañoque ocupa el fichero que alberga la parallel cache en memoria secundaria.

La clase ServletColdStart cuenta también con una funcionalidad que permite re-frescar la cache de Mondrian, dependiendo de un parámetro temporal. Para elloutiliza la API de control de cache (versión 2.3 de Mondrian), que permite refrescarsegmentos de cache. Éstos pueden modificarse o eliminarse completamente. El ad-ministrador de Mondrian tiene, por tanto, la posibilidad de elegir un eje temporalpara forzar el refresco de los datos agregados relacionados. Estos datos se refrescanagregando información de la RDBMS. El servlet sigue los siguientes pasos para elrefresco de la cache de Mondrian:

Libera los segmentos asociados al eje temporal elegido de la cache de Mondrian.Elimina las entradas de la parallel cache asociadas a los segmentos eliminadosen el paso anterior.Lanza el proceso de cold start, que permitirá cargar los datos agregados eli-

74


Figura 3.12.: Tiempo necesario para construir la cache de Mondrian mediante elproceso cold start (tomado de [Sendin-Raña et al., 2009]).

75

3. Contribuciones

minados. Si la respuesta a las peticiones MDX se encuentra en la cache deMondrian (o en la parallel cache), no se efectúan cambios ni se accede a labase de datos relacional. Si no se encuentra en alguna de las dos memorias detipo cache, Mondrian obtiene datos agregados actualizados de la RDMBS ylos introduce en la ambas memorias cache.Almacena el nuevo contenido de la parallel cache en memoria secundaria.

Todos estos pasos se ejecutan en segundo plano, asegurando el acceso concurrente alos datos del sistema OLAP. Los métodos de la API de control de cache de Mondrianaseguran la consistencia en todo este proceso. Desde el punto de vista del usuarioo del administrador, el proceso es atómico, y se asegura la consistencia de los datosagregados en todo momento. La parallel cache también asegura el acceso concurrentea datos consolidados.

3.1.5. Conclusiones

En el apartado 3.1.4 se ha explicado el proceso denominado cold start, diseñadopara conseguir un sistema ROLAP eficiente de código abierto. Esta propuesta solu-ciona los problemas de diseño y mantenimiento derivados del uso de las tablas devistas agregadas en los almacenes de datos subyacentes a los sistemas ROLAP. Conel proceso cold start el sistema de cache de Mondrian exhibe tiempos de respuestarápidos en cualquier situación, manteniendo la integridad en los datos.

El proceso cold start permite cargar las vistas de datos agregados en una cacheespecial, llamada parallel cache, y consigue tiempos de respuesta aceptables, inal-canzables sin alguna técnica de agregación (es decir accediendo directamente a lainformación base). Se garantiza una elevada calidad de servicio, ya que se aseguraque, ante caídas del sistema, los tiempos de recuperación serán muy rápidos. Ade-más, con este método también se asegura la consistencia de los datos agregadosdurante la actualización de la base de datos relacional subyacente.

En el apartado 3.1.3 se ha presentado una funcionalidad que permite evitar decla-raciones repetitivas en las sentencias MDX y en los esquemas Mondrian, gracias alas dimensiones calculadas. Este tipo especial de dimensión permite generar nuevasmedidas calculadas en tiempo real y con unas operaciones sencillas muy intuitivas(operaciones de tipo crossjoin). De este modo, es posible obtener respuestas a pe-ticiones complejas sin rediseñar el cubo multidimensional (introducir un conjuntomuy amplio y difícil de mantener de medidas calculadas), o sin introducir en cadapetición MDX largas definiciones de miembros calculados. Además de no afectar alrendimiento del sistema, las sentencias MDX que utilizan las dimensiones calculadassiguen cumpliendo el estándar.

76

3.2. Sistemas de Inteligencia de Negocio basados en Associative Query Logic

3.2. Sistemas de Inteligencia de Negocio basados enAssociative Query Logic


Se persigue la creación de una herramienta de gestión eficiente con capacidad deextraer datos almacenados en bases de datos de gran tamaño, y codificarlos como unconjunto de datos comprimidos en memoria principal para, posteriormente, poderrecuperarlos ante peticiones de un usuario (desde un panel de control de BI), contiempos de respuesta muy rápidos.

Se ha perseguido construir una herramienta de código abierto. Existen otros pro-ductos de Inteligencia de Negocio open source que han tenido éxito, como por ejem-plo Pentaho [Pentaho, WWW] o JasperSoft [Jaspersoft, WWW]. Sin embargo, estosproductos software orientados a sistemas OLAP no cumplen los requerimientos de al-tas prestaciones de partida. Al publicar nuestra contribución [Sendin-Raña et al., 2010],no existían soluciones de código abierto basadas en AQL o en el modelo de DataCloud.

3.2.2. Solución web de Inteligencia de Negocio basada en AQL

3.2.2.1. Cuadro de mando integral

El proyecto Pesca Fresca perseguía unas funciones específicas de cuadro de mandointegral o panel de control (dashboard) que se traducían en una serie de demandas alas capas inferiores, al motor de la solución web de BI. A continuación describimoscada uno de los objetos identificados y las características que deben cumplir:

Listados y tablas. Objetos que presentan, en forma de lista o tabla, datos.• Los listados contienen información no repetida almacenada en la base de

datos. Permiten aplicar filtros. Debe existir la posibilidad de ordenacióny de herramienta de búsqueda de valores concretos sin inspeccionar todoel objeto.

• Las tablas contienen información en formato matricial de dos o más co-lumnas de una o más tablas de la base de datos.

Gráficos. Permiten analizar de forma visual la información. Suelen presentartendencias, máximos, mínimos o cualquier alteración en el comportamiento,sin dejar de lado el detalle. Existen varios tipos:

• Barras.

77

3. Contribuciones

• Dispersión.• Lineal.• Radar.• Semáforo.• Tarta.• Velocímetro.

Deben poseer funciones de filtrado, para dotarles de versatilidad y funcio-nalidad. El filtrado se realiza mediante la selección con el ratón de aquellosdatos, sobre la gráfica, que queramos visualizar en detalle. Además, este tipode operaciones permiten ir descendiendo por el nivel de una jerarquía dada.Por ejemplo, si tenemos los datos en forma de gráfica de ventas por años, selec-cionando un año se deben poder consultar de forma automática las ventas deese año, por meses. Seleccionando más tarde uno de esos meses, se visualizarála misma gráfica de las ventas de ese año y de ese mes, por días. El procesoinverso también ha de ser posible.Botones: Acciones de rehacer, deshacer y eliminar filtros.Informes: Generación de documentos estructurados a partir de los datos pre-sentes en el cuadro de mando.Alertas: Para avisar al usuario cuando suceda algún evento. Será posible definirtantas alertas en el cuadro de mando como sea necesario. Existen dos tipos dealertas:

• Aviso emergente.• Envío de correo electrónico o mensaje instantáneo.

Marcadores: Funcionalidad que permite guardar el estado actual de un cuadrode mando. Tras una serie de acciones (definición de elementos del cuadro demando, aplicación de filtros, etc.) se podrán guardar los metadatos necesariospara recuperar esa configuración en el futuro.

3.2.2.2. Arquitectura orientada a servicio

Deseamos que nuestra solución proporcione un entorno para la publicación einvocación de servicios de BI a través de la red (mediante web). Además pre-tendemos que la aplicación web del lado del cliente sea muy visual, con aspectoatractivo, y que incorpore tecnologías web extendidas y maduras. Por estos mo-tivos, nuestra arquitectura de servicios web sigue el patrón MVC (Model-View-Controller) [Booth et al., 2004]. Más específicamente, nuestra solución utiliza Java

78


Struts [Struts, WWW], un entorno de desarrollo para aplicaciones web de códigoabierto.

Se proporciona la interactividad necesaria en la parte de cliente mediante tecno-logías AJAX (Asynchronous JavaScript and XML) [Murray, WWW]. AJAX es unmodelo de desarrollo web muy importante y ampliamente extendido para aplica-ciones basadas en navegadores web. El cliente también consume páginas JSP (JavaServer Pages) [JSP, WWW] para atender las peticiones iniciales al servidor web (ennuestro caso, Tomcat [Tomcat, WWW], un servidor Java).

La comunicación entre cliente y servidor se realiza mediante mensajes SOAP[SOAP, WWW] (para petición y respuesta). Cuando el cliente recibe una respuestaSOAP, la transforma y la presenta en el navegador. Para un adecuado acondicio-namiento de estas respuestas, se utiliza la tecnología CSS (Cascade Style Sheets)[CSS, WWW].

Los mensajes de petición SOAP, que el cliente genera hacia el servidor, se definenmediante el esquema XML de la figura 3.13.

Los mensajes de respuesta SOAP que recibe el usuario del servidor se definenmediante el esquema XML de la figura 3.14.

En el servidor se ha implementado la solución con tecnología Java. Es un lenguajeinterpretado, y por lo tanto no resulta óptimo en términos de tiempo de respuestao memoria principal consumida. Sin embargo, ofrece algunas características queson muy importantes para nuestro proyecto. Además de perseguir una aplicaciónmuy interactiva, altamente visual, que se ejecute en navegadores web, también sedemanda que proporcione características de privacidad, persistencia y seguridad. Eneste contexto, las ventajas que nos aporta la tecnología Java son:

Seguridad y robustez a través de:• Un potente manejo de excepciones.• Un eficiente gestor de asignación de memoria.• Un depurador de errores de alta calidad.• Mecanismos automáticos de recolección de basura (memoria principal).

Independencia de plataforma y portabilidad de código.Soporte por parte de una comunidad amplia y activa.Disponibilidad de una enorme colección de bibliotecas. Facilidad a la hora decrear aplicaciones que integran de manera sencilla un conjunto de aplicacionesdesarrolladas anteriormente con la tecnología Java.

Aun así, una aplicación de BI desarrollada en Java puede alcanzar un rendimiento

79

3. Contribuciones

<element name="getDataRequest"><complexType><sequence><element name="idUser" type="int"/><element minOccurs="0" name="filter"><complexType><attribute name="case" type="string" use="required"/><attribute name="restricted" type="boolean" use="required"/>

</complexType></element><element maxOccurs="unbounded" minOccurs="0" name="object"><complexType><sequence><element name="id" type="string"/><element minOccurs="0" name="field" type="string"/><element minOccurs="0" name="idMatrix" type="string"/><element minOccurs="0" name="classification" type="string"/><element minOccurs="0" name="varCalculation" type="string"/><element minOccurs="0" name="calculation"><complexType><sequence><element maxOccurs="unbounded" minOccurs="0" name="expression"><complexType><simpleContent><extension base="string"><attribute name="dim" type="string" use="required"/>

</extension></simpleContent>

</complexType></element>

</sequence></complexType>

</element><element minOccurs="0" name="filters"><complexType><sequence><element maxOccurs="unbounded" minOccurs="0" name="filter" type="string"/>


</element><element minOccurs="0" name="order" type="string"/><element minOccurs="0" name="sizePag" type="string"/><element minOccurs="0" name="numPag" type="int"/><element minOccurs="0" name="nulls" type="boolean"/>

</sequence><attribute name="new" type="boolean" use="optional"/><attribute name="filterAction" type="boolean" use="optional"/>



</element>

Figura 3.13.: Esquema que define las peticiones SOAP.80


<element name="getDataResponse"><complexType><sequence><element minOccurs="0" name="filters"><complexType><attribute name="case" type="string" use="required"/>

</complexType></element><element maxOccurs="unbounded" minOccurs="0" name="object"><complexType><sequence><element name="id" type="string"/><element minOccurs="0" name="text" type="string"/><element minOccurs="0" name="idMatrix" type="string"/><element maxOccurs="unbounded" minOccurs="0" name="classification"><complexType><simpleContent><extension base="string"><attribute name="field" type="string" use="optional"/>

</extension></simpleContent>

</complexType></element><element minOccurs="0" name="expression" type="string"/>

</sequence><attribute name="new" type="boolean" use="required"/>



</element>

Figura 3.14.: Esquema que define las respuestas SOAP.

81

3. Contribuciones

aceptable en términos de consumo de memoria principal y de tiempos de respuesta.En este trabajo doctoral no hemos buscado superar un producto comercial comoQlikView, sino conseguir una herramienta de código abierto, portable, basada en laweb, con un rendimiento comparable.

Durante el desarrollo de este trabajo doctoral se identificaron algunos errores enla descripción teórica del algoritmo de AQL y Data Cloud, así como en el productocomercial derivado. Se describen en detalle en los subapartados 3.2.2.4 y 3.2.2.5.

3.2.2.3. Diseño

La figura 3.15 muestra el diseño global de la solución web de BI con almacén dedatos en memoria para Pesca Fresca.

Figura 3.15.: Diseño global de la solución web de BI con almacén de datos enmemoria.

Se desglosa en la figura 3.16, donde se detalla la comunicación entre el cliente yel servidor, así como los módulos asociados a esos intercambios de información.

82


Figura 3.16.: Diseño detallado de la solución web de BI con almacén de datos enmemoria.

83

3. Contribuciones

Se desarrollaron los siguientes módulos:

Módulo de Autenticación, con el framework Struts 1.3. Existen dos tipos deroles: administrador (AD) y usuario básico(UB). Se emplea una autenticaciónmediante login/password con protocolo SSL.Módulo de Conexión a los Orígenes de Datos. Permite acceder a diferen-tes tipos de orígenes de datos (varios RDBMS o ficheros planos con estructuramatricial). Centrándonos en el acceso a RDBMS, se accede a la BBDD para laextracción de la información referente a la estructura y datos (tablas y camposde dichas tablas). Este módulo sólo lo utiliza el AD. Se subdivide en:

• Definición del formato SOAP (estructura) para petición y respuesta. Laspeticiones contienen siempre información para la autenticación frente alorigen de datos cuando es necesario. Las peticiones son, en el caso debases de datos, referentes a las tablas a procesar y los campos de interésde cada una de ellas. Las respuestas contienen, típicamente, listados conla información solicitada.

• Introducción del tipo de origen de datos, y de ser necesaria, informaciónde autenticación. Esta información reside en el cliente (obtenida del AD através de un cuadro de diálogo) y se utiliza en los mensajes que se envíanal servidor.

• Conexión al origen de datos. Este submódulo realiza todas las tareas delmódulo y también las tareas del módulo de carga.

• Petición de información de la estructura del origen de datos, para gene-ración automática del script de carga. Un ejemplo de este script se puedeconsultar en el anexo B.

Módulo de Carga de Datos. Carga en memoria de manera eficiente lainformación del origen de datos seleccionado en el Módulo de Conexión a Orí-genes de Datos. La prioridad es minimizar el espacio en memoria y agilizar lostiempos de consulta de esos datos. La carga de datos se subdivide en:

• Definición del formato SOAP de la petición de carga y de la respuesta.Las peticiones contienen el script de carga (ver anexo B), mientras quelas respuestas contienen la información necesaria para determinar si elproceso tuvo éxito o no.

• Procesado de la petición de carga. Esta subtarea se encarga de interpretarla petición de carga y traducirla a acciones necesarias para la obtención delos datos (por ejemplo, en caso de bases de datos, de generar las sentenciasSQL necesarias).

• Almacenamiento del script de carga en la base de datos.

84


• Ejecución de carga de datos.• Procesado de la respuesta del origen de datos. Es necesario optimizar los

datos obtenidos en el paso anterior para mejorar la utilización de espacioen memoria y la rapidez ante consultas a esos datos en memoria.

Se genera desde el cliente un mensaje SOAP cuyo contenido es el script decarga. En el Módulo de Carga de Datos se procesa dicho mensaje extrayendoel script y generando las sentencias SQL necesarias. Los datos resultantes seprocesan para obtener una estructura en memoria eficiente desde el punto devista del tamaño y la rapidez de acceso. Tras ello, el servidor envía un mensajeSOAP únicamente para indicar si carga fue procesada con éxito o si huboalgún error.Módulo de Procesado de Peticiones. Permite atender las peticiones deusuarios de análisis de los datos previamente cargados en memoria. La gene-ración y demanda de peticiones vienen motivadas por la carga inicial de lainterfaz gráfica, por una acción del usuario en alguno de los controles de lainterfaz gráfica, o por la utilización de marcadores. El procesado de peticionesse subdivide en:

• Definición del formato SOAP para la petición de datos y respuesta.• Procesado de la petición. Interpretación de los datos solicitados sobre la

información residente en memoria.• Búsqueda de resultados, eficiente, con tiempos de respuesta aceptables

(del orden de un segundo).• Construcción de respuesta SOAP indicando el estado del proceso.

Una vez se dispone de la estructura con los datos almacenada en la memoriaRAM, se pueden dar las siguientes situaciones:

• El UB o AD selecciona una de las interfaces de usuario disponibles. Elsistema ya dispone de la estructura almacenada en la RAM del servidor y,por tanto, de forma transparente al usuario, realiza la petición de los da-tos acorde a los objetos que forman la interfaz seleccionada. La peticiónSOAP es lo suficientemente potente para asociar los distintos elemen-tos/objetos de la interfaz con los datos que se deben mostrar. Una vezprocesada la petición en el servidor, la respuesta SOAP asocia los datoscon los objetos.

• Selección de alguno de los datos en la interfaz de usuario. Esto impli-ca que estamos aplicando un filtro que limita los datos a mostrar. Porello, se genera una petición SOAP al servidor y las respuestas SOAP lasprocesarán los clientes.

85

3. Contribuciones

• Uso de los marcadores. Consiste, en definitiva, en aplicar varios filtros deforma simultánea.

Módulo de Almacenamiento de Configuraciones. Se encarga de guardaren la base de datos toda la información referente a la configuración de lasinterfaces de usuario creadas por el AD, los marcadores que cada usuario hadefinido, el script de carga generado, etc. Cada vez que se genera, elimina omodifica un script de carga, una interfaz de usuario o un marcador, es necesarioque dichos cambios queden registrados en la base de datos de la aplicación,para que en usos futuros se disponga de datos actualizados. El almacenamientode configuraciones se subdivide en:

• Definición del formato SOAP para el envío de la información a almacenary la respuesta.

• Procesado de la información a almacenar. Extracción de la informacióncontenida en el mensaje, script de carga, configuración de la interfaz, etc.,para almacenarla en las tablas correspondientes de la base de datos.

• Construcción de la petición SOAP con la información necesaria y la res-puesta, también SOAP, indicando el éxito o fracaso del proceso.

Módulo de Interfaz de Usuario. Define las funcionalidades de la interfazgráfica que permiten la creación de controles, tablas y gráficas, y las accionesrelacionadas con ellos. Además, engloba tareas relacionadas con la generacióny envío de determinadas peticiones SOAP a los distintos módulos. Podemossubdividirlo en:

• Definición de objetos gráficos (listas, tablas, gráficas) y sus propiedades.• Control de eventos. Submódulo de decisión de petición de datos al servi-

dor ante eventos (puede ser o no necesaria esta petición al aplicar filtrosen el interfaz gráfico, seleccionar elementos en las tablas, etc.).

• Definición del formato de la interfaz gráfica. Este formato reside en labase de datos y está asociado a los usuarios registrados.

• Carga de la interfaz gráfica (definida por AD).• Creación del mensaje SOAP para la petición de la estructura de la BBDD

a procesar al Módulo de Conexión de Origen de Datos. Exclusivo para elAD.

• Creación del mensaje SOAP para la petición de la carga al Módulo deCarga de Datos. Exclusivo para el AD.

• Creación del mensaje SOAP de petición de datos al servidor (Módulo deProcesado de Peticiones).

86


• Creación del mensaje SOAP de envío de las configuraciones al Módulo deAlmacenamiento de Configuraciones.

• Procesado del mensaje SOAP de respuesta del servidor para cada uno delos casos anteriores.

• Creación de marcadores y su almacenaje en la base de datos (utilizandoSOAP). Los marcadores se emplean para guardar un estado determina-do de la interfaz gráfica (determinado por filtros u otros elementos). Sealmacenan en la base de datos, asociados a cada usuario, mediante unapetición SOAP. Los marcadores iniciales se cargan en la fase de autenti-cación de un UB, y se incorporan a la interfaz gráfica para permitir queel UB los seleccione.

3.2.2.4. Mejoras del algoritmo: Carga y almacenamiento de datos eficiente

QlikView toma de sus diferentes fuentes de datos las columnas de información ylas renombra con un alias. De acuerdo con la descripción de QlikView publicada en[QlikTech:1, 2000], la misma columna de datos puede renombrarse varias veces condiferentes alias. Los datos de la columna original se cargan en memoria para cadanuevo alias, generándose información redundante. La columna de datos original secarga en memoria tantas veces como alias referencien a esa columna en el sistema.

Las columnas se almacenan en la memoria principal con diferentes identificadores,los alias antedichos. Este método permite que múltiples columnas cargadas desdela fuente de datos sean completamente independientes desde el punto de vista dela aplicación, aun cuando en la fuente de datos fueran la misma. De este modo, unfiltrado de una de estas columnas no afectará al resto. Sin embargo, la carga de datosduplicados no es eficiente: se utiliza más espacio en memoria principal y afecta alrendimiento en términos de tiempo necesario para cargar varias veces los mismosdatos. Debemos considerar que hablamos de columnas que pueden implicar millonesde registros.

Pongamos un ejemplo. Imaginemos que queremos mostrar la información de de-terminados clientes y sus ventas asociadas en el cuadro de mandos integral. Pero,además, queremos que se nos muestren los diez clientes más deudores. En este casono queremos que el primer filtro aplicado a los clientes afecte a la gráfica del topten: es necesario disponer de un identificador de clientes para aplicar el filtro, y deotro para la gráfica.

A priori la manera de proceder más sencilla es generar dos entradas en la estructurade tabla binaria, para contener a los clientes top ten y a los clientes que se usaránpara el filtro. Ésta es la forma de proceder de [QlikTech:1, 2000]. El problema surgecon la duplicidad de la información de la estructura de datos final: las dos columnas

87

3. Contribuciones

(clientes top ten y clientes filtro), a pesar de considerarse campos distintos, contienenlos mismos datos de origen.

Nuestra implementación elimina este inconveniente. La idea consiste en identificarlos nombres de columna que se toman de la fuente de datos y los alias que seutilizan para renombrar esas columnas, además de aplicar diferentes filtros. Portanto, debemos definir un vector con los nombres de los tipos de elementos de datos(vector de nombres) y otro vector para los correspondientes alias (vector de alias).Es necesario establecer la relación entre estos dos vectores para identificar los aliasque corresponden a cada nombre original.

Dado que el vector de nombres representa la estructura de columnas de la tablabinaria, y que permite compartir la información de los mismos identificadores decolumna, se decide crear una tercera estructura. Esta nueva estructura tiene en cadaregistro los nombres de las columnas y sus alias. Las columnas de datos binarios estánenlazadas a las tablas de asociación, y por esta razón también es necesario definirla conexión entre los alias y sus correspondientes tablas de asociación.

Si se desea aplicar filtros de manera independiente a los datos que provienen de lamisma columna original, se debe asignar para cada alias un vector de selección, deestado y de frecuencia diferente. Al tomar esta decisión de diseño, el estado de unacolumna de datos codificados en memoria principal puede diferir del estado de otracolumna de datos codificados también en memoria principal, pero las dos resultande la lectura de la misma columna en la fuente de datos. Esencialmente, esto esposible porque existen diferentes vectores de estado.

Figura 3.17.: Diseño de la metodología para la reducción del tiempo de carga y delespacio en memoria principal (tomado de [Sendin-Raña et al., 2010]).

88


ID Nombre1 Mark2 JohnID Edad1 27

Cuadro 3.1.: Tablas nombre y edad.

ID1 02 1

Cuadro 3.2.: Tabla de correspondencia binaria para los valores de ID.

La figura 3.17 ilustra esta metodología. Se representan los vectores de nombre, losvectores de alias con los registros asociados, y una tabla binaria donde se definenlas asociaciones entre los dos vectores. Esta solución, al evitar cargar las columnasde datos originales varias veces, reduce el tiempo de carga de datos de las fuentesde datos a la memoria principal, y reduce también el espacio en memoria principalnecesario.

3.2.2.5. Mejoras del algoritmo: Establecimiento de un orden en lacomprobación de tablas

Podemos encontrarnos con que el proceso de filtrado de datos de la metodología deAQL y de Data Cloud no tiene siempre el rendimiento descrito en [QlikTech:1, 2000,QlikTech:2, 2001, QlikTech:3, 2006]. De hecho, esta descripción tan sólo funciona enun número reducido de casos. Explicaremos esta afirmación con un ejemplo.

Las tablas que muestra el cuadro 3.1 (cada una con dos columnas) representannombres de personas y sus edades. Ambas tablas están relacionadas por la columnaID, y hay tres columnas diferentes: ID, Nombre y Edad. El cuadro 3.2 muestra lacorrespondencia entre los valores y su codificación binaria para ID, el cuadro 3.3para Nombre y el cuadro 3.4 para Edad. En este simple escenario podemos pedir elnombre y la edad de una persona así como su número ID y las relaciones entre ellas.

NombreMark 0John 1

Cuadro 3.3.: Tabla de correspondencia binaria para los valores de nombre.

89

3. Contribuciones

Edad27 0

Cuadro 3.4.: Tabla de correspondencia binaria para los valores de edad.

Seleccionando uno de los valores de una columna podemos obtener la informaciónrelacionada de las otras dos columnas. Si, por ejemplo, quisiésemos conocer el nombrey la edad de la persona con ID #1, después de efectuar el algoritmo de filtrado, senos mostraría que el nombre correspondiente es “Mark” y su edad “27”. El contenidode los vectores de estado sería:

Para ID: <1,0>Para Nombre: <1,0>Para Edad: <1>

Los contenidos de los vectores de estado son coherentes con el resultado esperado.Si ahora seleccionásemos el ID #2 (vector de selección <0,1>) el resultado es-

perado sería que se nos mostrase el nombre “John” y ninguna edad. Es decir, elcontenido de los vectores de estado debería ser:


Sin embargo, el conjunto de vectores estado que se obtienen después de apli-car el algoritmo publicado en la descripción [QlikTech:1, 2000, QlikTech:2, 2001,QlikTech:3, 2006] difiere de este resultado esperado. Analicemos, pues, la evoluciónde los contenidos de los vectores de estado y vectores de frecuencia a través delproceso de filtrado.

En primer lugar, el contenido del vector de selección correspondiente a ID secopia en su vector de estado. Después el algoritmo comprueba la primera tabla,actualizando su vector de frecuencia. Existe una coincidencia para la entrada conID #2, por lo que es necesario actualizar los vectores de estado de ID y Nombre,una vez finalice la comprobación de la tabla. Los nuevos vectores de estado son:

Para ID: <0,1>Para Nombre: <0,1>

Pasando a la segunda tabla, se deben usar ahora los vectores de estado asociadosa ID y Edad. El vector de estado para ID ha cambiado a <0,1>, y el vector deestado para Edad se mantiene en el valor <1>. Después de comprobar esta segunda

90


tabla, y dado que no se ha encontrado ninguna coincidencia con ningún registro (sebuscaba ID #2), los vectores estado toman los siguientes valores:

Para ID: <0,0>Para Edad: <0>

En este punto, todas las tablas han sido comprobadas, pero al menos un vectorde estado ha modificado su valor, por lo que el algoritmo ha de ejecutarse de nuevo,utilizando los nuevos valores de los vectores de estado.

Reiniciamos las comprobaciones de las tablas empezando por la primera tabla.Tenemos que los valores de los vectores de estado son:


Después de comprobar los registros de esta tabla, el vector de estado asociado aNombre pasa a tomar el valor <0,0>. Repitiendo el proceso en la segunda tabla, losvectores de estado no varían, manteniéndose los valores:

Para ID: <0,0>Para Edad: <0>

De nuevo, una vez el algoritmo comprueba todas las tablas, verifica si se ha mo-dificado el contenido de algún vector de estado. Como así ha sido, se realiza unatercera fase de comprobación de las tablas del sistema. Tras esta última comproba-ción, que no modifica los valores de los vectores de estado para ID, Nombre y Edad,el algoritmo finaliza. Informa que no existen resultados asociados al ID #2, lo que,obviamente, no es un resultado válido. El valor obtenido debería haber sido:


En nuestro análisis del algoritmo descubrimos que el problema asociado a estetipo de casos se debía a la segunda tabla, la cual no cuenta con todas las entradasde la primera, pues no posee una entrada para el registro con ID #2. Después decomprobar esta tabla, el vector de estado para ID cambia, perdiendo la informa-ción que referencia al ID #2. Cuando se visita de nuevo la primera tabla para sucomprobación, el nuevo contenido del vector de estado genera este error.

Por tanto, podemos concluir que cuando se utiliza el algoritmo tal y como estádescrito en [QlikTech:1, 2000, QlikTech:2, 2001, QlikTech:3, 2006], si una de las ta-

91

3. Contribuciones

blas del sistema no contiene todos los diferentes datos que puede tomar una columnaen el sistema, y la selección del usuario atañe a esa columna, el resultado obtenidodifiere del resultado esperado. Esto se produce independientemente del orden en elque recorramos las tablas para su comprobación.

Este mal funcionamiento puede ser remediado introduciendo cambios en el algo-ritmo de filtrado. La idea es establecer un orden descendente para la comprobaciónde las columnas y mantener los valores de los vectores de estado (asociados a lascolumnas que conectan tablas) invariables. El algoritmo debe crear una estructurade árbol con un nodo raíz y varios nodos finales que puedan alcanzarse desde el nodoraíz, directamente o mediante múltiples conexiones con otros nodos).

El primer paso consiste en identificar el nodo que actuará como nodo raíz (tablainicial). Este nodo raíz contendrá la columna de datos que está asociada al valorseleccionado. Si esta columna está presente en varias tablas (es una columna que lasrelaciona), se puede escoger cualquiera de estas tablas como nodo raíz.

Tras determinar el nodo raíz, o tabla inicial, el siguiente paso consiste en identi-ficar las relaciones entre esta tabla y las otras tablas presentes en el sistema. Comohemos visto, dos tablas están relacionadas si comparten una columna con el mismoidentificador. Por tanto, el algoritmo escogerá cualquier tabla con una columna dedatos que comparta nombre con la tabla inicial. Y será la siguiente en el proceso decomprobación del algoritmo de filtrado. En caso de que existan varias tablas en esteprimer nivel (con alguna columna compartida con el nodo raíz), cualquiera de ellasse podrá seleccionar sin pérdida de funcionalidad.

En este punto, el algoritmo debe determinar si la tabla actual corresponde aun nodo final o a un nodo que conecta a otras tablas. Las tablas finales tan sólocomparten una columna de datos con otra tabla del sistema, que es la que conectaa dicha tabla con el nodo de nivel superior. Por otro lado, un nodo que conecta aotras tablas tiene varios enlaces, esto es, dos o más columnas de datos compartidascon otras tablas del sistema. Como mínimo dos, una para conectar con el nodo delnivel inferior, y una o varias para conectar con el nodo o nodos del nivel inferior.Es importante recalcar que un nodo de conexión, al seguir la estructura de árbol,puede tener varios enlaces hacia nodos inferiores, pero tan sólo uno para enlazar conel nivel superior. En caso contrario estaríamos hablando de otro tipo de estructuras,que permiten bucles.

Si la tabla no es un nodo de conexión, se sigue el procedimiento hasta que seencuentra un nodo final. Esto se realiza en vez de primero seleccionar todos los nodosdel mismo nivel y después continuar en el siguiente o siguientes niveles. Sin embargo,el algoritmo se comporta correctamente, independientemente de la estrategia queelijamos para recorrer la estructura en árbol.

Una vez el nodo final se alcanza, y el algoritmo actúa sobre esa tabla, se recorre el

92


camino de vuelta hasta que encuentra un nivel con alguno de los nodos sin visitar.Después el algoritmo recorre los nodos que dependen de ese nodo de conexión hacianiveles inferiores, y una vez finaliza, vuelve a repetir el proceso subiendo por la rutahasta que todas las tablas hayan sido visitadas.

Una vez el proceso finaliza por completo, se conoce el orden correcto del recorridopor las tablas del sistema (como hemos explicado, seguimos un esquema de secuenciaque recorre primero los niveles inferiores), al igual que las columnas de datos quedefinen las relaciones entre las distintas tablas. Esta información es importante,ya que con nuestro algoritmo, mientras se está comprobando una tabla, todos losvectores de estado pueden cambiar, exceptuando aquellos que definen el orden derecorrido correcto. Éstos son el vector de estado del valor seleccionado en la tabladel nodo raíz y los vectores de estado de las columnas de datos que conectan elresto de las tablas con la tabla del nivel inmediatamente superior. Estos vectoresde estado deben mantener la información invariable mientras se comprueba la tablacorrespondiente, pero podrán modificarse si están contenidos en otra tabla.

A continuación se explica el funcionamiento de este nuevo algoritmo mediante unejemplo. Consideremos las tablas que presenta el cuadro 3.5. Son cinco, y tres de ellasestán relacionadas por el campo Nombre. Además, una de estas tres está conectada alas otras dos por el campo Estudios. Se selecciona el valor “John” para este ejemplo.Podemos observar que la columna de datos que contiene el valor seleccionado estápresente en tres de las tablas. Por tanto, un orden correcto para recorrer estas tablaspodría ser (a)-(b)-(d)-(e)-(c). El valor seleccionado por el usuario está en color azul,y los resultados del proceso de filtrado están en color verde.

Tras la comprobación de la tabla (a) del cuadro 3.5, los vectores de estado corres-pondientes a esa tabla tienen los siguientes valores:

Para Nombre: <1,0,0>Para Edad: <1,0>

El vector de estado correspondiente a Edad cambia, pero no así el correspondientea Nombre. Después se pasa a comprobar la tabla (b) del cuadro 3.5. La columna dedatos Nombre conecta las dos tablas, por lo que debe mantenerse inalterable. Detodos modos, como el vector de estado actual es el vector de selección del usuario,tampoco cambiaría. Sin embargo, el vector de estado correspondiente a Estudiosmodifica su valor:

Para Estudios: <1,0,0,0>Sin mayores complicaciones se comprueban las tablas (d) y (e) del cuadro 3.5 (en

ese orden), y el resultado de aplicar el algoritmo produce el siguiente resultado paralos vectores de estado relacionados:

93

3. Contribuciones

(a)Edad Nombre

25 John27 Anna

(b)Nombre Estudios

John MedicinaAnna QuímicaMaría -

(c)Residencia Nombre

Paris AnnaRome María

(d)Semestres Estudios

6 Medicina7 Ingeniería6 Física

(e)Cursos Estudios

A MedicinaB MedicinaC FísicaA FísicaA QuímicaD Química

Cuadro 3.5.: Tablas para un ejemplo de operación del nuevo algoritmo.

Nombre Edad Residencia Estudios Semestres Cursos<1,0,0> <1,0> <0,0> <1,0,0,0> <1,0> <1,1,0,0>

Cuadro 3.6.: Valores finales de los vectores de estado.

94


Para Semestres: <1,0>Para Cursos: <1,0,0,0>

El último paso consiste en comprobar la tabla (c) del cuadro 3.5. El vector deestado para Nombre cambiaría a <0,0,0,0>, ya que el valor “John” no aparece enesta tabla, y las otras posiciones del vector ya tenían el valor 0. Sin embargo, dadoque esta es la columna de datos que conecta las tablas, debe permanecer inalterada,el vector de estado para Nombre se mantiene como <1,0,0,0>. El vector de estadopara Residencia cambia a <0,0>.

Se puede concluir que, con la modificación que introducimos en nuestro algorit-mo, se puede llegar al resultado esperado. Es más, se consigue sin realizar variascomprobaciones en las mismas tablas cuando cambian los valores originales de losvectores. La tabla del cuadro 3.6 muestra los valores finales de los diferentes vectoresde estado del sistema.

Con esta modificación del algoritmo se puede aplicar de forma correcta cualquierotra combinación de filtrado, sin importar la complejidad asociada. Tan sólo sedebe considerar que, como en el algoritmo original, los filtrados con políticas másrestrictivas pueden aplicarse a partir de los valores actuales de los vectores de estado,mientras que los filtros menos restrictivos requieren una reiniciación de los vectoresde estado a sus valores iniciales.

3.2.2.6. Uso del algoritmo mejorado para la extracción de resultados

La información codificada y almacenada en memoria principal debe extraerse deforma eficiente para permitir la evaluación de funciones matemáticas en las tablasseleccionadas. La metodología presentada en [QlikTech:3, 2006] define los pasos ne-cesarios para identificar todas las tablas de tipo conexión y de tipo final, para se-leccionar la tabla de inicio, necesaria para iniciar el proceso de conversión y deevaluación de las funciones matemáticas para cada registro.

Sin embargo, el proceso de conversión genera una estructura de datos que no essiempre adecuada para el proceso de filtrado. Cuando los filtros de datos no son partede la estructura generada, los vectores de selección de esos filtros no se tienen enconsideración, y por tanto los resultados obtenidos no son los esperados. Además, sise implementasen todos estos pasos cada vez que el usuario realizase una selección,nuestro sistema comenzaría a experimentar largos retardos que, como ya hemoscomentado, son inaceptable para nuestros propósitos.

Nuestra propuesta considera los filtros en la estructura de datos que se crea paradar soporte a las tablas o gráficas que aparecen en la interfaz gráfica del usuario.En primer lugar, la aplicación del servidor obtiene las expresiones (las funciones

95

3. Contribuciones

matemáticas) a evaluar. Después, las variables de datos se clasifican según las dife-rentes dimensiones definidas. El siguiente paso es determinar el eje de la dimensióny su tamaño, y determinar el orden en que se van a recorrer las tablas implicadas.Una vez el algoritmo tiene toda esta información, y las variables están identificadas(para ello se crean estructuras de datos volátiles), el proceso de generación de rutase inicia, y se crea una nueva estructura codificada en binario.

El proceso de generación de ruta comienza por las tablas donde las variables dedatos han sido definidas, y finaliza en las tablas de dimensión. El usuario define estastablas de dimensión mediante la interfaz gráfica. De este modo se visitan todas lastablas de conexión y se recupera tan sólo la información relevante para las funcionesmatemáticas o funciones de filtrado.

Los datos codificados en binario, la información para la tabla o la representacióngráfica de la interfaz de usuario, se guardan en una estructura de datos eficiente.Esto evita una sobrecarga de memoria principal y permite tiempos de respuestamuy bajos ante cambios en la interfaz gráfica del usuario. Todos los posibles filtrosdefinidos en el panel de control o dashboard pueden seleccionarse en esta nuevaestructura de datos.

Figura 3.18.: Ejemplo de un script para la carga de datos desde una fuente de datosa la memoria principal (tomado de [Sendin-Raña et al., 2010]).

A continuación se muestran unas figuras que ayudan a entender este proceso.La figura 3.18 muestra un ejemplo de script de carga para la construcción de lasestructuras de datos en memoria. La figura 3.19 muestra un panel de control con treslistas en la parte izquierda, que permiten operaciones de filtrado, y con tres gráficos

96


Figura 3.19.: Ejemplo de un cuadro de mandos con tres listas para filtrado y tresgráficas (tomado de [Sendin-Raña et al., 2010]).

Figura 3.20.: Ejemplo de cuadro de mandos con filtrado por producto (tomado de[Sendin-Raña et al., 2010]).

97

3. Contribuciones

Figura 3.21.: Ejemplo de cuadro de mandos con filtrado por tienda. Se muestran enlas gráficas la información de ventas asociada a esa tienda (tomado de[Sendin-Raña et al., 2010]).

98


en las partes central y derecha. Como en esta vista no existen filtros aplicados porel usuario, en las gráficas se presenta toda la información agregada. La figura 3.20muestra las ventas de un producto por localizaciones, tras la selección en el filtrocorrespondiente de un producto dado. La figura 3.21 muestra otra configuración, elefecto de la selección de una tienda dada. Las listas de productos y de estados seven afectadas por la selección en el filtro de tiendas. Esto se debe a que el listadode productos y de estados asociado a esa tienda es más restrictivo que el original.También se muestra el efecto que produce esta selección en los gráficos de ventas.

3.2.3. Resultados numéricos

Hemos evaluado nuestra propuesta en términos de:

Tiempo de carga de datos desde memorias secundarias a memoria principal.Tiempo de búsqueda.Memoria principal consumida durante la ejecución.

Se toma a la aplicación QlikView como referencia para comparar el rendimientosegún estos parámetros. Hay que aclarar previamente una diferencia relevante: Qlik-View es una herramienta que se ejecuta de forma totalmente local. Sin embargo,nuestra propuesta es una aplicación orientada a web, implementada para dar sopor-te multiusuario. Esto introduce una penalización temporal debido al tiempo extraconsumido en los procesos de comunicación cliente-servidor.

La solución propuesta se probó en el siguiente entorno: el servidor era un equipoDell con un procesador AMD Athlon de 2.3 GHz y una memoria DDR2 SRAM de 2gygabytes. Como fuente de datos se eligió una base de datos relacional, más concre-tamente mySQL. Los paneles de control (dashboards) se probaron en los navegadoresmás populares:

Mozilla Firefox.Internet Explorer.Google Chrome.Opera.

El primer tipo de pruebas consistió en la comparación de los tiempos requeridospara la carga de datos en memoria principal desde las tablas de la base de datosrelacional que actuaba como fuente de datos. Definimos esta medida como el tiempoque transcurre desde que se recibe la petición de cargar datos en memoria principalhasta que se informa al administrador de que la carga de datos ha finalizado conéxito. La figura 3.22 muestra los tiempos de carga para diferentes scripts de carga

99

3. Contribuciones

(cada uno de ellos implica la carga de un número diferente de registros y tablas).En media, el tamaño de los datos cargados en memoria ocupaba 550 megabytes enel motor mySQL.

Figura 3.22.: Comparación entre los tiempos de carga entre nuestra propuesta yQlikView (tomado de [Sendin-Raña et al., 2010]).

En el segundo tipo de pruebas se midió el consumo de memoria principal de lasdos aplicaciones (QlikView y nuestra propuesta) tras la carga de datos en memoria.La figura 3.23 muestra los diferentes resultados, igual que en el caso anterior, paradiferentes scripts de carga que implican diferente número de registros en memoriaprincipal. Estos resultados dependen del número de registros que contienen valo-res repetidos, tipos de datos cargados en memoria principal, y número de registroscargados por el script. Aunque nuestra propuesta presenta unos consumos de me-moria superiores, consideramos que la diferencia es más que aceptable. Podemosadoptar esta posición dadas las premisas del proyecto original, que sabíamos penali-zarían de algún modo el rendimiento de la solución alcanzada: una implementaciónmultiplataforma, válida para cualquier sistema operativo, y con una arquitectura

100


cliente-servidor que permitiese soporte multiusuario desde cualquier ubicación. Deeste modo, numerosos usuarios pueden enviar peticiones desde diferentes ubicacio-nes al mismo servidor, y recibir resultados al mismo tiempo. Esto, globalmente,implica una mayor eficiencia del uso de memoria. Además, dado que el tamaño dela fuente de datos (en media) fue de 550 megabytes, la diferencia relativa entre lasdos aproximaciones es baja.

Figura 3.23.: Comparación del consumo de memoria principal entre nuestra pro-puesta y QlikView (tomado de [Sendin-Raña et al., 2010]).

La figura 3.24 muestra el consumo de memoria principal de nuestra propuestadurante el proceso de carga de datos. Se ha medido este consumo desde el momentoen que se recibe la orden de cargar los datos en las estructuras de la memoria internahasta que el administrador recibe un informe de que el proceso ha finalizado conéxito. El estado final del consumo de la memoria (73 megabytes) corresponde a unode los casos de prueba mostrados en la figura 3.23. Se puede observar en la figura3.24 un pico de consumo de memoria debido a la utilización de estructuras de datosintermedias en el proceso de carga de datos. Estas estructuras son necesarias para

101

3. Contribuciones

construir las tablas con los valores finales codificados en binario. Sin embargo, elcolector de basura de la JVM (Java Virtual Machine) libera este pico de memoria, altratarse de información temporal. Por ello cualquier servidor (nótese que las pruebasse han realizado con un hardware de gama baja) no debería tener ningún problemapara gestionar estos picos temporales.

Figura 3.24.: Consumo de memoria principal durante el proceso de carga de da-tos. El eje horizontal representa el tiempo transcurrido (tomado de[Sendin-Raña et al., 2010]).

La figura 3.25 ilustra la diferencia de consumo de memoria cuando se utilizan losalias en el proceso de carga de datos en memoria principal. Se muestra la mejorade rendimiento de nuestra propuesta frente a QlikView. Esto se debe a que nuestrapropuesta identifica los nombres de las columnas y los alias que se utilizan en elscript de carga de datos, como se explicó en el apartado 3.2.2.4. La implementaciónde QlikView almacena información redundante en memoria principal, pero nuestrapropuesta únicamente crea nuevos vectores de estado, de selección y de frecuenciapara cada alias.

Las interfaces de BI normalmente permiten a los usuarios organizar la misma in-formación por medio de distintos filtros y en diferentes representaciones de tablas dedatos o de gráficas. Teniendo esto presente, un panel de control compartido (lo cualimplica numerosos alias) con nuestra implementación es más eficiente en términosde consumo de memoria principal que el mismo panel de control en QlikView.

Con nuestra propuesta, el tiempo de respuesta para la presentación de resultadosen forma de tabla o gráfico siempre es inferior a un segundo (estos valores de tiempode respuesta se producen en todos los cuadros de control de nuestros experimentos).

102


Figura 3.25.: Comparación entre nuestra propuesta y QlikView en términos de con-sumo de memoria principal cuando se utilizan los alias en el procesode carga de datos (tomado de [Sendin-Raña et al., 2010]).

103

3. Contribuciones

Normalmente, este tiempo incluye el tiempo necesario para el proceso de filtradoen base a una o más variables seleccionadas por el usuario. La figura 3.26 muestrael tiempo de filtrado. Los tiempos para la presentación de resultados en forma detabla o gráfico se muestran en la figura 3.27, en los mismos escenarios que el primer(figura 3.22) y segundo (figura 3.23) tipos de prueba. Consideramos que los tiemposde respuesta son adecuados desde el punto de vista subjetivo del usuario que manejael panel de control.

Figura 3.26.: Tiempo de filtrado (tomado de [Sendin-Raña et al., 2010]).

3.2.4. Conclusiones

Esta contribución se apoya en una herramienta de BI alojada en un servidorweb, con capacidad de atender peticiones desde cualquier terminal, desde cualquiersistema operativo, tan sólo a través de un navegador web. La herramienta BI resul-tante sigue el paradigma AQL, que permite manejar grandes cantidades de datosde manera eficiente y rápida. El proyecto ha sido desarrollado como open source y

104


Figura 3.27.: Tiempos de respuesta ante acciones de filtrado para la representaciónen forma de tablas o de gráficos en el panel de control del usuario(tomado de [Sendin-Raña et al., 2010]).

105

3. Contribuciones

multiplataforma. El cliente cuenta con una interfaz gráfica simple pero potente, concontroles que le permiten realizar complejos análisis.

El aspecto clave de esta contribución reside en las técnicas utilizadas para lacompresión de datos, que permiten el almacenamiento de grandes cantidades dedatos en memoria principal. Gracias a ello un sistema BI puede responder de maneracasi instantánea cualquier petición de un usuario.

El rendimiento, en términos de compresión, tiempo de carga de datos y tiempode respuesta ante peticiones del usuario se aproxima al de la herramienta que setoma como referencia: QlikView. Además, se proporcionan soluciones a algunos delos problemas presentados por la descripción publicada de QlikView. Esto puedeayudar al desarrollo de aplicaciones de código abierto o propietarias similares.

3.3. Mejora en el proceso de recarga de datos ensoluciones web AQL


En el apartado 1.2 se identificó un problema de los sistemas de BI: la carga de datoscuando el origen actualiza o introduce nuevos registros. La solución más extendidaes la recarga periódica, pero presenta algunos problemas:

El proceso de carga desde las fuentes de datos a los Data Warehouses implicaun tiempo de indisponibilidad, durante el cuál el almacén de datos no se en-cuentra operativo, ya que la información debe ser consistente. Esto repercutenegativamente en la disponibilidad del sistema de BI.El periodo de tiempo entre procesos de recarga no puede ser muy grande, yaque la información contenida en los Data Warehouses no estaría actualizada,pero tampoco muy pequeño, ya que la recarga implica indisponibilidad.

Se propone un algoritmo para actualización de cambios para la contribución pre-sentada en el apartado 3.2. Se deben realizar una serie de puntualizaciones previas:

Al no existir un gestor encargado de los orígenes de datos, que sería el encarga-do de comunicar las posibles modificaciones, no es posible detectar cambios enlas fuentes, a menos que se realicen pollings periódicos, lo que no es eficiente.No se puede introducir un gestor o agente en la fuente de datos, ya que setrataría de una solución invasiva.No se pueden detectar cambios en los orígenes de datos sin una inspección delos mismos. Esto quiere decir, y centrándonos en los orígenes de datos más

106

3.3. Mejora en el proceso de recarga de datos en soluciones web AQL

importantes y usuales (bases de datos relacionales), que no existe ningunasentencia SQL estándar que proporcione esta información. Ni siquiera existeuna que informe de cambios en la base de datos, o en una tabla de la misma.Es cierto que existen procedimientos almacenados y otro tipo de mecanismospropios de algunos motores de bases de datos (por ejemplo, SQL Server, Ora-cle, mySQL). Pero dependen de la tecnología de almacenamiento (MyISAM,InnoDB, etc.).

Por tanto, se ha optado por una solución que permite la recarga de datos en unmenor tiempo. Para ello se utiliza el mismo script de carga del apartado 3.2.3. Conrespecto a la solución original, nos beneficiamos de:

Servicio disponible todo el tiempo. En el esquema original, ante una recarga, latabla binaria se elimina, lo que impide efectuar consultas al usuario mientrasdura el proceso (ver figura 3.24, con tiempos de 10-15 segundos). Con estanueva propuesta, el usuario no experimenta en ningún momento corte delservicio. Además, se asegura integridad de los datos.Menor tiempo de recarga, y por lo tanto, menor tiempo de respuesta antemodificaciones. En el esquema original no se reutilizaba ninguno de los datospreviamente calculados. Con esta nueva propuesta se reutilizan para reducirel tiempo de recarga.

3.3.2. Funcionamiento del algoritmo de recarga optimizado

Como ya se ha adelantado, esta propuesta trata de aprovechar los datos previa-mente calculados, en particular los contenidos en la tabla binaria.

Existen tres posibles cambios en la fuente de datos: modificación, eliminación ycreación de un nuevo registro. Comprobarlos tras la codificación de valores de labase de datos relacional a binario, es arduo y lento. Conlleva la comprobación encada uno de los registros, buscando modificaciones.

La solución propuesta propone agregar para la tabla binaria un vector de apa-rición, que tomará los valores 0 o 1 para cada registro de la tabla binaria. Estevector de aparición identificará los registros sospechosos de modificación, y los quese mantienen inalterables.

Supongamos que contamos con las tablas de las figuras 3.7, 3.8 y 3.9. Su codifica-ción en valores binarios sería la mostrada en las figuras 3.10, 3.11, 3.12, 3.13, 3.14,3.15, 3.16 y 3.17.

Las tablas intermedias (necesarias en el proceso de construcción de la tabla binariafinal) serían las mostradas en las figuras 3.18, 3.19 y 3.20.

107

3. Contribuciones

ID Nombre Viaje Dinero Fechas1 John Brasil 2150 Julio2 Joan Italia 750 Agosto3 Mary Francia 1150 Enero4 John España 800 Septiembre5 Mary USA 3950 Julio6 John Italia 600 Enero7 John Francia 1250 Marzo8 John USA 2650 Septiembre

Cuadro 3.7.: Tabla A.

ID Nombre Estado Dirección País1 John Casado A UK2 Joan Soltero B UK3 Mary Soltero C Irlanda

Cuadro 3.8.: Tabla B.

ID Viaje Ciudad1 Brasil Río2 Italia Venecia3 Italia Florencia4 Italia Roma5 Francia París6 España Barcelona7 España Madrid8 USA NY9 USA Washington10 USA LA

Cuadro 3.9.: Tabla C.

108


NombreJohn 0Joan 1Mary 2

Cuadro 3.10.: Tablas de correspondencias binarias para Nombre.

ViajeBrasil 0Italia 1

Francia 2España 3

USA 4

Cuadro 3.11.: Tablas de correspondencias binarias para Viaje.

Dinero2150 0750 11150 2800 33950 4600 51250 62650 7

Cuadro 3.12.: Tablas de correspondencias binarias para Dinero.

FechasJulio 0

Agosto 1Enero 2

Septiembre 3Marzo 4

Cuadro 3.13.: Tablas de correspondencias binarias para Fechas.

109

3. Contribuciones

EstadoCasado 0Soltero 1

Cuadro 3.14.: Tablas de correspondencias binarias para Estado.

DirecciónA 0B 1C 2

Cuadro 3.15.: Tablas de correspondencias binarias para Dirección.

CiudadRío 0

Venecia 1Florencia 2

Roma 3París 4

Barcelona 5Madrid 6

NY 7Washington 8

LA 9

Cuadro 3.16.: Tablas de correspondencias binarias para Ciudad.

PaísUK 0

Ireland 1

Cuadro 3.17.: Tablas de correspondencias binarias para País.

110


Nombre Viaje Dinero Fechas0 0 0 01 1 1 12 2 2 20 3 3 32 4 4 00 1 5 20 2 6 40 4 7 3

Cuadro 3.18.: Tabla binaria A.

Nombre Estado Dirección País0 0 0 01 1 1 02 1 2 1

Cuadro 3.19.: Tabla binaria B.

Viaje Ciudad0 01 11 21 32 43 53 64 74 84 9

Cuadro 3.20.: Tabla binaria C.

111

3. Contribuciones

El resultado es la tabla binaria de la figura 3.21.El primer cambio que se introduce en el algoritmo original consiste en mantener

la traducción de los valores de las columnas a binario. Es decir, en caso de que seañada un nuevo valor, en lugar de reasignar los valores binarios como se haría en elalgoritmo original, se mantiene la asignación inicial y al nuevo valor se le asigna unvalor binario libre. Esto permitirá simplificar la detección de cambios y eliminaráposibles errores en su detección debido a una reasignación.

En el ejemplo mostrado en las tablas, el vector de aparición se creará con 17valores. Estos valores están inicialmente a cero, al principio del proceso de recarga.A continuación se crean los vectores de correspondencia. Estos vectores pueden versemodificados si:

Se ha sustituido un valor por otro (por ejemplo, Florencia por Milán). En estecaso se substituye el valor en la correspondiente posición, y este cambio noafectará en absoluto a la tabla binaria.Se ha añadido un nuevo valor (por ejemplo, el viaje por Francia ahora incluyeLa Rochelle). El nuevo par (La Rochelle, 10) se añade al final del vector detraducción.Se ha eliminado un valor (por ejemplo, el viaje por Italia ya no incluye Vene-cia). Se elimina esa entrada, pero sin modificar los valores de traducción de lossiguientes elementos. Es decir, Florencia seguirá con el valor 2. Automática-mente se marcan a -1 en el vector aparición todos los elementos correspondien-tes. No se eliminan, ya que el propósito es que el usuario pueda consultar latabla binaria original durante la mayor parte del proceso de recarga de datos.

En caso de que existan varios cambios en la fuente, por ejemplo el borrado de unregistro, incorporación de uno nuevo y modificación de otro, la complejidad está endetectar cuál ha sido el registro modificado y cuál es el nuevo, ya que esto afectaráal algoritmo y podría provocar errores al tratar los registros de tablas relacionadasen caso de que se detectase de forma incorrecta. Es aquí donde será de utilidad elvector de aparición.

Tras el paso inicial, se irán recorriendo los registros de la primera tabla, sin tenerque reservar espacio en memoria para la tabla binaria intermedia. Tan sólo se hade reservar espacio en memoria principal para el registro que se está comprobandoactualmente. Una vez codificado, se busca en la tabla binaria del servidor: si laentrada (comprobando sólo las columnas correspondientes y cuando el vector deaparición tenga estado 0) existe, se marca como 1. Una aparición no asegura que noexistan más entradas asociadas a este registro, por lo que la búsqueda no finalizahasta recorrer toda la tabla.

Si no se encuentra la entrada correspondiente en la tabla binaria, significa que se

112


Nombre Viaje Ciudad Dinero Fechas Estado Dirección País0 0 0 0 0 0 0 0

1 1 1 1 1 1 1 0

1 1 2 1 1 1 1 0

1 1 3 1 1 1 1 0

2 2 4 2 2 1 2 1

0 3 5 3 3 0 0 0

0 3 6 3 3 0 0 0

2 4 7 4 0 1 2 1

2 4 8 4 0 1 2 1

2 4 9 4 0 1 2 1

0 1 1 5 2 0 0 0

0 1 2 5 2 0 0 0

0 1 3 5 2 0 0 0

0 2 4 6 4 0 0 0

0 4 7 7 3 0 0 0

0 4 8 7 3 0 0 0

0 4 9 7 3 0 0 0

Cuadro 3.21.: Tabla binaria.

113

3. Contribuciones

trata de un registro nuevo o uno modificado, con lo cual se puede generar una nuevaentrada binaria en una tabla adicional, en paralelo, mientras continúa el proceso debúsqueda para el resto de registros. La creación del nuevo registro puede dependerde cambios en las tablas secundarias, por lo que podemos crear una pila de nuevosregistros que se procesa de forma paralela.

En las tablas sucesivas se irán realizando las mismas operaciones de búsqueda.El proceso de búsqueda de una nueva tabla esperará a la finalización del procesoencargado de construir los nuevos registros de la tabla anterior (proceso lanzado alno encontrar una entrada en la tabla binaria).

Al finalizar el proceso de búsqueda, y antes de iniciar el de la siguiente tabla,se inicia el vector de aparición y se redimensiona para considerar únicamente losregistros encontrados en la fase anterior (marcados con 1 en el anterior vector deaparición) y los nuevos registros creados. Por tanto, en las sucesivas búsquedas, nose considerarán nunca los registros que tengan un 0 -1 en el vector de aparición.

Se liberarán de memoria todos los registros de la tabla binaria con un valor 0 enel vector de aparición, para después añadir los nuevos registros creados. Se vuelve ainiciar el vector de aparición (con la nueva dimensión de la tabla binaria) y comienzael proceso de búsqueda de la siguiente tabla.

El orden para recorrer las diferentes tablas (proceso de búsqueda) definidas en elscript de carga es el mismo que en la implementación original de carga de datos.

Al finalizar el proceso de búsqueda y creación de nuevos registros en todas lastablas, se liberarán de memoria los registros que se fueron marcando con 0 en algunode los vectores de aparición, para después añadir los nuevos registros creados. Esteproceso de sustitución de los registros eliminados (sospechosos de haber sufridoalguna modificación) por los nuevos se inicia con un bloqueo de peticiones de usuarioa la estructura de datos en memoria. Al finalizar la agregación de los nuevos registrosa la tabla binaria, se desbloquearán y se permitirán de nuevo peticiones de datospor parte de los usuarios.

Intuitivamente, el proceso de construcción de esta subtabla binaria implica menortiempo de respuesta y menores recursos de memoria que la tabla binaria original.Además, el usuario sólo verá limitado su acceso a la estructura de datos duranteun tiempo mínimo (el de sustitución de unos registros por otros), por lo que noexperimentará interrupción en el servicio.

El consumo de memoria es mayor (en el proceso de carga original se liberan todaslas estructuras de datos para comenzar a crearlas de cero) pero aun así despreciable:solo se requieren un par de vectores de aparición (el principal y un auxiliar) y unvector binario para ir comparando los datos originales con los nuevos. Poco, frentea tablas de millones de registros.

114


Además, el tiempo de cohexistencia de la tabla binaria de nuevo cargada y lastablas binarias intermedias es muy reducido, y lo habitual es que las tablas binariasintermedias tengan un tamaño sensiblemente menor que la binaria final.

La primera carga se realizaría igual que en el algoritmo original, pero las sucesivasrecargas se beneficiarían del mecanismo de detección de cambios, en mayor medidacuantos menos registros se vean afectados por modificaciones.

3.3.3. Conclusiones

Hemos desarrollado un método para extraer información de una base de datosque reduce el tiempo de indisponibilidad del sistema debido a procesos de recargade datos y mejora el tiempo de procesado de los mismos. El método se caracterizapor:

Algoritmo de detección de cambios en la estructura cargada en memoria.Capacidad de procesado en paralelo.Mecanismo de adición de nuevos registros con un tiempo de bloqueo mínimo.Este algoritmo supone una mejora del tiempo de respuesta con respecto a lasrecargas del método propuesto en [Sendin-Raña et al., 2010].

115

Capítulo 4

Conclusiones

Índice4.1. Mejora de sistemas ROLAP . . . . . . . . . . . . . . . . . 117

4.2. Solución web basada en AQL . . . . . . . . . . . . . . . . 119

4.3. Líneas futuras . . . . . . . . . . . . . . . . . . . . . . . . . 120

4.1. Mejora de sistemas ROLAP

En el apartado 2.1 se ha presentado una solución para implantar un sistemaROLAP de código abierto eficiente. Este sistema permite a los usuarios realizarcomplejos análisis cumpliendo las reglas FASMI, que serían imposibles de satisfaceren sistemas clásicos. La implementación propuesta es una evolución de Mondrian,un servidor ROLAP open source que forma parte de la suite de Pentaho.

Un sistema OLAP eficiente necesita algún tipo de técnica de pre-agregación dedatos para cumplir las reglas FASMI. Tradicionalmente los servidores ROLAP con-siguen un alto rendimiento en análisis multidimensional mediante un correcto diseñode tablas de vistas agregadas en sus almacenes de datos, además de un ajuste pre-ciso en la configuración del esquema para aprovechar correctamente esta técnica depre-agregación.

Para cubos multidimensionales que albergan una cantidad muy elevada de infor-mación, el rendimiento depende de las características del hardware, de un correctoajuste en la base de datos relacional y, en menor medida, de las características delmotor ROLAP. El ajuste en el almacén de datos subyacente requiere un complejoproceso de diseño de tablas de vistas agregadas, y tiene como dificultad añadida elmantenimiento de estas vistas materializadas.

117

4. Conclusiones

La propuesta presentada en el apartado 3.1.4 evita el diseño, mantenimiento ylos problemas derivados de consistencia de datos de las tablas de vistas agregadas.La extensión diseñada para el sistema de cache de Mondrian permite tiempos derespuesta rápidos en cualquier situación, manteniendo la integridad en los datos.

Mondrian es escalable, ya que tiene capacidad para trabajar con bases de datosrelacionales de gran tamaño, con un número elevado de dimensiones y con numerososusuarios. Sin embargo, el rendimiento en la carga de datos es bajo cuando hablamosde bases de datos relacionales de gran tamaño. Nosotros proponemos un proceso(que denominamos cold start) para cargar las vistas de datos agregados en unacache especial, llamada parallel cache, y conseguimos unos tiempos de respuestaaceptables cuando Mondrian utiliza un grandes almacenes de datos. Conseguimosreducir el tiempo de respuesta en un orden de magnitud, si lo comparamos conMondrian sin ningún tipo de técnica de agregación de datos, es decir, accediendodirectamente a la información base. El control de la cache asegura la consistenciade los datos agregados mientras se actualiza la base de datos relacional subyacente.

La combinación de la cache propia de Mondrian, la parallel cache y el almacén dedatos subyacente permite tiempos de recuperación rápidos ante caídas abruptas delservidor, garantizando una alta calidad de servicio. Además, esta solución permiteimplementar un sistema OLAP en tiempo real, ya que la información que se intro-duce (nueva o actualizada) en la base de datos relacional también se actualiza en lacache secundaria.

Esta contribución es no intrusiva, ya que el diseño de la parallel cache, o cache se-cundaria, facilita una posible migración a nuevas versiones de Mondrian con mejoresprestaciones.

La segunda contribución a sistemas ROLAP es una mejora en la funcionalidaddesde el punto de vista del administrador de Mondrian. Se incluye una dimensiónvirtual que denominamos dimensión calculada, como se explica en detalle en el apar-tado 3.1.3. El administrador de Mondrian tiene que definir esta dimensión calculadadel mismo modo que define el cubo multidimensional: por medio de un documentoXML de sencilla configuración. Con esta nueva funcionalidad, las nuevas medidascalculadas pueden crearse en tiempo real con unas operaciones muy intuitivas, tansólo con definir una operación de cruce (crossjoin) entre los miembros de la dimen-sión calculada y las medidas definidas previamente en el cubo. Esta funcionalidadpermite evitar declaraciones repetitivas en las sentencias MDX y en los esquemasMondrian, por lo que se mejora la experiencia del usuario y del administrador deMondrian. Como el usuario puede solicitar nuevas medidas utilizando una interfazgráfica, es posible obtener informes complejos sin rediseñar el cubo multidimensionalo introducir en cada petición largas sentencias MDX con definiciones de miembroscalculados.

118

4.2. Solución web basada en AQL

El rendimiento del sistema Mondrian no se ve afectado con esta nueva funciona-lidad, y las sentencias MDX siguen cumpliendo el estándar.

4.2. Solución web basada en AQL

En el apartado 3.2 se ha presentado una solución para la implementación deuna aplicación web de BI eficiente. Esta aplicación posee unas características defacilidad y usabilidad adecuada para usuarios finales sin ningún tipo de experienciaprevia. Además, esta facilidad de uso no merma su potencia, pues es posible realizarcomplejos análisis sobre enormes cantidades de datos cargados en memoria.

La solución reside en un servidor web con soporte para los navegadores más popu-lares. La interfaz gráfica es versátil y atractiva, y cuenta con controles que permitenrealizar complejos análisis.

Se trata de la primera implementación de código abierto y portable del algoritmoAQL y de Data Cloud. Su rendimiento es comparable al de QlikView, la aplicacióncomercial que se toma como referencia, en términos de tiempo de carga de datos enmemoria principal desde la fuente de datos especificada, consumo de memoria prin-cipal para albergar esos datos codificados de manera eficiente, y tiempo de búsquedapara presentar resultados tras aplicar una serie de filtros.

Estos resultados son posibles gracias a las técnicas utilizadas para la compresión dedatos, que permiten el almacenamiento de grandes cantidades de datos en memoriaprincipal. Esto permite tiempos de respuesta casi instantáneos ante peticiones delusuario.

Además, se proporcionan dos mejoras sobre el algoritmo original de AQL y deData Clouds, que pueden ser muy beneficiosas tanto para aplicaciones distribuidassemejantes a la propuesta como para aplicaciones locales y dependientes del equiposobre el que se ejecutan, como es el caso de QlikView. Estas dos mejoras son:

Una reducción significativa de la información necesaria en memoria principalcuando el usuario quiere utilizar una función muy común, el alias.Una redefinición del algoritmo de búsqueda con operaciones de filtrado, queevita algunos errores que llevaba aparejada la descripción publicada del algo-ritmo de QlikView.

En el apartado 3.3 se propone un método para mejorar el tiempo de recarga dela solución propuesta en el apartado 3.2. Los usuarios de sistemas de BI deman-dan análisis sobre datos actualizados, y esto implica recargar información de losalmacenes de datos de manera frecuente. Sin embargo, los procesos de recarga deinformación actualizada conllevan indisponibilidad del sistema para evitar inconsis-

119

4. Conclusiones

tencias (al utilizar información del pasado y del presente al mismo tiempo). Por elloes de gran importancia conseguir procesos de recarga tan rápidos que el usuario finalno sea consciente del intervalo de indisponibilidad. La solución propuesta en 3.3.2lo consigue mediante la recarga selectiva de datos en la tabla binaria.

4.3. Líneas futuras

Nuestro propósito es explorar las posibilidades que nos permite la computaciónen la nube, con las plataformas opensource Apache Hadoop y Apache Spark. En elmomento de la publicación de las contribuciones de este trabajo doctoral, ApacheHadoop aún no había alcanzado su primera versión estable (año 2011), y Spark aúntardaría dos años más en entrar a formar parte del proyecto Apache.

Claramente Apache Hadoop se posiciona como la plataforma más adecuada paramejorar la solución basada en Mondrian. Como se ha comentado en el subapartado2.3.1.2, Pentaho ya cuenta con soporte para Apache Hadoop. Pero aún si no fueseasí, resulta intuitivo que las dos herramientas más potentes (MapReduce y HDFS)permitirán mejorar de forma sensible las capacidades de nuestro sistema OLAP ysu velocidad de procesado. En primer lugar, MapReduce, mediante la paralelizaciónde procesos, puede mejorar la velocidad ante peticiones de los usuarios al sistemaOLAP, y del proceso de cold start. Por otro lado, HDFS mejorará los tiempos decarga y permitirá contar con unos almacenes de datos de mayor capacidad.

La implementación de nuestra solución OLAP en Apache Hadoop nos permitirácuantificar estas mejoras, y permitirá establecer otras estrategias para la creacióndel parallel cache. En este sentido, Apache Spark puede ser un aliado para crear unacache de mayor capacidad, y mejorar las prestaciones de tiempo de respuesta antelas peticiones al sistema OLAP.

También es interesante el estudio de Hive y HBase, dos herramientas de ApacheHadoop, y las aplicaciones que puedan tener para nuestro sistema OLAP.

En cuanto al sistema de BI en-memoria presentado en el apartado 3.2, la apli-cación de Apache Spark resulta necesaria para poder a las demandas actuales delmercado. Con esta plataforma de memoria principal distribuida se podrán cargaren memoria principal mayores volúmenes de datos. Pero se debe estudiar en detallecomo repercute esto en los tiempos de generación de las tablas binarias, los tiemposde respuesta ante acciones de filtrado, y en los tiempos de recarga, estudiados en elapartado 3.3.

120

Anexo A

Esquema multidimensional

Esquema del cubo multidimensional desarrollado para el proyecto Pesca Fresca.

<?xml version="1.0"?>

<Schema name="PescaFrescaSchema" measuresCaption="Data Analysis">

<Cube name="PescaFresca">

<Table name="sep_gdia"/>

<Dimension name="Time" type="TimeDimension" caption="Time Dimension"><Hierarchy name="byYears" hasAll="true" allMemberName="All years"><Level name="Years" type="Numeric" uniqueMembers="true" levelType="TimeYears"><KeyExpression><SQL dialect="generic">YEAR(date)

</SQL></KeyExpression>

</Level></Hierarchy>

</Dimension>

<Dimension name="Time.byQuarters" type="TimeDimension"caption="Time Dimension by Quarters "><Hierarchy hasAll="true" allMemberName="All quarters"><Level name="Quarters" uniqueMembers="false" levelType="TimeQuarters"formatter="mondrian.misc.MiscQuarterParser"><KeyExpression><SQL dialect="generic"> QUARTER(date) </SQL>

</KeyExpression></Level>


121

A. Esquema multidimensional

<Dimension name="Time.byMonths" type="TimeDimension" caption="Time Dimension by Months"><Hierarchy hasAll="true" allMemberName="All months"><Level name="Months" uniqueMembers="false" levelType="TimeMonths"formatter="mondrian.misc.MiscMonthParser"><KeyExpression><SQL dialect="generic"> MONTH(date) </SQL>



<Dimension name="Time.byDays" type="TimeDimension" caption="Time Dimension by Days"><Hierarchy hasAll="true" ><Level name="Days" type="Numeric" uniqueMembers="false" levelType="TimeDays"><KeyExpression><SQL dialect="generic"> DAY(date) </SQL>



<Dimension name="Geographic location " foreignKey="fishery_id"><Hierarchy name="byRegions" hasAll="true" allMemberName="All regions"primaryKey="fishery_id"><Table name="sep_fishery"/><Level name="Regions" column="region" uniqueMembers="true"/><Level name="Zones" column="zone" nameColumn="zone_description" uniqueMembers="false"/><Level name="Cities" column="city" uniqueMembers="false"/><Level name="Fisheries" column="name" uniqueMembers="false"/>

</Hierarchy><Hierarchy name="byZones" hasAll="true" allMemberName="All zones"primaryKey="fishery_id"><Table name="sep_fishery"/><Level name="Zones" column="zone" nameColumn="zone_description" uniqueMembers="true"/><Level name="CitiesByZones" column="city" uniqueMembers="false"/><Level name="FisheriesByZones" column="name" uniqueMembers="false"/>


<Dimension name="Fishing species" foreignKey="species_id"caption="Fishing Species Dimension"><Hierarchy name="Fishing Species" hasAll="true" allMemberName="All species"primaryKey="species_id" primaryKeyTable="species_table"><View alias="species_table"><SQL dialect="generic">SELECT se.species_id as species_id, sge.description as group_description,

sf.fao_nc as fao, se.description as specie_descriptionFROM sep_species as seLEFT JOIN sep_fao as sf ON sf.fao=se.fao

122

LEFT JOIN sep_species_group as sge ON sge.codigo=se.grupo</SQL>

</View><Level name="Group" column="group_description" uniqueMembers="true"/><Level name="FaoSpecie" column="fao" uniqueMembers="true"/><Level name="Species" column=" species_description" uniqueMembers="false"/>


<Dimension name="Data State" caption="Data State Dimension "><Hierarchy name="Data State" hasAll="true" allMemberName="All data"><Level name="Data" type="String" uniqueMembers="true" column="data_state"formatter="mondrian.misc.MiscStateDataDimensionParser"/>


<Dimension name="Calculated Dimension" caption="Calculated Dimension"foreignKey="gdia_id"><Hierarchy hasAll="true" memberReaderClass="mondrian.rolap.MiscHierarchy"><Level name="Calculated Dimension" uniqueMembers="true"/>


<Measure name="Sales Notes" caption="Sales Notes" column="notes" aggregator="sum"datatype="Numeric" formatString="#,###"/>

<Measure name="Quantity" caption="Quantity (kg)" column="quantity" aggregator="sum"datatype="Numeric" formatString="#,###.##"/>

<Measure name="Sales" caption="Sales ()" column="price" aggregator="sum"datatype="Numeric" formatString="#,###.##"/>

<Measure name="Maximum Price" caption="Maximun Price" column="pmax" aggregator="max"datatype="Numeric" formatString="#,###.##"/>

<Measure name="Minimum Price" caption="Minimum Price" column="pmin" aggregator="min"datatype="Numeric" formatString="#,###.##"/>

<Measure name="Days Number" caption="Number of Days of Activity" column="date"aggregator="distinct count" datatype="Numeric" formatString="#,###"/>

<Measure name="Species Number" caption="Number of Fishing Species" column="species_id"aggregator="distinct count" datatype="Numeric" formatString="#,###.##"/>

<Measure name="Fisheries Number" caption="Number of Fisheries" column="fishery_id"aggregator="distinct count" datatype="Numeric" formatString="#,###"/>

<CalculatedMember name="Average Price" dimension="Measures" caption="Average Price"><Formula>

123

A. Esquema multidimensional

[Measures].[Price] / [Measures].[Quantity]</Formula><CalculatedMemberProperty name="FORMAT_STRING" value="#,###.##"/>

</CalculatedMember>

</Cube></Schema>

124

Anexo B

Script de carga

ÍndiceB.1. Clientes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125B.2. Proveedores . . . . . . . . . . . . . . . . . . . . . . . . . . . 126B.3. Facturas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126B.4. Especies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129B.5. Vales y cobros . . . . . . . . . . . . . . . . . . . . . . . . . 129B.6. Pagos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

Script de carga para la generación una estructura de datos en memoria que permitediseñar un cuadro de mando integral.

B.1. Clientes

LOAD cliente_id as cliente_id,codigo_c as codigo_cliente,nombre as nombre_cliente,persona_co as persona_contacto_cliente;FROM clientes;

//ProvLOAD cliente_id as cliente_id_para_prov,codigo_c as codigo_cliente_para_prov,nombre as nombre_cliente_para_prov,persona_co as persona_contacto_cliente_para_prov;FROM clientes;

//Para la pestaña de EspeciesLOAD cliente_id as cliente_especie_id,

125

B. Script de carga

nombre as nombre_cliente_especie,persona_co as persona_contacto_especie;FROM clientes;

//Para la pestaña de CobrosLOAD cliente_id as cliente_cobros_id,codigo_c as codigo_cliente_cobros,nombre as nombre_cliente_cobros,persona_co as persona_contacto_cobros;FROM clientes;

B.2. Proveedores

LOAD prove_id as proveedor_id,codigo_c as codigo_proveedor,nombre as nombre_proveedor,repres as representante_proveedor;FROM proveedores;

//CliLOAD prove_id as proveedor_id_para_cliente,codigo_c as codigo_proveedor_para_cliente,nombre as nombre_proveedor_para_cliente,repres as representante_proveedor_para_cliente;FROM proveedores;

//Para la pestaña de EspeciesLOAD prove_id as proveedor_especie_id,nombre as nombre_proveedor_especie,repres as representante_proveedor_especeie;FROM proveedores;

//Para la pestaña de PagosLOAD prove_id as proveedor_pagos_id,codigo_p as codigo_proveedor_pagos,nombre as nombre_proveedor_pagos,repres as representante_pagos_especeie;FROM proveedores;

B.3. Facturas

LOAD factura_id as id_factura_ca,nufactu as numero_factura_ca,cliente_id as cliente_id,iva as tipo_iva,xbruto1 as importe_BRUTO_1_factura_ca,

126

B.3. Facturas

xbruto2 as importe_BRUTO_2_factura_ca,xbruto3 as importe_BRUTO_3_factura_ca,xbase1 as importe_BASE_1_factura_ca,xbase2 as importe_BASE_2_factura_ca,xbase3 as importe_BASE_3_factura_ca,xtofa1 as importe_TOTAL_FACTURA_1_factura_ca,xtofa2 as importe_TOTAL_FACTURA_2_factura_ca,xtofa3 as importe_TOTAL_FACTURA_3_factura_ca,pp as factura_pronto_pago_ca,cobro_id as identificador_cobro_factura_ca;FROM ‘facli_ca‘ where between(fechafactu,CTOD("01/01/2002"),CTOD("12/31/2097"));

LOAD factura_id as id_factura_ca,linea_id,fechavale as fecha_factura_de,Year(date(fechavale,’MMDDYY’)) as año_consulta,Month(date(fechavale,’MMDDYY’)) as mes_consulta,Day(date(fechavale,’MMDDYY’)) as dia_consulta,nuvale as numero_factura_de,lineavale as linea_factura_de,prove_id as proveedor_id_para_cliente,categoria as categoria_producto,especie as nombre_especie,tipo_uni as tipo_unidades,cantidad as cantidad_producto_factura_de,precio as precio_producto_factura_de,importe as importe_BRUTO_factura_de;FROM facli_de where between(fechavale,CTOD("01/01/2002"),CTOD("12/31/2097"))and categoria != ’SUMINISTROS’;

LOAD factura_id as id_factura_prov_ca,nufactu as numero_factura_prov_ca,prove_id as proveedor_id,xbruto as importe_BRUTO_Factura_prov_ca,xcompra as importe_Compra_factura_prov_ca,xbase as importe_BASE_factura_prov_ca,xtofa as importe_TotalFactura_factura_prov_ca,xtotfin as importe_TotalPagar_factura_prov_ca;

FROM ‘fapro_ca‘ where between(fechafactu,CTOD("01/01/2002"),CTOD("12/31/2097"));

LOAD factura_id as id_factura_prov_ca,linea_id,fechavale as fecha_factura_prov_de,Year(date(fechavale,’MMDDYY’)) as año_consulta,Month(date(fechavale,’MMDDYY’)) as mes_consulta,Day(date(fechavale,’MMDDYY’)) as dia_consulta,nuvale as numero_factura_prov_de,lineavale as linea_factura_prov_de,cliente_id as cliente_id_para_prov,

127

B. Script de carga

categoria as categoria_producto,especie as nombre_especie,tipo_uni as tipo_unidades,cantidad as cantidad_producto_factura_prov_de,precio as precio_producto_factura_prov_de,importe as importe_BRUTO_factura_prov_de;FROM ‘fapro_de‘ where between(fechavale,CTOD("01/01/2002"),CTOD("12/31/2097"))and categoria != ’SUMINISTROS’;

LOAD faclide_fechavale as fecha_vale_cliente_desperdicios,Year(date(facli_de.fechavale ,’MMDDYY’)) as año_consulta,Month(date(facli_de.fechavale ,’MMDDYY’)) as mes_consulta,Day(date(facli_de.fechavale ,’MMDDYY’)) as dia_consulta,faclide.codespe as codigo_especie_desperdicios,faclide.tipo_uni as tipo_unidades_desperdicios,faclide.cantidad as cantidad_producto_cliente_desperdicios_No_Convertido,facli_de.cantidad * IIF((especies.factor_con = 0 OR especies.factor_con = NULL),1,especies.factor_con) as cantidad_producto_cliente_desperdicios;FROM facli_de, especies WHERE especies.codigo = facli_de.codespe AND(between(facli_de.fechavale,CTOD("01/01/2002"),CTOD("12/31/2097")) and((facli_de.tipo_uni = ’KG’) or (facli_de.tipo_uni = ’CA’)));

LOAD faprode_fechavale as fecha_vale_proveedor_desperdicios,Year(date(fapro_de.fechavale,’MMDDYY’)) as año_consulta,Month(date(fapro_de.fechavale,’MMDDYY’)) as mes_consulta,Day(date(fapro_de.fechavale,’MMDDYY’)) as dia_consulta,fapro_de.codespe as codigo_especie_desperdicios,faprode.tipo_uni as tipo_unidades_desperdicios,faprode.cantidad as cantidad_producto_proveedor_desperdicios_No_Convertido,fapro_de.cantidad * IIF((especies.factor_con = 0 OR especies.factor_con = NULL),1,especies.factor_con) as cantidad_producto_proveedor_desperdicios;FROM fapro_de, especies WHERE especies.codigo = fapro_de.codespe AND(between(fapro_de.fechavale,CTOD("01/01/2002"),CTOD("12/31/2097")) and((fapro_de.tipo_uni = ’KG’) or (fapro_de.tipo_uni = ’CA’)));

fapro_ca_ganancia:LOAD factura_id as id_fapro_ca_ganancia,prove_id as proveedor_id_ganancia,codigo_p as codigo_proveedor_ganancia,nombre as nombre_proveedor_ganancia,xrc as comision_proveedor_categoria,xcof as comision_proveedor_indefinido,xcof+xrc as comision_proveedor_total,

p_rpro as comision_proveedor;FROM ‘fapro_ca‘ where between(fechafactu,CTOD("01/01/2002"),CTOD("12/31/2097"));

faprode_ganancia:LOAD factura_id as id_fapro_ca_ganancia,Year(date(fechavale,’MMDDYY’)) as año_consulta,

128

B.4. Especies

Month(date(fechavale,’MMDDYY’)) as mes_consulta,Day(date(fechavale,’MMDDYY’)) as dia_consulta,codespe as codigo_especie_ganancia,importe as importe_BRUTO_faprov_de_ganancia,p_co as porcentaje_comision_especie_ganancia,p_rpro as porcentaje_comision_esp_prov_ganancia,round((fapro_de.importe*(fapro_de.p_co+fapro_ca.p_rpro))/100,2)as comision_especie_indefinido;FROM fapro_de, fapro_ca where between(fapro_de.fechavale,CTOD("01/01/2002"),CTOD("12/31/2097")) AND fapro_de.factura_id = fapro_ca.factura_id;

B.4. Especies

LOAD espe_id as especie_id,descri as nombre_especie,descri as nombre_especie_solo_pescados,cate_id as categoria_id_especie,tipo_unida as tipo_unidades;FROM especies;

LOAD espe_id as especie_id_desperdicios,codigo as codigo_especie_desperdicios,descri as nombre_especie_desperdicios;FROM especies;

LOAD espe_id as especie_id_ganancia,codigo as codigo_especie_ganancia,descri as nombre_especie_ganancia;FROM especies;

B.5. Vales y cobros

LOAD vale_id,nuvale as numero_vale,fecha as fecha_especie,Year(date(fecha,’MMDDYY’)) as año_consulta_especie,Month(date(fecha,’MMDDYY’)) as mes_consulta_especie,Day(date(fecha,’MMDDYY’)) as dia_consulta_especie;FROM ‘vale_ca‘ where between(fecha,CTOD("01/01/2002"),CTOD("12/31/2097"));

LOAD linea_id_valesu_de,vale_id,vale_de.linea as linea_valesu_de,vale_de.cliente_id as cliente_especie_id,vale_de.prove_id as proveedor_especie_id,vale_de.espe_id as especie_id,vale_de.cantidad * IIF((especies.factor_con = 0 OR especies.factor_con = NULL),

129

B. Script de carga

1,especies.factor_con) as cantidad_especie,vale_de.precio / IIF((especies.factor_con = 0 OR especies.factor_con = NULL),1,especies.factor_con) as precio_especie;FROM vale_de, especies WHERE especies.espe_id = vale_de.espe_id;

LOAD cobro_id,serie+’ ’+TRANSFORM(nufactu) as serie_factura_cobro,nufactu,serie,fechafactu as fecha_factura_cobro,Year(date(fechafactu,’MMDDYY’)) as año_consulta,Month(date(fechafactu,’MMDDYY’)) as mes_consulta,Day(date(fechafactu,’MMDDYY’)) as dia_consulta,codigo_c as codigo_clientes_cobros,nombre_c as nombre_cliente_cobros,forma_p as forma_pago_cobros,esta_cobro as estado_cobro,fecha_vto as fecha_vencimiento_cobro,Year(date(fecha_vto,’MMDDYY’)) as año_vencimiento,Month(date(fecha_vto,’MMDDYY’)) as mes_vencimiento,Day(date(fecha_vto,’MMDDYY’)) as dia_vencimiento,importe_vto as importe_vencimiento_cobro;FROM ‘cobros_ca‘ where between(fechafactu,CTOD("01/01/2002"),CTOD("12/31/2097"));

//Suma de todos los CobrosLOAD importe_vto as importe_Cobro_Total,Year(date(fechafactu,’MMDDYY’)) as año_consulta,Month(date(fechafactu,’MMDDYY’)) as mes_consulta;FROM ‘cobros_ca‘ where between(fechafactu,CTOD("01/01/2002"),CTOD("12/31/2097"));

//Suma de los Cobros PendientesLOAD importe_vto as importe_Cobro_Pendiente_Total,Year(date(fechafactu,’MMDDYY’)) as año_consulta,Month(date(fechafactu,’MMDDYY’)) as mes_consulta;FROM ‘cobros_ca‘ where between(fechafactu,CTOD("01/01/2002"),CTOD("12/31/2097"))and esta_cobro = ’Pendiente’;

//Suma de los Cobros CobradosLOAD importe_vto as importe_Cobro_Cobrado_Total,Year(date(fechafactu,’MMDDYY’)) as año_consulta,Month(date(fechafactu,’MMDDYY’)) as mes_consulta;FROM ‘cobros_ca‘ where between(fechafactu,CTOD("01/01/2002"),CTOD("12/31/2097"))and esta_cobro = ’Cobrado’;

//Suma de los Cobros DevueltosLOAD importe_vto as importe_Cobro_Devuelto_Total,Year(date(fechafactu,’MMDDYY’)) as año_consulta,Month(date(fechafactu,’MMDDYY’)) as mes_consulta;FROM ‘cobros_ca‘ where between(fechafactu,CTOD("01/01/2002"),CTOD("12/31/2097"))and esta_cobro = ’Devuelto’;

130

B.6. Pagos

//Suma de los Cobros RemesadosLOAD importe_vto as importe_Cobro_Remesado_Total,Year(date(fechafactu,’MMDDYY’)) as año_consulta,Month(date(fechafactu,’MMDDYY’)) as mes_consulta;FROM ‘cobros_ca‘ where between(fechafactu,CTOD("01/01/2002"),CTOD("12/31/2097"))and esta_cobro = ’Remesado’;

B.6. Pagos

LOAD pago_id,nuliqui as numero_liquidacion_Pagos,

codigo_p as codigo_proveedor_pagos,nombre_p as nombre_proveedor_pagos,(importe_pagar-importe_cobrar) as importe_pagos,fecha_liq as fecha_liquidacion_Pagos,Year(date(fecha_liq,’MMDDYY’)) as año_consulta,Month(date(fecha_liq,’MMDDYY’)) as mes_consulta,Day(date(fecha_liq,’MMDDYY’)) as dia_consulta,pagado as estado_Pagos;FROM ‘pagos_ca‘ where fecha_liq > CTOD("01/01/2002");

//Suma de los Pagos Totales (pagados y no pagados)LOAD importe_pagos as importe_Total_Pagos,Year(date(fecha_liq,’MMDDYY’)) as año_consulta,Month(date(fecha_liq,’MMDDYY’)) as mes_consulta;FROM ‘pagos_ca‘ where between(fecha_liq,CTOD("01/01/2002"),CTOD("12/31/2097"));

//Suma de los Pagos PagadosLOAD importe_pagos as importe_Pagado_Pagos,Year(date(fecha_liq,’MMDDYY’)) as año_consulta,Month(date(fecha_liq,’MMDDYY’)) as mes_consulta;FROM ‘pagos_ca‘ where between(fecha_liq,CTOD("01/01/2002"),CTOD("12/31/2097"))and pagado = ’Si’;

//Suma de los Pagos NO PagadosLOAD importe_pagos as importe_NO_Pagado_Pagos,Year(date(fecha_liq,’MMDDYY’)) as año_consulta,Month(date(fecha_liq,’MMDDYY’)) as mes_consulta;FROM ‘pagos_ca‘where between(fecha_liq,CTOD("01/01/2002"),CTOD("12/31/2097")) and pagado = ’No’;

131

Anexo C

Glosario

Agregación. Técnica utilizada para mejorar los tiempos de respuesta anteconsultas de petición de datos de un usuario. La mejora consiste en tenergeneradas estructuras de datos que ya tienen precomputadas las respuestas, oparte de ellas, antes de recibir la petición. Si una petición que pregunta sobrelas ventas de un producto en un año encuentra una tabla de datos agregadosdonde se ha precalculado esa información, en vez de tener que calcularse en elmomento a partir de los datos contenidos en la tabla de hechos, la respuestapodría ser casi inmediata.AQL (Associative Query Logic). Tecnología patentada por la empresasueca QlikTech y utilizada en su producto QlikView. Permite una compresiónde datos utilizando técnicas asociativas, y no relacionales, que permiten al-macenar los datos en memoria de manera eficiente. Esto provoca una mejorasensible en los tiempos de respuesta ante acciones de los usuarios en los cuadrosde mando de las herramientas de análisis.BI (Business Intelligence). El término tiene numerosas acepciones. Eneste trabajo doctoral nos referimos al BI como aquellas técnicas o herramientasenfocadas a extraer información relevante a partir de un conjunto muy grandede datos, y que permite la toma de acciones a partir de este conocimiento.Aplicaciones que asisten a estrategias futuras y decisiones relevantes gracias ala adquisición de este conocimiento.CRM (Customer Relationship Management). Sistemas para la gestiónde clientes en una empresa, típicamente dirigido a sus administrar las relacio-nes, ventas, etc.Cuadro de mandos. Entorno gráfico de una herramienta de BI que presentaal usuario información relevante sobre el objeto del análisis que se quiere efec-tuar. Esta información puede ser en forma de tablas o en forma de diferentestipos de gráficas. Se acompañan de controles que permiten al usuario controles

133

C. Glosario

de filtrado, cambios en los ejes del análisis, redefinición de los mismos, interac-tuar con la información, etc. Particularizando, se puede filtrar la informaciónque se visualiza seleccionando un elemento de una lista (por ejemplo, en uncuadro de mandos que muestra las ventas de todos los productos en el añoactual, queremos mostrar la misma información pero sólo para uno de los pro-ductos en cuestión). También se puede ampliar el detalle. Siguiendo con elejemplo anterior, si el cuadro de mandos cuenta con una gráfica de barras delas ventas por mes, seleccionando uno de los meses podriamos acceder en elmismo espacio asignado a esa gráfica a las ventas particularizadas a ese mes,por días.Cubo multidimensional. Estructura organizada en dimensiones orientada aproporcionar información analítica, a diferencia de las estructuras relacionalesde los RDBMS. Los elementos principales son las medidas y las dimensionesque las organizan. Normalmente los cubos multidimensionales están asociadosa sistemas OLAP. Estas estructuras están pensadas para una menor granula-ridad que las bases de datos relacionales. Permiten operaciones de agregaciónmediante la selección de uno o más elementos de una o más dimensiones.CSV (Comma Separated Values). Formato de documento de texto uti-lizado para representación de datos en formato de tabla. Cada columna sesepara con un carácter especial (típicamente coma, punto y coma, dos puntoso tabulación) y las filas con saltos de línea.Dashboard. Ver Cuadro de mandos.Dashboarding. Sistemas de gestión que permiten la creación, modificación,compartición y eliminación de cuadros de mando.Data Cloud. Colección de datos almacenados en memoria principal enlazadosentre sí a través de asociaciones lógicas.Data Marts. Clase especial de Data Warehouse, normalmente de menor ta-maño y especializados en un área específica de negocio.Dimensión. Atributo o conjunto de atributos que permiten analizar la infor-mación de un cubo multidimensional desde diferentes perspectivas, dividiendolas medidas en subcategorías. Una dimensión contiene una colección de jerar-quías definidas a partir del mismo origen de datos.Dimensión collapsed. Técnica de agregación de datos soportada por Mon-drian. Consiste en sustituir la clave de dimensión de la tabla de hechos por unconjunto de niveles de la dimensión. Con esta técnica se consigue un mayornivel de refinamiento.Dimensión degenerada. Tipo especial de dimensión que no toma sus miem-

134

bros de una tabla de dimensión, sino que los obtiene de la propia tabla dehechos.Dimensión lost. Técnica de agregación de datos soportada por Mondrian.Consiste en la construcción de una tabla agregada a partir de todos los valoresde esa dimensión, por lo que desaparece de la tabla resultante.Diseño bottom-up. Estrategia que consiste en abordar en primer lugar losdetalles, que conforman soluciones de mayor tamaño, que a su vez se combinanpara formar componentes que, en su conjunto, definen el sistema completo.Diseño top-down. Estrategia que consiste en abordar en primer lugar elresumen completo del sistema, sin entrar en detalles. Cada componente seidentifica y define, también sin detalle, y se divide en subcomponentes que, asu vez, vuelven a definirse hasta que la especificación es completa.DM (Data Mining). La minería de datos es una tecnología definida dentrodel ámbito de la inteligencia de negocio que intenta descubrir tendencias ypatrones a partir de grandes volúmenes de datos.Drill-down. Operación de incremento del nivel de detalle, centrándose enun aspecto de la información que se presenta en un panel de control de unaherramienta de inteligencia de negocio.Drill-through. Operación de navegación en un panel de control de una he-rramienta de inteligencia de negocio que involucra dos elementos. Las accionesefectuadas en uno de ellos tienen efectos (por ejemplo, incremento o decremen-to del nivel de detalle) en el otro.DW (Data Warehouse). Repositorios diseñados para ofrecer datos a losservidores intermedios del modelo de inteligencia de negocio. Normalmente sedefinen para un determinado ámbito de negocio. Son estructuras variantes enel tiempo y no volátiles.ETL (Extract-Transform-Load). Capa del modelo de sistema de inteli-gencia de negocio, encargada de obtener información de las fuentes de datos,transformarla para hacerla adecuada para el almacén de datos, y guardarla enél.Filtrado. Acción típica de un sistema de inteligencia de negocio, que consisteen modificar la información mostrada en el panel de control al seleccionar unvalor de una lista. Tras la selección sólo se mostrarán los datos asociados a esevalor.HOLAP (Hybrid OLAP). Combinación de un sistema MOLAP y ROLAP.Jerarquía. Conjunto de miembros organizados en una estructura organizadosen niveles para proporcionar capacidades de análisis a un sistema de inteligen-

135

C. Glosario

cia de negocio. Por ejemplo, las lonjas de pesca fresca pueden estar organizadasen una jerarquía geográfica, por ciudades, por comarcas, por provincias y porestados. La selección de una comarca engloba a todas las lonjas de ese ámbitogeográfico.Inteligencia de Negocio o Inteligencia Empresarial. Ver BI.MDX (MultiDimensional eXpressions). En un sistema OLAP, sentenciaque define una petición de datos a un cubo multidimensional. Las peticionesSQL son su equivalente en el mundo relacional.Medida. Elemento asociado a una cantidad definido en un cubo multidimen-sional de interés para el análisis. Se define a partir de una columna de registrosde la tabla de hechos.Miembro. Elemento de una dimensión, dentro de una jerarquía. Por ejemplo,si se define una jerarquía de localización geográfica, “Vigo” es un elemento delnivel ciudad y “Salnés” del nivel comarca.MOLAP(Multidimensional OLAP). Motor OLAP que utiliza matricesmultidimensionales en memoria principal para almacenar los datos del cubomultidimensional.Nivel. Conjunto de miembros de una jerarquía que tienen la misma distan-cia al nodo raíz. Por ejemplo, en una jerarquía de localización geográfica, losmiembros “Vigo” y “A Coruña” están en el mismo nivel (de ciudades), perono así “Asturias” (que pertenece al nivel de provincias).OLAP ((On-Line Analytical Processing). Sistemas de inteligencia de ne-gocio que actúan en la capa de servidores intermedios. Su propósito es obtenerrespuestas rápidas ante cuestiones que involucran grandes cantidades de datosde las capas inferiores (Data Warehouses). No efectúan acciones de escriturasobre las fuentes de datos.OLTP (On-Line Transaction Processing). Sistemas de inteligencia denegocio cuyo propósito es efectuar transacciones de datos, que pueden implicarlecturas y escrituras en las fuentes de datos.Panel de control. Ver Cuadro de mandos.Pivotado. Acción que permite cambiar la perspectiva de forma muy rápidaen un panel de control de un sistema de inteligencia de negocio. Por ejemplo,se puede tener una visión de las ventas por mes y, pivotando, cambiar paravisualizar la misma información por cliente.RDBMS (Relational Database Management System). Sistema de ges-tión de bases de datos relacionales.

136

ROLAP (Relational OLAP). Motor OLAP que utiliza una capa relacionalsubyacente para obtener los datos del cubo multidimensional.Rollup. Operación de decremento del nivel de detalle, opuesta a una operacióndrill-down.Slice and dice. Acción disponible en los paneles de control de los sistemasde inteligencia de negocio cuyo propósito es ir segmentando la información enpartes cada vez más pequeñas para mejorar el conocimiento al llegar a un nivelde detalle adecuado.Snowflake schema. El esquema de copo de nieve es un modelo de datos máscomplejo que el star schema. Las dimensiones del cubo multidimensional seconstruyen a partir de más de una tabla de datos.Sparsity. Término que describe la poca densidad de una tabla una base dedatos. Si una tabla tiene el 50 % de sparsity, indica que la mitad de los registrosde esa tabla o bien no tienen valor, o está a cero.SQL (Structured Query Language). Lenguaje de consultas a sistemas detipo RDBMS, que permite operaciones de lectura y escritura.Star schema. El esquema en estrella es un modelo de datos sencillo quecontiene una tabla de hechos y varias tablas de dimensión, para dotar al sistemade capacidades de análisis.Tabla de hechos. Tabla principal de una fuente de datos, que contiene losregistros asociados con las medidas definidas en el cubo multidimensional deun sistema OLAP.XML (eXtensible Markup Language). Formato de documento de textoutilizado para almacenar datos categorizados por marcas.

137

Bibliografía

[Agarwal et al., 1996] Agarwal, S., Agrawal, R., Deshpande, P., Gupta, A., Naugh-ton, J., Ramakrishnan, R., Sarawagi, S. On the computation of multidimensionalaggregates. Proceedings of 22nd International Conference on Very Large Data-bases, Mumbai, India; 1996, pp. 361-386.

[Apache, WWW] Apache Software Foundation. Disponible en: http://apache.org.[Último acceso Septiembre 2015]

[Apache Hadoop, WWW] Apache Hadoop. Disponible en: https://hadoop.apa-che.org. [Último acceso Septiembre 2015]

[Apache Spark, WWW] Apache Spark. Disponible en: http://spark.apache.org. [Úl-timo acceso Septiembre 2015]

[Barnard, 1938] Barnard, C. I. The Functions of the Executive. Cambridge, MA:Harvard University Press, 1938

[Boehnlein y Ulbrich vom Ende, 2000] Boehnlein, M., Ulbrich vom Ende, A. Busi-ness process oriented development of data warehouse structures. Data Warehou-sing, 2000.

[Booth et al., 2004] Booth, D., et al. Web Service Architecture. W3C WorkingGroup Note, 2004. Disponible en: http://www.w3c.org/TR/ws-arch [Últimoacceso Septiembre 2015]

[Czernicki, 2010] Czernicki, B. Silverlight 4 Business Intelligence Software (Expert’sVoice in Silverlight) Apress; Segunda ed. 2010.

[Chu, 2004] Chu, R. Web services standards for data mining. Proceedings of 10thACM SIGKDD International Conference on Knowledge Discovery and Data Mi-ning, Seattle, WA; 2004, pp. 31-37.

[Codd et al., 1993] Codd, E.F., Codd, S.B., Salley, C.T. Providing OLAP (on-lineanalytical processing) to user analysts: An IT mandate. Technical Report, E.F.

139

Bibliografía

Codd and Associates, 1993.[Chaudhuri y Dayal, 1997] Chaudhuri, S., Dayal, U. An ovierview of data warehou-

sing and OLAP Technology. SIGMOD Record 26 (1) 1997.[Chaudhuri et al., 2001] Chaudhuri, S., Dayal, U., Ganti, V. Database technology for

decision support systems. IEEE Computer Magazine; 2001, no. 34, pp. 48-55.[Chaudhuri et al., 2011] Chaudhuri, S., Dayal, U., Narasayya, V. An overview of

business intelligence technology. Communications of the ACM; 2011, vol. 54, no.8, pp. 88-98.

[CSS, WWW] Cascade Style Sheets Disponible en: http://www.w3.org/Style/CSS.[Último acceso Septiembre 2015]

[da Silva et al., 2006] da Silva, J., Times, V.C., Salgado, A.C. An open-source andWeb based framework for geographic and multidimensional processing. Procee-dings of 2006 ACM Symphosium on Applied Computing, Dijon, France; 2006,pp. 63-67.

[Dean y Ghemawat, 2008] Dean, J., Ghemawat, S. MapReduce: Simplified DataProcessing on Large Clusters. Communications of the ACM, 51(1), 2008, pp.107-113.

[Dutta et al, 2011] Dutta, H., Kamil, A., Pooleery, M., Sethumadhavan, S., Demme,J. Distributed storage of large-scale multidimensional electroencephalogram datausing Hadoop and Hbase. Grid and Cloud Database Management, Springer,2011.

[Essbase, WWW] Hyperion Essbase Disponible en: http://www.oracle.com/tech-network/middleware/essbase/overview/index.html. [Último acceso Septiembre2015].

[Ferris, 2013] Ferris, J. A new American Way of War? C4ISR, Intelligence andInformation Operations in Operation Iraqi Freedom: A Provisional Assessment.Intelligence and National Security, 2013, 18(4).

[Fildalgo et al., 2002] Fidalgo, R. do N., Times, V.C., de Souza, F. da F. ProvidingOLAP interoperability with OLAPWare. Proceedings of XXII International Con-ference of the Chilean Computer Science Society (SCCC’02), Copiapo, Atacama,Chile; 2002, pp. 167-176.

[Fiser et al., 2004] Fiser, B., Onan, U., Elsayed, I., Brezany, P. On-line analyti-cal processing on large databases managed by computational grids. Proceedingsof 15th International Workshop on Database and Expert Systems Applications(DEXA’04), Zaragoza, Spain; 2004, pp. 556-560.

[Giorgini et al., 2007] Giorgini, P., Rizzi, S., Garzetti, M. GRAnD: A goal-oriented

140

Bibliografía

approach to requirement analysis in data warehouses. Decision Support Systems,2007, vol 45 (1), pp. 4-21.

[Golfarelli et al., 1998] Golfarelli, M., Maio, D., Rizzi, S. The Dimensional Fact Mo-del: A Conceptual Model for Data Warehouses. International Journal of Coope-rative Information Systems, 1998, 7(2-3), pp. 215-247.

[Gupta et al., 1995] Gupta, A., Harinarayan, V., Quass, D. Aggregate-query proces-sing in data warehousing environments. Proceedings of 21st VLDB Conference,Zurich, Swizerland; 1995, pp. 358-369.

[Gupta y Mumick, 1999] Gupta, A., Mumick, I.S. (eds.) Materialized Views: Tech-niques, Implementations and Applications. MIT Press: Cambridge, MA, 1999.

[IBM, WWW] “Big data at the speed of business”, IBM Report. Disponible en:http://www.ibm.com/software/data/bigdata. [Último acceso Julio 2015].

[Inmon, 2005] Inmon, W.H. Building the Data Warehouse. Wiley, 2005.[Jaspersoft, WWW] JasperSoft. Disponible en: http://www.jaspersoft.com. [Último

acceso Septiembre 2015].[Jboss, WWW] Jboss. Disponible en: http://www.jboss.org [Último acceso Septiem-

bre 2015].[Jensen et al., 2004] Jensen, M., Holmgren, T., Pedersen, T. Discovering Multi-

dimensional Structure in Relational Data. Data Warehousing and KnowledgeDiscovery. Springer Berlin Heidelberg, 2004, pp. 138-148.

[Jinguo et al., 2008] Jinguo, Y., Jianqing, X., Pingjian, Z. A parallel algorithm forclosed cube computation. Proceedings of 7th IEEE/ACIS International Confe-rence on Computer and Information Science (ICIS08), 2008, pp. 95-99.

[JOLAP, WWW] Java Specification Requests. Java OLAP Interface (JOLAP) ,2000. Disponible en: http://jcp.org/jsr/detail/69.jsp. [Último acceso Septiembre2015].

[JPivot, WWW] JPivot. Disponible en: http://jpivot.sourceforge.net. [Último acce-so Septiembre 2015].

[JSP, WWW] Java Server Pages Disponible en: http://www.ora-cle.com/technetwork/java/jsp-138432.html. [Último acceso Septiembre 2015]

[Kimbal, 2008] Kimbal, R. The data warehouse Lifecycle Toolkit. Wiley, 2008.[HTTP, WWW] HTTP. Disponible en: http://www.w3.org/protocols. [Último acce-

so Septiembre 2015].[Larson, 2009] Larson, B. Delivering Business Intelligence with Microsoft SQL Ser-

ver 2008. MacGraw Hill, 2009.

141

Bibliografía

[Lönnqvist y Pirttimäki, 2006] Lönnqvist, A., Pirttimäki, V. The measurement ofBusiness Intelligence. Information Systems Management; Invierno 2006, 23(1),pp. 32-40.

[Madeira et al., 2003] Madeira, H., Costa, J., Vieira, M. The OLAP and data wa-rehousing approaches for analysis and sharing of results from dependability eva-luation experiments. Proceedings of 2003 International Conference on Dependa-ble Systems and Networks ( DSN’03), San Francisco, CA; 2003, pp. 86-91.

[MDAPI, WWW] OLAP Council. MDAPI Specification Version 2.0, 1998. Disponi-ble en: http://www.olapcouncil.org/research/apily.htm. [Último acceso Septiem-bre 2015].

[MDX, WWW] Multidimensional Expressions. Disponible en: http://technet.micro-soft.com/en-us/library/ms145973.aspx. [Último acceso Septiembre 2015].

[Miller, 2010] Miller, H. J. The Data Avalanche is here. Shouldn’t we be digging?.Journal of Regional Science, 2010, vol. 50(1), 181-201.

[Mondrian, WWW] Mondrian. Disponible en: http://mondrian.pentaho.org,http://sourceforge.net/projects/Mondrian. [Último acceso Septiembre 2015].

[Moorman, 1999] Moorman, M. The art of designing HOLAP databases. Procee-dings of 1999 XXIV Annual SAS Users Group International Conference, paper139, Miami Beach, FL, 1999.

[Mumick et al., 1997] Mumick, I.S., Quass, D., Mumick, B.S. Maintenance of datacubes and summary tables in a warehouse. Proceedings of 1997 ACM SIG-MOD International Conference on Management of Data, Tucson, AZ, 1997; pp.100-111.

[Murray, WWW] Murray, G. Asynchronous JavaScript Technology and XML(AJAX) With Java 2 Platform, Enterprise Edition. Disponible en:http://www.oracle.com/technetwork/articles/java/ajax-135201.html. [Últimoacceso Septiembre 2015]

[Negash y Gray, 2003] Negash S, Gray P. Business Intelligence. Proceedings of theAmericas Conference on Information Systems, 2003.

[OLAP Council, WWW] OLAP Council. Disponible en: http://www.olapcoun-cil.org. [Último acceso Septiembre 2015]

[OLAP Report, WWW] OLAP Report. Disponible en: http://www.olapreport.com.[Último acceso Septiembre 2015]

[OLE DB, WWW] Microsoft Corporation. OLE DB, 2002. Disponible en:http://msdn.microsoft.com/en-us/library/ms717005(VS.85).aspx. [Último acce-so Septiembre 2015].

142

Bibliografía

[Oliveira y Bernardino, 2006] Oliveira, R., Bernardino, J. Building OLAP tools overlarge databases. Proceedings of IADIS Virtual Multi Conference, 2006.

[Open OLAP, WWW] Open OLAP. Disponible en: http://sourceforge.jp/projec-ts/openolap. [Último acceso Septiembre 2015].

[Oren et al., 2011] Øren, O., Lauren, M. K., Phister Jr, P. W., Gillespie, T., West,R., Nissen, M. E., Leweling, T. A. Moving the limits of military experience.International C2 Journal, 2011, 4(2).

[Oueslati y Akaichi, 2010] Oueslati, W., Akaichi, J. A survey on Data Warehouseevolution. International Journal of Database Management Systems (IJDMS), ,Noviembre 2010, vol. 2(3).

[Palo, WWW] Palo. Disponible en: http://www.palo.net. [Último acceso Septiembre2015].

[Pendse, 2003] Pendse, N. “What is OLAP?”, The OLAP Report, 2003. Dispo-nible en: http://dssresources.com/papers/features/pendse04072002.htm. [Últimoacceso Septiembre 2015].

[Pentaho, WWW] Pentaho, Open Source Business Intelligence. Disponible en:http://www.pentaho.com. [Último acceso Septiembre 2015]

[Power, WWW] Power, D.J. A Brief History of Decision Support Systems.DSSResources.COM Disponible en: http://DSSResources.COM/history/dsshis-tory.html. [Último acceso Septiembre 2015].

[QlikTech:1, 2000] QlikTech International AB. Method and a device for displayinginformation about a large number of independent data elements. U.S. Patent6,037,938 B1, 2000.

[QlikTech:2, 2001] QlikTech International AB. Method and device for extractinginformation from a database. U.S. Patent 6,236,986 B1, 2001.

[QlikTech:3, 2006] QlikTech International AB. Method for extracting informationfrom a database. U.S. Patent 7,058,621 B1, 2006.

[QlikView, WWW] QlikView. Disponible en: http://www.qlik.com/us/explore/pro-ducts/qlikview. [Último acceso Septiembre 2015]

[Radar O’Reilly, WWW] Disponible en: http://radar.oreilly.com/2012/01/what-is-big-data.html. [Último acceso Septiembre 2015].

[SAP/BW, WWW] SAP Business Information Warehouse (SAP/BW) Disponibleen: http://go.sap.com/index.html. [Último acceso Septiembre 2015].

[Sendin-Raña et al., 2009] Sendín-Raña, P., González-Castaño, F.J., Pérez-Barros,E., Rodríguez-Hernández, P.S., Gil-Castiñeira, F., Pousada-Carballo, J.M. Im-

143

Bibliografía

proving the performance and functionality of Mondrian open-source OLAP sys-tems. Software Practice and Experience; 2009, no. 39, pp. 279-298.

[Sendin-Raña et al., 2010] Sendín-Raña, P., Rodríguez-Hernandez, E., González-Castaño, F.J., Costa-Montenegro, E., Rodríguez-Hernández, P.S., Pousada-Carballo, J.M., Burguillo-Rial, J.C. We-oriented business intelligence solutionbased on Associative Query Logic. Software Practice and Experience; 2010, no.40, pp. 779-796.

[SOAP, WWW] SOAP Specifications. Disponible en: http://www.w3.org/TR/soap.[Último acceso Septiembre 2015].

[Song et al., 2015] Song, J., Guo, C., Wang, Z., Zhang, Y., Yu, G., Pierson, J.-M.HaoLap: a Hadoop based OLAP system for big data. Journal of Systems andSoftware, Elsevier, 2015, vol. 102, pp. 167-181.

[Spofford et al., 2006] Spofford, G., Harinath, S., Webb, C., Huang, D.H., Civar-di, F. MDX Solutions with Microsoft SQL Server Analysis Services 2005 andHyperion Essbase. Wiley: New York, 2006.

[SSAS, WWW] Microsoft SQL Server Analysis Services Disponible en: https://tech-net.microsoft.com/es-es/library/ms175609(v=sql.90).aspx. [Último acceso Sep-tiembre 2015].

[Struts, WWW] Apache Foundation Struts Framework. Disponible en: http://s-truts.apache.org [Último acceso Septiembre 2010]

[Tableau, WWW] Tableau. Disponible en: http://www.tableausoftware.com. [Últi-mo acceso Septiembre 2015]

[Thalhammer y Schrefl, 2002] Thalhammer, T., Schrefl, M. Realizing active datawarehouses with off-the-self database technology. SoftwarePractice and Expe-rience; 2002, no. 32, pp. 1193-1222.

[Thomsen et al., 1999] Thomsen, E., Spofford, G., Chase, D. Microsoft OLAP So-lutions. Wiley: New York, 1999.

[Thusoo et al., 2009] Thusoo, A., Sarma, J.S., Jain, N., Shao, Z., Chakka, P., Ant-hony, S., Liu, H., Wyckoff, P., Murthy, R. Hive: a warehousing solution over amap-reduce framework. Proceedings of the VLDB Endowment, 2009, vol. 2 (2),pp. 1626-1629.

[Tian, 2008] Tian, X. Large-scale SMS messages mining based on MapReduce. IEEEInternational Symposium on Computational Intelligence and Design, 2008, pp.7-12.

[Tomcat, WWW] Tomcat. Disponible en: http://tomcat.apache.org. [Último accesoSeptiembre 2015].

144

Bibliografía

[Watson y Wixsom, 2007] Watson, H.J., Wixsom, B.H. The current state of Busi-ness Intelligence. Computer 40(9), 2007.

[Williams y Williams, 2003] Williams, S., Williams, N. The Business Value of Bus-siness Intelligence. Business Intelligence Journal, Otoño 2003, 8(4).

[Winter y Strauch, 2003] Winter, R., Strauch, B. A method for demand-driven in-formation requirements analysis in data warehousing Proceedings of Hawaii In-ternational Conference on System Sciences, 2003, pp. 1359-1365.

[XML, WWW] XML Specification. Disponible en: http://www.w3.org/-TR/2000/REC-xml-20001006. [Último acceso Septiembre 2015].

[XML/A:1, WWW] XML/A. Disponible en: https://technet.microsoft.com/en-us/library/ms187178(v=sql.90).aspx. [Último acceso Septiembre 2015].

[XML/A:2, WWW] XML for Analysis Specification Version 1.0. Microsoft Corpo-ration and Hyperion Solutions Corporation (20 de Noviembre de 2002).

[Wang et al., 2014] Wang, B., Gui, H., Roantree, M., O’Connor, M. F. Data CubeComputational Model with Hadoop MapReduce. Proceedings of 10th Internatio-nal Conference on Web Information Systems and Technologies (WEBIST 2014),2014.

[Wang y Ye, 2014] Wang, Y., Ye, X. Index-based OLAP aggregation for In-MemoryCluster Computing. Proceedings of International Conference on Cloud Compu-ting and Big Data (CCBD), 2014, pp. 148-151.

[Zaman y Schneider, 2005] Zaman, K.A., Schneider, D.A. Modeling and queryingmultidimensional data sources in siebel analytics: A federated relational system.Proceedings of 2005 ACM SIGMOD International Conference on Managementof Data, Baltimore, MD; 2005, pp. 822-827.

[Zhuge et al., 1995] Zhuge, Y., Garcia-Molina, H., Hammer, J., Widom, J. Viewmaintenance in a warehousing environment. Proceedings of ACM SIGMOD1995 International Conference on Management of Data, San Jose, CA; 1995, pp.506-521.

145

Contribución a las tecnologías de representación de datos ...

Documents

Transcript of Contribución a las tecnologías de representación de datos ...