virtual dataport 4.0 guÍa del...

VIRTUAL DATAPORT 4.0 GUÍA DEL ADMINISTRADOR

NOTA Este documento es confidencial y propiedad de denodo technologies (en adelante denodo). Ninguna de las partes del documento puede ser copiada, fotografiada, fotocopiada, transmitida electrónicamente, almacenada en un sistema de gestión documental o reproducida mediante cualquier otro mecanismo sin la autorización previa o por escrito de denodo.

copyright © 2007 Queda prohibida la reproducción total o parcial de este documento sin la autorización por escrito de denodo technologies

Virtual DataPort 4.0 Guía del Administrador

ÍNDICE

PREFACIO........................................................................................................................................................................... I ALCANCE ..................................................................................................................................................................... I QUIÉN DEBERÍA USAR ESTE DOCUMENTO.......................................................................................................... I RESUMEN DE CONTENIDOS.................................................................................................................................... I

1 INTRODUCCIÓN ..................................................................................................................................... 2

2 ARQUITECTURA GENERAL................................................................................................................... 3 2.1 NIVEL FÍSICO .......................................................................................................................................... 4 2.2 NIVEL LÓGICO......................................................................................................................................... 5

2.2.1 Módulo de Datos: Caché........................................................................................................................... 6 2.3 NIVEL DE USUARIO ............................................................................................................................... 6

3 INSTALACIÓN......................................................................................................................................... 8 3.1 INSTALACIÓN......................................................................................................................................... 8

3.1.1 Requisitos Hardware................................................................................................................................. 8 3.1.2 Requisitos Software.................................................................................................................................. 8 3.1.3 Utilización de la herramienta de instalación ............................................................................................ 8 3.1.4 Instalación de la Licencia........................................................................................................................ 10

3.2 ESTRUCTURA DE LA DISTRIBUCIÓN ............................................................................................... 10 3.2.1 Distribución Cliente................................................................................................................................. 10 3.2.2 Distribución Completa............................................................................................................................. 11 3.2.3 Tareas de Post-Instalación...................................................................................................................... 12

4 EJECUCIÓN ........................................................................................................................................... 14 4.1 EJECUCIÓN DE LA HERRAMIENTA DE ADMINISTRACIÓN GRÁFICA DE VIRTUAL DATAPORT 14

5 ADMINISTRACIÓN DEL SERVIDOR .................................................................................................. 16 5.1 CONFIGURACIÓN DEL SERVIDOR..................................................................................................... 16

5.1.1 Puerto ...................................................................................................................................................... 16 5.1.2 Pool de Threads....................................................................................................................................... 17 5.1.3 Configuración de la Caché ...................................................................................................................... 18 5.1.4 Configuración de los parámetros de “swapping” a disco ...................................................................... 19 5.1.5 Configuración de Parámetros de Ejecución de Procedimientos Almacenados ...................................... 20 5.1.6 Configuración de Internacionalización por defecto ................................................................................ 22

5.2 CONFIGURACIÓN DE LOGS ................................................................................................................ 22 5.3 EXPORTACIÓN DE METADATOS DEL SERVIDOR........................................................................... 22

6 CREACIÓN VISUAL DE VISTAS.......................................................................................................... 23 6.1 ACCESO A LA HERRAMIENTA GRÁFICA DE ADMINISTRACIÓN ................................................ 23 6.2 CREACIÓN Y MANEJO DE PROYECTOS .......................................................................................... 23

6.2.1 Cambiar elementos a otros proyectos .................................................................................................... 24 6.3 IMPORTACIÓN DE DATASOURCES Y CREACIÓN DE RELACIONES BASE................................ 25

6.3.1 Importación de Fuentes de tipo JDBC .................................................................................................... 25 6.3.2 Importación de Fuentes de Tipo Web Service........................................................................................ 27 6.3.3 Eliminación de una fuente de datos ....................................................................................................... 28


6.3.4 Creación de Relaciones Base partiendo de una Base de Datos............................................................. 28 6.3.5 Viendo el esquema de una relación base............................................................................................... 30 6.3.6 Creación de Relaciones Base partiendo de un Web Service ................................................................. 32

6.4 CREACIÓN VISUAL DE VISTAS.......................................................................................................... 34 6.4.1 Creación de Vistas de Tipo Unión........................................................................................................... 34 6.4.2 Viendo el Esquema de una vista............................................................................................................. 36 6.4.3 Creación de Vistas de tipo Join .............................................................................................................. 37 6.4.4 Creación de Vistas de tipo Selección ..................................................................................................... 40 6.4.5 Creación de vistas de tipo Agregación ................................................................................................... 49 6.4.6 Creación de Vistas de tipo Proyección.................................................................................................... 54 6.4.7 Aplanamiento de campos de tipo array de registros.............................................................................. 56 6.4.8 Modo de visualización en forma de árbol............................................................................................... 61 6.4.9 Ejecución de vistas y uso de VQL Shell .................................................................................................. 62 6.4.10 Traza de Ejecución de una Sentencia ..................................................................................................... 65 6.4.11 Sustitución de la Definición de Una Vista .............................................................................................. 67

6.5 OTROS TIPOS DE FUENTES................................................................................................................ 68 6.5.1 Tipos de rutas en Virtual DataPort.......................................................................................................... 68 6.5.2 Fuentes ODBC ......................................................................................................................................... 70 6.5.3 Fuentes XML ........................................................................................................................................... 71 6.5.4 Fuentes Web ........................................................................................................................................... 73 6.5.5 Fuentes de ficheros delimitados............................................................................................................. 74 6.5.6 Fuentes Google Mini............................................................................................................................... 76 6.5.7 Fuentes Aracne ....................................................................................................................................... 80 6.5.8 Fuentes LDAP .......................................................................................................................................... 85 6.5.9 Fuentes CUSTOM.................................................................................................................................... 87 6.5.10 Fuentes JDBC/ODBC a través de SQL Query.......................................................................................... 90 6.5.11 Propiedades de Configuración de Fuentes de Datos.............................................................................. 92

6.6 CONFIGURACIÓN AVANZADA DE VISTAS...................................................................................... 94 6.6.1 Configuración de Internacionalización.................................................................................................... 94 6.6.2 Configuración de la cache de una vista.................................................................................................. 94 6.6.3 Configuración de swapping .................................................................................................................... 95 6.6.4 Edición del Plan de Ejecución ................................................................................................................. 95 6.6.5 Capacidades de consulta ........................................................................................................................ 97 6.6.6 Propiedades de Configuración de Vistas .............................................................................................. 100 6.6.7 Propiedades de Configuración para tipos específicos de Vistas.......................................................... 101

6.7 PROCEDIMIENTOS ALMACENADOS.............................................................................................. 101 6.7.1 Importación de Procedimientos Almacenados ..................................................................................... 102 6.7.2 Ejecución de Procedimientos Almacenados ......................................................................................... 103 6.7.3 Uso de Procedimientos Almacenados en la Creación de Vistas .......................................................... 105

7 PUBLICACIÓN DE SERVICIOS WEB................................................................................................ 106

8 BASES DE DATOS, USUARIOS Y PERMISOS EN VIRTUAL DATAPORT................................... 109 8.1 BASES DE DATOS EN VIRTUAL DATAPORT ................................................................................. 109 8.2 ESTRUCTURA DE USUARIOS Y PERMISOS EN VIRTUAL DATAPORT...................................... 109

8.2.1 Tipos de usuarios .................................................................................................................................. 109 8.2.2 Tipos de permisos ................................................................................................................................. 109

8.3 ADMINISTRACIÓN GRÁFICA DE BASES DE DATOS, USUARIOS Y PERMISOS..................... 111 8.3.1 Creación de Bases de Datos ................................................................................................................. 111 8.3.2 Configuración y Borrado de Bases de Datos ........................................................................................ 112 8.3.3 Creación de usuarios............................................................................................................................. 113 8.3.4 Modificación y Borrado de usuarios ..................................................................................................... 115

9 MONITORIZACIÓN DEL SERVIDOR DATAPORT ........................................................................... 119


9.1 UTILIZANDO JCONSOLE................................................................................................................... 119 9.2 INFORMACIÓN GENERAL SOBRE EL SERVIDOR.......................................................................... 124 9.3 INFORMACIÓN GENERAL SOBRE DATASOURCES...................................................................... 125 9.4 INFORMACIÓN SOBRE LA CACHE.................................................................................................. 125 9.5 INFORMACIÓN Y EVENTOS SOBRE EL ACCESO AL CATÁLOGO (SENTENCIAS DDL) .......... 126 9.6 INFORMACIÓN Y EVENTOS SOBRE LA EJECUCIÓN DE SENTENCIAS DML .......................... 128 9.7 INFORMACIÓN Y EVENTOS SOBRE TRANSACCIONES.............................................................. 129

10 ARQUITECTURAS EN CLUSTER / BACKUP DE SERVIDORES..................................................... 131 10.1 INSTALACIÓN DE LAS UTILIDADES............................................................................................... 131 10.2 USO DEL SCRIPT PING...................................................................................................................... 131 10.3 USO DE LOS SCRIPTS IMPORT / EXPORT PARA BACKUP Y/O REPLICACIÓN ....................... 132

11 APÉNDICES......................................................................................................................................... 134 CLIENTE DE LÍNEA DE COMANDOS .................................................................................................................. 134 DRIVERS JDBC ...................................................................................................................................................... 135

BIBLIOGRAFÍA ............................................................................................................................................................. 137


ÍNDICE DE FIGURAS Figura 1 Arquitectura de Virtual DataPort .............................................................................................................. 4 Figura 2 Pantalla inicial de instalación de la Plataforma Denodo.......................................................................... 9 Figura 3 Autenticación en la herramienta de administración .............................................................................. 15 Figura 4 Configuración de puertos........................................................................................................................ 17 Figura 5 Configuración de cache........................................................................................................................... 18 Figura 6 Configuración de Swapping.................................................................................................................... 20 Figura 7 Configuración de Ejecución de Sentencias dentro de Procedimientos Almacenados ........................... 21 Figura 8 Creación de un Nuevo proyecto.............................................................................................................. 24 Figura 9 Importación de una Fuente de Datos JDBC............................................................................................ 26 Figura 10 Configuración del Pool de conexiones JDBC.......................................................................................... 27 Figura 11 Importación de una fuente de datos de tipo Web Service..................................................................... 28 Figura 12 Esquemas y tablas de una fuente JDBC................................................................................................. 29 Figura 13 Aceptación del esquema de una relación base...................................................................................... 30 Figura 14 Esquema de la vista base phone_inc .............................................................................................. 31 Figura 15 Esquema de la vista base internet_inc .................................................................................... 32 Figura 16 Operaciones y parámetros de un Web Service ...................................................................................... 33 Figura 17 Esquema de la vista base average_monthly_sales.............................................................. 34 Figura 18 Construcción de la vista unión de phone_inc e internet_inc ........................................... 35 Figura 19 Esquema de la vista unificada de incidencias: incidences ........................................................... 36 Figura 20 Construcción de Vista join de incidences y average_monthly_sales ......................... 37 Figura 21 Esquema de la vista join incidences_sales ............................................................................. 39 Figura 22 Construcción de la vista selección pref_clients_inc_sales ............................................. 41 Figura 23 Editor de condiciones de selección......................................................................................................... 42 Figura 24 Creación de una constante ..................................................................................................................... 43 Figura 25 Creación de una condición simple .......................................................................................................... 44 Figura 26 Esquema de RevenueSum....................................................................................................................... 45 Figura 27 Editor de valores de tipos compuestos................................................................................................... 46 Figura 28 Creando un valor de tipo getSumRevenuebyTaxIds_IN0 .................................................... 47 Figura 29 Condición con valores de tipos compuestos........................................................................................... 48 Figura 30 Resultado de ejecutar la vista RevenueSum_Selection ......................................................... 49 Figura 31 Creación de la vista de agregación inc_group_by_pref_clients .................................... 50 Figura 32 Creación de vista agregación inc_group_by_pref_clients (2) ........................................ 51 Figura 33 Editor de expresiones de agregación...................................................................................................... 52 Figura 34 Creación de una expresión de agregación.............................................................................................. 53 Figura 35 Editor de expresiones de atributo derivado............................................................................................ 55 Figura 36 La operación getAverageMonthlyRevenue del Web Service sales................................ 57 Figura 37 Vista base creada por defecto para getAverageMonthlyRevenue ...................................... 58 Figura 38 Aplanando el array devuelto por average_revenue_array ................................................... 59 Figura 39 Esquema de salida de average_revenue_array aplanada ................................................... 60 Figura 40 Esquema de la vista aplanada ................................................................................................................ 61 Figura 41 Vista en árbol de incidences_sales ....................................................................................... 62 Figura 42 Ejecutando la vista incidences_sales .................................................................................... 63 Figura 43 Resultado compuesto por una única tupla con un campo de tipo array de registros ............................ 64 Figura 44 Viendo el contenido de un campo de tipo array de registros................................................................. 64 Figura 45 Traza de ejecución de la vista incidences..................................................................................... 66 Figura 46 Traza de ejecución con errores de una vista join ................................................................................... 67 Figura 47 Confirmación de la sustitución de una vista........................................................................................... 68 Figura 48 Proporcionando valores para las variables de interpolación.................................................................. 69 Figura 49 Importación de una fuente de datos ODBC ............................................................................................ 71 Figura 50 Importación de una fuente de datos XML .............................................................................................. 72 Figura 51 Descripción de una fuente XML.............................................................................................................. 73 Figura 52 Importación de un wrapper HTML creado con ITPilot ............................................................................ 74 Figura 53 Importación de una nueva fuente de ficheros delimitados .................................................................... 75


Figura 54 Descripción de una fuente de tipo ficheros delimitados........................................................................ 76 Figura 55 Importación de una nueva fuente de tipo Google Mini.......................................................................... 77 Figura 56 Descripción de la fuente Google Mini .................................................................................................... 78 Figura 57 Pantalla de creación de vista base en fuentes Google Mini.................................................................. 79 Figura 58 Pantalla de creación de una fuente de datos Aracne............................................................................. 81 Figura 59 Descripción de la fuente Aracne............................................................................................................. 82 Figura 60 Pantalla de creación de vistas base en fuentes Aracne......................................................................... 83 Figura 61 Añadiendo un atributo con los términos más relevantes del campo SEARCHABLECONTENT.............. 84 Figura 62 Creación de un datasource LDAP............................................................................................................ 86 Figura 63 Propiedades del datasource LDAP.......................................................................................................... 86 Figura 64 Importación de un wrapper CUSTOM..................................................................................................... 87 Figura 65 Nueva fuente de datos CUSTOM............................................................................................................ 88 Figura 66 Creación de una vista base en un Datasource CUSTOM ....................................................................... 89 Figura 67 Nueva vista base sobre un datasource CUSTOM................................................................................... 90 Figura 68 Creación de una vista base utilizando una query SQL............................................................................ 91 Figura 69 Editando el valor de las variables de interpolación................................................................................ 92 Figura 70 Pantalla de configuración avanzada de la vista average_monthly_sales............................ 94 Figura 71 Editando el Plan de Ejecución de una vista ............................................................................................ 96 Figura 72 Formulario de búsqueda para una tienda de libros ................................................................................ 99 Figura 73 Método de búsqueda para una tienda de libros..................................................................................... 99 Figura 74 Importación de un Procedimiento Almacenado.................................................................................... 102 Figura 75 Propiedades de un procedimiento almacenado.................................................................................... 103 Figura 76 Ejecución del procedimiento almacenado CalculateAvgRevenue........................................ 104 Figura 77 Resultado de la ejecución del procedimiento almacenado CalculateAvgRevenue.............. 105 Figura 78 Publicación de un Web Service ............................................................................................................ 106 Figura 79 Operaciones generadas para inc_grouped_by_pref_clients ...................................... 107 Figura 80 Creación de una base de datos............................................................................................................. 111 Figura 81 Descripción de una base de datos........................................................................................................ 112 Figura 82 Asignar privilegios sobre una base de datos........................................................................................ 113 Figura 83 Creación de un usuario de tipo normal ................................................................................................. 114 Figura 84 Creación de un usuario de tipo LDAP ................................................................................................... 115 Figura 85 Descripción de un usuario..................................................................................................................... 116 Figura 86 Asignación de privilegios a un usuario a nivel de base de datos ........................................................ 117 Figura 87 Asignación de privilegios a un usuario a nivel de vista y/o procedimiento almacenado .................... 118 Figura 88 Conexión a DataPort desde jConsole.................................................................................................... 120 Figura 89 MBeans de Virtual DataPort ................................................................................................................. 121 Figura 90 Pestaña Attributes del Mbean RequestsManagementInfo.................................................................. 122 Figura 91 Detalle de una consulta en jConsole .................................................................................................... 123 Figura 92 Detalle de una notificación en jConsole............................................................................................... 124 Figura 93 Sintaxis de la sentencia LSET............................................................................................................... 135


ÍNDICE DE TABLAS Tabla 1 Conversiones entre tipos de dato DataPort y tipos de parámetros de servicios web ......................... 108 Tabla 2 Drivers JDBC ......................................................................................................................................... 136 Tabla 3 Drivers MySQL, IBM, Microsoft y Sybase ............................................................................................ 136


Prefacio i

PREFACIO

ALCANCE

Denodo Virtual Data Port permite que las aplicaciones de negocio puedan acceder fácilmente a vistas integradas de distintas fuentes de información heterogéneas y distribuidas, estructuradas y no estructuradas. Este documento introduce al lector mediante ejemplos a la instalación, configuración y administración de Denodo Virtual DataPort, incluyendo la creación de vistas unificadas sobre fuentes de datos heterogéneas y distribuidas.

QUIÉN DEBERÍA USAR ESTE DOCUMENTO

Este documento está dirigido a desarrolladores y administradores que quieran conocer con detalle cómo instalar, configurar y administrar Virtual DataPort, incluyendo la creación de vistas unificadas de datos sobre fuentes de información heterogéneas y distribuidas, estructuradas y no estructuradas. La información detallada precisa para desarrollar aplicaciones que utilicen Virtual Data Port se proporciona en la Guía del Desarrollador.

RESUMEN DE CONTENIDOS

Más concretamente, en este documento:

• Se presentan los conceptos fundamentales de las soluciones de integración de información basadas en Virtual DataPort.

• Se describen los procesos necesarios para instalar y configurar Virtual Data Port.

• Se describe detalladamente mediante ejemplos cómo utilizar las herramientas de administración visual de Virtual Data Port para construir vistas unificadas sobre información de fuentes distribuidas y heterogéneas.


Introducción 2

1 INTRODUCCIÓN

Hoy en día, y para soportar sus propios procesos de negocio, toda organización de cierta entidad dispone de multitud de sistemas de información desarrollados a lo largo del tiempo y que hacen uso de distintas fuentes de datos. Habitualmente, dichas fuentes están desarrolladas sobre tecnologías diferentes (bases de datos relacionales, servicios web, documentos XML, hojas de cálculo, ficheros planos...), de acuerdo a modelos de datos muy heterogéneos, e incluyen tanto información estructurada como no estructurada. El desarrollo de nuevos servicios para los clientes o la optimización de los procesos de negocio de la empresa exigen construir nuevos sistemas que necesitarán datos almacenados en esos repositorios de información heredados. Otra importante tendencia a considerar es la expansión de Internet, ejemplo paradigmático de dispersión de información y heterogeneidad de formatos. Sus contenidos son en muchas ocasiones un complemento fundamental para los sistemas corporativos. Especialmente si consideramos que, además, clientes, proveedores y competencia acostumbran ya a ofrecer interfaz web para dar acceso a información de mucho interés. Virtual DataPort es una solución global para la integración en tiempo real de fuentes de información heterogéneas y dispersas, estructuradas y no estructuradas. Para ello combina varias funcionalidades que gozan de importantes sinergias: Virtual DataPort integra aquella información que es relevante para la empresa, sin importar su procedencia y formato, incorpora esa información en su sistema de información, en tiempo real o con precargas configurables, y facilita la construcción de servicios telemáticos de alto valor estratégico y funcional, tanto corporativos como de negocio, imposibles de concebir sin su aplicación. Este documento pretende servir como guía técnica al software Virtual DataPort. Pretende ilustrar su capacidad de desarrollar soluciones que integren fuentes de información dispersas, y heterogéneas, con una estructura débil (fuentes estructuradas, semiestructuradas y no estructuradas), autónomas y sin un control centralizado.


Arquitectura General 3

2 ARQUITECTURA GENERAL

A grandes rasgos, Virtual DataPort permite que las aplicaciones de negocio puedan tratar una serie de fuentes de información distribuidas y heterogéneas, incluyendo fuentes externas como si su información estuviese contenida en una gran Base de Datos ”Virtual” que permite construir fácilmente vistas que combinen e integren dicha información. Virtual Data Port actúa como un mediador que proporciona una visión estructurada y unificada de los datos contenidos en todas las fuentes de información incluidas en el sistema. El sistema puede tratar fácilmente un amplio abanico de fuentes de información estructuradas, semi-estructuradas y no estructuradas, tales como: Bases de Datos, sitios web, documentos XML, Servicios Web, ficheros de texto plano, hojas de cálculo, índices sobre información no estructurada, etc. El sistema considera cada fuente de datos como una relación dentro de VirtualDataPort y permite utilizar un lenguaje (compatible en gran medida con SQL) llamado Denodo VQL (Virtual Query Language), para crear vistas que combinen arbitrariamente la información de dichas relaciones. En este proceso, Virtual DataPort es capaz de tratar con fuentes cuyas capacidades de consulta son limitadas (por ejemplo, en la mayor parte de fuentes web, sólo son permitidas las consultas que pueden realizarse a través de algún tipo de formulario HTML). Además, el motor de consulta de Virtual DataPort es capaz de consultar información no estructurada y combinarla de la forma deseada con información estructurada y semi-estructurada. Cuando el sistema recibe una consulta VQL sobre una vista unificada definida previamente, genera un plan de ejecución que consistirá en una lista de subconsultas que serán enviadas en tiempo real a las diversas fuentes involucradas, y una serie de operaciones de combinación de los datos obtenidos de cada fuente. Además, Virtual DataPort incluye un sistema (llamado módulo de cache) que permite al administrador decidir el mecanismo de actualización de los datos de las fuentes:

• El sistema podrá acceder a los datos de las fuentes en tiempo real proporcionando así información totalmente actualizada.

• Pueden crearse y configurarse caches para las fuentes o vistas que se desee.

Virtual DataPort también permite la actualización de las fuentes de datos, siempre que éstas sean capaces de soportar transacciones. El sistema de integración de información proporcionado por Virtual DataPort se modela en 3 niveles independientes: la capa de usuario, la capa lógica y la capa física (wrappers). En la Figura 1 se muestra una visión general de la arquitectura del sistema. A continuación se describirán cada uno de estos niveles.



Figura 1 Arquitectura de Virtual DataPort

2.1 NIVEL FÍSICO

El nivel físico tiene como misión conseguir que las fuentes de datos se comporten de cara a los niveles superiores de la arquitectura como relaciones con una estructura definida de acuerdo al modelo común de datos utilizado por DataPort. Estas labores son realizadas a través de los llamados wrappers. Un wrapper extrae información de una fuente, interpreta los resultados obtenidos, y los devuelve al sistema en el formato esperado por DataPort. También, en los casos en los que la fuente lo permite, un wrapper inserta, actualiza y/o borra información en una fuente. Los wrappers hacen posible que Virtual DataPort pueda tratar de manera consistente todas las fuentes externas, sin preocuparse de sus particularidades específicas. Para ello, proporciona la implementación de diferentes tipos de wrappers –uno por cada tipo de fuente externa-. Virtual DataPort soporta directamente los siguientes tipos de wrappers:

• Bases de datos: Extraen datos desde una Base de Datos Remota vía JDBC u ODBC. También insertan, actualizan y/o borran datos en los casos en los que las fuentes lo permitan.

• Servicios Web: Extraen datos realizando invocaciones a operaciones definidas por servicios web.

• XML: Son aquellos que permiten extraer datos encapsulados en ficheros XML, siguiendo una cierta DTD o esquema, o sin esquema ni DTD asociado. Los documentos XML pueden ser accedidos en el disco local o a través de protocolos como http y FTP. Otra utilidad de este tipo de wrapper es la importación de servicios web de tipo REST.

• Ficheros planos: Extraen datos de ficheros planos en formato CSV (Comma Separated Values) o similar. Los documentos CSV pueden ser accedidos en el disco local o a través de protocolos como http y FTP.



• ITPilot: Permiten acceder a información contenida en fuentes Web semi-estructuradas, permitiendo tratarlas de forma muy similar a como si fuesen bases de datos estructuradas. Los wrappers de este tipo son generados utilizando Denodo ITPilot [ITPILOT].

• Aracne: Denodo Aracne [ARCN] permite el crawling, filtrado, indexación y búsqueda de información no estructurada contenida en repositorios tales como la web, bases de datos relacionales, sistemas de ficheros locales o servidores de correo electrónico. Los índices creados con Denodo Aracne pueden ser importados directamente en DataPort para su consulta y combinación conjunta con información estructurada y semi-estructurada.

• Google Mini: Google Mini [GMINI] es la solución corporativa de Google para el crawling, indexación y búsqueda de información contenida en la web. Los índices creados con Google Mini pueden ser importados directamente en Denodo DataPort para su consulta y combinación conjunta con información estructurada y semi-estructurada.

• CUSTOM (también denominados wrappers de tipo MY): Extraen la información de una fuente, a través de una implementación Java proporcionada por el administrador de Virtual DataPort. Este tipo de wrapper permite la construcción ad-hoc de un programa envoltorio para una fuente específica. Los wrappers CUSTOM también pueden permitir la inserción, actualización y/o borrado de datos.

Los wrappers para bases de datos, servicios web, ficheros planos, XML, Aracne y Google Mini son creados automáticamente por Virtual DataPort al importar las fuentes de información correspondientes (véase sección 6.2). Los wrappers para fuentes web semi-estructuradas pueden ser creados con Denodo ITPilot [ITPILOT].

2.2 NIVEL LÓGICO

El nivel lógico, tiene como responsabilidad integrar y combinar las relaciones exportadas por los diferentes wrappers para componer el esquema global del sistema. Esta combinación se realiza mediante la definición de vistas, expresadas en el lenguaje Denodo VQL [VQL], sobre las relaciones exportadas por los wrappers del nivel físico. Estas relaciones, que representan a las fuentes del sistema, se denominan relaciones base (o, también vistas base). Una vez creadas las relaciones base representando las fuentes del sistema, el administrador puede crear vistas que las combinen entre sí como se desee, creando de esta manera las vistas del esquema global (o también vistas derivadas). Es importante resaltar que este proceso puede realizarse de manera recursiva en varios pasos: una vista derivada puede ser utilizada como base para la creación de nuevas vistas, permitiendo así combinaciones de complejidad arbitraria. Una vez creadas las vistas del esquema global combinando la información de las fuentes, el nivel lógico es capaz de responder consultas expresadas en VQL tanto sobre las vistas derivadas como sobre las relaciones base. El lenguaje de consultas VQL se basa en SQL, incorporando diversas extensiones para manejar información heterogénea y distribuida. Por ejemplo, VQL incluye diversas construcciones que facilitan la consulta de información no estructurada y su combinación con información estructurada. Cuando el sistema recibe una consulta, comprueba si es resoluble en función de las capacidades de consulta de las fuentes, elabora los posibles planes de ejecución, selecciona el más óptimo, y ejecuta la consulta devolviendo a la capa superior los resultados obtenidos. La capa lógica de Virtual DataPort también permite la actualización de las fuentes de datos mediante operaciones INSERT/UPDATE/DELETE, siempre que éstas sean capaces de soportar transacciones. En la capa lógica se pueden diferenciar los siguientes módulos:



• Generador de Planes de Consulta: En primer lugar, el generador de planes decide si la consulta recibida puede o no ser contestada, de acuerdo a las capacidades de consulta soportadas por las fuentes. En caso afirmativo debe generar los posibles planes de ejecución para la consulta.

• Optimizador: Tiene como misión seleccionar el plan de ejecución óptimo de entre todos los posibles (obtenidos por el Generador de Planes de Consulta). Para ello tendrá en cuenta tanto la materialización de cada uno de los planes activados, como su complejidad. También se consideran las capacidades de consulta ofrecidas por las fuentes, de manera que se puedan delegar a las mismas las operaciones que puedan realizar localmente, obteniéndose así una ejecución más eficiente y un menor trasiego de datos a través de la red. Otros aspectos tenidos en cuenta son las estrategias de ejecución más óptimas para las operaciones de join.

• Motor de Ejecución de Consultas: Una vez seleccionado el plan óptimo, el motor de ejecución se encarga de ponerlo en práctica, ejecutando las sub-consultas precisas sobre las fuentes e integrando los resultados obtenidos para generar la respuesta global. A su vez, el motor de ejecución tiene en cuenta qué información de las fuentes está ya precargada en el módulo de caché, de manera que se evitan accesos innecesarios a las fuentes de datos, logrando así una mayor eficiencia.

2.2.1 Módulo de Datos: Caché

Tal y como ya se ha comentado, Virtual DataPort dispone de un sistema (llamado módulo cache) para almacenar copias locales de los datos de las fuentes que se desee. Esta caché (también llamada warehouse) puede almacenarse en una Base de Datos Relacional accesible vía JDBC, Las Bases de datos soportadas actualmente para este propósito son PostgreSQL [POSQL], My SQL [MYSQL] y Oracle [ORCL]. Véase el Apéndice: Drivers JDBC para consultar los formatos adecuados para los drivers JDBC incluidos /o utilizados habitualmente con la caché de DataPort. El sistema generará y mantendrá automáticamente una tabla en la Base de Datos caché por cada relación base o vista para la que la cache haya sido configurada. A medida que se vayan realizando consultas, las tablas se irán rellenando con las tuplas obtenidas de las fuentes hasta el momento. Además, cada vista mantendrá una descripción de las tuplas actualmente contenidas en la caché, de forma que el gestor pueda saber qué consultas sobre la relación son resolubles con datos disponibles localmente. Cada vista en la caché tendrá asociado un tiempo de expiración, de manera que las tuplas “caducadas” no serán consideradas en las consultas y serán borradas periódicamente de forma automática. Este mecanismo permite además realizar precargas periódicas de datos de manera muy sencilla, simplemente escribiendo una consulta describiendo los datos a precargar y planificando temporalmente la repetición de dicha consulta con el intervalo temporal deseado. La caché también puede inhabilitarse para una consulta concreta o para las relaciones o fuentes que se desee, de manera que siempre es posible acceder a la información de las fuentes en tiempo real.

2.3 NIVEL DE USUARIO

El nivel del usuario, se ocupa de implementar la interfaz entre el usuario y el gestor Virtual DataPort. Es, por lo tanto, responsabilidad suya proporcionar los medios para que un usuario pueda establecer una sesión con el gestor, enviarle consultas y obtener los resultados correspondientes de las mismas. El nivel del usuario recibe la consulta emitida por el usuario en el lenguaje de consultas externo VQL y la traduce a álgebra relacional antes de entregársela al nivel lógico.



Cuando el nivel lógico devuelve una respuesta para la consulta efectuada, es también responsabilidad de este nivel proporcionársela al usuario a través de las interfaces de conexión definidas a tal efecto (ver Guía del Desarrollador [DEV] de Virtual DataPort). Denodo Virtual DataPort puede ser accedido vía JDBC, ODBC, a través del uso de Servicios Web (ver sección 7) y a través de la API nativa (DataPort API).


Instalación 8

3 INSTALACIÓN

3.1 INSTALACIÓN

Este apartado se centra en la instalación y configuración de los diferentes componentes de Denodo Virtual DataPort.

3.1.1 Requisitos Hardware

El sistema ha sido probado satisfactoriamente sobre un PC Pentium IV 2,4 GHz 1 Gb RAM con acceso a Internet. La instalación inicial requiere aproximadamente unos 50MB de espacio en disco.

3.1.2 Requisitos Software

Virtual DataPort requiere la preinstalación del siguiente software (el resto se incluye con la distribución):

• Un sistema operativo con soporte para Java.

Ejemplo: Linux Fedora Core 5 [FED] o un sistema operativo Windows [WIND] (2000 Professional, 2000 Server, 2000 Advanced Server, 2003, XP) o superior.

• Java 2 Runtime Environment Standard Edition (J2SE 1.4, J2SE 1.5 ó J2SE 1.6). La máquina virtual Java utilizada para la ejecución del sistema.

• Si se va a utilizar el sistema cache, un Gestor de Base de Datos JDBC para dar soporte al sistema caché. En la versión actual de DataPort pueden actúar como cache los gestores Oracle [ORCL], PostgreSQL [POSQL] y MySQL [MYSQL].

3.1.3 Utilización de la herramienta de instalación

Los módulos que forman parte de la Plataforma Denodo se instalan a través de una herramienta gráfica. El asistente de instalación le irá guiando por cada uno de los pasos de configuración necesarios. En este apartado se describirán los pasos a realizar para instalar cada uno de los componentes de Denodo Virtual DataPort. Tras la pantalla de presentación (ver Figura 2), el proceso de instalación le mostrará las condiciones de la licencia del producto, que debe leer cuidadosamente. Si acepta las condiciones, el sistema solicitará la configuración de internacionalización que se desea para el producto y, a continuación, la ruta en la que desea instalar el software (en adelante DENODO_HOME). La herramienta copiará los ficheros necesarios en dicho directorio.


Instalación 9

Figura 2 Pantalla inicial de instalación de la Plataforma Denodo

La siguiente pantalla le presentará los diferentes módulos que puede instalar, así como los componentes contenidos en cada módulo. En lo que se refiere a Virtual DataPort, hay dos posibles componentes a instalar:

- Sólo la distribución cliente de Virtual DataPort. Instala la herramienta de administración y creación visual de vistas de Virtual DataPort (ver sección 4.1), el intérprete de línea de comandos de VQL (ver Apéndices: Cliente de Línea de Comando) y las clases necesarias para desarrollar aplicaciones que ejecuten consultas sobre Virtual DataPort (ver Guía del Desarrollador de Virtual DataPort [DEV]).

- Virtual DataPort completo (cliente y servidor). Esta será la opción escogida por defecto. Una vez seleccionados los componentes, el sistema comenzará el proceso de copia de archivos. En el caso de DataPort es posible especificar los siguientes parámetros:

- Número de puerto en el que se lanzará el servidor DataPort. - Número de puerto utilizado para detener el servidor DataPort. - Número para el ‘Auxiliary Port’. Las comunicaciones entre los clientes y el servidor DataPort utilizan un

número de puerto adicional llamado “auxiliar” que puede especificarse en este momento. - En sistemas operativos Windows, es posible especificar que el servidor DataPort sea instalado como

servicio. NOTA IMPORTANTE: En el caso de que se esté realizando la instalación en la misma ruta en la que ya está instalado un servidor DataPort, el proceso de instalación sobreescribirá las definiciones ya existentes de vistas, fuentes, usuarios o cualquier otro elemento del catálogo. Si se desea conservar estas definiciones, es necesario realizar antes de la instalación una copia de seguridad de los metadatos (ver sección 5.3).Tras la instalación, los


Instalación 10

metadatos pueden,volver a cargarse en el servidor.. NOTA: Si las comunicaciones entre los clientes y el servidor deben atravesar un software de cortafuegos, éste debe configurarse para permitir el acceso al puerto de ejecución y al puerto auxiliar. Los números de puerto escogidos pueden cambiarse posteriormente haciendo uso de las opciones de la herramienta de administración (véase sección 5.1). NOTA: En el caso de instalar simultáneamente DataPort junto con ITPilot y/o Aracne, será posible especificar diversos parámetros de configuración para ellos. Véase la documentación de ITPilot [ITPILOT] y Aracne [ARCN] para más información. Por defecto, al instalar el servidor, se crea automáticamente un usuario admin (con contraseña inicial admin) que permite acceder al servidor, y la base de datos admin. El proceso de instalación permite también crear accesos directos en el escritorio para lanzar y detener las diversas herramientas que componen Virtual DataPort.

3.1.4 Instalación de la Licencia

Para que el software funcione correctamente, el fichero de licencia denodo.lic o vdp.lic debe encontrarse en la ruta DENODO_HOME/conf. Si no dispone de un fichero de licencia válido póngase en contacto con Denodo o con su distribuidor.

3.2 ESTRUCTURA DE LA DISTRIBUCIÓN

Una vez realizado el desempaquetado, la estructura de directorios que se obtiene para cada una de las distribuciones (cliente y/o servidor) es descrita en las siguientes subsecciones.

3.2.1 Distribución Cliente

Los principales directorios de la distribución cliente se indican a continuación

• conf/vdp-admin. En este directorio se encuentran los ficheros de configuración de la herramienta de administración de Virtual DataPort.

• log4j.xml. Fichero de configuración Log4J[LOG4J] del nivel de log en el cliente. Por defecto, la ruta al fichero de log es. $DENODO_HOME/logs/vdp-admin.

• bin. Directorio que incluye los scripts de ejecución del cliente para la shell bash (sistema Linux – Unix), y sus equivalentes archivos de procesamiento por lotes para Windows. Los primeros tienen extensión “.sh” y los segundos “.bat”:

• vqls.sh. Script de ejecución de la aplicación del cliente VQL en modo intérprete de comandos.

• vdp-admin.sh. Script que arranca la herramienta de administración de Virtual DataPort.

Todos los ficheros citados con anterioridad son scripts para la hell bash (intérprete de comandos Linux – Unix). Por cada uno de ellos, existe un archivo de extensión “.bat” equivalente para Windows.

s


Instalación 11

t

• lib. Directorio en el que se almacenan las diferentes librerías utilizadas por el sistema. En contrib se encuentran las librerías requeridas por la aplicación, cada una en un directorio propio en el que se indica, además del paquete de software, su número de versión.

• docs/vdp. Directorio en el que se encuentra la documentación de la aplicación, incluyendo la documentación javadoc.

• logs/vdp-admin. Directorio en el que se almacenan los ficheros de log de la herramienta de administración de Virtual DataPort.

3.2.2 Distribución Completa

Los principales directorios de la distribución completa (servidor y cliente) se especifican a continuación:

• conf/vdp y conf/vdp-admin. En estos directorios se encuentran los ficheros de configuración de, respectivamente, el servidor VDP y la herramienta de administración:

• log4j.xml. Archivo de configuración para registro de eventos (log) del sistema.

• bin. Directorio que incluye los scrip s de ejecución del sistema para la shell bash (sistema linux – unix) o sus equivalentes archivos de procesamiento por lotes para Windows. Los primeros tienen extensión “.sh” y los segundos “.bat”:

• vqlserver.sh. Recibe los parámetros startup (arranca el servidor) o shutdown (detiene el servidor). En el caso de Windows, además de vqlserver.bat (con uso equivalente a vqlserver.sh) existen también los scripts vqlserver_startup.bat y vqlserver_shutdown.bat) para el mismo propósito.

• vqls.sh. Script de ejecución de la aplicación del cliente en modo intérprete de comandos.

• vdpadmin.sh. Script que arranca la herramienta de administración de Virtual DataPort.

Todos los ficheros .sh citados con anterioridad son scripts para la shell bash (intérprete de comandos Linux – Unix). Por cada uno de ellos, existe un archivo de extensión “.bat” equivalente en sistemas MS Windows.

• vdpservice.bat. Lanzar VQLserver como un servicio de Windows. Admite los parámetros: install (instala el servidor como servicio Windows), start (arranca el servidor), stop (detiene el servidor), remove (desinstala el servidor como servicio Windows).

• metadata. Directorio que incluye la estructura de metadatos utilizada por el sistema

• samples/vdp. Directorio en el que se encuentran diferentes ejemplos para Virtual DataPort.

• extensions. Se ubican en este directorio las aplicaciones y librerías que no forman parte del núcleo de Virtual DataPort, y que pueden ser consideradas como extensiones. En


Instalación 12

extensions/dev/target/classes pueden incluirse clases adicionales que se desea que estén en el classpath del servidor DataPort (por ejemplo, implementaciones de wrappers de tipo CUSTOM. Véase sección Figura 62).

• lib. Directorio en el que se almacenan las diferentes librerías utilizadas por el sistema. En contrib se encuentran las librerías requeridas por la aplicación, cada una en un directorio propio en el que se indica, además del paquete de software, su número de versión.

• docs/vdp. Directorio en el que se encuentra la documentación de la aplicación, incluyendo la documentación javadoc.

• logs/vdp y logs/vdp-admin. Directorio en el que se almacenan los ficheros de log de, respectivamente, el servidor VDP y la herramienta de administración gráfica..

• tools. Contiene las utilidades para arquitecturas en cluster y copias de respaldo (ver sección 10).

• work. Directorio de trabajo para archivos temporales.

• webapps. Contiene los ficheros .wsdl y .war que permiten acceder a DataPort a través de una interfaz Web Service genérica (ver la Guía del Desarrollador de Virtual DataPort [DEV] para más detalle).

3.2.3 Tareas de Post-Instalación

Una vez instalado el sistema es necesario en caso de que ésta vaya a utilizarse, instalar la base de datos que actuará como cache. Si se van a utilizar wrappers de tipo MY u otras librerías no incluidas en la distribución inicial del sistema, también puede ser conveniente establecer un CLASSPATH externo mediante el uso de la variable de entorno DENODO_EXTERNAL_CLASSPATH.

3.2.3.1 Creación de la BD del Sistema Caché

En el caso de utilizar una configuración de Virtual DataPort con sistema caché, es necesario también instalar el Gestor de Base de Datos que va a ser utilizado para tal fin. En la versión actual de DataPort pueden actúar como cache los gestores Oracle[ORCL], PostgreSQL[POSQL] y MySQL[MYSQL]. Véase el Apéndice: Drivers JDBC para consultar los formatos adecuados para los drivers JDBC incluidos /o utilizados habitualmente con DataPort. La configuración del sistema cache puede realizarse con la herramienta de administración de Virtual DataPort (ver sección 5.1.3).

3.2.3.2 Classpath externo

Existen dos formas de añadir nuevas clases o librerías al classpath de ejecución de Denodo VirtualDataPort:

• Colocar las nuevas clases a partir de la ruta DENODO_HOME/extensions/dev/target/classes donde DENODO_HOME es la ruta base de la instalación. Las nuevas librerías se pueden cargar en cualquier directorio que cuelgue de DENODO_HOME/extensions.

• Haciendo que la variable de entorno DENODO_EXTERNAL_CLASSPATH apunte a las rutas a partir de las que se encuentran las clases externas o a las rutas completas a ficheros .jar.


Instalación 13

Esto es necesario para crear nuevos wrappers de tipo CUSTOM y de procedimientos almacenados (ver Guía Avanzada de VQL [VQL]).


Ejecución 14

4 EJECUCIÓN

Para arrancar el servidor de Virtual DataPort, basta utilizar los accesos directos creados durante la instalación de la aplicación (‘Start Virtual DataPort Server’) o ejecutar el script: $DENODO_HOME/bin/vqlserver.sh startup (vqlserver.bat startup en Windows). Para detener el servidor deben utilizarse los accesos directos correspondientes o bien ejecutar $DENODO_HOME/bin/vqlserver.sh shutdown (vqlserver.bat shutdown en Windows) Si se desea utilizar el sistema caché, debe haberse configurado correctamente en la herramienta de administración de Virtual DataPort (ver sección 5.1.3) y debe haberse arrancado previamente la base de datos JDBC que actuará como tal. La primera vez que se ejecuta Virtual DataPort utilizando caché, se generan de forma automática las estructuras necesarias para su funcionamiento. Para ejecutar los clientes básicos de la Base de Datos Virtual se dispone de los siguientes scripts (durante la instalación de la aplicación es posible también generar accesos directos para ellos):

• Herramienta de administración gráfica de Virtual Data Port: $DENODO_HOME/bin/vdpadmin.sh (vdpadmin.bat o vdpadmin.exe en Windows). Se utilizará para la mayoría de procesos de administración. El nombre del acceso directo correspondiente es ‘Start Virtual DataPort Administration Tool’.

• Cliente de línea de comandos: $DENODO_HOME/bin/vqls.sh (vqls.bat en Windows). El nombre del acceso directo correspondiente es ‘Start Virtual DataPort CommandLine Shell’.

4.1 EJECUCIÓN DE LA HERRAMIENTA DE ADMINISTRACIÓN GRÁFICA DE VIRTUAL DATAPORT

Una vez se ha ejecutado la herramienta de administración gráfica de Virtual DataPort el primer paso es autenticarse contra un servidor DataPort sobre el que se desean realizar las labores de administración (ver Figura 3). Para ello es necesario introducir la uri del servidor, un login de usuario y una contraseña. El formato de la uri del servidor es el siguiente: //nombre_maquina:puerto/base_de_datos (e.g. //localhost:9999/admin) donde:

• nombre_maquina es el nombre de la máquina dónde reside el servidor. • puerto es el número del puerto de ejecución del servidor • base_de_datos (opcional) es la base de datos de Virtual DataPort a la que se desea conectar. Al

instalar un servidor Virtual DataPort se crea una base de datos por defecto llamada admin.


Ejecución 15

Figura 3 Autenticación en la herramienta de administración

Para más detalles sobre los conceptos de base de datos y usuario en Virtual DataPort, véase la sección 7. Si es la primera vez que accede al servidor, puede utilizar el usuario de tipo administrador creado por defecto (login de usuario “admin” con clave de acceso “admin”). Es recomendable cambiar la contraseña de este usuario la primera vez que se conecte a un servidor. Para ello, debe utilizarse la opción ‘Change password’ del menú ‘File’ de la aplicación. Es posible conectarse al servidor en dos modos: modo de administración de una base de datos y modo de administración del servidor. Al modo de administración de una base de datos se accede cuándo la uri del servidor especifica una base de datos y además el usuario utilizado no es de tipo administrador. Este modo permite gestionar las fuentes, relaciones base y vistas unificadas que forman parte de una base de datos determinada del servidor DataPort. El modo de administración del servidor está reservado a los usuarios de tipo administrador y, en este caso, no es imprescindible que la uri suministrada especifique una base de datos. Este modo permite realizar tareas tales como:

• Crear, modificar o borrar bases de datos (ver sección 7). • Crear, modificar o borrar usuarios, así como gestionar sus priviliegios de acceso a bases de datos y vistas

(ver sección 7). • Configurar el sistema cache (ver sección 5.1.3). • Configurar la política de “swapping” del servidor (ver sección 6.6.3). • Configurar el pool de threads del servidor (ver sección 5.1.2). • Configurar los puertos de ejecución y parada del servidor (ver sección 5.1.1). • Configuración de opciones de internacionalización (ver sección 5.1.5).

Si la URI especificada incluye una base de datos y el usuario es administrador será posible realizar tanto las tareas de gestión del servidor como las de la base de datos indicada.


Administración del Servidor 16

5 ADMINISTRACIÓN DEL SERVIDOR

En esta sección se describen las principales opciones de administración del servidor disponibles en Denodo Virtual DataPort. En primer lugar se detalla cómo utilizar la herramienta de administración y creación visual de vistas para configurar diversos aspectos del servidor de Virtual DataPort. Posteriormente se describe cómo configurar los logs de la aplicación. Finalmente, se describe cómo exportar los metadatos del servidor para propósitos de respaldo (“backup”) y/o migración a otras instalaciones de Virtual DataPort.

5.1 CONFIGURACIÓN DEL SERVIDOR

Para gestionar las bases de datos, usuarios y permisos de un servidor Virtual DataPort es necesario acceder a la herramienta de administración en modo de administración de servidor, lo que implica hacerlo con un usuario de tipo administrador. Si es la primera vez que accede al servidor, puede utilizar el usuario de tipo administrador creado por defecto (login de usuario “admin” con clave de acceso “admin”). Los parámetros de configuración del servidor pueden agruparse como se indica en los siguientes apartados: puerto, sistema de multithreading, cache, parámetros de “swapping” a disco, parámetros de ejecución de procedimientos almacenados y configuración de internacionalización.

5.1.1 Puerto

El servidor DataPort utiliza tres números de puerto para sus comunicaciones con los clientes: el puerto de ejecución del servidor, el puerto de parada del servidor y un puerto auxiliar. Estos puertos pueden configurarse seleccionando la opción “Server Configuration – Server Port” (ver Figura 4). NOTA: En el caso de que la conexión entre los clientes y el servidor DataPort deba atravesar un cortafuegos, será necesario configurar el software del cortafuegos para permitir el acceso al puerto de ejecución y al puerto auxiliar.



Figura 4 Configuración de puertos

Los cambios de puerto tendrán efecto la siguiente vez que se relance el servidor de Virtual Data Port.

5.1.2 Pool de Threads

Tal y cómo ya se ha comentado, el motor de ejecución de consultas de Virtual DataPort opera de forma concurrente sobre las fuentes de información. La implementación de la concurrencia se lleva a cabo mediante un subsistema de multithreading, que puede configurarse a través de la herramienta de administración de Virtual Data Port. Para configurar el subsistema de multithreading de un servidor Virtual DataPort es necesario acceder a “Server Configuration - Threads Pool”. Los parámetros configurables son los siguientes:

• Max Threads: Número máximo de threads manejados en un determinado instante de tiempo por el Pool (por defecto 300)).

• Expiration Time: Tiempo máximo que un thread no utilizado permanece en el Pool (por defecto, 600.000 milisegundos)).

• Sleep Time: Indica cada cuanto tiempo se chequean los threads no utilizados en el Pool, para eliminar los que superen expirationTime (por defecto, 300.000 milisegundos).

• Timeout: Tiempo máximo permitido por el Pool para la ejecución de uno de sus threads (por defecto, 600.000 milisegundos).

• Checkout Time: Tiempo máximo que se espera por un thread libre. Si se supera este tiempo se produce una excepción (por defecto, 30.000 miliseguntos).



Los cambios de configuración tendrán efecto de forma inmediata.

5.1.3 Configuración de la Caché

Tal y como ya se ha comentado, Virtual DataPort dispone de un sistema (llamado módulo cache) para almacenar copias locales de los datos de las fuentes que se desee en una base de datos JDBC. Para configurar un servidor para utilizar cache es necesario acceder a la pestaña “Server Configuration”, escoger la opción “Cache” (ver Figura 5) y marcar la opción “Cache status on”. Adicionalmente, es necesario especificar los datos para crear un DataSource JDBC (ver sección 6.3.1) para la cache. Esto involucra especificar:

• Gestor de base de datos JDBC que se utilizará como cache (en la versión actual se soportan los gestores Oracle, PostgreSQL y MySQL).

• URI a la base de datos utilizada como cache. • Login y contraseña del usuario utilizado para acceder a la Base de datos de cache. • Si se marca la opción ‘Test Connection’ (recomendado), el sistema se conectará a la fuente para obtener su

fabricante y número de versión. Esta información podrá ser utilizada para optimizar el acceso a la fuente en función de sus características específicas. Si no se marca esta opción, se utilizará una configuración genérica.

• También es posible acceder a la opción ‘Pool Configuration’ para configurar los parámetros del pool de conexiones sobre la cache (ver sección 6.3.1).

Figura 5 Configuración de cache

Es posible también consultar y/o configurar los siguientes parámetros del funcionamiento de la cache:



• Maintainer Period: Especifica (en segundos) el período de ejecución de la tarea de mantenimiento de la cache. La tarea de mantenimiento es la encargada de realizar el borrado de entradas caducadas en la caché. Si el valor proporcionado es 0 o negativo, la tarea de mantenimiento no se ejecutará nunca.

• Time To Live: Especifica (en segundos) el tiempo de expiración por defecto de las entradas de la cache.

Una vez que la cache ha sido activada y configurada ya es posible configurar vistas del sistema para que la utilicen (ver sección 6.6.2). Por otra parte, si se desea inhabilitar la cache, basta seleccionar la opción “Cache off” en el panel “Cache” de la pestaña “Server Configuration”. Los cambios de configuración tendrán efecto de forma inmediata excepto cuando se cambie el gestor de caché, que exige reinicio del servidor. Es posible especificar una configuración de cache específica para cada Base de Datos del servidor DataPort (ver sección 8.3.2).

5.1.4 Configuración de los parámetros de “swapping” a disco

Para evitar desbordamientos de memoria, Virtual DataPort puede hacer “swapping” a disco de los resultados intermedios generados durante el proceso de ejecución de una vista o consulta. Para configurar los parámetros de “swapping” de un servidor es necesario acceder a la pestaña “Server Configuration” y escoger la opción “Swapping” (ver Figura 6). Para habilitar o deshabilitar el “swapping” a nivel global deben utilizarse, respectivamente, las opciones “Swapping status on” (opción por defecto) o “Swapping status off”.



Figura 6 Configuración de Swapping

Es posible también consultar y/o configurar los siguientes parámetros del funcionamiento del “swapping”:

• Tamaño máximo de cada resultado intermedio (megabytes). Durante la ejecución de una vista o consulta, DataPort realizará “swapping” a disco cuando algún resultado intermedio producido durante la ejecución supere el tamaño máximo especificado en este parámetro. Como norma general, se recomienda que el valor especificado no sea mayor que la tercera parte de la memoria disponible para la máquina virtual JAVA en la que se ejecuta el servidor DataPort.

• Tamaño máximo de los bloques escritos a disco (kbytes). Si DataPort realiza swapping de un resultado intermedio, realizará la escritura en disco utilizando bloques de, como máximo, el tamaño especificado.

La configuración general de swapping puede también ser específica para cada Base de Datos del servidor DataPort (ver sección 8.3.2). Si el swapping está activado a nivel global, es posible activarlo y configurarlo para una vista (véase sección 6.6.3). También es posible configurarlo dinámicamente para una consulta determinada utilizando la cláusula CONTEXT de VQL (ver la Guía Avanzada de VQL [VQL]). Los cambios de configuración tendrán efecto de forma inmediata.

5.1.5 Configuración de Parámetros de Ejecución de Procedimientos Almacenados

DataPort permite escribir procedimientos almacenados utilizando el lenguaje JAVA (ver sección 6.7 y Guía Avanzada de VQL [VQL]). Los procedimientos almacenados pueden ejecutar sentencias en el servidor DataPort. La ejecución de dichas sentencias hace uso de diveros parámetros de configuración.



Para modificar los parámetros de configuración de las sentencias ejecutadas dentro de un procedimiento almacenado, es necesario acceder a la pestaña “Server Configuration” y escoger la opción “Stored Procedures” (ver Figura 7).

Figura 7 Configuración de Ejecución de Sentencias dentro de Procedimientos Almacenados

Es posible modificar los siguientes parámetros:

• Query Timeout: Máximo tiempo (en milisegundos) que el procedimiento almacenado esperará a que termine la ejecución de una sentencia. Si se indica el valor 0, entonces el procedimiento esperará el tiempo necesario hasta que finalice la ejecución.

• Chunk Size: DataPort puede devolver los resultados de la ejecución de una sentencia en bloques, de forma que no es necesario esperar a que la ejecución de una consulta termine para disponer de las tuplas que ya se hayan obtenido. Este parámetro establece el número máximo de resultados que conforman un bloque. Si Virtual DataPort tiene disponibles suficientes resultados para completar un bloque, los devolverá al procedimiento almacenado sin esperar por más resultados. Los siguientes resultados se devolverán en nuevos bloques. Si no se especifica (o recibe el valor 0), entonces todos los resultados de la consulta se devolverán en un único bloque.

• Chunk Timeout: Este parámetro establece el máximo tiempo (en milisegundos) que el servidor esperará antes de devolver un nuevo bloque. Si se sobrepasa este tiempo, Virtual DataPort devolverá el bloque actual, incluso aunque no se haya alcanzado el número de tuplas especificado en el parámetro Chunk Size. Si no se especifica (o recibe el valor 0), el servidor devuelve todos los resultados conjuntamente al finalizar la ejecución de la sentencia.



5.1.6 Configuración de Internacionalización por defecto

La configuración de internacionalización del servidor DataPort especifica aspectos tales como zonas horarias, lenguajes o monedas. Por ejemplo, la moneda que se utilizará por defecto en los valores de tipo Money viene especificada por esta propiedad. DataPort incluye configuraciones de internacionalización típicas y, además, permite la creación de nuevas configuraciones ad-hoc. Véase la Guía Avanzada de VQL [VQL] para más información. Es posible también especificar una configuración de internacionalización específica para cada Base de Datos del servidor DataPort (ver sección 8.3.2). También es posible especificar una configuración de internacionalización distinta para una relación base del sistema (ver sección 6.6.1). Por último, la herramienta de administración gráfica de DataPort tiene también su propia configuración de internacionalización, que puede cambiarse en el menú “View-Preferences”.

5.2 CONFIGURACIÓN DE LOGS

El software Virtual DataPort hace uso del sistema de log de Jakarta-log4j[LOG4J]. Este sistema permite controlar los mensajes de log con distintos niveles de granularidad, y es totalmente configurable haciendo uso de ficheros de configuración externos. Para modificar el fichero de configuración de log es necesario tener algún conocimiento acerca de log4j. Brevemente, Log4j permite definir una serie de categorías sobre las que especificar el nivel de log de forma independiente. Log4j define diferentes niveles de log que, ordenados de mayor a menor nivel de detalle son: DEBUG, INFO, WARN, ERROR y FATAL. NOTA: En sistemas en producción es recomendable utilizar un nivel de log ERROR. Niveles inferiores degradan el rendimiento del sistema y sólo son aconsejables para tareas de depuración.

5.3 EXPORTACIÓN DE METADATOS DEL SERVIDOR

Desde el menú “File” de la herramienta de administración gráfica de Virtual DataPort, puede utilizarse la opción “Export …” para exportar todos los metadatos del servidor a un fichero VQL. Se exportarán los metadatos de todas las bases de datos del servidor, junto con sus usuarios y los permisos sobre las mismas. Para hacer uso de esta opción, el usuario debe ser de tipo administrador. Ejecutando el fichero VQL obtenido, podrán recrearse totalmente los metadatos del servidor DataPort en su estado en el momento de la exportación. Esta funcionalidad es especialmente útil para propósitos de respaldo (“backup”) y/o migración a otras instalaciones de Virtual DataPort. También es posible exportar solamente los metadatos de la base de datos activa utilizando la opción “Export Database”. En este caso, es suficiente con tener permisos sobre la base de datos a exportar. La exportación de una base de datos puede realizarse también desde su pantalla de configuración (ver sección 8.3.2). DataPort también proporciona scripts para programar la realización de copias de respaldo automáticas (ver sección 10.3).


Creación Visual de Vistas 23

6 CREACIÓN VISUAL DE VISTAS

En esta sección se describe cómo utilizar la herramienta de administración gráfica de Virtual DataPort para crear gráficamente vistas unificadas de datos procedentes de diversas fuentes heterogéneas. Como guía en la descripción del proceso utilizaremos el siguiente ejemplo: Ejemplo: Información unificada de incidencias y ventas de clientes. Una operadora de telecomunicaciones ofrece, entre otros, servicios de telefonía e Internet a sus clientes. La información sobre las incidencias notificadas en el servicio de telefonía se encuentra en una base de datos relacional que es accedida a través de JDBC. La información sobre las incidencias notificadas en el servicio de Internet se encuentra almacenada en otra base de datos relacional accedida también a través de JDBC. En nuestro ejemplo, el jefe del departamento de sistemas desea realizar un seguimiento del número de incidencias (ya sea de telefonía o Internet) notificadas por los clientes con mayor volumen de ventas, con el objetivo de detectar si es necesario tomar medidas para incrementar la satisfacción de los mismos. La información sobre el volumen de ventas de los clientes es gestionada por otro departamento de la operadora. Dicho departamento ofrece al resto de departamentos una interfaz Web Service para acceder a dicha información. En este ejemplo veremos cómo Virtual DataPort puede utilizarse para construir una vista unificada de datos que permita solucionar la necesidad del departamento de sistemas, permitiendo obtener el número total de incidencias de los clientes con mayor volumen de ventas. En la ruta DENODO_HOME/samples/vdp/incidences se encuentran scripts SQL para la creación en MySQL 4.1 y Oracle 9.0.1 de las tablas utilizadas en el ejemplo. También se incluye un fichero WSDL con la descripción del servicio web utilizado, así como un fichero .war con una implementación del mismo que ha sido probado con Tomcat 5.x [TOM] y Axis 1.x [AXIS].

6.1 ACCESO A LA HERRAMIENTA GRÁFICA DE ADMINISTRACIÓN

El primer paso es acceder a la herramienta en modo de administración de una base de datos (ver sección 4.1). Si no ha creado aún una base de datos propia y usuarios propios (véase sección 7), puede utilizar la base de datos (llamada admin) y el usuario (admin) creados por defecto al instalar un servidor DataPort. Para la realización de las acciones que se estudiarán a lo largo del ejemplo, es necesario haber accedido a la herramienta con un usuario con privilegios suficientes sobre la base de datos de Virtual DataPort sobre la que se está trabajando (ver sección 7). Los usuarios de tipo administrador (como el usuario por defecto admin) disponen de todos los privilegios.

6.2 CREACIÓN Y MANEJO DE PROYECTOS

Los diferentes componentes (datasources, relaciones base y vistas) que pueden crearse mediante la herramienta de administración de DataPort se agrupan en proyectos. Al iniciar la herramienta por primera vez sólo existirá un proyecto llamado ‘Default’. Para crear un nuevo proyecto debe seleccionarse la pestaña ‘Project Management’ y pulsar en la opción ‘new’ (ver Figura 8).



En esta pantalla se debe especificar un nombre para el proyecto y, opcionalmente, una descripción del mismo. Al pulsar ‘ok’ se creará el nuevo proyecto. En nuestro ejemplo crearemos un nuevo proyecto al que llamaremos ‘VDPExample’.

Figura 8 Creación de un Nuevo proyecto

Puede editarse un proyecto haciendo click sobre el nombre del mismo en el menú desplegable de la parte izquierda de la pantalla o borrarse haciendo uso de la opción ‘drop’. Si se elimina un proyecto, los elementos que contenga se mueven automáticamente al proyecto ‘default’. NOTA: estos proyectos sólo existen en la herramienta cliente utilizada para crearlos.

6.2.1 Cambiar elementos a otros proyectos

Tal y como se verá en apartados posteriores, al crear un nuevo datasource o una nueva vista, el nuevo elemento creado podrá ser asignado a uno de los proyectos existentes. Si más adelante se desea mover el elemento a otro proyecto, deben realizarse las siguientes acciones:

1. Desplegar los menús de la izquierda de la pantalla hasta localizar el elemento deseado. Los datasources estarán accesibles desde la pestaña ‘Data Sources’ mientras que las vistas lo estarán desde la pestaña ‘Query Builder’.

2. Hacer click con el botón derecho del ratón sobre el elemento que se desea mover y utilizar la opción ‘Move

to Project’ para seleccionar el proyecto destino.



6.3 IMPORTACIÓN DE DATASOURCES Y CREACIÓN DE RELACIONES BASE

El primer paso para la realización de nuestro ejemplo es la importación de las fuentes involucradas y la creación de las relaciones base (también llamadas vistas base) que representarán dentro de DataPort la información necesaria para la construcción de las vistas unificadas. Para realizar estas tareas es necesario acceder a la pestaña ‘Data Sources’ de la herramienta de administración. Comenzaremos viendo cómo importar fuentes de tipo ‘Base de datos’ lo que nos permitirá importar las bases de datos de incidencias de nuestro ejemplo (sección 6.3.1). Posteriormente se tratará el caso de la importación de fuentes de tipo Web Service (sección 6.3.2), lo que en nuestro ejemplo nos servirá para importar la información sobre ventas. La sección 6.3.3 describe como eliminar fuentes de datos una vez añadidas. Las diferencias con la importación de otros tipos de fuentes de datos, así como determinados aspectos avanzados, se tratarán más adelante en la sección 6.4.11. Una vez añadidas las fuentes de datos, se tratará la creación de relaciones base desde las mismas. En la sección 6.3.4 se trata de la creación de relaciones base desde fuentes de tipo Base de Datos, mientras que en la sección 6.3.6 se aborda el caso de la creación de relaciones base desde Web Services. El caso de otros tipos de fuentes, así como determinados aspectos avanzados, será comentado más adelante en la sección 6.4.11.

6.3.1 Importación de Fuentes de tipo JDBC

Para crear una nueva fuente de datos (DataSource) es necesario acceder a la pestaña “Data Sources” en la parte izquierda de la herramienta. Al hacerlo aparecerá una lista de los proyectos creados y debe hacerse click sobre el proyecto al que desea añadirse la nueva fuente. En nuestro ejemplo, seleccionaremos el proyecto ‘VDPExample’ que hemos creado anteriormente. A continuación, podrá desplegarse el menú “Relational DBs”. Al desplegarse dicho menú, aparecerá la lista de bases de datos externas añadidas actualmente como fuentes en la base de datos de Virtual DataPort clasificadas en función de si el acceso a la misma se realiza a través de JDBC o de ODBC. Para añadir una nueva base de datos JDBC a la lista es necesario hacer click en la opción ‘New’ que aparece al lado de la lista de bases de datos JDBC. Se accederá entonces a la pantalla de creación de una nueva fuente de datos de este tipo (ver Figura 9). En esta pantalla se solicitarán los siguientes datos:

• Nombre con el que se denominará a la fuente de datos (Data Source) dentro de Virtual DataPort. En nuestro ejemplo, al añadir la base de datos de incidencias del servicio de teléfono podemos utilizar el nombre phone_center. Al añadir la base de datos de incidencias del servicio de Internet podemos utilizar el nombre internet_center.

• Adaptador de base de datos. En este seleccionable es posible escoger uno de los gestores de bases de datos para los que DataPort incluye un adaptador. También se incluye un adaptador “Generic” que puede utilizarse con los gestores JDBC para los que no existe un adaptador específico. Los adaptadores específicos permiten diversas optimizaciones en el acceso a cada gestor, por lo que es preferible utilizarlos cuando sea posible. Si se marca la opción “Choose automatically” (recomendado), DataPort escogerá automáticamente el adaptador a utilizar mediante una conexión a la base de datos. Al seleccionar un adaptador, se rellenarán de forma automática los dos campos siguientes con sus valores correctos (Ruta al fichero .jar y nombre de la clase del driver JDBC) y el campo “Uri de acceso” se rellenará con una “plantilla” para la uri de conexión al gestor seleccionado. En el Apéndice: Drivers JDBC se listan los drivers JDBC incluidos y/o utilizados habitualmente con DataPort.

• Ruta al fichero .jar que contiene el driver JDBC a utilizar (opcional). En caso de que se vaya a utilizar un driver JDBC que no venga incluido con DataPort, este campo permite especificar una librería .jar externa que contenga el driver deseado. Si no se especifica, se deberá utilizar un driver disponible en el CLASSPATH actual del servidor DataPort.



• Nombre de la clase del Driver JDBC a utilizar. Por ejemplo, para una base de datos MySQL podría utilizarse típicamente el valor com.mysql.jdbc.Driver. Véase el Apéndice: Drivers JDBC para consultar los detalles acerca de los drivers JDBC incluidos y/o utilizados habitualmente con DataPort.

• Uri de acceso a la base de datos. En nuestro ejemplo suponiendo que se utiliza una base de datos MySQL donde la base de datos de incidencias se llama phone_center, y que esta se encuentra en la máquina acme escribiríamos: jdbc:mysql://acme/phone_center. Véase el Apéndice: Drivers JDBC para consultar los formatos adecuados para los drivers JDBC incluidos /o utilizados habitualmente con DataPort

• Login de usuario para acceso a la base de datos externa. • Contraseña del usuario para el acceso a la base de datos externa. • Si se marca la opción ‘Choose automatically’ (recomendado), el sistema se conectará a la base de datos

para obtener automáticamente el adaptador más adecuado. Si se marca esta opción, también se selecciona automáticamente la opción “Test Connection”.

• Finalmente, si se marca la opción ‘Test Connection’, el sistema efectuará una conexión de prueba a la fuente. Esto permite comprobar que la base de datos está accesible para el servidor DataPort.

Figura 9 Importación de una Fuente de Datos JDBC

Opcionalmente es posible utilizar la opción ‘Driver Properties’ para añadir propiedades (pares campo-valor) que se añadirán a la URI de conexión. También puede accederse también a la opción “Connections Pool Configuration” para configurar diversos parámetros del pool de conexiones que Virtual DataPort utilizará para optimizar el acceso a la base de datos externa (ver Figura 10). Los parámetros que pueden ser configurados son:



• Initial Size: Número de conexiones con las que se desea inicializar el pool. Se establecen y crean un número de conexiones en estado “idle” (ociosas), listas para ser utilizadas.

• Max Active: Número máximo de conexiones activas que puede gestionar el pool al mismo tiempo (cero implica sin límite)

• Ping Query: Consulta SQL utilizada por el pool para verificar el estado de las conexiones que se encuentran cacheadas. Es preciso que la consulta sea sencilla y exista la tabla en cuestión.

NOTA: A partir de la versión 3.5 de Virtual DataPort, el resto de parámetros que eran configurables en versiones anteriores han dejado de serlo. Para nuestro ejemplo, dejaremos todos los parámetros con su valor por defecto para ambas bases de datos.

Figura 10 Configuración del Pool de conexiones JDBC

Una vez que se pulse el botón ‘Ok’ en la pantalla de creación de la fuente de datos, ésta aparecerá ya en la lista mostrada en el menú de la parte izquierda de la pantalla.

6.3.2 Importación de Fuentes de Tipo Web Service

Siguiendo con nuestro ejemplo, el siguiente paso es añadir la fuente de datos (Data Source) que nos permite acceder a la información de ventas. Tal y cómo se ha comentado, esta fuente es de tipo Web Service. Para crear una nueva fuente de datos (DataSource) representando a un Web Service es necesario acceder a la pestaña “Data Sources”, y tras seleccionar el proyecto al que deseamos añadir la nueva fuente (VDPExample, en nuestro ejemplo), hacer click en la opción ‘New’ que aparece al lado de la lista de Web Services actuales. Se accederá entonces a la pantalla de creación de una nueva fuente de datos de tipo Web Service (ver Figura 11). En esta pantalla se solicitarán los siguientes datos:



• Nombre con el que se denominará a la fuente de datos dentro de Virtual DataPort. En nuestro ejemplo, al

añadir el servicio web de ventas podemos utilizar el nombre sales. • Ruta al fichero WSDL conteniendo la especificación del servicio web. En nuestro ejemplo, la ruta podría ser

$DENODO_HOME/samples/vdp/incidences/sales.wsdl. También es posible especificar una URL http.

Figura 11 Importación de una fuente de datos de tipo Web Service

6.3.3 Eliminación de una fuente de datos

Una vez que se ha añadido una fuente de datos es posible eliminarla haciendo clic en la opción ‘drop’ que aparece al lado de la fuente en la lista del desplegable DataSources. Si existen otros elementos del catálogo de DataPort (e.g. vistas) que dependen de la fuente, se mostrará un mensaje al usuario avisando de que el borrado se realizará en cascada. Si el usuario decide proseguir con la operación, los elementos dependientes del datasource serán también eliminados. Si el usuario que está realizando la operación no dispone de los permisos adecuados sobre todos los elementos involucrados, la operación de borrado fallará

6.3.4 Creación de Relaciones Base partiendo de una Base de Datos

Una vez añadida una fuente de datos al sistema es posible crear relaciones base desde ella. Para ello, debe pulsarse sobre la fuente de datos en la lista de la parte izquierda de la pantalla, accediendo así a los contenidos de la misma. En el caso de fuentes de tipo base de datos, al realizar esta acción se mostrará un árbol con los diversos esquemas de los que consta la base de datos externa, permitiendo ver también las tablas de las que consta así cómo los campos que componen las mismas (ver Figura 12).



Figura 12 Esquemas y tablas de una fuente JDBC

Al lado de cada tabla de la base de datos externa aparece la opción ‘Create base view’. Si se pulsa este botón, el sistema generará automáticamente el esquema de una relación base a partir de la tabla seleccionada y se mostrará al usuario (ver Figura 13). Si se desea, es posible modificar en este momento el nombre de la relación base, y el nombre y el tipo de los atributos que la componen. Mediante el seleccionable ‘Target Project’ puede especificarse el proyecto al que desea asignarse la nueva vista. En nuestro ejemplo, seleccionaremos el proyecto ‘VDPExample’. Una vez aceptado su esquema, la nueva relación base podrá verse en la parte izquierda de la pantalla colgando de la fuente (base de datos, en este caso) a la que pertenece la tabla utilizada. En nuestro ejemplo crearemos una relación base para la tabla phone_inc de la base de datos de telefonía y otra para la tabla internet_inc de la base de datos de Internet. phone_inc permite acceder a los datos de las incidencias registradas en el servicio de telefonía. Incluye campos que representan el CIF del cliente (taxId) que ha notificado la incidencia, un identificador de incidencia (pinc_id), una descripción de la misma (description), el momento temporal en el que se produjo (time), un tipo de incidencia (inc_type) y un campo específico adicional (specific_field3). Los atributos de internet_inc incluyen el CIF del cliente (taxId) que ha notificado la incidencia, un identificador de incidencia (iinc_id), una descripción de la misma (summary), el momento temporal en el que se produjo (time), y otros dos campos específicos adicionales (specific_field1 y specific_field2). También es posible crear una relación base a partir de una consulta SQL sobre la base de datos (botón ‘Create Base View From Query’). El uso de esta opción se explicará en el apartado 6.5.10.



Figura 13 Aceptación del esquema de una relación base

6.3.5 Viendo el esquema de una relación base

Haciendo click en una relación base que hayamos creado, podremos acceder a la página que muestra su esquema dentro de Virtual DataPort (ver Figura 14 y Figura 15 con los esquemas de las relaciones base generadas a partir de phone_inc e internet_inc). Una vez creada la relación base, si se desea modificar su esquema para eliminar atributos o cambiar el nombre de los mismos debe utilizarse una vista proyección sobre la misma (ver sección 6.4.6). Pulsando el botón ‘Edit’ se accede directamente a la pantalla de creación de una vista proyección sobre la relación base. Otra alternativa es sustituir la vista por otra con el mismo nombre (ver sección 6.4.11). Otras acciones posibles desde esta pantalla son:

• Ejecutar la vista (botón ‘Execute’). Obtiene las tuplas de la vista. Por defecto el sistema ejecutará una consulta ‘select * from viewname’ dónde viewname es el nombre de la vista. Sin embargo, la herramienta ofrece también la opción de acceder al editor de condiciones antes de la ejecución para crear una condición de selección sobre la vista (ver sección 6.4.4.1).

• Borrar la vista (botón ‘Delete’). Si hay otras vistas derivadas que utilicen en su definición a la vista a borrar, la herramienta avisará al administrador de que el borrado de la vista producirá el borrado en cascada de las vistas derivadas.

• Ver el código VQL generado para la creación de la vista (botón ‘View VQL’). Se muestran tanto las sentencias requeridas por la vista actual como las necesarias para crear todas las vistas de las que depende. De la misma forma también se muestran las sentencias de creación de los tipos, wrappers y datasources necesarios para definir completamente el elemento del catálogo seleccionado. Antes de la sentencia de creación de un elemento, se muestra la sentencia de borrado de ese elemento, de tal forma



que la ejecución del conjunto de sentencias mostrado resultará en la reconstrucción completa de ese elemento en el catálogo (borrando las ocurrencias previas, si las había).

• Ocultar la vista (botón ‘Hide View’). Si se pulsa este botón, la vista no se mostrará en la lista de la parte izquierda de la pantalla. Para que vuelva a aparecer puede utilizarse el menú ‘View-Hidden Views’ y seleccionar la vista ‘oculta’ que se desea que aparezca de nuevo en la lista.

Desde esta pantalla es posible también acceder a los aspectos de configuración avanzada de la vista (botón ‘Advanced’), aunque retrasaremos la explicación de esta opción hasta el apartado 6.5.11.

Figura 14 Esquema de la vista base phone_inc



Figura 15 Esquema de la vista base internet_inc

6.3.6 Creación de Relaciones Base partiendo de un Web Service

Una vez añadida una fuente de datos de tipo Web Service al sistema es posible crear relaciones base desde ella. Para ello, debe pulsarse sobre la fuente de datos en la lista de la parte izquierda de la pantalla, accediendo así a los contenidos de la misma. En el caso de fuentes de tipo Web Service, al realizar esta acción se mostrarán los diversos puertos de los que consta el Web Service. Para cada puerto se mostrará la lista de operaciones que incluye. En el detalle de cada operación se mostrarán sus parámetros de entrada, sus parámetros de salida y sus parámetros de entrada/salida (ver Figura 16). En nuestro ejemplo, el servicio web sales consta de un único puerto que contiene diversas operaciones. La operación que nos interesa recibe el nombre getAverageMonthlyRevenueBytaxID. Tiene un parámetro de entrada llamado ‘in0’ que especifica el cif (taxID) de un cliente y devuelve a la salida su volumen medio de ventas mensuales. A lado de cada operación del Web Service aparece un botón ‘Create base view’. Si se pulsa este botón, el sistema generará automáticamente el esquema de una relación base a partir de la operación seleccionada y se mostrará al usuario. Si se desea, es posible modificar en este momento el nombre de la relación base y el nombre y tipo de los atributos que la componen. Mediante el seleccionable ‘Target Project’ puede especificarse el proyecto al que desea asignarse la nueva vista. En nuestro ejemplo, seleccionaremos el proyecto ‘VDPExample’. En nuestro ejemplo cambiaremos el nombre de la relación base por el de average_monthly_sales, el del campo ‘in0’ por ‘taxId’ y el del campo ‘GetAverageMonthlyRevenueBytaxIdReturn’ por ‘revenue’.



Figura 16 Operaciones y parámetros de un Web Service

Una vez aceptado su esquema, la nueva relación base podrá verse en la parte izquierda de la pantalla colgando de la fuente de tipo Servicio Web a la que pertenece la operación utilizada. Haciendo click en una relación base que hayamos creado, podremos acceder a la página que muestra su esquema dentro de Virtual DataPort (ver Figura 17). Las opciones disponibles en esta pantalla fueron descritas en la sección 6.3.5. Si bien no es el caso en la operación utilizada en nuestro ejemplo, puede ocurrir que los resultados devueltos por una operación sean de tipo compuesto (e.g. arrays de elementos). En ese caso, dichos resultados se representarán en la relación base mediante campos de los tipos compuestos DataPort array y register. En ocasiones puede ser conveniente “aplanar” estos campos para conseguir una granularidad más adecuada en las tuplas de la relación base. En la sección 6.4.7 se explica como realizar esto. Otra situación similar ocurre cuando una operación importada desde un Servicio Web requiere parámetros de tipos compuestos (e.g. un array de elementos) a la entrada. En ese caso, los parámetros de entrada de la operación también se representarán en la relación base mediante los tipos compuestos DataPort array y register. Además para construir condiciones de consulta sobre esta relación base será necesario utilizar los constructores ROW (para crear elementos de tipo register) y ‘{ }’ para crear elementos de tipo array. En la sección 6.4.4.1.4 se muestra un ejemplo de esta situación.



Figura 17 Esquema de la vista base average_monthly_sales

6.4 CREACIÓN VISUAL DE VISTAS

Una vez creadas las relaciones base con la información que precisamos de las fuentes, es posible acceder a la pestaña ‘Query Builder’ para crear visualmente vistas derivadas que combinen e integren su información de la manera deseada. Las vistas tienen las siguientes características:

• Una vista es una relación más dentro del catálogo de Virtual DataPort. Podrá por lo tanto aparecer en la claúsula FROM de cualquier consulta VQL y podrá ser utilizada como base para la construcción de nuevas vistas o consultas.

• Sobre una vista puede utilizarse la cache y pueden definirse privilegios de uso (ver sección 7). • Al crear una vista se precomputan parcialmente sus planes de ejecución. Esto se traduce en una ejecución

más eficiente de las consultas sobre vistas.

Las siguientes secciones detallan el proceso de creación visual de vistas utilizando nuestro ejemplo para ilustrar el proceso.

6.4.1 Creación de Vistas de Tipo Unión

Una vista de tipo unión permite contener en una única vista las tuplas provenientes de diversas relaciones de entrada. Para realizar la operación de unión en álgebra relacional estándar, se precisa que todas las relaciones tengan el mismo esquema, es decir, los mismos atributos y del mismo tipo. Sin embargo, en Virtual DataPort se utiliza una



unión extendida por la cuál, si alguna de las relaciones de entrada tiene algún atributo que no está presente en las otras, éste se añade a la vista resultante. Para definir una vista unión es necesario desplegar el menú ‘Toolbox - Relational Operations y seleccionar la opción ‘Union’. Para seleccionar las relaciones sobre las que se desea realizar la operación de unión, se debe hacer drag&drop desde la lista de vistas y relaciones base que aparecen en la parte izquierda de la pantalla. En nuestro ejemplo, haremos drag & drop de las vistas base phone_inc e internet_inc (ver Figura 18). Según se añaden vistas de entrada, se va generando automáticamente el esquema de la vista unión resultado. Los esquemas de las vistas de entrada se muestran a la izquierda del área de trabajo mientras que el esquema de salida se muestra a la derecha.

Figura 18 Construcción de la vista unión de phone_inc e internet_inc

Debajo de las vistas de entrada, se muestra también una ‘Lista de asociaciones’ entre sus campos. Los campos unidos por una asociación se considerarán como un único atributo en el esquema de salida. Para que sea posible establecer una asociación entre dos campos es necesario que tengan el mismo tipo. Por defecto, el sistema creará asociaciones entre los atributos que tengan el mismo nombre y el mismo tipo (en nuestro ejemplo esto ocurre con los campos time y taxId). Es también posible especificar asociaciones adicionales entre atributos que en las diferentes vistas de entrada reciben nombres diferentes En nuestro ejemplo haremos esto con los atributos description de phone_inc y summary de internet_inc.



Para ello basta hacer un drag & drop desde un atributo al otro y en el esquema de salida aparecerá un único atributo representando a ambos. El nombre asignado al atributo en el esquema de salida será el del primer atributo marcado en la operación de drag & drop. También es posible borrar una asociación creada previamente mediante el uso del botón “[x]” situado al lado de cada asociación. Sobre el esquema de la vista de salida es posible cambiar los nombres de los atributos, cambiar el nombre de la vista resultado y también eliminar los atributos que no sean necesarios en la vista (esto supone, de forma implícita, una vista de tipo proyección. Ver sección 6.4.6). En nuestro ejemplo eliminaremos los campos pinc_id, iinc_id, specific_field1, specific_field2 y specific-field3 ya que no son necesarios para nuestros propósitos. Como nombre para la vista resultante escogeremos incidences. También es posible añadir nuevos atributos derivados a la vista unión resultante mediante el uso del botón ‘New Field’, que permite acceder al editor de expresiones de atributo derivado (ver sección 6.4.6.1). Una vez que la vista de salida tiene ya la forma deseada, basta pulsar el botón ‘ok’ para crearla. Haciendo click sobre ella en la lista en la parte izquierda de la pantalla se accederá a su esquema. Por último, mediante el seleccionable ‘Target Project’ puede especificarse el proyecto al que desea asignarse la nueva vista. En nuestro ejemplo, seleccionaremos el proyecto ‘VDPExample’.

6.4.2 Viendo el Esquema de una vista

Haciendo click sobre la vista se accederá al esquema de la misma (ver Figura 19). Además de las opciones disponibles para vistas base (ver sección 6.3.5) desde esta pantalla también es posible acceder a una representación en árbol de la vista que muestra cómo ésta se define en función de relaciones base y operadores de álgebra relacional usando el botón ‘Tree View’.

Figura 19 Esquema de la vista unificada de incidencias: incidences



6.4.3 Creación de Vistas de tipo Join

Una vista de tipo Join permite realizar la operación de álgebra relacional del mismo nombre sobre una serie de vistas de entrada. Para definir una vista join es necesario desplegar el menú ‘Toolbox - Relational Operations’ y seleccionar la opción ‘Join’. Para seleccionar las relaciones sobre las que se desea realizar la operación de join se debe hacer drag&drop desde la lista de vistas y relaciones base que aparecen en la parte izquierda de la pantalla. En nuestro ejemplo, haremos drag & drop de la vista incidences y de la vista base average_monthly_sales (ver Figura 20). Según se añaden vistas de entrada, se va generando automáticamente el esquema de la vista join resultado. Los esquemas de las vistas de entrada se muestran a la izquierda del área de trabajo mientras que el esquema de salida se muestra a la derecha. Para añadir una condición de join es necesario especificar el operador involucrado en el seleccionable que aparece al lado del texto “Operator” y, a continuación, hacer un drag & drop que enlace los atributos de join entre sí en las vistas de entrada. El nombre asignado al atributo en el esquema de salida será el del primer atributo marcado en la operación de drag & drop. En nuestro ejemplo seleccionaremos el operador ‘=’ y haremos un drag& drop desde el atributo taxId de la vista incidences al atributo taxId de la vista average_monthly_sales, definiendo así la condición de join incidences.taxId=average_monthly_sales.taxId

Figura 20 Construcción de Vista join de incidences y average_monthly_sales



Puede especificarse también el tipo de operación de join deseada: inner, left outer, right outer o full outer (ver ‘Cláusula FROM’ en la Guía Avanzada de VQL [VQL]). En nuestro ejemplo utilizaremos un ‘inner join’ convencional. También pueden fijarse las preferencias sobre la estrategia de ejecución del join. Esta elección puede tener implicaciones importantes en la optimización de consultas (ver ‘Optimización de Consultas’ en la Guía Avanzada deVQL [VQL]). Involucra dos parámetros:

• Método de ejecución (merge, hash, nested o nested parallel). En el caso de que el método escogido sea nested_parallel, será posible escoger también el número máximo de subconsultas en paralelo que se ejecutarán sobre la segunda fuente (ver ‘Optimización de Consultas’ en la Guía Avanzada de VQL [VQL] para más información sobre los métodos de ejecución de joins).

• Orden en el que deben considerarse las relaciones de entrada. La vista de la parte superior se considerará como primera relación si se escoge la opción Ordered y como segunda si se escoge Reverse Order).

En nuestro ejemplo, no fijaremos ninguna preferencia para la estrategia de ejecución, dejando al servidor VDP que seleccione la que considere mejor. Sobre el esquema de la vista de salida es posible cambiar los nombres de los atributos, cambiar el nombre de la vista resultado (por defecto será vista1_j_vista2) y también eliminar los atributos que no sean necesarios en la vista (esto supone una vista de tipo proyección de forma implícita. Ver sección 6.4.6). En nuestro ejemplo fijaremos el nombre de la vista a incidences_sales y eliminaremos uno de los atributos taxId. También es posible añadir nuevos atributos derivados a la vista resultante mediante el uso del botón ‘New Field’, que permite acceder al editor de expresiones de atributo derivado (ver sección 6.4.6.1). Por último, mediante el seleccionable ‘Target Project’ puede especificarse el proyecto al que desea asignarse la nueva vista. En nuestro ejemplo, seleccionaremos el proyecto ‘VDPExample’. Una vez que la vista de salida tiene ya la forma deseada, basta pulsar el botón ‘ok’ para crearla. Haciendo click sobre ella en la lista en la parte izquierda de la pantalla se accederá a su esquema (ver Figura 21).



Figura 21 Esquema de la vista join incidences_sales

6.4.3.1 Condiciones de join con operadores de similitud

DataPort soporta condiciones de join que utilicen operadores de similitud. La evaluación de un operador de similitud devuelve un valor entre 0 y 1 que estima la similitud entre los operandos utilizando un determinado algoritmo de similitud. Además de los operandos a comparar, el operador recibe como parámetros el algoritmo de similitud a utilizar y un umbral mínimo de similitud. Si la similitud entre los operandos alcanza o supera el umbral, la condición se evalua como verdadera. En caso contrario, se evalua como falsa. DataPort 4.0 incluye el operador ~ para evaluar la similitud entre operandos de tipo cadena de caracteres. Para este propósito, DataPort incluye algoritmos basados en la distancia de edición entre los textos (algoritmos ScaledLevenshtein, JaroWinkler, Jaro, Level2Jaro, MongeElkan, Level2MongeElkan), en la aparición de términos comunes a los dos textos (algoritmos TFIDF, Jaccard, UnsmoothedJS), o combinaciones de ambos (JaroWinklerTFIDF). Si no se especifica ningún algoritmo, DataPort escogera cuál aplicar. Si se selecciona el operador ~ como operador de una condición de join, debe especificarse el algoritmo de similitud que se desa utilizar (si se escoge la opción default, el algoritmo será escogido por DataPort) y el umbral mínimo de similitud que debe alcanzarse para que se considere que los operandos emparejan. Ejemplo: Consideremos una variación de nuestro ejemplo en la que los clientes son identificados por su nombre en lugar de por su taxid. Desafortunadamente, el nombre de los clientes en las bases de datos de incidencias no coincide exactamente con su nombre en el Servicio Web de ventas, por lo que una operación de join con el operador de igualdad no producirá buenos resultados. En este caso, puede utilizarse un join con un operador de similitud para solucionar este problema.



El ejemplo incidences incluido con la distribución permite también reproducir esta situación. Se incluyen dos tablas relacionales adicionales llamadas internet_inc_cname y phone_inc_cname. Estas tablas son similares a las tablas internet_inc y phone_inc, que se han venido utilizando en nuestro ejemplo, pero incluyen un atributo customer_name que indica el nombre del cliente en lugar del atributo taxid. El servicio web sales incluye también una operación llamada GetAverageMonthlyRevenueCName que devuelve un elemento de datos compuesto conteniendo el nombre y la facturación mensual de todos los clientes. Para solucionar el problema planteado por este ejemplo pueden seguirse los siguientes pasos:

1. Crear vistas base para las tablas internet_inc_cname y phone_inc_cname (ver sección 6.3.3).

2. Crear una vista base para la operación GetAverageMonthlyRevenueCName (ver sección 6.3.6). 3. Realizar la unión de las vistas base creadas para internet_inc_cname y

phone_inc_cname (ver sección 6.4.1). 4. “Aplanar” el elmento compuesto devuelto por la vista creada para la operación

GetAverageMonthlyRevenueCName. Véase la sección 6.4.7 para una explicación detallada del proceso de “aplanamiento” de elementos de datos compuestos.

5. Realizar la vista join por el campo customer_name entre la vista obtenida como resultado del paso 3 y la vista obtenida como resultado del paso 4. Especifique el operador • como operador de join y fije el umbral de similitud a 0.7.

6. Ejecute la vista obtenida en el paso 5. Se observará como el join es realizado correctamente a pesar de que los nombres de los clientes en las vistas de entrada no eran exactamente iguales.

6.4.4 Creación de Vistas de tipo Selección

Una vista de tipo Selección permite ejecutar una condición sobre una vista de entrada. Para definir una vista selección es necesario desplegar el menú ‘Toolbox - Relational Operations’ y seleccionar la opción ‘Selection’. Para seleccionar la vista sobre la que se desea realizar la operación de selección, se debe hacer drag&drop desde la lista de vistas y relaciones base que aparecen en la parte izquierda de la pantalla. En nuestro ejemplo, haremos drag & drop de la vista incidences_sales (ver Figura 22). Para añadir una condición de selección es necesario pulsar el botón ‘Set Condition’, accediendo de esta forma al editor de condiciones, que nos permitirá crear la condición deseada (véase la sección 6.4.4.1). Una vez creada la condición, basta pulsar el botón ‘OK’ y la condición se añadirá a la vista selección. En nuestro ejemplo, introduciremos la condición revenue>1000 para retener sólo los datos de aquellos clientes para los cuáles el volumen mensual medio de ventas supera los 1.000 euros. Sobre el esquema de la vista de salida es posible cambiar los nombres de los atributos, cambiar el nombre de la vista resultado (en nuestro ejemplo escogeremos pref_clients_inc_sales) y eliminar los atributos que no sean necesarios en la vista (esto supone una vista de tipo proyección de forma implícita). También es posible añadir nuevos atributos derivados a la vista resultante mediante el uso del botón ‘New Field’, que permite acceder al editor de expresiones de atributo derivado (ver sección 6.4.6.1). Por último, mediante el seleccionable ‘Target Project’ puede especificarse el proyecto al que desea asignarse la nueva vista. En nuestro ejemplo, seleccionaremos el proyecto ‘VDPExample’.



Figura 22 Construcción de la vista selección pref_clients_inc_sales

Una vez que el esquema de la vista de salida tiene ya la forma deseada, basta pulsar el botón ‘ok’ para que la nueva vista sea creada y aparezca en la lista de la parte izquierda de la pantalla.

6.4.4.1 Utilización del Editor de Condiciones

El editor de condiciones (ver Figura 23) permite crear condiciones de selección. La condición puede escribirse directamente en formato VQL en la caja ‘Selection Condition’ o puede crearse de manera totalmente gráfica. A continuación se describe este último proceso. En la parte izquierda de la pantalla encontramos menús para crear diversos valores que pueden aparecer como operandos en las condiciones:

• Constantes. Este menú permite crear constantes de los diversos tipos de dato soportados por Virtual DataPort.

• Funciones. Este menú permite crear una invocación a una de las funciones permitidas por Virtual DataPort. Las funciones pueden recibir como parámetros constantes, atributos o el resultado de evaluar otras funciones. Devuelven un único resultado. La lista de funciones disponibles y el uso de cada una de ellas puede consultarse en la Guía Avanzada de VQL [VQL].

• Atributos. Se corresponde con la lista de atributos de la vista sobre la que se aplica la selección. Los atributos pueden actuar como parámetros de funciones y/o pueden aparecer directamente como operandos en las condiciones.



Figura 23 Editor de condiciones de selección

En la parte derecha de la pantalla encontramos menús para seleccionar los diversos operadores que pueden aparecer en las condiciones:

• Operadores que pueden participar en las condiciones simples. Se agrupan por el tipo de datos al que son aplicables. NOTA: Los tipos de datos xml y blob no se muestran en el menú derecho de operadores puesto que carecen de operadores.

• Operadores lógicos (AND, OR, NOT). Se utilizan para combinar las diferentes condiciones simples en una expresión booleana.

Las cajas centrales de la pantalla permiten la construcción de, de arriba a abajo, tres tipos de elementos: valores que aparecerán en las condiciones, condiciones simples y condiciones booleanas compuestas. La caja de la izquierda de cada grupo es un espacio de trabajo para la creación de nuevos elementos mientras que la caja de la derecha muestra los elementos ya creados. Los siguientes subapartados describirán con más detalle la creación de cada uno de estos tipos de elementos. Por último, la caja “Selection condition” contendrá la condición de selección finalmente creada.

6.4.4.1.1 Creación de valores para las condiciones

Para crear un nuevo valor constante deben realizarse las siguientes acciones:

1. Seleccionar el tipo de dato de la constante en el desplegable ‘Constants’ de la parte izquierda de la pantalla y hacer ‘click’ o drag & drop sobre el espacio de trabajo de creación de valores (caja superior izquierda).



2. Aparecerá en el espacio de trabajo el tipo seleccionado, junto con un área de texto para rellenar el valor de la constante.

a. Si la constante es de tipo simple, el valor deseado puede escribirse directamente en el área de texto.

b. Si es de tipo compuesto (array o register), al pulsar el botón ‘□’ que aparece al lado del área de texto, se abrirá un nuevo panel para editar los valores de la constante deseada (ver sección 6.4.4.1.4).

c. Si es de tipo xml, al pulsar el botón ‘□’ se abrirá un panel que permite o bien escribir el valor deseado o bien cargarlo desde un fichero.

3. Al pulsar el botón ‘>’ la nueva constante aparecerá en la lista de valores creados (caja superior derecha). Para crear un nuevo valor de tipo función, deben realizarse las siguientes acciones:

1. Seleccionar la función deseada en el desplegable ‘Functions’ de la parte izquierda de la pantalla y hacer ‘click’ o drag & drop sobre el espacio de trabajo de creación de valores (caja superior izquierda).

2. Aparecerá en el espacio de trabajo la función seleccionada, junto con un área para rellenar el valor de cada parámetro de la función. Los valores de los parámetros deben estar presentes en la lista de valores creados (caja superior derecha). Para asignar un valor ya creado como parámetro de una función, se hará una operación de drag & drop que lleve el valor creado al área del parámetro. Al pulsar el botón ‘>’ que aparece al lado de la función, ésta aparecerá en la lista de valores creados (caja superior derecha).

En nuestro ejemplo, crearemos un nuevo valor constante de tipo Float. Para ello arrastraremos el tipo Float sobre el espacio de trabajo y rellenaremos el valor de la misma que, en este caso, será 1000 (ver Figura 24).

Figura 24 Creación de una constante

6.4.4.1.2 Creación de condiciones simples



Para crear una nueva condición simple deben realizarse las siguientes acciones:

1. Seleccionar el operador de condición simple deseado en los desplegables de la parte derecha de la pantalla y hacer ‘click’ o drag & drop del mismo sobre el espacio de trabajo de creación de condiciones simples (caja central izquierda).

2. Aparecerá en el espacio de trabajo el operador seleccionado junto con un área para rellenar sus operandos. Los operandos pueden ser o bien atributos de la vista de entrada (presentes en el desplegable “Fields” de la parte izquierda de la pantalla) o valores ya creados (cuya lista se muestra en la caja superior derecha). Para asignar un atributo o un valor ya creado como operando de la condición, se hará una operación de drag & drop que lleve el elemento al área del parámetro. Al pulsar el botón ‘>’ que aparece al lado de la condición simple, ésta aparecerá en la lista de condiciones simples ya creadas (caja central derecha).

En nuestro ejemplo seleccionaremos el operador ‘>=’ asociado al tipo Float y haremos drag & drop del mismo sobre espacio de trabajo. Como operando izquierdo utilizaremos el atributo revenue. Como operando derecho utilizaremos el valor constante Float (1000) creado en la sección anterior. Ver Figura 25.

Figura 25 Creación de una condición simple

6.4.4.1.3 Creación de condiciones booleanas

Para crear una nueva condición booleana deben realizarse las siguientes acciones:

1. Seleccionar el operador booleano deseado (AND, OR o NOT) en los desplegables de la parte derecha de la pantalla y hacer ‘click’ o drag & drop del mismo sobre el espacio de trabajo de creación de condiciones booleanas (caja inferior izquierda).

2. Aparecerá en el espacio de trabajo el operador seleccionado junto con un área para especificar sus operandos. Los operandos pueden ser condiciones simples ya creadas (cuya lista se muestra en la caja central derecha) u otras condiciones booleanas creadas previamente. Para asignar una condición ya creada



como operando de la nueva condición booleana, se hará una operación de drag & drop que lleve la condición al área del operando. Al pulsar el botón ‘>’ que aparece al lado de la condición booleana, ésta aparecerá en la lista de condiciones booleanas ya creadas (caja inferior derecha).

Finalmente, se realizará una operación de drag & drop de la condición que se desee añadir a la selección a la caja “Selection Condition”. Al pulsar ‘ok’, se volverá a la página de creación de la vista selección, dónde la condición aparecerá ya creada. En nuestro ejemplo, no crearemos condiciones booleanas compuestas, por lo que podemos hacer drag&drop directamente desde la condición simple creada en la sección anterior hasta la caja “Selection Condition”.

6.4.4.1.4 Creación de condiciones que utilizan constantes de tipos compuestos

Denodo Virtual DataPort soporta el modelado de tipos de dato con estructura en árbol mediante el uso de los tipos register y array (ver Guía avanzada de VQL [VQL]). Es posible crear constantes de estos tipos compuestos y utilizarlas en las condiciones de selección. En esta sección se explicará cómo mediante un ejemplo.

Figura 26 Esquema de RevenueSum

En el ejemplo se utilizará una relación base llamada RevenueSum, cuyo esquema se muestra en la Figura 26. RevenueSum puede ser creada de la siguiente forma:

1. Utilizando el datasource para acceder al Servicio Web de ejemplo sales (ver sección 6.3.2), crear una relación base partiendo de la operación getSumRevenueByTaxIds. Esta operación recibe como entrada un array de cadenas de caracteres (cada una de ellas será el taxId de un cliente) y devuelve la suma de la facturación de todos los clientes especificados (valor de tipo float).



2. Llamaremos a la nueva relación base RevenueSum. También cambiaremos el nombre de sus atributos por, respectivamente, clients y totalrevenue. El atributo clients es de tipo ‘array de registros’ y representa el parámetro de entrada de la operación. Más concretamente DataPort genera de forma automática un tipo array llamado getsumrevenuebyids_in0. Cada elemento de este tipo array será de un tipo register, también generado automáticamente por DataPort, y llamado getsumrevenuebyids_in0_string. Los elementos de este último tipo tienen un único campo de tipo text al que cambiaremos el nombre por el de ‘taxId’.

Figura 27 Editor de valores de tipos compuestos

En este ejemplo se creará una vista selección utilizando una condición sobre RevenueSum para obtener el total obtenido sumando las facturaciones de los clientes con taxIds ‘B78596011’ y ‘B78596012’. Los pasos a efectuar son los siguientes:

1. Seleccionar la opción ‘Query Builder – Toolbox – Relational Operations – Selection’ y arrastrar RevenueSum sobre el área de trabajo para crear una nueva vista selección. Pulsar la opción ‘Set Condition’ para acceder al editor de condiciones de selección.

2. En el desplegable ‘Constants’ de la parte izquierda de la pantalla, aparecerán ahora, además de los tipos

de dato simples, el tipo de dato compuesto getSumRevenuebyTaxIds_IN0.



3. Hacer ‘drag & drop’ del tipo getSumRevenuebyTaxIds_IN0 sobre el área de creación de valores y pulsar en el botón ‘□’.

4. Se abrirá un nuevo panel emergente como el mostrado en la Figura 27 para crear una nueva constante del

tipo getSumRevenuebyTaxIds_IN0. Al tratarse de un tipo array, es posible crear varios elementos para el mismo. Para ello debe pulsarse el botón ‘+’ que aparece al lado de ‘Value’. En nuestro ejemplo, el array debe tener dos elementos así que se pulsará dos veces.

5. Es posible editar ahora los valores para cada uno de los elementos del array, que serán siempre de un tipo

register. Para ello basta hacer click sobre ellos y se desplegarán como puede verse en la Figura 28. Para cada campo del tipo register, existirá un área de texto en el que escribir el valor deseado. En el tipo de nuestro ejemplo hay un único campo llamado taxId. En el primer registro introduciremos el valor ‘B78596011’ y en el segundo el valor ‘B78596012’.

Figura 28 Creando un valor de tipo getSumRevenuebyTaxIds_IN0

6. Al pulsar ‘ok’, el panel se cerrará y el nuevo valor compuesto aparecerá en el área de creación. Pulsando el botón ‘ > ’ la nueva constante estará creada (su representación en VQL será {ROW(‘B78596011’),ROW(‘B78596012’)}). Véase la Guía Avanzada de VQL [VQL] para más información sobre los constructores ROW y {}.



7. La nueva constante puede ser ahora utilizada para crear la condición de consulta deseada sobre el campo clients. El proceso de creación de esta condición es el mismo que con constantes de tipos simples (ver sección 6.4.4.1.2). En esta ocasión tendremos que utilizar el operador ‘=’ correspondiente al tipo array. En la Figura 29 se muestra la condición ya creada en la caja ‘Selection Condition’ (su representación VQL será: clients={ROW(‘B78596011’),ROW(‘B78596012’)}. La Figura 30 muestra el resultado de ejecutar la vista selección resultante (véase la sección 6.4.9 para obtener información sobre cómo ejecutar vistas y navegar por los resultados obtenidos cuando estos son de tipo compuesto).

Figura 29 Condición con valores de tipos compuestos



Figura 30 Resultado de ejecutar la vista RevenueSum_Selection

6.4.5 Creación de vistas de tipo Agregación

Una vista de tipo Agregación permite realizar una operación de tipo GroupBy sobre una vista de entrada. Para definir una vista agregación es necesario desplegar el menú ‘Toolbox - Relational Operations’ y seleccionar la opción ‘Aggregation’. Para seleccionar la vista sobre la que se desea realizar la operación de agregación, se debe hacer drag&drop desde la lista de vistas y relaciones base que aparecen en la parte izquierda de la pantalla. En nuestro ejemplo, haremos drag & drop de la vista pref_clients_inc_sales. El esquema de la vista de entrada se muestra a la izquierda del área de trabajo mientras que el esquema de salida actual se muestra a la derecha. Al comienzo, dicho esquema de salida estará vacío. Es importante recordar que una vista de tipo agregación puede tener en su salida dos tipos de atributos:

• Atributos de groupBy. Atributos por los que se realiza la operación de agrupamiento. • Atributos resultado de la aplicación de una expresión de agregación. Las expresiones de agregación

involucran el uso de funciones de agregación como COUNT, MIN, AVG, etc. (véase la Guía Avanzada de VQL para consultar la lista completa y la descripción de las funciones de agregación).

Para especificar los atributos de groupBy basta arrastrarlos mediante una operación drag & drop sobre la lista de campos de agrupamiento (‘Group By Fields’) que aparece en la parte central-inferior de la pantalla. También es posible arrastrar un atributo de la vista de entrada directamente a la vista de salida. En ese caso el atributo pasa a considerarse un atributo de agrupación y además aparecerá en el esquema de la vista de salida (ver Figura 31). En nuestro ejemplo, los campos de agrupamiento serán taxId y revenue.



Figura 31 Creación de la vista de agregación inc_group_by_pref_clients

Para añadir atributos resultado de una expresión de agregación, utilizaremos el botón “New Aggregation Expresión”, que nos dará acceso al editor de expresiones de agregación. Una vez creada la expresión de agregación,se añadirá un atributo al esquema de la vista de salida, con el nombre y la expresión creadas utilizando el editor de expresiones de agregación. En nuestro ejemplo, añadiremos un atributo resultado de la expresión de agregación count(*) al que asignaremos el nombre num_incidences (ver Figura 32). El uso del editor de expresiones de agregación se describe en la sección 6.4.5.1.



Figura 32 Creación de vista agregación inc_group_by_pref_clients (2)

Sobre el esquema de la vista de salida es posible cambiar los nombres de los atributos, cambiar el nombre de la vista resultado (en nuestro ejemplo escogeremos inc_group_by_pref_clients) y eliminar los atributos que se desee. También es posible añadir nuevos atributos derivados a la vista resultante mediante el uso del botón ‘New Field’, que permite acceder al editor de expresiones de atributo derivado (ver sección 6.4.6.1). Por último, mediante el seleccionable ‘Target Project’ puede especificarse el proyecto al que desea asignarse la nueva vista. En nuestro ejemplo, seleccionaremos el proyecto ‘VDPExample’. Una vez que la vista de salida tiene ya la forma deseada, basta pulsar el botón ‘ok’ para crearla. Haciendo click sobre ella en la lista en la parte izquierda de la pantalla se accederá a su esquema..

6.4.5.1 Utilización del Editor de Expresiones de Agregación

El editor de expresiones de agregación (ver Figura 33) permite crear expresiones de agregación. La expresión puede escribirse directamente en VQL en la caja ‘Field Expression’ y el nombre del nuevo atributo en la caja ‘Field name’. Además, también puede crearse la expresión de forma totalmente gráfica. A continuación se describe este último proceso.



Figura 33 Editor de expresiones de agregación

En la parte izquierda de la pantalla encontramos menús para crear diversos valores que pueden aparecer como operandos en las expresiones:


• Funciones de agregación. Este menú permite crear una invocación a una de las funciones de agregación permitidas por Virtual DataPort. Las funciones pueden recibir como parámetros constantes, atributos o el resultado de evaluar otras funciones. Devuelven un único resultado. La lista de funciones disponibles y el uso de cada una de ellas puede consultarse en la Guía Avanzada de VQL [VQL].

• Atributos. Se corresponde con la lista de atributos de la vista sobre la que se aplica la agregación. Los atributos pueden actuar como parámetros de funciones. En la lista aparece también el valor ‘*’ que sirve para construir expresiones de agregación que se apliquen a todos los campos de la tupla (e.g. count (*) )

Las cajas centrales de la pantalla permiten la construcción de expresiones. La caja de la izquierda es un espacio de trabajo para la creación de nuevas expresiones mientras que la caja de la derecha muestra las expresiones ya creadas. Por último, la caja “Aggregation expression” contendrá la expresión finalmente creada. En esta caja puede incluirse también el nombre que se asociará en la vista de salida al atributo asociado a la expresión. Para crear una nueva expresión constante deben realizarse las siguientes acciones:

1. Seleccionar el tipo de dato de la constante en el desplegable ‘Constants’ de la parte izquierda de la pantalla y hacer ‘click’ o drag & drop sobre el espacio de trabajo de creación de expresiones (caja izquierda).



2. Aparecerá en el espacio de trabajo el tipo seleccionado, junto con un área de texto para rellenar el valor de la constante:




3. Al pulsar el botón ‘>’ la nueva constante aparecerá en la lista de valores creados (caja superior derecha). Para crear una nueva expresión de tipo función, deben realizarse las siguientes acciones:

1. Seleccionar la función deseada en el desplegable ‘Functions’ de la parte izquierda de la pantalla y hacer ‘click’ o drag & drop sobre el espacio de trabajo de creación de expresiones (caja izquierda).

2. Aparecerá en el espacio de trabajo la función seleccionada, junto con un área para rellenar el valor de los parámetros de la función. Los valores de los parámetros deben ser o bien expresiones presentes en la lista de valores creados (caja derecha) o bien atributos. Para asignar una expresión ya creada como parámetro de una función, se hará una operación de drag & drop que lleve la expresión creada al área del parámetro. Al pulsar el botón ‘>’ que aparece al lado de la función, ésta aparecerá en la lista de expresiones creadas (caja derecha).

En nuestro ejemplo, crearemos una nueva expresión de tipo función con la función count aplicada sobre el atributo especial * (ver Figura 34). Finalmente arrastraremos la expresión creada sobre la caja ‘Aggregation Expression’ y le asignaremos al nuevo atributo el nombre num_incidences.

Figura 34 Creación de una expresión de agregación



6.4.6 Creación de Vistas de tipo Proyección

Una vista de tipo Proyección permite eliminar o añadir atributos a una vista de entrada. Para definir una vista proyección es necesario desplegar el menú ‘Toolbox - Expresions Editor’ y seleccionar la opción ‘Projection’. Para seleccionar la vista sobre la que se desea realizar la operación de selección, se debe hacer drag&drop desde la lista de vistas y relaciones base que aparecen en la parte izquierda de la pantalla. Sobre el esquema de la vista de salida es posible cambiar los nombres de los atributos, cambiar el nombre de la vista resultado y también eliminar los atributos que no sean necesarios en la vista (esto supone una vista de tipo proyección de forma implícita). También es posible añadir nuevos atributos derivados a la vista resultante mediante el uso del botón ‘New Field’. Esto permitirá acceder al editor de expresiones de atributo derivado (ver sección 6.4.6.1). Es importante destacar que también es posible proyectar un atributo atómico que forme parte de un atributo compuesto (atributos de tipo Register). Esto puede hacerse o bien a través del editor de expresiones de atributo derivado o bien, de forma más rápida y sencilla, haciendo click con el botón derecho del ratón sobre el campo atómico deseado y escogiendo la opción ‘Project subfield’. Por último, mediante el seleccionable ‘Target Project’ puede especificarse el proyecto al que desea asignarse la nueva vista. En nuestro ejemplo, seleccionaremos el proyecto ‘VDPExample’. Una vez que la vista de salida tiene ya la forma deseada, basta pulsar el botón ‘ok’ para que sea creada. Haciendo click sobre la vista en la lista de la parte izquierda de la pantalla se accederá a su esquema.

6.4.6.1 Utilización del Editor de Expresiones de Atributo Derivado

El editor de expresiones de atributo derivado se muestra en la Figura 35. Es posible escribir la expresión deseada directamente en formato VQL en la caja ‘Field Expression’, utilizando la caja ‘Field Name’ para especificar el nombre del nuevo atributo asociado a la expresión.



Figura 35 Editor de expresiones de atributo derivado

También es posible crear la expresión deseada de forma totalmente gráfica. A continuación se describe este último proceso. En la parte izquierda de la pantalla encontramos menús para crear diversos valores que pueden aparecer como operandos en las expresiones:


• Funciones de atributo derivado. Este menú permite crear una invocación a una de las funciones de atributo derivado permitidas por Virtual DataPort. Las funciones pueden recibir como parámetros constantes, atributos o el resultado de evaluar otras funciones. Devuelven un único resultado. La lista de funciones disponibles y el uso de cada una de ellas puede consultarse en la Guía Avanzada de VQL [VQL].

• Atributos. Se corresponde con la lista de atributos de la vista sobre la que se aplica la proyección. Los atributos pueden actuar como parámetros de funciones.

Las cajas centrales de la pantalla permiten la construcción de expresiones. La caja de la izquierda es un espacio de trabajo para la creación de nuevas expresiones mientras que la caja de la derecha muestra las expresiones ya creadas. Por último, la caja “Field expression” contendrá la expresión finalmente creada. En esta caja puede incluirse también el nombre que se asociará en la vista de salida al atributo asociado a la expresión.



Para crear una nueva expresión constante deben realizarse las siguientes acciones:

1. Seleccionar el tipo de dato de la constante en el desplegable ‘Constants’ de la parte izquierda de la pantalla y hacer ‘click’ o drag & drop sobre el espacio de trabajo de creación de expresiones (caja izquierda).

2. Aparecerá en el espacio de trabajo el tipo seleccionado, junto con un área de texto para rellenar el valor de la constante:




3. Al pulsar el botón ‘>’ la nueva constante aparecerá en la lista de valores creados (caja superior derecha). Para crear una nueva expresión de tipo función, deben realizarse las siguientes acciones:

1. Seleccionar la función deseada en el desplegable ‘Functions’ de la parte izquierda de la pantalla y hacer ‘click’ o drag & drop sobre el espacio de trabajo de creación de expresiones (caja izquierda).

2. Aparecerá en el espacio de trabajo la función seleccionada, junto con un área para rellenar el valor de los parámetros de la función. Los valores de los parámetros deben ser o bien expresiones presentes en la lista de valores creados (caja derecha) o bien atributos. Para asignar una expresión ya creada como parámetro de una función, se hará una operación de drag & drop que lleve la expresión creada al área del parámetro. Al pulsar el botón ‘>’ que aparece al lado de la función, ésta aparecerá en la lista de expresiones creadas (caja derecha).

6.4.7 Aplanamiento de campos de tipo array de registros

Denodo Virtual DataPort soporta el modelado de tipos de dato con estructura en árbol mediante el uso de los tipos register y array (ver Guía avanzada de VQL [VQL]). En DataPort, un elemento de tipo array puede ser considerado como una sub-vista; de esta forma, un tipo array siempre tiene asociado un tipo register, que actua como el esquema de la sub-vista que está modelando. En ocasiones puede ser deseable “aplanar” un campo compuesto que contenga un array de registros. Esto es especialmente frecuente al tratar fuentes de tipo XML y Web services. Esta sección describe como hacerlo. Es importante notar que si desea “aplanar” directamente un registro (y no un array de registros), debe hacerlo utilizando la vista proyección (ver sección 6.4.6) en lugar del mecanismo aquí descrito. Supóngase la siguiente modificación en el ejemplo que hemos estado utilizando hasta ahora. Utilizaremos ahora la operación getAverageMonthlySales del web service sales. Esta operación no recibe ningún parámetro y, además, devolverá la información de taxId y revenue (ver Figura 36).



Figura 36 La operación getAverageMonthlyRevenue del Web Service sales

La relación base creada por defecto sobre esta nueva operación tendrá un único atributo de tipo array de registros y una única tupla dónde se encontrará toda la información devuelta por el servicio web (ver Figura 37). De cara a la combinación de la información con otras fuentes (por ejemplo, para la combinación con las tablas de incidencias de nuestro ejemplo) puede ser mucho más útil una vista que tenga dos atributos (taxId y revenue) y una tupla por cada cliente. Esto puede realizarse mediante una operación de “aplanamiento” sobre la vista original. A continuación se describe dicho proceso.



Figura 37 Vista base creada por defecto para getAverageMonthlyRevenue

Para realizar una operación de aplanamiento sobre una vista es necesario seleccionar en el menú de la parte izquierda la opción ‘Toolbox-Advanced operations-Flatten’. A continuación debe hacerse un drag & drop de la vista a aplanar sobre el área de trabajo. Al hacer esto, en la parte izquierda del área de trabajo aparece el esquema de la vista de entrada. En la parte derecha aparece el esquema de la vista de salida (inicialmente ambos esquemas serán iguales).



El siguiente paso consiste en situarse en la vista de entrada sobre el campo de tipo array que se desea aplanar, pulsar el botón derecho del ratón y seleccionar la opción ‘Flatten array’ (ver Figura 38).

Figura 38 Aplanando el array devuelto por average_revenue_array

La vista de salida mostrará entonces el esquema aplanado (ver Figura 39).



Figura 39 Esquema de salida de average_revenue_array aplanada

En cada operación de “aplanamiento” es posible seleccionar solamente un array. Si se desea aplanar más de uno es necesario realizar esta operación para cada uno de ellos. Como es habitual, es posible cambiar el nombre de la vista aplanada obtenida como resultado o de sus atributos. También es posible añadir nuevos atributos derivados a la vista resultado utilizando el botón ’New Field’. Finalmente, al pusar el botón ‘ok’ se crará la nueva vista obtenida como resultado de la operación de aplanamiento (ver Figura 40).



Figura 40 Esquema de la vista aplanada

6.4.8 Modo de visualización en forma de árbol

Utilizando el botón ‘Tree View’ de la pantalla que muestra el esquema de una vista, es posible acceder al modo de visualización de la vista en modo árbol (‘Tree View’). Este modo de visualización muestra de forma gráfica los sucesivos niveles de vistas que se han ido componiendo para definir la vista. Por ejemplo, la Figura 41 muestra el árbol de la vista incidences_sales. Haciendo click sobre cualquiera de las vistas del árbol, se accederá a la página que muestra su esquema. Haciendo click sobre los nodos del árbol que representan operaciones de combinación (joins, uniones, selecciones…) se visualizarán sus principales propiedades. Por ejemplo, en el caso de las operaciones de selección se mostrará la condición utilizada para crearla.



Figura 41 Vista en árbol de incidences_sales

6.4.9 Ejecución de vistas y uso de VQL Shell

El botón ‘Execute’ de la pantalla que muestra el esquema de una vista permite obtener las tuplas de la misma. Por defecto el sistema ejecutará una consulta ‘select * from viewname’ dónde viewname es el nombre de la vista. Sin embargo, la herramienta ofrece también la opción de acceder al editor de condiciones antes de la ejecución para crear una condición de selección sobre la vista (ver sección 6.3.4.1). La opción “Limit rows” permite limitar el número de tuplas devueltas por la ejecución de la consulta. En la Figura 42 se muestra el resultado de ejecutar la vista incidences_sales. El botón “View Execution Trace” permite acceder a la traza de ejecución de la consulta (ver sección 6.4.10). Si se ha utilizado la opción “Limit rows”, la traza no estará disponible.



Figura 42 Ejecutando la vista incidences_sales

Si la respuesta de la ejecución de la consulta contiene algún campo compuesto (registros o arrays de registros), deberá hacerse doble click sobre el campo para navegar por sus subcomponentes. Por ejemplo la Figura 43 muestra el resultado de ejecutar la vista base average_revenue_array (descrita en la sección 6.4.7). Esta vista devuelve como resultado una única tupla que contiene un campo de tipo array de registros. Cada registro contiene el taxId y las ventas mensuales medias de un cliente. Haciendo dobre click sobre el campo ‘[Array]’ se accede a su contenido (ver Figura 44). El botón ‘Back’ puede utilizarse en esta pantalla para volver al nivel superior.



Figura 43 Resultado compuesto por una única tupla con un campo de tipo array de registros

Figura 44 Viendo el contenido de un campo de tipo array de registros

A la hora de construir consultas sobre una vista, es conveniente tener presente que sus condiciones de consulta deben satisfacer las capacidades obligatorias de la vista (ver sección 6.6.3).

6.4.9.1 Uso de VQL Shell

La pestaña VQL_SHELL de la herramienta permite acceder a un intérprete de VQL que permite enviar sentencias y consultas escritas en dicho lenguaje contra el servidor. Es posible escribir una o más sentencias separadas por ‘;’. Las sentencias se ejecutarán al pulsar el botón ‘Execute’ o al pulsar la combinación de teclas CTRL+ENTER. La opción “Limit rows” permite limitar el número de tuplas devueltas por la ejecución de la consulta. El botón “Load” permite cargar un script VQL contenido en un fichero. El botón “View Execution Trace” permite ver la traza de ejecución de la última sentencia ejecutada (esta opción no estará disponible si se ha utilizado “Limit rows”). Este botón se habilita si la sentencia se ejecuta con la cláusula TRACE (ver sección 6.4.10). La consola incluye un “log de comandos” que guarda las últimas sentencias VQL ejecutadas. Existen dos formas para navegar por el log de comandos:

• Utilizando el seleccionable ‘Commands log’. Abriendo este seleccionable puede accederse a una lista de las últimas sentencias ejecutadas y es posible seleccionar una de ellas.

• Utilizando las teclas F1 (retroceso al comando anterior) y F2 (avance al comando siguiente). También es posible utilizar el desplegable de vistas y relaciones base de la parte izquierda para acelerar la escritura de las sentencias VQL:

• Haciendo click con el botón izquierdo del ratón sobre una vista aparecerá su nombre en la caja de texto utilizada para escribir la sentencia VQL.

• Haciendo click con el botón derecho aparecerá SELECT * FROM <nombre de vista> en la caja de texto.

• Haciendo click con el botón central aparecerá DESC VQL <nombre de vista> en la caja de texto.

6.4.10 Traza de Ejecución de una Sentencia

Tras la ejecución de una sentencia, ya sea a través de la VQL Shell o a través de la pantalla de ejecución de una vista, es posible acceder a una traza de la misma. La traza sólo estará disponible si no se ha utilizado la opción “Limit rows” en la ejecución. La traza de una sentencia permite un examen detallado de su plan de ejecución. Dicho plan es mostrado al administrador en la forma de un árbol, dónde cada nodo representa una vista intermedia involucrada en la ejecución de la consulta o un acceso a una fuente a través de un wrapper. Para cada nodo en el árbol de ejecución de la consulta, se muestran sus parámetros más relevantes. Entre estos parámetros se encuentran:

• Tipo de nodo. Si el nodo es una vista, indica el tipo de vista de que se trata (vista base, unión, join, proyección,…). Si se trata de un acceso a una fuente (wrapper), se indica el tipo de fuente (JDBC, Web Service, Web…).

• Tiempo de ejecución. Tiempo invertido en la ejecución completa del nodo y de todos sus hijos. • Momento de inicio. Momento exacto en el que se inicia el procesamiento del nodo en el plan de ejecución. • Momento de fin de la consulta. Momento exacto en el que se finaliza el procesamiento del nodo (y de

todos sus hijos) en el plan de ejecución. • Tiempo de obtención de primera tupla de resultados. Tiempo transcurrido hasta que el nodo recibió la

primera tupla a procesar.



• Número de tuplas procesadas. Número de tuplas procesadas por el nodo. • Status. Indica si el nodo se ejecutó correctamente o se produjo algún error. • Parámetros avanzados. Proporcionan más detalle sobre cada tipo de nodo. Por ejemplo:

o En el caso de nodos de tipo wrapper, se indican las subconsultas exactas ejecutadas sobre cada fuente de datos, así como los datos de conexión utilizados para acceder a cada una de ellas.

o Para cada nodo de tipo vista, se indica si se ha utilizado o no la cache, si ha sido necesario realizar swapping, si existen reglas de reescritura asociadas a la misma, etc. (para más información, se recomienda la lectura de la Guía Avanzada de VQL [VQL]).

A modo de ejemplo, la Figura 45 muestra parte de la traza gráfica de la ejecución de la vista incidences (creada en la sección 6.4.1). Una de las principales utilidades de la funcionalidad de traza es la depuración en el caso de que se produzcan condiciones de error. En este caso, los nodos que han provocado algún error durante la ejecución aparecerán marcados en rojo. Haciendo ‘click’ sobre los nodos que provocaron el error, podrá accederse a la causa exacta del mismo.

Figura 45 Traza de ejecución de la vista incidences

Por ejemplo, la Figura 46 muestra la traza de ejecución de una vista join cuando una de las fuentes de datos está caída. Más concretamente, la traza se corresponde con una vista join sobre la vista incidences (creada en la sección 6.4.1) y la vista flat_revenue (creada en la sección 6.4.7), cuando el Servicio Web del que procede flat_revenue está caído..



Figura 46 Traza de ejecución con errores de una vista join

6.4.11 Sustitución de la Definición de Una Vista

En ocasiones es necesario modificar una vista de DataPort. Las razones son diversas: por cambios en las fuentes que exigen la actualización de la vista ya existente, o porque el administrador del sistema se ve obligado a intercambiar una fuente por otra (p.e. porque los datos han sido migrados a otro sistema, o debido a que se ha decidido pasar a un repositorio redundante). En estos casos, es necesario poder modificar fácilmente la vista afectada sin que haya que regenerar todo el sistema de vistas derivadas que utilizan la vista modificada. DataPort permite realizar esta operación de una manera muy sencilla; sólo es necesario crear la nueva vista y darle el mismo nombre que la vista que se desea. Tras solicitar confirmación al usuario (ver Figura 47), DataPort eliminará la vista anterior y actualizará las vistas derivadas afectadas por el cambio (se recalculan esquemas y capacidades de consulta, y se borran los elementos que ya no sean necesarios ; en el caso de un cambio de vista base, sobre un tipo de fuente distinto, el viejo wrapper se borra si ya no es utilizado por ninguna otra vista). En caso de que debido al cambio de vista las capacidades de consulta (ver sección 6.6.5) de alguna de las vistas derivadas se hayan alterado (p.e. debido a la adición de algún campo adicional, o a alguna restricción de consulta no existente anteriormente), DataPort actualizará las capacidades y restricciones de consulta de las vistas derivadas siempre que sea posible. Si los cambios introducidos presentaran incoherencias con respecto a las vistas derivadas (p.e. al actualizar una vista que participaba en una operación de “join” en la que alguno de los atributos de join

desaparecen), éstas aparecerán en la interfaz gráfica con el símbolo a la izquierda del nombre.



Figura 47 Confirmación de la sustitución de una vista

6.5 OTROS TIPOS DE FUENTES

En esta sección se describe el proceso de importación de fuentes de datos de tipo ODBC, XML, Web, Ficheros delimitados, Aracne, Google Mini y CUSTOM, así como el proceso de creación de relaciones base para las mismas. También se detalla un caso especial en la creación de relaciones base de fuentes de datos de tipo JDBC/ODBC: la creación de una relación base utilizando una consulta SQL “patrón”. Por último, en la sección 6.5.11 se describe cómo configurar las propiedades de configuración de una fuente de datos. Durante el proceso de añadir fuentes de tipo XML y ficheros delimitados, es necesario especificar rutas a diversos documentos. Los formatos de ruta disponibles en Virtual DataPort se describen en la sección 6.5.1. El resto de subapartados se ocupan, respectivamente, de la importación de cada uno de los tipos de fuentes mencionados.

6.5.1 Tipos de rutas en Virtual DataPort

Durante el proceso de añadir fuentes de tipo XML y ficheros delimitados, es necesario especificar rutas a ficheros de datos. Denodo Virtual DataPort soporta diversos tipos de rutas para acceder a estos documentos. En la pantalla de importación de la fuente, para cada documento que sea necesario especificar, es necesario escoger uno de los tipos de ruta disponibles y pulsar el botón ‘Edit’ para configurarla. A continuación se describen los tipos de ruta disponibles:

• Ruta local. Permite indicar un fichero disponible en el sistema de ficheros local.



• Ruta http Client. Permite acceder al fichero a través de una petición http. Es necesario especificar el método de conexión http utilizado (GET/POST) y la url a invocar.

• Ruta NSEQL. Permite utilizar una secuencia de navegación NSEQL [NSEQL] para acceder al fichero. Requiere que Denodo ITPilot [ITPILOT] esté instalado en la misma ruta que el servidor DataPort.

• Ruta FTP. Permite acceder a un fichero disponible en un servidor FTP. Los parámetros necesarios para configurar esta ruta son la url al servidor y el identificador de usuario y contraseña a utilizar.

6.5.1.1 Rutas con variables de interpolación

Las rutas de acceso a los ficheros de datos de fuentes XML y de ficheros delimitados pueden ser parametrizadas en función de la consulta efectuada utilizando variables de interpolación (ver ‘Contexto de Ejecución de una Consulta y Cadenas de Interpolación’ en Guía Avanzada de VQL [VQL]). Si la ruta especificada incluye variables de interpolación, entonces durante el proceso de creación de relaciones base será necesario un paso intermedio (ver Figura 48) en el que DataPort solicitará valores válidos para las mismas. Esto es necesario para que DataPort pueda acceder a un fichero de datos y obtener la metainformación necesaria para la creación de la relación base.

Figura 48 Proporcionando valores para las variables de interpolación

Cada variable de interpolación debe estar asociada a un atributo de la relación base generada (ver Guía Avanzada de VQL [VQL] para más detalle). Si el fichero de datos especificado incluye algún campo con el mismo nombre que la variable, entonces la variable se asociará al atributo de la relación base correspondiente a dicho campo. En caso de que la consulta SQL especificada no devuelva ningún campo con el mismo nombre que la variable, DataPort añadirá un nuevo atributo a la relación base con el nombre de la variable. NOTA: Cuando se utilizan variables de interpolación en la ruta, el carácter “\” actua como carácter de escape para los caracteres especiales utilizados para indicar nombres de variables (‘@’, ‘{‘, ‘}’). En sistemas Windows este mismo carácter se utiliza para especificar rutas a ficheros lo cuál puede causar ciertas situaciones de ambigüedad.



c

Por ejemplo el sistema interpretará que la ruta “c:\tmp\@{var}” apunta a un fichero llamado ‘tmp@{var}’ en el directorio ‘c:\’ ya que la segunda aparición de ‘\’ se considera como carácter de escape al ir inmediatamente seguido de ‘@’. Sin embargo la ruta “c:\tmp\\@{var}” apuntaría a un fichero cuyo nombre se corresponderá con el valor de la variable var y que se encuentra en “c:\tmp”.

6.5.2 Fuentes ODBC

DataPort permite acceder a fuentes ODBC mediante la utilización de un puente JDBC-ODBC. El proceso para crear una nueva fuente de datos de tipo ODBC se inicia accediendo a la pestaña ‘Data Sources – Projects – ProjectName- Relational DB – ODBC’ y haciendo click en la opción ‘New’ (Proje tName representa el nombre del proyecto al que deseamos añadir la nueva fuente). Se accederá entonces a la pantalla de creación de una nueva fuente ODBC (ver Figura 49). En esta pantalla se solicitan los siguientes datos:

• Nombre con el que se denominará a la fuente de datos (Data Source) dentro de Virtual DataPort. • Adaptador de base de datos. En este seleccionable es posible escoger uno de los gestores de bases de

datos para los que DataPort incluye un adaptador para acceso ODBC. También se incluye un adaptador “Generic” que puede utilizarse con los gestores ODBC para los que no existe un adaptador específico. Los adaptadores específicos permiten diversas optimizaciones en el acceso a cada gestor, por lo que es preferible utilizarlos cuando sea posible. Si se marca la opción “Choose automatically” (recomendado), DataPort escogerá automáticamente el adaptador a utilizar mediante una conexión de prueba a la base de datos.

• DSN (Data Source Name). Nombre del origen de datos ODBC que se utilizará. • Login de usuario para acceso a la base de datos externa. • Contraseña del usuario para el acceso a la base de datos externa. • Si se marca la opción ‘Choose automatically’ (recomendado), el sistema se conectará a la base de datos

para obtener automáticamente el adaptador más adecuado. Si se marca esta opción, se selecciona también automáticamente la opción “Test Connection”.

• Finalmente, si se marca la opción ‘Test Connection’, el sistema efectuará una conexión de prueba a la fuente. Esto permite comprobar que la base de datos está accesible para el servidor DataPort.

Opcionalmente, puede accederse también a la opción “Connections Pool Configuration” para configurar diversos parámetros del pool de conexiones que Virtual DataPort utilizará para optimizar el acceso a la base de datos externa. Los parámetros disponibles son los mismos que para el caso de fuentes JDBC (ver sección 6.3.1).



Figura 49 Importación de una fuente de datos ODBC

También es posible utilizar la opción ‘DSN Properties Configuration’ para añadir propiedades (pares campo-valor) que se añadirán a la URI de conexión. Una vez importada la fuente ODBC, el proceso de creación de relaciones base es igual al de JDBC (ver sección 6.3.3).

6.5.3 Fuentes XML

Para crear una nueva fuente de datos (DataSource) representando a un documento XML es necesario acceder a la pestaña “Data Sources” y, tras seleccionar el proyecto al que deseamos añadir la nueva fuente, hacer click en la opción ‘New’ que aparece al lado de la lista actual de fuentes XML. Se accederá entonces a la pantalla de creación de una nueva fuente de datos XML (ver Figura 50). En esta pantalla se solicitarán los siguientes datos: • Nombre con el que se denominará a la fuente de datos dentro de Virtual DataPort. • Ruta al fichero XML que contiene los datos deseados. Esta ruta puede ser parametrizada en función de la

consulta efectuada utilizando variables de interpolación (ver sección 6.5.1.1). • Ruta al fichero conteniendo la especificación del esquema del documento XML (opcional). El esquema puede

estar descrito utilizando la especificación DTD o la especificación XML Schema. Si no se especifica (marcando la opción‘None’), Virtual DataPort tratará de inferir un esquema adecuado analizando la estructura del documento XML que contiene los datos.

Los formatos de ruta disponibles se detallan en la sección 6.5.1.



Figura 50 Importación de una fuente de datos XML

Al pulsar ok, se creará la nueva fuente de datos y se accederá a la pantalla de descripción de la fuente XML (ver Figura 51). Al pulsar el botón ‘Create Base View’ se mostrará automáticamente el esquema de una relación base asociada a la fuente (excepto si la ruta al fichero de datos incluyese variables de interpolación, en cuyo caso habrá un paso intermedio; ver sección 6.5.1.1). Es posible modificar en este momento el nombre de la relación base, y el nombre y tipo de cada uno de los atributos que la componen. Mediante el seleccionable ‘Target Project’ puede también especificarse el proyecto al que desea asignarse la nueva vista. Una vez aceptado su esquema, la nueva relación base podrá verse en la parte izquierda de la pantalla colgando de la fuente XML utilizada.



Figura 51 Descripción de una fuente XML

Haciendo click en una relación base que hayamos creado, podremos acceder a la página que muestra su esquema dentro de Virtual DataPort. Una vez creada la relación base, si se desea modificar su esquema para eliminar atributos o cambiar el nombre de los mismos debe utilizarse una vista proyección sobre la misma (ver sección 6.4.6). Pulsando el botón ‘Edit’ se accede directamente a la pantalla de creación de una vista proyección sobre la relación base.

6.5.4 Fuentes Web

Las fuentes de datos web permiten utilizar los wrappers web creados a través de Denodo ITPilot [ITPILOT]. Sólo es posible importar y utilizar este tipo de fuentes en el caso de que Denodo ITPilot esté instalado en la misma ruta que el servidor DataPort. Para crear una nueva fuente de datos de este tipo es necesario acceder a la pestaña “Data Sources” y, tras seleccionar el proyecto al que deseamos añadir la nueva fuente, hacer click en la opción ‘New’ que aparece al lado de la lista actual de fuentes ITPilot. Se accederá entonces a la pantalla de creación (ver Figura 52). En esta pantalla se solicita un fichero conteniendo las sentencias VQL de creación del wrapper. Este fichero es generado directamente por el entorno de generación de Denodo ITPilot.



Figura 52 Importación de un wrapper HTML creado con ITPilot

Al pulsar ok, se añadirá la nueva fuente web. Haciendo click sobre él se accederá a una pantalla desde la cuál es posible crear una relación base a partir de la misma. En esta pantalla es posible modificar el nombre de la relación base y el tipo de cada uno de los atributos que la componen. Mediante el seleccionable ‘Target Project’ también puede especificarse el proyecto al que desea asignarse la nueva vista. Una vez aceptado su esquema, la nueva relación base podrá verse en la parte izquierda de la pantalla colgando de la fuente web utilizada. Haciendo click en una relación base que hayamos creado, podremos acceder a la página que muestra su esquema dentro de Virtual DataPort. Una vez creada la relación base, si se desea modificar su esquema para eliminar atributos o cambiar el nombre de los mismos debe utilizarse una vista proyección sobre la misma (ver sección 6.4.6). Pulsando el botón ‘Edit’ se accede directamente a la pantalla de creación de una vista proyección sobre la relación base.

6.5.5 Fuentes de ficheros delimitados

Este tipo de fuente permite que Denodo Virtual DataPort pueda acceder a los datos contenidos en ficheros planos en formato CSV (Comma Separated Values) o similar.



Figura 53 Importación de una nueva fuente de ficheros delimitados

Para crear una nueva fuente de datos de este tipo es necesario acceder a la pestaña “Data Sources” y, tras seleccionar el proyecto al que deseamos añadir la nueva fuente, hacer click en la opción ‘New’ que aparece al lado de la lista actual de fuentes de este tipo. Se accederá entonces a la pantalla de creación de una nueva fuente de datosde tipo de ficheros delimitados (ver Figura 53). En esta pantalla se solicitarán los siguientes datos: • Nombre con el que se denominará a la fuente de datos dentro de Virtual DataPort. • Ruta al fichero que contiene los datos deseados. Los formatos de ruta disponibles se detallan en la sección

6.5.1. La ruta puede ser parametrizadas en función de la consulta efectuada utilizando variables de interpolación (ver sección 6.5.1.1).

• Delimitador de columna. Indica la cadena de caracteres que se utilizará como separador entre campos de una misma tupla.

• Delimitador de fin de tupla. Indica la cadena de caracteres que se utilizará como marca de fin de una tupla. Por defecto se utilizará la cadena ‘\n’ que identifica a un retorno de carro.

• Delimitador de inicio de la zona de datos: Expresión regular (en formato JAVA) que identifica el lugar del fichero delimitado dónde se comenzará a buscar tuplas. Si no se especifica se asume como valor el comienzo del fichero.

• Incluir delimitador de comienzo como parte de la zona de datos. Si se marca esta opción, el texto que encaje con la expresión regular de inicio se considerará como parte del espacio de búsqueda de tuplas (y de su cabecera).

• Delimitador de fin de la zona de datos: Expresión regular (en formato JAVA) que identifica el lugar del fichero delimitado hasta el que se buscarán tuplas. Si no se especifica se asume como valor el fin del fichero.

• Incluir delimitador de fin como parte de la zona de datos. Si se marca esta opción, el texto que encaje con la expresión regular de fin se considerará como parte del espacio de búsqueda de tuplas.

• Header. Esta casilla de verificación indica si la primera línea con datos del fichero contiene o no los nombres de los campos. Si es así, dichos nombres se utilizarán para crear los atributos de la relación base en DataPort.



Al pulsar ok, se creará la nueva fuente de datos y se accederá a la pantalla de descripción de la fuente de ficheros delimitados (ver Figura 54). Al pulsar ‘Create Base View’ se creará automáticamente el esquema de una relación base asociada a la fuente (excepto si la ruta al fichero de datos incluyese variables de interpolación, en cuyo caso habrá un paso intermedio; ver sección 6.5.1.1). Es posible modificar en este momento el nombre de la relación base, y el nombre y tipo de cada uno de los atributos que la componen. Mediante el seleccionable ‘Target Project’ puede especificarse el proyecto al que desea asignarse la nueva vista. Una vez aceptado su esquema, la nueva relación base podrá verse en la parte izquierda de la pantalla.

Figura 54 Descripción de una fuente de tipo ficheros delimitados

Haciendo click en una relación base que hayamos creado, podremos acceder a la página que muestra su esquema dentro de Virtual DataPort. Una vez creada la relación base, si se desea modificar su esquema para eliminar atributos o cambiar el nombre de los mismos debe utilizarse una vista proyección sobre la misma (ver sección 6.4.6). Pulsando el botón ‘Edit’ se accede directamente a la pantalla de creación de una vista proyección sobre la relación base.

6.5.6 Fuentes Google Mini

Denodo Virtual DataPort permite utilizar como fuente buscadores web construidos utilizando el software Google Mini [GMINI]. Para crear una nueva fuente de datos (DataSource) representando a un buscador Google Mini es necesario acceder a la pestaña “Data Sources” y, tras seleccionar el proyecto al que deseamos añadir la nueva fuente, hacer click en la opción ‘New’ que aparece al lado de la lista actual de fuentes Google Mini. Se accederá entonces a la pantalla de creación de una nueva fuente de datos de este tipo (ver Figura 55). En esta pantalla se solicitarán los siguientes datos: • Nombre con el que se denominará a la fuente de datos dentro de Virtual DataPort.



• Nombre de la máquina en la que está accesible el buscador. Puede ser una máquina remota accesible en Internet (e.g. ‘search.acme.com’).

• Puerto en el que se ejecuta el servicio Google Mini. En muchas ocasiones, este puerto es el 80.

Figura 55 Importación de una nueva fuente de tipo Google Mini

Al pulsar ok, se creará la nueva fuente de datos y se accederá a la pantalla de descripción de la fuente Google Mini (ver Figura 56), dónde se muestran los campos disponibles en el buscador. Estos campos son fijos para todos los buscadores Google Mini.



Figura 56 Descripción de la fuente Google Mini

Al pulsar ‘Create Base View’ se creará automáticamente el esquema de una relación base asociada a la fuente (ver Figura 57).



Figura 57 Pantalla de creación de vista base en fuentes Google Mini

En la parte superior de la pantalla, es posible especificar un valor para los siguientes parámetros: • Site Collections. Este parámetro es obligatorio. Especifica, dentro del servidor GoogleMini,,

sobre qué colecciones buscar. Las colecciones son creadas por el administrador del servidor Google Mini. Su nombre es sensible a mayúsculas/minúsculas. Es posible especificar varias colecciones separadas por comas. En ese caso, se buscará en todas ellas. Si se está accediendo a un servidor externo, la colección a buscar puede obtenerse normalmente examinando el valor del parámetro site en las invocaciones al mismo.

• Client: Este parámetro es opcional. Identifica al cliente que realiza las consultas. El servidor Google Mini puede estar configurado para comportarse de forma diferente en función del cliente que emita una consulta.

• Languages: Este parámetro es opcional. Si se especifica, se devolverán sólo documentos en el lenguaje especificado. El lenguaje debe ser un valor de los enumerados en la documentación de Google Mini [GSEARCHLANG].

• Number of Key Match: Este parámetro es opcional. Google Mini permite al administrador determinar manualmente la prioridad de las páginas a la hora de mostrarse en los resultados de una búsqueda. Este parámetro recibe un valor entero entre 0 y 5, dónde 5 siginifica la máxima prioridad. Si se establece este valor, las búsquedas sobre esta relación base sólo devolverán las páginas cuya prioridad sea la especificada o superior. .

El valor de estos parámetros puede modificarse posteriormente en la pantalla de configuración avanzada de la vista base creada (ver sección 6.6.7).



En la pantalla de creación de la vista base, también es posible modificar el nombre de la relación base, el nombre y tipo de cada uno de los atributos que la componen, así como eliminar los atributos no deseados. El contenido de cada uno de los atributos es el siguiente: • TITLE. Título generado por Google Mini para el documento. • SUMMARY. Resumen generado por Google Mini para el documento. • URL. URL del documento. • MIMETYPE. Tipo MIME del documento. • RATING. Prioridad asignada por el administrador de Google Mini para el documento. Puede tomar valores entre

0 y 5, donde 5 significa máxima prioridad. • MAXDOCS. Atributo añadido por DataPort que permite restringir el número máximo de resultados devueltos por

una búsqueda. • METAS. Atributo compuesto de tipo array de registros (ver Guía Avanzada de VQL [VQL]) que contiene los tags

meta del documento. Cada registro tiene dos campos, que indican el nombre del metatag (metakey) y su valor (metavalue).

• CONTENT. Contenido del documento. Es el campo utilizado habitualmente para las búsquedas. • SITE. Permite restringir los documentos devueltos a aquellos que pertenezcan a un dominio determinado (e.g.

‘acme.com’). • FILETYPE. Extensión del fichero del documento. Mediante el seleccionable ‘Target Project’ puede especificarse el proyecto al que desea asignarse la nueva vista. Una vez aceptado su esquema, la nueva relación base podrá verse en la parte izquierda de la pantalla. La forma más habitual de consultar las relaciones base construidas partiendo de fuentes Google Mini es mediante el uso del operador CONTAINS, que permite ejecutar búsquedas booleanas complejas sobre información textual indexada (ver Guía Avanzada de VQL [VQL]).

6.5.7 Fuentes Aracne

Denodo Virtual DataPort permite utilizar como fuente índices construidos utilizando Denodo Aracne 4.0 o superior [ARCN]. Para crear una nueva fuente de datos (DataSource) representando a un índice Aracne, es necesario acceder a la pestaña “Data Sources” y, tras seleccionar el proyecto al que deseamos añadir la nueva fuente, hacer click en la opción ‘New’ que aparece al lado de la lista actual de fuentes Aracne. Se accederá entonces a la pantalla de creación de una nueva fuente de datos Aracne (ver Figura 58). En esta pantalla se solicitarán los siguientes datos: • Nombre con el que se denominará a la fuente de datos dentro de Virtual DataPort. • Nombre de la máquina en la que está accesible el buscador. • Puerto en el que se ejecuta el servidor de búsqueda de Denodo Aracne. En la instalación por defecto de Aracne,

este puerto es el 4000.



Figura 58 Pantalla de creación de una fuente de datos Aracne

Al pulsar ok, se creará la nueva fuente de datos y se accederá a la pantalla de descripción de la fuente Aracne (ver Figura 59). Para cada índice contenido en el servidor Aracne, se muestran los campos disponibles en el mismo.



Figura 59 Descripción de la fuente Aracne

Al pulsar ‘Create Base View’ sobre alguno de los índices, se creará automáticamente el esquema de una relación base asociada al índice seleccionado (ver Figura 60). Es posible en este momento modificar el nombre de la relación base, el nombre y tipo de cada uno de los atributos que la componen, así como eliminar los atributos no deseados. Todas las vistas base pregeneradas partiendo de índices Aracne tienen una serie de atributos fijos, aunque pueden incluir también atributos específicos si los índices de partida los tienen. A continuación se describen los atributos fijos (véase la Guía del Administrador de Aracne [ARCN] para más detalle): • TASK. Nombre de la tarea Aracne que obtuvo e indexó este documento. • PUBDATE. Fecha de publicación del documento. Sólo aparece en el caso de que el índice contenga documentos

de tipo RSS • TITLE. Título generado por Aracne para el documento. • ANCHORTEXT. Si se trata de un documento que Aracne obtuvo mediante un proceso de crawling web, contiene

el texto del enlace utilizado para acceder al documento. • SUMMARY. Resumen generado por Aracne para el documento. • URL. En el caso de documentos obtenidos a través de la web, contiene la URL original del documento. En el caso

de documentos RSS se corresponde con el valor del campo link del item RSS. En el caso de documentos obtenidos de un sistema de ficheros local, contiene la ruta al mismo. En el caso de documentos obtenidos a partir de un servidor de correo electrónico contiene el nombre del servidor de correo y el nombre de la cuenta a la que pertenece el correo.

• IDENTIFIER. URL normalizada. • CONTENT. Contenido “útil” del documento generado por Aracne. Véase la Guía del Administrador de Aracne

[ARCN] para más detalle. • DESCRIPTION. Sólo aparece en el caso de que el índice contenga documentos de tipo RSS. En ese caso toma el

valor del elemento DESCRIPTION del documento RSS. • MODIFIED. Fecha de última modificación del documento en el índice.



• SEARCHABLECONTENT. Atributo añadido por DataPort que representa la concatenación del contenido de los principales campos fijos textuales del índice (título, resumen, contenido, anchortext,…), así como de los campos específicos que el índice pueda contener. Es el campo sobre el que se suelen realizar las búsquedas.

• LEVEL Nivel de profundidad de crawling en el que se obtuvo el documento. • TYPE. Tipo de contenido: html, pdf, rss, etc. • TITLEXML. Título del documento en XML con información sobre la estructura visual del contenido (párrafos).

Este campo se utiliza para la representación visual del título, no para búsquedas. Véase la Guía del Administrador de Aracne [ARCN] para una descripción del formato utilizado.

• SUMMARYXML. Resumen del documento en XML que informan sobre la estructura visual del contenido (párrafos). Este campo se utiliza para la representación visual del resumen, no para búsquedas. Véase la Guía del Administrador de Aracne [ARCN] para una descripción del formato utilizado.

• PATH. En el caso de que el servidor Aracne guarde una copia local al documento, contiene la ruta al mismo. • SCORE. Indicación de la relevancia relativa del documento para la consulta. Habitualmente los resultados de

una búsqueda se devuelven ordenados decrecientemente por SCORE. • MAXDOCS. Atributo añadido por DataPort que permite restringir el número máximo de resultados devueltos por

una búsqueda. • CATEGORIES. Sólo puede aparecer en el caso de que el índice contenga documentos de tipo RSS que

contengan un elemento CATEGORIES. En ese caso toma el valor de dicho elemento del documento RSS.

Figura 60 Pantalla de creación de vistas base en fuentes Aracne

Al lado de cada atributo de la vista base propuesta se muestra la opción “Create Main Terms”. El uso de esta opción se describe en la subsección 6.5.7.1.



Mediante el seleccionable ‘Target Project’ que aparece debajo del esquema de la vista, puede especificarse el proyecto al que desea asignarse la nueva vista. Una vez aceptado su esquema, la nueva relación base podrá verse en la parte izquierda de la pantalla. La forma más habitual de consultar las relaciones base construidas partiendo de fuentes Aracne es mediante el uso del operador CONTAINS, que permite ejecutar complejas búsquedas booleanas sobre información textual indexada (ver (ver Guía Avanzada de VQL [VQL])).

6.5.7.1 Accediendo a los términos más relevantes de un documento

Denodo Aracne es capaz de generar automáticamente las palabras más relevantes de un documento o de un campo del mismo, de acuerdo a la medida de relevancia TFIDF (Term Frequency Inverse Document Frequency). Estos términos pueden ser accedidos a través de DataPort tal y cómo se describe en esta sección. Los términos más relevantes se acceden como nuevos atributos en la vista base DataPort. Para crear un nuevo atributo en la vista base que contenga los términos más relevantes del valor de un campo determinado del documento, es necesario pulsar la opción ‘Create main terms’ que aparece al lado del campo deseado. Por ejemplo, si se desea añadir un nuevo atributo que contenga los términos más relevantes del campo del índice SEARCHABLECONTENT, debe pulsarse en la opción ‘Create main terms’ que aparece a su lado. La Figura 61 muestra este nuevo atributo (llamado SEARCHABLECONTENT_MAIN_TERM).

Figura 61 Añadiendo un atributo con los términos más relevantes del campo SEARCHABLECONTENT



El nuevo atributo SEARCHABLECONTENT_MAIN_TERM será un atributo compuesto de tipo array de registros (ver Guía Avanzada de VQL [VQL]). Cada registro tiene dos campos: • El término relevante. Este campo, por defecto, toma el nombre del campo del índice añadiéndole el sufijo

_TERM (en nuestro caso, por tanto, el nombre será SEARCHABLECONTENT_TERM). Sin embargo, como se ve en la figura, el nombre del campo puede ser cambiado

• Su posición en la lista de más relevantes. Este campo, por defecto, toma el nombre del campo del índice añadiéndole el sufijo _SCORE (en nuestro caso, por tanto, el nombre será SEARCHABLECONTENT_SCORE). Sin embargo, como se ve en la figura, el nombre del campo puede ser cambiado. El término más relevante toma la posición 1.

En el proceso de creación del nuevo atributo, es posible especificar dos parámetros: • Number of main terms. Número máximo de términos relevantes que se incluirán para cada documento. • Filter main terms words. Lista de “palabras usuales” (separadas por comas) que no deben aparecer entre los

términos más relevantes de este campo. Si Aracne generase entre los términos más relevantes del contenido del atributo alguno que apareciese en dicha lista, sería eliminado de la lista de términos relevantes. Es importante darse cuenta de que aquí es necesario especificar solamente palabras usuales específicas de la aplicación. Las palabras usuales del lenguaje utilizado tales como artículos, pronombres, etc. (comúnmente llamadas “stopwords”) son ya eliminadas por Denodo Aracne. La lista de palabras usuales puede estar contenida en un fichero. El fichero especificado debe ser un fichero de texto dónde las palabras aparezcan separadas por comas.

Además, en la parte inferior de la pantalla de creación la vista base, se encuentra el parámetro ‘General Words to Filter Main Terms’, que permite indicar una lista de palabras usuales comunes a todos los campos de la vista base. Nuevamente, no es necesario preocuparse de especificar palabras usuales del lenguaje utilizado tales como artículos, pronombres, etc. (comúnmente llamadas “stopwords”), debido a que son ya eliminadas por Denodo Aracne. El valor de estos parámetros puede modificarse posteriormente en la pantalla de configuración avanzada de la vista base creada (ver sección 6.6.7).

6.5.8 Fuentes LDAP

Las fuentes de datos de tipo LDAP permiten dar de alta un servidor LDAP en DataPort. La autenticación de un usuario de DataPort puede ser delegada a cualquiera de los servidores LDAP dados de alta (ver sección 8.3.3 para más detalles sobre la creación de usuarios en DataPort). Para crear una nueva fuente de datos de este tipo es necesario acceder a la pestaña “Data Sources” y, tras seleccionar el proyecto al que deseamos añadir la nueva fuente, hacer click en la opción ‘New’ que aparece al lado de la lista actual de fuentes LDAP. Se accederá entonces a la pantalla de creación (ver Figura 62). En esta pantalla se solicitarán los siguientes datos: • Nombre con el que se denominará a la fuente de datos dentro de Virtual DataPort. • Ruta al servidor LDAP. Por ejemplo: ldap://acmehost:389, donde acmehost es el nombre de la

máquina en la que reside el servidor y, en este caso, este se ejecuta en el puerto 389.



Figura 62 Creación de un datasource LDAP

Una vez pulsado, ‘ok’, se accederá a la pantalla que muestra las propiedades del nuevo datasource (ver Figura 63).

Figura 63 Propiedades del datasource LDAP



Una vez creado el nuevo datasource, estará ya disponible para la creación de nuevos usuarios (ver sección 8.3.3).

6.5.9 Fuentes CUSTOM

Las fuentes de datos de tipo CUSTOM (también llamadas de tipo MY) permiten incluir en Denodo DataPort wrappers “ad-hoc” creados específicamente para acceder a una fuente propietaria determinada. Véase la Guía Avanzada de VQL [VQL] para saber cómo desarrollar wrappers CUSTOM. DataPort incluye una serie de wrappers CUSTOM de ejemplo en la ruta $DENODO_HOME/samples/vdp/wrappersCustom. El fichero README en dicha ruta contiene instrucciones sobre cómo compilarlos, instalarlos y utilizarlos. Las pantallas que se muestran en esta sección utilizan como ejemplo los datos del wrapper CUSTOM de ejemplo com.denodo.vdp.demo.wrapper.custom.MetaPayRollWrapper.

Figura 64 Importación de un wrapper CUSTOM

Para crear una nueva fuente de datos de este tipo es necesario acceder a la pestaña “Data Sources” y, tras seleccionar el proyecto al que deseamos añadir la nueva fuente, hacer click en la opción ‘New’ que aparece al lado de la lista actual de fuentes de este tipo. Se accederá entonces a la pantalla de creación de una nueva fuente de datos CUSTOM (ver Figura 64). En esta pantalla se solicitarán los siguientes datos: • Nombre con el que se denominará a la fuente de datos dentro de Virtual DataPort. • Nombre completo de la clase que implementa el wrapper de tipo CUSTOM. Dicha clase debe encontrarse en el

classpath de la aplicación. Para ello puede incluirse la clase a partir de la ruta DENODO_HOME/extensions/dev/target/classes. También es posible colocar la clase en cualquier otra ruta siempre que esta esté incluida en el valor de la variable de entorno $DENODO_EXTERNAL_CLASSPATH.

• Classpath. Si se desea, es posible especificar un Classpath adicional a utilizar por la implementación de la fuente de datos CUSTOM.



Si se han compilado e instalado los ejemplos de wrappers CUSTOM incluidos con DataPort, siguiendo las instrucciones de Al pulsar ok, se creará la nueva fuente de datos (ver Figura 65).

Figura 65 Nueva fuente de datos CUSTOM

Pulsando el botón “Create Base View”, puede crearse de una vista base asociada al nuevo datasource. El wrapper CUSTOM utilizado para implementar el acceso a la fuente puede aceptar parámetros de entrada (véase la Guía Avanzada de VQL [VQL] ). En ese caso, se le solicitará al usuario el valor de dichos parámetros que se utilizará para esta vista base (ver Figura 66).



Figura 66 Creación de una vista base en un Datasource CUSTOM

Al pulsar ok, se creará automáticamente el esquema de una relación base asociada a la fuente de datos (ver Figura 67).



Figura 67 Nueva vista base sobre un datasource CUSTOM

Mediante el seleccionable ‘Target Project’ puede especificarse el proyecto al que desea asignarse la nueva vista. Haciendo click en una relación base que hayamos creado, podremos acceder a la página que muestra su esquema dentro de Virtual DataPort. Una vez creada la relación base, si se desea modificar su esquema para eliminar atributos o cambiar el nombre de los mismos debe utilizarse una vista proyección sobre la misma (ver sección 6.4.6). Pulsando el botón ‘Edit’ se accede directamente a la pantalla de creación de una vista proyección sobre la relación base.

6.5.10 Fuentes JDBC/ODBC a través de SQL Query

Un caso especial en la creación de relaciones base para fuentes de tipo JDBC/ODBC aparece cuando, en lugar de utilizar una tabla como “plantilla” para la creación de la relación base, deseamos utilizar para dicho propósito una query SQL arbitraria sobre la fuente (que puede, por ejemplo, incluir invocaciones de procedimientos almacenados). Para ello, desde la pantalla de detalle de la fuente de datos, debe utilizarse el botón ‘Create Base View From Query’ accediendo así a la pantalla mostrada en la Figura 68.



Figura 68 Creación de una vista base utilizando una query SQL

Una vez especificado el nombre para la relación base y la consulta SQL deseada, al pulsar ‘ok’, se creará el esquema de la nueva relación base. Su esquema puede ser editado de la manera habitual como paso previo a la creación de la relación base. La consulta SQL utilizada para la creación de la relación base puede utilizar también “variables de interpolación” (ver Guía Avanzada de VQL [VQL]), que permiten parametrizar la consulta SQL efectuada sobre la fuente en función de las condiciones de consulta especificadas en DataPort. En ese caso, al pulsar ‘ok’ para crear la relación base, se le presentará al usuario un asistente (ver Figura 69) solicitándole valores para las variables utilizadas, de forma que DataPort pueda ejecutar una consulta para obtener la metainformación necesaria para la creación de la relación base. Cada variable de interpolación debe estar asociada a un atributo de la relación base generada, de forma que la variable pueda obtener su valor en tiempo de ejecución (ver Guía Avanzada de VQL [VQL] para más detalle). Si la consulta SQL especificada para acceder a la fuente de datos devuelve algún campo con el mismo nombre que la variable, entonces la variable se asociará al atributo de la relación base correspondiente. En caso de que la consulta SQL especificada no devuelva ningún campo con el mismo nombre que la variable, DataPort añadirá un nuevo atributo a la relación base con dicho nombre.



Figura 69 Editando el valor de las variables de interpolación

6.5.11 Propiedades de Configuración de Fuentes de Datos

Virtual DataPort mantiene propiedades para cada una de las fuentes de datos y vistas base, que permiten configurar características concretas de las fuentes subyacentes, como su capacidad de soporte de transacciones distribuidas, o si permite operaciones de inserción. Esta funcionalidad permite al administrador del sistema el configurar óptimamente las características de cada fuente de datos y vista base y, por ende, sus posibilidades de combinación y ejecución. Las propiedades de cada fuente de datos pueden configurarse seleccionando la fuente de datos deseada y pulsando el botón ’Edit’, para después hacer click sobre el enlace “Source Configuration”. Este enlace sólo aparece en aquellas fuentes de datos que tengan propiedades configurables. Las propiedades configurables son las siguientes:

- Delegate All Operators (DS: JDBC, ODBC). Indica si la fuente permite delegación de todos los operadores. Por defecto, el valor es “false”.

- Delegate Array Literal (DS: JDBC, ODBC). Indica si la fuente permite delegar constantes compuestas de tipo array. Por defecto, el valor es “true” para las fuentes JDBC y ODBC.

- Delegate Compound Field Projection (DS: JDBC, ODBC). Indica si la fuente permite la delegación de proyecciones sobre campos compuestos. Por defecto, el valor es “true” para fuentes JDBC y ODBC.

- Delegate GROUP BY (DS: JDBC, ODBC). Indica si la fuente permite la delegación de la cláusula GROUP BY. Por defecto, el valor es “true” para fuentes JDBC y ODBC.

- Delegate HAVING clause (DS: JDBC, ODBC). Indica si la fuente permite la delegación de la cláusula HAVING. Por defecto, el valor es “true” para fuentes JDBC y ODBC.

- Delegate Inner Join (DS: JDBC, ODBC). Indica si la fuente permite la delegación del operador Inner Join. Por defecto, el valor es “true” para fuentes JDBC y ODBC.

- Delegate Join (DS: JDBC, ODBC). Indica si la fuente permite la delegación del operador Join. Por defecto, el valor es “true” para fuentes JDBC y ODBC.



- Delegate Left Function (DS: JDBC, ODBC). Indica si la fuente permite delegar condiciones con funciones en la parte izquierda. Por defecto, el valor es “true” para fuentes JDBC y ODBC.

- Delegate Left Literal (DS: JDBC, ODBC). Indica si la fuente permite delegar condiciones con constantes en la parte izquierda. Por defecto, el valor es “true” para fuentes JDBC y ODBC.

- Delegate Natural Outer Join (DS: JDBC, ODBC). Indica si la fuente permite la delegación del operador Natural Outer Join. Por defecto, el valor es “false” para fuentes JDBC y ODBC.

- Delegate NOT Condition (DS: JDBC, ODBC). Indica si la fuente permite la delegación de la condición NOT. Por defecto, el valor es “true” para fuentes JDBC y ODBC.

- Delegate OR Condition (DS: JDBC, ODBC). Indica si la fuente permite la delegación de la condición OR. Por defecto, el valor es “true” para fuentes JDBC y ODBC.

- Delegate ORDER BY (DS: JDBC, ODBC). Indica si la fuente permite la delegación de la cláusula ORDER BY. Por defecto, el valor es “true” para fuentes JDBC y ODBC.

- Delegate Projection (DS: JDBC, ODBC). Indica si la fuente permite la delegación del proyecciones. Por defecto, el valor es “true” para fuentes JDBC y ODBC..

- Delegate Register Literal (DS: JDBC, ODBC). Indica si la fuente permite delegar constantes compuestas de tipo registro. Por defecto, el valor es ”false” para fuentes JDBC y ODBC.

- Delegate Right Function (DS: JDBC, ODBC). Indica si la fuente permite delegar condiciones con funciones en la parte derecha. Por defecto, el valor es “true” para fuentes JDBC y ODBC.

- Delegate Right Literal (DS: JDBC, ODBC). Indica si la fuente permite delegar condiciones con constantes en la parte derecha. Por defecto, el valor es “true” para fuentes JDBC y ODBC.

- Delegate Selection (DS: JDBC, ODBC). Indica si la fuente permite delegar condiciones. Por defecto, el valor es “true” para fuentes JDBC y ODBC.

- Delegate UNION (DS: JDBC, ODBC). Indica si la fuente permite la delegación del operador de unión. Por defecto, el valor es “true” para fuentes JDBC y ODBC.

- Supports Modifier in Aggregate Function (DS: JDBC, ODBC): Indica si la fuente soporta modificadores DISTINCT/ALL en las funciones de agregación.

- Supports Branch Outer Join (DS: JDBC, ODBC). Indica si la fuente permite (left | right) outer join. Por defecto, el valor es “false” para fuentes JDBC y ODBC.

- Supports Eq Outer Join (DS: JDBC, ODBC). Indica si la fuente permite la delegación del operador Equality Outer Join. Por defecto, el valor es “false” para fuentes JDBC y ODBC.

- Supports Explicit Cross Join (DS: JDBC, ODBC). Indica si la fuente permite la delegación del operador Explicit Cross Join. Por defecto, el valor es “false” para fuentes JDBC y ODBC.

- Supports Full Eq Outer Join (DS: JDBC, ODBC). Indica si la fuente permite la delegación del operador Full Equality Outer Join. Por defecto, el valor es “false” para fuentes JDBC y ODBC.

- Supports Full NotEq Outer Join (DS: JDBC, ODBC). Indica si la fuente permite la delegación del operador Full Not Equality Outer Join. Por defecto, el valor es “false” para fuentes JDBC y ODBC.

- Supports Fusing in using AND Natural Join (DS: JDBC, ODBC). indica si la fuente fusiona los campos iguales al ejecutar un join natural o un join con la clausula USING. Por defecto, el valor es “false” para fuentes JDBC y ODBC.

- Supports Join On Condition (DS: JDBC, ODBC). Indica si la fuente permite la delegación de la cláusula Join On. Por defecto, el valor es “false” para fuentes JDBC y ODBC.

- Supports Natural Join (DS: JDBC, ODBC). Indica si la fuente permite la delegación de la cláusula Natural Join. Por defecto, el valor es “false” para fuentes JDBC y ODBC.

- Supports Using Join (DS: JDBC, ODBC). Indica si la fuente permite la delegación de la cláusula Using Join. Por defecto, el valor es “false” para fuentes JDBC y ODBC.

- Delegate Aggregate Functions List (DS: JDBC, ODBC). Indica qué funciones de agregación son delegables. En las fuentes JDBC y ODBC, la lista está compuesta por las funciones AVG, COUNT, MAX, MIN y SUM.

- Delegate Scalar Functions List (DS: JDBC, ODBC). Indica qué funciones escalares son delegables. En las fuentes JDBC y ODBC, la lista está compuesta por las funciones ABS, CEIL, CONCAT, DIV, FLOOR, GETDAY, GETHOUR, GETMINUTE, GETSECOND, GETMONTH, GETYEAR, LEN, LOG, LOWER, MOD, MULT, NOW, POWER, REPLACE, ROUND, SQRT, SUBSTRACT, SUM, TEXTCONSTANT, TRIM y UPPER.

- Delegate Operators List (DS: JDBC, ODBC). Indica qué operadores son delegables. En las fuentes JDBC y ODBC, la lista está compuesta por los operadores =, <>, <=, >, >=, in, between, contains, containsor, like, isnull, isnotnull, istrue e isfalse.

Virtual DataPort tiene valores por defecto para algunas bases de datos relacionales concretas (MySQL, Oracle, Postgres, …) que pueden variar con respecto a los arriba descritos.

6.6 CONFIGURACIÓN AVANZADA DE VISTAS

El botón ‘Advanced’ de la pantalla del esquema de una vista permite acceder a su asistente de configuración avanzada (ver Figura 70). Desde esta pantalla puede configurarse la cache de la vista, sus capacidades de consulta, su política de “swapping” a disco, ciertas características de su plan de ejecución (sólo en vistas derivadas), su configuración de internacionalización (sólo en vistas base) y algunos aspectos específicos para las vistas procedentes de algunos tipos de fuentes. Los siguientes subapartados se ocupan de cada uno de estos aspectos.

Figura 70 Pantalla de configuración avanzada de la vista average_monthly_sales

6.6.1 Configuración de Internacionalización

La configuración de internacionalización de una relación base especifica aspectos tales como zonas horarias, lenguajes o monedas. Por ejemplo, la moneda que se utilizará en los valores de tipo Money viene especificada por esta propiedad. DataPort incluye configuraciones de internacionalización típicas y, además, permite la creación de nuevas configuraciones ad-hoc. Véase la Guía Avanzada de VQL [VQL] para más información.

6.6.2 Configuración de la cache de una vista

Para la cache de una vista pueden utilizarse los siguientes parámetros:



• Tiempo de expiración (‘time to live’). Indica el tiempo de expiración (en segundos) para los datos

almacenados en la cache de la vista. • Cache on/off/post. Puede activarse o desactivarse la cache para la vista mediante el selector cache on/off.

La opción ‘post’ activa la cache permitiendo además el uso de post-procesados. Si la opción ‘post’ está habilitada, el sistema detectará si una consulta dada puede ser contestada en función de otra consulta previa aunque ésta no sea igual a la nueva consulta. Esto se realiza mediante la aplicación de una serie de operaciones de post-procesado. Por ejemplo, si los resultados de una consulta previa select * from view where field1 = a están en la cache y el sistema recibe la query select * from view where field1 = a and field2 = b, sería posible responderla tomando como base los resultados de la primera consulta y aplicando una operación de post-procesado que elimine aquellas tuplas en las cuáles no se cumpla que field2 = b. Si esta opción se encuentra deshabilitada, el sistema sólo utilizará la cache si la consulta recibida es la misma que la consulta previa. El uso de la técnica de post-procesados puede no ser deseable si un wrapper no devuelve siempre todos los resultados de una consulta efectuada sobre una determinada fuente. Por ejemplo, si un wrapper que accede a una fuente web devuelve sólo los primeros 100 resultados devueltos por la fuente para la consulta select * from view where field1 = a , entonces el resulltado de aplicar la condición de post-procesado (field2 = b) sobre los resultados de la consulta puede ser diferente del resultado obtenido al ejecutar directamente sobre la fuente select * from view where field1 = a and field2 = b.

6.6.3 Configuración de swapping

Para evitar desbordamientos de memoria, Virtual DataPort puede hacer “swapping” a disco de los resultados intermedios generados durante el proceso de ejecución de una vista. Para habilitar o deshabilitar el “swapping” para la vista deben utilizarse, respectivamente, las opciones “Swap on” o “Swap off” (opción por defecto). Es necesario haber activado previamente el “swapping” a nivel global en el servidor (ver sección 5.1.4). Durante la ejecución de una vista o consulta, DataPort realizará “swapping” a disco cuando algún resultado intermedio producido durante la ejecución supere un tamaño máximo determinado. Este tamaño puede ser especificado (en megabytes) utilizando el campo “Max size”. Como norma general, se recomienda que el valor especificado no sea mayor que la tercera parte de la memoria disponible para la máquina virtual JAVA en la que se ejecuta el servidor DataPort. NOTA: DataPort también permite configurar dinámicamente el uso de “swapping”para una consulta determinada utilizando la cláusula CONTEXT de VQL (ver la Guía Avanzada de VQL [VQL]).

6.6.4 Edición del Plan de Ejecución

Un aspecto clave en la optimización de la ejecución de consultas y vistas en DataPort es la estrategia de ejecución utilizada para cada operación de join involucrada. Tal y cómo se ha descrito en la sección 6.4.3, al crear una vista de tipo join es posible especificar la estrategia de ejecución deseada. Una estrategia de ejecución de una operación de join indica dos parámetros (ver ‘Optimización de Consultas’ en la Guía Avanzada de VQL [VQL] para más detalle):

• Método de ejecución (merge, hash o nested) y • Orden en el que deben considerarse las relaciones de entrada. La vista de la parte superior se considerará

como primera relación si se escoge la opción Ordered y como segunda si se escoge Reverse Order).



Además, también es posible escoger la opción ANY, de forma que DataPort escogerá el método de ejecución a utilizar. Sin embargo, una vista puede ser utilizada como base para la construcción de otras vistas derivadas y la estrategia óptima a utilizar para una misma operación de join puede ser diferente en cada caso. Ejemplo: Supóngase una vista join V3 con atributos A, B y C. V3 tiene como relaciones de entrada a las vistas V1 (con atributos A y B) y V2 (con atributos B y C). Supóngase también que las consultas sobre V3 están utilizando el método de ejecución nested-loop. Una práctica común de optimización al utilizar este método de ejecución es ordenar las relaciones de entrada de forma que la primera sea la que menos tuplas aporta a la operación de join. En nuestro ejemplo, supondremos que habitualmente el número de tuplas de entrada al join procedentes de V1 es menor que el de V2 y, por lo tanto, V3 se consulta habitualmente considerando a V1 como primera relación. Supóngase ahora que deseamos crear una nueva vista V4 que es una vista selección sobre V3 aplicando la condición C=c. Supóngase también que hay pocas tuplas en V2 que verifiquen dicha condición. Entonces, al ejecutar una consulta sobre V4, la situación más habitual será que a la vista join V3 lleguen menos tuplas procedentes de V2 que de V1. Por tanto, cuando se ejecute V4 sería deseable que V2 fuese considerada como primera relación, a diferencia del caso general dónde se pretende lo contrario. Para tratar estos casos, en cualquier vista derivada V es posible definir la estrategia de ejecución preferida para cada una de las vistas join que intervienen en su definición. Estas estrategias se utilizarán sólo al ejecutar consultas sobre V y no sobrescribirán las preferencias de ejecución por defecto de dichas vistas join.

Figura 71 Editando el Plan de Ejecución de una vista

De esta forma, las preferencias para el plan de ejecución de V no afectarán a las consultas efectuadas directamente sobre las vistas join originales o sobre otras vistas derivadas que las utilicen.



Para editar las preferencias sobre la estrategia de ejecución de joins de una vista derivada, debe accederse a su pantalla de configuración avanzada y pulsar en el botón ‘Edit Execution Plan’. Se mostrará entonces la pantalla de edición de planes de ejecución de la vista (en la Figura 71, se muestra la pantalla de edición de planes de ejecución para la vista incidences_sales creada en la sección 6.4.3). La pantalla muestra el árbol de definición de la vista. Para cada operación de join involucrada en la definición, es posible marcar la casilla ‘Specify execution plan (don’t inherit it)’ habilitando así dos campos seleccionables para escoger el método de ejecución y el orden de las relaciones de entrada que se desee. Si se especifica la opción ‘ANY’ para algún parámetro, DataPort utilizará información de costes interna para escoger la opción más adecuada para el mismo. Al pulsar ‘ok’ se volverá a la pantalla de configuración avanzada de la vista. Pulsando de nuevo ‘ok’ en esta pantalla los cambios de configuración serán efectivos. NOTA: DataPort también permite configurar dinámicamente las preferencias del plan de ejecución para una consulta determinada utilizando la cláusula CONTEXT de VQL (ver la Guía Avanzada de VQL [VQL]).

6.6.5 Capacidades de consulta

Algunas fuentes de datos tales cómo los sitios web o los sistemas que ofrecen una interfaz Web Service, no permiten cualquier consulta sobre sus datos, sino que presentan interfaces de consulta limitada (e.g. formularios HTML en el caso de un sitio web y una lista de parámetros en el caso de una operación de un Servicio Web). Es por ello que Virtual DataPort permite al administrador especificar explícitamente las capacidades de consulta de las relaciones o vistas base. Además, Virtual DataPort también calcula automáticamente las capacidades de consulta de las vistas derivadas en función de las capacidades de sus vistas base. Por lo tanto al acceder a la configuración avanzada de una vista, las opciones disponibles varian en función de si la vista es una relación base (también llamadas vistas base) o bien es una vista derivada. La diferencia estriba en que en el caso de las relaciones base es posible modificar sus capacidades de consulta, mientras que en el caso de las vistas derivadas es posible consultarlas pero no modificarlas directamente. Las capacidades de consulta se expresan mediante una lista de métodos de búsqueda. Cada método de búsqueda especifica una manera diferente en la que la vista (o relación base) puede ser consultada. Véase la sección 6.6.5.1 para una descripción detallada sobre cómo interpretar los métodos de búsqueda de una vista (o relación base). Al crear una relación base, el sistema le asigna automáticamente unos métodos de búsqueda. Si bien en la mayoría de ocasiones los métodos creados automáticamente no necesitarán ser modificadas, este puede no ser siempre el caso, especialmente en fuentes de los tipos web y Web Service. Una vez en la vista de configuración avanzada de una relación base, es posible modificar fácilmente los métodos de búsqueda generados por defecto para la misma (ver Figura 70). Como puede verse en la figura un método de búsqueda especifica para cada atributo de la vista (véase la siguiente subsección para más detalle): • Su tipo de dato, • Una lista de operadores por los que el campo puede ser consultado. ‘any’ indica cualquier operador. Pueden

añadirse nuevos operadores para el atributo utilizando el desplegable de su columna ‘Operators’. También pueden eliminarse operadores utilizando los botones ‘[x]’ que aparecen al lado de cada operador.

• Una indicación sobre si se trata de un atributo obligatorio (‘OBL’) opcional (‘OPT’) o no soportado (‘NOS’) en las consultas sobre la vista.

• La multiplicidad soportada para el atributo en las consultas sobre la vista. • Una lista de los valores posibles para el atributo que pueden aparecer en una condición de una consulta válida

sobre la vista. Si no se especifica ningún valor, se asume que cualquiera es válido. Para añadir nuevos valores



basta teclearlos en la caja de texto que aparece en la columna ‘Values’ del atributo y pulsar el botón que aparece a su derecha. Puede borrarse un valor utilizando el botón ‘[X]’ que aparece a su lado.

• Una indicación de si el atributo aparece o no en la respuesta de las consultas efectuadas sobre la vista. Si se desean añadir o borrar métodos de búsqueda completos, es posible hacerlo utilizando directamente el lenguaje VQL (véase la Guía Avanzada de VQL [VQL]).

6.6.5.1 Métodos de Búsqueda

Cada relación base describe explícitamente sus capacidades de consulta mediante los denominados métodos de búsqueda. Si una relación no tiene ningún método de búsqueda, entonces no podrá realizarse ninguna consulta sobre ella. Cada método de búsqueda estará compuesto por una serie de 5-uplas. Cada 5-upla representa una restricción que una consulta determinada debe cumplir para que pueda ser ejecutada sobre la fuente utilizando ese método de búsqueda. El formato de una 5-upla es (atributo, operadores, obligatoriedad, multiplicidad, valores_posibles) donde:

• atributo es un atributo de la relación.

• operadores es el conjunto de operadores que puede ser utilizado en las consultas sobre esa relación base y con ese método de búsqueda. ‘ANY’ representa a cualquier operador admitido por el tipo de dato del atributo.

• obligatoriedad puede tomar tres valores: ‘OBL’ indica que el atributo debe obligatoriamente aparecer en cualquier consulta sobre la fuente. ‘OPC’ indica que el atributo puede aparecer o no en la consulta (es opcional) y ‘NOS’ indica que las consultas por ese atributo no están permitidas en la fuente.

• multiplicidad indica por cuántos valores puede consultarse a la vez la fuente para el atributo y el operador dados. Si no es posible realizar consultas por ese atributo (valor “NOS” en el campo obligatoriedad) el valor es forzosamente 0. ‘+’ indica un número de valores mayor que 0 pero sin límite superior.

• valores_posibles es la lista de valores por los que puede consultarse el atributo. Si contiene el valor ‘ANY’ significa que el rango de búsqueda no está acotado (dentro del rango asociado al tipo de dato del atributo) y puede consultarse el atributo por cualquier valor. Si el campo obligatoriedad está fijado en la 5-upla al valor ‘NOS’, entonces forzosamente toma el valor de un conjunto vacío.

Ejemplo: Consideremos el ejemplo de una tienda virtual de libros en Internet cuyo formulario de búsqueda es como el mostrado en la Figura 72.



Figura 72 Formulario de búsqueda para una tienda de libros

El formulario obliga al usuario a especificar un valor para el atributo TITLE y opcionalmente le permite fijar un valor para el atributo AUTHOR y para el atributo FORMAT (restringido a un conjunto de valores). Las búsquedas por título y autor son búsquedas por palabra clave (operador Contains). Una búsqueda por frase exacta (operador eq) se indica marcando la casilla adjunta a la caja de búsqueda del campo. Para cada atributo se permite la búsqueda simultánea por un solo valor. Además de los campos TITLE, AUTHOR y FORMAT, supondremos que la tienda devuelve en su salida un atributo PRICE, por el que no se pueden realizar consultas directamente en el formulario. Modelaremos esta fuente como una relación R={TITLE,AUTHOR,FORMAT,PRICE} con un método de búsqueda conteniendo las 5-uplas que se muestran en la Figura 73.

(TITLE,{like,=}, OBL, 1, Any) (AUTHOR, {like,=}, OPT, 1, Any) (FORMAT, {=}, OPT, 1,

{‘All formats’,‘Hardcover’,‘eBooks’, `Paperbacks’}) (PRICE, {}, NOS, 0, {})

Figura 73 Método de búsqueda para una tienda de libros

Nótese que la primera 5-upla tenga el valor {Contains, eq} en el campo OPERADORES y OBL en el campo OBLIGATORIEDAD, no significa que sea obligatorio consultar el atributo TITLE con ambos operadores, sino que es obligatorio consultarlo al menos con alguno de ellos. Si se quisiese representar que el atributo TITLE debe aparecer obligatoriamente en la consulta con ambos operadores (no es posible en el formulario de ejemplo), debería hacerse con dos 5-uplas diferentes para el atributo TITLE, una con cada operador: {(TITLE, {like}, OBL, 1, ANY) (TITLE, {=}, OBL, 1, ANY)}. Por tanto, como se ve, cuando se quiere diferenciar el tratamiento de un determinado atributo en función del operador con el que se utiliza, puede haber más de una 5-upla por atributo. Al crear vistas o relaciones del esquema global, Virtual DataPort es capaz de calcular automáticamente sus métodos de búsqueda partiendo de los de las fuentes y de la expresión utilizada para definir la vista. Esto permite al sistema saber a priori si una determinada consulta va a poder ser contestada. Por lo tanto, para vistas derivadas, DataPort permite consultar las capacidades de consulta de las mismas, pero no es posible modificarlas directamente.



6.6.6 Propiedades de Configuración de Vistas

Tal y como ya se ha comentado en el apartado 6.5.11, Virtual DataPort mantiene propiedades para cada una de las fuentes de datos y vistas base, que permiten configurar características concretas de las fuentes subyacentes, como su capacidad de soporte de transacciones distribuidas, o si permite operaciones de inserción. En el apartado 6.5.11 se comentaron las propiedades de configuración de las fuentes de datos. En esta sección se describen aquellas propiedades configurables en cada una de las vistas base, dependiendo del tipo de fuente de datos de donde provienen. Las propiedades de cada vista base pueden configurarse seleccionando la vista base en el menú izquierdo, ya sea en el área “DataSources” o en “QueryBuilder”, y pulsar el botón “Advanced” para que aparezca la ventana de configuración avanzada de la vista base. Debajo de los métodos de búsqueda (utilizando la barra de desplazamiento si es necesario) aparece el enlace “Wrapper Source Configuration”, que lleva, finalmente, a la pantalla de configuración de propiedades. También se pueden configurar desde VQL (ver la Guía Avanzada de VQL [VQL] para más información). Las propiedades configurables son las siguientes: - Allow Insert: indica si la fuente de datos subyacente a la vista admite operaciones de inserción. Es aplicable a

bases de datos relacionales (accesibles mediante JDBC y ODBC) y wrappers CUSTOM. Los posibles valores son: o Default: VDP asigna un valor por defecto dependiendo del tipo de fuente. En el caso de fuentes

relacionales y wrappers CUSTOM, el valor por defecto es “Yes”. o Yes: la fuente de datos permite las operaciones de inserción. o No: la fuente de datos no permite las operaciones de inserción.

- Allow Delete: indica si la fuente de datos subyacente a la vista admite operaciones de borrado de filas. Es aplicable a bases de datos relacionales (accesibles mediante JDBC y ODBC) y wrappers CUSTOM. Los posibles valores son:

o Default: VDP asigna un valor por defecto dependiendo del tipo de fuente. En el caso de fuentes relacionales y wrappers CUSTOM, el valor por defecto es “Yes”.

o Yes: la fuente de datos permite las operaciones de borrado. o No: la fuente de datos no permite las operaciones de borrado.

- Allow Update: indica si la fuente de datos subyacente a la vista admite operaciones de actualización de filas. Es aplicable a bases de datos relacionales (accesibles mediante JDBC y ODBC) y wrappers CUSTOM. Los posibles valores son:


o Yes: la fuente de datos permite las operaciones de actualización. o No: la fuente de datos no permite las operaciones de actualización.

- Delegate All Operators. Indica si la vista permite delegación de todos los operadores. Aplicable a wrappers CUSTOM. Por defecto, el valor es “true”.

- Delegate AND Condition. Indica si la vista permite la delegación de la condición AND. Por defecto, el valor es “true” para vistas base procedentes de wrappers CUSTOM.

- Delegate Array Literal: Indica si la vista permite delegar constantes compuestas de tipo array. Aplicable a wrappers CUSTOM. Por defecto, el valor es “true”.

- Delegate Compound Field Projection: Indica si la vista permite la delegación de proyecciones sobre campos compuestos. Aplicable a wrappers CUSTOM. Por defecto, el valor es “true”.

- Delegate Left Function: Indica si la vista permite delegar condiciones con funciones en la parte izquierda. Aplicable a wrappers CUSTOM. Por defecto, el valor es “true”.

- Delegate Left Literal: Indica si la vista permite delegar condiciones con constantes en la parte izquierda. Aplicable a wrappers CUSTOM. Por defecto, el valor es “true”.

- Delegate NOT Condition: Indica si la vista permite la delegación de la condición NOT. Aplicable a wrappers CUSTOM. Por defecto, el valor es “true”.

- Delegate OR Condition: Indica si la vista permite la delegación de la condición OR. Aplicable a wrappers CUSTOM. Por defecto, el valor es “true”.

- Delegate Register Literal: Indica si la vista permite delegar constantes compuestas de tipo registro. Aplicable a wrappers CUSTOM. Por defecto, el valor es “true”.



- Delegate Right Field: Indica si la vista permite delegar condiciones con campos en la parte derecha. Aplicable a wrappers CUSTOM. Por defecto, el valor es “true”.

- Delegate Right Function: Indica si la vista permite delegar condiciones con funciones en la parte derecha. Aplicable a wrappers CUSTOM. Por defecto, el valor es “true”.

- Delegate Right Literal: Indica si la fuente permite delegar condiciones con constantes en la parte derecha. Aplicable a wrappers CUSTOM. Por defecto, el valor es “true”.

- Supports Distributed Transactions: indica si la fuente de datos subyacente puede participar en una transacción distribuída XA [XA]. Es aplicable a bases de datos relacionales (accesibles mediante JDBC y ODBC) y wrappers CUSTOM. Los posibles valores son:


o Yes: la fuente de datos cumple la especificación XA. o No: la fuente de datos no cumple la especificación XA.

- Data in Order Field List: indica los campos por los que vienen ordenados los datos. Se separan por comas y los nombre de campos van acompañados del modificador ASC/DESC. Propiedad aplicable en todas las fuentes de datos.

- Delegate Operators List: esta propiedad determina la lista de operadores delegables a la fuente de datos. Esto permite a VDP optimizar el plan de consulta creado a partir de la consulta realizada por el usuario, delegando parte del procesamiento a la fuente nativa. Mientras que VDP realiza automáticamente esta acción en bases de datos relacionales (dejando que las operaciones de selección, proyección, unión o join sean ejecutadas por la base de datos de la que la vista base concreta proviene), otros tipos de fuentes no proveen esa información en sus metadatos, aunque a veces sea posible. VDP permite indicar la lista de operadores delegables en el tipo de datos Web Service y CUSTOM (en wrappers CUSTOM por defecto se permiten delegar todos los operadores (DelegateAllOperators = true). En wrappers WS se permiten delegar operador "=").

6.6.7 Propiedades de Configuración para tipos específicos de Vistas

Las vistas base procedentes de algunos tipos de fuentes presentan propiedades de configuración específicas. En la actualidad, las fuentes cuyas vistas base presentan parámetros específicos son las de tipo Denodo Aracne (ver sección 6.5.7) y las de tipo Google Mini (ver sección 6.5.6). Las propiedades específicas estos tipos de vistas base pueden configurarse seleccionando la vista base en el menú izquierdo, ya sea en el área “DataSources” o en “QueryBuilder”, y pulsando el botón “Advanced” para que aparezca la ventana de configuración avanzada de la vista base. Debajo de los métodos de búsqueda (utilizando la barra de desplazamiento si es necesario) aparece el enlace “Wrapper Specific Configuration”, que lleva, finalmente, a la pantalla de configuración de propiedades. En el caso de las vistas base procedentes de fuentes de tipo Google Mini, las propiedades configurables son: “Site Collections”, “Client”, “Languages” y “Number of Key match”. Véase la sección 6.5.6 para una descripción de la función de estas propiedades. En el caso de las vistas base procedentes de fuentes de tipo Denodo Aracne, las propiedades configurables son las referentes a los atributos creados durante la importación de la vista base para contener los términos más relevantes de un documento (o de un campo del mismo). Véase la sección 6.5.7 para una descripción de la función de estas propiedades.

6.7 PROCEDIMIENTOS ALMACENADOS

DataPort permite escribir procedimientos almacenados utilizando el lenguaje JAVA (ver Guía Avanzada de VQL [VQL]). En la ruta DENODO_HOME/samples/vdp/storedProcedures se encuentran diversos procedimientos almacenados de ejemplo. El fichero README en la citada ruta describe su función y contiene las instrucciones para



compilarlos e instalarlos. En esta sección utilizaremos el procedimiento almacenado CalculateAvgRevenue, incluido en dichos ejemplos.

6.7.1 Importación de Procedimientos Almacenados

Para importar un nuevo procedimiento almacenado (Stored Procedure), es necesario acceder a la pestaña “Query Builder”, y tras seleccionar el proyecto al que deseamos añadir el nuevo procedimiento, hacer click en la opción ‘New’ que aparece al lado de la lista actual. Se accederá entonces a la pantalla de importación de un nuevo procedimiento almacenado (ver Figura 74). En esta pantalla se solicitarán los siguientes datos:

• Nombre con el que se denominará al procedimiento almacenado dentro de Virtual DataPort. • Nombre completo de la clase que implementa el procedimiento almacenado. Por ejemplo, suponiendo que

se han compilado e instalado los ejemplos de procedimientos almacenados incluidos con la distribución de DataPort, podríamos introducir el valor com.denodo.vdp.demo.storedprocedure.CalculateAvgRevenue. La clase indicada debe encontrarse en el CLASSPATH de DataPort en el momento de arrancar el servidor. Para ello puede incluirse la clase a partir de la ruta DENODO_HOME/extensions/dev/target/classes. También es posible colocar la clase en cualquier otra ruta siempre que esta esté incluida en el valor de la variable de entorno $DENODO_EXTERNAL_CLASSPATH.

• Ruta al fichero .jar que contiene la clase que implementa el procedimiento almacenado (opcional). Si la clase que implementa el procedimiento almacenado no se encuentra en el CLASSPATH actual del servidor DataPort, puede utilizarse esta opción para proporcionar la ruta al fichero .jar que la contiene.

Figura 74 Importación de un Procedimiento Almacenado

Al pulsar ‘Ok’, se accederá a la pantalla que muestra las propiedades del procedimiento almacenado que se acaba de importar, incluyendo sus parámetros de entrada y/o de salida junto con el tipo de dato asociado a cada uno (ver Figura 75).



Los parámetros de un procedimiento almacenado pueden ser de tipo IN, OUT o IN_OUT. Los parámetros IN son parámetros de entrada; los OUT son parámetros que se muestran sólo a la salida; y los parámetros IN_OUT son parámetros de entrada que también se muestran a la salida. El tipo de los parámetros de un procedimiento almacenado sirve para indicar con qué campos hay que consultar el procedimiento almacenado (IN) y cuáles mostrará como resultado (OUT). En la Figura 75 se muestra información sobre el procedimiento almacenado CALCULATEREVENUE el cual tiene dos parámetros: el parámetro de entrada (IN) denominado taxid_list de tipo array y el parámetro de salida (OUT) avgRevenue de tipo double.

Figura 75 Propiedades de un procedimiento almacenado

6.7.2 Ejecución de Procedimientos Almacenados

Los procedimientos almacenados pueden ser invocados mediante la sentencia CALL (Guía Avanzada de VQL [VQL]). Los procedimientos almacenados pueden también ser ejecutados desde la herramienta de administración. Para ello, debe pulsarse el botón ‘Execute’ desde la pantalla que muestra las propiedades del procedimiento almacenado. La herramienta solicitará entonces valores para los parámetros de entrada del procedimiento y realizará la ejecución del mismo, mostrando la salida obtenida. En la Figura 76 se muestra la pantalla en la que se especifican los valores de los parámetros de entrada para el procedimiento CalculateAvgRevenue. Dicho procedimiento de ejemplo recibe como entrada un parámetro de tipo array de registros llamado taxid_list. Cada registro contiene un único campo llamado taxid, que se corresponde con el CIF de un cliente. En nuestro ejemplo, podemos crear un array conteniendo dos registros con los valores ‘B78596011’ y ‘B78596012’ (en la sección 6.4.4.1.4 se explicó cómo utilizar el wizard de creación de constantes de tipos compuestos).



Figura 76 Ejecución del procedimiento almacenado CalculateAvgRevenue

El resultado de la ejecución se muestra en la Figura 77.



Figura 77 Resultado de la ejecución del procedimiento almacenado CalculateAvgRevenue

6.7.3 Uso de Procedimientos Almacenados en la Creación de Vistas

Los procedimientos almacenados de Virtual DataPort pueden ser utilizados como base para la creación de nuevas vistas derivadas. En particular, una invocación a un procedimiento almacenado puede aparecer en la cláusula FROM de cualquier consulta o definición de vista VQL. El procedimiento almacenado se considerará como una vista cuyo esquema incluye todos los parámetros de entrada y/o salida (es decir, de tipo IN, OUT o IN_OUT) del procedimiento almacenado y con un único método de búsqueda (ver sección 6.6.5). El método de búsqueda de una vista creada a partir de un procedimiento almacenado tendrá una restricción de obligatoriedad por cada parámetro de entrada (IN e IN_OUT) y una restricción NOS por cada parámetro de salida (OUT). Puede crearse gráficamente una vista que utilice un procedimiento almacenado en la cláusula FROM. Para ello, basta con hacer ‘drag&drop’ del procedimiento deseado sobre la pantalla de creación de vistas del tipo deseado (unión, join, selección, proyección,…). En ese momento, si el procedimiento tiene parámetros de entrada (IN e IN_OUT), se solicitará un valor para los mismos.


Publicación de Servicios Web 106

7 PUBLICACIÓN DE SERVICIOS WEB

Virtual DataPort permite publicar una o varias vistas (y/o procedimientos almacenados) como un Servicio Web, facilitando así su uso por cualquier aplicación externa. En esta sección se describe dicho proceso de publicación.

Figura 78 Publicación de un Web Service

La publicación de vistas se realiza mediante la pestaña ‘Data Export Tool’ de la herramienta de administración. Una vez accedida dicha pestaña, los pasos para generar el servicio web son los siguientes:

1. Hacer click en la opción ‘new’ del panel “Web Services” para acceder a la pantalla de publicación de un nuevo servicio web (ver Figura 78).

2. Seleccionar una vista (o procedimiento almacenado) a exportar utilizando el desplegable “Projects” de la

parte izquierda y hacer un drag&drop de la misma hasta el área de trabajo de la parte derecha de la pantalla. En nuestro ejemplo, haremos “ drag&drop ” de la vista inc_grouped_by_pref_clients creada en la sección 6.4.5.

3. Al añadir la vista o procedimiento almacenado que se desea publicar, DataPort analiza las capacidades de

consulta permitidas por la misma y genera de forma automática una serie de “operaciones candidatas” para consultar la vista a través del servicio web (en la Figura 79 se muestran las operaciones generadas para nuestro ejemplo). Típicamente, se generarán operaciones con las siguientes características:

a. Las operaciones generadas tendrán una serie de parámetros de entrada que se corresponderán

con atributos de la vista (en el caso de procedimientos almacenados, se corresponderán con los



parámetros de entrada del procedimiento). Su invocación devolverá aquellas tuplas de la vista o procedimiento almacenado cuyos valores para los atributos de entrada coincidan con los especificados para los parámetros correspondientes. En nuestro ejemplo hay una operación de este tipo: getINC_GROUPED_BY_PREF_CLIE_001 que recibe tres parámetros de entrada, que se corresponden con los atributos de la vista taxID, revenue y num_incidences,

b. En caso de que en la vista hubiese métodos de búsqueda sin atributos obligatorios (ver sección

6.6.4), se generará también una operación sin parámetros de entrada que, al ser invocada, devolverá todas las tuplas de la vista. En nuestro ejemplo esta operación se llama getINC_GROUPED_BY_PREF_CLIE.

c. El valor de retorno de todas las operaciones generadas será un array de elementos. Cada uno de

estos elementos se corresponderá con una tupla de la vista y tendrá un subelelemento para cada uno de sus atributos.

Figura 79 Operaciones generadas para inc_grouped_by_pref_clients

4. Es posible eliminar una operación candidata (pulsando la opción ‘drop’ al lado del nombre de la misma), así como cambiar su nombre (pulsando la opción ‘rename’).

5. También es posible eliminar parámetros de entrada de una operación (pulsando la opción ‘drop’ al lado del

nombre del parámetro) si bien, dependiendo de las capacidades de consulta de la vista (ver sección 6.6.4), en algunas de las operaciones generadas puede haber parámetros obligatorios que no puedan ser eliminados.



6. Es posible añadir al servicio web generado operaciones generadas a partir de otras vistas o procedimientos almacenados. Para ello basta con hacer drag & drop de la nueva vista y repetir los pasos 3-5.

7. A continuación es necesario especificar:

a. El estilo de Servicio Web a generar (RPC o DOCUMENT). Algunas aplicaciones consumidoras de Servicios Web pueden exigir un estilo concreto.

b. El nombre deseado para el servicio web que será generado (campo ‘Edit Web Service name’) c. La ruta dónde se desea generar los ficheros .wsdl y .war del servicio web.

i. El fichero .war contiene la implementación del Servicio Web y puede ser instalado en un contenedor web J2EE (como, por ejemplo, Apache Tomcat [TOM]).

ii. El fichero .wsdl [WSDL] define la interfaz del servicio web generado. Puede usarse junto a una utilidad para la programación de Web Services (como, por ejemplo, las incluidas con Apache Axis [AXIS]) para generar los stubs necesarios para implementar un programa cliente que acceda al servicio web.

8. Finalmente, pulsando ‘ok’ los ficheros .wsdl y .war serán generados en la ruta especificada.

La Tabla 1 muestra las conversiones aplicadas entre los tipos de dato DataPort y los tipos de dato utilizados para los parámetros de entrada y salida del servicio web generado. En dicha tabla, el prefijo xsd identifica a los tipos XML Schema y el prefijo soapenc a los tipos SOAP)

Tipo de Dato DataPort Tipo de dato Servicio Web text xsd:string long xsd:long double xsd: double int xsd:int

boolean xsd:boolean link xsd:string float xsd:float money xsd:double time xsd:int date xsd:date ó xsd:dateTimeblob xsd:hexBinary xml xsd:string

enumerated xsd:string array xsd:complexType

(restriction on soapenc:array)

register xsd:complexType (sequence)

Tabla 1 Conversiones entre tipos de dato DataPort y tipos de parámetros de servicios web


Bases de Datos, Usuarios y Permisos en Virtual DataPort 109

8 BASES DE DATOS, USUARIOS Y PERMISOS EN VIRTUAL DATAPORT

En esta sección se describen diversos conceptos clave dentro de la arquitectura de Virtual DataPort. La sección 8.1 describe el concepto de base de datos tal y como se entiende en el contexto de un servidor Virtual DataPort. La sección 8.2 describe los conceptos generales sobre la gestión de usuarios y permisos en DataPort. Por último, en la sección 8.3 se describe cómo gestionar esta estructura haciendo uso de la herramienta de administración gráfica de Virtual DataPort. Los comandos VQL que permiten gestionar esta estructura son descritos detalladamente en la Guía Avanzada de VQL [VQL].

8.1 BASES DE DATOS EN VIRTUAL DATAPORT

Un servidor de Virtual DataPort puede contener varias bases de datos diferentes (no confundir con las posibles bases de datos externas que puedan actuar como fuentes del sistema). Una base de datos de Virtual DataPort representa un esquema virtual compuesto por una serie de DataSources, vistas y relaciones base. Cada base de datos es independiente del resto de base de datos del servidor y, tal y como se detalla en la siguiente sección, los diferentes usuarios pueden tener privilegios diferentes sobre cada base de datos. Es decir, no es posible acceder a los elementos de una base de datos desde otra base de datos; por otra parte, todos los elementos del catálogo, excepto usuarios, bases de datos y i18n pertenecen a una base de datos concreta. Al instalar un servidor Virtual DataPort se crea una base de datos de ejemplo llamada admin.

8.2 ESTRUCTURA DE USUARIOS Y PERMISOS EN VIRTUAL DATAPORT

8.2.1 Tipos de usuarios

Denodo Virtual DataPort distingue dos tipos de usuarios:

• Administradores. Pueden crear, modificar y borrar bases de datos dentro de un servidor DataPort sin limitación alguna. De la misma forma también pueden crear usuarios, modificarlos (por lo tanto editar sus permisos) y borrar usuarios. Al instalar el servidor se crea un usuario de administración por defecto cuyo nombre de usuario es admin y su contraseña es también admin. Este usuario nunca puede ser borrado.

• Usuarios normales. No pueden crear, modificar ni borrar usuarios. No pueden crear ni borrar bases de

datos, aunque sí pueden tener privilegios de conexión, lectura, creación o escritura sobre una o varias bases de datos y de inserción, actualización, consulta y borrado sobre vistas particulares contenidas en las mismas. También pueden establecer permisos de lectura y escritura sobre procedimientos almacenados.

8.2.2 Tipos de permisos

Los permisos de Virtual DataPort se aplican a un usuario determinado para delimitar las acciones que le está permitido realizar sobre las bases de datos, vistas y procedimientos almacenados de un determinado servidor. Los permisos para un usuario pueden aplicarse de manera global sobre una base de datos o de manera particular sobre una vista o un procedimiento almacenado dentro de una base de datos particular. Los permisos sobre vistas y procedimientos almacenados particulares se aplican solo si el usuario no tiene el permiso correspondiente a nivel global. Denodo Virtual DataPort soporta los siguientes tipos de permisos globales sobre una base de datos:



• Permisos de lectura: Si un usuario dispone de este permiso sobre una base de datos a nivel global, puede

realizar las siguientes tareas sobre la misma: o Ver la lista de relaciones base, vistas y/o procedimientos almacenados de la base de datos (se

corresponde con el comando VQL LIST). Si un usuario no tiene permisos de lectura sobre una base de datos pero sí sobre alguna de sus vistas y/o procedimientos almacenados, el comando LIST podrá ejecutase pero sólo mostrará el conjunto de vistas y procedimientos sobre las que el usuario tiene permisos de lectura.

o Ver el esquema de cualquier relación base, vista o procedimiento almacenado de la base de datos (se corresponde con el comando VQL DESC).

o Ejecutar consultas sobre cualquier vista y/o procedimiento almacenado de la base de datos (se corresponde con el comando VQL SELECT).

• Permisos de creación: Si un usuario dispone de este permiso sobre una base de datos a nivel global, puede

realizar las siguientes tareas sobre la misma: o Creación de DataSources, vistas, relaciones base y procedimientos almacenados en la base de

datos (se corresponde con el comando VQL CREATE).

• Permisos de escritura. Disponer del permiso de escritura implica disponer también automáticamente del permiso de lectura. Si un usuario dispone de este permiso sobre una base de datos puede realizar sobre ella las siguientes tareas adicionales:

o Borrado de cualquier vista, relación base y/o procedimiento almacenado de la base de datos. También podrá borrar cualquier DataSource de la base de datos que haya sido creado por él pero no podrá borrar DataSources creados por otros usuarios (se corresponde con el comando VQL DROP).

o Modificación de cualquier vista, relación base y/o procedimiento almacenado de la base de datos. También podrá modificar cualquier DataSource de la base de datos que haya sido creado por él pero no podrá modificar DataSources creados por otros usuarios (se corresponde con el comando VQL ALTER).

• Permisos de conexión. Si un usuario dispone de este permiso sobre una base de datos entonces puede

conectarse a la misma, no pudiendo conectarse en caso contrario. Este tipo de permiso es útil si, por ejemplo, se desea revocar temporalmente el acceso de un usuario a una base de datos sin por ello tener que modificar el resto de sus privilegios habituales de forma manual.

Denodo Virtual DataPort también soporta la particularización de los privilegios a vistas y procedimientos almacenados concretos. Los tipos de permisos que pueden aplicarse a una vista y/o a un procedimiento almacenado de una base de datos son:

• Permisos de lectura: Si un usuario dispone de este permiso sobre una vista o procedimiento almacenado, puede realizar las siguientes tareas sobre dicho componente:

o Ver su esquema (se corresponde con el comando VQL DESC). o Ejecutar consultas sobre él (se corresponde con el comando VQL SELECT). o Crear nuevas vistas que lo utilicen, siempre que disponga de permisos de creación dentro de la

base de datos a la que pertenece. Se corresponde con el comando VQL CREATE VIEW. o Si un usuario no tiene permisos de lectura sobre una base de datos pero sí sobre alguna de sus

vistas y/o procedimientos, el comando LIST podrá ejecutase pero sólo mostrará dichos componentes.

• Permisos de escritura. Disponer del permiso de escritura implica disponer también automáticamente del

permiso de lectura. Si un usuario dispone de este permiso sobre una vista y/o procedimiento almacenado puede realizar sobre ella las siguientes tareas adicionales:

o Borrado del componente (se corresponde con el comando VQL DROP).



o Modificación del componente (se corresponde con el comando VQL ALTER). • Permisos de Inserción. Permite insertar tuplas en la vista (nunca un procedimiento almacenado) a través de

sentencias INSERT. • Permisos de Actualización. Permite actualizar tuplas de la vista (nunca un procedimiento almacenado) a

través de sentencias UPDATE. • Permisos de Borrado. Permite borrar tuplas de la vista (nunca un procedimiento almacenado) a través de

sentencias DELETE.

8.3 ADMINISTRACIÓN GRÁFICA DE BASES DE DATOS, USUARIOS Y PERMISOS

Para gestionar las bases de datos, usuarios y permisos de un servidor Virtual DataPort es necesario acceder a la herramienta de administración en modo de administración de servidor, lo que implica hacerlo con un usuario de tipo administrador (en este caso no es obligatorio especificar una base de datos en la uri de conexión al servidor). Al instalar el servidor se crea un usuario de administración por defecto cuyo nombre de usuario es admin y su contraseña es también admin. Las siguientes secciones describen, respectivamente, cómo crear nuevas bases de datos, cómo modificarlas o borrarlas, cómo crear nuevos usuarios y, finalmente, cómo modificar o borrar los usuarios existentes.

8.3.1 Creación de Bases de Datos

Para crear una nueva base de datos debe accederse a la pestaña “Databases Management” y pulsar el botón ‘new’.

Figura 80 Creación de una base de datos

La herramienta solicitará entonces los siguientes datos para la nueva base de datos (ver Figura 80):



• Nombre de la base de datos. • Descripción. Campo opcional para incluir una descripción de la base de datos.

8.3.2 Configuración y Borrado de Bases de Datos

Para ver la lista de bases de datos actuales del servidor Virtual DataPort debe accederse a la pestaña “Database Management” de la herramienta de administración Para cada base de datos se muestra su nombre y su campo descripción (ver Figura 81). El valor del campo descripción puede ser modificado pulsando el botón “edit”.

Figura 81 Descripción de una base de datos

Existen también una serie de botones que permiten efectuar diferentes acciones sobre la base de datos:

• Pulsando el botón “Assign privileges”, se mostrará una lista de todos los usuarios de Virtual DataPort que no sean de tipo administrador. Para cada usuario es posible especificar si el usuario dispone o no de permisos globales de conexión, creación, lectura y/o escritura sobre la base de datos (ver Figura 82).

• Los botones “i18n”, “Swap” y “Cache” permiten, respectivamente, cambiar la configuración de internacionalización (ver sección 5.1.5), las políticas de swapping (ver sección 5.1.4) y la configuración de la cache (ver sección 5.1.3) para la base de datos. En los tres casos, si se marca la casilla “Default Configuration”, se utilizará la configuración por defecto en el servidor.

• Pulsando el botón “Export VQL”, es posible exportar a un fichero VQL todos los metadatos de la base de datos, de forma que esta puede ser fácilmente recreada en otra instalación de Virtual DataPort. En el proceso de exportación no se incluirán los usuarios ni las asignaciones de permisos activas para la base de datos. Tampoco se incluirá la sentencia de creación de la base de datos.



Figura 82 Asignar privilegios sobre una base de datos

Por último, también es posible borrar la base de datos pulsando el botón “delete” (el sistema solicitará confirmación de la operación y, debido a lo delicado de la misma, se obligará a introducir nuevamente la contraseña del usuario). Nótese que al borrar una base de datos se eliminarán todos sus componentes: DataSources, vistas, relaciones base, etc.

8.3.3 Creación de usuarios

Para crear un usuario debe accederse a la pestaña “User Management” y pulsar el botón ‘New User’. La herramienta solicitará entonces los siguientes datos para el nuevo usuario (ver Figura 83):

• Login del usuario. • Descripción. Campo opcional para incluir una descripción del usuario. • Tipo de usuario: Los usuarios podrán ser de tipo Administrador o usuarios normales. • Tipo de autenticación. La autenticación del usuario podrá realizarse contra DataPort (opción “Normal”) o

contra un servidor LDAP dado de alta en DataPort (ver sección 6.5.6 para obtener información sobre cómo dar de alta un servidor LDAP). Dependiendo de la opción escogida, los datos a cumplimentar son diferentes

o En el caso “Normal”, se solicitará una password para el usuario. Será preciso escribirla dos veces para propósitos de comprobación.

o En el caso “LDAP”, será necesario proporcionar los siguientes datos (ver Figura 84): Servidor LDAP a utilizar. Debe especificarse la base de datos dónde se ha dado de alta

el servidor LDAP deseado utilizando el seleccionable “Database”. Una vez hecho esto, debe seleccionarse el servidor LDAP utilizando el seleccionable “Datasource”.

Usuario LDAP. Debe especificarse el nombre del usuario contra el que se realizará la autenticación en el servidor LDAP. Por ejemplo, el valor 'cn=test,ou=People,dc=denodo,dc=com’ identifica al usuario test en la unidad organizativa People del dominio denodo.com.



Figura 83 Creación de un usuario de tipo normal

NOTA: Si se elimina en cascada (ver sección 6.3.3) un datasource LDAP, los usuarios que dependen del mismo serán también eliminados (esta operación sólo pùede ser realizada por un usuario de tipo administrador).



Figura 84 Creación de un usuario de tipo LDAP

8.3.4 Modificación y Borrado de usuarios

Para ver la lista de usuarios actuales del servidor Virtual DataPort debe accederse a la pestaña “User Management” de la herramienta de administración. Para cada usuario se muestra su login, su campo descripción y su tipo (administrador o usuario normal). Ver Figura 85.



Figura 85 Descripción de un usuario

La descripción y la contraseña del usuario pueden ser modificadas pulsando el botón “edit”. Si el usuario no es de tipo Administrador, puede usarse la opción “Assign privileges” para modificar sus privilegios sobre las diversas bases de datos del sistema (ver sección 8.3.4.2). Desde la pantalla de lista de usuarios, también es posible borrar el usuario pulsando el botón “delete” (el sistema solicitará confirmación de la operación). No es posible borrar el administrador predefinido “admin”.

8.3.4.1 Cambio de contraseña del usuario activo

La contraseña del usuario activo puede también modificarse utilizando la opción ‘Change password’ del menú ‘File’ de la aplicación. Esta opción está disponible tanto en modo de administración de una base de datos como en modo de administración del servidor.

8.3.4.2 Modificación de los privilegios de un usuario

Para los usuarios que no sean de tipo administrador, es posible modificar sus privilegios sobre las diferentes bases de datos y vistas del sistema. Una vez que se ha accedido a la pantalla de edición de privilegios (ver Figura 86) de un usuario, aparece una lista de las bases de datos del servidor VDP. Para cada base de datos aparecen una serie casillas de verificación que permiten proporcionar al usuario permisos globales de conexión, lectura, creación y/o escritura para todas las relaciones base y vistas de la base de datos.



Figura 86 Asignación de privilegios a un usuario a nivel de base de datos

Si se desea configurar los permisos de una base de datos a nivel de vistas debe utilizarse la opción “Edit View Privileges” asociada a la base de datos. Entonces se accederá a una lista de las vistas y relaciones base contenidas en la base de datos seleccionada (ver Figura 87). Para cada vista o procedimiento almacenado, aparecerán casillas de verificación que permiten proporcionar al usuario permisos de lectura, escritura, inserción, actualización y/o borrado (estos tres últimos sólo para las vistas) sobre el componente. Es importante notar que si se ha marcado la casilla de verificación de un determinado permiso a nivel global en la base de datos, entonces se hará caso omiso de los permisos particulares asignados a nivel de vista.



Figura 87 Asignación de privilegios a un usuario a nivel de vista y/o procedimiento almacenado


Monitorización del servidor Dataport 119

9 MONITORIZACIÓN DEL SERVIDOR DATAPORT

Es posible acceder a información y eventos de monitorización del servidor DataPort utilizando el estándar Java Management eXtensions (JMX) [JMX]. Esta información puede ser utilizada, entre otros fines, para gestionar el uso del servidor y para auditar las acciones realizadas sobre los datos de las fuentes y/o los metadatos de DataPort. Entre la información de monitorización accesible se encuentra:

• Información general sobre el servidor, como por ejemplo el número de conexiones, activas o no, atendidas por el servidor o la cantidad de memoria ocupada.

• Información sobre la configuración y los accesos a la cache del servidor. • Información sobre los accesos a cada fuente de datos del sistema. • Información sobre los accesos a las vistas de cada base de datos de DataPort. • Información sobre las transacciones, activas o no, efectuadas sobre el servidor.

Además, DataPort genera diversos tipos de notificaciones accesibles a través de JMX cuando suceden eventos tales como:

• La ejecución de una sentencia de creación o modificación de metadatos, comúnmente llamadas sentencias DDL (e.g. ALTER TABLE, CREATE VIEW,…).

• La ejecución de una sentencia de consulta o actualización de datos, comúnmente llamadas sentencias DML (e.g. SELECT, INSERT,…).

• El comienzo o el fin de una transacción ejecutada en el servidor. En JMX, la información exportada se expone como un conjunto de objetos llamados MBeans. Los MBeans exportados por DataPort pertenecen al dominio JMX com.denodo.vdb.management.mbeans. Puede utilizarse cualquier cliente JMX para acceder a la información y los eventos de monitorización de DataPort. Las consolas JMX jConsole (incluida con el Java Developer Kit 1.5) y jManage [JMANAGE] han sido probadas exitosamente para acceder a la información y eventos exportados por el servidor DataPort. Para acceder a la información del servidor utilizando una de estas consolas, suele ser necesario especificar una URL para acceder al servidor. Por ejemplo, suponiendo que el servidor DataPort se ejecute localmente a la consola en el puerto 9999, la URL en la que se encontraría disponible el servidor DataPort sería:

service:jmx:rmi://localhost:9999/jndi/rmi://localhost:9999/jmxrmi También es posible acceder programáticamente a los mbeans utilizando la API JMX [JMX]. La subsección 9.1 proporciona información sobre cómo utilizar jConsole para acceder a DataPort. Las siguientes subsecciones describen en más detalle la información y eventos disponibles en cada una de las siguientes categorías: información general del servidor, información general sobre fuentes de datos, información general sobre la cache, información y eventos sobre sentencias DDL, información y eventos sobre sentencias DML e información y eventos sobre transacciones.

9.1 UTILIZANDO JCONSOLE

jConsole es una consola de administración de servidores conformes con la norma JMX que se distribuye con el Java Developer Kit a partir de su versión 1.5. En esta sección se introduce brevemente el uso de jConsole para acceder a la información y los eventos de monitorización de DataPort. Consúltese la documentación del Java Developer Kit para información detallada acerca del uso de jConsole [JCONSOLE].



Figura 88

Para ejecutar jConsole, basta utilizar el fichero ejecutable incluido con el Java Developer Kit. Por ejemplo, en sistemas Windows:

%JAVA_HOME%\bin\jconsole En la ventana de conexión a un agente, escoger la pestaña ‘Remote’, introducir los datos del servidor DataPort (máquina, puerto, nombre de usuario y contraseña), y pulsar el botón ‘Connect’. Debe utilizarse un usuario de tipo administrador.

Conexión a DataPort desde jConsole

Al conectarse al servidor, aparece diversa información que jConsole muestra por defecto para un agente monitorizado como, por ejemplo, el tiempo que el servidor ha estado levantado, o información sobre el número de threads y el uso de memoria por parte del proceso. La información específica del servidor DataPort se encuentra en la pestaña ‘MBeans’. En dicha pestaña se muestran a la izquierda de la pantalla los MBeans actualmente disponibles. La información de DataPort se ofrece a través de los MBeans del dominio com.denodo.vdb.management.mbeans.



Figura 89

j

MBeans de Virtual DataPort

La información y los eventos proporcionados por cada uno de los MBean disponibles en dicho paquete se describen en las siguientes secciones. En esta sección se mostrará solamente un ejemplo para ilustrar el uso de Console con DataPort. Ejemplo: Acceso a la información y eventos acerca de las conexiones activas y de las sentencias DDL. En la parte izquierda de la Figura 89, se muestran los MBeans que contienen la información sobre DataPort. Todos ellos cuelgan del dominio com.denodo.vdb.management.mbeans. En la parte derecha de la figura, se muestran también las propiedades del MBean com.denodo.vdb.management.mbeans:type=VDBServerManagementInfo (ver sección 9.2), que incluyen el número de conexiones activas y el número de conexiones totales desde que se inició el servidor. Los valores de las propiedades que pueden ser modificadas son mostrados por jConsole utilizando el color azul (e.g. el valor de la propiedad CompleteManagementActive aparece en azul). La información y los eventos acerca de sentencias DML (SELECT, INSERT, UPDATE, DELETE…) se encuentran accesibles a través de los MBeans que cuelgan de com.denodo.vdb.management.mbeans:type=RequestsManagementInfo (ver sección 9.6). Al hacer clic sobre dicho nombre, aparecerá una lista de las bases de datos existentes en el servidor DataPort. Al hacer clic sobre una de ellas, se accederá a información sobre las sentencias DML ejecutadas sobre dicha base de datos. Por ejemplo, la Figura 90 muestra información sobre las consultas ejecutadas sobre la base de datos admin.



Se muestra información tal como el número total de peticiones atendidas (propiedad TotalRequests) o el número de peticiones activas en ese momento (propiedad ActiveRequests). Pulsando el botón ‘Refresh’ la información de los atributos mostrados en la pantalla actual es refrescada consultando al servidor. Nótese, sin embargo, que cada nueva petición DDL sobre DataPort aparece como un nuevo atributo. Para que jConsole muestre nuevos atributos (y, por lo tanto, datos correspondientes a nuevas peticiones) es necesario acceder a la pantalla de otro MBean cualquiera y entonces volver a la pantalla original. Esto hará que jConsole cargue los nuevos atributos. Para ver los datos de cada petición puede hacerse doble clic en la celda ‘Value’ de la misma y se accederá a todos sus datos, como por ejemplo, el tipo de sentencia que se ha ejecutado (SELECT, INSERT,…), el usuario que la ejecutó, el momento en que lo hizo o la sentencia exacta ejecutada (ver Figura 91).

Figura 90 Pestaña Attributes del Mbean RequestsManagementInfo



Figura 91 Detalle de una consulta en jConsole

Continuando con el ejemplo, los eventos relacionados con sentencias DML de la base de datos admin pueden verse pulsando en la pestaña ‘Notifications’ y, a continuación, pulsando en el botón ‘Subscribe’. Desde ese momento, cada vez que en DataPort se ejecute una sentencia DML aparecerá una nueva notificación en jConsole. Haciendo doble clic sobre la celda ‘UserData’ de la misma, pueden verse los detalles de la sentencia ejecutada (ver Figura 92).



Figura 92 Detalle de una notificación en jConsole

9.2 INFORMACIÓN GENERAL SOBRE EL SERVIDOR

La información general sobre el servidor se accede a través de los MBeans com.denodo.vdb.management.mbeans:type=VDBServerManagementInfo y com.denodo.vdb.management.mbeans:type=MemoryManagementInfo. A continuación se describen las propiedades de cada uno de ellos:

• com.denodo.vdb.management.mbeans:type=VDBServerManagementInfo. o CompleteManagementActive: Esta propiedad es modificable por el usuario y puede

tomar los valores true o false. Si se fija su valor a true, se activa el modo de monitorización completa. En este modo, se calcula una estimacion de la memoria actual (propiedad TotalMemory del MBean MemoryManagementInfo) y el pico de memoria ocupada por una consulta (propiedad MaxMemory del MBean MemoryManagementInfo). La monitorización de estos parámetros es costosa, por lo que se aconseja activar este modo sólo en caso necesario.

o ServerName: (sólo lectura) URI del servidor DataPort ( e.g. //localhost:9999/VQLServer)

o TotalConnections: (sólo lectura) Numero total de conexiones abiertas contra el servidor desde que fue iniciado.

o ActiveConnections: (sólo lectura) Numero de conexiones activas en el momento actual.

• com.denodo.vdb.management.mbeans:type=MemoryManagementInfo. Los atributos de este MBean sólo se calculan si está activado el modo de monitorización completa (ver más arriba).

o TotalMemory. (sólo lectura) Estimación de la memoria total ocupada por el servidor. o MaxMemory. (sólo lectura) Estimación del pico de memoria ocupada alcanzado por el servidor

desde su inicio. Adicionalmente, el MBean com.denodo.vdb.management.mbeans:type=MemoryManagementInfo expone una operación que puede ser invocada por un cliente JMX:

• gc. Ejecuta el “garbage collector” del la máquina virtual JAVA sobre el servidor DataPort.

9.3 INFORMACIÓN GENERAL SOBRE DATASOURCES

La información general sobre fuentes de datos (data sources) se expone a través de los MBeans de la forma: com.denodo.vdb.management.mbeans:type=DataSourceManagementInfo,dataSourceType=<dstype>,dataSourceName=<dsname>. Donde <dstype> es el tipo de datasource (JDBC, ODBC, WS, XML,…) y <dsname> es el nombre del datasource. Para cada data source, su MBean expone las siguientes propiedades:

• DatabaseName. (sólo lectura) Nombre de la base de datos en la que se encuentra el datasource. • DataSourceName. (sólo lectura) Nombre del datasource. • DataSourceType: (sólo lectura) Tipo del datasource: JDBC, ODBC, XML, WS (Web services), DF

(ficheros delimitados), ARN (Aracne), GS (Google Mini), CUSTOM, LDAP, HTML. • NumRequests: (sólo lectura) Numero de peticiones ejecutadas sobre el datasource desde el inicio del

servidor. • ActiveRequests: (sólo lectura) Numero de peticiones sobre el datasource activas en el momento

actual.

9.4 INFORMACIÓN SOBRE LA CACHE

La información general sobre el servidor se accede a través de los MBeans de la forma: com.denodo.vdb.management.mbeans:type=Cache,databaseName=<dbname>,subtype=DatabaseCache donde <dbname> especifica el nombre de una base de datos DataPort. y com.denodo.vdb.management.mbeans:type=Cache,databaseName=<dbname>,subtype=ViewCache,viewName=<vname> donde <dbname> especifica el nombre de una base de datos DataPort y <vname> especifica el nombre de una vista de dicha base de datos. A continuación se describen las propiedades de cada uno de estos dos subtipos:

• subtype=DatabaseCache. Para cada base de datos DataPort se exponen las siguientes propiedades:

o DatabaseName. (sólo lectura) Nombre de la base de datos. o CacheStatus. (sólo lectura) Estado de la cache (ON/OFF/POST). o UserName. Nombre del usuario en el datasource asociado a la base de datos utilizada como

cache. o UserPwd. Contraseña del usuario en el datasource asociado a la cache de la base de datos. o DriverClassName. Clase del driver JDBC en el datasource asociado a la base de datos

utilizada como cache. o LastCacheAccessStatus: (sólo lectura) Indica si el ultimo acceso a la base de datos de

la cache fue exitoso (true) o no (false). o CustomDataSource: (sólo lectura) Indica si la base de datos utilizada como cache emplea

(true) o no (false) un datasource diferente del utilizado por defecto por el servidor DataPort o DBURI: (sólo lectura) URI de conexion a la base de datos utilizada como cache.

• subtype=ViewCache. Para cada vista (viewName) de cada base de datos (databaseName) se exponen las siguientes propiedades:

o DatabaseName(RO). (sólo lectura) Nombre de la base de datos DataPort a la que pertenece la vista.

o ViewName. (sólo lectura) Nombre de la vista o CacheStatus. Estado de la cache de la vista (ON/OFF/POST). o TTLInCache. Tiempo de vida de los datos en la cache de la vista. o LastAccess. (sólo lectura) Momento del último acceso a la cache de la vista. o LastRefresh. (sólo lectura) Momento en el que se escribiron nuevas tuplas por última vez

en la cache de la vista. o RefreshFailuresCount. (sólo lectura) Numero de fallos contabilizados en los accesos

para escribir nuevas tuplas en la cache de la vista.

9.5 INFORMACIÓN Y EVENTOS SOBRE EL ACCESO AL CATÁLOGO (SENTENCIAS DDL)

La información y eventos sobre el acceso a la información del catálogo (sentencias DDL) se exponen a través de los MBeans de la forma: com.denodo.vdb.management.mbeans:type=CatalogManagementInfo,databaseName=<dbname> donde <dbname> especifica el nombre de una base de datos DataPort. Los MBeans de este tipo ofrecen una única propiedad (de sólo lectura) llamada DatabaseName y que indica el nombre de la base de datos. Al subscribirse al MBean de una base de datos determinada, se recibirá una notificación cada vez que ocurra uno de los siguientes eventos:

• Comienza una transacción. • Se ejecuta una sentencia que afecta a los metadatos de la base de datos. • Finaliza una transacción.

En cada notificación aparecen los siguientes campos:

• Timestamp. Momento en el que se genera la notificación de la sentencia en el servidor JMX. • Type: Indica si la notificación se refiere al comienzo de una transacción (‘startTransaction’),

al fin de una transacción (‘endTransaction’) o a la ejecución de una sentencia de acceso al catálogo (‘newEvent’).

• UserData: Elemento compuesto. Sus subpropiedades dependen del tipo de notificación: o Ejecución de sentencia:

DatabaseName: Nombre de la base de datos DataPort sobre la que se ejecuta la sentencia.

UserName: Identificador del usuario que ejecuta la sentencia. EventID: Identificador de la notificación generado por DataPort. Los identificadores

se asignan utilizando un contador. TransactionID: Identificador de la transacción dentro de la cuál se ejecuta la

sentencia. Time: Momento de ejecución de la sentencia de acuerdo al servidor DataPort. VQLQuery: Código VQL de la sentencia.

o Comienzo de transacción: Autostarted: Indica si la transacción ha sido creada explícitamente por el

usuario. Todas las sentencias que modifican el catálogo de DataPort deben ejecutarse dentro de una transacción. Por lo tanto, si el usuario no la ha creado, DataPort la creará por sí mismo.

DatabaseName: Nombre de la base de datos DataPort sobre la que se inicia la transacción.

UserName: Identificador del usuario que inicia la transacción. EventID: Identificador de la notificación generado por DataPort. Los identificadores

se asignan utilizando un contador. TransactionID: Identificador asignado a la transacción que comienza. Time: Momento de inicio de la transacción de acuerdo al servidor DataPort. ,

o Finalización de transacción: DatabaseName: Nombre de la base de datos DataPort sobre la que se ejecuta la

transacción. UserName: Identificador del usuario que ejecuta la transacción. Status: Estado de finalización de la transacción (COMMIT o ROLLBACK). EventID: Identificador de la notificación generado por DataPort. Los identificadores

se asignan utilizando un contador. TransactionID: Identificador asignado a la transacción que finaliza.

o Time: Momento de inicio de la transacción de acuerdo al servidor DataPort. • SeqNum: Número de secuencia generado por DataPort para la notificación. Normalmente los números de

secuencia se asignan utilizando un contador., • Message:

o Si se notifica la ejecución de una sentencia: Processed the <event eventId> in transaction <transactionId>.

o Si se notifica el comienzo de una transacción: Started the transaction <transactionId>.

o Si se notifica el fin de una transacción: Finished the transaction <transactionId>.

• Event: Será de la forma javax.management.Notification[com.denodo.vdb.management.mbeans:type=CatalogManagementInfo,databaseName=<dbName>][type=<eventType>][message=<eventmessage>], donde <dbName> es el nombre de la base de datos DataPort, <eventType> es startTransaction, endTransaction o newEvent y <eventmessage> toma el mismo valor que en la propiedad Message.

• Source: Nombre del MBean.

9.6 INFORMACIÓN Y EVENTOS SOBRE LA EJECUCIÓN DE SENTENCIAS DML

La información y eventos sobre la ejecución de sentencias DML se exponen a través de los MBeans de la forma: com.denodo.vdb.management.mbeans:type= RequestsManagementInfo,databaseName=<dbname> donde <dbname> especifica el nombre de una base de datos DataPort. Para cada base de datos se exponen las siguientes propiedades:

• DatabaseName: (sólo lectura) Nombre de la base de datos DataPort. • MaxRequests: Numero maximo de peticiones que se exportarán simultáneamente en el MBean.

Cada petición aparece como un atributo de la forma Request. • TotalRequests: (sólo lectura) Numero total de peticiones contabilizadas desde el inicio del servidor. • ActiveRequests: (sólo lectura) Numero de peticiones activas (que no han finalizado). • Request : (sólo lectura) Por cada petición ejecutada aparecerá un nuevo atributo de tipo

compuesto con las siguientes subpropiedades: o Identifier: Identificador de la transacción. Normalmente los identificadores se asignan

utilizando un contador. o DatabaseName: Nombre de la base de datos DataPort sobre la que se ejecuta la sentencia. o UserName: Identificador del usuario que ejecuta la sentencia. o Cache: toma el valor true si la consulta ha accedido a la cache durante su ejecución y el

valor false en caso contrario. o Memory. Estimación de la memoria consumida por la sentencia. Sólo disponible si está

activada la propiedad CompleteManagementActive del MBean com.denodo.vdb.management.mbeans:type=VDBServerManagementInfo

o MaxMemory. Estimación del pico de memoria consumida por la consulta. Sólo disponible si está activada la propiedad CompleteManagementActive del MBean com.denodo.vdb.management.mbeans:type=VDBServerManagementInfo.

o StartTime: Momento en el que comenzó la ejecución de la sentencia. o EndTime: Momento en el que finalizó la ejecución de la sentencia. o RequestType: Indica el tipo de sentencia. Puede tomar los siguientes valores: SELECT

BASE VIEW, SELECT VIEW, QUERY WRAPPER, CALL STOREDPROCEDURE, INSERT, UPDATE

o State: Puede tomar los valores: OK, ERROR o PROCESSING. o Swap: toma el valor true si el servidor ha necesitado hacer swapping a disco de resultados

intermedios durante la ejecución de la consulta y el valor false en caso contrario. o VQLQuery: Código VQL de la sentencia.

Además, los mbeans de este tipo permiten también subscribirse a notificaciones. Cada vez que una sentencia DML sea ejecutada sobre la base de datos especificada, se recibirá una notificación con los siguientes datos:

• Timestamp. Momento en el que se genera la notificación de la sentencia en el servidor JMX. • Type: Este tipo de notificaciones llevan como indicador de tipo la cadena ‘endRequest’. • UserData: Elemento compuesto. Sus subpropiedades son las mismas que las de la propiedad

Request descrita anteriormente. • SeqNum: Número de secuencia generado por DataPort para la notificación. Normalmente los números de

secuencia se asignan utilizando un contador. • Message: En este tipo de notificaciones lleva el valor ‘Finished the request’.

• Event: Será de la forma javax.management.Notification[source=com.denodo.vdb.management.mbeans:type=RequestsManagementInfo,databaseName=<dbname>][type=endRequest][message=Finished the request ''], donde <dbName> es el nombre de la base de datos DataPort, e es el identificador de la sentencia.

• .Source: Nombre del MBean.

9.7 INFORMACIÓN Y EVENTOS SOBRE TRANSACCIONES

La información y eventos sobre la ejecución de transacciones se exponen a través de los MBeans de la forma: com.denodo.vdb.management.mbeans:type= TransactionsManagementInfo,databaseName=<dbname> donde <dbname> especifica el nombre de una base de datos DataPort. Para cada base de datos se exponen las siguientes propiedades:

• DatabaseName: (sólo lectura) Nombre de la base de datos DataPort. • MaxTransactions: Numero maximo de peticiones que se exportarán simultáneamente en el

MBean. Cada transacción aparece como un atributo de la forma Transaction. • TotalTransactions: (sólo lectura) Numero total de transacciones contabilizadas desde el inicio

del servidor. • ActiveTransactions: (sólo lectura) Numero de peticiones activas (que no han finalizado). • Transaction : (sólo lectura) Por cada transacción ejecutada aparecerá un nuevo atributo de

tipo compuesto con las siguientes subpropiedades: o Identifier: Identificador de la transacción. Normalmente los identificadores se asignan

utilizando un contador. o DatabaseName: Nombre de la base de datos DataPort sobre la que se ejecuta la transacción. o UserName: Identificador del usuario que ejecuta la transacción. o Autostarted: Indica si la transacción ha sido creada explícitamente por el usuario (true).

Todas las sentencias que modifican el catálogo de DataPort deben ejecutarse dentro de una transacción. Por lo tanto, si el usuario no la ha creado, DataPort la creará por sí mismo y en ese caso el valor de esta propiedad será false.

o StartTime: Momento en el que comenzó la transacción. o EndTime: Momento en el que finalizó la transacción. o State: Indica el estado con el que terminó la transacción. Puede tomar los valores:

ROLLBACK o COMMIT. Además, los MBeans de este tipo permiten también subscribirse a notificaciones. Cada vez que una transacción comience o finalice sobre la base de datos especificada, se recibirá una notificación con los siguientes datos:

• Timestamp. Momento en el que se genera la notificación en el servidor JMX. • Type: Este tipo de notificaciones llevan como indicador de tipo la cadena ‘startTransaction’ o

‘endTransaction’, según la notificación indique el inicio o el fin de una transacción. • UserData: Elemento compuesto. Sus subpropiedades son las mismas que las de la propiedad

Transaction descrita anteriormente. • SeqNum: Número de secuencia generado por DataPort para la notificación. Normalmente los números de

secuencia se asignan utilizando un contador.

• Message: Si la notificación indica el comienzo de una transacción, toma el valor ‘Started the transaction’. Si indica el fin de una transacción, toma el valor ‘Finished the transaction’.

• Event: Será de la forma javax.management.Notification[source=com.denodo.vdb.management.mbeans:type=TransactionsManagementInfo,databaseName=<dbname>][type=<type>][message=<msg>], donde <dbName> es el nombre de la base de datos DataPort, <type> es el tipo de la notificación (‘startTransaction’ o ‘endTransaction’) y <msg> es el mensaje de la notificación (‘Started the transaction’ o ‘Started the transaction’).

• Source: Nombre del MBean.


Arquitecturas en cluster / Backup de Servidores 131

10 ARQUITECTURAS EN CLUSTER / BACKUP DE SERVIDORES

DataPort puede funcionar dentro de una arquitectura en cluster, para proporcionar tolerancia a fallos y balanceo de carga entre servidores. Típicamente, una arquitectura de clustering para DataPort funciona de la siguiente forma:

1. Un sistema de clustering externo distribuye las peticiones recibidas entre un pool de servidores DataPort. 2. El sistema de clustering detecta (utilizando un chequeo llamado comunmente ‘comprobación de salud del

servidor’) cuando un servidor no está respondiendo. En ese caso, la carga se distribuye entre los restantes servidores.

3. Cuando el servidor vuelve a estar disponible, el sistema de clustering lo detecta (utilizando otra vez la ‘comprobación de salud’), y lo añade de nuevo al pool.

DataPort ha sido validado utilizando las siguientes soluciones de clustering:

• Linux Virtual Server architecture [LVS], utilizando Keepalived [KALV] para comprobar si un servidor está respondiendo en un momento dado..

• Windows 2000 Network Load Balancing Tool [WNLB]. Esta es la solución de clustering incluida en la familia de servidores Windows 2000.

DataPort proporciona diversas facilidades para facilitar la configuración de arquitecturas de cluster:

• DataPort proporciona un script ‘PING’ para comprobar el estado de un servidor DataPort. Si bien soluciones como Keepalived proporcionan sus propias implementaciones por defecto para ‘comprobar la salud’ de una aplicación, el script PING proporcionado por DataPort permite detectar situaciones de fallo del servidor que no serían detectadas por las comprobaciones por defecto.

• DataPort proporciona una utilidad para replicar fácilmente de forma automática los metadatos y la configuración de un servidor DataPort en un pool de otros servidores DataPort. Esta utilidad puede ser utilizada también para programar la realización de copias de seguridad (backups) de los metadatos de un servidor DataPort.

Las siguientes secciones describen, respectivamente, como instalar las utilidades de ayuda a la configuración de entornos de clustering, como utilizar el script PING y como usar la utilidad para replicar los metadatos de un servidor DataPort en un conjunto de otros servidores.

10.1 INSTALACIÓN DE LAS UTILIDADES

Las utilidades se encuentran en la ruta %DENODO_HOME%\tools. Se ofrecen comprimidas en un fichero denominado denodo-vdp-cluster-tools-4.0.1 que se encuentra disponible tanto en formato .zip como en formato .tar.gz.

10.2 USO DEL SCRIPT PING

El script ping se encuentra disponible en el directorio bin de la distribución de las utilidades. Se ofrece en dos versiones: ping.sh (para sistemas Linux) y ping.bat (para sistemas Windows). El formato de invocación del script es el siguiente: ping [-t timeout] [-v] [//]host[:port]



donde host es la máquina donde reside el servidor DataPort cuyo estado se desea comprobar y port es el puerto en el cuál se ejecuta (si no se especifica, se asume el puerto 9999), timeout es el tiempo máximo (en milisegundos) que se desea esperar por la respuesta del servidor. La opción –v muestra por la salida estándar el estado del servidor y el tiempo tardado en recibir una respuesta del mismo. El script ping devuelve el valor 0 si la comprobación de estado es exitosa y un valor distinto de cero en otro caso. A continuación, se muestra un ejemplo de ejecución del comando ping: ping -t 5000 -v //localhost:9999/ Este comando comprueba el estado del servidor DataPort que se está ejecutando en la máquina local en el puerto 9999. Se espera un máximo de 5 segundos por la respuesta del servidor y se muestra el resultado de la comprobación por la salida estándar.

10.3 USO DE LOS SCRIPTS IMPORT / EXPORT PARA BACKUP Y/O REPLICACIÓN

Los scripts import y export se encuentran disponibles en el directorio bin de la distribución de las utilidades. Se ofrecen en dos versiones: import.sh y export.sh (para sistemas Linux) y import.bat y export.bat (para sistemas Windows). El script export permite exportar los metadatos de un servidor DataPort a un fichero. Es posible exportar todos los metadatos y la configuración del servidor o sólo los metadatos y configuración de una base de datos DataPort especificada. Los metadatos exportados son los mismos que cuando se utilizan las opciones equivalentes de la herramienta de administración (ver secciones 5.3 y 8.3.2). El formato de invocación del script es el siguiente: export –l login -p password –u host[:port]/database [-d database] –f outputFilename donde: -l login indica el nombre de usuario con el que se realizará la conexión al servidor. El usuario debe tener permisos suficientes para la acción a ejecutar. -p password indica la contraseña con la que se realizará la conexión al servidor. -u uri. URI de conexión al servidor DataPort. Es necesario especificar una base de datos contra la que se autenticará el usuario. Si no se especifica puerto, se asume el 9999. -d,database especifica una base de datos cuyos metadatos se exportarán. Si no se especifica la opción –d, se exportarán los contenidos completos del servidor. –f outputFilename indica el nombre del fichero al que se exportarán los metadatos. A continuación, se muestra un ejemplo de ejecución del comando export: export -l admin -p admin -u //localhost:9999/admin -f serverexport.vql Este comando exporta los metadatos completos del servidor DataPort que se está ejecutando en la máquina local en el puerto 9999. El acceso al servidor se realiza con el usuario admin con password admin. El resultado de la exportación se guarda en un fichero llamado serverexport.vql. El script import permite importar los metadatos contenidos en un fichero obtenido mediante la utilidad export en una lista de servidores DataPort, identificados por su URI. La lista de servidores puede proporcionarse por línea de



comando o puede incluirse en un fichero. De esta forma, es posible tanto restaurar una copia de seguridad realizada con export como replicar los metadatos de un servidor DataPort en una lista de servidores en cluster. El formato de invocación del script es el siguiente: import -f path-to-file [-s servers-file | -l server (-l server)*] donde: -f path-to-file es el fichero conteniendo los metadatos a importar. -l server especifica la URI de un servidor en el cuál importar los metadatos. La URI debe ser de la forma [//]host[:port]/database?user@password donde host y port identifican la máquina y el puerto donde se ejecuta el servidor (el puerto por defecto es el 9999), database especifica la base de datos contra la que se realizará la autenticación, user especifica el nombre de usuario con el que conectarse al servidor y password indica su contraseña. -s servers-file especifica el nombre de un fichero que contiene las URIs de los servidores en los que importar los metadatos. Cada URI debe aparecer en una línea del fichero en el mismo formato utilizado para las URIs del parámetro –l. Por ejemplo: import -f export.vql -l localhost/admin?admin@admin1 -l host2:9099/admin?admin@admin2 importa los metadatos contenidos en export.vql en los servidores que se están ejecutando en la máquina local en el puerto 9999 y en la máquina llamada host2 en el puerto 9099. En ambos casos la autenticación se realiza contra la base de datos admin y utilizando el usuario del mismo nombre. La contraseña en el primer servidor es admin1 y en el segundo es admin2. import -f export.vql -s servers.conf importa los metadatos contenidos en export.vql en los servidores cuyas URIs se especifiquen en el fichero servers.conf.


Apéndices 134

11 APÉNDICES

CLIENTE DE LÍNEA DE COMANDOS

Virtual DataPort proporciona un cliente de línea de comandos. Dicho cliente permite al usuario introducir sentencias expresadas en VQL, que definen y/o modifican elementos del diccionario de datos y/o emiten consultas sobre el gestor. El cliente interfaz de comandos se denomina vqls (vqls.bat para entornos Windows y vqls.sh para entornos UNIX/Linux). También puede iniciarse utilizando el acceso directo ‘Start Virtual DataPort Command Line Shell’ creado durante la instalación. Este cliente proporciona también un conjunto de sentencias propias que permiten realizar operaciones sobre el propio cliente. Las sentencias locales que contiene el cliente de línea de comandos son: LHELP, EXIT, LSET y LOAD. El comando LHELP permite al usuario solicitar ayuda sobre los comandos locales del cliente. Si no recibe ningún parámetro, hará un listado de todos los comandos locales. Opcionalmente puede recibir el nombre de un comando local específico, en cuyo caso, mostrará su sintaxis. El comando EXIT permite finalizar la sesión en el cliente vqls. El comando local LSET, cuya sintaxis se muestra en la Figura 93, permite modificar los parámetros de configuración del cliente (cuyos valores por defecto, estarán especificados en el fichero de configuración VDBConfiguration.properties). Normalmente será necesario modificar estos parámetros para especificar el servidor DataPort contra el que deseamos ejecutar sentencias VQL. Los parámetros configurables a través del comando LSET son:

• Nombre del usuario (user). Se podrá modificar el usuario que se utiliza en el proceso de conexión con el servidor.

• Contraseña del usuario (password). El comando permitirá cambiar la clave de acceso del usuario que se utiliza en el proceso de autenticación con el servidor.

• URI al servidor. El formato de la uri del servidor es el siguiente: //nombre_maquina:puerto/base_de_datos dónde:

o nombre_maquina es el nombre de la máquina dónde reside el servidor. o puerto es el número del puerto de ejecución del servidor o base_de_datos (opcional) es la base de datos de Virtual DataPort a la que se desea

conectar. Si no se especifica, el sistema se conectará sólo para labores de administración del servidor, siempre que el usuario escogido sea de tipo administrador ( ver sección 4.1).

• Timeout de una consulta. El límite de tiempo, expresado en milisegundos, que está dispuesto a esperar el usuario hasta que finalice una consulta, antes de forzar su finalización.

Apéndices 135

• Timeout de un chunk o un resultado parcial. Máximo tiempo que está dispuesto a esperar el usuario entre la llegada desde el servidor de dos bloques consecutivos del resultado a la consulta.

• Tamaño de un chunk o un resultado parcial. Máximo número de tuplas que está dispuesto a esperar el usuario entre la llegada desde el servidor de dos bloques consecutivos del resultado de una consulta.

LSET <var> <value> <var>={ user | password | URL | querytimeout | chunktimeout | chunksize}

Figura 93 Sintaxis de la sentencia LSET

El comando local LOAD permite cargar un fichero local de sentencias y ejecutarlas sobre el gestor, almacenando en un fichero o en la salida estándar los resultados obtenidos. Las sentencias contenidas en el fichero deben finalizar con el carácter ‘;’, y deben separarse entre sí por una línea con el texto ‘#END-SENTENCE’. Pueden utilizarse líneas de comentario prefijadas con ‘//’. La sentencia LOAD recibe dos parámetros. El primero indica la ruta del fichero local que contiene las sentencias a ejecutar, y el segundo parámetro, de carácter opcional, el nombre del fichero en el que se desean guardar los resultados. Por otro lado, el usuario podrá ejecutar en el intérprete de línea de comandos, sentencias del lenguaje de definición y manejo de datos de Virtual DataPort. Un comando particularmente importante de este lenguaje es el comando HELP, que se utiliza para mostrar la sintaxis de todas las sentencias pertenecientes al lenguaje de definición y manejo de datos VQL (para más información sobre estas sentencias, véase la Guía Avanzada de VQL [VQL]). Las sentencias que interpreta el cliente de linea de comandos, deben finalizar por el carácter ‘;’ seguido de un carácter ‘\n’ y/o ‘\r’. Además, a diferencia de las sentencias que interpreta el comando LOAD, no pueden estar separadas por #END-SENTENCE y no admiten la utilización de comentarios. Cuando el usuario realiza una consulta sobre una o varias relaciones (ya sean relaciones base o vistas derivadas) del gestor, el cliente emite la consulta contra el servidor, y como resultado el servidor envía al cliente las tuplas resultado de la consulta, agrupadas en ckunks o resultados parciales. El cliente de línea de comandos mostrará al usuario los resultados a medida que los va recibiendo del servidor, sin esperar a que todos estén disponibles (esto es, de forma asíncrona).

DRIVERS JDBC

La siguiente tabla muestra los drivers JDBC incluidos con DataPort 3.1. Para cada driver se muestran las bases de datos para las que ha sido probado conjuntamente con DataPort, el nombre de la clase que debe especificarse al importar un datasource JDBC que utilice dicho driver y el formato de URI utilizado. Base de datos Clase URI Oracle 8i Oracle 9i Oracle 10g

oracle.jdbc.OracleDriver jdbc:oracle:<<protocol>>:@<<hostName>>:<<port>>:<<databaseName>> Protocolos: thin (recomendado), oci, oci8, kprb

PostgreSQL 7.2.3 PostgreSQL 7.4.6 PostgreSQL 8

org.postgresql.Driver jdbc:postgresql://<<hostName>>:<<port>>/<<databaseName>>

SQL Server 8.00.194 net.sourceforge.jtds.jdbc.Driver jdbc:jtds:sqlserver://<<hostName>>:<<port>>/<<DatabaseName>>

Sybase Adaptive Server Enterprise 12.5B

net.sourceforge.jtds.jdbc.Driver jdbc:jtds:sybase://<<hostName>>:<<port>>/<DatabaseName>>

Apéndices 136

Tabla 2 Drivers JDBC

Los drivers para MySQL e IBM DB2 así como los drivers creados por sus fabricantes para Microsoft SQL Server y Sybase, no están incluidos en la distribución de DataPort pero pueden ser descargados de los sitios web de dichas empresas. También han sido probados exitosamente con DataPort. Los datos relativos a estos drivers se muestran en la siguiente tabla: Base de datos Clase URI MySQL 4.0.15 MySQL 4.1.1

com.mysql.jdbc.Driver jdbc:mysql://<<hostName>>:<<port>>/<<databaseName>>

DB2 8.2 com.ibm.db2.jcc.DB2Driver jdbc:db2://<<hostName>>:<<port>>/<<databaseName>>

SQL Server 8.00.194 com.microsoft.jdbc.sqlserver.SQLServerDriver

jdbc:microsoft:sqlserver://<<hostName>>;DatabaseName=<<databaseName>>

Sybase Adaptive Server Enterprise 12.5B

com.sybase.jdbc3.jdbc.SybDriver jdbc :sybase:Tds:/<<hostName>>/:/<<port>>/<<database>>

Tabla 3 Drivers MySQL, IBM, Microsoft y Sybase

Si bien cualquier otro driver JDBC debería funcionar conjuntamente con DataPort, los presentes en las listas anteriores han sido probados exitosamente al importar un datasource JDBC. Como ya se ha comentado en la sección 5.1.3, en el caso de utilizar una configuración de Virtual DataPort con sistema caché, es necesario configurar el Gestor de Base de Datos a utilizar. Las versiones con las que se ha probado exitosamente la caché son: PostgreSQL 7.4.6 y 8.0.0, Oracle: 8i, 9i, 10g y MySQL 4.1, 5 (cuyo driver no se incluye en la distribución de DataPort). Para utilizar un driver JDBC no incluido con la distribución de DataPort puede seguirse uno de los siguientes procedimientos: • Instalar el driver en una ruta incluida en la variable de entorno $DENODO_EXTERNAL_CLASSPATH o en la ruta

DENODO_HOME/extensions/dev/target/classes (donde DENODO_HOME es la ruta base de la instalación de DataPort).

• Al crear un nuevo DataSource JDBC, especificar directamente el fichero .jar del driver deseado (ver sección 6.3.1).


Bibliografía 137

BIBLIOGRAFÍA

[ARCN] Guía de Administración de Denodo Aracne 4.0. Denodo Technologies 2007.

[AXIS] Apache Axis. Apache Software Foundation. http://ws.apache.org/axis/

[DEV] Guía del Desarrollador de Denodo Virtual DataPort 4.0. Denodo Technologies 2007.

[FED] The Fedora Project. RedHat Corporation and the Fedora Community. http://fedora.redhat.com/

[GMINI] Google Mini. http://www.google.com/enterprise/mini/

[GSEARCHLANG] Lenguajes soportados por Google Mini. http://code.google.com/enterprise/documentation/xml_reference.html#request_subcollections_auto

[ITPILOT] Manual de Usuario de Denodo ITPilot 4.0. Denodo Technologies 2007.

[JDBC] Java DataBase Connection Technology. Sun Microsystems. http://java.sun.com/products/jdbc/

[JCONSOLE] Using JConsole. http://java.sun.com/j2se/1.5.0/docs/guide/management/jconsole.html

[JMANAGE] jManage: Open Source Application Management. http://www.jmanage.org/

[JMX] Java Management eXtensions (JMX). http://java.sun.com/javase/technologies/core/mntr-mgmt/javamanagement/

[KALV] KeepAlived. Health Checking for LVS & High Availability. http://www.keepalived.org/

[LOG4J] The Log4j Project. Apache Software Foundation. http://logging.apache.org/log4j/docs/

[LVS] Linux Virtual Server Architecture. http://www.linuxvirtualserver.org/

[MYSQL] MySQL Open Source Database. http://www.mysql.com/

[NSEQL] Guía de NSEQL de Denodo ITPilot 4.0. Denodo Technologies Corporation 2007.

[ORCL] Oracle Database. Oracle Corporation. http://www.oracle.com/database/index.html

[POSQL] PostgreSQL Open Source Database. http://www.postgresql.org/

[TOM] Apache Jakarta Tomcat. The Apache Software Foundation. http://jakarta.apache.org/tomcat/

[VQL] Guía Avanzada de VQL de Denodo Virtual DataPort 4.0. Denodo Technologies 2007.

[WIND] Familia de Sistemas Operativos Windows. Microsoft Corporation. http://www.microsoft.com/windows/default.mspx

[WNLB] Network Load Balancing with Windows 2000 Advanced Server http://www.microsoft.com/technet/prodtechnol/windows2000serv/support/nlbcontb.mspx

[WSDL] Web Services Description Language (WSDL). http://www.w3.org/TR/wsdl

[XA] X/Open Company Ltd. Distributed Transaction Processing: The XA Specification. The Open Group, February 1992.

http://fedora.redhat.com/

http://java.sun.com/products/jdbc/

http://java.sun.com/javase/technologies/core/mntr-mgmt/javamanagement/

http://java.sun.com/javase/technologies/core/mntr-mgmt/javamanagement/

http://logging.apache.org/log4j/docs/

http://www.linuxvirtualserver.org/

http://www.postgresql.org/

http://www.postgresql.org/

http://www.microsoft.com/windows/default.mspx

http://www.w3.org/TR/wsdl

virtual dataport 4.0 guÍa del...

Documents