Implementación de una interfaz gráfica para hacer uso de las librería OLAP API de Oracle

Texto completo

(1)UNIVERSIDAD DE LOS ANDES DEPARTAMENTO DE INGENIERÍA DE SISTEMAS PROYECTO DE TESIS. IMPLEMENTACIÓN DE UNA INTERFAZ GRÁFICA PARA HACER USO DE LAS LIBRERIAS OLAP API DE ORACLE®. FECHA: PROFESOR ASESOR: ALUMNO: CÓDIGO:. AGOSTO 5 DE 2004 JOSÉ ABASOLO JUAN CARLOS MENDOZA 199811129 1.

(2) Tabla de Contenidos 1. Introducción..................................................................................................................6 2. Objetivos generales.......................................................................................................7 3. Objetivos específicos....................................................................................................7 4. Marco teórico................................................................................................................8 4.1. Modelo multidimensional.........................................................................................8 4.2. ¿Qué es OLAP?.......................................................................................................11 4.2.1. Las 12 reglas de Codd......................................................................................12 4.3. El metadata OLAP..................................................................................................14 4.3.1. Dimensiones.....................................................................................................16 4.3.2. Jerarquías.........................................................................................................16 4.3.3. Niveles.............................................................................................................16 4.3.4. Atributos..........................................................................................................17 4.4. Arquitecturas OLAP...............................................................................................17 4.4.1. ROLAP............................................................................................................17 4.4.2. MOLAP............................................................................................................19 4.4.3. HOLAP............................................................................................................21 5. Estado del arte.............................................................................................................21 5.1. Sobre los APIs OLAP.............................................................................................22 5.1.1. Metadata...........................................................................................................23 5.1.2. Modelo de consultas........................................................................................24 5.1.3. Modelo de datos...............................................................................................25 5.2. XMLA.....................................................................................................................25 5.2.1. Discover...........................................................................................................26 5.2.2. Execute.............................................................................................................27 5.3. JOLAP.....................................................................................................................30 5.3.1. Arquitectura.....................................................................................................30 5.3.2. Niveles de implementación .............................................................................31 5.3.3. Paquetes propuestos.........................................................................................32 5.3.4. Especificación de los paquetes en detalle........................................................32 5.4. ORACLE OLAP API..............................................................................................38 5.4.1. Desarrollo de una aplicación con el API OLAP..............................................38 5.4.2. Acciones que una aplicación con el API OLAP debe ejecutar........................39 5.4.3. Componentes del API......................................................................................39 6. Requerimientos...........................................................................................................42 6.1. Requerimientos no funcionales...............................................................................42 6.1.1. Desempeño.......................................................................................................42 6.1.2. Interacción usuario aplicación.........................................................................42 6.1.3. Infraestructura de red.......................................................................................43 2.

(3) 6.1.4. Infraestructura de hardware..............................................................................43 6.1.5. Plataforma........................................................................................................43 6.2. Casos de uso............................................................................................................44 7. Arquitectura de la aplicación......................................................................................48 7.1. Descripción de componentes y diagramas de clases...............................................49 7.1.1. Kernel...............................................................................................................50 7.1.2. Metadata...........................................................................................................51 7.1.3. Consultas..........................................................................................................52 7.1.4. Comandos........................................................................................................55 7.1.5. Interfaz gráfica.................................................................................................56 8. Resultados Obtenidos..................................................................................................57 9. Recomendaciones futuras............................................................................................58 10. Bibliografía...............................................................................................................58. 3.

(4) Índice de ilustraciones Ilustración 1: Ejemplo de modelo dimensional.................................................................11 Ilustración 2: Modelo de consulta OLAP sobre SQL........................................................18 Ilustración 3: Modelo de arquitectura ROLAP..................................................................19 Ilustración 4: Arquitectura MOLAP..................................................................................20 Ilustración 5: Arquitectura de la aplicación.......................................................................49 Ilustración 6: Componente yolap.kernel............................................................................50 Ilustración 7: Componente yolap.metadata........................................................................51 Ilustración 8: Componente yolap.query.............................................................................53 Ilustración 9: Componente yolap.command......................................................................55 Ilustración 10: Componente yolap.gui...............................................................................56. 4.

(5) Índice de Tablas Tabla1: Ejemplo de tabla asimétrica..................................................................................37 Tabla 2: Caso de uso 1.......................................................................................................44 Tabla 3: Caso de uso 2.......................................................................................................44 Tabla 4: Caso de uso 3.......................................................................................................45 Tabla 5: Caso de uso 4.......................................................................................................45 Tabla 6: Caso de uso 5.......................................................................................................46 Tabla 7: Caso de uso 6.......................................................................................................46 Tabla 8: Caso de uso 7.......................................................................................................47 Tabla 9: Caso de uso 8.......................................................................................................47 Tabla 10: Caso de uso 9.....................................................................................................48. 5.

(6) 1 Introducción Las bases de datos relacionales han servido durante ya varios años como soporte indispensable a las aplicaciones de manejo de información de forma transaccional pemitiendo que muchos procesos que llevan a cabo las organizaciones sean controlados, agilizados y monitoreados. Estas bases de datos relacionales almacenan a lo largo del tiempo una gran cantidad de información sobre las transacciones típicas de. dichas. organizaciones. La información esta siendo insertada o modificada en un curso de utilización normal, sin embargo, el potencial real de esta información va mucho más allá del simple control de las transacciones; se ve la necesidad de ordenarla y usarla para ser utilizada en el proceso de toma de decisiones.. Cuando se genera la necesidad de utilizar esta información para ser analizada posteriormente, las bases de datos relacionales que manejan dichas transacciones se ven limitadas en algunos aspectos.. En primer lugar, el hecho de que las operaciones estén soportadas por estas bases de datos implica que están siendo alimentadas constantemente y un proceso de extracción constante de datos en grandes volúmenes podría afectar radicalmente su funcionamiento y desempeño. En este punto se ve la necesidad de copiar dicha información en otra fuente cuyo objetivo principal sea el de consulta.. En segundo lugar, los modelos relacionales tienen una complejidad alta para un usuario promedio y los modelos pueden ser difíciles de entender. Por esto surge la necesidad de generar un modelo unificado de almacenamiento, fácil de entender y de consultar.. 6.

(7) Por último, la forma tanto física como lógica en la cual se almacena la información relacional no es suficiente para satisfacer las necesidades de rendimiento esperadas en un sistema de sólo consulta sobre grandes volúmenes de datos. Aquí surge entonces la propuesta de almacenar dicha información de forma óptima para los objetivos que se buscan.. La funcionalidad de OLAP (Online Analitical Process) de la mano del modelo dimensional que en adelante se describirá, presenta una solución simple, práctica y de alto impacto en una organización que necesite este tipo de análisis sobre la información.. 2 Objetivos generales Desarrollar una herramienta que permita hacer análisis dimensional OLAP usando las librerías (API) OLAP proveídas por ORACLE® como middleware para acceder a los datos persistentes en una base de datos relacional. Esta aplicación será básicamente una interfaz gráfica para generar reportes dinámicamente.. 3 Objetivos específicos 1. Hacer un análisis de los estándares existentes para manejo de ambientes OLAP y establecer la similaridad con el API desarrollado por ORACLE®. 2. Definir una arquitectura ntier que independice la interfaz de la fuente de datos. 3. Especificar la funcionalidad de la herramienta por fases (casos de uso). 4. Diseñar y desarrollar la fase I de la herramienta (interfaz gráfica). 7.

(8) 4 Marco teórico 4.1 Modelo multidimensional El modelo dimensional es un modelo que puede ser tanto lógico como físico. Que el modelo sea lógico significa que la forma de presentación y manipulación de la información se hace a través de él, mientras que un modelo físico significa que los datos son almacenados siguiendo dicho modelo.. Para el caso específico de OLAP el modelo multidimensional puede ser físico y lógico o solamente lógico. Existen varias razones por las cuales una aplicación OLAP utiliza este modelo:. 1. Hace el proceso de análisis de información más sencillo de entender para los usuarios finales en cuanto a que se presenta más natural. 2. Permite obtener rendimientos mucho mayores con grandes cantidades de información. 3. Es fácilmente extensible, modificable y reutilizable. 4. Es un modelo estandarizado y adoptado ampliamente. 5. Permite bajo los mismos conceptos básicos, modelar muchos tipos diferentes de problemas en una gran variedad de ambientes diferentes. 6. Tiene estrategias claras para mejorar el rendimiento.. La implementación de una solución para la toma de decisiones busca responder preguntas sobre el negocio. La respuesta a estas preguntas permitirá en últimas que las personas que. 8.

(9) toman decisiones en una organización puedan aprender de su historia y así tener una memoria corporativa. Las preguntas que se podrían responder son, por ejemplo: “¿cuántos productos para animales se vendieron en las sucursales del norte?”. Es importante aclarar que estas preguntas pueden ser de una complejidad mucho mayor.. El modelo dimensional esta orientado a hechos (facts, medidas) o a partes de un negocio tales como las ventas, los pedidos, entre otros. Estos hechos representan finalmente una medida cuantitativa de algún procedimiento o transacción llevada a cabo. Cada una de estas transacciones normalmente es asociada a ciertas variables.. Si se toma como ejemplo una tienda de minoreo, una transacción de venta estaría compuesta por la cantidad de productos, el precio de venta de cada uno, la información del producto, cliente, vendedor, fecha, tienda, entre otros. Para este caso particular los hechos son las medidas de cantidad. y costo de venta de cada producto por dicha. cantidad. Las otras variables que se ven involucradas (información de cliente, producto, etc.) son lo que normalmente se conoce como. dimensiones. En una venta, las. características demográficas de unos clientes pueden ser similares a otros, , como por ejemplo, la ciudad de residencia, la edad, el sexo, etc. Aquí ya se puede ver que una venta es realmente un grupo de valores cuantitativos numéricos asociado a atributos cualitativos determinados. El objeto de un análisis de venta no sería el de establecer cuántos productos compró un cliente particular pero si cuántos compraron los hombres en la tienda de Barranquilla en el segundo trimestre del año. Nótese que la pregunta que se sugiere puede no tener sentido pero uno de los objetivos de OLAP es que cualquier pregunta pueda ser formulada indistintamente y la responsabilidad de interpretación queda sujeta al usuario.. 9.

(10) El modelo dimensional se basa en las nociones que provee el modelo relacional tales como tablas, llaves foráneas y llaves primarias, para proveer una abstracción sobre estas herramientas. Es de notar que para las herramientas OLAP no es necesario que el modelo relacional sea físico en cuanto a que pueden existir aplicaciones de éste estilo que almacenen sus datos en diversos formatos como archivos, bases de datos relacionales y bases de datos multidimensionales.. El modelo dimensional cuenta con una tabla central que contiene las medidas o hechos y que tiene el nombre de tabla de hechos. Esta tabla establece una relación con otras tablas que representan las dimensiones. La mayoría de campos en la tabla de hechos son llaves foráneas a las tablas de las dimensiones y cuenta con los campos que contienen los hechos.. Más adelante se explica en detalle cada uno de éstos objetos del modelo relacional y que son denominados el metadata.. 10.

(11) CUSTOMER_DIM Key Nombre Sexo Mes_nacido. VENTAS_HECHOS Time_key Product_key Customer_key Cantidad Ventas_pesos. TIME_DIM Key Day Week Year period. PRODUCT_DIM Key Type Size Color. Ilustración 1: Ejemplo de modelo dimensional. 4.2 ¿Qué es OLAP? OLAP traduce Online Analitical Process y es básicamente un ambiente computacional interactivo que permite hacer análisis sobre cantidades considerables de información con el objetivo de hacer descubrimientos descriptivos sobre ésta.. Por esta razón una aplicación OLAP debe estar soportada por una fuente de datos persistente que contenga información histórica y debe proveer una interfaz consistente para su acceso.. OLAP está soportado por un modelo abstracto de almacenamiento y consulta llamado modelo dimensional. Este es hasta ahora el modelo más aceptado en este tipo de. 11.

(12) aplicaciones en cuanto provee una forma estandarizada y sencilla de acceder a la información.. 4.2.1 Las 12 reglas de Codd En 1993, E.F. Codd y asociados publicaron un artículo titulado ‘Providing OLAP (On line Analytical Processing) to UserAnalysts: An IT Mandate’ en donde exponían 12 reglas claras que se debían seguir para lograr un ambiente OLAP. Aunque estas reglas hoy en día han sido muy discutidas no dejan de ser útiles para comprender muchos de los requerimientos no funcionales de una aplicación OLAP. A continuación se hará una breve descripción de dichas reglas iniciales.. 4.2.1.1 Vista conceptual multidimensional La mayoría de expertos entendidos en el tema de OLAP y las bodegas de datos concuerdan en que el mejor modelo para hacer análisis descriptivo de información histórica es el multidimensional y entre sus razones más importantes se encuentra el hecho que este modelo es de fácil entendimiento para personas no familiarizadas con el mundo de los sistemas de información. Por esto un ambiente OLAP, aunque no restringe el modelo persistente de datos, si exige que su vista conceptual sea multidimensional.. 4.2.1.2 Transparencia Una aplicación OLAP puede obtener su información persistente de fuentes heterogéneas de datos sin que esto implique que el usuario final deba percibir el ambiente de una forma diferente. Se debe tener en cuenta que los usuarios OLAP son, la mayoría de veces, personas que estudian disciplinas diferentes a la computacional.. 12.

(13) 4.2.1.3 Accesibilidad El ambiente OLAP debe proveer un único esquema lógico consistente de la información.. 4.2.1.4 Rendimiento consistente. Esta es una de las reglas más difíciles de cumplir a la luz de la cantidad de datos que una aplicación OLAP involucra, pero a su vez es muy importante debido a que tanto la información histórica como las dimensiones en un modelo, pueden aumentar en drásticamente en el tiempo.. Esta regla establece que el rendimiento de una aplicación debe ser lineal a medida que aumentan los datos y las dimensiones. Esto no es más que escalabilidad.. 4.2.1.5 Arquitectura cliente-servidor En esta regla se encuentra la base para el estudio realizado en este documento. Y aunque su nombre lo dice, la arquitectura clienteservidor, que podría ser ampliada a una arquitectura multi capas, ofrece un ambiente abierto multiusuario que permite la centralización de la información.. 4.2.1.6 Dimensionalidad genérica El modelo dimensional debe no solo permitir n dimensiones sino permitir toda la funcionalidad a cada una de ellas.. 13.

(14) 4.2.1.7 Manejo dinámico de la matriz de esparcimiento Debido a que una aplicación OLAP maneja grandes cantidades de información y muchos de estos campos contienen datos vacíos o nulos, estas aplicaciones deberán manejar de manera ágil y automática la compresión, agregación y cache de dicha información.. 4.2.1.8 Soporte multiusuario Como todos los sistemas multiusuario una aplicación OLAP debe ofrecer concurrencia, seguridad y transaccionalidad.. 4.2.1.9 Operaciones a través de todas las dimensiones Es similar a la regla 6. Todas las dimensiones deben ser creadas con las mismas reglas y se debe poder operar indiscriminadamente por todas ellas.. 4.2.1.10Manipulación intuitiva Las operaciones que se realizan deben involucrar pocos pasos y su uso debe ser lo más sencillo y robusto posible.. 4.2.1.11Flexibilidad en los reportes Los usuarios deben poder ver y buscar lo que quieren. Los reportes deben reflejar los cambios hechos en los datos.. 4.2.1.12Dimensiones ilimitadas Deberá soportar al menos entre 15 y 20 dimensiones en un solo esquema.. 4.3 El metadata OLAP Ya se explicó brevemente como funciona el modelo relacional pero falta mostrar un poco 14.

(15) en detalle los tipos de objetos que se involucran dentro de un modelo dimensional y que hacen parte de la metadata de éste.. Primero que todo, metadata significa “el modelo que describe el modelo”. Este término es muy común en el ámbito OLAP debido a que las aplicaciones que presentan la funcionalidad al usuario final normalmente “descubren” las fuentes de datos, lo que añade una gran flexibilidad a la hora de usar una aplicación OLAP. En últimas, el metadata es una descripción del modelo relacional que se está trabajando, así que cada cubo o modelo OLAP tendrá asociado un modelo dimensional que será descrito por este metadata. Los objetos más comunes de un modelo metadata de OLAP son:. 1. Esquemas 2. Dimensiones 3. Jerarquías 4. Niveles 5. Medidas o Hechos 6. Cubos 7. Vértices 8. Atributos. Medidas Son valores numéricos casi siempre aditivos o promediables. Las medidas son las que capturan la información cuantitativa que finalmente se va a analizar agrupándose a través de las dimensiones. Algunas medidas también pueden ser calculadas a partir de otras. 15.

(16) medidas, por ejemplo, una medida de utilidad será calculada como el precio de venta menos el precio de costo.. 4.3.1 Dimensiones Las dimensiones son una estructura que categoriza los datos. Normalmente una dimensión esta asociada con una o mas jerarquías. Siempre deben ser combinadas con las medidas para lograr satisfacer los requerimientos de los usuarios finales.. 4.3.2 Jerarquías Las jerarquías permiten organizar por niveles una dimensión para permitir al usuario navegar a través de ellas. Las jerarquías son muy comunes en casi cualquier modelo del mundo que se haga. En OLAP y en el modelo dimensional, las jerarquías están dadas según el caso particular que se esté trabajando. Por ejemplo, es claro que en las unidades de tiempo existen jerarquías: un año contiene doce meses y un mes contiene 28 o más días. Existen dos tipos de jerarquías, las simétricas y las asimétricas. Las primeras son aquellas en las cuales cada elmento del mismo nivel tiene el mismo número de hijos. El tiempo es un ejemplo de jerarquía simétrica. Las segundas son las que no tienen una forma definida. Una jerarquía de productos representa una jerarquía asimétrica.Por ejemplo, el nivel “prendas de vestir” tiene como hijos “ropa masculina” y “ropa femenina” y el nivel “calzado” tiene como hijos “calzado elegante” y “calzado casual”.. 4.3.3 Niveles Es una posición en una jerarquía. Estos niveles están ordenados dentro de las jerarquías para permitir navegar a través de ellos. 16.

(17) 4.3.4 Atributos Es la característica descriptiva de un elemento de una dimensión. Un atributo podría ser por ejemplo “nombre de almacén”, en la dimensión geográfica.. 4.4 Arquitecturas OLAP Los ambientes OLAP ofrecen una interfaz homogénea para presentar los datos a los usuarios, es decir, la mayoría de las aplicaciones ofrecen funcionalidades muy similares a estos. Por otro lado, la implementación puede tener varios “sabores” y formas arquitectónicas. Aquí se introducen entonces los modelos de arquitectura más comunes en un ambiente OLAP.. 4.4.1 ROLAP Su nombre traduce Relational OLAP y básicamente es un modelo OLAP cuya fuente de datos es una base de datos relacional con alguna capa de abstracción para soportar el modelo dimensional. Este tipo de arquitecturas ofrecen ciertas ventajas tales como:. 1. Se pueden tener las bases de datos operativas (que son relacionales) y las OLAP en el mismo espacio y si ambas son del mismo proveedor es posible que el método de extracción y carga sea más ágil y sencillo. 2. Se pueden aprovechar los estándares que ofrecen las bases de datos relacionales para el acceso a la información tales como SQL. 3. Las personas encargadas de las bases de datos operativas (DBAs) pueden a su vez ejercer funciones administrativas sobre la base de datos OLAP. 4. La información puede ser almacenada más eficientemente sacando provecho de 17.

(18) los muchos años de investigación que llevan las empresas proveedoras de bases de datos relacionales. 5. Su mantenimiento es sencillo así como su actualización y modificación. 6. Su arquitectura esta muy enfocada a los componentes en cuanto se puede hacer de varias capas.. Los sistemas ROLAP almacenan la información en tablas bajo un diseño dimensional ya sea de estrella o de copo de nieve. Los agregados se implementan con vistas materializadas de consultas típicas sobre los datos. Una consulta típica sobre una base de datos ROLAP en SQL sería del estilo:. SELECT SUM(medidas) FROM DIMENSION_UNO, DIMENSION_DOS, TABLA_HECHOS WHERE JOIN ENTRE TABLA DE HECHO Y DIMENSIONES, CONDICIONES SOBRE LAS DIMENSIONES GROUP BY CAMPOS DE AGRUPAMIENTO SOBRE LAS DIMENSIONES ORDER BY CONDICION DE ORDEN. Ilustración 2: Modelo de consulta OLAP sobre SQL. En el siguiente gráfico se muestra la arquitectura ROLAP. 18.

(19) Ilustración 3: Modelo de arquitectura ROLAP. Aquí la información es obtenida por un servidor de aplicaciones usando para esto otro servidor de metadata para descubrir la información y así presentar la funcionalidad a los clientes ya sea a través de aplicaciones web, clientes livianos o clientes pesados.. 4.4.2 MOLAP Las siglas traducen Multidimensional OLAP y a diferencia de ROLAP éste provee una vista multidimensional de la información y no es una abstracción sobre el modelo relacional. La ventaja más importante de un modelo MOLAP es su alto rendimiento y las principales características de esta arquitectura son:. 1. Almacenan información en arreglos de n dimensiones donde los contenidos del arreglo son las medidas o hechos del cubo. Cada una de las dimensiones del arreglo representa a su vez las dimensiones del cubo. 2. Requiere, para ser modificado, que estos arreglos sean recalculados.. 19.

(20) 3. No pueden almacenar grandes cantidades de información. 4. Sólo se puede acceder al cubo desde la aplicación que conoce el formato en el que se guardó la información. 5. Algunas pueden tener la información localmente o remotamente.. En este tipo de arquitecturas el proceso más complicado es el de extracción de información pero una vez que se logra, la eficiencia es notable.. A continuación se muestra una gráfica con la arquitectura MOLAP.. Ilustración 4: Arquitectura MOLAP. En este caso la información histórica se encuentra almacenada en una bodega de datos (puede ser cualquier fuente de datos). Un servidor de aplicaciones crea los cubos extrayendo la información de la bodega de datos sirviéndose del servidor de metadata para ésto. Los clientes pueden tener aplicaciones livianas o pesadas. En este escenario los 20.

(21) clientes acceden finalmente al cubo OLAP a través del servidor de aplicaciones.. 4.4.3 HOLAP Sus siglas traducen Hybrid OLAP, lo que significa que es una combinación entre arquitecturas ROLAP y MOLAP. Aquí la información puede estar guardada de forma relacional y además ofrecer opciones para extraerla y guardarla en cubos multidimensionales. La ventaja de este modelo es que provee las ventajas de los dos mundos. Por esta razón, muchos proveedores de aplicaciones de este estilo están adoptando esta arquitectura.. La base de datos ORACLE® es un ejemplo de un motor HOLAP ya que puede guardar la información tanto en un modelo relacional como dimensional. En principio se tiene la información en modelo relacional pero luego puede ser cargado en un espacio analítico que es de naturaleza multidimensional.. 5 Estado del arte En los objetivos generales se especificó claramente que para desarrollar la aplicación OLAP se usará una librería (API) OLAP desarrollada por ORACLE®. Ésta decisión fue tomada después de haber analizado dos estándares para middleware OLAP importantes en la industria: JOLAP (Java OLAP) y XMA (XML for Analysis). El primero es una propuesta estándar de un API OLAP para ser usado en ambientes puramente Java y que viene siendo desarrollado por un grupo llamado The Java Community Process dentro del cual se encuentran inscritos para este proyecto, entre otros, ORACLE® Corporation, Sun Microsystems e Hiperion. El segundo es una propuesta abierta de un estándar OLAP 21.

(22) para web services en la cual están involucradas compañías como Microsoft, Hiperion y SAS entre otras.. Ambos estándares están ya especificados pero la decisión de usar un API propietario se debe al hecho que éste ya ha sido desarrollado en su totalidad, además de que la compañía que lo desarrolló se encuentra liderando el grupo que desarrolló el estándar JOLAP que de hecho es, a la fecha, muy reciente para tener implementaciones estables. El otro estándar (XMLA) también es una propuesta que merece ser revisada pero de igual manera, aunque ya existen implementaciones, no se cuenta con los recursos para usarlas.. Aunque se ha tomado la decisión de usar librerías propietarias ya desarrolladas, este marco teórico tratará de hacer un análisis de ambos estándares así como de las librerías a usar. Se espera que, luego de analizar el estándar JOLAP y el API OLAP de ORACLE®, se encuentre que ambos cuentan con similitudes tales que la aplicación a desarrollar pueda ser fácilmente modificada para usar JOLAP como capa de middleware.. 5.1 Sobre los APIs OLAP Antes de comenzar la explicación de las diferentes propuestas de estándares para librerías OLAP de middleware será interesante plantear algunas nociones comunes a todas, las cuales pueden servir de introducción para facilitar su entendimiento.. Hay diferencias notables entre unas especificaciones y otras en lo que se refiere a OLAP, pero hay una funcionalidad común entre ellas que es muy importante: el manejo de metadata, un lenguaje o funcionalidad para hacer consultas y unas estructuras de datos para manipular la información. 22.

(23) 5.1.1 Metadata En un modelo multidimensional enfocado a OLAP es necesario que las aplicaciones cliente “descubran” el modelo sobre el que se va a hacer análisis y esto se debe a varios factores.. El modelo dimensional mantiene un comportamiento que sigue unas reglas sencillas y, ya sea que se use un modelo de estrella o de copo de nieve, siempre se cuenta con la noción de dimensiones y hechos que se modelan homogéneamente de aplicación a aplicación.. Mediante el uso de metadata para descubrir en tiempo de ejecución el modelo se pueden lograr capas genéricas tanto de interfaz gráfica como de middleware que permiten su adaptación a cualquier tipo de problema multidimensional que exista sin tener que decodificar ninguna de las dos capas antes mencionadas.. El metadata permite entonces descubrir en tiempo de ejecución aspectos como los hechos, dimensiones, niveles, tipos de datos, operaciones de agregación y otros aspectos.. Esta área es ahora altamente discutida mundialmente y es centro de gran atención por parte de los más importantes desarrolladores de software en el planeta. La razón es que a medida que pasa el tiempo las organizaciones van acumulando grandes cantidades de información en una gran variedad de plataformas y formatos diferentes y surge entonces la necesidad de que exista un intercambio efectivo de información entre todas ellas. Por 23.

(24) esta razón se propone un estándar que describa las fuentes de datos: Propuesto en 1998, desarrollado en la OMG (CORBA, UML entre otros estándares) y auspiciado por las más grandes compañías de software del mundo en lo concerniente a Data Warehousing, CWM (Common Warehouse Metamodel) es una propuesta que promete facilitar el intercambio de metadata entre aplicaciones que ayudan a la toma de decisiones. Además de esto, Sun Microsystems se compromete con una implementación para la plataforma Java que ahora es ejemplo de desarrollo abierto.. Pero el estándar CWM no está solo: Su implementación se apoya en tecnologías abiertas como UML, XMI, MOF y CORBA. Esto muestra el interés mundial por adoptar estándares que faciliten la integración entre sistemas propietarios. El desarrollo de estándares de comunicación de información, de generación de modelos a partir de meta modelos, el uso de XML y DTD y otras propuestas de generar reglas unificadas abiertas, favorecerá en gran medida a usuarios y diseñadores de recursos informáticos que ahora podrían hacer diseños cuyas piezas están unidas por interfaces estandarizadas con una gran variedad de implementaciones a lo largo del mercado informático. Esto permitiría hacer un desarrollo arquitectónico sin las piezas precisas. Una analogía interesante son, por ejemplo, los estándares mecánicos: cuando se construye una máquina, muchos ingenieros hacen el diseño usando medias estándares de tornillos, de rodamientos y diámetros de diversas piezas y pueden lograr un diseño completo sin haber comprado las piezas concretas porque saben que a la hora de construirlas pueden conseguir en el mercado una gran variedad de ofertas diferentes, tanto en precio como en calidad. Así mismo podría llegar a suceder con el software.. 5.1.2 Modelo de consultas Dentro de la funcionalidad de una librería OLAP, así como en el estándar JDBC, existe un método para formular consultas sobre la información que se encuentra en la capa de. 24.

(25) datos. En el caso de XMLA se propone el estándar MDX pero se abre la posibilidad a los proveedores de esta implementación de proponer sus propios lenguajes de consulta.. 5.1.3 Modelo de datos Siguiendo con la analogía con JDBC que particularmente ofrece estructuras de datos (i.e. ResultSet) que deben ser usadas para mantener localmente la información, ambos estándares también proponen un modelo de datos especializado y optimizado para OLAP que facilita la manipulación de información dimensional.. 5.2 XMLA XMLA traduce XML for Analysis y es un estándar para aplicaciones OLAP propuesto por un grupo de organizaciones líderes en la industria de software que ofrecen aplicaciones que apoyan la toma de decisiones basándose en información histórica de las empresas. Este grupo está liderado por Microsoft Corporation y ya cuenta con alrededor de 20 adeptos entre los cuales están Hiperion, SAS, Microestrategy y Cognos, entre otros.. La idea principal de XMLA es la de hacer un estándar abierto multiplataforma para el cual se ofrezcan implementaciones en cada una de las plataformas interesadas y en cualquier lenguaje y sistema operacional. Para lograrlo este grupo decidió realizar la especificación enfocada a Web Services usando el estándar SOAP para comunicación de llamados remotos a aplicaciones a través de XML.. Un comando XMLA puede tener dos métodos diferentes: discover y execute.. 25.

(26) 5.2.1 Discover Este método sirve para obtener información tal como la lista de fuentes de datos disponibles en el servidor y detalles específicos de la fuente de datos. La información que retorna depende de los parámetros que sean pasados en el método.. La sintaxis de este método es la siguiente:. Discover ( [in] RequestType As EnumString, [in] Restrictions As Restrictions, [in] Properties As Properties, [out] Result As Rowset) A continuación se explicará brevemente los parámetros y su uso.. 5.2.1.1 Tipo de pedido (RequestType) Es un parámetro de entrada que determina el tipo de información que será retornada en el método. Consiste en una enumeración de RequestTypes que sirve al método discover para determinar el formato en el que se debe retornar la información.. Entre algunas de las funcionalidades esta:. 1. Descubrir las fuentes de datos 2. Descubrir las propiedades 3. Descubrir los rowsets del esquema 26.

(27) 4. Descubrir las enumeraciones. 5. Descubrir los literales.. 5.2.1.2 Restricciones (Restrictions) Este parámetro permite al usuario restringir los resultados que devuelve el método. Estos parámetros son opcionales.. 5.2.1.3 Propiedades (Properties) Este parámetro consiste en una colección de propiedades de XML for Análisis. Cada propiedad permite al usuario controlar algún aspecto del método como el tipo de formato de retorno o el tiempo de espera (timeout).. 5.2.1.4 Resultado (Result) Este es el parámetro de salida del método y viene en formato RowSet. Las columnas de este resultado dependen directamente de los parámetros de entrada del método.. 5.2.2 Execute Este método sirve para enviar requerimientos de información al servidor. Incluye pedidos que involucren transferencia de datos como consultas o actualizaciones.. La sintaxis del método es la siguiente:. 27.

(28) Execute ( [in] Command As Command, [in] Properties As Properties, [out] Result As Resultset) Los parámetros son los que voy a describir a continuación. 5.2.2.1 Comando (Command) Es un parámetro de entrada y debe tener el comando en un lenguaje de consulta o actualización proveído por el vendedor de la aplicación. Todos deben soportar el lenguaje mdXML que es un lenguaje para hacer consultas multidimensionales.. 5.2.2.2 Propiedades (Properties) Estas propiedades le permiten al usuario controlar algunos aspectos del parámetro de retorno tales como el formato, el lenguaje en el que deben ser formateados los resultados y se puede definir la información para la conexión.. 5.2.2.3 Resultado (Result) Este es el parámetro de salida. En este debe ir la información que resulta de la consulta, por lo tanto, su formato debe ser multidimensional describiendo el cubo que se pidió con sus medidas, dimensiones y vértices.. Este resultado (ResultSet) tiene una estructura de dos partes. La primera parte es la descripción o metadata del cubo que se retorna y la segunda son los datos en si. La 28.

(29) primera parte se denomina OLAPInfo y la segunda consta de Ejes, y celdas.. 5.2.2.3.1 OLAPInfo Aquí se define la estructura del resultado. Los objetos principales de los que consta son:. 1. CubeInfo: Que contiene información sobre el cubo como el nombre. 2. AxisInfo: Define la información sobre los ejes del cubo. 3. CellInfo: Define la información sobre las celdas o medidas.. 5.2.2.4 Datos En los datos entonces se encuentran, ya con el formato que fue especificado en el OLAPInfo, los datos concreto del cubo. Los elementos con los que cuenta son:. 1. Ejes: Tiene el conjunto de ejes del cubo. Cada eje puede ser representado como un producto cartesiano de dos conjuntos o simplemente con una enumeración de tuplas o con una combinación de los dos formatos. 2. Celdas: Aquí se encuentran los datos de las medidas o celdas del cubo. Cada objeto de estos tiene un numero único. Cuando se tiene la ubicación de coordenadas dentro del cubo, este número sirve para saber cuál de las celdas corresponde a dicha ubicación.. 29.

(30) 5.3 JOLAP JOLAP es una especificación que busca ser un estándar para la industria en lo que se refiere a funcionalidad OLAP en el middleware. Fue propuesto por varias compañías multinacionales de software muy importantes como Hiperion y ORACLE®, entre otras. La idea principal es lograr un API de interfaces análogo al estándar JDBC para las bases de datos relacionales pero para bases de datos OLAP. Esta especificación, igual que JDBC, está hecha para ser implementada en el lenguaje JAVA y para que cada proveedor de software OLAP provea su propio driver. A continuación voy a hacer una breve descripción de la estructura de la especificación.. 5.3.1 Arquitectura La arquitectura de JOLAP cuenta con cuatro componentes principales: un modelo de metadata, un modelo de query, un modelo para hacer consultas personalizadas y un modelo de datos (cursores).. 5.3.1.1 Meta-modelo Esta especificación esta basada en la especificación de la OMG llamada Common Datawarehouse Metamodel (CWM)1 y como su nombre lo dice es el modelo de metamodelo que soporta JOLAP para poder descubrir y describir la fuente de datos con la cual se va a trabajar.. 1. Esta especificación está diseñada para que diversas fuentes de datos relacionales e interfaces que usan esta información puedan intercambiarla fácilmente usando un estándar basado en XML. URL: http://www.omg.org/cwm/. 30.

(31) 5.3.1.2 Query model Este componente presenta interfaces especializadas en la ejecución de queries. En este componente, el grupo desarrollador de la especificación hizo un gran esfuerzo porque logró establecer una estructura que no requiriera de un lenguaje especifico como SQL o MDX. Esto da a la especificación una característica adicional de portabilidad.. 5.3.1.3 Source model Este componente presenta interfaces para extender el modelo de query ya presentado. Está para ser usado en casos donde las consultas tienen una complejidad tal que no es posible realizarlas usando el modelo común de query.. 5.3.1.4 Cursor Model Este componente representa el modelo de datos de JOLAP análogo al ResultSet de JDBC. Esto quiere decir que por medio de las interfaces proveídas por este componente es posible manipular la información que se obtiene de las consultas. Su especificación es bastante robusta porque debe permitir funcionalidades como cache entre otras que mas adelante se expondrán.. 5.3.2 Niveles de implementación La especificación define que pueden haber dos niveles posibles de implementación:. 1. Nivel 1: Cumple con todos los requerimientos excepto con el componente Source model. 2. Nivel 2: Cumple con el nivel 2 y con el Source Model. 31.

(32) 5.3.3 Paquetes propuestos Los paquetes propuestos son los siguientes:. •. javax.olap.metadata (contiene la funcionalidad de metadata). •. javax.olap.serversidemetadata (permite tener driver en el cliente y en el servidor que intercambien metadata vía CWM). •. javax.olap.resource (maneja los recursos de jolap como creación de clases y conexiones). •. javax.olap.query (interfaces para realizar consultas). •. javax.olap.cursor (interfaces para manipular la información extraída de la fuente de datos). •. javax.olap.sourcemodel (paquete extendido de consultas opcional). 5.3.4 Especificación de los paquetes en detalle. 5.3.4.1 Source model Este paquete permite crear una conexión con la fuente de datos y sigue un patrón similar al ConnectionFactory proveído por JDBC. Las interfaces más importantes de las que consta son:. •. ConnectionFactory: Se encarga de crear las conexiones con la fuente de datos. 32.

(33) •. Connection: Permite abrir y cerrar una conexión, obtener las dimensiones, cubos y esquemas (objetos metadata) de la fuente de datos.. •. Abortable: esta interfaz es implementada por Connection y contiene únicamente el método abort que sirve para abortar una conexión cuando ésta demanda mucho tiempo en alguna operación o a petición del usuario.. 5.3.4.2 Metadata model Debe permitir representar esquemas OLAP en una manera flexible independiente de la implementación. Utilizan el CWM metamodelo de OLAP como la definición básica.. Se pueden desarrollar dos implementaciones: Una del lado del servidor y otra del lado del cliente. La primera utiliza para hacer pedidos del driver cliente al servidor (usa CWM y XML) y la segunda para proveer funcionalidad de metadata al usuario final.. En la especificación del lado del cliente se cuenta con las siguientes clases importantes:. •. Esquema. •. Cubo. •. Dimensión. •. Nivel. •. Jerarquía. 33.

(34) 5.3.4.3 Query model Provee un mecanismo para obtener la información OLAP valiéndose de los elementos del modelo metadata. Los usuarios crean queries instanciando clases de este modelo y pasándoselas al modelo de metadata.. Entre las clases principales del modelo están:. •. Dimension queries. •. Edge queries. •. Data queries. 5.3.4.3.1 Dimensión queries Estos operan sobre los miembros de las dimensiones. Representan acceso a atributos de objetos dentro de dichas dimensiones tales como jerarquías, niveles, entre otras.. Se pueden manipular tres aspectos de dichos queries:. •. Especificación de los atributos de cada miembro que serán obtenidos.. •. Filtrar sobre esos atributos para restringir el número de miembros.. •. Ordenar sobre los atributos para definir el orden.. Estos queries son agregado por los edge queries que a su vez son agregados por los data queries.. 34.

(35) 5.3.4.3.2 Edge queries Consiste en un conjunto de uno o más Dimension queries que describen un eje en el resultado. En estas combinaciones de dimensiones se puede especificar si se desea el resultado como un producto cartesiano de los elementos de cada dimensión o como una serie de tuplas asimétricamente ordenadas.. 5.3.4.3.3 Data queries Estos devuelven los datos de un cubo. Para hacerlo deben especificar la combinación de miembros que identifican las coordenadas de los datos deseados dentro del cubo. Este query agrega dimensiones y debe contener al menos una dimensión de medidas.. 5.3.4.4 Cursor model Los requerimientos para el modelo de cursor de JOLAP son:. •. Completitividad. •. Presentación multidimensional. •. Flexibilidad en la navegación.. •. Asimetría. •. Espacio virtual del resultado. •. Asociación con el query. 35.

(36) 5.3.4.4.1 Completitividad El cursor debe ser capaz de guardar información de cualquier consulta que pueda ser generada por el usuario.. 5.3.4.4.2 Presentación multidimensional Un cursor debe tener elementos que faciliten la presentación multidimensional de la información. Esto significa que debería tener elementos de una consulta multidimensional como los vértices.. 5.3.4.4.3 Flexibilidad en la navegación Deberá permitir que la presentación de la navegación se haga en una variedad de formas:. •. Una presentación tabular donde cada dimensión y cada medida corresponden a una columna.. •. Una presentación de tabla cruzada donde múltiples dimensiones anidadas son ordenadas en un eje.. •. Una presentación de tabla cruzada compleja donde las dimensiones anidadas pueden ser movidas independientemente en la vista.. 5.3.4.4.4 Asimetría Los reportes son asimétricos en cuanto los resultados de una dimensión son dependientes 36.

(37) de los resultados de otra. Por ejemplo, si se quiere obtener para cada estado los productos que representaron ventas por más de una cantidad en el vértice anidado de estados y productos puede haber, para el caso de California dos productos y para el caso de Texas diez productos, lo que lo hace asimétrico. La tabla siguiente muestra este ejemplo:. ENERO. CALIFORNIA PROD B. PROD A. PROD C. TEXAS PROD A. Tabla1: Ejemplo de tabla asimétrica. 5.3.4.4.5 Espacio virtual del resultado El resultado de una consulta puede ser enorme lo que impide que los recursos tanto de red como de memoria logren satisfacer la demanda de información. Muchas de las aplicaciones restringen al usuario haciendo que éste condicione su consulta antes de ejecutarla, sin embargo, esta situación no es del todo natural. El cursor debe permitir que se obtenga solo alguna parte de la información que el usuario solicitó en la consulta.. 5.3.4.4.6 Asociación con el query Si los usuarios ejecutan acciones de drill, rotación, pívot usualmente hacen clic sobre elementos de la interfaz que finalmente se representan en cambios sobre la consulta. Por esta razón el cursor debe ofrecer una forma para obtener el modelo que fue usado para generar la consulta y así poder hacer modificaciones.. 5.4 ORACLE® OLAP API ORACLE® ofrece, incluido dentro de su base de datos un API OLAP que provee funcionalidad para conectarse a una fuente de datos OLAP de ORACLE® a través de un 37.

(38) driver JDBC. Toda la información concerniente a este API y que será expuesta a continuación fue obtenida directamente del libro “Developer's guide to the OLAP API, 10g release” .. 5.4.1 Desarrollo de una aplicación con el API OLAP En esta sección se especifican los pasos a seguir para desarrollar una aplicación de usuario final con este API:. 1. Tomar las decisiones de diseño tales como la arquitectura de capas 2. Levantar los requerimientos para los usuarios finales 3. Diseñar los templates para crear las consultas (opcional) 4. Escribir y probar el código JAVA 5. Hacer deploy de la aplicación. Esta metodología no tiene nuevos descubrimientos. En general estos serán los pasos a llevar a cabo en el momento de desarrollar la interfaz gráfica.. 5.4.2 Acciones que una aplicación con el API OLAP debe ejecutar Aquí se muestra una secuencia de las acciones que se deben llevar a cabo para ejecutar una aplicación usando este API. El desarrollo se basará en esta secuencia como orden de implementación del puente con JOLAP.. 38.

(39) 1. Conectarse a la fuente de datos 2. Descubrir el metadata disponible 3. Generar y ejecutar consultas 4. Desplegar los resultados. 5.4.3 Componentes del API. 5.4.3.1 Metadata Como en JOLAP este API presenta una serie de clases análogas que representancada uno de los elementos de un modelo dimensional OLAP. Estos elementos son:. 1. Dimensión 2. Nivel 3. Jerarquía 4. Medida 5. Atributo. Aquí se puede ver que los modelos OLAP normalmente tienen tipos de objetos comunes por lo que no se hará mucho énfasis en ellos hasta la etapa misma de la implementación.. 5.4.3.2 Conexión a la fuente de datos Para conectarse a la fuente de datos es necesario contar con un driver de JDBC que 39.

(40) funcione para una base de datos ORACLE®. Cuando esté funcionando dicho driver se deben seguir los pasos usuales de obtención de una conexión JDBC para luego, a partir de la conexión obtener dos objetos: TransactionDataProvider y DataProvider. De estos dos objetos se obtiene luego un objeto MdmMetadataProvider que será el que finalmente permitirá descubrir el metadata en la fuente de datos.. 5.4.3.3 Consultas La funcionalidad de este API gira alrededor de un objeto llamado Source. Este objeto se obtiene directamente de los objetos metadata o de las operaciones entre objetos de tipo Source y en el reside la información de los atributos. Para hacer una consulta se crean objetos de este tipo a partir de objetos del mismo tipo especificando los parámetros de filtro, join, ordenamiento y ranking. Es decir, a partir de un objeto Source, pasándole parámetros de consulta, se obtiene otro objeto source que puede luego ser usado en un join de múltiples dimensiones.. 5.4.3.4 Cursores Los objetos Cursor se crean a partir de los objetos Source de las consultas usando el objeto DataProvider que representa la conexión. Este proceso es básicamente de tres pasos.. 1. Obtener un objeto CursorManagerEspecification pasándole el objeto Source al DataProvider en un método. 2. Obtener. un. CursorManager. del. CursorManagerEspecification.. 40. DataProvider. pasándole. el. objeto.

(41) 3. Finalmente se crea el Cursor pidiéndoselo al CursorManager.. Esta arquitectura permite entre otras cosas.. 1. Crear varios cursores del mismo objeto CursorManager con diferentes parámetros 2. Actualizar el objeto CursorManagerEspecification para un CursorManager.. Existen objetos Source para los cuales se dan algunos casos específicos:. 1. El objeto Source especifica una operación computacionalmente imposible como una recursión infinita. 2. El objeto Source representa un conjunto de datos infinito. 3. El objeto Source que no tiene elementos o contiene objetos del mismo tipo que no tienen elementos.. 41.

(42) 6 Requerimientos 6.1 Requerimientos no funcionales 6.1.1 Desempeño El desempeño es un requerimiento crítico de esta aplicación ya que debido a la naturaleza de los usuarios es necesario que se obtengan los resultados concretos en un tiempo muy corto dependiendo del tipo de consulta que se desee hacer.. 6.1.2 Interacción usuario aplicación La visión general en cuanto a los requerimientos de navegabilidad son los siguientes:. •. Presentación del modelo OLAP de la forma más universal y abstracta posible para que los usuarios que tengan claros los conceptos OLAP estén en capacidad de hacer uso de la aplicación de forma satisfactoria.. •. Los usuarios deben estar en capacidad de navegar a través de un modelo OLAP haciendo un número reducido de comandos sobre la interfaz gráfica. Esto significa que la aplicación esta lista para usar en el momento en el que el usuario la accede.. •. La presentación gráfica debe ser consistente en todo momento permitiendo así que el usuario pueda usar casi cualquier funcionalidad después de conocer el funcionamiento de una sola de ellas.. •. El usuario debe estar en todo momento enterado del progreso de su interacción 42.

(43) con la aplicación, es decir, debe visualizar a todo momento su consulta. •. El sistema siempre debe responder ante un comando ejecutado por el usuario. En caso de que una operación tome más tiempo del esperado el usuario no deberá pensar que la aplicación no responde.. 6.1.3 Infraestructura de red El sistema requiere una infraestructura de red básica con las siguientes características.. 1. Conexión a través del protocolo TCP/IP 2. Especificación Ethernet o de más velocidad.. 6.1.4 Infraestructura de hardware 6.1.4.1 Cliente Es necesario que el cliente cuente con una máquina que soporte J2SE® de forma satisfactoria para el uso de las librerías gráficas SWING.. 6.1.4.2 Servidor El servidor de debe soportar una base de datos ORACLE® 10g funcionando como un servicio de red.. 6.1.5 Plataforma La aplicación debe correr en cualquier plataforma soportada por ORACLE® para el servidor y por J2SE® para el cliente. 43.

(44) 6.2 Casos de uso. Código Nombre Cliente Descripción Prioridad Curso eventos. Caminos excepción. CU01 Conectar a una fuente de datos Usuario El usuario se conecta a una fuente que provee los datos Alta 1. El usuario ingresa al sistema. 2. El sistema pide al usuario el URL del servidor, el nombre de la base de datos, el usuario y la contraseña. 3. El usuario llena los datos y acepta. 4. El sistema verifica que la fuente de datos sea OLAP. 5. Se sucede el caso de uso Obtener meta datos. 3. Si en el paso 3 el URL, el usuario o la contraseña son incorrectos el sistema notifica el error y vuelve al paso 2. 4. Si en el paso 4 la fuente de datos no es OLAP el sistema informa del error y vuelve a comenzar en el paso 2. Tabla 2: Caso de uso 1. Código Nombre Cliente Descripción Prioridad Prerrequisitos Curso eventos. Caminos excepción. CU2 Obtener meta datos Usuario Se obtiene una descripción de la fuente de datos OLAP del servidor Alta Existe una conexión válida a una fuente de datos OLAP • El usuario solicita al sistema la obtención de los meta datos. • El sistema se conecta a la fuente de datos, obtiene los nombres y descripciones de los cubos disponibles y pide al usuario que seleccione uno de ellos. • El usuario selecciona uno de los cubos disponibles y acepta. • El sistema obtiene las dimensiones, niveles, jerarquías y medidas del cubo que el usuario seleccionó, las presenta al usuario y genera un cubo en blanco para ser llenado. • Si en el paso 2 se genera un error en la conexión a la fuente de datos el sistema reporte el error y pregunta al usuario si desea repetir el proceso. Tabla 3: Caso de uso 2. 44.

(45) Código Nombre Cliente Descripción Prioridad Prerrequisitos Curso eventos. CU3 Agregar un nivel a un vértice Usuario Se agrega una dimensión a un o del los vértices del cubo Alta Debe haber un meta modelo cargado en la aplicación 6. El usuario selecciona un nivel de una jerarquía del meta modelo y un vértice al cual quiere mover dicho nivel (horizontal, vertical, página). 7. El sistema hace el movimiento del nivel mostrando todos los elementos de dicho nivel disponibles en el vértice seleccionado. Dichos vértices pueden ser el horizontal, vertical o el de página.. Caminos excepción Tabla 4: Caso de uso 3. Código Nombre Cliente Descripción Prioridad Prerrequisitos Curso eventos. CU4 Agregar una medida al cubo Usuario Se agrega una medida al cubo Alta Debe haber un meta modelo cargado en la aplicación. • El usuario escoge la opción de agregar medida, selecciona la medida correspondiente y acepta. • El sistema muestra los valores de la medida agregados bajo los criterios dimensionales especificados previamente para el cubo.. Caminos excepción Tabla 5: Caso de uso 4. 45.

(46) Código Nombre Cliente Descripción. CU5 Bajar de nivel en la jerarquía (drill down) Usuario Se cambia un nivel de una dimensión del cubo por todos sus hijos correspondientes en la jerarquía Prioridad Alta Prerrequisitos Debe existir un meta modelo cargado. Un nivel de la jerarquía debe estar en un vértice del cubo Curso 3. El usuario selecciona en el cubo el nivel sobre el que quiere eventos bajar en la jerarquía u da la opción de bajar de nivel. 4. El sistema reemplaza los valores del nivel con los de los niveles hijo correspondientes y recalcula los valores agregados de las medidas del cubo. Caminos excepción Tabla 6: Caso de uso 5. Código Nombre Cliente Descripción. CU6 Subir de nivel en la jerarquía (drill up) Usuario Se cambia un nivel de una dimensión del cubo por su padre correspondiente en la jerarquía Prioridad Alta Prerrequisitos Debe existir un meta modelo cargado. Un nivel de la jerarquía debe estar en un vértice del cubo Curso 5. El usuario selecciona en el cubo el nivel sobre el que quiere eventos subir en la jerarquía y da la opción de subir de nivel. 6. El sistema reemplaza los valores del nivel por el valor del nivel padre y recalcula los valores agregados de las medidas del cubo. Caminos excepción Tabla 7: Caso de uso 6. 46.

(47) Código Nombre Cliente Descripción Prioridad Prerrequisitos Curso eventos. CU7 Filtrar elementos de una dimensión (dice) Usuario Filtra los elementos de una dimensión Alta 1. El usuario selecciona el nivel de la jerarquía sobre el cual quiere aplicar el filtro y da la opción de filtrar. 2. El sistema pide al usuario ingresar el tipo de filtro que desea aplicar: por selección de miembros, por rangos, ranking. 3. El usuario selecciona la opción, llena los parámetros y acepta. 4. El sistema recalcula el cubo actual basado en los nuevos valores de la dimensión filtrada.. Caminos excepción Tabla 8: Caso de uso 7. Código Nombre Cliente Descripción Prioridad Prerrequisitos Curso eventos. CU8 Establecer operación de agregación sobre una medida Usuario Se establece que operación aplica el sistema para agregar medidas Media 7. El usuario selecciona la medida a la cual desea establecer la operación de agregación y selecciona la opción de cambiar operación de agregación 8. El sistema despliega las operaciones comunes de agregación: suma, promedio, máximo, mínimo, cuenta, producto. 9. El usuario selecciona una y acepta. 10. El sistema recalcula el cubo basándose en los nuevos valores de la operación de agregación.. Caminos excepción Tabla 9: Caso de uso 8. 47.

(48) Código Nombre Cliente Descripción Prioridad Prerrequisitos Curso eventos. CU9 Mover un elemento de una dimensión de un vértice a otro Usuario Mueve miembros de una dimensión entre vértices Alta 6. El usuario selecciona el miembro de un vértice que quiere mover y da la opción de mover. 7. El sistema le pide al usuario que especifique hacia que vértice (horizontal, vertical, página) quiere mover el miembro y en que posición quiere él que quede este miembro (principio, final). 8. El usuario elige las opciones y acepta. 9. El sistema recalcula el cubo con las nuevas modificaciones.. Caminos excepción Tabla 10: Caso de uso 9. 7 Arquitectura de la aplicación En el siguiente gráfico se muestra la arquitectura global de la propuesta OLAP de ORACLE®. La aplicación que se desarrolló es el componente de interfaz gráfica que se comunica con el API de OLAP proveido por ORACLE®. Este API a su vez utiliza la implementación del estandar JDBC de conectividad con bases de datos para conectarse con el motor de bases de datos ORACLE® en donde recide la funcionalidad OLAP necesaria para realizar los reportes. El motor de base de datos contiene un componente (API) adherido a ésta que provee directamente la funcionalidad de OLAP en lenguaje PL/SQL que es ejectuado por el API de OLAP a través de JDBC.. 48.

(49) INTERFAZ GRÁFICA YOLAP. ORACLE OLAP API. JDBC ORACLE JDBC DRIVER. MOTOR OLAP ORACLE. ORACLE DBMS BD RELACIONAL. Ilustración 5: Arquitectura de la aplicación. A continuación se describirá la arquitectura específica de la interfaz gráfica que se implementó, especificando cada uno de sus componentes.. 7.1 Descripción de componentes y diagramas de clases La arquitectura de la aplicación está diseñada de forma tal que pueda ser fácilmente adaptada a otras fuentes y APIs que provean servicios OLAP. Por esta razón el contenido esta constituido por interfaces implementables. Una implementación de dichas interfaces para la plataforma ORACLE® está en un estado de implentación básico.. La interfaz gráfica consta de seis componentes principales que son: kernel, metadata, query, conexión, comandos e interfaz gráfica. Todos estos componentes se encuentran especificados dentro del paquete yolap. Las implementaciones de estas interfaces para el caso específico de conexión con ORACLE® están dentro de paquete yolap.oracle. 49.

(50) 7.1.1 Kernel Este componente se encuentra en el paquete yolap.kernel y es el encargado de controlar, crear y mantener los objetos que hacen parte de todos los otros componentes de la aplicación. En la siguiente grafica se describe el diagrama de clases de este componente.. Ilustración 6: Componente yolap.kernel. La interfaz ReporterModel se encarga de mantener una lista de los objetos de tipo DataSourceModel. Estos últimos representan un reporte sobre un motor OLAP determinado que representa una fuente de datos como por ejemplo ORACLE®.. 50.

(51) La clase abstracta DataSourceProvider es un factory que tiene registradas las implementaciones de las fuentes de datos (DataSourceModel) y que tiene implementaciones para cada una de ellas.. 7.1.2 Metadata Este componente que se encuentra en el paquete yolap.metadata contiene una serie de interfaces y clases abstractas que representan de forma arborea la estructura de la metadata que se encuentra almacenada en el servidor con el fin de que el usuario final pueda generar los reportes seleccionando directamente en ésta los objetos que sean de su interés. El diagrama de clases que se presenta a continuación presenta la estructura del componente.. Ilustración 7: Componente yolap.metadata. El servidor de OLAP puede contener un número indeterminado de cubos. Por esta razón 51.

(52) existe la interfaz MetadataModel que se encarga de manejar una lista de dichos cubos logrando que el usuario pueda usarlos indiferentemente. La clase abstracta AbstractMetadataModel provee una implementación extendible de dicha interfaz. La intefaz CubeModel representa algún cubo que se encuentre dentro del modelo OLAP en el servidor. Esta clase extiende a su vez la interfaz javax.swing.tree.TreeModel y que representa un modelo de árbol gráfico de Java® . Al extender esta interfaz se esta asegurando que las clases de visualización gráfica proveidas por Java® puedan mostrar al usuario final la estructura de la metadata.. La interfaz MetadataObjectModel representa los objetos contenidos dentro de un cubo OLAP que normalmente se encuentran ordenados de forma jerárquica como son las Dimensiones, Esquemas, Niveles, Medidas y Atributos. La clase abstracta que implementa esta interfaz especifica de manera explícita el tipo de objeto de la metadata OLAP que representa. Esta interfaz extiende de javax.swing.tree.TreeNode de manera que puede ser usada en un modelo de árbol de interfaz gráfica de swing.. 7.1.3 Consultas Este componente se encuentra en el paquete yolap.query y es el encargado de proveer a la aplicación de la funcionalidad necesaria para generar y modificar las consultas que se hacen sobre el motor de OLAP de ORACLE®. En el diagrama de clases que se presenta a continuación se describe de forma gráfica este componente.. 52.

(53) Ilustración 8: Componente yolap.query. Para generar una consulta con el API OLAP de ORACLE® es necesario generar un objeto de tipo Source que proviene directamente de los objetos de la metadata y posteriormente se deben ejecutar ciertas operaciones sobre estos que llevan a la generación de clases de tipo Cursor. Existe la posibilidad de realizar todo este proceso de tal forma que las consultas de hagan de forma transaccional y dinámica, es decir, que el usuario pueda en tiempo de ejecución ir realizando modificaciones al estado actual de la 53.

(54) consulta. Para lograr esto es necesario extender tres tipos de clases: Template, MetadataState y SourceGenerator. La primera se encarga de prestar la funcionalidad de fachada para las consultas dinámicas, la segunda almacena los datos necesarios para realizar la consulta y la tercera genera los objetos Source bajo los parámetros establecidos por el programador.. Se definieron entonces varias clases de tipo Template que se encargan de mantener de forma anidada el estado de la consulta del usuario siguiendo la lógica de presentación. Cada una de estas clases esta acompañada de sus respectivas clases de tipo MetadataState y SourceGenerator. Se definió que una consulta OLAP tiene un conjunto de dimensiones para cada borde. Estos bordes pueden ser horizontales, verticales y de página.. La clase ReportTemplate representa el estado actual de la consulta global. La clase ReportMetadataState que lo acompaña contiene los objetos MeasureGroupTemplate y EdgeTemplate. La primera se encarga de controlar las operaciones sobre el grupo de medidas que componen la consulta y la segunda se encarga de controlar dichas operaciones sobre los tres tipos de bordes que puede tener esta consulta que pueden ser horizontales, verticales o de página. Ambas estan acompañadas por sus respectivos objetos de tipo MetadataState que contienen el estado de la consulta a un nivel de detalle mas específico para las medidas en el caso de la primera y de dimensiones en el caso de la segunda.. Cuando una consulta esta siendo generada el punto de entrada siempre será el objeto ReportTemplate que a su vez irá almacenando la información de dicha consulta en los objetos que contiene.. 54.

(55) 7.1.4 Comandos Este componente se encuentra en el paquete yolap.command y es básicamente un patrón de tipo command que se encarga de centralizar los comandos que se ejecutan sobre la aplicación en una lista que permite deshacer las acciones hechas por los usuarios. Este componente se hace con el fin de permitir al usuario volver a estados previos de la consulta. El gráfico que se muestra a continuación expone el diagrama de clases de este componente:. Ilustración 9: Componente yolap.command. La clase CommandFacade se encarga de mantener la lista de comandos que han sido 55.

(56) ejecutados y de ejecutar dichos comandos. Cuando un componente de la aplicación va a realizar una acción crea el objeto que implemente la interfaz Command y se la pasa a CommandFacade para que éste la ejecute.. 7.1.5 Interfaz gráfica Los objetos específicos de la interfaz gráfica se encuentran en el paquete yolap.gui. La mayoría de estos objetos son componentes que extienden de las librerias proveidas por Java® swing®. Estas clases tienen una jerarquía análoga a la de las clases del kernel y de los componentes de metadata y query y se encargan de presentar estos objetos del mundo al usuario final suministrándole los controladores necesarios para que éste los manipule. A continuación se presenta el diagrama de clases de este componente.. Ilustración 10: Componente yolap.gui. 56.

(57) La ventana principal de la aplicación esta implementada por la clase MainFrame. Ésta contiene el método main de entrada a la aplicación y su responsabilidad es cargar las barras de menús superiores así como los componentes de metadata y consulta. Extiende de la clase Frame del API swing de Java®.. La clase ReportComponent se encarga de contener la información de cada uno de los reportes sobre fuentes de datos OLAP que estan siendo ejecutados. Contiene los componentes gráficos MetadataComponent encargado de la visualización de la metadata OLAP de la fuente de datos y ReportViewComponent encargado de la visualización del reporte que esta siendo trabajado por el usuario final.. 8 Resultados Obtenidos A lo largo del proceso se lograron la mayoría de los objetivos específicos de este documento: se hizo una investigación exaustiva del estado del arte de las aplicaciones OLAP actuales y las ventajas y desventajas que éstas presentan; se estableció, con base en el API de ORACLE®, una arquitectura para la aplicación que permitiera implementaciones futuras en otras plataformas.. En la etapa de desarrollo surgieron problemas técnicos a la hora de implementar sobre las librerias OLAP de ORACLE® por lo cual el nivel de desarrollo no alcanzó el nivel esperado de avance. El alto nivel de bugs hizo necesario que fueran obtenidos los patches correspondientes para la base de datos que no fue suficiente para poner a punto los servicios que eran requeridos por la aplicación. Estos problemas podrían eventualmente ser resueltos por el personal de soporte técnico de ORACLE® por esta razón se. 57.