VIRTUAL DATAPORT 4.0 GUÍA AVANZADA DE VQL

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 Avanzada de VQL

ÍNDICE

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

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

2 VIRTUAL DATAPORT A VISTA DE PÁJARO....................................................................................... 3 2.1 CREACIÓN O DEFINICIÓN DE DATOS ................................................................................................ 3

2.1.1 Definición de relaciones base................................................................................................................... 3 2.1.2 Definición de datasources y wrappers ..................................................................................................... 5 2.1.3 Definición de las vistas del esquema global ............................................................................................ 6

2.2 EJECUCIÓN DE SENTENCIAS.............................................................................................................. 7

3 CARACTERÍSTICAS................................................................................................................................ 9 3.1 TIPOS DE DATOS ................................................................................................................................... 9 3.2 INTERNACIONALIZACIÓN.................................................................................................................. 10 3.3 CAPACIDADES DE CONSULTA.......................................................................................................... 11 3.4 REGLAS DE REESCRITURA................................................................................................................. 11

4 LENGUAJE DE DEFINICIÓN Y MANEJO DE DATOS: VQL ............................................................. 12 4.1 SENTENCIAS ........................................................................................................................................ 12 4.2 SENTENCIA SELECT: CLÁUSULAS.................................................................................................... 13 4.3 INSERT / UPDATE /DELETE: CLÁUSULAS........................................................................................ 13 4.4 OPERADORES LÓGICOS...................................................................................................................... 14 4.5 OPERADORES DE COMPARACIÓN ................................................................................................... 15 4.6 FUNCIONES DE ATRIBUTO DERIVADO Y CONDICIONES............................................................. 18

4.6.1 Funciones Aritméticas............................................................................................................................. 18 4.6.2 Funciones de Manejo de Texto............................................................................................................... 19 4.6.3 Funciones de Manejo de Fechas............................................................................................................. 21 4.6.4 Funciones de Conversión de Tipos.......................................................................................................... 22 4.6.5 Funciones de manejo de XML................................................................................................................. 23 4.6.6 Otras funciones ....................................................................................................................................... 24

4.7 FUNCIONES DE AGREGACIÓN .......................................................................................................... 25 4.8 CONVENCIONES DE SINTAXIS ......................................................................................................... 26

4.8.1 Sintaxis de funciones y valores de condiciones ..................................................................................... 28

5 CREACIÓN DE UNA RELACIÓN BASE (O VISTA BASE)................................................................. 30 5.1 MODIFICACIÓN DE UNA RELACIÓN BASE ..................................................................................... 30 5.2 CAPACIDADES DE CONSULTA: MÉTODOS DE BÚSQUEDA Y WRAPPERS............................... 32

5.2.1 Restricciones de Consulta....................................................................................................................... 32 5.2.2 Asignación de Wrappers a Métodos de Búsqueda ................................................................................ 33 5.2.3 Ejemplo de Creación de un Método de Búsqueda.................................................................................. 33

5.3 REGLAS DE REESCRITURA................................................................................................................. 34 5.3.1 Reglas de Reescritura de Entrada........................................................................................................... 34 5.3.2 Reglas de Reescritura de Salida............................................................................................................. 37


6 CONSULTAS: SENTENCIA SELECT ................................................................................................... 39

6.1 CLÁUSULA FROM................................................................................................................................. 41 6.1.1 Operaciones de join ................................................................................................................................ 41 6.1.2 FLATTEN VIEW (Aplanando estructuras de datos) ................................................................................. 42

6.2 CLÁUSULA SELECT.............................................................................................................................. 43 6.2.1 Atributos Derivados ................................................................................................................................ 44

6.3 CLÁUSULA WHERE.............................................................................................................................. 44 6.3.1 Condiciones con valores compuestos..................................................................................................... 45

6.4 CLÁUSULA GROUP BY ........................................................................................................................ 45 6.4.1 Uso de Funciones de Agregación............................................................................................................ 46

6.5 CLÁUSULA HAVING............................................................................................................................. 46 6.6 CLÁUSULA UNION............................................................................................................................... 47

6.6.1 Especificación de proyecciones en consultas UNION ............................................................................ 47 6.7 CLÁUSULA ORDER BY......................................................................................................................... 47 6.8 CLÁUSULA CONTEXT .......................................................................................................................... 48 6.9 CLÁUSULA TRACE ............................................................................................................................... 49

7 DEFINICIÓN DE UNA VISTA DERIVADA .......................................................................................... 52 7.1 MODIFICACIÓN DE UNA VISTA DERIVADA.................................................................................... 53

7.1.1 Reglas de Reescritura Sobre Vistas Derivadas ...................................................................................... 54

8 INSERCIONES, ACTUALIZACIONES Y BORRADOS SOBRE VISTAS........................................... 56 8.1 SENTENCIA INSERT ............................................................................................................................ 56 8.2 SENTENCIA UPDATE........................................................................................................................... 57 8.3 SENTENCIA DELETE ............................................................................................................................ 58 8.4 USO DE WITH CHECK OPTION .......................................................................................................... 58

9 TRANSACCIONES EN DATAPORT .................................................................................................... 60

10 PROCEDIMIENTOS ALMACENADOS................................................................................................ 61 10.1 IMPORTACIÓN DE UN PROCEDIMIENTO ALMACENADO............................................................ 61 10.2 USO DE PROCEDIMIENTOS ALMACENADOS................................................................................. 61 10.3 CREACIÓN DE NUEVOS PROCEDIMIENTOS ALMACENADOS .................................................... 62 10.4 PROCEDIMIENTOS PREDEFINIDOS.................................................................................................. 64

11 DEFINICIÓN DE OTROS ELEMENTOS DEL CATÁLOGO ................................................................. 65 11.1 DEFINICIÓN DE UN TIPO DE DATO................................................................................................... 65 11.2 DEFINICIÓN DE UN MAPA ................................................................................................................. 66

12 CREACIÓN DE BASES DE DATOS, USUARIOS Y PERMISOS....................................................... 68 12.1 BASES DE DATOS EN VIRTUAL DATAPORT ................................................................................... 68 12.2 ESTRUCTURA DE USUARIOS Y PERMISOS EN VIRTUAL DATAPORT........................................ 68

12.2.1 Tipos de usuarios .................................................................................................................................... 68 12.2.2 Tipos de permisos ................................................................................................................................... 68

12.3 SENTENCIAS VQL DE BASES DE DATOS, USUARIOS Y PERMISOS .......................................... 70 12.3.1 Creación de Bases de Datos ................................................................................................................... 70 12.3.2 Modificación y Borrado de Bases de Datos............................................................................................ 70 12.3.3 Creación de usuarios............................................................................................................................... 71 12.3.4 Modificación y Borrado de usuarios ....................................................................................................... 72


12.3.5 Cambio de Base de Datos Activa............................................................................................................ 72 12.3.6 Modificación de los privilegios de un usuario........................................................................................ 73

13 DESCRIPCIÓN DE ELEMENTOS DEL CATÁLOGO ........................................................................... 76 13.1 EXPORTACIÓN DE METADATOS....................................................................................................... 77

14 LISTADO DE ELEMENTOS DEL CATÁLOGO..................................................................................... 78

15 ELIMINACIÓN DE ELEMENTOS DEL CATÁLOGO ........................................................................... 80

16 OTROS COMANDOS ............................................................................................................................ 82 16.1 BORRADO DE ENTRADAS DE LA CACHÉ DEL DICCIONARIO DE DATOS .................................. 82 16.2 COMANDO DE AYUDA........................................................................................................................ 82

17 GENERACIÓN DE WRAPPERS Y DATASOURCES .......................................................................... 84 17.1 CONVERSIONES VÁLIDAS ENTRE TIPOS EN LOS WRAPPERS Y VDP....................................... 85

17.1.1 Conversiones de tipo nativo de un wrapper a tipos Java ...................................................................... 85 17.2 ESPECIFICACIÓN DE RUTAS EN VIRTUAL DATAPORT................................................................. 88 17.3 CREACIÓN DE DATASOURCES.......................................................................................................... 90

17.3.1 DataSources JDBC.................................................................................................................................. 90 17.3.2 DataSources ODBC ................................................................................................................................. 93 17.3.3 DataSources para Servicios Web ........................................................................................................... 95 17.3.4 DataSources XML ................................................................................................................................... 96 17.3.5 DataSources DF....................................................................................................................................... 96 17.3.6 DataSources Denodo Aracne.................................................................................................................. 98 17.3.7 DataSources Google Mini....................................................................................................................... 98 17.3.8 DataSources LDAP .................................................................................................................................. 99 17.3.9 DataSources Custom............................................................................................................................... 99 17.3.10 Propiedades de Configuración de Fuentes de Datos............................................................................ 100

17.4 CREACIÓN DE WRAPPERS............................................................................................................... 105 17.4.1 Contexto de Ejecución y Cadenas de Interpolación.............................................................................. 105 17.4.2 Metainformacion de un wrapper .......................................................................................................... 105 17.4.3 Wrapper JDBC ...................................................................................................................................... 106 17.4.4 Wrapper ODBC...................................................................................................................................... 108 17.4.5 Wrapper ITPilot ..................................................................................................................................... 109 17.4.6 Wrapper de Servicios Web................................................................................................................... 112 17.4.7 Wrapper XML........................................................................................................................................ 114 17.4.8 Wrapper DF ........................................................................................................................................... 116 17.4.9 Wrapper Denodo Aracne ...................................................................................................................... 117 17.4.10 Wrapper Google Mini ........................................................................................................................... 120 17.4.11 Wrapper CUSTOM ................................................................................................................................ 123 17.4.12 Propiedades de Configuración de Wrappers ........................................................................................ 126

17.5 SENTENCIAS DE CONSULTA DE WRAPPERS .............................................................................. 128

18 CARACTERÍSTICAS AVANZADAS................................................................................................... 130 18.1 GESTIÓN DE VALORES DE TIPOS COMPUESTOS........................................................................ 130

18.1.1 Manejo de Tipos Compuestos: Ejemplo ............................................................................................... 131 18.2 OPTIMIZACIÓN DE CONSULTAS .................................................................................................... 135

18.2.1 Optimización de Operaciones de join ................................................................................................... 135 18.2.2 Uso de la Cache .................................................................................................................................... 139 18.2.3 Configuración de Políticas de “Swapping”........................................................................................... 140


18.3 CREACIÓN DE CONFIGURACIONES DE INTERNACIONALIZACIÓN.......................................... 141 18.3.1 Acceso y Mantenimiento de la Información de Cambio de Divisas..................................................... 144

18.4 CONTEXTO DE EJECUCIÓN DE UNA CONSULTA Y CADENAS DE INTERPOLACIÓN............ 144

19 APÉNDICES......................................................................................................................................... 146 19.1 SINTAXIS DE EXPRESIONES DE BÚSQUEDA DEL OPERADOR CONTAINS ............................ 146

19.1.1 Términos y Frases exactas.................................................................................................................... 146 19.1.2 Modificadores de términos................................................................................................................... 146 19.1.3 Operadores Booleanos.......................................................................................................................... 148 19.1.4 Agrupaciones ........................................................................................................................................ 148 19.1.5 Escapar caracteres especiales.............................................................................................................. 148

19.2 SOPORTE PARA EL OPERADOR CONTAINS DE CADA TIPO DE FUENTE................................. 148 19.2.1 Aracne ................................................................................................................................................... 148 19.2.2 Google Mini........................................................................................................................................... 149

BIBLIOGRAFÍA ............................................................................................................................................................. 150


ÍNDICE DE FIGURAS Figura 1 Formulario de búsqueda para una tienda de libros .................................................................................. 5 Figura 2 Método de búsqueda para una tienda de libros....................................................................................... 5 Figura 3 Primitivas básicas para la especificación de sentencias VQL................................................................ 28 Figura 4 Reglas para la formación de funciones .................................................................................................. 29 Figura 5 Sintaxis de la sentencia CREATE TABLE ........................................................................................ 30 Figura 6 Ejemplo de creación de una vista base .................................................................................................. 30 Figura 7 Sintaxis de la sentencia ALTER TABLE ........................................................................................... 32 Figura 8 Ejemplo de creación de un método de búsqueda con ALTER TABLE ............................................. 33 Figura 9 Adición de una regla de reescritura de entrada REGEXP() .............................................................. 36 Figura 10 Adición de una regla de reescritura sobre condiciones MAP() ........................................................... 36 Figura 11 Adición de una regla de reescritura de entrada CHANGEOPERATOR() ......................................... 37 Figura 12 Adición de una regla de reescritura de salida con la función MAP().................................................. 38 Figura 13 Sintaxis de la sentencia SELECT......................................................................................................... 40 Figura 14 Sintaxis de una FLATTEN view ............................................................................................................... 43 Figura 15 Sintaxis para una condición.................................................................................................................... 44 Figura 16 Sintaxis para una proyección sobre el resultado de una unión.............................................................. 47 Figura 17 Sintaxis de la cláusula CONTEXT ........................................................................................................ 49 Figura 18 Traza de ejecución .................................................................................................................................. 51 Figura 19 Sintaxis de la sentencia CREATE VIEW ........................................................................................... 52 Figura 20 Ejemplo de definición de una vista en función de otras......................................................................... 53 Figura 21 Sintaxis de la sentencia ALTER VIEW .............................................................................................. 54 Figura 22 Adición de una regla de reescritura de entrada sobre vista derivada ................................................... 55 Figura 23 Borrado de una regla de reescritura de salida de una vista no base..................................................... 55 Figura 24 Adición de una reescritura sobre resultados en una vista derivada ...................................................... 55 Figura 25 Sintaxis de la sentencia INSERT......................................................................................................... 56 Figura 26 Sintaxis de la sentencia UPDATE......................................................................................................... 57 Figura 27 Sintaxis de la sentencia DELETE......................................................................................................... 58 Figura 28 Sintaxis de CREATE PROCEDURE .................................................................................................. 61 Figura 29 Sintaxis de ALTER PROCEDURE ..................................................................................................... 61 Figura 30 Sintaxis de la sentencia CALL .............................................................................................................. 61 Figura 31 Sintaxis de la sentencia CREATE TYPE ........................................................................................... 65 Figura 32 Creación de un tipo de dato enumerated ............................................................................................... 65 Figura 33 Creación de un tipo de dato register ...................................................................................................... 66 Figura 34 Creación de un tipo de dato array y del tipo register que contiene ...................................................... 66 Figura 35 Sintaxis de la sentencia CREATE MAP .............................................................................................. 66 Figura 36 Creación de un mapa de tipo inputrewrite ............................................................................................. 67 Figura 37 Sintaxis de la sentencia CREATE DATABASE ................................................................................ 70 Figura 38 Sintaxis de la sentencia ALTER DATABASE ................................................................................... 71 Figura 39 Sintaxis de la sentencia CREATE USER ........................................................................................... 72 Figura 40 Sintaxis de la sentencia ALTER USER .............................................................................................. 72 Figura 41 Sintaxis de las sentencias CONNECT y CLOSE ................................................................................. 73 Figura 42 Sintaxis de las cláusulas GRANT/REVOKE para Bases de Datos...................................................... 73 Figura 43 Sintaxis de las cláusulas GRANT/REVOKE para Bases de Datos...................................................... 74 Figura 44 Sintaxis de las cláusulas GRANT/REVOKE para vistas...................................................................... 75 Figura 45 Ejemplo de asignación de privilegios a usuarios.................................................................................... 75 Figura 46 Sintaxis de la sentencia DESC .............................................................................................................. 76 Figura 47 Sintaxis de la sentencia LIST .............................................................................................................. 78 Figura 48 Sintaxis de la sentencia DROP .............................................................................................................. 80 Figura 49 Sintaxis de la sentencia CLEAR CACHE ........................................................................................... 82 Figura 50 Sintaxis de la sentencia HELP .............................................................................................................. 83 Figura 51 Sentencia que solicita ayuda sobre el comando ALTER TABLE ..................................................... 83 Figura 52 Sintaxis de la sentencia de creación de un datasource JDBC ............................................................... 92


Figura 53 Sintaxis de la sentencia de modificación de un datasource JDBC ........................................................ 93 Figura 54 Sintaxis de la sentencia de creación de un datasource ODBC............................................................... 95 Figura 55 Sintaxis de la sentencia de modificación de un datasource ODBC........................................................ 95 Figura 56 Sintaxis de la sentencia de creación de un datasource WS. ................................................................. 95 Figura 57 Sintaxis de la sentencia de modificación de un datasource WS. .......................................................... 95 Figura 58 Sintaxis de la sentencia de creación de un datasource XML................................................................. 96 Figura 59 Sintaxis de la sentencia de modificación de un datasource XML.......................................................... 96 Figura 60 Sintaxis de la sentencia de creación de un datasource DF.................................................................... 97 Figura 61 Sintaxis de la sentencia de modificación de un datasource DF............................................................. 98 Figura 62 Sintaxis de la sentencia de creación de un datasource Aracne............................................................. 98 Figura 63 Sintaxis de la sentencia de modificación de un datasource Aracne...................................................... 98 Figura 64 Sintaxis de la sentencia de creación de un datasource Google Mini .................................................... 98 Figura 65 Sintaxis de la sentencia de modificación de un datasource Google Mini ............................................. 99 Figura 66 Sintaxis de la sentencia de creación de un datasource LDAP ............................................................... 99 Figura 67 Sintaxis de la sentencia de modificación de un datasource LDAP ........................................................ 99 Figura 68 Sintaxis de la sentencia de creación de un datasource Custom.......................................................... 100 Figura 69 Sintaxis de la sentencia de modificación de un datasource Custom................................................... 100 Figura 70 Ejemplo de modificación de configuración de un datasource. ............................................................. 103 Figura 71 Sintaxis de creación de un wrapper JDBC ........................................................................................... 106 Figura 72 Sintaxis de modificación de un wrapper JDBC .................................................................................... 107 Figura 73 Sintaxis de creación de un wrapper ODBC........................................................................................... 108 Figura 74 Sintaxis de modificación de un wrapper ODBC.................................................................................... 109 Figura 75 Sintaxis de creación de un wrapper de tipo ITPilot .............................................................................. 110 Figura 76 Sintaxis de modificación de un wrapper de tipo ITPilot ....................................................................... 110 Figura 77 Ejemplo de wrapper ITPIlot 4.0............................................................................................................. 111 Figura 78 Ejemplo de creación de un wrapper ITPilot ......................................................................................... 112 Figura 79 Sintaxis de creación de un wrapper de servicios Web ........................................................................ 113 Figura 80 Sintaxis de modificación de un wrapper de servicios Web ................................................................. 113 Figura 81 Sintaxis de creación de un wrapper XML............................................................................................ 115 Figura 82 Sintaxis de modificación de un wrapper XML..................................................................................... 115 Figura 83 Sintaxis de creación de un wrapper DF ............................................................................................... 116 Figura 84 Sintaxis de modificación de un wrapper DF ........................................................................................ 117 Figura 85 Sintaxis de creación de un wrapper Denodo Aracne .......................................................................... 118 Figura 86 Ejemplo de creación de un wrapper Denodo Aracne ........................................................................... 119 Figura 87 Sintaxis de modificación de un wrapper Denodo Aracne ................................................................... 120 Figura 88 Sintaxis de creación de un wrapper Google Mini ............................................................................... 122 Figura 89 Ejemplo de creación de un wrapper Google Mini ................................................................................ 122 Figura 90 Sintaxis de modificación de un wrapper Google Mini ........................................................................ 123 Figura 91 Sintaxis de creación de un wrapper tipo CUSTOM .............................................................................. 126 Figura 92 Ejemplo de creación de un wrapper CUSTOM ..................................................................................... 126 Figura 93 Sintaxis de modificación de un wrapper tipo CUSTOM ....................................................................... 126 Figura 94 Ejemplo de configuración de un Wrapper CUSTOM ............................................................................ 128 Figura 95 Sintaxis de las sentencias de consulta de wrappers ........................................................................... 128 Figura 96 Sintaxis de la sentencias de consulta de wrappers ITPilot.................................................................. 129 Figura 97 Árboles de tipos compuestos................................................................................................................ 132 Figura 98 Tupla con elementos compuestos ........................................................................................................ 133 Figura 99 Árbol de valores de tipos compuestos.................................................................................................. 133 Figura 100 Creación de una relación base con tipos compuestos ......................................................................... 133 Figura 101 Creando un método de búsqueda con tipos compuestos..................................................................... 134 Figura 102 Adición de un método de búsqueda con tipos compuestos ................................................................. 134 Figura 103 Sintaxis de QUERYPLAN ................................................................................................................... 137 Figura 104 Árbol de definición de la vista V5........................................................................................................ 138 Figura 105 Internacionalización es_euro................................................................................................................ 144


ÍNDICE DE TABLAS Tabla 1 Conversiones de tipos permitidas con la función CAST ....................................................................... 23 Tabla 2 Conversiones automáticas entre tipos JAVA y tipos Virtual DataPort .................................................. 85 Tabla 3 Otras conversiones válidas entre tipos JAVA y tipos Virtual DataPort.................................................. 85 Tabla 4 Conversiones de tipos JDBC................................................................................................................... 86 Tabla 5 Conversiones de tipos ITPilot.................................................................................................................. 87 Tabla 6 Conversiones de tipos de Web Services ................................................................................................ 87 Tabla 7 Conversiones de tipos XML .................................................................................................................... 88 Tabla 8 Caracteres reservados para el formato de una fecha .......................................................................... 143


Prefacio i

PREFACIO

ALCANCE

Este documento proporciona una visión de Virtual DataPort desde el punto de vista del administrador avanzado.

QUIÉN DEBERÍA USAR ESTE DOCUMENTO

Este documento está dirigido a administradores y desarrolladores que quieran conocer con detalle cómo se realizan todas las actividades de administración de una solución de integración basada en Virtual DataPort utilizando directamente el lenguaje VQL. Se incluye la descripción de actividades tales como la definición de wrappers, la elaboración de vistas unificadas a partir de las relaciones base o la especificación de mapas sobre los campos integrados. La información detallada necesaria para instalar el sistema, administrarlo a través de herramientas gráficas y/o desarrollar aplicaciones utilizando las APIs se proporciona en otros manuales que serán referenciados a medida que sea necesario.

RESUMEN DE CONTENIDOS

Más concretamente, en este documento:

• Se describen algunas características importantes de Virtual DataPort que es necesario conocer previamente para comprender el resto del documento.

• Se proporciona una visión general del lenguaje VQL.

• Se muestra en detalle cómo se realizan las diferentes tareas de operación sobre el servidor Virtual DataPort, es decir, cómo se definen y modifican los elementos del catálogo y cómo se realizan consultas y/o modificaciones sobre el servidor.


Introducción 2

1 INTRODUCCIÓN

Denodo Virtual DataPort es una solución global para la integración de fuentes de información heterogéneas y dispersas en tiempo real. Virtual DataPort utiliza el lenguaje VQL (Virtual Query Language) como lenguaje de consulta, actualización y definición de datos. VQL permite crear, actualizar y manipular los elementos que constituyen el diccionario de datos del sistema, así como la realización de consultas y actualizaciones sobre las vistas integradas de información. VQL es un lenguaje muy similar a SQL pero que incluye además construcciones específicas para tratar con las peculiaridades de un sistema de integración de información virtual en tiempo real. En este documento se describe VQL y la forma de utilizarlo para realizar las labores de administración de Virtual DataPort. Es importante resaltar que en general no es necesario utilizar VQL directamente. En la Guía del Administrador [3] se describe el uso de las herramientas gráficas de Virtual DataPort, que permiten realizar la mayoría de las labores de administración de forma gráfica.


Virtual Dataport a Vista de Pájaro 3

r l

2 VIRTUAL DATAPORT A VISTA DE PÁJARO

En esta sección se proporciona una breve introducción a las etapas involucradas en la creación de aplicaciones de integración de información utilizando Virtual DataPort. Se asume que la creación de dichas aplicaciones se realizará en este caso utilizando directamente el lenguaje VQL. Véase la Guía del Administrador [3] para una descripción de cómo realizar estas tareas de forma gráfica a través de las herramientas de administración de Virtual DataPort. El modo gráfico es el recomendado para realizar las tareas de administración. En la operación de Virtual DataPort se pueden distinguir dos fases: una primera de creación o definición de datos y una segunda de ejecución de las consultas y/o actualizaciones que especifica el usuario. En la primera fase se define el modelo de datos unificado del sistema, es decir, se importan las fuentes a utilizar y se definen vistas que combinan dicha información de la forma deseada. La segunda fase, la ejecución de consultas y/o actualizaciones, constituye la operación normal del sistema, en la cual acepta sentencias expresadas en VQL sobre las vistas y las resuelve extrayendo y combinando información de las fuentes y/o modificando información de éstas. Los siguientes subapartados se ocupan, respectivamente, de cada una de estas fases.

2.1 CREACIÓN O DEFINICIÓN DE DATOS

Esta fase tiene como objetivo definir la estructura de las vistas o relaciones de las que constará el esquema global de Virtual DataPort. Todas las tareas involucradas en la creación y administración de esquemas dentro del servidor se describen detalladamente en secciones posteriores de este documento. En esta sección se proporciona tan solo una visión general del proceso. Para la definición de datos será necesario –en primer lugar- definir las relaciones base (también llamadas vistas base) que representarán a las fuentes externas suministradoras de la información. Para ello es necesario especificar un wrapper para la relación base, cuya misión será extraer información de la fuente e interpretar los resultados devueltos por ella. Dependiendo del tipo de fuente utilizada, puede ser necesario como paso previo a la creación de wrappers, la creación de un datasource. Los datasources encapsulan información de acceso a una fuente determinada de forma que ésta puede ser reutilizada por los diferentes wrappers que actuen sobre la misma. Una vez que las relaciones base ya puedan acceder a los datos de las fuentes, se definirán las vistas que componen el esquema global mediante la composición y combinación de las relaciones base. A continuación se describen brevemente estas operaciones.

2.1.1 Definición de relaciones base

Cada fuente en el sistema se modelará como un conjunto de relaciones base exportadas por la misma. Cada e ación base estará compuesta de un conjunto de atributos, de manera similar a una tabla en una Base de Datos relacional convencional. Cada atributo de una relación pertenecerá a un tipo de dato. El tipo de un determinado atributo delimita qué operadores de consulta pueden aplicarse sobre él, así como ciertas restricciones que los elementos de ese tipo deben cumplir. Algunos tipos de datos usuales soportados por Virtual DataPort son: cadenas de caracteres, enteros, divisas, fechas, etc. Están soportados también los tipos de dato array (para representar datos multi-valuados) y register (para representar datos de tipo registro). Combinando estos dos tipos de dato, pueden también representarse fácilmente en el modelo unificado estructuras de datos jerárquicas.



Además, cada relación base describirá explícitamente sus capacidades de consulta mediante los denominados métodos de búsqueda. Esto es necesario porque algunas fuentes de datos (e.g. fuentes web o servicios web) no permiten realizar cualquier consulta sobre sus datos, sino que presentan interfaces limitadas para esos efectos (e.g. formularios HTML o las operaciones definidas a través de un Servicio Web). 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 fuente 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. ‘OPT’ 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. ‘ANY’ 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.

En fuentes tales como bases de datos relacionales habitualmente será permitida cualquier consulta. En ese caso las relaciones base creadas a partir de dichas fuentes tendrán típicamente un único método de búsqueda con una 5-upla por cada atributo de la relación. Cada 5-upla indicará que el atributo puede aparecer o no en las consultas (valor ‘OPT’ en obligatoriedad) y con cualquier multiplicidad (valor ‘ANY’ en multiplicidad). En otras fuentes la situación puede ser diferente. Considérese el siguiente ejemplo. Ejemplo: Consideremos el ejemplo de una tienda virtual de libros en Internet cuyo formulario de búsqueda es como el mostrado en la Figura 1.



Figura 1

Figura 2

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 like). Una búsqueda por frase exacta (operador ‘=’) 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 PRECIO, 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 2.

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

'All formats','Hardcover', 'eBooks', 'Paperbacks') (PRICE, , NOS, 0, )

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

Nótese que la primera 5-upla tenga el valor like, = 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 este 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.

2.1.2 Definición de datasources y wrappers

Para que una relación base pueda obtener datos de una fuente determinada es necesario crear y asignarle un wrapper. Cada wrapper debe proporcionar acceso a los datos que componen una relación base en una fuente de



manera que, de cara al servidor DataPort, se estructuren de manera similar a una tabla de una Base de Datos Relacional. Más concretamente, cada wrapper debe proporcionar una visión de la fuente acorde al modelo de relación base expuesto en el apartado anterior. El proceso de generación de wrappers para fuentes tales como Bases de Datos JDBC/ODBC, Servicios web, documentos XML, ficheros de texto delimitados o índices de información no estructurada, puede realizarse de manera rápida y sencilla con la ayuda de la herramienta de administración de Denodo Virtual DataPort (ver [3]). Normalmente es necesario crear previamente un datasource para la fuente, que encapsulará información de acceso a la misma reutilizable por los diferentes wrappers que actúen sobre ella. La creación de wrappers para fuentes web semi-estructuradas puede realizarse de forma totalmente gráfica con Denodo ITPilot (ver [6]). Es posible también crear wrappers para aplicaciones específicas utilizando el tipo de wrapper Custom. Si se desea crear los datasources y wrappers directamente mediante VQL, sin ayuda de la herramienta de administración, en la sección 17 de este documento se describe cómo hacerlo. En general, el uso de la herramienta de administración es fuertemente recomendado para estas tareas ya que el proceso es más sencillo y automático. Una vez creado el wrapper para una fuente, basta asociarlo al método de búsqueda o métodos de búsqueda deseados de la relación base que representa a dicha fuente en el sistema (véase sección 5). En ese momento ya podremos realizar consultas sobre la relación base.

2.1.3 Definición de las vistas del esquema global

Una vez definidas las relaciones base y construidos sus wrappers, cada relación del esquema global se define mediante una consulta sobre las relaciones base, de forma similar a la definición de vistas en una Base de Datos convencional. Es importante destacar que en la definición de una vista, además de las relaciones base, pueden utilizarse también vistas intermedias que se hayan definido previamente. Ejemplo: Supónganse tres relaciones base A = TITLE, AUTHOR, FORMAT, PRICE, B = TITLE, AUTHOR, FORMAT, PRICE y C = TITLE, AUTHOR, AVERAGE _RELEVANCE. A y B representan a dos tiendas electrónicas de libros en Internet. C representa a una fuente en la que sus usuarios valoran libros y el sistema permite buscar la valoración media de un libro determinado. Supóngase que deseamos obtener una relación del esquema global R = TITLE,AUTHOR,PRICE,AVERAGE_RELEVANCE), que contenga todos los libros de A y B, junto con su valoración media según C y el valor mínimo encontrado para el atributo PRICE, de entre las ocurrencias del libro encontradas en ambas fuentes. La definición de R podría hacerse en los dos siguientes pasos:

1. Creación de la vista bookview como la unión de A y B.

CREATE VIEW bookview AS • SELECT * FROM A • UNION • SELECT * FROM B;

2. Creación de la vista R como el join de bookview y C, aplicando una operación groupby para seleccionar el precio mínimo para cada libro.

CREATE VIEW R AS



l

• SELECT TITLE, AUTHOR, AVERAGE_RELEVANCE,MIN(PRICE) AS MINIMUM • FROM bookview JOIN C ON ( bookview.TITLE = C.TITLE AND bookview.AUTHOR = C.AUTHOR ) • GROUP BY TITLE, AUTHOR;

Tal y como ya se ha comentado, las relaciones base pueden presentar limitaciones en sus capacidades de consulta, que se expresan mediante métodos de búsqueda. Al crear vistas, Virtual DataPort es capaz de calcular automáticamente sus métodos de búsqueda partiendo de los de las relaciones base 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 y también hace posible que un servidor Virtual DataPort pueda ser utilizado como fuente para otro servidor Virtual DataPort, facilitando así abordar proyectos de gran tamaño mediante un enfoque incremental.

2.1.3.1 Post-procesados

A la hora de considerar las capacidades de consulta de una fuente, es también preciso tener en cuenta que el servidor Virtual DataPort puede realizar operaciones de post-procesado sobre los resultados obtenidos. A partir de las restricciones de consulta de una fuente, aplicando post-procesados es posible obtener su lista de capacidades como un superconjunto de ésta. Esta tarea la realiza de forma automática el servidor.

2.2 EJECUCIÓN DE SENTENCIAS

Una vez terminada la fase de creación, el sistema está preparado para aceptar consultas y/o actualizaciones; las actualizaciones sólo pueden realizarse sobre vistas actualizables conforme al estándar SQL 92, las cuales son vistas definidas sobre wrappers JDBC/ODBC o wrappers Custom. Los detalles sobre la manera en que las aplicaciones externas pueden enviar y ejecutar sentencias sobre la Base de Datos Virtual se muestran en la Guía del Desarrollador [5]. En esta sección, se proporciona tan solo una visión general del proceso de ejecución de consultas desde un punto de vista interno. Cuando se recibe una consulta VQL, el intérprete de consultas de Virtual DataPort comienza comprobando si la consulta puede ser contestada en función de las capacidades de las vistas involucradas. Si la consulta no puede ser contestada, el usuario es informado de ello. Si puede serlo, el proceso continúa. Seguidamente el Generador de P anes del sistema crea todos los posibles planes de ejecución para la consulta. Los planes diferirán normalmente entre sí en aspectos como el algoritmo utilizado para ejecutar los joins o los métodos de búsqueda concretos seleccionados sobre las fuentes. Es responsabilidad del módulo optimizador obtener el coste de cada uno de los planes, en función de diferentes parámetros, de manera que pueda seleccionarse el mejor. Este proceso se ocupa, entre otras tareas, de distribuir de forma óptima el procesamiento entre el servidor DataPort y las fuentes, delegando a las mismas, cuando sea posible, operaciones tales como condiciones de selección, joins, uniones o agrupaciones. De esta forma puede minimizarse la transferencia de datos por la red. Esta etapa también se ocupa de tareas tales cómo escoger el método más adecuado para implementar operadores de join, de fijar la estrategia de swapping a disco de resultados muy grandes o de gestionar el uso del módulo de cache. Véase la sección 18.2 para más detalle. Una vez seleccionado el plan óptimo, el Motor de Ejecución se encarga de ponerlo en marcha. La ejecución de un plan supondrá la ejecución de una serie de sub-consultas expresadas únicamente en términos de las relaciones base. Estas subconsultas serán ejecutadas por el wrapper de la fuente correspondiente. Es remarcable la capacidad que tiene Virtual DataPort de explotar al máximo las posibilidades de paralelismo, por lo que normalmente la ejecución de las subconsultas se efectúa en paralelo. Finalmente, el motor de ejecución combina los resultados devueltos por las fuentes de acuerdo a lo especificado por el plan, obteniendo así la respuesta final a la consulta.



Es importante destacar que el sistema funciona de manera asíncrona. Esto quiere decir que a medida que están disponibles resultados de las fuentes, el sistema empieza a procesarlos, aunque las fuentes todavía no hayan emitido una respuesta completa. Esto puede acelerar mucho los tiempos de obtención de las primeras tuplas del resultado final (tiempos de respuesta). Otro aspecto importante, es que el sistema es capaz de tratar resultados parciales, esto es: es capaz de procesar la consulta incluso si alguna de las fuentes está temporalmente inaccesible, proporcionando los resultados que puedan obtenerse con el resto de fuentes. Opcionalmente, pueden pre-cargarse o mantenerse todos o parte de los datos de las fuentes en la caché del sistema. En ese caso, el sistema comprobará si la subconsulta recibida puede ser resuelta con los datos contenidos en la caché. Si es así, obtiene la respuesta directamente de la misma en lugar de consultar a la fuente. Virtual DataPort también soporta la ejecución de sentencias de actualización (INSERT / UPDATE /DELETE) sobre las vistas, siempre que éstas sean actualizables de acuerdo a la definición estándar en SQL-92. Véase la sección 8 para más detalle.


Características 9

3 CARACTERÍSTICAS

Virtual DataPort permite de manera rápida y sencilla, extraer y combinar en tiempo real información procedente de múltiples fuentes heterogéneas estructuradas, semi-estructuradas y no estructuradas. Virtual DataPort proporciona un lenguaje de definición y manejo de datos llamado Denodo VQL (Virtual Query Language), cuya sintaxis es similar a SQL (Structured Query Language) con algunas extensiones necesarias para un entorno de integración virtual de fuentes de información heterogéneas y distribuidas. Por ejemplo, VQL incluye diversas construcciones que facilitan la consulta de información no estructurada y su combinación con información estructurada. En este apartado se describen algunas características importantes de Virtual DataPort que es necesario conocer previamente para comprender el resto del documento.

• En primer lugar, se describen cuáles son los tipos de datos existentes.

• A continuación, se describen los mecanismos de internacionalización de los diferentes tipos de datos del sistema.

• Posteriormente, se introducen los mecanismos de representación de las capacidades de consulta de una relación.

• Por último, se introduce el sistema de reglas de reescritura, que permite solventar dificultades derivadas de las heterogeneidades semánticas de las fuentes.

3.1 TIPOS DE DATOS

Virtual DataPort incluye en su catálogo un conjunto de tipos de datos predefinidos. Estos tipos se pueden dividir en dos grupos: los tipos básicos y los tipos compuestos. Los tipos de datos básicos soportados son:

• int. Representa un número entero en el rango -2147483648 a 2147483647.

• long: Representa un número entero en el rango -9223372036854775808 a 9223372036854775807.

• float: Representa un número real en el rango 1.4E-45 a 3.4028235E38.

• double. Representa un número real en el rango 4.9E-324 a 1.7976931348623157E308.

• boolean: Representa un valor lógico, verdadero o falso (true | false).

• text. Representa una cadena de caracteres.


Características 10

• date. Encapsula una fecha.

• time. Representa un intervalo de tiempo o duración.

• money. Representa una cantidad monetaria.

• blob. Representa un elemento de datos binario.

• xml. Representa un documento XML (o un fragmento de un documento XML).

Los tipos de datos compuestos, que permiten la creación de nuevos tipos de datos, son los siguientes:

• enumerated. Los atributos de este tipo pueden tomar como valor una cadena de caracteres de entre un conjunto predefinido por el tipo de datos.

• register. Tipo de dato que sirve para representar información que posee una estructura interna y heterogénea, es decir, los campos en los que se subdivide el dato no son todos del mismo tipo.

• array. Representa una lista –por tanto, importa el orden– de elementos de un mismo tipo register.

Como se verá mas adelante (ver secciones 11.1 y 18.1), Virtual DataPort permite la definición de tipos de datos compuestos específicos que permiten modelar de forma natural elementos de datos jerárquicos como los utilizados habitualmente en fuentes de datos tales como los Servicios Web o los documentos XML.

3.2 INTERNACIONALIZACIÓN

Virtual DataPort incorpora soporte para la integración de fuentes de datos procedentes de distintos países o ámbitos geográficos expresando además los datos de salida en los formatos esperados por el país deseado. Por ejemplo, Virtual DataPort incorpora soporte para comparar cantidades monetarias expresadas en monedas diferentes mediante conversiones automáticas. De forma similar DataPort ofrece soporte para mostrar los resultados de una consulta en una determinada zona horaria independientemente de la zona utilizada por las fuentes de datos (e.g. en España, aunque se extraigan datos de fuentes inglesas, los resultados podrán mostrar las monedas, horas y fechas correspondientes a España). Para cada uno de los paises/localizaciones de los que pueden proceder los datos que maneja el servidor existe una configuración de internacionalización, que se representa por medio de un mapa de tipo i18n (ver construcción de mapas en el Apartado 11.2). Virtual DataPort incluye mapas ya creados para las configuraciones más habituales de muchos paises. El nombre de dichas configuraciones utiliza el prefijo estándar definido en la norma ISO-3166 [2] (e.g. España (es_euro), Reino Unido (gb), Francia (fr), Estados Unidos (us), etc.). También es muy sencillo crear nuevas configuraciones de internacionalización. Véase la sección 18.3 para una descripción detallada del proceso. Por último, es importante tener en cuenta que el formato por defecto a utilizar para escribir constantes de tipo date, money y double en las consultas sobre una vista viene fijado por la configuración de internacionalización que se esté utilizando sobre la misma. Véase la sección 18.3 para más información sobre los distintos parámetros de una configuración de internacionalización y la sección 13 para saber cómo consultar los parámetros asignados a una configuración concreta. Por otro lado, la sección 4.6.3 describe diversas funciones para manejar fechas que pueden ser útiles para expresar las fechas en el formato deseado.


Características 11

3.3 CAPACIDADES DE CONSULTA

En el contexto en el que funciona Virtual DataPort, puede ocurrir que las fuentes de información presenten capacidades de consulta limitadas. Por ejemplo, la mayor parte de fuentes web sólo permiten la realización de consultas que cumplan las restricciones impuestas por un determinado formulario HTML de consulta. Por ello, el administrador debe especificar directamente las capacidades de consulta de las relaciones que representan las fuentes del sistema (estas relaciones se llaman relaciones base). La descripción de las capacidades de consulta en Virtual DataPort se realiza mediante los llamados métodos de búsqueda. Para cada relación base, el administrador definirá uno o más métodos de búsqueda. Los métodos de búsqueda de las vistas derivadas serán obtenidos automáticamente por el sistema partiendo de los métodos de búsqueda de las relaciones base que intervienen en la vista y de la expresión utilizada para construirla, por lo que el administrador no tiene que ocuparse de su definición en este caso.

3.4 REGLAS DE REESCRITURA

En ocasiones, fuentes diferentes pueden utilizar distintos formatos para representar el mismo tipo de contenidos semánticos. Virtual DataPort incluye un sistema propio para el tratamiento de las representaciones heterogéneas de información procedente de varias fuentes. Concretamente, se proporciona un mecanismo que permite reescribir las consultas realizadas y los resultados obtenidos desde una fuente para adaptarlos al formato deseado. Por ejemplo, supóngase que una determinada fuente A tiene un atributo que almacena el nombre del autor de un libro utilizando un atributo con el formato de representación ‘Apellido, Nombre’ (e.g. ‘Smith, John’ o ‘de Cervantes, Miguel’), mientras que otra fuente B utiliza un formato ‘Nombre Apellido’ (e.g. ‘John Smith’ o ‘Miguel de Cervantes’). Además, cuando se realizan consultas por el atributo autor, ambas fuentes esperan que el nombre aparezca en la consulta en su formato particular. Supóngase ahora que se desea usar Virtual DataPort para definir una vista unión sobre A y B, a la que llamaremos C. Cuando el servidor reciba la consulta select * from C where author = ’John Smith’, deberá emitir subconsultas a A y B para extraer de ambas fuentes los libros del autor deseado y devolver el resultado. Sin embargo, para que la consulta pueda ser contestada correctamente por la fuente A, será necesario incluir una regla de reescritura de consulta que transforme la cadena de caracteres ‘John Smith’ en ‘Smith, John’. De la misma forma que puede ser necesario reescribir consultas para tratar las heterogeneidades de representación en las fuentes, puede ser necesario transformar los resultados recibidos desde ellas para que su representación se adecue al formato deseado para las vistas del esquema global. La reescritura de resultados se realiza en Virtual DataPort a través de las reglas de reescritura sobre resultados o de salida. Continuando con el ejemplo anterior, la fuente A devolverá sus resultados con el atributo autor codificado en el formato ‘Apellido, Nombre’, mientras que en la vista C se desea que todos los resultados estén en el formato ‘Nombre Apellido’. Por tanto, es necesaria una regla de reescritura de salida que realice la transformación en los datos extraídos de A. Las reglas de reescritura se aplican sobre métodos de búsqueda. El tipo de reglas de reescritura que pueden aplicarse varía según el método de búsqueda pertenezca a una relación base o a una vista derivada. Véanse las secciones 5.3 y 7.1.1 para más detalle.


Lenguaje de Definición y Manejo de Datos: VQL 12

4 LENGUAJE DE DEFINICIÓN Y MANEJO DE DATOS: VQL

El lenguaje estructurado SQL (Structured Query Language), es un lenguaje de base de datos normalizado soportado por la mayoría de los gestores de Base de Datos relacionales implantados en el mercado. Virtual DataPort proporciona un lenguaje llamado Denodo VQL (Denodo Virtual Query Language) que extiende SQL para dotarle de las capacidades necesarias para un entorno de integración distribuida utilizando el enfoque EII. VQL, al igual que SQL, está compuesto por comandos, cláusulas, operadores y funciones. Estos elementos se combinan en las instrucciones para crear, actualizar y manipular las bases de datos. Este apartado describe la sintaxis de VQL.

4.1 SENTENCIAS

Existen dos tipos de sentencias:

• Sentencias DDL (Data Definition Language), que permiten crear y definir nuevas relaciones, wrappers, etc. Los comandos DDL son:

o CREATE: Crea o reemplaza nuevas tablas (relaciones base), vistas, procedimientos almacenados, wrappers, datasources, mapas, tipos, bases de datos y usuarios.

o DROP: Elimina elementos como tablas (relaciones base), vistas, procedimientos almacenados, wrappers, datasources, mapas, tipos, bases de datos y usuarios.

o ALTER: Modifica propiedades específicas de una tabla (o relación base) como su configuración de internacionalización, de caché, de “swapping”, reglas de reescritura, etc. También permite realizar modificaciones sobre las descripciones de bases de datos y usuarios, la asignación de permisos de acceso y creación a usuarios y la redefinición de procedimientos almacenados, wrappers y datasources.

o DESC: Muestra la descripción de tipos de datos, vistas, procedimientos almacenados mapas, operadores, wrappers, datasources, bases de datos y usuarios definidos en el servidor. También permite obtener una visión jerárquica de las dependencias de una vista (vistas sobre las que se define junto con los operadores relacionales implicados), y las sentencias VQL requeridas para reconstruir un elemento del catálogo.

o LIST: Enumera los distintos elementos del catálogo (tipos de datos, vistas, etc.)

o GRANT and REVOKE: Permiten establecer o revocar permisos para usuarios sobre bases de datos, vistas y/o procedimientos almacenados.

• Sentencias DML (Data Manipulation Language), que permiten consultar y actualizar datos. Virtual DataPort dispone de las siguientes sentencias DML:

o SELECT, para realizar consultas sobre el servidor.



o INSERT, UPDATE y DELETE, para, respectivamente, realizar inserciones, actualizaciones y borrados.

o BEGIN, COMMIT, ROLLBACK, para, respectivamente, comenzar, confirmar y deshacer una transacción.

o CALL, para invocar procedimientos almacenados.

4.2 SENTENCIA SELECT: CLÁUSULAS

La sentencia SELECT es utilizada para ejecutar consultas y para definir nuevas vistas. Está compuesta por un conjunto de cláusulas. Las cláusulas son condiciones impuestas sobre una sentencia que colaboran en la definición de los datos que se desea definir, seleccionar o manipular. Las cláusulas que soporta el lenguaje son:

• FROM: Permite especificar la relación o relaciones de la cuál se van a seleccionar los datos. Es posible especificar subconsultas.También es posible especificar la invocación a un procedimiento almacenado.

• WHERE: Especifica las condiciones que deben cumplir los datos que se desea seleccionar.

• UNION: Permite realizar la unión de dos sentencias SELECT.

• GROUP BY: Utilizada para agrupar los resultados obtenidos como respuesta a una consulta en función de determinados campos denominados de agregación.

• HAVING: La cláusula HAVING se utiliza para filtrar los registros devueltos por una consulta que utilice la cláusula GROUP BY.

• ORDER BY: Utilizada para ordenar los datos seleccionados, en base al atributo indicado.

• CONTEXT: Utilizada para modificar determinadas opciones de configuración para la ejecución de una consulta determinada.

• TRACE: Permite obtener el plan de ejecución de una sentencia.

4.3 INSERT / UPDATE /DELETE: CLÁUSULAS

Las sentencias INSERT / UPDATE /DELETE permiten, respectivamente, insertar, modificar y borrar tuplas de una vista, actualizando directamente la fuente de datos. Estas sentencias pueden ejecutarse sólo sobre vistas creadas a partir de fuentes de tipo base de datos o de tipo CUSTOM. Además, las vistas deben ser actualizables de acuerdo a la definición del estándar SQL-92 (ver sección 8). La sentencia INSERT permite insertar una nueva tupla de datos en una vista, actualizando directamente la fuente de datos. Soporta las siguientes cláusulas:



• INTO: indica la vista sobre la que se realizará la inserción de datos y los atributos de la misma.

• VALUES: indica el valor para cada atributo de la vista de la nueva tupla insertada.

• SET: sintaxis alternativa al uso de la cláusula VALUES para especificar el valor de cada atributo de la nueva tupla.

La sentencia UPDATE permite modificar una o varias tuplas de datos de una vista, actualizando directamente la fuente de datos. Soporta las siguientes cláusulas:

• UPDATE: permite indicar la vista a actualizar.

• SET: permite indicar qué atributos de la vista serán modificados por la operación, así como el nuevo valor que tomará cada uno de ellos.

• WHERE: especifica la condición que deben cumplir las tuplas a actualizar.

La sentencia DELETE permite eliminar una o varias tuplas de una vista, actualizando directamente la fuente de datos. Soporta las siguientes cláusulas:

• FROM: permite indicar la vista a actualizar.

• WHERE: especifica la condición que deben cumplir las tuplas a eliminar.

Todas las sentencias mencionadas soportan además las siguientes cláusulas:

• CONTEXT: utilizada para modificar determinadas opciones de configuración para la ejecución de una sentencia.

• TRACE: permite obtener el plan de ejecución de una sentencia.

4.4 OPERADORES LÓGICOS

Los operadores lógicos se utilizan para combinar expresiones booleanas (que se evalúan a true o false), utilizadas típicamente en una cláusula WHERE. Los operadores lógicos soportados son:

• AND: Es el "y" lógico. Evalúa dos condiciones y devuelve un valor verdadero sólo si ambas son ciertas.

• OR: Es el "o" lógico. Evalúa dos condiciones y devuelve un valor de verdadero si alguna de las dos es cierta.

• NOT: Es la negación lógica. Se aplica sobre una condición y niega su valor.



4.5 OPERADORES DE COMPARACIÓN

Un operador de este tipo devuelve el valor lógico true o false en función del resultado de evaluación sobre dos o más operandos. Dependiendo de la naturaleza del operador, los operandos pueden tener que pertenecer a un tipo de datos determinado. Cuando el operando derecho de un operador pueda tomar varios valores, estos deben introducirse separados por comas (ver sección 4.8). Los operadores soportados actualmente son:

• ‘<’: Recibe dos operandos que pueden ser de los tipos: int, long, float, double, date, time, money. Se evalúa a true si el primer operando es menor que el segundo.

• ‘<=’: Se aplica sobre dos operandos de los mismos tipos que en el operador ‘<’ y se evalúa a true si el primer operando es menor o igual que el segundo.

• ’>’: Recibe dos operandos que pueden ser de los tipos: int, long, float, double, date, time, money. Comprueba si el primer operando es mayor que el segundo.

• ‘>=’: Se aplica sobre dos operandos de los mismos tipos que el operador ‘>’ y se evalúa a true si el primer operando es mayor o igual que el segundo.

• ‘=’: Recibe dos operandos que pueden ser de los tipos: int, long, float, double, boolean, text, enumerated, date, time, money, link. Evalúa la igualdad entre sus dos operandos.

• ‘<>’: Se aplica sobre los mismos tipos que el operador ‘=’ y se evalúa a true si el primer operando es diferente del segundo.

• ‘like’: Admite como operandos 1 elemento de tipo text y una o más expresiones regulares. Comprueba si la cadena de caracteres es conforme a todas las expresiones regulares recibidas. Cada expresión regular debe seguir el formato estándar en SQL para las expresiones utilizadas con el operador SQL like. Más concretamente, el carácter ‘%’ representa a un segmento de cualquier longitud dentro una cadena de caracteres y el carácter ‘_’ representa a un segmento de longitud 1. Por ejemplo, la expresión ‘%comercio_’ concuerda con cualquier cadena de caracteres que termine con la subcadena ‘comercio’seguida de un carácter cualquiera. Si se desea incluir los carácteres ‘%’ o ‘_’ como parte de una subcadena constante, deben escaparse prefijándolos con el carácter ‘$’. Si se desea incluir el carácter de escape debe escribirse ‘$$’.

Ejemplos: La primera consulta mostrada devuelve aquellas tuplas de la vista internet_inc cuyo atributo summary contenga el texto ‘adsl’. La segunda exige que además contengan el texto ‘error’:

SELECT * FROM internet_inc WHERE summary like '%adsl%' SELECT * FROM internet_inc WHERE summary like '%adsl%','%error%'

• ‘contains’: Admite como operandos 2 elementos de tipo text. El primer operando será un atributo de tipo text procedente de un índice de información no estructurada externo (e.g. datasources tipo Aracne y/o Google Mini). El segundo operando será una expresión de búsqueda booleana escrita en el lenguaje de búsqueda sobre información no estructurada de DataPort.



La sintaxis del lenguaje de búsqueda sobre información no estructurada se describe en la sección 19.1. Sin embargo, es necesario tener presente que las opciones de búsqueda disponible dependen de las capacidades proporcionadas nativamente por la fuente de datos. Por ejemplo, Google Mini no soporta diversas características del lenguaje de búsqueda como, por ejemplo, las búsquedas por proximidad. Por lo tanto, cuando se utilice el operador contains con atributos procedentes de fuentes Google Mini, dichas capacidades no estarán disponibles. La sección 19.2 detalla con exactitud las capacidades de búsqueda soportadas para fuentes Google Mini y para fuentes Aracne. Los wrappers de tipo Custom que permitan el acceso a otras fuentes de datos pueden especificar qué capacidades del lenguaje de búsqueda para contains soportan a través de las Propiedades de Configuración (ver sección 17.3.10.1).

En el caso de vistas derivadas, las capacidades de búsqueda soportadas para un atributo son calculadas por DataPort en función de las capacidades de los atributos de sus vistas base. Es posible ver las capacidades de cada atributo haciendo uso de la sentencia DESC VIEW para consultar el valor de sus Propiedades de Configuración (ver secciones 17.3.6 y 17.3.10.1).

Ejemplos: La siguiente consulta devuelve aquellas tuplas de la vista aracneview cuyo atributo searchablecontent contenga las palabras ‘acme’ e ‘incorporated’:

SELECT * FROM aracneview WHERE searchablecontent contains 'acme AND incorporated’

La siguiente consulta devuelve aquellas tuplas de la vista aracneview cuyo atributo searchablecontent contenga la frase exacta “acme incorporated” y alguna palabra que comience por ‘product’:

SELECT * from aracneview WHERE searchablecontent contains '"acme incorporated "AND product*'

• ’containsor’: Admite como operandos 2 ó más elementos de tipo text. Comprueba si la primera cadena contiene al menos una de las restantes cadenas que recibe.

• ‘isContained’: Admite como operandos 2 o más elementos de tipo text. Comprueba si la primera cadena está contenida en todas las restantes cadenas que recibe.

• ‘is not NULL’: Se aplica sobre un único operando, que puede pertenecer a los siguientes tipos de dato: int, long, float, double, boolean, text, enumerated, date, time, money y link. Comprueba si el valor no es nulo, es decir, si tiene algún valor.

• ‘is NULL’: Recibe un operando que puede ser de uno de los siguientes tipos de dato: int, long, float, double, boolean, text, enumerated, date, time, money y link. Evalúa si su valor es nulo, es decir, si no tiene valor.

• ‘is TRUE’: Se aplica sobre un único operando de tipo boolean. Devuelve el valor lógico del operando (es decir, true sí y sólo sí su valor es true; false en caso contrario).

• ‘is FALSE’: Recibe un operando de tipo boolean. Devuelve la negación del valor lógico del operando (es decir, true sí el operando se evalúa a false; false en caso contrario).



• ‘in’: Recibe una lista de operandos que puede ser de uno de los siguientes tipos de dato: int, long, float, double, text, enumerated, date, time, money y link. Devuelve true si el operando de la parte izquierda está incluido en la lista de operandos de la parte derecha. La lista de operandos puede ir o no entre paréntesis.

Ejemplo: Las dos siguientes sentencias producen el mismo resultado: seleccionan aquellas tuplas de la vista internet_inc tales que su valor para el atributo taxid es igual o bien al valor 'B78596011' o al valor 'B78596012':

SELECT * FROM internet_inc WHERE taxid in ('B78596011','B78596012') SELECT * FROM internet_inc WHERE taxid in 'B78596011','B78596012'

• ‘between’: Se aplica sobre tres operandos que pueden ser de alguno de los siguientes tipos de datos: int, long, float, double, date, time y money. Devuelve true si el operando de la parte izquierda se encuentra dentro del rango especificado por los otros dos operandos, incluyendo los valores límite. Como sintaxis alternativa, los operandos que delimitan el rango pueden separarse con la palabra AND.

Ejemplo: Las dos siguientes sentencias producen el mismo resultado: seleccionan aquellas tuplas de la vista internet_inc tales que su valor para el atributo iinc_d está en el rango entre 2 y 4 (inclusives):

SELECT * FROM internet_inc WHERE iinc_id between 2 AND 4 SELECT * FROM internet_inc WHERE iinc_id between 2,4

• ‘~’. La evaluación de este operador devuelve un valor entre 0 y 1 que estima la similitud entre dos operandos de tipo text, utilizando una variedad de algoritmos de similitud. Además de los operandos a comparar, el operador de similitud recibe como parámetros el algoritmo de similitud a utilizar y un umbral mínimo de similitud. Si la similitud entre las cadenas de caracteres alcanza o supera el umbral, la condición se evalua como verdadera. En caso contrario, se evalua como falsa. El operando izquierdo (de tipo text) es una de las cadenas de caracteres a comparar. El operando derecho es una lista de elementos de tipo text. El primer elemento de dicha lista es la segunda cadena de caracteres a comparar. El segundo especifica el umbral mínimo de similitud (un valor entre 0 y 1) y el tercero (opcional) especifica el algoritmo de similitud que se desea utilizar. Los algoritmos disponibles son los mismos que para la función similarity (ver sección 4.6.2).

Ejemplo: La siguiente consulta devuelve aquellas tuplas cuyo campo customername tenga una similitud superior a 0.7 con la cadena ‘General Motors Inc’, utilizando el algoritmo de distancia de edición entre cadenas de Jaro Winkler:

SELECT * FROM internet_inc_cname WHERE customer_name ~ 'General Motors Inc','0.7','JaroWinkler'

NOTA: Los valores de tipo de dato blob no pueden participar en condiciones de consulta.



4.6 FUNCIONES DE ATRIBUTO DERIVADO Y CONDICIONES

Las funciones de atributo derivado se utilizan para generar nuevos atributos en el esquema de una vista, aplicando algún procesamiento sobre los valores de los otros atributos de la vista, sobre constantes y/o sobre el resultado de evaluar otras funciones. Estas funciones pueden utilizarse también como operandos en las condiciones. Una función se define como un identificador y una lista de argumentos, que pueden ser a su vez constantes, campos o nuevas funciones. En algunos casos (un subconjunto de las funciones aritméticas y de las de manejo de texto), los parámetros recibidos por una función, así como el valor que será devuelto por ellas, deben normalmente pertenecer todos al mismo tipo de datos. Por ejemplo, la función SUM puede realizar la suma de dos o más valores enteros, de dos o más valores en punto flotante o de dos o más valores de tipo double pero no realizará, la suma de un valor entero y de un valor en punto flotante. Además, algunas funciones, sólo operarán con elementos pertenecientes a un tipo de dato concreto. Virtual DataPort proporciona una serie de funciones predefinidas, que pueden agruparse en diferentes tipos, en base al tipo de datos sobre las que se aplican:

- Funciones aritméticas - Funciones para el manejo de texto - Funciones para el manejo de fechas - Funciones de conversión de tipos. - Funciones para el manejo de elementos de tipo XML. - Otras funciones.

En los siguientes apartados se describen las funciones soportadas por el sistema. NOTA: La notación de funciones es, en general, prefija, es decir, se indica un identificador seguido de una lista de parámetros entre paréntesis y separados por comas. Para algunas funciones existe también notación infija (por ejemplo, para algunas funciones aritméticas).

4.6.1 Funciones Aritméticas

Las funciones aritméticas se aplican sobre atributos y literales de tipo numérico, int, long, float, double, time y money, con la restricción de que todos los parámetros deben de poseer el mismo tipo. Permiten realizar cálculos matemáticos sobre atributos y literales. Las funciones aritméticas soportadas son:

• SUM: La función suma recibe un número variable de argumentos (mayor o igual a dos) y devuelve como resultado un nuevo elemento del mismo tipo conteniendo la suma de los anteriores. La versión infija de esta función recibe dos argumentos y se representa con el símbolo ‘+’.

• SUBTRACT: La función resta recibe dos argumentos y devuelve un nuevo elemento del mismo tipo con el resultado de restar del primer argumento el valor del segundo. La versión infija de esta función recibe dos argumentos y se representa con el símbolo ‘-‘.

• MULT: La función producto recibe un número variable de argumentos (mayor o igual a dos) y devuelve un nuevo elemento del mismo tipo con el resultado del producto entre los diferentes argumentos. La versión infija de esta función recibe dos argumentos y se representa por el símbolo ‘*’.

• DIV: La función división recibe dos argumentos de tipo numérico y devuelve un nuevo elemento del mismo tipo con el resultado de dividir el primer argumento por el segundo. Si los argumentos son enteros, el resultado de la división será también entero. La versión infija de esta función recibe dos argumentos y se representa con el símbolo ‘/’.



• MIN: La función mínimo recibe un número variable de argumentos (mayor o igual a dos) y devuelve como resultado el valor del menor argumento de la lista.

• MAX: La función máximo recibe un número variable de argumentos (mayor o igual a dos) y devuelve como resultado el valor del mayor argumento de la lista.

• ABS: La función valor absoluto recibe un único argumento de tipo numérico y devuelve como resultado su valor absoluto.

• MOD: La función módulo recibe dos argumentos de tipo numérico o money devuelve el resultado de la operación módulo entre el primer argumento y el segundo (el resto de la división entera entre el primer argumento y el segundo). La versión infija de esta función recibe dos argumentos y se representa con el símbolo ‘%’.

• CEIL: Esta función recibe un argumento numérico y devuelve el menor entero, mayor o igual que el argumento, más próximo al argumento. Si el argumento es de tipo int, devuelve un valor de tipo int. Si el argumento es de tipo long, float o double, el valor devuelto es de tipo long. Si el argumento es de tipo time o money, el valor devuelto es del mismo tipo.

• FLOOR: Esta función recibe un argumento numérico y devuelve el mayor entero, menor o igual que el argumento, más próximo al argumento. Si el argumento es de tipo int, devuelve un valor de tipo int. Si el argumento es de tipo long, float o double, el valor devuelto es de tipo long. Si el argumento es de tipo time o money, el valor devuelto es del mismo tipo.

• ROUND: Esta función recibe un argumento numérico y devuelve como resultado el número entero más próximo al argumento. Si el argumento es de tipo int, devuelve un valor de tipo int. Si el argumento es de tipo long, float o double, el valor devuelto es de tipo long. Si el argumento es de tipo time o money, el valor devuelto es del mismo tipo.

• POWER: Esta función recibe dos argumentos numéricos, el segundo de los cuáles debe ser entero. Devuelve como resultado un valor de tipo double obtenido mediante la exponenciación del primer argumento con el segundo como exponente.

• SQRT: Esta función recibe un argumento numérico y devuelve un valor de tipo double con el resultado de obtener la raíz cuadrada del argumento.

• LOG: Esta función recibe un valor numérico y devuelve un valor de tipo double con el resultado de obtener el logaritmo en base 10 del argumento.

4.6.2 Funciones de Manejo de Texto

Las funciones de manejo de texto tienen como objetivo realizar alguna transformación o cálculo sobre un atributo o literal de tipo texto.

• TEXTCONSTANT: Esta función permite crear un elemento de tipo texto a partir del literal que se pasa como parámetro (sólo necesario en la cláusula SELECT).



• CONCAT: La función concatenación recibe un número variable de argumentos, y permite obtener un elemento de tipo texto como resultado de concatenar sus parámetros. La versión infija de esta función recibe 2 argumentos y se representa con el símbolo ‘||’.

• LEN: La función len recibe como parámetro un argumento de tipo texto, y devuelve el número de caracteres que lo forman.

• REPLACE: Esta función recibe 3 argumentos de tipo texto y devuelve el resultado de reemplazar en el primero las ocurrencias del segundo, por el tercero.

• REPLACEMAP: Esta función recibe como entradas un texto y un mapa de transformaciones especificando una serie de textos (a los que llamaremos claves) que deben ser reemplazados por otros (a los que llamaremos valores de reemplazo) en el texto original. En el. Tiene dos posibles firmas:

o REPLACEMAP (originalText: text, mapName: text). Las claves y los valores de reemplazo se especifican mediante un mapa clave-valor definido por el administrador (en la sección 11.2 se describe la forma de crear mapas). La función recibe dos argumentos: el primero indica el texto sobre el que realizar las transofrmaciones y el segundo el nombre del mapa.

o REPLACEMAP (key: text, viewName: text, keyField:text, valueField:text). Las claves y los valores de reemplazo se especifican mediante una vista DataPort. Recibe cuatro parámetros: el texto sobre el que realizar las transofrmaciones, el nombre de la vista conteniendo el mapa de transformaciones, el nombre del atributo de la vista que contiene las claves y el nombre del atributo de la vista que contiene los valores de reemplazo.

Ambas firmas devuelven un elemento de tipo text conteniendo el texto original una vez que todas las transformaciones especificadas se han realizado (si la clave no existiese, se devuelve null). La clave es insensible a mayúsculas/minúsculas.

Ejemplo: Supóngase que el mapa test contiene las correspondencias:

ADSL -> DSL Error -> Warning

La siguiente consulta devuelve tuplas con un atributo llamado new_summary cuyos valores son obtenidos tomando el valor del atributo summary de la vista internet_inc y sustituyendo las ocurrencias de la palabra “ADSL” por “DSL” y de la palabra “Error” por la palabra “Warning”.

SELECT REPLACEMAP (summary,'test') AS new_summary FROM internet_inc

• LOWER: Esta función recibe un argumento de tipo texto y lo devuelve a la salida con todos los caracteres que lo forman convertidos a minúsculas.

• UPPER: Esta función recibe un argumento de tipo texto y lo devuelve a la salida con todos los caracteres que lo forman convertidos a mayúsculas.



• SUBSTRING: La función substring recibe como parámetros un argumento de tipo texto y dos números enteros. Devuelve a la salida la parte del substring del primer argumento que se corresponde a las posiciones indicadas por el segundo (inicio) y tercer (fin) argumentos.

• REGEXP: Esta función permite realizar transformaciones sobre cadenas de caracteres basadas en expresiones regulares. Recibe tres argumentos: un elemento de tipo texto, una expresión regular “de entrada” y una expresión regular “de salida”. Las expresiones regulares deben expresarse utilizando la sintaxis de expresiones regulares del lenguaje JAVA [11]. La función se comporta de la forma siguiente: la expresión regular de entrada se evalúa contra el texto del primer argumento y la expresión regular de salida puede incluir los “grupos” definidos en la expresión regular de entrada. Las porciones de texto que hayan encajado con los mismos se sustituirán en la expresión de salida. Por ejemplo, el resultado de evaluar:

REGEXP(‘Shakespeare,William’,‘(\w+),(\w+)’,‘$2 $1’) será el valor de tipo texto ‘William Shakespeare’.

• TRIM: Esta función recibe un argumento de tipo texto y devuelve el mismo argumento, una vez le ha eliminado espacios y retornos de carro iniciales y finales.

• REMOVEACCENTS: Esta función recibe un argumento de tipo texto y devuelve el mismo argumento, una vez le ha eliminado los acentos.

• SIMILARITY(value1: text, value2: text, algorithm:text): Esta función recibe dos cadenas de caracteres y devuelve un valor entre 0 y 1, que es una medida de la similitud estimada entre las cadenas. El tercer parámetro (opcional) especifica el algoritmo a utilizar para calcular la medida de similitud. DataPort incluye los siguientes algoritmos (si no se especifica ningún algoritmo, DataPort escogera cuál aplicar):

o Basados en la distancia de edición entre las cadenas de los textos: ScaledLevenshtein, JaroWinkler, Jaro, Level2Jaro, MongeElkan, Level2MongeElkan.

o Basados en la aparición de términos comunes en los textos: TFIDF, Jaccard, UnsmoothedJS.

o Combinaciones de ambos: JaroWinklerTFIDF.

Ejemplo: La siguiente consulta devuelve aquellas tuplas cuyo campo customername tenga una similitud superior a 0.7 con la cadena ‘General Motors Inc’, utilizando el algoritmo de distancia de edición entre cadenas de Jaro-Winkler:

SELECT * FROM internet_inc_cname WHERE similarity(customer_name,'General Motors Inc','JaroWinkler') > 0.7

4.6.3 Funciones de Manejo de Fechas

Las funciones de manejo de fechas permiten obtener fechas y elementos concretos de una fecha.

• NOW: Esta función no recibe ningún argumento y crea un objeto de tipo date conteniendo la fecha actual.



• GETDAY: Recibe un argumento de tipo date y devuelve un objeto de tipo long que representa el día de la fecha recibida.

• GETHOUR: Recibe un argumento de tipo date y devuelve un objeto de tipo long que representa la hora de la fecha recibida.

• GETMINUTE: Recibe un argumento de tipo date y devuelve un objeto de tipo long que representa el minuto de la fecha recibida.

• GETSECOND: Recibe un argumento de tipo date y devuelve un objeto de tipo long que representa el segundo de la fecha recibida.

• GETTIMEINMILLIS: Recibe un argumento de tipo date y devuelve un objeto de tipo long que representa el número de milisegundos transcurridos desde el 1 de Enero de 1970 a las 00:00:00 GMT hasta la fecha recibida como parámetro. el segundo de la fecha recibida.

• GETMONTH: Recibe un argumento de tipo date y devuelve un objeto de tipo long que representa el mes de la fecha recibida.

• GETYEAR: Recibe un argumento de tipo date y devuelve un objeto de tipo long que representa el año de la fecha recibida.

• TO_DATE: Permite convertir cadenas de texto que representan fechas en elementos de tipo date. Recibe tres argumentos de tipo texto. El primero de ellos representa un patrón para expresar fechas (siguiendo la sintaxis estándar en el lenguaje JAVA especificada en [12]) mientras el segundo será una fecha expresada de acuerdo al mencionado patrón. El tercero, opcional, es un parámetro de tipo texto que indica la configuración de internacionalización que representa el “locale” de la fecha a procesar. Como resultado se devuelve un elemento de tipo date equivalente a la fecha especificada.

4.6.4 Funciones de Conversión de Tipos

Estas funciones permiten realizar diversas transformaciones entre datos de tipos diferentes.

• CAST: Esta función recibe dos argumentos. El primero especifica el nombre de un tipo de datos y el segundo especifica un valor que se desea convertir a dicho tipo de datos. La siguiente tabla muestra las conversiones de tipo posibles:

Tipo Destino Tipos Origen array array blob text, blob boolean text, int, long, float, double, boolean date text, date, long double text, int, long, float, double, time, money enumerated text, enumerated float text, int, long, float, double, time, money int text, int, long, float, double, time, money link text, link long text, int, long, float, double, time, money, date



money text, int, long, float, double, money register xml, register text text, int, long, float, double, boolean, date, time, xml,

money, link, blob, enumerated, register, array Time text, long, int, time Xml text, xml

Tabla 1 Conversiones de tipos permitidas con la función CAST

• TO_DATE: Permite convertir cadenas de texto que representan fechas en elementos de tipo date. Ver sección 4.6.3.

• CREATETYPEFROMXML: Esta función crea un tipo compuesto register (ver sección 18.1) partiendo de un elemento de tipo XML. Recibe dos argumentos: el primero es de tipo texto y debe contener el nombre del nuevo tipo mientras el segundo es el elemento XML. Véase la sección 4.6.5 para más detalle.

4.6.5 Funciones de manejo de XML

Estas funciones permiten crear y manejar elementos de tipo XML.

• XPATH: Esta función aplica una expresión Xpath [13] sobre un elemento de tipo XML. Recibe dos argumentos obligatorios: un elemento de tipo XML y un texto conteniendo la expresión Xpath. Devuelve un elemento XML con el resultado de la aplicación de la expresión. Opcionalmente puede recibir un tercer parámetro de tipo boolean; cuando este tercer parámetro tome el valor true, se añadirá al resultado la cabecera XML (“<?xml version="1.0" encoding="UTF-8"?>). Nótese que el resultado de aplicar una expresión Xpath puede ser un valor individual (entero, texto, etc.). En ese caso es posible utilizar la función CAST para convertirlo al tipo correspondiente de Virtual DataPort.

• CREATETYPEFROMXML: Esta función crea un tipo compuesto register (ver sección 18.1) que reproduce el esquema de un elemento XML de ejemplo. Recibe dos argumentos: el primero es de tipo texto y debe contener el nombre del nuevo tipo mientras que el segundo es una cadena de caracteres conteniendo un ejemplo del elemento XML (de tipo text). El esquema del tipo compuesto será inferido por DataPort analizando la estructura del elemento XML. Devuelve el nombre del nuevo tipo creado. Véase la siguiente sub-sección para un ejemplo.

4.6.5.1 Convirtiendo datos XML en tipos compuestos de Virtual DataPort

Combinando las funciones CAST y CREATETYPEFROMXML es posible crear en una vista nuevos atributos compuestos de tipo register (ver sección 18.1) partiendo de datos XML. Considérese el siguiente ejemplo: supongamos una vista V con un atributo llamado PERSONAL_DATA_XML de tipo XML. Supondremos también que cada valor del atributo PERSONAL_DATA_XML contiene código XML de la forma:

<person> <name> John Smith </name> <age> 25 </age> </person>

Considérese ahora la siguiente expresión:

CREATE VIEW PERSON AS



SELECT CAST(CREATETYPEFROMXML('personaldata_type', '<person><name> John Smith </name><age> 25 </age></person>'),PERSONAL_DATA_XML) PERSONALDATA FROM V

El atributo derivado PERSONALDATA de la vista PERSON sería de tipo personaldata_type, que sería un tipo register compuesto por los campos name (de tipo text) y age (de tipo long). Nótese que el segundo parámetro de la función CREATETYPEFROMXML debe ser un ejemplo de los valores contenidos en el campo PERSONAL_DATA_XML de la vista V. Convertir datos de tipo XML en datos de tipos compuestos de DataPort permite combinar los datos contenidos en el código XML con los datos provenientes de otras relaciones. Por ejemplo, supongamos que tenemos una vista RISK_LEVEL que tiene dos atributos llamados age (de tipo long) y risk (de tipo double) que recoge algún tipo de índice de riesgo calculado en función de la edad de un individuo. Sería posible hacer una operación de join entre la vista PERSON y la vista RISK_LEVEL utilizando para ello el atributo age de RISK_LEVEL y el campo age del atributo PERSONALDATA de la vista PERSON.

4.6.6 Otras funciones

En esta sección se agrupan funciones misceláneas:

• HASH: Esta función recibe un único argumento de tipo text y devuelve un HASH MD5 del mismo.

• MAP: Esta función permite obtener el valor asociado a una determinada clave en un mapa de conversión de valores. Tiene dos posibles firmas:

o MAP (key: text, mapName: text, i18nConf:text). Permite obtener el valor asociado a una determinada clave en un mapa clave-valor definido por el administrador (en la sección 11.2 se describe la forma de crear mapas). La función recibe tres argumentos: el primero indica la clave deseada y el segundo el nombre del mapa. El tercero (opcional y de tipo text) especifica el nombre de la configuración de internacionalización que debe aplicarse al nuevo valor creado.

o MAP (key: text, viewName: text, keyField:text, valueField:text). Permite obtener el valor asociado a una determinada clave en base a los valores contenidos en una vista DataPort. Recibe cuatro parámetros: la clave deseada, el nombre de la vista conteniendo el mapa de conversiones, el nombre del atributo de la vista que contiene las claves y el nombre del atributo de la vista que contiene los valores.

Ambas firmas devuelven un elemento de tipo text con el valor asociado para la clave especificada (si la clave no existiese, se devuelve null). La clave es insensible a mayúsculas/minúsculas.

• COALESCE: Esta función recibe un número variable de argumentos (mayor o igual a dos) de un mismo tipo y devuelve como resultado el primer argumento no nulo.

• CONTEXTUALSUMMARY: Esta función obtiene un resumen contextual de un texto en base a una búsqueda por palabra clave. Se obtendrán una serie de fragmentos del texto que contengan la palabra o frase especificada. Presenta la siguiente firma:



• CONTEXTUALSUMMARY(content:text, keyword:text, [beginDelim:text, endDelim:text, fragmentSeparator:text, fragmentLength:int [,maxFragmentsNumber:int]]), donde:

o content: El texto a analizar y del que se desea extraer los fragmentos más relevantes. (obligatorio)

o keyword: La palabra clave utilizada para extraer los fragmentos del texto. (obligatorio). El contenido de este argumento puede ser una única palabra o una frase.

o beginDelim: Texto a añadir como prefijo de la palabra clave cuando ésta aparezca en el texto. (opcional, valor por defecto "")

o endDelim: Texto a añadir como sufijo de la palabra clave cuando ésta aparezca en el texto. (opcional, valor por defecto "")

o fragmentSeparator: Texto a utilizar como separador de los diferentes fragmentos de texto obtenidos como resultado. (opcional, el valor por defecto es " ...")

o fragmentLength: Número aproximado de palabras que aparecerán antes y después de las ocurrencias de la palabra clave dentro del texto (opcional, el valor por defecto es 5).

o maxFragmentNumber: Número máximo de fragmentos a obtener.

4.7 FUNCIONES DE AGREGACIÓN

Las funciones de agregación se usan dentro de un comando SELECT para devolver un único valor por cada grupo de tuplas resultado de una operación de agrupamiento. Las funciones de agregación reciben como parámetro una expresión indicando el nombre del atributo sobre el que se aplica. Opcionalmente, este parámetro puede estar precedido por uno de dos modificadores: ALL ó DISTINCT. Estos modificadores afectan a la semántica de algunas funciones de agregación, aplicándolas sobre todas las tuplas de un grupo o sólo sobre las que presenten distinto valor para el atributo considerado. A continuación se enumeran las diferentes funciones de agregación:

• AVG: Utilizada para calcular el promedio de los valores de un atributo determinado. Aplicable sobre atributos de tipo int, long, float, double, time y money. Devuelve un valor de tipo double.

• COUNT: Utilizada para devolver el número total de tuplas resultado de una operación de selección (si se especifica como atributo el carácter especial ‘*’) o el número de tuplas que tienen valor no nulo para un atributo concreto. Aplicable sobre cualquier tipo de atributo. Se puede utilizar esta función de agregación sin especificar una clausula de GROUP BY, pero en ese caso, sólo puede aplicarse sobre el atributo de carácter especial ‘*’ para contabilizar el número total de tuplas devueltas.

• SUM: Utilizada para devolver la suma de todos los valores de un atributo determinado que no sean nulos. Aplicable sobre atributos de tipo int, long, float, double, time y money.

• MAX: Utilizada para devolver el valor más alto de un atributo especificado. Aplicable sobre atributos de tipo int, long, float, double, time y money. La implementación de esta función ignora el modificador ALL/DISTINCT.



• MIN: Utilizada para devolver el valor más bajo de un atributo especificado. Aplicable sobre atributos de tipo int, long, float, double, time y money. La implementación de esta función ignora el modificador ALL/DISTINCT.

• FIRST: Utilizada para devolver el valor de un atributo de la primera tupla de cada grupo de valores. Aplicable sobre cualquier tipo de atributo. La implementación de esta función ignora el modificador ALL/DISTINCT.

• LAST: Utilizada para devolver el valor de un atributo de la última tupla de cada grupo de valores. Aplicable sobre cualquier tipo de atributo. La implementación de esta función ignora el modificador ALL/DISTINCT.

• LIST: Función de agregación que devuelve una lista con todos los valores de un atributo especificado, para cada grupo. Aplicable sobre cualquier tipo de atributo.

4.8 CONVENCIONES DE SINTAXIS

Los siguientes apartados de este documento describen las diferentes operaciones que se pueden realizar sobre Virtual DataPort, en base a las instrucciones que forman parte del lenguaje VQL. A continuación se listan las convenciones de notación y sintaxis utilizadas para esta descripción.

• El lenguaje no es sensible a mayúsculas y minúsculas.

• El texto en minúsculas y especificado entre los símbolos ‘<’ y ’>’ (<name>) indica un elemento cuya sintaxis concreta será especificada posteriormente. Si aparece el separador ‘:’ (e.g. <name:element-definition>), entonces indica un nombre de elemento representativo y a continuación el nombre del elemento que lo define.

• Los símbolos ‘::=’ declaran la definición de un elemento.

• Los corchetes ([]) indican elementos opcionales. También se utiliza para acceder a elementos de un array o para definir un parámetro multivaluado de una función. En estos casos se especifica entrecomillada para indicar explícitamente que deben aparecer, y que no indican elementos opcionales.

• El asterisco (*) indica que un elemento se puede especificar cero o más veces. Ejemplo: [<search_method_clause>]* indica que el elemento [<search_method_clause>] se puede repetir tantas veces como sea necesario. Posee un significado especial cuando se utiliza en la sentencia SELECT o con la función de agregación COUNT.

• El signo suma (+) indica que un elemento se puede especificar una o más veces. Ejemplo: [<field>]+ indica que el elemento [<field>] debe aparecer al menos una vez y se puede repetir tantas veces como sea necesario.

• Elementos separados por el carácter "|", y agrupados entre llaves (), indican elementos alternativos. Por ejemplo: elemento1 | elemento2 indica que en esa posición habrá que escribir el elemento1 o el elemento2.



• Las comas (,) se utilizan en construcciones sintácticas para separar elementos de una lista.

• Los paréntesis (()) sirven normalmente para agrupar expresiones y reforzar la precedencia. En algunos casos se exigen como parte de la sintaxis particular de una sentencia.

• El punto (.) se utiliza en las constantes numéricas y para separar nombres de tablas, columnas y campos.

• El carácter de espacio en blanco puede ser un espacio, un tabulador, un retorno de carro o un salto de línea.

• Identificadores (<identifier>). Los identificadores permiten asociar nombres a los diferentes elementos del catálogo y son en general alfanuméricos a los que se exige que no puedan comenzar por un número. Existen una serie de palabras reservadas que no pueden ser utilizadas como identificadores (ver Figura 3).

• Números (<number>). Un número es una combinación de dígitos, que pueden estar precedidos por un signo ‘-‘ y pueden incluir un punto como carácter separador decimal y opcionalmente un exponente (si se trata de números reales).

• Valores lógicos (<boolean>). Representación de los valores lógicos “true” y “false”.

• Literales (<literal>). Permiten definir cualquier cadena de caracteres entrecomillándola (comillas simple o dobles). Los caracteres comilla simple o doble (dependiendo del caso) deben ser escapados (carácter de escape \’ y \” respectivamente).

• Operadores (<operator>). Permiten definir los operadores del sistema, que pueden estar representados por identificadores, por una combinación de los símbolos definidos para <opsymbol> o las expresiones “is null”, “is not null”, “is true” “is false”.



<identifier> ::= [A-Za-z\200-\377_][A-Za-z\200-\377_0-9\$]* <integer> ::= [-][0-9]+ <number> ::= <integer> | (([0-9]*\.[0-9]+)|([0-9]+\.[0-9]*)) ((([0-9]*\.[0-9]+)|([0-9]+\.[0-9]*)|([0-9]+))([Ee][-+][0-9]+)) <boolean> ::= true | false <literal> ::= '[^\']*' | "[^\"]*" <operator> ::= <unary operator> | <binary operator> <opsymbol> ::= [\~\!\@\#\^\&\|\'\?\<\>\=]+ <unary operator> ::= is null | is not null | is true | is false <binary operator> ::= = | <identifier> | <opsymbol> <reserved VQL word> ::= ADD, ALL, ALTER, AND, ANY, ARN, AS, ASC, BASE, CALL, CLEAR, CONNECT,CONTEXT, CREATE, CROSS, CUSTOM, DATABASE, DEFAULT, DESC, DF, DISTINCT, DROP, EXCEL, EXISTS, FALSE, FIELD, FILTER, FROM, FULL, GRANT, GROUP BY, GS, HASH, HAVING, HTML, IF, INNER, IS, JDBC, JOIN, LDAP, LEFT, MERGE, MY, NATURAL,NESTED, NOS, NOT, NULL, OBL, ODBC, OF, OFF, ON, ONE, OPT, OR, ORDER BY, ORDERED, PRIVILEGES, RAW, RAWPATTERNS, READ, REVERSEORDER, REVOKE, RIGHT, ROW, SELECT, SWAP, TABLE, TO, TRACE, TRUE, UNION, USER, USING, VDB, VIEW, WHERE, WITH, WRITE, WS, ZERO

Figura 3 Primitivas básicas para la especificación de sentencias VQL

4.8.1 Sintaxis de funciones y valores de condiciones

Tal y como se ha ido comentando a lo largo de este manual, en Virtual DataPort existen diferentes tipos de funciones que se pueden utilizar para diversos propósitos. Un primer tipo de funciones son las que calculan un valor a partir de una tupla. Las funciones de este tipo se referencian en condiciones de consulta o se utilizan para obtener un atributo derivado. Otro tipo de funciones, son las funciones de agregación, que calculan un valor a partir de un conjunto de tuplas. También existen las funciones de transformación que actúan en las reglas de reescritura. Virtual DataPort utiliza una sintaxis de funciones genérica común para la representación de todas las funciones existentes en el sistema. Dicha sintaxis se muestra en la Figura 4. <field name> ::= <identifier>[.<identifier>] | <identifier>[.<identifier>]'['<integer>']' [<compound field name>]* | (<identifier>[.<identifier>])[<compound field name>]* <compound field name> ::= .<identifier> | '['<integer>']' <funcsymbol> ::= [\+\-\*\/\%]+ <value> ::= <field name> | <number> | <boolean> | <literal> | <function>



| <value> <funcsymbol> <value> | ( <value> ) | <rowvalue> | <rowvalue> [, <rowvalue>]* <rowvalue> ::= ROW( <value> [, <value>]* ) <function> ::= <identifier> ( [ [<function modifier>] <function parameter> [, <function parameter>]* ] ) <function parameter> ::= * | <value> | '[' [ <value>, [ <value> ]* ] ']' <function modifier> ::= ALL | DISTINCT

Figura 4 Reglas para la formación de funciones

Para definir la sintaxis de una función, es necesario definir previamente los siguientes elementos:

• El elemento <field name> define la sintaxis para especificar un atributo de una relación, en el que puede aparecer el nombre de la relación y la referencia a campos de elementos de tipos compuestos (ver sección 18.1 para una descripción detallada del soporte de tipos compuestos).

• El elemento <value> define la sintaxis para cualquier parámetro de una función, que puede ser un nombre de un atributo, una constante numérica, booleana o literal. También es posible crear un valor compuesto utilizando el constructor ROW (ver sección 6.3.1). Como se puede observar, el parámetro de una función puede ser a su vez una nueva función. Además, un <value> permite especificar notaciones infijas para una función (véase la regla <value> <funcsymbol> <value>).

Una vez descritos los elementos básicos de una función, podemos definir una función como un identificador seguido por una lista de parámetros, entre paréntesis y separados por comas. Los parámetros de una función pueden ser “*”, univaluados (elementos <value>) o multivaluados (elementos <value>, entre corchetes y separados por comas). La sintaxis que se ha explicado con anterioridad es común para todos los tipos de funciones existentes en Virtual DataPort. Sin embargo, pueden existir algunas particularidades para algún tipo de función. Estas particularidades, cuando existen, se comentan en la sección del manual correspondiente a cada tipo de función. Por último, es importante recordar que el formato a utilizar para escribir constantes de tipo date, money y double en las consultas sobre una vista viene fijado por la configuración de internacionalización que se esté utilizando sobre la misma. Véase la sección 18.3 para más información sobre los distintos parámetros de una configuración de internacionalización y la sección 13 para saber cómo consultar los parámetros asignados al mapa de internacionalización asignado a una configuración concreta.


Creación de una Relación Base (o Vista Base) 30

5 CREACIÓN DE UNA RELACIÓN BASE (O VISTA BASE)

La sentencia CREATE TABLE permite la creación de una relación base (también llamada vista base) en Virtual DataPort. Una relación base representa en el sistema EII información que proviene directamente de una fuente externa (web, relacional, etc.). La sintaxis de la sentencia CREATE TABLE se muestra en la Figura 5. Cada relación o vista base se compone de un conjunto de atributos. Cada atributo de una relación pertenecerá a un tipo de dato. El tipo de un determinado atributo determina qué operadores pueden aplicarse sobre él. El esquema de la vista se corresponde con los atributos que componen cada tupla que pertenece a la relación base y los tipos de dato a los que pertenece cada atributo. En la creación de la relación base se especifica su nombre, su configuración de internacionalización y su esquema. CREATE [ OR REPLACE ] TABLE <name:identifier> I18N <name:identifier> ( <field> [, <field> ]* )

<field> ::= <name:identifier>:<type:identifier> [ ( <property list> ) ]

<property list> ::= <name:identifier> [= <value:identifier>] [, <name_i:identifier> [= <value_i:identifier>] ]*

Figura 5 Sintaxis de la sentencia CREATE TABLE

El uso del modificador OR REPLACE permite especificar que, si ya existe una vista base con el nombre indicado, ésta debe ser reemplazada por la nueva vista. En caso de que debido al cambio de definición de la vista, las capacidades de consulta (ver sección 5.2) 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á automáticamente el esquema y las capacidades de consulta de las vistas derivadas siempre que sea posible. En la Figura 6 se muestra la creación de una vista base a través de la sentencia CREATE TABLE. Se crea una vista base de nombre ‘book’, con internacionalización española (es_euro) y con dos atributos TITLE y AUTHOR de tipo texto. CREATE TABLE book I18N es_euro ( title:TEXT, author:TEXT );

Figura 6 Ejemplo de creación de una vista base

5.1 MODIFICACIÓN DE UNA RELACIÓN BASE

Utilizando la sentencia ALTER TABLE es posible configurar las siguientes propiedades específicas de una relación base: su configuración de internacionalización, su configuración de caché, su configuración de “swapping”,



añadir, eliminar o modificar un método de búsqueda y añadir, eliminar o modificar una regla de reescritura. En la Figura 7 se muestra la sintaxis de ALTER TABLE. Una vez creada y definida la estructura de una relación base, es necesario especificar sus métodos de búsqueda para que el servidor pueda saber qué consultas se pueden ejecutar sobre la información de la fuente que representa. Los métodos de búsqueda se componen de reglas que representan las restricciones que una consulta determinada debe cumplir para que pueda ser ejecutada utilizando ese método de búsqueda. Además, cada método de búsqueda tendrá asociado un wrapper que poseerá la información necesaria para traducir la consulta del usuario a la fuente e interpretar su respuesta. La sección 5.2 proporciona más detalle sobre este aspecto. También es posible aplicar a los métodos de búsqueda de una relación base reglas de reescritura sobre consultas (que reescriben consultas antes de enviarlas a la fuente, para adaptarlas a los formatos que la fuente precisa), o sobre los resultados (que reescriben los resultados obtenidos de la fuente para adaptarlos a otro formato deseado), para el tratamiento de las representaciones heterogéneas de información procedente de varias fuentes. La sección 5.3 se ocupa con detalle de las reglas de reescritura. El comando ALTER TABLE también permite indicar si la relación base debe ser cacheada (CACHE ON), es decir, si deben materializarse o no en la cache local las tuplas que se vayan extrayendo de la fuente como resultado de la ejecución de consultas. La sección18.2.2 se ocupa de este aspecto con más detalle. Finalmente, es posible configurar la política de “swapping” a disco utilizada por DataPort al ejecutar consultas sobre la relación base que involucren gran número de tuplas. Véase la sección 18.2.3 para una descripción detallada. ALTER TABLE <name:identifier> [ I18N <name:identifier> ] [ CACHE ON | POST | OFF | INVALIDATE ] [ TIMETOLIVEINCACHE <seconds:integer> ] [ SWAP ON | OFF ] [ SWAPSIZE <megabytes:integer> ] [ <table search method clause> ]* <table search method clause> ::= ADD SEARCHMETHOD <name:identifier> ( [ I18N <name:identifier> ] [ CONSTRAINTS ( [ <constraint clause> ]+ ) ] [ OUTPUTLIST ( <output clause> ) ] [ <wrapper clause> ] [ PATTERNS ( [ <pattern clause> ]+ ) ] [ RAWPATTERNS ( [ <pattern clause> ]+ ) ] ) | ALTER SEARCHMETHOD <name:identifier> ( [ I18N <name:identifier> | DEFAULT ] [ CONSTRAINTS ( [ <constraint clause> ]+ ) ] [ OUTPUTLIST ( <output clause> ) ] [ <wrapper clause> ] [ PATTERNS ( [ <pattern clause> ]+ ) ] [ RAWPATTERNS ( [ <pattern clause> ]+ ) ] ) | DROP SEARCHMETHOD <name:identifier> <constraint clause> ::= ADD <field> ( [ <operator> [, <operator> ]* ] ) <obligatoriness> <multiplicity>



[ ( <value_1:value> [ , <value_i:value> ]* ) ] | NOS ZERO | 0 () | DROP <integer> <output clause> ::= <field> [ ,<field> ]* <wrapper clause>= WRAPPER ( <wrapper type> <name:identifier> ) | DROP WRAPPER <wrapper type> ::= ARN | CUSTOM | DF | GS | ITP | JDBC | ODBC | WS | XML <pattern clause>= ADD INPUT [FIELD <field> <operator> [, <operator> ]* ]+ <input_function:function> <integer> | ADD OUTPUT () | <condition_clause> <i18n:identifier> <output_function:function> <integer> | DROP INPUT <integer> | DROP OUTPUT <integer> <field> ::= <identifier>[.<identifier>]* <obligatoriness> ::= OPT | OBL <multiplicity> ::= ZERO | ONE | ANY | <integer> <condition clause> ::= (see section 6.3) <operator> includes “any” to represent any operator.

Figura 7 Sintaxis de la sentencia ALTER TABLE

5.2 CAPACIDADES DE CONSULTA: MÉTODOS DE BÚSQUEDA Y WRAPPERS

En la creación de un método de búsqueda, se deben especificar los siguientes elementos: la lista de restricciones de consulta, la lista de atributos de salida y el wrapper, previamente creado por medio de la sentencia CREATE WRAPPER, encargado de extraer los datos de la fuente.

5.2.1 Restricciones de Consulta

Para la especificación de los métodos de búsqueda, es necesario especificar una serie de 5-tuplas, a las que llamaremos ‘restricciones de consulta’. Para cada restricción de consulta, se deben indicar los siguientes elementos:

• Atributo – es un atributo de la relación.

• Operadores – es el conjunto de operadores que puede ser utilizado en las consultas sobre esa fuente y con ese método de búsqueda. ‘ANY’ representa a cualquier operador admitido por el tipo de dato del atributo. Si el campo de obligatoriedad (explicado más adelante) es ‘NOS’, no se especifica su valor.

• Obligatoriedad – puede tomar cuatro valores: ‘OBL’ indica que el atributo debe obligatoriamente aparecer en cualquier consulta sobre la fuente. ‘OPT’ indica que el atributo puede aparecer o no en la consulta (es opcional). ‘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. Puede tomar los valores ‘ZERO’ (que equivale a ‘0’), ‘ONE’ (que equivale a ‘1’), ‘ANY’ y cualquier número entero. Si no es posible realizar consultas por ese atributo (valor ‘NOS’ en el campo obligatoriedad) este parámetro es opcional. ‘ANY’ 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’, este parámetro es opcional.

Después de especificar las restricciones de consulta, se indican los atributos que aparecen a la salida de las consultas realizadas a través del método de búsqueda. Los atributos de salida de un método de búsqueda, se especifican enumerando los atributos separados por comas.

5.2.2 Asignación de Wrappers a Métodos de Búsqueda

Como se puede observar en la sintaxis de la Figura 7, para asignar un wrapper a un método de búsqueda, es necesario indicar dos elementos: el tipo del wrapper, y el nombre del mismo. El tipo de wrapper indica la naturaleza de la fuente externa de la que extrae información. La creación de un wrapper se explica con detalle en la sección 17.

5.2.3 Ejemplo de Creación de un Método de Búsqueda

En la Figura 8 se muestra un ejemplo en el que se añade un método de búsqueda a una relación. ALTER TABLE bookview ADD SEARCHMETHOD bookview_sm1 ( CONSTRAINTS ( ADD TITLE (any) OBL ANY ADD AUTHOR (like) OPT ANY ADD FORMAT NOS ZERO () ADD PRICE NOS ZERO () ) OUTPUTLIST (TITLE, AUTOR, FORMAT, PRICE) WRAPPER (ITP booktest) );

Figura 8 Ejemplo de creación de un método de búsqueda con ALTER TABLE

En el ejemplo de la Figura 8, se añade a la relación base denominada bookview, un método de búsqueda de nombre bookview_sm1, con cuatro restricciones de consulta. Las restricciones del método de búsqueda, indican que para realizar una consulta sobre la fuente, es obligatorio buscar por el atributo TITLE (especificando cualquier número de valores), opcionalmente se puede buscar por el atributo AUTHOR (especificando cualquier número de valores), y que no se permite la consulta directa por el resto de los atributos (FORMAT, PRICE). Además, en la definición del método de búsqueda se indica que todos los atributos aparecen a la salida. Por último se le asocia al método de búsqueda el wrapper denominado booktest de tipo ITPilot, como el encargado de extraer los resultados cuando se realiza una consulta utilizando este método de búsqueda. Es importante resaltar que aunque la fuente no pueda hacer consultas por sí misma por determinados atributos (en el ejemplo anterior, esto ocurre con FORMAT y PRICE), Virtual DataPort sí será capaz de realizar algunas consultas sobre dichos atributos por medio de post-procesados sobre los resultados obtenidos de las fuentes. Por ejemplo, si el servidor recibiese la consulta: SELECT * FROM BOOKVIEW WHERE TITLE like ‘java’ AND



s

FORMAT = ‘eBook’, Virtual DataPort sería capaz de contestarla extrayendo de la fuente los libros que contienen la palabra ‘java’ en el título (ya que la fuente sí permite esa consulta) y, posteriormente, aplicaría un post-procesado para filtrar los resultados y quedarse sólo con aquellos que además tengan la cadena ‘eBook’ en su atributo FORMAT.

5.3 REGLAS DE REESCRITURA

Tal y como ya se ha comentado, el sistema de reglas de reescritura sirve para tratar con heterogeneidades semánticas y de formatos de representación en las fuentes. Existen dos tipos de reglas de reescritura:

• Reglas de Ree critura de Entrada. Sirven para adaptar las consultas que se envíen a una relación a los formatos de representación esperados por ésta.

• Reglas de Reescritura de Salida. Adaptan los resultados obtenidos de una relación al formato esperado por las vistas de orden superior.

Las reglas de reescritura se aplican sobre métodos de búsqueda. El tipo de reglas de reescritura que pueden aplicarse varía según el método de búsqueda pertenezca a una relación base o a una vista derivada. Más concretamente, un método de búsqueda de una relación base tiene asociadas cuatro listas de reglas de reescritura diferentes: dos listas de tipo raw (una sobre resultados y otra sobre consultas); y otras dos de tipo no raw (una de entrada –consultas- y otra de salida –resultados-). Sin embargo, un método de búsqueda de una vista derivada sólo tiene asociadas las dos listas de tipo no raw. Una regla de tipo raw tiene como característica diferencial que puede tratar con los valores de los atributos de una relación base sin estar sujeta a las restricciones asociadas a los tipos de datos de dichos atributos. Esto es posible porque estas reglas operan o bien sobre consultas que se van a enviar a un wrapper (reglas de entrada), o bien sobre los datos devueltos por un wrapper (reglas de salida), y los datos enviados o devueltos por un wrapper no están tipados por el servidor. El uso de reglas de tipo raw es especialmente importante cuando se trata con atributos de tipo enumerado. Véanse los apartados 5.3.2.3 y 5.3.1.3 para ver algunos ejemplos de reglas de tipo raw. En cambio, una vista derivada, por cada subvista inmediatamente inferior en la jerarquía de vistas, tiene asociadas dos listas de reglas de reescrituras: una lista de reglas de reescritura sobre consultas y otra lista de reglas que reescriben los resultados, sin que sea posible utilizar reglas de tipo raw. Los siguientes apartados describen, respectivamente, el uso de las reglas de reescritura de entrada y de salida.

5.3.1 Reglas de Reescritura de Entrada

Las reglas de reescritura de entrada de una relación base, es decir, las que actúan sobre condiciones de consulta (independiente de si son tipo raw o no), se aplican sobre un método de búsqueda y se componen de los siguientes elementos:

• Las expresiones-patrón o patrones asociados a la regla de reescritura. Sirven para indicar la estructura que deben seguir las condiciones de consulta que serán reescritas mediante esta regla de reescritura. Una expresión-patrón se compone de varias condiciones-patrón. Cada condición-patrón consta de dos elementos: un atributo de la relación y un conjunto de operadores. Una condición de consulta encaja o verifica una condición patrón, si tiene como parte izquierda el atributo de la condición-patrón y tiene como operador alguno de los operadores que contiene la condición-patrón. Las expresiones-patrón deben construirse de modo que ninguna condición encaje con varias condiciones-patrón. Una expresión-patrón se verifica para una condición de consulta si: 1) para cada condición patrón existe una condición simple que la



satisface, y 2) si las condiciones simples que cumplen cada una de las condiciones patrón no están contenidas en ninguna condición OR y NOT.

• La función de transformación. Es la función que reescribe las condiciones que han encajado con las expresiones-patrón, produciendo a la salida un nuevo conjunto de condiciones de consulta que tomarán el lugar de las encajadas en la consulta original. Una función de transformación es una función predefinida (cuya sintaxis se explica en el Apartado 4.8) parametrizada por valores individuales o listas de valores individuales.

• La posición que toma la regla de reescritura en la lista de reglas de reescritura asociadas al método de búsqueda sobre el que actúa.

El resultado de una reescritura de condiciones es el subconjunto de condiciones que no ha encajado con ninguna expresión-patrón, más el resultado de aplicar la función de transformación sobre el subconjunto de condiciones que sí han sido encajadas. Como podemos ver en el Apartado 4.8, una función de transformación de una regla de reescritura de entrada se compone de un nombre y una serie de parámetros. Los parámetros son opcionales, van separados por comas y pueden ser elementos simples (literal, número o nombre de atributo, con la sintaxis general definida en el apartado 4.8) o listas. Las listas se delimitan por los caracteres ’[’ y ’]’, sus elementos se separan con el carácter ‘,’ y pueden ser cualquier elemento simple. Las funciones de transformación de entrada que Virtual DataPort incluye ya implementadas son: REMOVEACCENTS(), REGEXP(), MAP() y CHANGEOPERATOR(). Los siguientes subapartados se ocupan, respectivamente, de cada una de ellas.

5.3.1.1 REMOVEACCENTS

La función de transformación REMOVEACCENTS()elimina los acentos de los literales de búsqueda. Esta función no recibe ningún parámetro.

5.3.1.2 REGEXP

La función REGEXP() realiza transformaciones sobre los valores resultado de evaluar la parte derecha de las condiciones, desde un formato de entrada a un formato de salida, parametrizados ambos formatos por variables. Esta función recibe dos parámetros: una expresión regular de entrada y otra de salida. Las expresiones regulares deben expresarse utilizando la sintaxis de expresiones regulares del lenguaje JAVA[11]. En la Figura 9 se muestra un ejemplo de una regla de reescritura de entrada que utiliza la función de transformación REGEXP(). Dicha regla de reescritura, sobrescribe las condiciones de la forma (AUTHOR like <value>), dónde <value> es una cadena que representa el nombre y los apellidos del autor separados por una coma, intercambiando el orden del nombre y apellidos y eliminando la coma. Por ejemplo, dicha regla de reescritura sustituiría la condición (AUTHOR like ‘Smith, John ') por (AUTHOR like ’John Smith’). ALTER TABLE bookview ALTER SEARCHMETHOD bookview_sm1 ( PATTERNS ( ADD INPUT FIELD AUTHOR like REGEXP('(\w+),(\w+)','$2 $1') 1 )



);

Figura 9 Adición de una regla de reescritura de entrada REGEXP()

5.3.1.3 MAP

La función de transformación de entrada MAP() modifica los operandos de una lista de condiciones de consulta basándose en la aplicación de mapas de correspondencia directa sobre determinadas condiciones. Es decir, transforma unas condiciones en otras en base a un mapa (ver la creación de mapas en el Apartado 11.2). Esta función, recibe dos parámetros: el nombre de la configuración de internacionalización de las condiciones del mapa y el nombre del mapa que contiene las correspondencias de transformación de las condiciones. En la Figura 10 se muestra un fragmento de código que añade, a un método de búsqueda específico, una regla de reescritura de entrada de tipo raw que utiliza la función MAP(), en la segunda posición dentro de la lista de reglas de reescritura que posee el método de búsqueda. ALTER TABLE otherview ALTER SEARCHMETHOD otherview_sm1 ( RAWPATTERNS ( ADD INPUT FIELD TIMETABLE = Map(‘es_euro’, ‘daysOfWeek’) 2 ) );

Figura 10 Adición de una regla de reescritura sobre condiciones MAP()

La función MAP() utiliza el mapa “daysOfWeek” (creado en la Figura 36) que contiene condiciones expresadas según la configuración de internacionalización denominada “es_euro”. Nótese que, en este caso, es preciso utilizar una reescritura del tipo raw ya que el campo TIMETABLE tiene un tipo de dato enumerado que admite sólo unos determinados valores (más concretamente, los mostrados en la columna de la izquierda de la Figura 36) y el resultado de la reescritura es un valor no compatible con ese tipo de datos (más concretamente, el resultado será uno de los valores mostrados en la columna de la derecha de la Figura 36, que no son valores permitidos por el tipo de dato del atributo TIMETABLE).

5.3.1.4 CHANGEOPERATOR

La función de transformación de entrada CHANGEOPERATOR(), cambia el operador de la lista de condiciones que encajan con la regla de reescritura. Recibe como parámetro el nombre del operador que tendrán las condiciones después de aplicar sobre ellas la función de transformación. Por ejemplo, en la Figura 11 se define una regla de reescritura que al aplicarse sobre una condición de la forma (TITLE = ’value'), se sustituye por la condición (TITLE like ’value’). NOTA: Esta función de transformación está obsoleta y no se recomienda su uso en nuevas aplicaciones.



ALTER TABLE bookview ALTER SEARCHMETHOD bookview_sm1 ( PATTERNS ( ADD INPUT FIELD TITLE = ChangeOperator('like') 1 ) );

Figura 11 Adición de una regla de reescritura de entrada CHANGEOPERATOR()

5.3.2 Reglas de Reescritura de Salida

Las reglas de reescritura de salida de una relación base, es decir, las que actúan sobre tuplas de resultados, se aplican sobre un método de búsqueda y se componen de los siguientes elementos:

• La condición asociada a la regla de reescritura. Sirve para indicar sobre qué tuplas debe aplicarse esta regla de reescritura. Si no se especifica ninguna condición, significa que la regla de reescritura reescribe todas las tuplas de la vista. Estas condiciones se construyen de la misma manera que las utilizadas con la cláusula WHERE de la sentencia SELECT (ver sección 6.3).

• Internacionalización de la condición. Indica la configuración de internacionalización de los literales que contiene la condición.

• Función de transformación de salida. La función que realiza la reescritura sobre una tupla resultado. Dicha función de transformación recibe las tuplas que verifican una expresión-patrón y las reescribe, obteniendo un nuevo conjunto de tuplas que sustituye a las que encajaron inicialmente.

• Posición de la regla, dentro de la lista de reglas de escritura asociadas al método de búsqueda al que está asociado.

Una función de trasformación de salida tiene la misma sintaxis que una función de transformación de entrada (sigue la sintaxis genérica de las funciones predefinidas de Virtual DataPort, descrita en el Apartado 4.8). Las funciones de transformación sobre resultados que se incluyen son: REMOVEACCENTS(),REGEXP() y MAP(). Los siguientes subapartados se ocuparán, respectivamente, de cada una de ellas.

5.3.2.1 REMOVEACCENTS

La función de transformación de salida REMOVEACCENTS(), elimina los acentos de los valores de un conjunto de atributos. El parámetro que recibe es la lista de atributos de tipo texto sobre los que debe actuar, eliminando los acentos de las cadenas que tienen como valores dentro de la tupla. La lista de atributos se especifica entre corchetes, separados por comas (p.e. [field1, field2] ).

5.3.2.2 REGEXP

La función de transformación de salida REGEXP(), reescribe los valores para un conjunto de atributos de una tupla, que concuerdan con una expresión regular de entrada, a un formato de salida, parametrizados ambos formatos por variables. Las expresiones regulares de entrada y salida siguen la misma sintaxis que los utilizados por la función de transformación de entrada del mismo nombre (descrita en el Apartado 5.3.1.2). Esta función recibe tres parámetros: la lista de atributos de la tupla que reescribe (entre corchetes y separados por comas), los patrones de



entrada y los patrones de salida. Los dos últimos indican el formato de los valores de entrada y salida para dichos atributos, respectivamente.

5.3.2.3 MAP

La función MAP() reescribe una tupla aplicando mapas de correspondencia directa sobre determinados campos de la misma. Recibe como parámetros la opción de internacionalización a aplicar, la lista de nombres de los atributos sobre los que se aplican los mapas (entre corchetes y separados por comas) y la lista de mapas a aplicar a cada uno de los atributos especificados en el atributo anterior. Como ejemplo, supóngase que tenemos una tienda electrónica de libros que, para la información de formato, puede devolver uno de los siguientes valores: ‘eBook’, ’Hardcover’ o ‘Paperback’, mientras que la relación base que representa a dicha fuente tiene un atributo FORMAT, que pertenece a un tipo de dato enumerado que admite los siguientes valores: ’EB’, ’HC’ o ‘PB’. Podríamos definir un mapa que realizase la conversión entre unos y otros valores y, posteriormente, utilizar una función de reescritura MAP para reescribir adecuadamente los resultados obtenidos de la fuente. En la Figura 12 se muestra cómo se añadiría una regla de reescritura tipo raw sobre resultados que reescribe el valor del campo FORMAT aplicando el mapa “testBookFormat” (expresado según la configuración de internacionalización “es_euro”) sobre todas las tuplas resultado de ejecutar el método de búsqueda bookview_sm1. ALTER TABLE bookview ALTER SEARCHMETHOD bookview_sm1 ( RAWPATTERNS ( ADD OUTPUT () es Map('es_euro',[FORMAT],[ 'testBookFormat']) 1 ) );

Figura 12 Adición de una regla de reescritura de salida con la función MAP()

Nótese que en este ejemplo, la regla de reescritura se ha hecho de tipo raw porque los valores utilizados por la fuente para los datos del atributo FORMAT, no son válidos para el tipo de datos enumerado definido para este atributo (será, de hecho, la regla de reescritura la que convierta el valor recibido de la fuente en uno de los valores aceptados por el tipo de dato del atributo).


Consultas: Sentencia SELECT 39

6 CONSULTAS: SENTENCIA SELECT

Virtual DataPort permite realizar consultas sobre las relaciones previamente creadas utilizando la sentencia SELECT. Su sintaxis se muestra en la Figura 13. La sintaxis de esta y todas las sentencias VQL puede consultarse también haciendo uso del comando HELP (ver sección 16.2).

Los siguientes subapartados describen el uso de cada una de las cláusulas de la sentencia SELECT.

<select> | <union select> [ FILTER <function> [; <function> ]* | ORDER BY <order by field> [, <order by field>]* [ ASC | DESC ] ] [ CONTEXT ( <context information> [, <context information>]* ) ] [ TRACE ] <select> ::= SELECT [DISTINCT] <select fields> FROM <view> [ , <view> ]* WHERE <condition> GROUP BY <group by field> [ , <group by field> ]* HAVING <condition> <union select> ::= <select> [ UNION <select> ]+ <projected union select> ::= SELECT <select fields> FROM ( <union select> ) <select fields> ::= <select field> [ [ AS ] <alias:identifier>] [, <select field> [ [ AS ] <alias:identifier>] ]* <select field> ::= * | <value> <view> ::= <simple view> | <join view> | ( <select> ) <simple view> ::= <view:identifier> [ [ AS ] <alias:identifier> ] | <procedure:identifier> ( [<procedureParameter> [,<procedureParameter>]*] ) [ [ AS ] <alias:identifier> ] | <flatten view> <join view> ::= <inner view1:view> [<method type>] [<order type>] [<join type>] JOIN <inner view2:view> ON ( <join condition> ) | <inner view1:view> NESTED PARALLEL [<order type>] [<join type>] JOIN [nestedParallelNumber:integer] <inner view2:view> ON ( <join condition> ) | <inner view1:view> [<method type>] [<order type>] NATURAL [<join type>] JOIN <inner view2:view> | <inner view1:view> NESTED PARALLEL [<order type>] NATURAL [<join type>] JOIN [nestedParallelNumber:integer] <inner view2:view> | <inner view1:view> [<method type>] [<order type>] [<join type>] JOIN <inner view2:view> USING ( <field> [, <field>]* ) | <inner view1:view> NESTED PARALLEL [<order type>] [<join type>] JOIN [nestedParallelNumber:integer]<inner view2:view> USING ( <field> [, <field>]* )



| <inner view1:view> CROSS JOIN <inner view2:view> <inner view> ::= <simple view> | ( <view> ) <join type> ::= LEFT [OUTER] | RIGHT [OUTER] | FULL [OUTER] | INNER <method type> ::= HASH | NESTED | MERGE <order type> ::= ORDERED | REVERSEORDER <flatten view> ::= FLATTEN ( <view identifier>[.<register field>]*.<array field> ) | FLATTEN ( <view identifier> AS <alias> [, <alias>[.<register field>]*.<array field> AS <alias> ]*, <alias>[.<register field>]*.<array field> ) <value> ::= (see Figura 4) <condition> ::= <condition> AND <condition> | <condition> OR <condition> | NOT <condition> | ( <condition> ) | <value> <binary operator> <value> [ , <value> ]* | <value> <binary operator> ( <value> [ , <value> ]* ) | <value> BETWEEN <value> AND <value> | <value> <unary operator> <view identifier> ::= <view name:identifier> | <view name:literal> <value> ::= (see Figura 4) <join condition> ::= <simple join condition> [ AND <simple join condition> ]* | ( <join condition> ) <simple join condition> ::= <field1:field name> <binary operator> <field2:field name> | <field2:field name> <binary operator> <field1:field name> <group by field> ::= <field name> | <field position:integer> <order by field> ::= <field name> | <field position:integer> <binary operator> ::= (see Figura 3) <field name> ::= (see Figura 4) <context information> ::= <literal> = <context value> | QUERYPLAN = <query plan> <query plan> ::= | [<view name:identifier> : <view plans>]+ <view plans> ::= <view plan> | [ ( [<view plan>] ) ]+ <view plan> ::= <any method type> <any order type> | NESTED PARALLEL [nestedParallelNumber:integer] <any order type> <any method type> ::= <method type> | ANY <any order type> ::= <order type> | ANY <context value> ::= <number> | <boolean> | <literal>

Figura 13 Sintaxis de la sentencia SELECT



6.1 CLÁUSULA FROM

La especificación de la tabla origen se realiza a través de la cláusula FROM. En dicha cláusula, se indica el nombre de la relación -o relaciones- de las que se extrae la información. Es posible indicar alias para las relaciones en la cláusula FROM, que podrán ser utilizados en el resto de cláusulas de la sentencia SELECT, y facilitarán la creación de condiciones de Join. Si se indica un alias para una relación en la cláusula FROM, en el resto de la sentencia SELECT no se podrá utilizar el nombre de la relación para prefijar campos de la misma; deberá utilizarse siempre el alias. Es posible utilizar subconsultas en la cláusula FROM. La subconsulta debe incluirse entre paréntesis. Ejemplo: La siguiente sentencia utiliza una subconsulta que realiza una operación de UNION entre las vistas internet_inc y phone_inc:

SELECT * FROM (SELECT * FROM internet_inc UNION SELECT * FROM phone_inc) WHERE taxid="B78596011"

Si se listan varias relaciones en la cláusula FROM sin separarlas por la cláusula JOIN, entonces se realizará el producto cartesiano de las mismas. El siguiente subapartado se ocupa de las diferentes operaciones de join disponibles. La cláusula FROM también puede contener invocaciones a procedimientos almacenados. Los resultados devueltos por la invocación del procedimiento serán tratados en este caso como las tuplas de una vista. Véase la sección 10 para más detalle.

6.1.1 Operaciones de join

La cláusula FROM también permite definir las condiciones de Join entre las vistas involucradas en una consulta. Para ello debe utilizarse la construcción:

FROM view1 JOIN view2 ON (joinCondition) donde view1 y view2 son las vistas involucradas y joinCondition especifica la condición de join deseada. Pueden utilizarse los siguientes modificadores sobre la cláusula JOIN:

• INNER: La operación de join realizada será de tipo inner. Los ‘inner join’ incluyen en el resultado sólo aquellas tuplas construidas a partir de las tuplas de ambas relaciones que quedan asociadas en función de las condiciones de join. Es el tipo más habitual de join y el utilizado por defecto. Ejemplos:

FROM view1 JOIN view2 ON (joinCondition) FROM view1 INNER JOIN view2 ON (joinCondition)

• OUTER: La operación de join realizada será de tipo outer. Hay tres opciones para los join ‘outer’ (debe utilizarse siempre una de ellas): FULL, LEFT y RIGHT. Si se utiliza la opción FULL se incluyen en el resultado las tuplas de ambas relaciones aunque no tengan una tupla asociada en la otra relación (los atributos de la otra relación se rellenarán con NULL en la tupla resultante). Si se utiliza la opción LEFT, sólo se incluyen las tuplas de la primera relación que no tengan tuplas asociadas en la segunda. Si se especifica la opción RIGHT, sólo se añaden las tuplas de la segunda que no tengan tuplas asociadas en la primera. Ejemplos:

FROM view1 FULL OUTER JOIN view2 ON (joinCondition) FROM view1 LEFT OUTER JOIN view2 ON (joinCondition) FROM view1 RIGHT OUTER JOIN view2 ON (joinCondition)



• NATURAL: Se realizará la operación de join natural. En este tipo de join no se indicarán condiciones ya que se realizará asociando aquellos atributos con el mismo nombre y el mismo tipo en ambas relaciones de entrada utilizando el operador ‘=’. Puede utilizarse tanto con joins ‘inner’ como ‘outer’. Ejemplos:

FROM view1 NATURAL JOIN view2 FROM view1 NATURAL LEFT OUTER JOIN view2

• CROSS: Se realizará el producto cartesiano de las vistas especificadas. Es equivalente a listar las relaciones en la cláusula FROM sin utilizar JOIN. Ejemplo:

FROM view1 CROSS JOIN view2 En lugar de especificar una condición de join es posible también utilizar la claúsula USING para especificar una lista de atributos con el mismo nombre y mismo tipo en ambas relaciones. Si alguno de los atributos especificados no existe en alguna rama del join, o los tipos no coinciden en ambas ramas, se producirá un error. Este caso es equivalente a utilizar una condición de join que exija la igualdad de los valores de los atributos especificados en ambas relaciones. Ejemplo:

FROM view1 JOIN view2 USING (attribute1,…,attributeN) Por último, es posible también fijar una estrategia de ejecución para una operación de join determinada. Véase la sección 18.2.1 para más información a este respecto.

6.1.2 FLATTEN VIEW (Aplanando estructuras de datos)

Denodo Virtual DataPort soporta el modelado de tipos de dato con estructura en árbol mediante el uso de los tipos register y array (ver sección 18.1). En Virtual DataPort un elemento de tipo array debe ser visto como una subrelación; en realidad un array DataPort siempre tendrá asociado internamente un tipo register. Cada subelemento contenido en el array pertenecerá a dicho tipo de datos register. De esta forma, los campos de este registro pueden verse como el esquema de la subrelación 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. Supóngase que tenemos un Servicio Web con una operación getAverageMonthlySales. Esta operación no recibe ningún parámetro y devuelve información sobre las ventas mensuales de todos los clientes de una empresa mediante un array de objetos dónde cada objeto tendrá dos propiedades: taxId y revenue. La relación base creada sobre esta nueva operación tendrá típicamente un único atributo de tipo array conteniendo elementos de un tipo register y una única tupla dónde se encontrará toda la información devuelta por el servicio web. De cara a la combinación de la información con otras fuentes 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. En la cláusula FROM se puede utilizar un constructor especial (FLATTEN) para la definición de consultas sobre visiones “aplanadas” de vistas con tipos de datos compuestos (ver sección18.1). El constructor FLATTEN permite generar tuplas a partir de los subcampos compuestos de tipo array de las tuplas originales de una vista determinada. Su sintaxis (ver Figura 14) permite las siguientes alternativas:



- Especificando el nombre de un atributo de una vista de tipo array, genera una vista que tiene como esquema el del registro contenido en el array indicado. El nombre del subelemento array especificado puede encontrarse contenido dentro de una o varias estructuras de registros (pero no puede atravesar ningún otro array).

- Especificando el nombre de una vista y un alias, es posible obtener la representación aplanada de un array que podría estar a su vez contenido en otros arrays. Además en este caso se conservan el resto de campos de la vista. La sintaxis se especifica indicando inicialmente un alias para la vista original, y a continuación el elemento array sobre el que aplicar la operación FLATTEN. Si se desea aplicar sobre un array que está contenido en otro, será necesario añadir un alias al último array indicado y sobre éste especificar el elemento array que interese (si se desea atravesar más elementos array, se procede de forma similar). El esquema resultante contendrá los campos de la vista original (excepto sobre el que se realice la operación de FLATTEN) y todos los elementos de todos los registros involucrados en el aplanamiento.

<flatten view> ::= FLATTEN ( <view name:identifier>[.<register field>]*.<array field> ) | FLATTEN ( <view name:identifier> AS <alias>, [ <alias>[.<register field>]*.<array field> AS <alias> ]*, <alias>[.<register field>]*.<array field> )

Figura 14 Sintaxis de una FLATTEN view

Ejemplo: Supóngase que tenemos la relación base AVERAGE_REVENUE_ARRAY cuyo esquema está compuesto por un campo de tipo array de registros llamado RETURN. Cada registro tiene dos campos: TAXID y REVENUE. La siguiente sentencia devuelve los contenidos “aplanados” de AVERAGE_REVENUE_ARRAY:

SELECT TAXID, REVENUE FROM FLATTEN (AVERAGE_REVENUE_ARRAY AS V, V.RETURN)

6.2 CLÁUSULA SELECT

A través de la cláusula SELECT se indican los atributos (separados por comas) que se desea obtener de las relaciones que se especifican en la cláusula FROM. Las consultas que un usuario realiza pueden involucrar tanto relaciones base como vistas complejas derivadas previamente definidas. Si se especifica el carácter “*” en la cláusula SELECT, significa que se seleccionan todos los atributos de las vistas sobre las que se realiza la consulta. Como resultado de una consulta sobre Virtual DataPort, se obtiene una relación o vista cuyo esquema viene dado por los nombres y tipos de los atributos especificados en la cláusula SELECT. También es posible definir alias para las columnas obtenidas, permitiendo de esta forma modificar el nombre de algún atributo. En el caso de atributos derivados, no es obligatorio definir un alias para indicar el nombre del nuevo campo de la relación (véase el apartado 6.2.1). Si no se especifica, entonces el sistema asociará como alias el nombre de la función generadora del atributo derivado, en el caso de las funciones, y el nombre del último subcampo referenciado en el caso de un subelemento de un campo compuesto. En una consulta, si un campo no tiene alias y es una referencia a un campo de una vista inferior, su nombre es el nombre de la vista de la que proviene seguida del nombre del campo (separados por el caracter '.'). En cambio, en una vista, el nombre de sus campos nunca encapsulan el nombre de una vista inferior; por tanto, en una vista el nombre de un campo sin alias que es una referencia a un campo de una vista inferior, será simplemente el nombre del campo en la vista inferior sin ningún nombre de vista.



En las consultas y en las vistas, no se permite que haya dos campos con el mismo nombre, siendo necesario renombrar (mediante alias) alguno de ellos de forma diferente. Finalmente, puede incluirse el modificador DISTINCT. En ese caso se eliminarán del resultado aquellas tuplas duplicadas.

6.2.1 Atributos Derivados

En la cláusula SELECT, además de columnas que procedan directamente de atributos de relaciones incluidas en la cláusula FROM, pueden incluirse columnas cuyos valores se deriven de un cálculo a partir de los valores de otras columnas. Este tipo de atributos suelen denominarse atributos derivados. Los valores de un atributo derivado se obtienen por medio de una función predefinida (ver la sección 4.6), que puede recibir como parámetros los valores de otras columnas, así como valores constantes o, incluso, el resultado de aplicar otras funciones del mismo tipo. En la sección 4.6 se puede encontrar la descripción de las funciones soportadas por Virtual DataPort. A continuación se muestran algunos ejemplos de utilización de funciones de atributo derivado. La siguiente consulta obtiene el sueldo de los empleados (vista emp) con un incremento de 1000 euros en una columna denominada newSalary.

SELECT SUM(1000, salary) newSalary FROM emp;

Y el siguiente ejemplo muestra el uso como parámetro de una función anidada:

SELECT NAME, SUM(SALARY, DIV(SALARY,1000)) salaries FROM emp;

6.3 CLÁUSULA WHERE

En la cláusula WHERE se especifican las condiciones que deben cumplir los resultados de la consulta efectuada. La sintaxis para la especificación de una condición se muestra en la Figura 15. <condition> ::= <condition> AND <condition> | <condition> OR <condition> | NOT <condition> | ( <condition> ) | <value> <binary operator> <value> [ , <value> ]* | <value> <binary operator> ( <value> [ , <value> ]* ) | <value> BETWEEN <value> AND <value> | <value> <unary operator>

Figura 15 Sintaxis para una condición

Una condición es una secuencia de elementos condición separados por los operadores lógicos AND, OR o NOT. Cada condición, representa una operación de comparación, que al evaluarse obtiene como resultado un valor positivo (verdadero) o negativo (falso). Las condiciones pueden agruparse entre los símbolos ‘(’ y ‘)’ para variar su precedencia.



Una condición se compone de un argumento, que es el elemento sobre el cuál se aplica la condición y que se corresponderá con el primer operando, seguido de un operador de comparación. Este operador, a su vez, y siempre que no sea unario (IS NULL, IS NOT NULL, IS TRUE o IS FALSE), va seguido de uno o varios argumentos dependiendo de la naturaleza del mismo. Los operadores de comparación que soporta Virtual DataPort se especifican en el apartado 4.5, e incluyen operadores de igualdad, de comparación mayor/menor, de contención de cadenas, etc. Se puede decir que una condición se compone de tres elementos: una parte izquierda (que será el operando sobre el que se aplica la operación de comparación), un operador y una parte derecha (que es opcional y que contiene el resto de los operandos que se compararán con el de la parte izquierda). Un operando de una condición puede ser el nombre de un atributo, un literal, un número, un valor lógico, una expresión a evaluar o un valor compuesto (ver sección 6.3.1). Una expresión como operando de una condición es una función predefinida y parametrizada como la que se utiliza para la especificación de un atributo derivado dentro de la cláusula SELECT, pero con una particularidad añadida: en la mayoría de los casos es obligatorio que uno de los operandos sobre el que se aplica la condición (es decir, en el operando de la parte izquierda o en alguno de los de la derecha), esté parametrizado por al menos el nombre de un atributo (no es así, por ejemplo con la función TEXTCONSTANT("texto"), porque TEXTCONSTANT devuelve siempre como resultado un elemento de tipo "text"). Como ya se ha adelantado, algunos operadores pueden admitir operandos de varios tipos de dato, pero en una misma condición, todos sus operandos deben pertenecer al mismo tipo. Por ejemplo, el operador ‘=’, sirve para comparar elementos de cualquier tipo de dato (tipo texto, entero, real, etc), pero dentro de una condición específica, es necesario que todos los operandos sean del mismo tipo (no se pueden comparar, por ejemplo, un valor tipo entero con un valor tipo texto, aunque es posible utilizar la función CAST para realizar las conversiones de tipo precisas antes de la comparación).

6.3.1 Condiciones con valores compuestos

El constructor ROW permite crear valores compuestos de tipo register (ver sección 18.1). Por ejemplo:

ROW (value1,…,valueN) crearía un valor de tipo register con N campos. Cada value especificado puede ser un atributo, un literal, un número, un valor lógico, una expresión a evaluar o un nuevo elemento ROW. Cada campo del registro creado será del tipo de datos del value correspondiente. Utilizando ROW combinado con los contructores ‘‘ y ‘’ es posible también crear tipos array DataPort. Por ejemplo:

ROW (value1,…,valueN), ROW (valueN+1,…,value2N) crearía un valor de tipo array conteniendo dos valores register. NOTA: Véase la Figura 4 para una descripción formal de la sintaxis de creación de valores compuestos. Las condiciones con valores compuestos pueden utilizarse solamente con los operadores de igualdad ‘=’ y desigualdad ‘<>’. Para que la comparación sea posible ambos operandos deben tener tipos compatibles.

6.4 CLÁUSULA GROUP BY

Otra cláusula perteneciente al comando SELECT es GROUP BY. Esta cláusula permite agrupar los resultados obtenidos de una consulta en función de los valores de un conjunto de atributos, obteniendo por cada uno de esos grupos una única tupla en los resultados. En la cláusula GROUP BY se especifican los atributos por los que se



desea realizar la operación de agrupamiento. Si no se especificasen atributos de agrupamiento (sin cláusula GROUP BY o con cláusula GROUP BY vacía) pero en la cláusula SELECT se indicasen funciones de agregación, entonces todos los resultados obtenidos por la sentencia SELECT formarían un grupo. Cuando en una consulta se especifica la cláusula GROUP BY, el contenido de la cláusula SELECT está restringido. Sólo se podrán especificar en ella los atributos de agrupamiento (es decir, los que se especifican en el GROUP BY). El resto de los atributos deberán aparecer como parámetros de funciones de agregación, que calcularán el valor “agregado” de cada atributo en las tuplas resultado. Cuando se especifica una función de agregación en la cláusula SELECT, es necesario indicar un alias para el nuevo atributo en la vista resultado. De no hacerlo, se generará un alias de forma automática, que será el nombre de la función aplicada. En una vista de agrupación, en la cláusula SELECT también pueden aparecer funciones de atributo derivado, aunque sólo aplicadas sobre campos o funciones de agregación.

6.4.1 Uso de Funciones de Agregación

Una función de agregación o de agregado, se aplica sobre las tuplas pertenecientes a un grupo resultado de una operación GROUP BY, y calcula un valor a partir de las mismas. En el Apartado 4.7 se enumeran las funciones de agregación existentes en Virtual DataPort. Las funciones de agregación, siguen la sintaxis general de las funciones predefinidas (ver Apartado 4.8), pero sólo admiten como parámetro el nombre del atributo sobre el que actúan (tampoco admiten funciones anidadas). Adicionalmente, también permiten especificar el modificador ALL/DISTINCT. Una excepción la constituye la función de agregación COUNT(), que puede recibir como parámetro el carácter especial “*”, para indicar que cuente el número de tuplas que pertenecen a cada grupo. Por ejemplo, dada una relación emp representando a los empleados de una empresa, que contenga un atributo departament que indique a qué departamento pertenece cada empleado, para obtener los diferentes departamentos, junto con el número de empleados que pertenecen a cada uno de ellos, se realizaría la siguiente consulta:

SELECT count(*) AS numOfWorkers, department FROM emp GROUP BY department;

6.5 CLÁUSULA HAVING

La cláusula HAVING permite especificar condiciones de filtrado sobre los resultados devueltos por una consulta que utilice la cláusula GROUP BY. Por ejemplo, continuando con el ejemplo de la sección anterior, para obtener solamente los datos correspondientes a departamentos con más de 10 empleados, podríamos efectuar la siguiente consulta:

SELECT count(*) AS numOfWorkers, department FROM emp GROUP BY department HAVING COUNT(*)>10



6.6 CLÁUSULA UNION

La sentencia SELECT también permite obtener una nueva vista que contenga las tuplas contenidas en otras dos vistas o consultas. Esto es posible mediante la cláusula UNION. Esto se corresponde, salvando algunas diferencias leves, con la operación unión de álgebra relacional. Cada relación que interviene en la operación de unión se corresponde con una consulta específica. Para especificar una unión de varias consultas, éstas se separan por la palabra UNION. En principio, para realizar su unión en álgebra relacional, se precisa que todas las relaciones tengan el mismo esquema, es decir, los mismos atributos. Sin embargo, en Virtual DataPort, si alguna de las vistas tiene algún atributo que la otra no tiene, éste se añade a la vista resultante (unión ampliada). Además, en este caso, la unión incluye filas repetidas, es decir, si alguna fila está en dos tablas, la tupla aparecerá dos veces en la vista resultado. Puede utilizarse el modificador DISTINCT para evitar esta situación.

6.6.1 Especificación de proyecciones en consultas UNION

Como característica adicional, es posible indicar en las sentencias SELECT de Virtual DataPort los campos a proyectar de una vista unión; es decir, se permite indicar una proyección (SELECT <field list>) sobre el resultado de una <union view>. Su sintaxis se muestra en la Figura 16. <union select> ::= <select> [ UNION <select> ]+ <projected union select> ::= SELECT <select fields> FROM ( <union select> )

Figura 16 Sintaxis para una proyección sobre el resultado de una unión

6.7 CLÁUSULA ORDER BY

En el comando SELECT, se puede utilizar la cláusula ORDER BY para indicar que se desea obtener el resultado ordenado por una lista de atributos. La cláusula ORDER BY va seguida del atributo o atributos de la vista final por los que se desean ordenar las tuplas y el orden, ascendente o descendente que se desea utilizar. Por defecto, los resultados se muestran en orden ascendente. Por ejemplo, la siguiente consulta obtiene los empleados ordenados por el atributo pay en orden descendente.

SELECT * FROM emp ORDER BY pay DESC; También es posible especificar los atributos de ordenación por su número de orden en la cláusula SELECT. Por ejemplo: SELECT name,pay FROM emp ORDER BY 2 DESC; En general, los resultados de una consulta sobre Virtual DataPort se tratarán de forma asíncrona, es decir que los resultados se obtendrán a medida que son extraídos de las fuentes, sin que sea preciso esperar a tener disponibles todos los resultados para procesar los que ya han llegado. En cambio, si una consulta tiene especificada una cláusula ORDER BY, el resultado de la consulta se obtendrá de forma síncrona (es decir, no se podrá acceder a ningún resultado hasta que se hayan obtenido todos).



z

6.8 CLÁUSULA CONTEXT

Una consulta tiene un contexto de ejecución, es decir, un conjunto de características de ejecución específicas que poseen unos valores por defecto. Por ejemplo, los resultados de una consulta, mientras no se indique lo contrario, se mostrarán según una configuración de internacionalización concreta; es decir, en una moneda, lenguaje, etc. específicos. La sentencia SELECT, mediante la cláusula CONTEXT, permite modificar el contexto de ejecución para la consulta actual. En general, la cláusula CONTEXT recibe pares clave-valor (separados por comas), dónde la clave es el nombre de la característica de ejecución a modificar y el valor indica el nuevo valor para dicha característica. El nombre de la clave no es sensible a mayúsculas /minúsculas, mientras que, en el caso del valor, depende de la característica que represente (ver Figura 17 para una descripción formal de la sintaxis). Las características de ejecución configurables a través de CONTEXT son:

• i18n: La internacionalización para los resultados de una consulta. Dicha propiedad, toma como valor el nombre de una configuración de internacionalización (por ejemplo: es_euro). Una internacionalización es válida, si existe un mapa de tipo i18n en el catálogo del servidor (en el Apartado 11.2 se explican en detalle los tipos de mapas pertenecientes al catálogo).

• Cache: La utilización de caché de resultados, es decir, si debe aprovechar resultados de consultas anteriores para la resolución de la consulta. Esta propiedad, puede tomar como valores “ON” (para utilizar la caché de las vistas involucradas en la consulta de acuerdo a su configuración actual) y “OFF” (para desactivar la caché para la consulta). Por defecto, está a “ON”. Véase la sección 18.2.2 para más detalles sobre la configuración de la cache en vistas.

• QueryPlan: Permite especificar en tiempo de ejecución diversas características del plan de ejecución de la consulta. Véase la sección 18.2.1 para más detalle.

• DelegateUnnamedViews. Puede tomar los valores ‘YES’ o ‘NO’. Si no se indica, se asume el valor ‘YES’. La utilidad de esta opción se explica a continuación. Al crear vistas utilizando la herramienta de administración gráfica de Virtual DataPort, es posible que el sistema cree vistas intermedias adicionales. Estas vistas reciben un nombre interno creado por DataPort y, por ello, se denominan “vistas sin nombre”. Además, cuando se ejecuta una consulta que realiza una proyección o una agregación sobre una vista existente, DataPort también crea internamente una vista sin nombre que dura tan sólo mientras se ejecuta la consulta. Por otro lado, DataPort intenta delegar siempre la mayor cantidad de procesamiento que sea posible a las fuentes de datos origen. En ciertos casos, la delegación a la fuente de las operaciones realizadas por las vistas sin nombre puede llevar a que, en ciertas consultas, no se utilice la cache de una vista, incluso aunque la cache haya sido activada. En estos casos, el usuario puede decidir fijar el valor de esta propiedad a ‘NO’. Véase la sección 18.2.2.1 para más detalle.

• Swap: Indica si está activado o no el “swapping” para la consulta. Esta propiedad debe tomar el valor “ON” para indicar que está permitido realizar swapping de resultados intermedios durante la ejecución de la consulta. El valor “OFF” indica lo contrario. Véase la sección 18.2.3 para más detalle.

• SwapSi e: Esta propiedad indica el tamaño máximo que puede alcanzar un resultado intermedio obtenido mediante la ejecución de esta consulta sin que el sistema realice “swapping” del mismo. Recibe como parámetro el tamaño máximo (en megabytes). Sólo tiene efecto en caso de que se haya especificado la opción SWAP ON. Véase la sección 18.2.3 para más detalle.

<context information> ::=



<literal> = <context value> | QUERYPLAN = <query plan> <query plan> ::= (see section 18.2.1.1) <context value> ::= <number> | <boolean> | <literal>

Figura 17 Sintaxis de la cláusula CONTEXT

6.9 CLÁUSULA TRACE

Mediante la cláusula TRACE del comando SELECT, se solicita al servidor un nivel detallado de traza en la ejecución de una consulta. La traza de una sentencia permite un examen detallado de su plan de ejecución. Dicho plan puede modelarse como un árbol donde 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, la cláusula TRACE muestra sus parámetros más relevantes. La herramienta de administración de DataPort (ver Guía del Administrador [3]) permite visualizar la traza de ejecución en forma gráfica, lo que permite un análisis más sencillo de esta información. Entre los parámetros mostrados por la cláusula TRACE 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 hasta que se obtuvo la 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.

• Estado. 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.

• Condiciones de error. La traza indica también los posibles errores producidos durante la ejecución del nodo.

A modo de ejemplo, la Figura 18 muestra la traza de la ejecución de la consulta siguiente:

SELECT * FROM INTERNET_INC TRACE INTERNET_INC es una vista base creada sobre una tabla del mismo nombre accesible a través de una fuente de datos JDBC. BASE PLAN ( name = INTERNET_INC startTime = Wed Jan 10 17:50:01 850 GMT+01:00 2007 endTime = Wed Jan 10 17:50:04 063 GMT+01:00 2007 responseTime = Wed Jan 10 17:50:04 053 GMT+01:00 2007 numRows = 4 state = OK completed = true fields = [IINC_ID, SUMMARY, TTIME, TAXID, SPECIFIC_FIELD1, SPECIFIC_FIELD2] search conditions = [] filter conditions = [] numOfFilteredTuples = 0 numOfDuplicatedTuples = 0 numOfSwappedTuples = 0 swapping = false inputRewriteFunctions = false outputRewriteFunctions = false inputRawRewriteFunctions = false outputRawRewriteFunctions = false JDBC WRAPPER ( name = internet_inc startTime = Wed Jan 10 17:50:02 070 GMT+01:00 2007 endTime = Wed Jan 10 17:50:04 063 GMT+01:00 2007 responseTime = Wed Jan 10 17:50:04 063 GMT+01:00 2007 numRows = 4 state = OK completed = true searchConditions = [] orderByFields = [] projectedFields = [IINC_ID, SUMMARY, TTIME, TAXID, SPECIFIC_FIELD1, SPECIFIC_FIELD2] JDBC ROUTE ( name = internet_inc#0 startTime = Wed Jan 10 17:50:03 782 GMT+01:00 2007 endTime = Wed Jan 10 17:50:04 063 GMT+01:00 2007 responseTime = Wed Jan 10 17:50:04 063 GMT+01:00 2007 numRows = 4 state = OK completed = true SQLSentence = SELECT t0.iinc_id, t0.summary, t0.ttime, t0.taxId, t0.specific_field1, t0.specific_field2 FROM test_vdb.internet_inc t0 parameters = [] DBUri = jdbc:mysql://localhost/test_vdb userName = vdb connectionTime = 0 cachedStatus = false )



) )

Figura 18 Traza de ejecución

Para analizar la traza de ejecución de consultas, se recomienda el uso de la herramienta de administración de DataPort (ver Guía del Administrador [3]), que permite visualizar la traza de ejecución en forma gráfica.


Definición de una Vista Derivada 52

7 DEFINICIÓN DE UNA VISTA DERIVADA

Partiendo de las relaciones base del sistema, el administrador puede definir otras nuevas en función de éstas, ampliando las funcionalidades del servidor. Estas nuevas relaciones se llaman: vistas derivadas o vistas del esquema global. Virtual DataPort permite definir esquemas de mediación para cada aplicación de agregación concreta, mediante la definición de vistas sobre las relaciones base. El sistema se encargará de calcular automáticamente los métodos de búsqueda de las nuevas relaciones partiendo de los métodos de búsqueda de las relaciones base involucradas en la vista y de la expresión utilizada para crearla. La sentencia CREATE VIEW permite crear vistas derivadas en el esquema mediado del servidor. Su sintaxis se muestra en la Figura 19. CREATE [ OR REPLACE ] VIEW <name:identifier> AS <select> [ WITH [ CASCADED | LOCAL ] CHECK OPTION ] [ CONTEXT ( <context information> [, <context information>]* ) ] <select> ::= (see Figura 13) <context information> ::= (see Figura 13)

Figura 19 Sintaxis de la sentencia CREATE VIEW

Como se puede observar, en la definición de una vista se especifica un nombre y la consulta que la define. La consulta que se especifica, se define utilizando la sintaxis de la sentencia SELECT, que ha sido explicada en detalle en el Apartado 6. Por lo tanto, el administrador puede crear nuevas vistas derivadas utilizando diferentes tipos de relaciones entre elementos preexistentes en el sistema. Por ejemplo, puede generar una nueva relación que sea la unión de varias, el join, el producto cartesiano, la selección, la proyección o el group-by. Además, en la creación de una nueva relación pueden combinarse varios de estos tipos de operadores con el nivel de complejidad que se desee. También pueden definirse vistas que tomen como base otras vistas previamente definidas, con lo que se pueden construir árboles de vistas de tantos niveles como sea necesario. Por ejemplo, considerando las vistas A, B y R como relaciones base (que acceden directamente a las fuentes para obtener sus datos), el administrador podría definir una vista G como el join del resultado de aplicar la unión (A, B), con R; como se puede observar en la Figura 20.



Figura 20

∪

A BI R

G∪

A BI R

G

Ejemplo de definición de una vista en función de otras

La creación de una vista también admite la cláusula estándar SQL WITH CHECK OPTION, cuyo uso está relacionado con la actualización de los contenidos de la vista mediante las sentencias INSERT /UPDATE / DELETE. En la sección 8.4 se explica con detalle la función de este modificador. El uso del modificador OR REPLACE permite especificar que, si ya existe una vista con el nombre indicado, ésta debe ser reemplazada por la nueva vista. En caso de que debido al cambio de definición de la vista, las capacidades de consulta (ver sección 5.2) 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á el esquema y las capacidades de consulta de las vistas derivadas de nivel superior, siempre que sea posible

7.1 MODIFICACIÓN DE UNA VISTA DERIVADA

Una vez creada una vista derivada a partir de otras vistas existentes, es posible modificar algunas de sus propiedades:

• La configuración de la caché mediante las opciones CACHE y TIMETOLIVEINCACHE (ver sección 18.2.2),

• La configuración de las políticas de “swapping” de DataPort mediante las opciones SWAP y SWAPSIZE (ver sección 18.2.3)

• La configuración de las estrategias de ejecución de los joins involucrados en la definición de la vista mediante la opción QUERYPLAN (ver sección 18.2.1).

• La configuración de reglas de reescritura de condiciones o resultados para el tratamiento de las representaciones heterogéneas de información procedente de varias fuentes (ver sección 7.1.1).

La sentencia ALTER VIEW permite al administrador de Virtual DataPort realizar todas estas operaciones. Su sintaxis se muestra en la Figura 21. ALTER VIEW <name:identifier> [ CACHE ON | POST | OFF | INVALIDATE ] [ TIMETOLIVEINCACHE <seconds:integer> ] [ SWAP ON | OFF ] [ SWAPSIZE <megabytes:integer> ] [ QUERYPLAN = <query plan> ] [ <view search method clause> ]* <view search method clause> ::=



ALTER <name:identifier> ( [ PATTERNS ( [ <pattern clause> ]+ ) ] ) <pattern clause>= ADD INPUT [FIELD <field> <operator> [, <operator> ]* ]+ <input_function:function> <integer> | ADD OUTPUT () | <condition_clause> <i18n:identifier> <output_function:function> <integer> | DROP INPUT <integer> | DROP OUTPUT <integer> <operators> includes “any” to represent any operator. <query plan> ::= (see section 18.2.1.1)

Figura 21 Sintaxis de la sentencia ALTER VIEW

7.1.1 Reglas de Reescritura Sobre Vistas Derivadas

La sentencia ALTER VIEW permite añadir o eliminar reglas de reescritura. Las reglas de reescritura de entrada indican cómo deben de ser “traducidas” las consultas que se realizan sobre la vista superior para poder delegarlas a las vistas inmediatamente inferiores. Y las reglas de reescritura de salida indican cómo deben ser transformadas las tuplas obtenidas de las vistas inferiores para incluirlas como resultado de la vista inmediatamente superior de forma homogénea. En el Apartado 5.3, se describe la estructura de la reglas de reescritura de entrada y salida sobre un método de búsqueda de una relación base. Las reglas de reescritura asociadas a una vista derivada, son iguales que las que se aplican sobre las relaciones base, con la diferencia de que las reglas de reescritura sobre las vistas base se indican a nivel de los métodos de búsqueda de una fuente, mientras que las reglas de reescritura sobre las vistas derivadas se especifican a nivel de las vistas que se encuentran por debajo en la jerarquía de vistas. Una vista derivada tiene asociada dos listas de reglas de reescritura de tipo no raw por cada vista inmediatamente inferior: una lista de reglas de reescritura sobre resultados y otra sobre consultas. Nótese que a este nivel no es posible utilizar reglas tipo raw (que sí pueden utilizarse sobre relaciones base, tal y como se mostró en la sección 5.3), debido a que es necesario asegurar la consistencia entre los tipos de datos de los atributos de una vista derivada y los de las relaciones que la componen. Tal y como ya se comentó en el apartado 5.3.1, una regla de reescritura sobre condiciones o de entrada se compone de tres partes diferenciadas:

• las expresiones-patrón o patrones que indican la estructura que deben seguir las condiciones de consulta que deben de ser reescritas mediante esta regla de reescritura,

• la función de transformación que reescribe las condiciones que han encajado con las expresiones-patrón y

• la posición que ocupa dentro de la lista de reglas de reescritura de entrada asociadas al contenedor especificado.

Por otro lado, una regla de reescritura sobre resultados o de salida se estructura en los siguientes elementos:

• la condición que debe verificar la tupla para que se aplique sobre ella la regla de reescritura,



• la internacionalización de dicha condición,

• la función de transformación de salida que reescribe los resultados y,

• la posición que ocupa en la lista de reglas de reescritura de salida.

En el ejemplo de la Figura 22 se añade a la vista bookview, una regla de reescritura de entrada en la primera posición. La regla de reescritura cambia el formato de los valores de las condiciones de consulta que utilizan el operador like sobre el atributo AUTHOR, al delegarlas a la subvista base bookshop. ALTER VIEW bookview ALTER bookshop ( PATTERNS ( ADD INPUT FIELD AUTHOR like REGEXP('(\w+),(\w+)', '$2 $1') 1 ) );

Figura 22 Adición de una regla de reescritura de entrada sobre vista derivada

Para eliminar la primera regla de reescritura de entrada que se aplica sobre la vista bookshop, desde bookview, se debe ejecutar la sentencia de la Figura 23. ALTER VIEW bookview ALTER bookshop ( PATTERNS ( DROP INPUT 1 ) );

Figura 23 Borrado de una regla de reescritura de salida de una vista no base

Y por último, la Figura 24 muestra como se añade a la vista bookview, una regla de reescritura sobre resultados en la primera posición. La regla de reescritura de salida modifica el formato de los valores del atributo AUTHOR en todas las tuplas (ya que carece de condición) que provienen de la subvista bookshop. ALTER VIEW bookview ALTER bookshop ( PATTERNS ( ADD OUTPUT () es REGEXP([AUTHOR], '(\w+),(\w+)', '$2 $1') 1 ) );

Figura 24 Adición de una reescritura sobre resultados en una vista derivada


Inserciones, Actualizaciones Y Borrados sobre Vistas 56

8 INSERCIONES, ACTUALIZACIONES Y BORRADOS SOBRE VISTAS

Las sentencias INSERT / UPDATE / DELETE permiten, respectivamente, insertar, modificar y borrar tuplas de una vista, actualizando directamente la fuente de datos. Estas sentencias pueden ejecutarse sólo sobre vistas creadas a partir de fuentes de tipo base de datos (fuentes JDBC/ODBC. Ver secciones 17.3.1 y 17.3.2) y de tipo CUSTOM (ver sección 17.4.9). Además, las vistas deben ser actualizables de acuerdo a la definición del estándar SQL-92. En resumen, una vista actualizable debe verificar las siguientes restricciones:

• La sentencia SELECT utilizada en la definición de la vista no puede incluir DISTINCT, GROUP BY o HAVING.

• La cláusula FROM de la sentencia se refiere a exactamente una vista. Esa vista debe ser o bien una vista base o bien una vista actualizable. En el caso de ser una vista base, debe o bien pertenecer a una base de datos (DataSources JDBC/ODBC. Ver secciones 17.3.1 y 17.3.2) o bien utilizar un wrapper de tipo MY que proporcione soporte para actualizaciones (ver sección 17.4.9).

• Los atributos derivados no son actualizables.

• Una vista que utilice una función de agregación (aunque no haya cláusula GROUP BY) no es actualizable.

8.1 SENTENCIA INSERT

La sentencia INSERT permite insertar una nueva tupla en una vista, actualizando directamente la fuente de datos. La Figura 25 muestra su sintaxis. INSERT INTO <name:identifier> (<field name>[, <field name>]*) VALUES (<value>[, <value>]*) [ CONTEXT ( <context information> [, <context information>]* ) ] [ TRACE ] INSERT INTO <name:identifier> SET <field name> = <value> [, <field name> = <value> ]* [ CONTEXT ( <context information> [, <context information> ]* ) ] [ TRACE ] <field name> ::= <identifier>[.<identifier>] <value> ::= NULL | <number> | <boolean> | <literal>

Figura 25 Sintaxis de la sentencia INSERT

Por ejemplo, la siguiente sentencia añade una nueva tupla en la vista internet_inc:



INSERT INTO internet_inc (iinc_id, summary, ttime, taxid, specific_field1, specific_field2) VALUES (6,"Error in ADSL Router", "31-mar-2005 22h 35m 24s", "B78596015", "5", "6")

Como efecto de la ejecución de esta sentencia, se añadirá una nueva tupla en la base de datos fuente a la tabla representada por la vista internet_inc. También es posible utilizar la sintaxis alternativa:

INSERT INTO internet_inc SET iinc_id=6, summary="Error in ADSL router", ttime="31-mar-2005 22h 35m 24s", taxid="B78596015", specific_field1="5", specific_field2="6"

8.2 SENTENCIA UPDATE

La sentencia UPDATE permite modificar el valor de determinados atributos para todas las tuplas de una vista que verifiquen una determinada condición, actualizando directamente la fuente de datos. La Figura 26 muestra su sintaxis: UPDATE <name:identifier> SET (<field name>[, <field name>]*) = (<value>[, <value>]*) [ WHERE <condition> ] [ CONTEXT ( <context information> [, <context information>]* ) ] [ TRACE ] UPDATE <name:identifier> SET <field name> = <value> [, <field name> = <value>]* [ WHERE <condition> ] [ CONTEXT ( <context information> [, <context information>]* ) ] [ TRACE ] <field name> ::= <identifier>[.<identifier>] <value> ::= NULL | <number> | <boolean> | <literal> | <field name> <condition> ::= <condition> AND <condition> | <condition> OR <condition> | NOT <condition> | ( <condition> ) | <value> <binary operator> <value> [ , <value> ]* | <value> <unary operator>

Figura 26 Sintaxis de la sentencia UPDATE

Por ejemplo, la siguiente sentencia modifica las tuplas de la vista internet_inc cuyo valor para el atributo iinc_id sea 6, haciendo que su valor para los atributos specific_field1 y specific_field2 pase a ser 10:

UPDATE internet_inc



SET (specific_field1, specific_field2) = ("10","10") WHERE iinc_id=6

Como efecto de la ejecución de esta sentencia, se modificarán las tuplas correspondientes en la base de datos fuente, en la tabla representada por la vista internet_inc. También es posible utilizar la sintaxis alternativa:

UPDATE internet_inc SET specific_field1="10", specific_field2="10" WHERE iinc_id=6

8.3 SENTENCIA DELETE

La sentencia DELETE permite eliminar las tuplas de una vista que verifiquen una determinada condición, actualizando directamente la fuente de datos. La Figura 27 muestra su sintaxis: DELETE FROM <name:identifier> [ WHERE <condition> ] [ CONTEXT ( <context information> [, <context information>]* ) ] [ TRACE ] <condition> ::= <condition> AND <condition> | <condition> OR <condition> | NOT <condition> | ( <condition> ) | <value> <binary operator> <value> [ , <value> ]* | <value> <unary operator>

Figura 27 Sintaxis de la sentencia DELETE

Por ejemplo, la siguiente sentencia borra las tuplas de la vista internet_inc cuyo valor para el atributo iinc_id sea mayor que 4:

DELETE FROM internet_inc WHERE iinc_id>4 Como efecto de la ejecución de esta sentencia, se borrarán las tuplas correspondientes en la base de datos fuente, en la tabla representada por la vista internet_inc.

8.4 USO DE WITH CHECK OPTION

Al crear una vista, DataPort también soporta el uso de la cláusula estándar SQL WITH CHECK OPTION [CASCADED]. Si una vista ha sido creada con esta opción, las actualizaciones de datos que sean inconsistentes con la definición de la vista serán rechazadas y DataPort devolverá un mensaje de error. Por ejemplo, si definimos la vista incidences_acme utilizando la sentencia siguiente:

CREATE VIEW incidences_acme AS SELECT * FROM Internet_inc WHERE taxid="B78596011" WITH CHECK OPTION

Entonces, al ejecutar la siguiente sentencia de inserción, obtendremos un mensaje de error, ya que el valor indicado para el atributo taxid es inconsistente con la condición de selección utilizada para definir incidences_acme.



INSERT INTO incidences_acme (iinc_id, summary, ttime, taxid, specific_field1, specific_field2) VALUES (6,"Error in ADSL Router", "31-mar-2005 22h 35m 24s", "B78596015", "5", "6")

El modificador CASCADED se utiliza para que esta comprobación se aplique también a las condiciones de las vistas de nivel inferior (ver Figura 19). Si no se indica, la comprobación se realizará sólo con las condiciones definidas en esta vista.


Transacciones en DataPort 60

9 TRANSACCIONES EN DATAPORT

DataPort permite definir transacciones haciendo uso de las siguientes cláusulas:

• BEGIN. Permite iniciar una transacción.

• COMMIT. Confirma la transacción activa.

• ROLLBACK. Deshace los cambios realizados en la transacción activa.

Las transacciones en DataPort son distribuidas por naturaleza. Por lo tanto, sólo pueden participar en ellas fuentes de datos que implementen el protocolo Two-Phase-Commit. La mayor parte de gestores de bases de datos comerciales implementan dicho protocolo. Por lo tanto, el tipo principal de fuentes DataPort cuyas vistas pueden participar en transacciones son las fuentes de datos de tipo JDBC/ODBC (ver secciones 17.3.1 y 17.3.2 ). Adicionalmente, los wrappers de tipo CUSTOM y los procedimientos almacenados también pueden participar en transacciones siempre que implementen las operaciones necesarias para ello (ver secciones 17.4.9 y 10.3). Es posible especificar si una fuente de datos soporta o no transacciones distribuidas mediante el uso de la propiedad supportsDistributedTransactions de la configuración de las fuentes (ver secciones 17.3.6 y 17.4.12).


Procedimientos Almacenados 61

10 PROCEDIMIENTOS ALMACENADOS

DataPort soporta la creación de procedimientos almacenados escritos en el lenguaje JAVA. Esta sección describe cómo crearlos y cómo importarlos en DataPort utilizando el lenguaje VQL. La distribución de DataPort contiene diversos ejemplos de procedimientos almacenados (incluyendo su código fuente) en la ruta DENODO_HOME/samples/vdp/storedProcedures. El fichero README en dicha ruta contiene instrucciones para compilar e instalar dichos procedimientos.

10.1 IMPORTACIÓN DE UN PROCEDIMIENTO ALMACENADO

La sentencia CREATE PROCEDURE permite añadir un nuevo procedimiento almacenado al servidor DataPort. La Figura 28 muestra su sintaxis. CREATE [OR REPLACE] PROCEDURE <name:identifier> CLASSNAME <className:literal> [CLASSPATH <classPath:literal>]

Figura 28 Sintaxis de CREATE PROCEDURE

La cláusula CLASSNAME indica el nombre de la clase JAVA que implementa el procedimiento almacenado. Esta clase debe estar presente en el CLASSPATH del servidor DataPort (ver sección Tareas de Post-Instalación de la Guía del Administrador [3]). Opcionalmente, puede utilizarse la cláusula CLASSPATH para indicar librerías adicionales utilizadas por el procedimiento almacenado y que no se encuentren ya en el CLASSPATH del servidor. El uso del modificador OR REPLACE permite especificar que si ya existe un procedimiento con el nombre indicado, éste debe ser reemplazado por el nuevo procedimiento. Esto provocará el recálculo de esquemas y capacidades de las vistas derivadas que utilicen dicho procedimiento. Una vez creado, un procedimiento almacenado puede modificarse utilizando la sentencia ALTER PROCEDURE, cuya sintaxis se muestra en la Figura 29. ALTER PROCEDURE <name:identifier> [CLASSNAME <className:literal>] [CLASSPATH <classPath:literal>]

Figura 29 Sintaxis de ALTER PROCEDURE

La interpretación de las cláusulas CLASSNAME y CLASSPATH es la misma que para la sentencia CREATE PROCEDURE.

10.2 USO DE PROCEDIMIENTOS ALMACENADOS

La invocación de un procedimiento almacenado se realiza mediante la sentencia CALL. Su sintaxis se muestra en la Figura 30. CALL <procedureName:identifier> ( [<paramValue:literal> [ ,<paramValue:literal> ]* ] ) [ CONTEXT ( "i18n" = <literal> ) ] [ TRACE ]

Figura 30 Sintaxis de la sentencia CALL



Por ejemplo, la siguiente sentencia invoca el procedimiento almacenado DropIncidence pasándole un único parámetro de tipo numérico:

CALL DropIncidence(5) Los procedimientos almacenados pueden ser utilizados en la cláusula FROM de una sentencia SELECT. Los valores devueltos por el procedimiento se tratan en este caso de forma análoga a las tuplas de una vista. Por ejemplo:

SELECT avgrevenue FROM CalculateAvgRevenue(ROW("B78596011"),ROW("B78596012"))

En este caso, utilizamos como ejemplo el procedimiento almacenado CalculateAvgRevenue, que recibe como entrada un parámetro de tipo array de registros. Cada registro contiene un único campo, que se corresponde con el CIF de un cliente. Este procedimiento devuelve una única tupla de resultado con un atributo llamado avgrevenue que contiene la media de la facturación de los clientes indicados.

10.3 CREACIÓN DE NUEVOS PROCEDIMIENTOS ALMACENADOS

Las clases e interfaces necesarias para la creación de nuevos procedimientos almacenados se encuentran en el paquete com.denodo.vdb.engine.storedprocedure. En esta sección, se describe brevemente el uso de sus principales clases. Véase la documentación Javadoc [4] para más detalle sobre clases y operaciones. Cualquier procedimiento almacenado debe extender la clase AbstractStoredProcedure, que implementa las interfaces StoredProcedure y StoredProcedureExecutor. Es posible reescribir los siguientes métodos:

• public void initialize(DatabaseEnvironment environment). Método invocado en el momento de inicializar el procedimiento almacenado (cuya implementación es obligatoria). Recibe como parámetro un objeto de tipo DatabaseEnvironment, que proporciona métodos de utilidad para comunicarse con el servidor DataPort. Estos métodos permiten realizar las siguientes acciones (ver documentación Javadoc [4] para más detalle):

o Ejecutar sentencias sobre el servidor DataPort (métodos executeQuery, executeUpdate),

o Obtener referencias a otros procedimientos almacenados del servidor (método lookupProcedure), para poder ejecutarlos.

o Obtener referencias a una función del servidor (método lookupFunction), para poder ejecutarlas,

o Crear transacciones (método createTransaction),

o Unir un procedimiento almacenado a la transacción actual (método joinTransaction),

o Escribir en el log del servidor (método log),



o Obtener el valor de una propiedad del servidor (método getDatabaseProperty). Las propiedades accesibles actualmente mediante este método son CURRENT_USER y CURRENT_DATABASE que indican el nombre del usuario y de la base de datos actuales respectivamente.

• public String getDescription(). Debe devolver la descripción del procedimiento almacenado (obligatorio).

• public String getName(). Debe devolver el nombre del procedimiento almacenado (cuya implementación es obligatoria).

• void prepare(). Opcionalmente, el procedimiento almacenado puede reescribir este método para preparar la transacción actual.

• void commit(). Opcionalmente, el procedimiento almacenado puede reescribir este método para confirmar la transacción actual.

• void rollback().Opcionalmente, el procedimiento almacenado puede reescribir este método para deshacer la transacción actual.

• public StoredProcedureParameter[] getParameters(). Método que debe especificar los parámetros de entrada y salida del procedimiento almacenado (obligatorio). Estos parámetros se devuelven como un array de objetos StoredProcedureParameter. Cada objeto StoredProcedureParameter especifica el nombre, tipo y dirección (entrada o salida) de un parámetro. En caso de que el parámetro sea de tipo compuesto, se debe especificar también un array de objetos StoredProcedureParameter para describir sus campos. Ver documentación Javadoc [4] para más detalle.

• public void doCall(Object[] inputValues) throws StoredProcedureException. Método invocado al ejecutar el procedimiento almacenado (obligatorio).

• public int getNumOfAffectedRows(). Devuelve el número de entidades de datos afectadas por la ejecución del procedimiento (obligatorio).

La clase AbstractStoredProcedure también proporciona los siguientes métodos:

• public StoredProcedureResultSet getProcedureResultSet(). Método utilizado para obtener el objeto StoredProcedureResultSet asociado del procedimiento almacenado. Este objeto es el que contiene los resultados que devolverá el procedimiento almacenado, por lo que normalmente la implementación del método doCall precisará llamar a getProcedureResultSet()para obtenerlo y añadirle los resultados deseados.

• protected static java.sql.Array createArray(Collection values, int type). Método para crear un objeto de tipo SQL array. Necesario cuando el procedimiento almacenado devuelva valores de tipo compuesto.



• protected static java.sql.Struct createStruct(Collection values, int type).Método para crear un objeto de tipo SQL struct. Necesario cuando el procedimiento almacenado devuelva valores de tipo compuesto.

La distribución de DataPort contiene diversos ejemplos de procedimientos almacenados (incluyendo su código fuente) en la ruta DENODO_HOME/samples/vdp/storedProcedures. El fichero README en dicha ruta contiene instrucciones para compilar e instalar dichos procedimientos.

10.4 PROCEDIMIENTOS PREDEFINIDOS

DataPort incluye los siguientes procedimientos almacenados predefinidos:

• WriteLogInfo (String text). Escribe un mensaje en el log del servidor DataPort en el nivel info.

• WriteLogError (String text). Escribe un mensaje en el log del servidor DataPort en el nivel error.

• Wait (long timeInMillis). Espera el tiempo especificado (en milisegundos).

• LogController (String logCategory, String logLevel). Permite modificar el nivel de log para una categoría de log determinada. Su cambio no persiste entre diferentes ejecuciones del servidor.


Definición de Otros Elementos del Catálogo 65

11 DEFINICIÓN DE OTROS ELEMENTOS DEL CATÁLOGO

11.1 DEFINICIÓN DE UN TIPO DE DATO

Virtual DataPort incluye en su catálogo un conjunto de tipos de datos predefinidos (ver Apartado 3.1). Como ya se ha adelantado, los tipos de datos que incluye se pueden dividir en dos grupos: los tipos básicos y los tipos compuestos. Virtual DataPort permite la definición de nuevos tipos de datos compuestos a través de la sentencia CREATE TYPE. Es decir, se permite la creación de tipos de datos de tipo array, enumerated, y register. Véase la sección 18.1 para una explicación detallada de cómo manejar los tipos compuestos array y register. La Figura 31 muestra la sintaxis de la sentencia CREATE TYPE. CREATE TYPE <name:identifier> AS <array>|<enumerated>|<register> <array> ::= ARRAY OF <register> <enumerated> ::= ENUMERATED OF ( <literal> [ , <literal> ]* ) <register> ::= REGISTER OF ( <name:identifier>:<type:identifier> [ , <name:identifier>:<type:identifier>]* )

Figura 31 Sintaxis de la sentencia CREATE TYPE

En la creación de un tipo de dato, es necesario asignarle un nombre único que lo identifique y diferencie del resto de los tipos existentes. Los tipos de dato enumerated (ver sección 3.1) se crean enumerando la lista de valores que admiten, separados por comas. En la Figura 32 se crea un tipo de dato enumerated que representa los días de la semana en inglés. CREATE TYPE daysOfWeek AS ENUMERATED OF (

'MONDAY', 'TUESDAY', 'WEDNESDAY', 'THURSDAY', 'FRIDAY', 'SATURDAY', 'SUNDAY'

);

Figura 32 Creación de un tipo de dato enumerated

Para crear un nuevo tipo register es necesario indicar el tipo de los elementos que contiene y asignarles un nombre. En la Figura 33 se crea un tipo de dato registro que contiene los datos personales referentes a una persona: el nombre (atributo NAME de tipo text), los apellidos (atributo SURNAME de tipo text), teléfono (atributo PHONE de tipo arrayphone), sueldo (atributo PAY de tipo money) y su fecha de cumpleaños (atributo BIRTH de tipo date). CREATE TYPE registerPersonalData AS REGISTER OF (

NAME:text, SURNAME:text, PHONE:arrayphone, PAY:money, BIRTH:date

);



Figura 33 r t Creación de un tipo de dato egis er

Para la definición de un tipo de dato array, es necesario indicar el nombre del tipo register de los elementos que contiene. En la Figura 34 se crea el tipo de dato array denominado array_phone que encapsula una lista de teléfonos, donde cada teléfono se representa a través de un entero. Cada elemento del array array_phone es de tipo registro register_phone. Como se puede observar, el tipo register_phone encapsula a un elemento de tipo int denominado number. CREATE TYPE registerPhone AS REGISTER OF ( NUMBER:int ); CREATE TYPE arrayPhone AS ARRAY OF registerPhone;

Figura 34

t

Creación de un tipo de dato array y del tipo register que contiene

11.2 DEFINICIÓN DE UN MAPA

Un mapa representa una lista de pares clave-valor. Existen los siguientes tipos de mapas:

• simple. Se utilizan con la función MAP (ver sección 4.6).

• i18n. Representan la configuración de internacionalización referente a una localización específica. Algunos ejemplos de parámetros configurados a través de estos ficheros son: moneda, símbolos utilizados como separadores decimales y de miles para la moneda, formato de fecha, etc. Véase el apartado 3.2 para más detalle.

• inputrewrite. Se utilizan para la traducción de valores de condiciones al formato de la fuente para delegar una consulta sobre ella. Son utilizados por la función de transformación sobre condiciones (que forman parte de una regla de reescritura de entrada) denominada MAP().

• outputrewri e. Estos mapas se utilizan para la conversión de enumeraciones, para adaptarlas al formato de integración, a partir del formato de una fuente específica. Este tipo de mapas se utilizan en la función de transformación de salida –que compone una regla de reescritura sobre resultados- denominada MAP().

Virtual DataPort permite la creación de mapas a través de la sentencia CREATE MAP. Su sintaxis se muestra en la Figura 35. Esta sentencia permite la creación de los diferentes tipos de mapas. Para ello se debe indicar el tipo del mapa: i18n, inputrewrite o outputrewrite o simple, el nombre del mapa que lo identifica, y la lista de pares clave-valor que forman parte del mismo. CREATE MAP I18N|SIMPLE|INPUTREWRITE|OUTPUTREWRITE <name:identifier> ( [<name:literal> = <value:literal>]+ ) )

Figura 35 Sintaxis de la sentencia CREATE MAP

La Figura 36 muestra un ejemplo de creación de un mapa de tipo inputrewrite. CREATE MAP INPUTREWRITE daysOfWeek ( 'lunes' = ”TIMETABLE = 'Monday'” 'martes' = ”TIMETABLE = 'Tuesday'” 'miercoles' = ”TIMETABLE = 'Wednesday'” 'jueves' = ”TIMETABLE = 'Thursday'”



'viernes' = ”TIMETABLE = 'Friday'” 'sabado' = ”TIMETABLE = 'Saturday'” 'domingo' = ”TIMETABLE = 'Sunday'” );

Figura 36 Creación de un mapa de tipo inputrewrite


Creación de Bases de Datos, Usuarios y Permisos 68

12 CREACIÓN DE BASES DE DATOS, USUARIOS Y PERMISOS

En esta sección se describen diversos conceptos clave dentro de la arquitectura de Virtual DataPort. La sección 12.1 describe el concepto de base de datos tal y como se entiende en el contexto de un servidor Virtual DataPort. La sección 12.2 describe los conceptos generales sobre la gestión de usuarios y permisos en DataPort. Por último, en la sección 12.3 se describen los comandos VQL que permiten gestionar esta estructura.

12.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, Wrappers, 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. Al instalar un servidor Virtual DataPort se crea una base de datos admin, que no puede ser eliminada.

12.2 ESTRUCTURA DE USUARIOS Y PERMISOS EN VIRTUAL DATAPORT

12.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, modificar 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 o sobre vistas particulares contenidas en las mismas.

12.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 la información relativa a una relación base, vista o procedimiento almacenado de la base de datos. Por ejemplo, ver el esquema, métodos de búsqueda, configuración de caché y “swapping”, etc., de una vista base (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 dichos componentes:

o Ver la información relativa a una relación base, vista o procedimiento almacenado. Por ejemplo, ver el esquema, métodos de búsqueda, configuración de caché, “swapping”, ... de una vista (se corresponde con el comando VQL DESC).

o Ejecutar consultas sobre la vista o procedimiento almacenado (se corresponde con los comandos VQL SELECT o CALL).

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 a través de sentencias INSERT. No aplicables a procedimientos almacenados.

• Permisos de Actualización. Permite actualizar tuplas de la vista a través de sentencias UPDATE. No

aplicables a procedimientos almacenados.

• Permisos de Borrado. Permite borrar tuplas de la vista a través de sentencias DELETE. No aplicables a procedimientos almacenados.

12.3 SENTENCIAS VQL DE BASES DE DATOS, USUARIOS Y PERMISOS

Para gestionar las bases de datos, usuarios y permisos de un servidor Virtual DataPort es necesario acceder con un usuario de tipo administrador y no es necesario 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.

12.3.1 Creación de Bases de Datos

La sentencia VQL CREATE DATABASE permite a un usuario administrador crear una nueva base de datos en el servidor, indicando un nombre para la nueva base de datos y, opcionalmente, una descripción de la misma. En la Figura 37 se muestra la sintaxis de la sentencia CREATE DATABASE. El uso de las opciones de asignación de privilegios a usuarios se describe en la sección 12.3.6. CREATE DATABASE <name:identifier> [<description:literal>] [ <grant> ]* <grant> ::= (see section 12.3.6.1)

Figura 37 Sintaxis de la sentencia CREATE DATABASE

12.3.2 Modificación y Borrado de Bases de Datos

Para ver la lista de bases de datos actuales en el servidor, debe utilizarse el comando LIST (ver apartado 14). Cada usuario verá las bases de datos para las que tiene permiso de conexión. Un usuario administrador tendrá acceso a todas las bases de datos del servidor. Una vez creada una base de datos, un usuario administrador puede modificar su descripción utilizando la sentencia ALTER DATABASE (ver Figura 38). ALTER DATABASE <name:identifier> [ <description:literal> ] [ I18N DEFAULT | <name:identifier> ] [ CACHE DEFAULT | [ON | OFF ] ( [MAINTAINERPERIOD <seconds:integer>] [TIMETOLIVE <seconds:integer>] [DATASOURCE DEFAULT | CUSTOM] ) ] [ SWAP



DEFAULT | [ON | OFF] ( [SWAPSIZE <megabytes:integer>] [BLOCKSIZE <megabytes:integer>] ) ] [ <grant> ]* <grant> ::= (see section 12.3.6.1)

Figura 38 Sintaxis de la sentencia ALTER DATABASE

A través de esta sentencia es posible modificar los privilegios de acceso de los usuarios para la base de datos (ver sección 12.3.6), y las preferencias por defecto en la base de datos para la configuración de la cache (ver sección 18.2.2) y el swapping a disco de consultas de gran tamaño (ver sección 18.2.3). El comando DESC (ver apartado 13) permite obtener información relativa a una base de datos, mostrando los permisos del usuario para esta base de datos. Si el usuario es un administrador, entonces mostrará los permisos de todos los usuarios sobre la base de datos indicada. Un usuario administrador también puede borrar una base de datos del servidor, utilizando el comando DROP (ver apartado 15). Nótese que al borrar una base de datos se eliminarán todos sus componentes: DataSources, vistas, relaciones base, etc.

12.3.3 Creación de usuarios

La sentencia CREATE USER (Figura 39) permite crear un nuevo usuario en el servidor. Como ya se ha comentado previamente, existen dos tipos de usuarios. Un usuario administrador puede crear usuarios de cualquiera de los dos tipos. Para crear un nuevo usuario es necesario indicar su nombre, su password y opcionalmente una descripción. En la sentencia de creación se especifica también si se trata de un nuevo usuario administrador (modificador ADMIN) o de un usuario normal. El modificador ENCRYPTED permite especificar que la contraseña ya se proporciona cifrada y, por lo tanto, no debe cifrarse nuevamente. La autenticación del usuario podrá realizarse contra DataPort o contra un data source de tipo LDAP dado de alta en DataPort (ver sección 17.3.8). El segundo caso se especifica utilizando el modificador LDAP. En ese caso, es necesario proporcionar dos datos adicionales:

• Servidor LDAP a utilizar (DATASOURCE). El formato es <databaseName>.<dataSourceName> donde <databaseName> especifica la base de datos dónde se ha dado de alta el data source LDAP y <dataSourceName> es el nombre del data source.

• Usuario LDAP (USERNAME). Especifica 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.

NOTA: Si se elimina en cascada (ver sección 15) 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). Cómo asignar privilegios a los usuarios se describe en la sección 12.3.6. CREATE USER [ADMIN] <name:identifier> <authentication> [<description:literal>]



[ <grant> ]* <authentication> ::= <password:literal> [ENCRYPTED] | LDAP ( DATASOURCE <databaseName:identifier>.<dataSourceName:identifier> USERNAME <name:literal> ) <grant> ::= (see section 12.3.6.2)

Figura 39 Sintaxis de la sentencia CREATE USER

12.3.4 Modificación y Borrado de usuarios

La sentencia LIST (ver apartado 14) permite obtener un listado de los usuarios del servidor. Es posible obtener la información relativa a un usuario, y a los permisos que posee sobre las diferentes bases de datos y vistas de las mismas mediante el comando DESC (ver apartado 13). Un usuario administrador puede acceder a toda la información de cualquier usuario. El resto de usuarios sólo pueden obtener su propia información. Un usuario administrador puede eliminar usuarios del servidor utilizando la sentencia DROP (ver apartado 15). No es posible borrar el administrador predefinido “admin”.

12.3.4.1 Modificar los datos de un usuario

Cualquier usuario puede modificar su clave de acceso y su descripción utilizando la sentencia ALTER USER (ver Figura 40). En caso de tratarse de un usuario que se autentica contra un servidor LDAP es también posible modificar los datos del servidor (ver sección 12.3.3). También es posible modificar los privilegios de un usuario (ver sección 12.3.6). ALTER USER <name:identifier> [ <authentication> ] [ <description:literal> ] [ <grant> ]* <authentication> ::= PASSWORD <password:literal> | LDAP ( [DATASOURCE <databaseName:identifier>.<dataSourceName:identifier> ] [ USERNAME <name:literal> ] ) <grant> ::= (see section 12.3.6.2)

Figura 40 Sintaxis de la sentencia ALTER USER

12.3.5 Cambio de Base de Datos Activa

En el transcurso de una sesión contra el servidor Virtual DataPort, un usuario puede requerir la conexión a una base de datos del servidor o la utilización de un usuario diferente para realizar determinadas tareas que requieran otros permisos. Para permitir esta funcionalidad pueden utilizarse los comandos CONNECT y CLOSE (Figura 41). CONNECT [USER <name:identifier> PASSWORD <password:literal>] [DATABASE <name>]CLOSE



Figura 41 Sintaxis de las sentencias CONNECT y CLOSE

El comando CONNECT permite indicar un nombre de usuario y su clave para iniciar una nueva sesión en el servidor con un nuevo perfil. Es posible también iniciar una sesión con una nueva base de datos (con el usuario actual u otro usuario). El comando CLOSE permite restablecer la sesión anterior, después de haber establecido una nueva sesión con el comando CONNECT.

12.3.6 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, vistas y procedimientos almacenados del sistema. Esta tarea sólo la pueden realizar usuarios administradores. La modificación de privilegios de un usuario puede realizarse a nivel de base de datos para un conjunto de usuarios, o de forma individual por usuario.

12.3.6.1 Especificación de privilegios por base de datos

Utilizando las sentencias CREATE DATABASE (Figura 37) o ALTER DATABASE (Figura 38) es posible especificar los privilegios de acceso de los diferentes usuarios del servidor a nivel de base de datos, haciendo uso de las cláusulas GRANT y REVOKE. En la Figura 42 se muestra la sintaxis de estas cláusulas para la asignación de permisos de usuarios a nivel global de base de datos. A nivel de base de datos es posible conceder o revocar todos los permisos (ALL PRIVILEGES), o una lista de los siguientes permisos:

- CONNECT: Permite que el usuario indicado se conecte a la base de datos. Si un usuario no posee este permiso sobre una base de datos, el resto de privilegios no se consideran.

- CREATE: Permite que un usuario pueda crear nuevos elementos en el catálogo del servidor. - READ: Permite que un usuario acceda a todas las vistas y procedimientos almacenados de la base de

datos indicada. - WRITE: Permite que el usuario especificado modifique o borre cualquier vista y/o procedimiento

almacenado de la base de datos indicada. El permiso de escritura implica al permiso de lectura. <grant> ::= GRANT <database privileges> TO <user:identifier> REVOKE <database privileges> TO <user:identifier> <database privileges> ::= ALL PRIVILEGES | <database privilege list> <database privilege list> ::= <database privilege> [, <database privilege>]* <database privilege> ::= CONNECT | CREATE | READ | WRITE

Figura 42 Sintaxis de las cláusulas GRANT/REVOKE para Bases de Datos

12.3.6.2 Especificación de privilegios por usuario

Los privilegios de un usuario pueden asignarse también cuando se crea el usuario o una vez creado con las sentencias CREATE USER (Figura 39) o ALTER USER (Figura 40) respectivamente.



La gestión de privilegios de un usuario se realiza mediante la utilización de las cláusulas GRANT (asignar privilegios) y REVOKE (revocar privilegios). Pueden distinguirse dos casos:

- asignación de permisos de usuarios a bases de datos - asignación de permisos de usuarios a vistas o procedimientos almacenados de bases de datos.

En la Figura 43 se muestra la sintaxis de estas cláusulas para la asignación de permisos de usuarios a nivel global de base de datos. A nivel de base de datos es posible conceder o revocar todos los permisos (ALL PRIVILEGES), o una lista de los siguientes permisos:

- CONNECT: Permite que el usuario se conecte a la base de datos indicada. Si un usuario no posee este permiso sobre una base de datos, el resto de privilegios no se consideran.

- CREATE: Permite que el usuario pueda crear nuevos elementos en el catálogo del servidor. - READ: Permite que el usuario acceda a todas las vistas y/o procedimientos almacenados de la base de

datos indicada. - WRITE: Permite que el usuario modifique o borre cualquier vista y/o procedimiento almacenado de la

base de datos indicada. El permiso de escritura implica al permiso de lectura. <grant> ::= GRANT <database privileges> ON <database:identifier> | REVOKE <database privileges> ON <database:identifier> <database privileges> ::= ALL PRIVILEGES | <database privilege list> <database privilege list> ::= <database privilege> [, <database privilege>]* <database privilege> ::= CONNECT | CREATE | READ | WRITE

Figura 43 Sintaxis de las cláusulas GRANT/REVOKE para Bases de Datos

En la Figura 44 se muestra la sintaxis de estas cláusulas para la asignación de permisos de usuarios a nivel de vistas y/o procedimientos almacenados. Estas asignaciones se hacen efectivas cuando un usuario no tiene acceso de lectura o escritura global sobre todos los elementos de la base de datos. En el caso de asociación de privilegios de usuarios sobre vistas de una base de datos, son aplicables los permisos READ, WRITE, INSERT, UPDATE y DELETE. <grant> ::= GRANT <view privileges> ON <database::identifier>.<view::identifier>] | GRANT <procedure privileges> ON PROCEDURE <database:identifier>.<procedure:identifier> | REVOKE <view privileges> ON <database::identifier>.<view::identifier>] | REVOKE <procedure privileges> ON PROCEDURE <database:identifier>.<procedure:identifier> <view privileges> ::= ALL PRIVILEGES | <view privilege list> <view privilege list> ::= <view privilege> [, <view privilege>]* <view privilege> ::= READ | WRITE | INSERT | UPDATE | DELETE



<procedure privileges> ::= ALL PRIVILEGES | <procedure privilege list> <procedure privilege list> ::= <procedure privilege> [, <procedure privilege>]* <procedure privilege> ::= READ | WRITE | INSERT | UPDATE | DELETE

Figura 44 Sintaxis de las cláusulas GRANT/REVOKE para vistas

En la Figura 45 se muestra un ejemplo en el que se crean dos bases de datos, “database1” y “database2”, y un usuario “user1” al que se le asignan los siguientes privilegios sobre las bases de datos “database1” y “database2”:

- posee todos los privilegios sobre “database1” - tiene permiso de conexión a “database2” y permisos de creación, pero sólo posee permisos de

lectura/escritura para la vista “view1”. CREATE DATABASE database1 ‘Database1 Description’; CREATE DATABASE database2 ‘Database2 Description’; CREATE USER user1 ‘user1password’ ‘User1 Description’ GRANT ALL PRIVILEGES ON database1 GRANT CONNECT, CREATE ON database2 GRANT READ,WRITE ON database2.view1;

Figura 45 Ejemplo de asignación de privilegios a usuarios


Descripción de Elementos del Catálogo 76

13 DESCRIPCIÓN DE ELEMENTOS DEL CATÁLOGO

En los apartados anteriores, se han explicado las sentencias que permiten la creación y modificación de algunos de los elementos que componen el catálogo o diccionario de datos de Virtual DataPort: relaciones base, vistas derivadas, wrappers, datasources, tipos de dato, mapas, bases de datos y usuarios. Virtual DataPort permite visualizar el estado actual de algunos de los elementos que pertenecen al catálogo, a través de la sentencia DESC. DESC DATABASE | USER | TYPE | PROCEDURE |VIEW [TREE] <name:identifier> DESC DATASOURCE ARN | CUSTOM | DF | GS | JDBC | LDAP | ODBC | WS | XML <name:identifier> DESC MAP I18N | INPUTREWRITE | OUTPUTREWRITE | SIMPLE <name:identifier> DESC OPERATOR <name:operator> <type:identifier> DESC PROCEDURE AS VIEW <name:identifier> ( [<procedureParameter> [,<procedureParameter>]*] ) <procedureParameter> ::= <value> DESC WRAPPER ARN | CUSTOM | DF | GS | ITP | JDBC | ODBC | WS | XML <name:identifier> DESC SESSION DESC VQL VIEW | PROCEDURE | TYPE <name:identifier> DESC VQL WRAPPER ARN | CUSTOM | GS | DF | ITP | JDBC | ODBC | WS | XML <name:identifier> DESC VQL MAP I18N | INPUTREWRITE | OUTPUTREWRITE | SIMPLE <name:identifier> DESC VQL DATABASE [ <name:identifier> ]

Figura 46 Sintaxis de la sentencia DESC

En la Figura 46 se muestran las opciones disponibles para la descripción de distintos elementos del catálogo. El primer grupo de sentencias permite obtener los diferentes elementos del catálogo, y una descripción de los mismos:

- La primera sentencia, permite solicitar la descripción de una base de datos, un usuario, un tipo de dato, un procedimiento almacenado o una vista, a partir de su nombre. De forma opcional, cuando se describe una vista se puede indicar el modificador TREE que permite obtener el conjunto de vistas sobre las que se define la vista actual, junto con los operadores de álgebra relacional que las combinan.

- La sentencia DESC DATASOURCE permite visualizar los diferentes tipos de datasources definidos en el catálogo.

- La sentencia DESC MAP permite visualizar el contenido de un mapa de tipo i18n, inputrewrite o outputrewrite.

- La sentencia DESC OPERATOR solicita la descripción de un operador para un tipo de dato específico. - La sentencia DESC PROCEDURE AS VIEW describe un procedimiento almacenado tratándolo como

una vista. Esto es útil porque los procedimientos almacenados de DataPort pueden aparecer en la cláusula FROM de una consulta o vista (ver sección 10.2). En ese caso, es necesario especificar los parámetros de invocación al procedimiento.


Descripción de Elementos del Catálogo 77

- La sentencia DESC WRAPPER permite visualizar los diferentes tipos de wrappers definidos en el catálogo.

Con la sentencia DESC SESSION un usuario puede obtener el nombre de base de datos contra la que está conectado, y el nombre de login utilizado para la conexión. El grupo de sentencias DESC VQL permite visualizar el conjunto de sentencias VQL necesarias para la creación de una vista, tipo de datos, procedimiento almacenado, datasource o wrapper de uno de los tipos especificados. 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 para crear 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).

13.1 EXPORTACIÓN DE METADATOS

Mediante la sentencia DESC VQL DATABASE es posible exportar todos los metadatos de una determinada base de datos de Virtual DataPort, o incluso de todo el sistema. Esto es especialmente útil para propósitos de backup y de migración desde una instalación de Virtual DataPort a otra. Si la sentencia DESC VQL DATABASE especifica el nombre de una base de datos, se exportarán todos los metadatos de la base de datos especificada, si bien no se incluirán los usuarios ni las asignaciones de permisos activas para la misma. Tampoco se incluirá la sentencia CREATE DATABASE necesaria para la creación de la base de datos. Si se utiliza DESC VQL DATABASE sin especificar el nombre de una base de datos, entonces se exportarán todos los metadatos del sistema, incluyendo todas las bases de datos, los usuarios y las asignaciones de permisos. Para ejecutar esta sentencia, es necesario utilizar un usuario de tipo administrador.


Listado de Elementos del Catálogo 78

t

14 LISTADO DE ELEMENTOS DEL CATÁLOGO

La sentencia LIST permite listar los elementos existentes en el catálogo. En la Figura 47 se muestran las diferentes opciones de utilización de esta sentencia:

- La primera permite solicitar el listado de todas las bases de datos, usuarios, o configuraciones de internacionalización.

- LIST TYPES muestra todos los tipos de datos del catálogo o los de una característica determinada (enumerados, array o registro).

- LIST VIEWS permite listar las relaciones base o todas las vistas definidas en el servidor. - LIST PROCEDURES permite listar los procedimientos almacenados definidos en el servidor. - LIST PATTERNS permite listar las reglas de reescritura -de tipo raw o no- existentes para un método

de búsqueda de una relación o vista. - LIST OPERATORS permite listar los operadores que actúan sobre un tipo de dato específico, es decir,

los que admiten como operandos valores de un tipo de dato concreto. - LIST WRAPPERS muestra la enumeración de wrappers del tipo especificado (ver sección 17). - LIST DATASOURCES muestra el listado de orígenes de datos del tipo especificado (ver sección 17.3). - LIST MAPS permite listar todos los mapas de tipo simple, i18n, inputrewrite o outputrewri e .

LIST DATABASES | USERS | I18NS ] LIST TYPES [ ENUMERATED | ARRAY | REGISTER ] LIST VIEWS [ BASE | ALL ] LIST INPUT | OUTPUT PATTERNS [RAW] <view:identifier> <container:identifier> LIST OPERATORS [ <type:identifier> ] LIST WRAPPERS ARN | CUSTOM | DF | GS | ITP | JDBC | MY | ODBC | WS | XML LIST DATASOURCES ARN | CUSTOM | DF | GS | JDBC | LDAP [ALL] | ODBC | WS | XML LIST MAPS I18N | INPUTREWRITE | OUTPUTREWRITE | SIMPLE LIST PROCEDURES

Figura 47 Sintaxis de la sentencia LIST

Por ejemplo, para listar las bases de datos existentes se ejecuta la siguiente sentencia: LIST DATABASES;

Si se desean listar los mapas de tipo i18n, se utiliza la sentencia: LIST MAPS I18N;


Listado de Elementos del Catálogo 79

Para listar las reglas de reescritura de entrada de tipo no raw para el método de búsqueda shopview_sm1 de la vista base shopview, se ejecuta:

LIST INPUT PATTERNS shopview shopview_sm1;

Y para listar los operadores que operan sobre el tipo de dato int se utiliza la sentencia: LIST OPERATORS int;


Eliminación de Elementos del Catálogo 80

15 ELIMINACIÓN DE ELEMENTOS DEL CATÁLOGO

El servidor Virtual DataPort también permite eliminar un elemento específico del diccionario de datos, mediante la sentencia DROP. DROP DATABASE | USER [ IF EXISTS ] <name:identifier> DROP TYPE [ IF EXISTS ] <name:identifier> [ CASCADE ] DROP VIEW | TABLE [ IF EXISTS ] <name:identifier> | <name:literal> [ CASCADE ] DROP WRAPPER ARN | CUSTOM | DF | GS | ITP | JDBC | ODBC | WS | XML [ IF EXISTS ] <name:identifier> [ CASCADE ] DROP DATASOURCE ARN | CUSTOM | DF | GS | JDBC | LDAP | ODBC | WS | XML [ IF EXISTS ] <name:identifier> [ CASCADE ] DROP MAP INPUTREWRITE | OUTPUTREWRITE | I18N | SIMPLE [ IF EXISTS ] <name:identifier> DROP PROCEDURE [ IF EXISTS ] <name:identifier>

Figura 48

t

Sintaxis de la sentencia DROP

En la Figura 48 se muestran los distintos usos de la sentencia DROP: - Eliminación de una base de datos o un usuario del sistema. - Eliminación de un tipo de datos. - Eliminación de una vista (base o derivada) a partir de su nombre. - Eliminación de un wrapper específico (ver sección 17) o un origen de datos (ver sección 17.3), indicando su

tipo y nombre. - Eliminación de un mapa concreto del diccionario de datos, a partir de su tipo (i18n, inputrewrite,

outputrewri e) y su nombre - Eliminación de un procedimiento almacenado.

En todos los casos anteriores es posible incluir el modificador IF EXISTS. En ese caso la sentencia DROP se ejecutará solamente en caso de que el elemento especificado exista. Las sentencias de borrado de vistas, tipos, wrappers y datasources admiten el modificador opcional CASCADE. Si no se indica este modificador, cuando se intenta borrar uno de esos elementos se producirá un error si algún otro elemento del catálogo depende de él (por ejemplo, si se borra un datasource y existe un wrapper que lo utiliza). En este caso, el elemento no podrá ser borrado. Si se utiliza CASCADE, borra el elemento indicado, y todos los elementos que dependían de él. Si el usuario que está realizando el borrado no dispone de permisos sobre todos los elementos involucrados, la operación de borrado fallará. A continuación se muestran algunos ejemplos de utilización de la sentencias DROP. Para eliminar la vista shopview se ejecutaría la siguiente sentencia:

DROP VIEW shopview;

Para eliminar el wrapper ITP denominado shopview sería suficiente ejecutar: DROP WRAPPER ITP shopview;


Eliminación de Elementos del Catálogo 81

Y para eliminar el mapa tipo i18n es_euro se utilizaría la sentencia:

DROP MAP I18N es_euro;


Otros Comandos 82

16 OTROS COMANDOS

16.1 BORRADO DE ENTRADAS DE LA CACHÉ DEL DICCIONARIO DE DATOS

El contenido del catálogo de Virtual DataPort se almacena en disco, según una política de almacenamiento de metadatos específica. Con el fin de reducir el tiempo de acceso a los elementos del catálogo, el servidor realiza caché en memoria de algunos de sus elementos como son: vistas, tipos de datos, wrappers, datasources, usuarios, bases de datos y mapas. El sistema proporciona una sentencia que permite borrar el contenido de los diferentes sistemas caché que utiliza a través de la sentencia CLEAR CACHE (ver Figura 49). De esta forma permite forzar la recarga de metadatos desde su almacenamiento persistente. CLEAR CACHE OF ALL | VIEWS | TYPES | WRAPPERS | DATASOURCES | USERS | DATABASES | PROCEDURES | MAPS [I18N | INPUTREWRITE | OUTPUTREWRITE | SIMPLE ]

Figura 49 Sintaxis de la sentencia CLEAR CACHE

Si se desea borrar el contenido de la caché referente a las vistas, tipos de datos, wrappers, datasources, usuarios o bases de datos, se debe parametrizar la sentencia CLEAR CACHE con las opciones VIEWS, TYPES, WRAPPERS, DATASOURCES, USERS, DATABASES y PROCEDURES respectivamente. Por otro lado, si se desea eliminar la caché de los mapas, de internacionalización y los utilizados por las funciones de transformación de entrada y de salida MAP() (es decir, los mapas de tipo inputrewrite y outputrewrite) la sentencia se debe parametrizar con la opción MAPS I18N, SIMPLE, INPUTREWRITE, OUTPUTREWRITE, respectivamente. Por último, la sentencia CLEAR CACHE ALL, permite borrar todos los sistemas de caché de metadatos existentes en Virtual DataPort.

16.2 COMANDO DE AYUDA

Virtual DataPort incluye una sentencia de ayuda, HELP, que presenta al usuario una visión detallada de la sintaxis de todos los comandos existentes. La sintaxis del comando HELP se muestra en la Figura 50. La sentencia HELP, si no recibe ningún parámetro, presenta su propia sintaxis. Opcionalmente, admite como parámetro el nombre del comando para el que se desea la ayuda. Por ejemplo, la sentencia de la Figura 51 permite al usuario conocer en detalle la sintaxis del comando ALTER TABLE. HELP <topic> <topic> ::= ALTER DATABASE | ALTER DATASOURCE ARN | CUSTOM | DF | GS | JDBC | LDAP | ODBC | WS | XML | ALTER PROCEDURE | ALTER TABLE


Generación de Wrappers y DataSources 84

17 GENERACIÓN DE WRAPPERS Y DATASOURCES

Los wrappers son componentes encargados de ofrecer al servidor una visión de las fuentes acorde a un modelo común. Cada método de búsqueda en una relación base tiene asociado un wrapper que es el encargado de recibir las consultas emitidas sobre ella, transformarlas en consultas sobre la fuente, y obtener sus resultados, devolviéndolos a la capa lógica de acuerdo a un formato compatible con la relación base. Los wrappers hacen que para el servidor sean transparentes las peculiaridades de la obtención de datos desde las fuentes. Virtual DataPort incluye los siguientes tipos predefinidos de wrappers:

• ITPilot: Se utiliza para incorporar en el sistema wrappers para fuentes semi-estructuradas creados con Denodo ITPilot [6]. Estas fuentes pueden estar accesibles desde el sistema de ficheros local, vía web, o vía FTP. El tipo de fuente más importante para el que se utiliza este envoltorio son las fuentes web, pero puede ser utilizado para otras fuentes semi-estructuradas (ver documentación de Denodo ITPilot [6]).

• JDBC: Extraen datos desde una Base de Datos Remota vía JDBC.

• ODBC: Extraen datos desde una Base de Datos Remota vía ODBC.

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

• XML: Son aquellos que permiten extraer datos encapsulados en ficheros XML, que pueden seguir opcionalmente una cierta DTD o esquema.

• DF: Extraen datos de ficheros de texto planos, que utilizan determinados caracteres como delimitadores de tupla y campo. Entre los ficheros soportados se encuentran aquellos en formato CSV que suelen obtenerse como resultado de volcar datos de bases de datos o documentos Excel.

• ARACNE. Permiten acceder a índices sobre información no estructurada creados utilizando Denodo Aracne [16].

• GOOGLE MINI. Permiten acceder a índices sobre información no estructurada creados con la herramienta de búsqueda Google Mini [17].

• CUSTOM (también llamados MY): Extraen la información de una fuente, a través de una implementación Java específica. Este tipo de wrapper permite la construcción ad-hoc de un programa envoltorio para un tipo de fuente específico.

Para todos los wrappers excepto los de tipo ITPilot existen elementos datasource para encapsular cierta información de acceso y configuración a la fuente de datos. Adicionalmente existe un tipo de datasource para representar los servidores LDAP que pueden ser utilizados para autenticar a usuarios de DataPort (ver sección 12.3.3). Los datasources LDAP no tienen wrappers asociados. En esta sección se describe la forma de crear en Virtual DataPort nuevos wrappers (y sus datasources) de cualquiera de estos tipos.



El resto de esta sección se estructura cómo sigue. Las secciones 17.1 y 17.2 definen aspectos de interés general para el resto de la sección: las conversiones válidas de tipos entre los wrappers y las relaciones base en Virtual DataPort, y las formas de especificar rutas a recursos dentro de Virtual DataPort. La sección 17.3 especifica cómo añadir al sistema fuentes de datos (DataSources) de los diversos tipos disponibles. Finalmente, la sección 17.4 muestra cómo crear wrappers para cada uno de estos tipos de fuente.

17.1 CONVERSIONES VÁLIDAS ENTRE TIPOS EN LOS WRAPPERS Y VDP

En esta sección se describen los mappings de compatibilidad entre los tipos Java exportados por los wrappers y los tipos de dato utilizados por Virtual DataPort en las relaciones base y vistas (ver sección 3.1). A la hora de asignar wrappers a relaciones base será necesario tener en cuenta estas reglas de compatibilidad para asegurarse de que los esquemas definidos para los wrappers y las relaciones base son compatibles. La siguiente tabla muestra los mappings de tipos más comunes. Estos son también los mappings aplicados de forma automática por la herramienta gráfica de administración de Virtual DataPort (ver Guía del Administrador [3]).

Tipos Java Tipos Virtual DataPort int, java.lang.Short, java.lang.Integer int long, java.lang.Long long float, java.lang.Float float double, java.lang.Double double boolean, java.lang.Boolean boolean java.lang.String text java.util.Date, java.util.Calendar, java.sql.Date, java.sql.Timestamp, java.sql.Time

date

byte[], java.sql.Blob blob

Tabla 2 Conversiones automáticas entre tipos JAVA y tipos Virtual DataPort

Por defecto, cualquier otro tipo de dato java no especificado en esta tabla, se asociará al tipo de dato VDP text. Existen otros mappings posibles entre tipos Java y tipos Virtual DataPort, que pueden especificarse pero que no se aplican de forma automática. Pueden verse en la siguiente tabla.

Tipos Java Tipos Virtual DataPort long, java.lang.Long time java.lang.String enumerated java.lang.String link java.lang.String xml double, java.lang.Double money

Tabla 3 Otras conversiones válidas entre tipos JAVA y tipos Virtual DataPort

Por otra parte, los wrappers pueden proporcionar elementos compuestos como arrays y registros, que se asocian directamente a arrays y registros utilizados por el servidor VDP.

17.1.1 Conversiones de tipo nativo de un wrapper a tipos Java

Cada tipo de wrapper posee sus propias asociaciones entre los tipos nativos de las fuentes que modelan y tipos java. En los siguientes apartados se muestran las conversiones aplicadas a los diferentes tipos de wrappers soportados por Virtual DataPort.



En general, para aquellos wrappers que accedan a fuentes que puedan devolver objetos o arrays de objetos, el wrapper es responsable de representar estas estructuras mediante registros y arrays respectivamente.

17.1.1.1 Tabla de conversiones de tipos para wrappers JDBC

Tipos JDBC Tipos Java ARRAY Clase propietaria JDBCArrayTypeVO BIGINT java.lang.Long BINARY java.lang.String BIT java.lang.Boolean BLOB byte [] BOOLEAN java.lang.Boolean CHAR java.lang.String CLOB java.lang.String DATALINK java.lang.String DATE java.sql.Date DECIMAL java.lang.Double DISTINCT java.lang.String DOUBLE java.lang.Double FLOAT java.lang.Float INTEGER java.lang.Integer JAVA_OBJECT java.lang.String LONGVARBINARY java.lang.String LONGVARCHAR java.lang.String NULL java.lang.String NUMERIC java.lang.Double OTHER JDBCRegisterTypeVO REAL java.lang.Float REF java.lang.String SMALLINT java.lang.Short STRUCT JDBCRegisterTypeVO TIME java.sql.Time TIMESTAMP java.sql.Timestamp TINYINT java.lang.Byte VARBINARY java.lang.String VARCHAR java.lang.String

Tabla 4 Conversiones de tipos JDBC

El resto de tipos se convierte a java.lang.String. Dependiendo de la versión de base de datos a la que se accede, pueden existir diferentes conversiones.

17.1.1.2 Tabla de conversiones de tipos para wrappers ODBC

Para los wrappers ODBC se aplican las mismas convesiones que para los wrappers JDBC en los que se basa.

17.1.1.3 Tabla de conversiones de tipos para wrappers de fuentes web

Los wrappers para fuentes web generados con ITPilot 4.0 o posterior utilizan la siguiente tabla de conversión de tipos:

Tipos ITPilot Tipos Java boolean boolean date java.util.Calendar



double double float float int int string java.lang.String url java.lang.String

Tabla 5 Conversiones de tipos ITPilot

Los wrappers de fuentes web generados con versiones de ITPilot anteriores a la 4.0 no proporcionan información relativa al tipo de los elementos que obtienen, por lo que se encapsulan utilizando la clase java java.lang.String.

17.1.1.4 Tabla de conversiones de tipos para wrappers de Servicios Web

Tipos SOAP Tipos Java xsd:base64Binary byte[] xsd:boolean boolean xsd:byte byte xsd:dateTime java.util.Calendar xsd:decimal java.math.BigDecimal xsd:double double xsd:float float xsd:hexBinary byte[] xsd:int int xsd:integer java.math.BigInteger xsd:long long xsd:QName java.lang.String con formato

"namespacelocalPart" xsd:short short xsd:string java.lang.String

Tabla 6 Conversiones de tipos de Web Services

El resto de elementos se tratan como objetos Java utilizando la API de instrospección para acceder a sus propiedades y de esta forma poder reconstuir su estructura.

17.1.1.5 Tabla de conversiones de tipos para wrappers XML

Tipos XML-Schema Tipos Java Positiveinteger negativeinteger nonpositiveinteger nonnegativeinteger int unsignedint gYear gMonth gDay

java.lang.Integer

long unsignedlong

java.lang.Long



byte unsignedbyte

java.lang.Byte

Double java.lang.Double Float java.lang.Float short unsignedshort

java.lang.Short

Boolean java.lang.Boolean string normalizedString token base64Binary hexBinary duration dateTime date time gYearMonth gMonthDay

java.lang.String

Tabla 7 Conversiones de tipos XML

17.1.1.6 Tabla de conversiones de tipos para wrappers de ficheros delimitados

Un wrapper DF no posee metainformación que permita identificar valores de datos almacenados en un fichero con sus tipos, por lo que un wrapper DF siempre trata los elementos obtenidos encapsulados en la clase java java.lang.String.

17.1.1.7 Tabla de conversiones de tipos para wrappers CUSTOM

Un wrapper CUSTOM indica los tipos de sus campos con clases Java, por lo que no requiere conversiones.

17.1.1.8 Tabla de conversiones de tipos para wrappers Aracne

Todos los campos de los índices de Denodo Aracne serán traducidos a atributos de tipo text en DataPort. Los wrappers creados en base a índices de Denodo Aracne incluyen algunos atributos adicionales a los contenidos en el índice original que pueden ser de otros tipos. Ver sección 17.4.9.

17.1.1.9 Tabla de conversiones de tipos para wrappers Google Mini

Todos los campos de los índices de Google Mini serán traducidos a atributos de tipo text en DataPort, excepto el campo RATING que es de tipo entero. Los wrappers creados en base a índices de Google Mini incluyen algunos atributos adicionales a los contenidos en el índice original que pueden ser de otros tipos. Ver sección 17.4.10.

17.2 ESPECIFICACIÓN DE RUTAS EN VIRTUAL DATAPORT

Virtual DataPort utiliza la especificación de rutas en diversos puntos de la creación de fuentes de datos (DataSources) y wrappers. Estas rutas permiten localizar un determinado recurso (fichero, página web, etc.). En Virtual DataPort existen tres tipos de rutas, que se describen a continuación junto con los parámetros que es necesario especificar habitualmente para cada una de ellas en una sentencia VQL:



• LOCAL: Ruta que accede a un recurso dentro de un sistema de ficheros local. Necesita los siguientes parámetros:

o El nombre de la clase utilizada para implementar la conexión utilizada por la ruta. Para este tipo de rutas, se proporciona una única clase conexión: LocalConnection.

o La ruta local al recurso (e.g. fichero).

• HTTP: Ruta que representa el acceso a un recurso a través de un servidor web. Es necesario especificar los siguientes parámetros:

o El nombre de la clase utilizada para implementar la conexión utilizada por la ruta. Para este tipo de rutas, se proporcionan dos clases diferentes:

http.HTTPClientConnection: Realiza una conexión contra un servidor web utilizando el protocolo http para acceder a un recurso remoto. Opcionalmente, recibe como parámetro el tiempo máximo a esperar para obtener las cabeceras de respuesta de la petición http realizada. Por ejemplo, la declaración de conexión siguiente indica que se utilice este tipo de conexión con un tiempo máximo de respuesta de 2 minutos: http.HTTPClientConnection,120000.

http.IEBrowserConnection: Realiza una conexión contra un servidor web utilizando un pool de browsers de Denodo ITPilot [6]. Estos navegadores son capaces de ejecutar secuencias de navegación avanzadas sobre el navegador Microsoft Internet Explorer [10], escritas en el lenguaje definido por ITPilot. No recibe ningún parámetro.

o Patrón de Acceso (urlpatron). Representa una secuencia de navegación a una fuente web, cuyo formato debe ser entendible por la clase conexión utilizada. La clase http.HTTPClientConnection permite especificar una petición http (expresada en el formato habitual utilizado para peticiones GET). ITPilot [6] proporciona un lenguaje de secuencias de navegación llamado NSEQL para la clase conexión http.IEBRowserConnection. En ambos casos la ruta puede incluir variables de interpolación cuyo valor será obtenido en tiempo de ejecución (ver sección 18.4).

o Método de Acceso (method). Indica el método http de acceso a utilizar con la ruta. Puede tomar los valores GET o POST. En la actualidad, este parámetro sólo se considera si se utiliza la clase conexión http.HTTPClientConnection.

• FTP: Ruta que accede a un archivo vía FTP. Recibe como parámetros:

o El nombre de la clase utilizada para implementar la conexión utilizada por la ruta. Para este tipo de rutas, se proporciona una única clase conexión: ftp.FTPBeanConnection.

o URL del servidor apuntando al recurso (host:port/path/file).



o Identificador del usuario que debe ser utilizado para el acceso, y

o Contraseña para ese usuario.

17.3 CREACIÓN DE DATASOURCES

Antes de describir en detalle cada uno de los tipos de wrappers existentes en Virtual DataPort, es necesario introducir el concepto de DataSource. Los DataSources son utilizados por los wrappers para la localización de su origen de datos. Esto permite, además de la reutilización del localizador de la fuente en base a un nombre, mantener y configurar pools de conexiones sobre la misma, (si este concepto es aplicable a ese tipo de fuente). Por ejemplo, el uso de pool de conexiones es imprescindible por consideraciones de eficiencia a la hora de tratar orígenes de datos relacionales. Las siguientes secciones describen el proceso manual de creación de cada tipo de DataSource. NOTA: Se recomienda fuertemente que el proceso de creación de wrappers y datasources se realice de forma gráfica mediante la herramienta de administración de DataPort (ver [3]).

17.3.1 DataSources JDBC

Para agilizar el acceso a fuentes JDBC, evitando el costoso proceso de creación de una nueva conexión cada vez que se realiza una consulta, se permite especificar en los DataSources de tipo JDBC diferentes parámetros para el pool de conexiones. En caso de no especificar todos los posibles parámetros implícitamente en la sentencia de creación, se utilizarán los valores por defecto. Para la definición de un origen de datos JDBC es necesario especificar:

- DRIVERCLASSNAME: La clase driver a utilizar para la conexión al origen de datos. - DATABASEURI: El URL de conexión a la base de datos. - USERNAME: El nombre del usuario a utilizar para el acceso. - USERPASSWORD: La clave de acceso para el usuario utilizado. - CLASSPATH: Ruta al archivo JAR conteniendo el driver JDBC para la fuente especificada (opcional). - Parámetros de identificación de la base de datos a la que se accede (importantes para considerar las

características especiales de las diferentes bases de datos utilizadas como origen de información). Estos campos son opcionales. Si no se especifican, entonces se utiliza la configuración general de acceso a una base de datos.

o DATABASENAME: Nombre de la base de datos a la que acceder. o DATABASEVERSION: Número de versión del origen de datos.

- Parámetros de inicialización del pool de conexiones asociado a este origen de datos (opcionales). o VALIDATIONQUERY: 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. Por defecto, si no se especifica, se utiliza “SELECT COUNT (*) FROM SYS.DUAL”.

o INITIALSIZE: Número de conexiones con las que se desea inicializar el pool. Se establecen y crean un número de conexiones en estado “idle” (ocioso), listas para ser usadas. Por defecto, si no se especifica, su valor es 4.

o MAXACTIVE: Número máximo de conexiones que puede gestionar el pool al mismo tiempo. Por defecto, si no se especifica, 8. (Cero implica sin límite)

- Parámetros de configuración de la fuente de datos (SOURCECONFIGURATION). Virtual DataPort permite indicar características concretas de las fuentes subyacentes para tenerlas en cuenta a la hora de ejecutar sentencias sobre ellas. Ver sección 17.3.6 para más detalle.



La sentencia de creación del origen de datos también permite especificar el modificador OR REPLACE. En ese caso, si ya existe un origen de datos con el mismo nombre, su definición será sustituida por la nueva. En la siguiente figura se muestra la sintaxis de creación de DataSources JDBC, con la opcionalidad de los diferentes grupos de parámetros.

CREATE [ OR REPLACE ] DATASOURCE JDBC <name:identifier> DRIVERCLASSNAME=<literal> DATABASEURI=<literal> USERNAME=<literal> USERPASSWORD=<literal> [ CLASSPATH=<literal> ] [ DATABASENAME=<literal> DATABASEVERSION=<literal> ] [ VALIDATIONQUERY=<literal> INITIALSIZE=<integer> MAXACTIVE=<integer> ] [ VALIDATIONQUERY=<literal> INITIALSIZE=<integer> MAXIDLE=<integer> MINIDLE=<integer> MAXACTIVE=<integer> EXHAUSTEDACTION=<integer> TESTONBORROW=<boolean> TESTONRETURN=<boolean> TESTWHILEIDLE=<boolean> [ TIMEBETWEENEVICTION=<integer> NUMTESTPEREVICTION=<integer> MINEVIDECTABLETIME=<integer> [ POOLPREPAREDSTATEMENTS=<boolean> MAXSLEEPINGPS=<integer> INITIALCAPACITYPS=<integer> ] ] ] [ SOURCECONFIGURATION ( [ <source configuration property> [, <source configuration property> ]* ] ) ] <source configuration property> ::= DELEGATEALLOPERATORS = true | false | DEFAULT | DELEGATEARRAYLITERAL = true | false | DEFAULT | DELEGATECOMPOUNDFIELDPROJECTION = true | false | DEFAULT | DELEGATEGROUPBY = true | false | DEFAULT | DELEGATEHAVING = true | false | DEFAULT | DELEGATEINNERJOIN = true | false | DEFAULT | DELEGATEJOIN = true | false | DEFAULT | DELEGATELEFTFUNCTION = true | false | DEFAULT



MAXACTIVE=<integer> EXHAUSTEDACTION=<integer> TESTONBORROW=<boolean> TESTONRETURN=<boolean> TESTWHILEIDLE=<boolean> [ TIMEBETWEENEVICTION=<integer> NUMTESTPEREVICTION=<integer> MINEVIDECTABLETIME=<integer> [ POOLPREPAREDSTATEMENTS=<boolean> MAXSLEEPINGPS=<integer> INITIALCAPACITYPS=<integer> ] ] ] [ SOURCECONFIGURATION ( [ <source configuration property> [, <source configuration property> ]* ] ) ] <source configuration property> ::= (see CREATE DATASOURCE JDBC for details)

Figura 53 Sintaxis de la sentencia de modificación de un datasource JDBC

17.3.2 DataSources ODBC

Virtual DataPort permite definir bases de datos accesibles vía ODBC como fuentes del sistema. En la Figura 54 se muestra la sintaxis de la sentencia VQL de creación de un origen de datos ODBC. Para mayor información respecto a los diferentes parámetros que es necesario establecer para definir la conexión y para definir el pool de conexiones contra la fuente de datos, ver creación de datasources JDBC. La sentencia de creación del origen de datos permite especificar el modificador OR REPLACE. En ese caso, si ya existe un origen de datos con el mismo nombre, su definición será sustituida por la nueva. También se permite especificar diferentes parámetros de configuración de la fuente de datos (SOURCECONFIGURATION), que Virtual DataPort tendrá en cuenta a la hora de ejecutar sentencias sobre ella. Ver sección 17.3.6 para más detalle. En el caso de datasources ODBC puede no especificarse la clase driver a utilizar para la conexión contra el gestor. Para ello debe especificarse el atributo DSN en lugar del DATABASEURI junto con el DRIVERCLASSNAME. Cuando se especifica el atributo DSN, el driver utilizado será el driver puente JDBC-ODBC. NOTA: En el caso de tipos de fuentes ODBC, el sistema gestor debe encontrarse en la máquina local al servidor Virtual DataPort o en su defecto debe instalarse un gestor ODBC en el que registrar el driver ODBC del servidor de bases de datos remota. En cualquier caso, la conexión entre VDP y el gestor de ODBC o de Base de Datos ODBC será local. CREATE [OR REPLACE] DATASOURCE ODBC <name:identifier> DSN=<literal> | DATABASEURI=<literal>



[, <operator:identifier> ]* ] )

Figura 54 r Sintaxis de la sentencia de creación de un datasou ce ODBC

De forma análoga a los datasources JDBC, existe una sentencia de modificación de datasources ODBC (ALTER DATASOURCE ODBC), con la misma sintaxis que la sentencia de creación. ALTER DATASOURCE ODBC <name:identifier> DSN=<literal> | DATABASEURI=<literal> DRIVERCLASSNAME=<literal> USERNAME=<literal> USERPASSWORD=<literal> [ PROPERTIES=<literal> ] [ CLASSPATH=<literal> ] [ DATABASENAME=<literal> DATABASEVERSION=<literal> ] [ INITIALSIZE=<integer> MAXACTIVE=<integer> VALIDATIONQUERY=<literal> ] [ SOURCECONFIGURATION ( [ <source configuration property> [, <source configuration property> ]* ] ) ]

<source configuration property> ::= (see CREATE DATASOURCE ODBC for details)

Figura 55 Sintaxis de la sentencia de modificación de un datasource ODBC

17.3.3 DataSources para Servicios Web

Para configurar como origen de datos un servicio web es necesario especificar el URI al fichero WSDL que define el Servicio Web. En la Figura 56 se muestra la sintaxis de creación de un datasource para un servicio Web. El modificador OR REPLACE permite que, si ya existe un origen de datos con el mismo nombre, su definición sea reemplazada por la nueva. CREATE [OR REPLACE] DATASOURCE WS <name:identifier> WSDLURI <literal>

Figura 56 Sintaxis de la sentencia de creación de un datasource WS.

La sentencia de modificación de un datasource de este tipo es similar. ALTER DATASOURCE WS <name:identifier> WSDLURI = <literal>

Figura 57 Sintaxis de la sentencia de modificación de un datasource WS.



Un fichero WSDL permite definir uno o varios servicios web, y cada servicio web puede disponer de varios puertos con una o varias operaciones. Un origen de datos para servicios web, permitirá crear wrappers modelando cualquiera de las operaciones que define.

17.3.4 DataSources XML

Virtual DataPort permite definir ficheros XML como orígenes de datos para extraer información. Para definir un origen de datos XML es necesario especificar la ruta de acceso al documento XML y, opcionalmente, la ruta de acceso al fichero conteniendo el esquema del mismo, tal y como se explica a continuación:

- SCHEMA o DTD (opcional): Ruta al fichero que contiene la metainformación del fichero XML origen de datos. Puede ser un XML-Schema o una DTD. Si no se especifica, Virtual DataPort tratará de inferir un esquema adecuado analizando la estructura del documento XML indicado en el siguiente parámetro.

- ROUTE: Especificación de la ruta de acceso al fichero XML que representa el origen de datos. Puede incluir variables de interpolación para parametrizar la ruta de acceso en función de las condiciones de la consulta efectuada sobre el datasource (ver sección 18.4).

La especificación de rutas en DataPort fue descrita en la sección 17.2. La sintaxis de creación se puede ver en la Figura 58: CREATE [OR REPLACE] DATASOURCE XML <name:identifier> [ SCHEMA | DTD <route>] ROUTE <route> <route> ::= LOCAL <connection class name:literal> <uri:literal> | HTTP <connection class name:literal> GET | POST <uri:literal> | FTP <connection class name:literal> <uri:literal> <login:literal> <password:literal>

Figura 58 t Sintaxis de la sentencia de creación de un da asource XML

El modificador OR REPLACE permite que, si ya existe un origen de datos con el mismo nombre, su definición sea reemplazada por la nueva. A continuación se muestra la sintaxis de la sentencia de modificación de un datasource XML. ALTER DATASOURCE XML <name:identifier> [ SCHEMA | DTD <route>] ROUTE <route> <route> ::= LOCAL <connection class name:literal> <uri:literal> | HTTP <connection class name:literal> GET | POST <uri:literal> | FTP <connection class name:literal> <uri:literal> <login:literal> <password:literal>

Figura 59 Sintaxis de la sentencia de modificación de un datasource XML

17.3.5 DataSources DF

Este tipo de origen de datos permite que Denodo Virtual DataPort pueda acceder a los datos contenidos en ficheros planos en formato CSV (Comma Separated Values) o similar. Para definir un origen de datos de fichero delimitado es necesario especificar los siguientes elementos:



- ROUTE: La ruta al fichero de texto de tipo delimitado del que extraer la información. Puede incluir variables de interpolación para parametrizar la ruta de acceso en función de las condiciones de la consulta efectuada sobre el datasource (ver sección 18.4).

- COLUMNDELIMITER: Cadena de caracteres utilizada como separador de elementos en el fichero delimitado.

- ENDOFLINEDELIMITER: Cadena de caracteres utilizada como separador de tuplas de datos en el fichero delimitado (por defecto se utilizará el retorno de carro, \n).

- BEGINDELIMITER: Expresión regular (en formato JAVA) que identifica el lugar del fichero delimitado dónde se comenzará a buscar tuplas (o cabeceras si la opción “header” ha sido seleccionada). Si no se especifica se asume como valor el comienzo del fichero. Si se añade el modificador ISDATA entonces el texto que encaje con la expresión regular se considerará como parte del espacio de búsqueda.

- ENDDELIMITER: 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. Si se añade el modificador ISDATA entonces el texto que encaje con la expresión regular de fin se considerará como parte del espacio de búsqueda de tuplas.

- HEADER: Permite especificar si la primera tupla de datos del fichero debe utilizarse como cabecera, es decir, como metainformación que proporciona el nombre de los diferentes campos que componen una tupla del fichero delimitado.

El modificador OR REPLACE permite que, si ya existe un origen de datos con el mismo nombre, su definición sea reemplazada por la nueva. CREATE [OR REPLACE] DATASOURCE DF <name:identifier> ROUTE <route> COLUMNDELIMITER = <literal> [ ENDOFLINEDELIMITER = <literal> ] [ BEGINDELIMITER = <literal> [ISDATA] ] [ ENDDELIMITER = <literal> [ISDATA] ] [ HEADER = <boolean> ]

<route> ::= LOCAL <connection class name:literal> <uri:literal> | HTTP <connection class name:literal> GET | POST <uri:literal> | FTP <connection class name:literal> <login:literal>

<password:literal> <uri:literal>

Figura 60 Sintaxis de la sentencia de creación de un datasource DF

La Figura 61 muestra la sintaxis de la sentencia de modificación de un datasource de ficheros delimitados. ALTER DATASOURCE DF <name:identifier> ROUTE <route> COLUMNDELIMITER = <literal> [ ENDOFLINEDELIMITER = <literal> ] [ BEGINDELIMITER = <literal> [ISDATA] ] [ ENDDELIMITER = <literal> [ISDATA] ] [ HEADER = <boolean> ] <route> ::= LOCAL <connection class name:literal> <uri:literal> | HTTP <connection class name:literal> GET | POST <uri:literal> | FTP <connection class name:literal> <login:literal> <password:literal> <uri:literal>



Figura 61 Sintaxis de la sentencia de modificación de un datasource DF

La especificación de rutas en DataPort fue descrita en la sección 17.2.

17.3.6 DataSources Denodo Aracne

Virtual DataPort permite importar un servidor de búsqueda de Denodo Aracne[16] como fuente de datos. Es necesario específicar los siguientes parámetros:

- name: Nombre con el que se denominará a la fuente de datos dentro de Virtual DataPort. - ARNURI. URI de acceso al servidor de búsqueda de Aracne que se desea importar. El formato de URI es

host:port, donde host es el nombre de la máquina en la que está accesible el buscador y port es el puerto en el que se ejecuta. En la instalación por defecto de Aracne, este puerto es el 4000.

La sintaxis de creación se puede ver en la Figura 62: CREATE [ OR REPLACE ] DATASOURCE ARN <name:identifier> ARNURI = <literal>

Figura 62 Sintaxis de la sentencia de creación de un datasource Aracne

El modificador OR REPLACE permite que, si ya existe un origen de datos con el mismo nombre, su definición sea reemplazada por la nueva. A continuación se muestra la sintaxis de la sentencia de modificación de un datasource Aracne. ALTER DATASOURCE ARN <name:identifier> ARNURI = <literal>

Figura 63 rc Sintaxis de la sentencia de modificación de un datasou e Aracne

17.3.7 DataSources Google Mini

Virtual DataPort permite importar un servidor de búsqueda de Google Mini [17] como fuente de datos. Es necesario específicar los siguientes parámetros:

- name: Nombre con el que se denominará a la fuente de datos dentro de Virtual DataPort. - GSURI. URI de acceso al servidor de búsqueda de Google Mini que se desea importar. El formato de URI

es host:port, donde host es el nombre de la máquina en la que está accesible el buscador y port es el puerto en el que se ejecuta.

La sintaxis de creación se puede ver en la Figura 64: CREATE [ OR REPLACE ] DATASOURCE GS <name:identifier> GSURI = <literal>

Figura 64 Sintaxis de la sentencia de creación de un datasource Google Mini

El modificador OR REPLACE permite que, si ya existe un origen de datos con el mismo nombre, su definición sea reemplazada por la nueva. A continuación se muestra la sintaxis de la sentencia de modificación de un datasource Google Mini.



ALTER DATASOURCE GS <name:identifier> GSURI = <literal>

Figura 65 Sintaxis de la sentencia de modificación de un datasource Google Mini

17.3.8 DataSources LDAP

Virtual DataPort permite importar un servidor LDAP como fuente de datos. Los servidores LDAP importados pueden utilizarse para que los usuarios de DataPort se autentiquen contra ellos (ver sección 12.3.3). Para añadir un nuevo datasource LDAP es necesario especificar los siguientes parámetros:

- name: Nombre con el que se denominará a la fuente de datos dentro de Virtual DataPort. - URI. URI de acceso al servidor LDAP que se desea importar. El formato de URI es

ldap://host:port, donde host es el nombre de la máquina en la que está accesible el servidor y port es el puerto en el que se ejecuta.

La sintaxis de creación se puede ver en la Figura 66: CREATE [ OR REPLACE ] DATASOURCE LDAP <name:identifier> URI=<serverURI:literal>

Figura 66 Sintaxis de la sentencia de creación de un datasource LDAP

El modificador OR REPLACE permite que, si ya existe un origen de datos con el mismo nombre, su definición sea reemplazada por la nueva. A continuación se muestra la sintaxis de la sentencia de modificación de un datasource Aracne. ALTER DATASOURCE LDAP <name:identifier> URI=<serverURI:literal>

Figura 67 Sintaxis de la sentencia de modificación de un datasource LDAP

17.3.9 DataSources Custom

Virtual DataPort permite crear wrappers ad-hoc para fuentes de datos para las que no exista un conector específico proporcionado por DataPort. Para ello es necesario crear dos clases JAVA que implementen el comportamiento deseado (ver sección 17.4.11). Una vez creada dicha clase, es posible importar la fuente de datos en DataPort mediante un datasource CUSTOM. Es necesario específicar los siguientes parámetros:

- name:Nombre con el que se denominará a la fuente de datos dentro de Virtual DataPort. - CLASSNAME. Nombre de la clase que implementa el wrapper específico para la fuente. Debe extender

com.denodo.vdb.catalog.wrapper.my.MetaMyWrapperImpl. V er sección 17.4.9. - CLASSPATH. (Opcional) Classpath adicional requerido para la ejecución del wrapper.

La sintaxis de creación se puede ver en la Figura 68: CREATE [ OR REPLACE ] DATASOURCE CUSTOM <name:identifier> CLASSNAME=<className:literal> [ CLASSPATH=<classPath:literal> ]



Figura 68 Sintaxis de la sentencia de creación de un datasource Custom

El modificador OR REPLACE permite que, si ya existe un origen de datos con el mismo nombre, su definición sea reemplazada por la nueva. A continuación se muestra la sintaxis de la sentencia de modificación de un datasource Custom. ALTER DATASOURCE CUSTOM <name:identifier> CLASSNAME=<className:literal> [ CLASSPATH=<classPath:literal> ]

Figura 69 r

j

Sintaxis de la sentencia de modificación de un datasou ce Custom

17.3.10 Propiedades de Configuración de Fuentes de Datos

Virtual DataPort mantiene propiedades para cada una de las fuentes de datos y wrappers, 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 wrapper y, por ende, sus posibilidades de combinación y ejecución. Las propiedades de cada fuente de datos pueden configurarse añadiendo pares parámetro-valor a la sentencia de creación del DataSource, o gráficamente mediante la herramienta de administración (ver Guía del Administrador deVirtual DataPort [3]). Las propiedades configurables son las siguientes:

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

• Delegate Array Literal (DELEGATEARRAYLITERAL, 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 Pro ection (DELEGATECOMPOUNDFIELDPROJECTION, 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 (DELEGATEGROUPBY, 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 (DELEGATEHAVING, 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 (DELEGATEINNERJOIN, 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 (DELEGATEJOIN, 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 (DELEGATELEFTFUNCTION, 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 (DELEGATELEFTLITERAL, 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 (DELEGATENATURALOUTERJOIN, 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 (DELEGATENOTCONDITION, 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 (DELEGATEORCONDITION, 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 (DELEGATEORDERBY, 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 (DELEGATEPROJECTION, DS: JDBC, ODBC). Indica si la fuente permite la delegación de proyecciones. Por defecto, el valor es “true” para fuentes JDBC y ODBC.

• Delegate Register Literal (DELEGATEREGISTERLITERAL, DS: JDBC, ODBC). Indica si la fuente permite la utilización de literales con tipo de dato registro. Por defecto, el valor es ”false” para fuentes JDBC y ODBC.

• Delegate Right Field (DELEGATERIGHTFIELD, DS: JDBC, ODBC). Indica si la fuente permite la utilización de campos en la parte derecha de las condiciones. Por defecto, el valor es “true” para fuentes JDBC y ODBC.

• Delegate Right Function (DELEGATERIGHTFUNCTION, 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 (DELEGATERIGHTLITERAL, 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 (DELEGATESELECTION, DS: JDBC, ODBC). Indica si la fuente permite la delegación de condiciones. Por defecto, el valor es “true” para fuentes JDBC y ODBC.

• Delegate UNION (DELEGATEUNION, 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.



t

• Supports Modifier in Aggregate Function (SUPPORTSAGGREGATEFUNCTIONSOPTIONS, DS: JDBC, ODBC). Indica si la fuente soporta modificadores DISTINCT/ALL en las funciones de agregación. Por defecto el valor es “true” para fuentes JDBC y ODBC.

• Supports Branch Outer Join (SUPPORTSBRANCHOUTERJOIN, DS: JDBC, ODBC). Indica si la fuente acepta los modificadores (left | right) outer sobre la cláusula join. Por defecto, el valor es “false” para fuentes JDBC y ODBC.

• Supports Eq Outer Join (SUPPORTSEQOUTERJOINOPERATOR, DS: JDBC, ODBC). Indica si la fuente soporta el operador Equality Outer Join. Por defecto, el valor es “false” para fuentes JDBC y ODBC.

• Supports Explici Cross Join (SUPPORTSEXPLICITCROSSJOIN, DS: JDBC, ODBC). Indica si la fuente soporta el operador Explicit Cross Join. Por defecto, el valor es “false” para fuentes JDBC y ODBC.

• Supports Full Eq Outer Join (SUPPORTSFULLEQOUTERJOIN, DS: JDBC, ODBC). Indica si la fuente soporta el operador Full Equality Outer Join. Por defecto, el valor es “false” para fuentes JDBC y ODBC.

• Supports Full NotEq Outer Join (SUPPORTSFULLNOTEQOUTERJOIN, DS: JDBC, ODBC). Indica si la fuente soporta el operador Full Not Equality Outer Join. Por defecto, el valor es “false” para fuentes JDBC y ODBC.

• Supports Fusing in using AND Natural Join (SUPPORTSFUSINGINUSINGANDNATURALJOIN, 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 (SUPPORTSJOINONCONDITION, DS: JDBC, ODBC). Indica si la fuente soporta la cláusula Join On. Por defecto, el valor es “false” para fuentes JDBC y ODBC.

• Supports Natural Join (SUPPORTSNATURALJOIN, DS: JDBC, ODBC). Indica si la fuente soporta la cláusula Natural Join. Por defecto, el valor es “false” para fuentes JDBC y ODBC.

• Supports Using Join (SUPPORTSUSINGJOIN, DS: JDBC, ODBC). Indica si la fuente soporta la cláusula Using Join. Por defecto, el valor es “false” para fuentes JDBC y ODBC.

• Delegate Aggregate Functions List (DELEGATEAGGREGATEFUNCTIONS, 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 (DELEGATESCALARFUNCTIONS, DS: JDBC, ODBC). Indica qué funciones escalares son delegables. En las fuentes JDBC y ODBC, la lista está compuesta por las funciones ABS, CEIL, COALESCE, CONCAT, DIV, FLOOR, GETDAY, GETHOUR, GETMINUTE, GETSECOND, GETMONTH, GETYEAR, LEN, LOG, LOWER, MOD, MULT, NOW, POWER, REPLACE, ROUND, SQRT, SUBTRACT, SUM, TEXTCONSTANT, TRIM y UPPER.



• Delegate Operators List (DELEGATEOPERATORSLIST, 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, is null, is not null, is true e is false.

• Operator Properties. Permite especificar propiedades sobre el soporte proporcionado por la fuente de datos para un operador específico. Para cada operador, se especifica su nombre (atributo operator_name) y su lista de propiedades. En la actualidad, estas propiedades existen solamente para el operador contains (ver sección 17.3.10.1).

Ejemplo: Supóngase que la creación de un DataSource procedente de una fuente relacional MySQL de una versión muy antigua no admite la cláusula USING en joins. Por defecto, VDP tiene este parámetro con un valor “true”, por lo que es necesario cambiarlo. Para ello, es necesario modificar el valor en la sentencia de creación de la siguiente manera: CREATE DATASOURCE JDBC OldMySQL DRIVERCLASSNAME = 'com.mysql.jdbc.Driver' DATABASEURI = 'jdbc:mysql://localhost/vdp_demo' USERNAME = 'user' USERPASSWORD = 'userpwd' #Configuration parameters … SOURCECONFIGURATION ( SUPPORTSUSINGJOIN = false );

Figura 70 Ejemplo de modificación de configuración de un datasource.

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.

17.3.10.1 Propiedades de Configuración del Operador CONTAINS

El operador CONTAINS permite ejecutar búsquedas booleanas complejas por palabra clave sobre atributos de tipo text procedentes de un índice de información no estructurada externo (e.g. datasources tipo Aracne y/o Google Mini). La sintaxis del lenguaje de búsqueda sobre información no estructurada se describe en la sección 19.1. Sin embargo, las opciones de búsqueda disponible dependen de las capacidades proporcionadas nativamente por la fuente de datos. La sección 19.2 detalla con exactitud las capacidades de búsqueda soportadas para fuentes Google Mini y para fuentes Aracne. Los wrappers de tipo Custom que permitan el acceso a otras fuentes de datos pueden especificar qué capacidades del lenguaje de búsqueda para contains soportan a través de la propiedad operator properties de las Propiedades de Configuración. Esta sección describe dichas propiedades

• Supports And. Toma el valor true si se soportan las búsquedas con el operador lógico AND y el valor false en caso contrario.

• Supports OR. Toma el valor true si se soportan las búsquedas con el operador lógico OR y el valor false en caso contrario.



v

• Supports Not. Toma el valor true si se soportan las búsquedas con el operador lógico NOT y el valor false en caso contrario.

• Supports Exact Search. Toma el valor true si se soportan las búsquedas por frase exacta y el valor false en caso contrario.

• Supports One Wildcards First Position. Toma el valor true si se soporta el comodín que encaja con un solo carácter (i.e. el comodín ‘?’) en la primera posición de un término.

• Supports One Wildcards Rest Position. Toma el valor true si se soporta el comodín que encaja con un solo carácter (i.e. el comodín ‘?’) en el resto de posiciones de un término excepto la primera.

• Supports Multi Wildcards First Position. Toma el valor true si se soportan los comodines que encajan con múltiples caracteres (i.e. el comodín ‘*’) en la primera posición de un término.

• Supports Multi Wildcards Rest Position. Toma el valor true si se soportan los comodines que encajan con múltiples caracteres (i.e. el comodín ‘*’) en el resto de posiciones de un término, excepto la primera.

• Supports Fuzzy Terms Without Minimum Relevance. Toma el valor true si se soportan búsquedas difusas sin especificar una similitud mínima entre los términos de búsqueda y las concordancias encontradas.

• Supports Fuzzy Terms With Minimum Relevance. Toma el valor true si se soportan búsquedas difusas especificando una similitud mínima entre los términos de búsqueda y las concordancias encontradas.

• Supports Proximity Terms Without Maximum Distance. Toma el valor true si se soportan búsquedas por proximidad sin especificar una distancia máxima entre los términos de la frase de búsqueda.

• Supports Proximity Terms With Maximum Distance.. Toma el valor true si se soportan búsquedas por proximidad especificando una distancia máxima entre los términos de la frase de búsqueda.

• Supports Boosting Terms Without Boosting Factor. Toma el valor true si se soportan la especificación de aumento de la relevancia de un término sin especificar un factor de aumento concreto.

• Supports Boosting Terms With Boosting Factor. Toma el valor true si se soportan la especificación de aumento de la relevancia de un término especificando un factor de aumento concreto.

• Supports Inclusi e Range Search. Toma el valor true si se soportan búsquedas por rango (inclusivas).

• Supports Exclusive Range Search. Toma el valor true si se soportan búsquedas por rango (exclusivas).

• Supports Field Grouping. Toma el valor true si se soporta la combinación de operadores lógicos AND y OR haciendo uso de paréntesis. Por ejemplo:



title contains '(term1 AND term2) OR (term3) '

• Supports Grouping. Toma el valor true si se soporta la combinación de operadores lógicos AND y OR que vayan en distintas condiciones de consulta. Por ejemplo:

title contains 'term1' AND (content contains 'term2' OR summary contains 'term3')

17.4 CREACIÓN DE WRAPPERS

Para cada tipo de wrapper soportado por Virtual DataPort, existe una sentencia de creación de wrappers. Los siguientes subapartados describen en mayor detalle el proceso de creación manual de cada tipo de wrapper. NOTA: Se recomienda fuertemente que el proceso de creación de wrappers y datasources se realice de forma gráfica mediante la herramienta de administración de DataPort (ver [3]). Previamente la sección 17.4.1 introduce los conceptos de contexto de ejecución y cadenas de interpolación, que serán utilizados en la creación de algunos tipos de wrappers, mientras que la sección 17.4.2 proporciona información general acerca del esquema de los resultados devueltos por un wrapper.

17.4.1 Contexto de Ejecución y Cadenas de Interpolación

Como ya se ha comentado en secciones anteriores, la misión del wrapper de una fuente es ejecutar consultas y/o modificaciones sobre la misma de forma transparente para las capas superiores del servidor DataPort. Cuando DataPort solicita a un wrapper que ejecute una consulta utiliza dos maneras diferentes para proporcionarle la información sobre las condiciones consulta que el wrapper debe ejecutar sobre la fuente:

• Como una lista estructurada de condiciones de consulta. Esta es la forma utilizada por la mayor parte de tipos de wrappers.

• Como un conjunto de variables de interpolación incluidas en un contexto de ejecución. Esta forma de acceso es utilizada por los wrappers de tipo ITPilot que utilicen versiones de Denodo ITPilot anteriores a la 4.0 (ver sección 17.4.5.2) y por los wrappers JDBC que utilizan una consulta SQL patrón (ver sección 17.4.3.2). Los detalles sobre el uso de cadenas de interpolación pueden consultarse en la sección 18.4.

17.4.2 Metainformacion de un wrapper

De forma opcional en la mayoría de los wrappers, es posible especificar metainformación del esquema de salida que proporcionan (OUTPUTSCHEMA), esto es, los campos que van a representar la información extraída de la fuente. Estos campos pueden ser de tres tipos:

• SIMPLE: campos univaluados o multivaluados de valores pertenecientes a tipos de datos básicos, como cadenas de texto, enteros, etc. De forma opcional se puede indicar si son campos de consulta (obligatorios u opcionales). Un wrapper esperará recibir condiciones sobre campos especificados como obligatorios para poder ejecutarse. También especifican los tipos de datos Java asociados a los elementos procedentes del origen de datos, en base a las tablas de conversión especificadas en la sección 17.1.1.

• REGISTER: formado por uno o varios campos, tanto simples como compuestos.



• ARRAY: listas formadas por campos de tipo registro.

Esta información posibilita la generación automática de relaciones base a partir de wrappers. Adicionalmente, para cada campo del esquema de salida pueden indicarse una serie de restricciones:

- Si el campo puede tomar valores nulos (NULL) o no puede tomarlos (NOT NULL). Por defecto, se asume el valor NULL.

- Si los resultados pueden ser ordenados por el campo (SORTABLE) o no (NOT SORTABLE).También es posible especificar que los resultados pueden ser ordenados por el campo pero sólo en orden ascendente (SORTABLE ASC) o descendente (SORTABLE DESC). Por defecto se asume el valor SORTABLE.

- Si el campo puede ser actualizado en una sentencia UPDATE (UPDATEABLE) o no puede (NOT UPDATEABLE). Por defecto se asume el valor UPDATEABLE.

17.4.3 Wrapper JDBC

Un wrapper JDBC, extrae información desde una Base de Datos remota vía JDBC. La sintaxis para la creación de un wrapper de este tipo, se muestra en la Figura 71. CREATE [ OR REPLACE ] WRAPPER JDBC <name:identifier> DATASOURCENAME=<name:identifier> RELATIONNAME=<name:literal> | SQLSENTENCE=<literal> [ OUTPUTSCHEMA ( <field> [, <field>]* ) ] [ SOURCECONFIGURATION ( [ <source configuration property> [, <source configuration property> ]* ] ) ] <field> ::= <name:identifier> [ = <mapping:literal> ] : <type:literal> [ ( OBL | OPT ) ] [ <inline constraints> ]* | <name:identifier> [ = <mapping:literal> ] : ARRAY OF (<register field> ) [ <inline constraints> ]* | <name:register field> <register field> ::= <name:identifier> [ = <mapping:literal> ] : REGISTER OF ( <field> [, <field> ]* ) [ <inline constraints> ]* <inline constraint> ::= [ NOT ] NULL | [ NOT ] UPDATEABLE | SORTABLE [ ASC | DESC ] | NOT SORTABLE | EXTERN <source configuration property> ::= ALLOWDELETE = true | false | DEFAULT | ALLOWINSERT = true | false | DEFAULT | ALLOWUPDATE = true | false | DEFAULT | DATAINORDERFIELDSLIST = ( <name:identifier> ASC | DESC [, <name:identifier> ASC | DESC ]* ) | DEFAULT | SUPPORTSDISTRIBUTEDTRANSACTIONS = true | false | DEFAULT

Figura 71 Sintaxis de creación de un wrapper JDBC

ALTER WRAPPER JDBC <name:identifier> [ DATASOURCENAME=<name:identifier>] [ RELATIONNAME=<name:identifier> | SQLSENTENCE=<literal> ] [ OUTPUTSCHEMA ( <field> [, <field>]* ) ] [ SOURCECONFIGURATION ( [ <source configuration property>



[, <source configuration property> ]* ] ) ] <field> ::= (see CREATE WRAPPER JDBC for details) <source configuration property> ::= (see CREATE WRAPPER JDBC for details)

Figura 72 Sintaxis de modificación de un wrapper JDBC

Para especificar un wrapper de tipo JDBC es preciso indicar el nombre del datasource JDBC a utilizar (DATASOURCENAME) e información relativa a los datos de la base de datos especificada por el datasource a los que accederá el wrapper. Para indicar la información a la que el wrapper accederá se pueden utilizar dos mecanismos:

- Indicar el nombre de una tabla en la base de datos (RELATIONNAME). - Especificar una sentencia SQL (SQLSENTENCE). La sentencia SQL puede ser una cadena de

interpolación (ver apartado 18.4). Otra consideración importante es que los resultados devueltos por la consulta efectuada deben ser compatibles con el esquema de la relación base a la que dicho wrapper está asociado en el servidor. Más concretamente, los nombres de los atributos obtenidos como resultado de la consulta, deben coincidir con los de la relación base, y además sus valores deben ser compatibles con sus tipos de dato en la relación base. Para dar mayor flexibilidad e independencia entre las relaciones base y las fuentes de información, de forma opcional el wrapper JDBC permite definir el esquema de salida de la información que propocionará (ver apartado 17.4.2). Para cada elemento de tipo simple es necesario especificar su tipo. Además, es posible indicar una asociación entre el nombre del campo devuelto por el wrapper y el nombre del campo en la base de datos (especificado en el mapping). La sentencia de creación del wrapper admite el modificador OR REPLACE. En caso de ser especificado, si ya existiese un wrapper con el mismo nombre, su definición sería reemplazada por la nueva. Por último, también se permite especificar ciertas propiedades del wrapper (SOURCECONFIGURATION) que DataPort tendrá en cuenta para determinar qué operaciones pueden realizarse sobre el mismo. En la declaración de la sentencia correspondiente se indican las propiedades aplicables (Figura 71), y son explicadas en la sección 17.4.12.

17.4.3.1 Especificación de una tabla en la base de datos remota

La primera alternativa para especificar los datos a obtener de la base de datos remota es indicar el nombre de la tabla o vista en la base de datos de la que extraer los datos. En tiempo de ejecución, el wrapper recibirá una lista de condiciones y una lista con los nombres de los campos de salida que se le solicitan al wrapper. En base a estos elementos, el wrapper construirá automáticamente una sentencia SQL válida para ejecutar en el gestor de base de datos remoto.

17.4.3.2 Utilización de una sentencia SQL patrón

El otro mecanismo para modelar el proceso de selección de información en un wrapper JDBC se basa en definir una sentencia SQL con la consulta a realizar sobre la base de datos. El uso de este mecanismo puede ser útil, por ejemplo, para utilizar como relación base el resultado de la ejecución de una consulta SQL ad-hoc o, incluso, de un procedimiento almacenado en la base de datos remota. La sentencia SQL especificada es una cadena de interpolación que puede ser parametrizada con variables recibidas del contexto de ejecución (ver en la sección 18.4 los detalles sobre las mismas).



17.4.4 Wrapper ODBC

Un wrapper ODBC permite la adición de orígenes de datos que cumplen el estándar de interoperabilidad de datos ODBC, en el sistema Virtual DataPort. La Figura 73 muestra la sintaxis de creación de un wrapper ODBC, que sigue la misma estructura que la definida para un wrapper JDBC. Para crear un wrapper de este tipo, es necesario especificar la cadena de conexión al origen de datos (datasource ODBC previamente definido), la relación de la que extrae datos o la consulta SQL patrón, y el esquema de salida que proporciona el wrapper, con su estructura de tipos. Para más información, ver apartado 17.4.3. CREATE [ OR REPLACE ] WRAPPER ODBC <name:identifier> DATASOURCENAME=<name:identifier> RELATIONNAME=<name:literal> | SQLSENTENCE=<literal> [ OUTPUTSCHEMA ( <field> [, <field>]* ) ] [ SOURCECONFIGURATION ( [ <source configuration property> [, <source configuration property> ]* ] ) ] <field> ::= <name:identifier> [ = <mapping:literal> ] : <type:literal> [ ( OBL | OPT ) ] [ <inline constraints> ]* | <name:identifier> [ = <mapping:literal> ] : ARRAY OF (<register field>) [ <inline constraints> ]* | <name:register field> <register field> ::= <name:identifier> [ = <mapping:literal> ] : REGISTER OF ( <field> [, <field> ]* ) [ <inline constraints> ]* <inline constraint> ::= [ NOT ] NULL | [ NOT ] UPDATEABLE | SORTABLE [ ASC | DESC ] | NOT SORTABLE | EXTERN <source configuration property> ::= ALLOWDELETE = true | false | DEFAULT | ALLOWINSERT = true | false | DEFAULT | ALLOWUPDATE = true | false | DEFAULT | DATAINORDERFIELDSLIST = ( <name:identifier> ASC | DESC [, <name:identifier> ASC | DESC ]* ) | DEFAULT | SUPPORTSDISTRIBUTEDTRANSACTIONS = true | false | DEFAULT

Figura 73 Sintaxis de creación de un wrapper ODBC

La sentencia de creación del wrapper también admite el modificador OR REPLACE. En caso de ser especificado, si ya existiese un wrapper con el mismo nombre, su definición sería reemplazada por la nueva. Por último, también se permite especificar ciertas propiedades del wrapper (SOURCECONFIGURATION) que DataPort tendrá en cuenta para determinar qué operaciones pueden realizarse sobre el mismo. En la declaración de la sentencia correspondiente se indican las propiedades aplicables (Figura 73), y son explicadas en la sección 17.4.12. ALTER WRAPPER ODBC <name:identifier> [ DATASOURCENAME=<name:identifier> ] [ RELATIONNAME=<name:identifier> | SQLSENTENCE=<literal> ] [ OUTPUTSCHEMA ( <field> [, <field>]* ) ] [ SOURCECONFIGURATION ( [ <source configuration property> [, <source configuration property> ]* ]) ] <field> ::= (see CREATE WRAPPER ODBC for details)



<source configuration property> ::= (see CREATE WRAPPER ODBC for details)

Figura 74 Sintaxis de modificación de un wrapper ODBC

17.4.5 Wrapper ITPilot

Los wrappers de tipo ITPilot se utilizan para incorporar en el sistema fuentes semi-estructuradas (típicamente fuentes web semi-estructuradas). Estas fuentes pueden ser accedidas a través de la web, del sistema de ficheros local o de un servicio FTP. Este tipo de wrappers requieren Denodo ITPilot [6] para su ejecución (ITPilot también permite crear gráficamente estos wrappers y mantenerlos de forma automática). Es importante destacar que el administrador DataPort no tiene que crear las sentencias VQL para importar estos wrappers manualmente. ITPilot incluye opciones para generar automáticamente el VQL necesario para estas tareas. Se recomienda fuertemente utilizar las sentencias generadas automáticamente por ITPilot. La sintaxis para la creación de un wrapper de tipo ITPilot se muestra en la Figura 75. CCREATE [ OR REPLACE ] WRAPPER ITP <name:identifier> [ MAINTENANCE TRUE | FALSE ] ([ OUTPUTSCHEMA ( <field> [, <field>]* ) ] SEQUENCE ( <sequence clause> )[ <substitution_clause> ]* | <scriptcode:literal> <xmlcontent:literal>) [ SOURCECONFIGURATION ( [ <source configuration property> [, <source configuration property> ]* ] ) ] <field> ::= <name:identifier> [<regexp>] [ ( OBL | OPT ) ] [ ( <alias:literal> [, <alias:literal> ]* ) ] [ <inline constraints> ]* | <name:identifier>:ARRAY OF ( <register field> ) [ <inline constraints> ]* | <name:register field> <register field> ::= <name:identifier>:REGISTER OF ( <field> [, <field> ]* ) [ <inline constraints> ]* <sequence clause> ::= CONNECTIONNAME=<connection class name:literal> CREATENEWINSTANCE=<boolean> ADD ROUTE <route> <route> ::= LOCAL <connection class name:literal> <specification:literal> <uri:literal> | HTTP <connection class name:literal> <specification:literal> GET | POST <uri:literal> | FTP <connection class name:literal> <specification:literal> <uri:literal> <login:literal> <pwd:literal> <substitution_clause> ::= ADD SUBSTITUTION <precondition_1> [,<precondition_i>]* ( <sequence_clause> ) <inline constraint> ::= [ NOT ] NULL | [ NOT ] UPDATEABLE | SORTABLE [ ASC | DESC ] | NOT SORTABLE



<source configuration property> ::= DATAINORDERFIELDSLIST = DEFAULT | ( <name:identifier> ASC | DESC [, <name:identifier> ASC | DESC ]* )

Figura 75 Sintaxis de creación de un wrapper de tipo ITPilot

La sintaxis de la sentencia de modificación de un wrapper ITPilot es similar a la de creación. ALTER WRAPPER ITP <name:identifier> [ MAINTENANCE TRUE | FALSE ] [[ OUTPUTSCHEMA ( <field> [, <field>]* ) ] SEQUENCE ( <sequence clause> ) [ <substitution_clause> ]*) | <scriptcode:literal> <xmlcontent:literal> ] [ SOURCECONFIGURATION ( [ <source configuration property> [, <source configuration property> ]* ] ) ] <field> ::= (see CREATE WRAPPER ITP for details) <sequence clause> ::= (see CREATE WRAPPER ITP for details) <substitution_clause> ::= (see CREATE WRAPPER ITP for details) <source configuration property> ::= (see CREATE WRAPPER ITP for details)

Figura 76 Sintaxis de modificación de un wrapper de tipo ITPilot

Existen dos maneras alternativas de crear un wrapper ITPilot según la versión de ITPilot utilizada sea anterior o posterior a la 4.0. La sección 17.4.5.1 se ocupa de los wrappers creados con ITPilot 4.0 o posterior y la sección 17.4.5.2 se ocupa de los wrappers creados con versiones anteriores. A continuación se describen las opciones comunes a ambos casos. La cláusula MAINTENANCE permite activar o desactivar el sistema de mantenimiento automático de ITPilot para el wrapper. Véase la documentación de ITPilot [6] para más detalle. La sentencia de creación del wrapper admite el modificador OR REPLACE. En caso de ser especificado, si ya existiese un wrapper con el mismo nombre, su definición sería reemplazada por la nueva. También se permite especificar ciertas propiedades del wrapper (SOURCECONFIGURATION) que DataPort tendrá en cuenta para determinar qué operaciones pueden realizarse sobre el mismo. En la declaración de la sentencia correspondiente se indican las propiedades aplicables (Figura 75), y son explicadas en la sección 17.4.12

17.4.5.1 Wrappers ITPilot con la Versión 4.0 y posteriores

A partir de la versión 4.0, los wrappers creados con Denodo ITPilot se modelan como flujos de componentes que se compilan al lenguaje Javascript. En este caso, los wrappers serán creados especificando el código Javascript generado por ITPilot para el wrapper (<scriptcode:literal> en la sintaxis) y la descripción del flujo de componentes que forman el wrapper, también generada por ITPilot (<xmlcontent:literal> en la sintaxis). La Figura 77 muestra un ejemplo (no se muestra el código Javascript completo ni la descripción completa del flujo de componentes): CREATE WRAPPER ITP AcmeWrapper MAINTENANCE FALSE "function getInit() … (rest of Javascript code)" "<?xml version='1.0' encoding='ISO-8859-1' ?> <InitComponent className='com.denodo.itp.model.components … (rest of flow description)"



Figura 77

r

Ejemplo de wrapper ITPIlot 4.0

17.4.5.2 Wrappers ITPilot con versiones anteriores de ITPilot anteriores a la 4.0

En versiones anteriores a ITPilot 4.0, la creación de un wrapper ITPilot requiere la especificación de una secuencia de acceso. Una secuencia de acceso representa a una serie de localizaciones ( utas a páginas), dónde el sistema buscará consecutivamente, y en orden, los resultados a extraer de la fuente. Las rutas de acceso a los recursos de los que se extrae la información se especifican mediante cadenas de interpolación (ver sección 18.4). Una secuencia de acceso contiene la siguiente información:

• CONNECTIONNAME: Clase Java utilizada para realizar la conexión. Una conexión se crea a partir de una cadena de caracteres compuesta por dos partes: el nombre de la conexión y los parámetros de inicialización de la misma (opcionales, pueden indicarse sin asociar ningún valor). Ambos elementos deben ir separados por comas. La clase especificada aquí actúa como clase por defecto para aquellas rutas del wrapper que no especifiquen explícitamente su clase conexión. Por defecto se utilizará la clase http.HTTPClientConnection.

Virtual DataPort incluye diversas clases conexión para los diversos tipos de rutas disponibles. En la descripción de la sintaxis de cada tipo de ruta (ver sección 17.2) se muestran las clases conexión disponibles.

• CREATENEWINSTANCE: Si es necesario crear una nueva conexión para cada petición o se deben intentar reutilizar conexiones existentes (este parámetro sólo se tiene en cuenta en las rutas que no especifiquen su propia clase conexión).

• La lista de rutas a las que es necesario acceder para obtener la información de la fuente externa. La especificación de rutas se realiza tal y como se vio en la sección 17.2, añadiendo una especificación de extracción de los datos que contiene el recurso apuntado por la ruta definida (la especificación debe estar escrita utilizando el lenguaje de extracción de datos DEXTL de ITPilot [6]). Además, los patrones de acceso pueden ser parametrizados utilizando variables del contexto y funciones de interpolación (ver sección 18.4).

Otra consideración importante a la hora de construir el wrapper, es que los resultados devueltos por la consulta efectuada deben ser compatibles con el esquema de la relación base a la que dicho wrapper está asociado en Virtual DataPort. Más concretamente, los nombres de los atributos obtenidos como resultado de la extracción de datos, deben coincidir con los de la relación base, y además sus valores deben ser compatibles con sus tipos de datos en la relación base. A la metainformación general que se puede indicar relativa al esquema de salida que proporciona el wrapper (ver apartado 17.4.2), se puede además añadir sobre los campos de tipo simple una expresión regular con la que deben encajar todos los resultados (se descartarán aquellas tuplas en las que el valor para un campo no encaje con su expresión regular asociada). En el caso de los wrappers ITPilot de versiones anteriores a ITPilot 4.0, los campos de tipo simple son todos textuales. También es posible añadir una lista de alias para cada campo del wrapper. Estos alias podrán ser utilizados por ITPilot para las labores de mantenimiento automático de los wrappers (véase [6] para más información). Adicionalmente, tanto en la sentencia de creación como de modificación de un wrapper ITPilot es posible indicar si se desea activar el mantenimiento automático para el wrapper.



17.4.5.2.1 Sustituciones

Los wrappers ITPilot utilizados con las versiones de ITPilot anteriores a la 4.0 pueden ser configurado para utilizar secuencias de acceso diferentes en función de las condiciones de la consulta que Virtual DataPort le pide resolver. Para ello, el administrador puede especificar las denominadas sustituciones. Una sustitución especifica:

• Una lista de precondiciones sobre los atributos incluidos en la consulta. Una precondición representa un requisito que deben satisfacer las condiciones de consulta.

• Una secuencia, que se ejecutará si se cumplen todas las precondiciones de la sustitución.

Si las condiciones de consulta no verifican las precondiciones de ninguna sustitución, entonces se accederá a la fuente a través de la secuencia por defecto. El formato de la lista de precondiciones consiste en una lista de cadenas, donde cada cadena representa un nombre de una variable del contexto de ejecución del wrapper. Una condición de una sustitución se verifica si la variable que referencia existe en el contexto de ejecución (ver sección 18.4). Las precondiciones se especifican con la forma <atributo>#<operador>. Por ejemplo, supóngase que se desea utilizar una determinada secuencia de acceso en el caso de que se realice una consulta sobre el wrapper que contenga una condición sobre el atributo TITLE con el operador containsor (esto es, condiciones de la forma “TITLE containsor ‘values’”): para ello, se crearía una sustitución con una precondición de la forma “TITLE#containsor”. En laFigura 78 se muestra un wrapper ITPilot con una secuencia por defecto que utiliza una ruta HTTP, con patrón de acceso ACCESSPAT1 (que debe ser acorde a alguno de los formatos soportados por ITPilot [6]) y especificación de extracción de datos DATAEXTRACTSPEC1 (que debe estar escrita en el lenguaje de extracción de datos de ITPilot, DEXTL [6]). Además, se incluye una substitución a utilizar en caso de que se consulte la fuente con el operador containsor sobre el atributo TITLE. En ese caso, se utilizaría otra secuencia consistente en una ruta HTTP con patrón de acceso ACCESSPAT2 y especificación de extracción DATAEXTRACTSPEC2. CREATE WRAPPER ITP shopview SEQUENCE ( CONNECTIONNAME='http.HTTPClientConnection,120000' CREATENEWINSTANCE=TRUE ADD ROUTE HTTP '' ‘DATAEXTRACTSPEC1’ POST 'ACCESSPAT1' ) ADD SUBSTITUTION 'TITLE#containsor' ( CONNECTIONNAME='http.HTTPClientConnection,120000' CREATENEWINSTANCE=TRUE ADD ROUTE HTTP '' 'DATAEXTRACTSPEC2' POST 'ACCESSPAT2' )

Figura 78 Ejemplo de creación de un wrapper ITPilot

17.4.6 Wrapper de Servicios Web

Virtual DataPort soporta la creación de wrappers para servicios Web. Mediante la información contenida en un fichero WSDL de especificación de un servicio web (indicado al crear el datasource de servicio web), el wrapper debe seleccionar una operación concreta a modelar como una relación base, definiendo cómo se establecen los



diferentes parámetros requeridos para la ejecución de la operación y qué datos de salida formarán parte del resultado del wrapper. En la Figura 79 se muestra la sintaxis de la sentencia VQL de creación de un wrapper de servicios web. CREATE [ OR REPLACE ] WRAPPER WS <name:identifier> DATASOURCENAME=<name:identifier> SERVICENAME=<literal> PORTNAME=<literal> OPERATIONNAME=<literal> [ INPUTMESSAGE=<literal> OUTPUTMESSAGE=<literal> ] [ OUTPUTSCHEMA ( <field> [, <field>]* )] [ SOURCECONFIGURATION ( [ <source configuration property> [, <source configuration property> ]* ] ) ] <field> ::= <name:identifier> = <mapping:literal> [ VALUE <literal> ] [ ( OBL | OPT ) ] [ <inline constraints> ]* | <name:identifier> = <mapping:literal> : ARRAY OF ( <register field> ) [ <inline constraints>]* | <name:register field> <register field> ::= <name:identifier> = <mapping:literal> : REGISTER OF ( [ <field> [, <field> ]* ] ) [ <inline constraints> ]* <inline constraint> ::= [ NOT ] NULL | [ NOT ] UPDATEABLE | SORTABLE [ ASC | DESC ] | NOT SORTABLE <source configuration property> ::= DATAINORDERFIELDSLIST = DEFAULT | ( <name:identifier> ASC | DESC [, <name:identifier> ASC | DESC ]* ) | DELEGATEOPERATORSLIST = DEFAULT | ( <operator:identifier> [, <operator:identifier> ]* )

Figura 79 Sintaxis de creación de un wrapper de servicios Web

La sintaxis de modificación de un wrapper de servicios web es similar y se muestra en la Figura 80. ALTER WRAPPER WS <name:identifier> [ DATASOURCENAME = <name:identifier> ] [ SERVICENAME = <name:literal> ] [ PORTNAME = <name:literal> ] [ OPERATIONNAME = <operation:literal> ] [ INPUTMESSAGE = <input:literal> OUTPUTMESSAGE = <output:literal> ] [ OUTPUTSCHEMA ( <field> [, <field>]* ) ] [ SOURCECONFIGURATION ( [ <source configuration property> [, <source configuration property> ]* ] ) ] <field> ::= (see CREATE WRAPPER WS for details) <source configuration property> ::= (see CREATE WRAPPER WS for details)

Figura 80 Sintaxis de modificación de un wrapper de servicios Web



Además del nombre de datasource de servicio web que identifica el fichero WSDL de definición, es necesario indicar otros parámetros que definen de forma unívoca la operación del servicio web a utilizar por el wrapper:

- SERVICENAME: Nombre del servicio web sobre el que invocar la operación. Un fichero WSDL puede contener la definición de varios servicios web.

- PORTNAME: Nombre del puerto del que seleccionar la operación concreta a modelar. - OPERATIONNAME: Nombre de la operación a modelar. Puede haber varias operaciones diferentes con

el mismo nombre, que se diferencian en los mensajes de entrada/salida que permiten. Estos se indican en los siguientes parámetros.

- INPUTMESSAGE: Nombre del mensaje que define los parámetros de entrada de la operación del método de búsqueda a modelar (opcional).

- OUTPUTMESSAGE: Nombre del mensaje que define los parámetros de salida de la operación del método de búsqueda a invocar (opcional).

Los atributos de los mensajes de la operación seleccionada y su estructura de tipos definen el esquema de salida del wrapper de servicios web. Es decir, un wrapper de servicio web posee como esquema los atributos de entrada, de salida y de entrada- salida, con los nombres definidos en el fichero WSDL. NOTA: Desde la versión 3.1 de Virtual DataPort se permite que las operaciones utilicen parámetros compuestos también en el mensaje de entrada. Estos parámetros se convertirán a tipos compuestos DataPort (ver sección 18.1) de la misma forma que los del mensaje de salida y podrán especificarse condiciones sobre ellos utilizando los constructores de valores compuestos ROW y ‘’ ‘’ (ver sección 6.3.1). A partir de la lista de condiciones recibidas, el wrapper creará los parámetros necesarios para la invocación del servicio web y obtener los resultados deseados. Como en el resto de los wrappers, es posible indicar de forma explícita el esquema de salida del wrapper (OUTPUTSCHEMA), junto con las asociaciones entre los atributos externos y los parámetros del servicio web. El atributo “name” de un campo del OUTPUTSCHEMA indica el nombre con el que el wrapper exportará el elemento. El atributo “mapping” indica el nombre utilizado por el servicio Web. Para referenciar los diferentes elementos de un servicio web en los mappings a realizar, se utiliza la siguiente notación:

- $<parameterNumber> referencia al parámetro de la posición indicada de la operación del servicio web.

- $$ referencia al parámetro de salida, devuelto por la invocación de la operación del servicio web. Ésta es la notación utilizada para los elementos de primer nivel (parámetros y salida del servicio web). Para el resto de elementos (campos de un objeto resultado o parámetro del servicio web), el mapping se obtiene del nombre real de la propiedad en el objeto correspondiente. La sentencia de creación del wrapper también admite el modificador OR REPLACE. En caso de ser especificado, si ya existiese un wrapper con el mismo nombre, su definición sería reemplazada por la nueva. Por último, también se permite especificar ciertas propiedades del wrapper (SOURCECONFIGURATION) que DataPort tendrá en cuenta para determinar qué operaciones pueden realizarse sobre el mismo. En la declaración de la sentencia correspondiente se indican las propiedades aplicables (Figura 79), y son explicadas en la sección 17.4.12.

17.4.7 Wrapper XML

Virtual DataPort soporta la creación de wrappers que tienen como origen ficheros de datos XML. En la Figura 81 se muestra la sintaxis de creación de un wrapper XML. CREATE [ OR REPLACE ] WRAPPER XML <name:identifier> DATASOURCENAME=<name:identifier> [ OUTPUTSCHEMA ( <field> [, <field>]* ) ]



[ SOURCECONFIGURATION ( [ <source configuration property> [, <source configuration property> ]* ] ) ] <field> ::= <name:identifier> [ = <mapping:literal> ] [: <type:literal>] [ ( OBL | OPT ) [ EXTERN ] ] [ ( [ <value:literal> [, <value:literal> ]* ] ) ] [ <inline constraints> ]* | <name:identifier> [ = <mapping:literal> ] : ARRAY OF (<register field>) [ <inline constraints> ]* | <name:register field> <register field> ::= <name:identifier> [ = <mapping:literal> ] : REGISTER OF ( <field> [, <field> ]* ) [ <inline constraints> ]* <inline constraint> ::= [ NOT ] NULL | [ NOT ] UPDATEABLE | SORTABLE [ ASC | DESC ] | NOT SORTABLE <source configuration property> ::= DATAINORDERFIELDSLIST = DEFAULT | ( <name:identifier> ASC | DESC [, <name:identifier> ASC | DESC ]* )

Figura 81 Sintaxis de creación de un wrapper XML

La sintaxis de modificación de un wrapper XML es similar y puede verse en la Figura 82. ALTER WRAPPER XML <name:identifier> [ DATASOURCENAME=<name:identifier> ] [ OUTPUTSCHEMA ( <field> [, <field>]* ) ] [ SOURCECONFIGURATION ( [ <source configuration property> [, <source configuration property> ]* ] ) ] <field> ::= (see CREATE WRAPPER XML for details) <source configuration property> ::= (see CREATE WRAPPER XML for details)

Figura 82 Sintaxis de modificación de un wrapper XML

Un wrapper XML se define a través de un datasource XML, que identifica un recurso XML local o remoto. El wrapper XML analiza la estructura del documento XML y devuelve como atributos las etiquetas XML de primer nivel (utilizando su nombre como nombre de atributo), encapsulando el resto de elementos en tipos compuestos. Pueden utilizarse operaciones de “aplanamiento” (ver sección 6.1.2) para transformar la relación base resultante de la forma deseada. Al igual que en el resto de wrappers, es posible especificar el esquema de salida de los datos proporcionados por el wrapper, permitiendo seleccionar sólo aquellos elementos del documento XML que interesan e incluso cambiar su nombre (en mapping se especifica el nombre en el wrapper; name almacena el nombre externo). La sentencia de creación del wrapper también admite el modificador OR REPLACE. En caso de ser especificado, si ya existiese un wrapper con el mismo nombre, su definición sería reemplazada por la nueva.



Por último, también se permite especificar ciertas propiedades del wrapper (SOURCECONFIGURATION) que DataPort tendrá en cuenta para determinar qué operaciones pueden realizarse sobre el mismo. En la declaración de la sentencia correspondiente se indican las propiedades aplicables (Figura 81), y son explicadas en la sección 17.4.12.

17.4.8 Wrapper DF

Virtual DataPort soporta la creación de wrappers de ficheros delimitados CSV y similares. Para crear un wrapper de este tipo es necesario indicar el nombre del origen de datos (cómo acceder al fichero que contiene los datos) – DATASOURCENAME -. De forma opcional como en el resto de wrappers, es posible especificar el esquema de datos devuelto por el wrapper (OUTPUTSCHEMA). La sentencia de creación del wrapper también admite el modificador OR REPLACE. En caso de ser especificado, si ya existiese un wrapper con el mismo nombre, su definición sería reemplazada por la nueva. Por último, también se permite especificar ciertas propiedades del wrapper (SOURCECONFIGURATION) que DataPort tendrá en cuenta para determinar qué operaciones pueden realizarse sobre el mismo. En la declaración de la sentencia correspondiente se indican las propiedades aplicables (Figura 83), y son explicadas en la sección 17.4.12. NOTA: En este tipo de wrappers, actualmente no se soporta el “mapping” ni la especificación de registros o arrays como elementos del outputschema. En la siguiente figura se muestra la sintaxis de creación de un wrapper de ficheros delimitados. CREATE [ OR REPLACE ] WRAPPER DF <name:identifier> DATASOURCENAME=<name:identifier> [ OUTPUTSCHEMA ( <field> [, <field>]* ) ] [ SOURCECONFIGURATION ( [ <source configuration property> [, <source configuration property> ]* ] ) ] <field> ::= <name:identifier> [ = <mapping:literal> ] [ ( OBL | OPT ) [ EXTERN ] ] [ ( [ <value:literal> [, <value:literal> ]* ) ] ] [ <inline constraints> ]* | <name:register field> <register field> ::= <name:identifier> [ = <mapping:literal> ] : REGISTER OF ( <field> [, <field> ]* ) [ <inline constraints> ]* <inline constraint> ::= [ NOT ] NULL | [ NOT ] UPDATEABLE | SORTABLE [ ASC | DESC ] | NOT SORTABLE <source configuration property> ::= DATAINORDERFIELDSLIST = DEFAULT | ( <name:identifier> ASC | DESC [, <name:identifier> ASC | DESC ]* )

Figura 83 Sintaxis de creación de un wrapper DF



La sintaxis de la sentencia de modificación de un wrapper de ficheros delimitados es similar. ALTER WRAPPER DF <name:identifier> [ DATASOURCENAME=<name:identifier> ] [ OUTPUTSCHEMA ( <field> [, <field>]* ) ] [ SOURCECONFIGURATION ( [ <source configuration property> [, <source configuration property> ]* ] ) ] <field> ::= (see CREATE WRAPPER DF for details) <source configuration property> ::= (see CREATE WRAPPER DF for details)

Figura 84 Sintaxis de modificación de un wrapper DF

17.4.9 Wrapper Denodo Aracne

Virtual DataPort soporta la creación de wrappers sobre índices de información no estructurada creados con Denodo Aracne [16]. Para crear un wrapper de este tipo es necesario indicar el nombre del origen de datos – DATASOURCENAME – y el nombre del manejador Aracne – HANDLERNAME – a partir del cuál se va a crear el wrapper. Como en el resto de wrappers, es posible especificar el esquema de datos devuelto por el wrapper (OUTPUTSCHEMA). En este caso, el esquema debe contener una serie de atributos fijos que deben estar presentes siempre que el manejador escogido de Denodo Aracne los exporte. De estos atributos fijos sólo será posible modificar su nombre. Además, el esquema puede incluir también atributos específicos que se correspondan con otros campos específicos exportados por el manejador Aracne. A continuación se describen los atributos fijos (véase [16] para más detalle): • TASK. Nombre de la tarea Aracne que obtuvo e indexó este documento. Es de tipo cadena de caracteres. • PUBDATE. Fecha de publicación del documento. Sólo aparece en el caso de que el índice contenga

documentos de tipo RSS. Es de tipo cadena de caracteres. • TITLE. Título generado por Aracne para el documento. Es de tipo cadena de caracteres. • 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. Es de tipo cadena de caracteres. • SUMMARY. Resumen generado por Aracne para el documento. Es de tipo cadena de caracteres. • URL. En el caso de documentos obtenidos a través de la web, contiene laURL 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. Es de tipo cadena de caracteres.

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

[16] para más detalle. Es de tipo cadena de caracteres. • 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. Es de tipo cadena de caracteres. • MODIFIED. Fecha de última modificación del documento en el índice. • SEARCHABLECONTENT. Campo añadido por DataPort que almacena 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. Es de tipo cadena de caracteres. • TYPE. Tipo de contenido: html, pdf, rss, etc. Es de tipo cadena de caracteres.



• 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. Es de tipo cadena de caracteres.

• 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. Es de tipo cadena de caracteres.

• PATH. En el caso de que el servidor Aracne guarde una copia local al documento, contiene la ruta al mismo. Es de tipo cadena de caracteres.

• 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. Es de tipo flotante.

• MAXDOCS. Atributo añadido por DataPort que permite restringir el número máximo de resultados devueltos por una búsqueda. Es de tipo entero.

• 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. Es de tipo cadena de caracteres.

Además, 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 incluidos en campos adicionales del esquema del wrapper DataPort. El uso de la cláusula FILTERMAINTERMS está también relacionado con esta funcionalidad. Véase la sección 17.4.9.1. La sentencia de creación del wrapper también admite el modificador OR REPLACE. En caso de ser especificado, si ya existiese un wrapper con el mismo nombre, su definición sería reemplazada por la nueva. La sintaxis de creación se muestra en la Figura 88. CREATE [ OR REPLACE ] WRAPPER ARN <name:identifier> DATASOURCENAME=<name:identifier> HANDLERNAME=<literal> [ OUTPUTSCHEMA ( <field> [, <field>]* )] [ FILTERMAINTERMLIST ( <literal> [, <literal>]* )] <field> ::= <name:identifier> = <mapping:literal> [ VALUE <literal> ] : <type:literal> [ ( OBL | OPT ) ] | <name:identifier> = <mapping:literal> : ARRAY OF ( <register field> ) [ <inline constraints>]* | <name:register field> <register field> ::= <name:identifier> = <mapping:literal> : REGISTER OF ( [ <field> [, <field> ]* ] ) <inline constraint> ::= MAINTERMS ( <name:identifier>,<num_of_mainterms_integer> [, ( <literal> [, <literal>]* ) ] )

Figura 85 Sintaxis de creación de un wrapper Denodo Aracne

En la siguiente figura se muestra un ejemplo de creación de un wrapper Aracne. Los campos del wrapper deben incluir los antes expuestos siempre que el manejador escogido de Denodo Aracne también los incluya. En esos campos, para que el wrapper funcione correctamente, la única modificación posible es posible cambiar su nombre.



En el ejemplo, el nombre del campo TITLE es cambiado por DOCNAME. En el ejemplo, también se añade un campo para contener los términos más relevantes del documento (ver sección 17.4.9.1). CREATE WRAPPER ARN aracneview3 DATASOURCENAME=aracnesearch HANDLERNAME='default' OUTPUTSCHEMA ( TASK : 'java.lang.String' (OPT), PUBDATE : 'java.lang.String' (OPT), DOCNAME='TITLE' : 'java.lang.String' (OPT), ANCHORTEXT : 'java.lang.String' (OPT), SUMMARY : 'java.lang.String' (OPT), IDENTIFIER : 'java.lang.String' (OPT), URL : 'java.lang.String' (OPT), CONTENT : 'java.lang.String' (OPT), DESCRIPTION : 'java.lang.String' (OPT), MODIFIED : 'java.lang.String' (OPT), SEARCHABLECONTENT : 'java.lang.String' (OPT) EXTERN, LEVEL : 'java.lang.String' (OPT), TYPE : 'java.lang.String' (OPT), TITLEXML : 'java.lang.String' (OPT), SUMMARYXML : 'java.lang.String' (OPT), PATH : 'java.lang.String' (OPT), SCORE : 'java.lang.Float', MAXDOCS : 'java.lang.Integer' (OPT) EXTERN, SEARCHABLECONTENT_MAIN_TERM = 'SEARCHABLECONTENT_MAIN_TERM': ARRAY OF ( SEARCHABLECONTENT_MAIN_TERM_REG: REGISTER OF ( SEARCHABLECONTENT_SCORE : 'java.lang.Integer', SEARCHABLECONTENT_TERM : 'java.lang.String' ) )MAINTERMS (SEARCHABLECONTENT ,10,( 'usualterm1' , 'usualterm2') ) );

Figura 86 Ejemplo de creación de un wrapper Denodo Aracne

La sintaxis de la sentencia de modificación del wrapper es similar y se muestra en la Figura 90. ALTER WRAPPER ARN <name:identifier> DATASOURCENAME=<name:identifier> HANDLERNAME=<literal> [ OUTPUTSCHEMA ( <field> [, <field>]* )] [ FILTERMAINTERMLIST ( <literal> [, <literal>]* )] <field> ::= <name:identifier> = <mapping:literal> [ VALUE <literal> ] : <type:literal> [ ( OBL | OPT ) ] | <name:identifier> = <mapping:literal> : ARRAY OF ( <register field> ) [ <inline constraints>]* | <name:register field> <register field> ::=



<name:identifier> = <mapping:literal> : REGISTER OF ( [ <field> [, <field> ]* ] ) <inline constraint> ::= MAINTERMS ( <name:identifier>,<num_of_mainterms_integer> [, ( <literal> [, <literal>]* ) ] )

Figura 87 Sintaxis de modificación de un wrapper Denodo Aracne

17.4.9.1 Añadiendo campos con los términos más relevantes

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 campos adicionales en el wrapper DataPort, tal y cómo se describe en esta sección. Por ejemplo, en la Figura 86 se añade un nuevo atributo llamado SEARCHABLECONTENT_MAIN_TERM para contener los términos más relevantes del campo del índice SEARCHABLECONTENT. El nuevo atributo debe ser un atributo compuesto de tipo array de registros (ver sección 18.1). Cada registro debe tener dos campos: • El término relevante. En nuestro ejemplo, toma el nombre del campo del índice añadiéndole el sufijo _TERM

(SEARCHABLECONTENT_TERM). • Su posición en la lista de más relevantes. En nuestro ejemplo, toma el nombre del campo del índice

añadiéndole el sufijo _SCORE (SEARCHABLECONTENT_SCORE). Es de tipo entero. El término más relevante tomará la posición 1.

Además se debe utilizar el modificador MAINTERMS para especificar el contenido del nuevo campo. Para ello, es posible especificar los siguientes parámetros: • Name (Obligatorio). Nombre del campo afectado. En nuestro ejemplo, SEARCHABLECONTENT. • Number of main terms (Obligatorio). Número máximo de términos relevantes que se incluirán para cada

documento. • Filter main terms words (Opcional). 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.

Además, la sintaxis de creación de wrappers Aracne incluye la cláusula FILTERMAINTERMS (ver Figura 85). Esta claúsula permite especificar 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.

17.4.10 Wrapper Google Mini

Virtual DataPort soporta la creación de wrappers sobre buscadores creados con la herramienta Google Mini[17]. Como es habitual, para crear un wrapper de este tipo es necesario indicar el nombre del origen de datos – DATASOURCENAME -. También es posible especificar los siguientes parámetros: • SITECOLLECTIONS. 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á por 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 los URLs de invocación.

• 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 [18].

• NUMKEYMATCH: 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 sólo devolverán las páginas cuya prioridad sea la especificada o superior.

Como en el resto de wrappers, es posible especificar el esquema de datos devuelto por el wrapper (OUTPUTSCHEMA). En este caso, el esquema debe constar de una serie de campos fijos y sólo será posible modificar su nombre. A continuación se describe cada campo: • TITLE. Título generado por Google Mini para el documento. Es de tipo cadena de caracteres. • SUMMARY. Resumen generado por Google Mini para el documento. Es de tipo cadena de caracteres. • URL. URL del documento. Es de tipo cadena de caracteres. • MIMETYPE. Tipo MIME del documento. Es de tipo cadena de caracteres. • RATING. Prioridad asignada manualmente por el administrador de Google Mini para el documento. Puede

tomar valores entre 0 y 5, donde 5 significa máxima prioridad. Es de tipo entero. • MAXDOCS. Campo añadido por DataPort que permite restringir el número máximo de resultados devueltos por

una búsqueda. Es de tipo entero. • METAS. Atributo compuesto de tipo array de registros (ver sección 18.1) que contiene los tags meta del

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

• CONTENT. Contenido del documento. Es el campo utilizado habitualmente para las búsquedas. Es de tipo cadena de caracteres.

• SITE. Permite restringir los documentos devueltos a aquellos que pertenezcan a un dominio determinado (e.g. ‘acme.com’). Es de tipo cadena de caracteres.

• FILETYPE. Extensión del fichero del documento. Es de tipo cadena de caracteres. La sentencia de creación del wrapper también admite el modificador OR REPLACE. En caso de ser especificado, si ya existiese un wrapper con el mismo nombre, su definición sería reemplazada por la nueva. La sintaxis de creación se muestra en la Figura 88. CREATE [ OR REPLACE ] WRAPPER GS <name:identifier> DATASOURCENAME=<name:identifier> SITECOLLECTIONS ( <literal> [, <literal>]* ) [ CLIENT=<literal> ] [ LANGUAGES ( <literal> [, <literal>]* ) ] [ NUMKEYMATCH=<integer> ] [ OUTPUTSCHEMA ( <field> [, <field>]* )] <field> ::= <name:identifier> = <mapping:literal> [ VALUE <literal> ] : <type:literal> [ ( OBL | OPT ) ] | <name:identifier> = <mapping:literal> : ARRAY OF ( <register field> )



| <name:register field> <register field> ::= <name:identifier> = <mapping:literal> : REGISTER OF ( [ <field> [, <field> ]* ] )

Figura 88 Sintaxis de creación de un wrapper Google Mini

En la siguiente figura se muestra un ejemplo de creación de un wrapper Google Mini. Los campos del wrapper deben ser los especificados. Para que la sentencia funcione correctamente, tan sólo es posible cambiar, si se desea, el nombre de los campos de salida. En el ejemplo, el nombre del campo TITLE es cambiado por DOCNAME. CREATE WRAPPER GS acme_com DATASOURCENAME=acme_com SITECOLLECTIONS ( 'Acme_com' ) OUTPUTSCHEMA ( DOCNAME='TITLE' : 'java.lang.String' (OPT), SUMMARY : 'java.lang.String', URL : 'java.lang.String' (OPT), MIMETYPE : 'java.lang.String', RATING : 'java.lang.Integer', MAXDOCS : 'java.lang.Integer' (OPT) EXTERN, METAS: ARRAY OF ( METAS: REGISTER OF ( METAKEY : 'java.lang.String', METAVALUE : 'java.lang.String' ) ), CONTENT : 'java.lang.String' (OPT) EXTERN, SITE : 'java.lang.String' (OPT) EXTERN, FILETYPE : 'java.lang.String' (OPT) EXTERN, LANGUAGE : 'java.lang.String' )

Figura 89 Ejemplo de creación de un wrapper Google Mini

La sintaxis de la sentencia de modificación del wrapper es similar y se muestra en la Figura 90. ALTER WRAPPER GS <name:identifier> DATASOURCENAME=<name:identifier> SITECOLLECTIONS ( <literal> [, <literal>]* ) [ CLIENT=<literal> ] [ LANGUAGES ( <literal> [, <literal>]* ) ] [ NUMKEYMATCH=<integer> ] [ OUTPUTSCHEMA ( <field> [, <field>]* )]LTER WRAPPER GS <name:identifier> <field> ::= <name:identifier> = <mapping:literal> [ VALUE <literal> ] : <type:literal> [ ( OBL | OPT ) ] | <name:identifier> = <mapping:literal> : ARRAY OF ( <register field> )



| <name:register field> <register field> ::= <name:identifier> = <mapping:literal> : REGISTER OF ( [ <field> [, <field> ]* ] )

Figura 90 Sintaxis de modificación de un wrapper Google Mini

17.4.11 Wrapper CUSTOM

El tipo de wrapper CUSTOM permite acceder a una fuente mediante una implementación específica. De este modo, es posible construir un wrapper ad-hoc para el acceso a una fuente externa. Los wrappers CUSTOM están asociados a un datasource CUSTOM. En el proceso de creación de este tipo de datasources (ver sección 17.3.9), es necesario especificar una clase que implementa los wrappers de este tipo. Como se explica a continuación, esta clase debe extender com.denodo.vdb.catalog.wrapper.my.MetaMyWrapperImpl. Para crear un nuevo wrapper de tipo CUSTOM, es necesario extender dos clases Java:

• La clase abstracta com.denodo.vdb.catalog.wrapper.my.MetaMyWrapperImpl. Extendiendo esta clase se definirá el esquema de salida del nuevo wrapper, así como cierta metainformación adicional.

• com.denodo.vdb.engine.wrapper.raw.my.MyAccessImpl. Se extenderá esta clase para implementar el comportamiento específico del wrapper.

Las siguientes subsecciones se ocupan, respectivamente, de cada una de ellas. Posteriormente se indica como dar de alta el nuevo wrapper CUSTOM en el servidor DataPort una vez que este ha sido implementado. 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.

17.4.11.1 Definiendo la metainformación del wrapper CUSTOM

Para definir la metainformación del nuevo wrapper CUSTOM es necesario extender la clase abstracta com.denodo.vdb.catalog.wrapper.my.MetaMyWrapperImpl. En particular, es necesario redefinir los siguientes métodos (véase la documentación Javadoc [4] y los ejemplos para más detalle):

• public abstract MyAccessImpl doCreate() throws CreateWrapperException. Este método es responsable de crear la clase wrapper que realizará la ejecución de la consulta. Dicha clase será discutida en la siguiente sección.

• public com.denodo.vdb.catalog.wrapper.metadata.MetaRegisterRaw getOutputSchema()throws LoadWrapperException. Este método debe devolver el esquema de los datos que serán obtenidos a través de las consultas efectuadas por el wrapper. Para cada uno de los atributos contenidos en las tuplas de respuesta debe indicarse:

o Su tipo de dato.

o Si el atributo es consultable en la fuente (es decir, si el wrapper es capaz de aplicar condiciones de selección sobre dicho atributo en la fuente). Si el atributo es consultable, puede ser además



obligatorio. Eso indica que el wrapper sólo será capaz de ejecutar consultas que incluyan al menos una condición de selección para dicho atributo.

• public List getWrapperParameters(). (OPCIONAL) Este método debe devolver una lista conteniendo los parámetros de configuración del wrapper. Cada parámetro se representa mediante un objeto com.denodo.vdb.catalog.wrapper.my.MetaMyWrapperParameter. Al crear un parámetro de configuración debe especificarse en el constructor su nombre y si el parámetro es obligatorio (true) u opcional (false). Si no se implementa este método, el wrapper no tendrá parámetros de configuración.

• public com.denodo.vdb.catalog.wrapper.SourceConfiguration getSourceConfiguration().(OPCIONAL) Este método permite especificar las propiedades de configuración del datasource CUSTOM (ver sección 17.3.10). La implementación de este método en el wrapper puede llamar a la implementación de este método en la superclase para obtener las propiedades de configuración por defecto. Si no se implementa este método, el wrapper utilizará las propiedades de configuración por defecto.

Para simplificar el proceso se proporciona una implementación por defecto para la jerarquía de clases que definen el esquema de un wrapper CUSTOM (ver com.denodo.vdb.catalog.wrapper.my.metadata.MyMetaRegisterRaw en la documentación javadoc [4]).

17.4.11.2 Creando el wrapper

Una vez definida la clase que encapsula la metainformación del wrapper, es necesario crear la clase que definirá el comportamiento específico del mismo. Esta clase extenderá com.denodo.vdb.engine.wrapper.raw.my.MyAccessImpl y, tal y como se comentó en la sección anterior, será devuelta por el método doCreate. de com.denodo.vdb.catalog.wrapper.my.MetaMyWrapperImpl (véase la documentación Javadoc [4] para más detalle). Es posible redefinir los siguientes métodos principales:

• doRun. (obligatorio) Este método será invocado por DataPort para ejecutar una consulta sobre el wrapper. Recibe como parámetro la lista de condiciones de consulta que DataPort delega al wrapper para su ejecución sobre la fuente. Esta lista está compuesta por objetos de tipo com.denodo.vdb.engine.wrapper.condition.WrapperCondition (ver documentación Javadoc[4]).

• doInsert. En el caso de que el wrapper soporte inserciones, este método será invocado por DataPort para ejecutar una sentencia INSERT. Recibe como parámetro una lista de nombres de atributos y una lista de los valores a insertar.

• doUpdate. En el caso de que el wrapper soporte actualizaciones, este método será invocado por DataPort para ejecutar una sentencia UPDATE. Recibe como parámetros una lista de los atributos a modificar, una lista con los nuevos valores y una lista de condiciones de consulta compuesta por objetos com.denodo.vdb.engine.wrapper.condition.WrapperCondition (ver documentación Javadoc [4]).



• doDelete. En el caso de que el wrapper soporte borrados, este método será invocado por DataPort para ejecutar una sentencia DELETE sobre el wrapper. Recibe como parámetro una lista de condiciones de consulta compuesta por objetos com.denodo.vdb.engine.wrapper.condition.WrapperCondition (ver documentación Javadoc[4]).

• prepare. En el caso de que el wrapper soporte transacciones, este método será invocado para preparar una transacción.

• commit. En el caso de que el wrapper soporte transacciones, este método será invocado para confirmar una transacción.

• rollback. En el caso de que el wrapper soporte transacciones, este método será invocado para deshacer los cambios de una transacción.

• stop. (obligatorio) Este método será invocado por DataPort para detener la ejecución de un wrapper.

La implementación de estos métodos puede acceder al valor de los parámetros de configuración del wrapper a través del método Map getParameters(). Para cada parámetro, existe una clave en el mapa de la forma MetaPayRollWrapper.PNAME donde PNAME es el nombre del parámetro. La ejecución del wrapper debe proporcionar los resultados de acuerdo a la interfaz com.denodo.vdb.engine.IRawResult (ver documentación Javadoc [4]). Para añadir tuplas a este resultado, el wrapper seguirá los siguientes pasos:

• Invocar el método createRawRow en el objeto MyAccessImpl para crear una nueva tupla vacía (que será un objeto com.denodo.vdb.engine.IRawRow)

• Rellenar la tupla con los datos obtenidos por el wrapper.

• Añadirla al resultado invocando el método addRawRow en el objeto MyAccessImpl.

Es importante tener en cuenta que los resultados devueltos por el wrapper deben ser compatibles con el esquema de la relación base a la que dicho wrapper está asociado en el servidor Virtual DataPort. Más concretamente, los nombres de los atributos obtenidos como resultado de la consulta, deben coincidir con los de la relación base, y además sus valores deben ser compatibles con sus tipos de dato en la relación base.

17.4.11.3 Creando o modificando el wrapper CUSTOM en el servidor DataPort

La Figura 91 muestra la sintaxis de creación de un wrapper de tipo CUSTOM. El único parámetro obligatorio que recibe en su creación –además de un nombre que lo identifica- es el nombre del datasource a partir del cuál se creará (ver sección 17.3.9). Si los wrappers del datasource admiten parámetros de configuración, la cláusula PARAMETERS permite especificarlos. También se admite el modificador OR REPLACE. En caso de ser especificado, si ya existiese un wrapper con el mismo nombre, su definición sería reemplazada por la nueva.



Por último, también se permite especificar ciertas propiedades del wrapper (SOURCECONFIGURATION) que DataPort tendrá en cuenta para determinar qué operaciones pueden realizarse sobre el mismo. En la declaración de la sentencia correspondiente se indican las propiedades aplicables (Figura 91), y son explicadas en la sección 17.4.12. CREATE [ OR REPLACE ] WRAPPER CUSTOM <name:identifier> DATASOURCENAME=<name:identifier> [ PARAMETERS ( <paramName:identifier>=<paramValue:literal> [,<paramName:identifier>=<paramValue:literal>]* ) ]

Figura 91 Sintaxis de creación de un wrapper tipo CUSTOM

La Figura 92 muestra un ejemplo de creación de un wrapper CUSTOM. El wrapper recibe el nombre testcustom y es asociado al datasource CUSTOM llamado testcustomds. Los wrappers del datasource testcustomds reciben dos parámetros de configuración llamados ENTERPRISE y YEAR. El nuevo wrapper es configurado con los valores 'enterprise1' y , '2006' respectivamente. CREATE WRAPPER CUSTOM testcustom DATASOURCENAME=testcustomds PARAMETERS ( ENTERPRISE='enterprise1', YEAR='2006' ) ;

Figura 92 Ejemplo de creación de un wrapper CUSTOM

La sintaxis de la sentencia de modificación de un wrapper CUSTOM es la que se muestra en la Figura 93.. Las opciones disponibles son las mismas que para la creación del wrapper. ALTER WRAPPER CUSTOM <name:identifier> [ DATASOURCENAME=<name:identifier> ] [ PARAMETERS ( <paramName:identifier>=<paramValue:literal> [,<paramName:identifier>=<paramValue:literal>]* ) ]

Figura 93 Sintaxis de modificación de un wrapper tipo CUSTOM

17.4.12 Propiedades de Configuración de Wrappers

Tal y como ya se ha comentado en el apartado 17.3.6, Virtual DataPort mantiene propiedades para cada una de las fuentes de datos y wrappers, 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 17.3.6 se comentaron las propiedades de configuración de las fuentes de datos. En esta sección se describen aquellas propiedades configurables en cada uno de los wrappers, dependiendo del tipo de fuente de datos de donde provienen. Las propiedades de cada wrapper pueden configurarse en la sentencia de creación de wrappers, añadiendo pares parámetro-valor, o desde la herramienta de administración de Virtual DataPort si se desea realizar la operación de manera gráfica (ver Guía del Administrador de VDP [3] para más información). Las propiedades configurables son las siguientes: - Allow Insert (ALLOWINSERT): indica si la fuente de datos subyacente admite operaciones de inserción. Es

aplicable a bases de datos relacionales (accesibles mediante JDBC y ODBC) y wrappers CUSTOM. Los posibles valores son:



c

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

o true: la fuente de datos permite las operaciones de inserción. o false: la fuente de datos no permite las operaciones de inserción.

- Allow Delete (ALLOWDELETE): indica si la fuente de datos subyacente 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 true: la fuente de datos permite las operaciones de borrado. o false: la fuente de datos no permite las operaciones de borrado.

- Allow Update (ALLOWUPDATE): indica si la fuente de datos subyacente 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 true: la fuente de datos permite las operaciones de actualización. o false: la fuente de datos no permite las operaciones de actualización.

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

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

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

- Delegate Compound Field Proje tion (DELEGATECOMPOUNDFIELDPROJECTION): Indica si la fuente permite la delegación de proyecciones sobre campos compuestos. Aplicable a wrappers CUSTOM. Por defecto, el valor es “true”.

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

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

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

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

- Delegate ORDER BY (DELEGATEORDERBY): Indica si la fuente permite la delegación de la cláusula ORDER BY. Aplicable a wrappers CUSTOM. Por defecto, el valor es “true”.

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

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

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

- Delegate Right Literal (DELEGATERIGHTLITERAL): 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 (SUPPORTSDISTRIBUTEDTRANSACTIONS): indica si la fuente de datos subyacente puede participar en una transacción distribuída XA [14]. Es aplicable a bases de datos relacionales (accesibles mediante JDBC y ODBC) y wrappers CUSTOM. Los posibles valores son:


o true: la fuente de datos cumple la especificación XA.



o false: la fuente de datos no cumple la especificación XA. - Data in Order Field List (DATAINORDERFIELDSLIST): Esta propiedad determina la lista de campos por los

que vienen ordenados los datos (si es el caso). Además, para cada campo debe especificarse si la ordenación es ascendente (ASC) o descendente (DESC). Cada par nombre de campo con su criterio de ordenación, se separa por una coma. Esta propiedad es aplicable en todas las fuentes de datos,

- Delegate Operators List (DELEGATEOPERATORSLIST)t: 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 (por defecto todos) y CUSTOM (por defecto “=”).

Ejemplo: si se desea establecer que un wrapper CUSTOM no acepta transacciones (es decir, no permite operaciones de inserción, actualización y borrado, ni soporta transacciones distribuidas), la sentencia de creación del wrapper tendría que ser como sigue: CREATE WRAPPER MY roll CLASSNAME = 'com.denodo.vdp.demo.wrapper.my.MetaPayRollWrapper' SOURCECONFIGURATION ( ALLOWINSERT = false, ALLOWDELETE = false, ALLOWUPDATE = false, SUPPORTSDISTRIBUTEDTRANSACTIONS=false );

Figura 94 Ejemplo de configuración de un Wrapper CUSTOM

17.5 SENTENCIAS DE CONSULTA DE WRAPPERS

Virtual DataPort permite realizar consultas directamente sobre wrappers (sin tener que definir relaciones base sobre ellos ni métodos de búsqueda). En la Figura 95 se muestra la sintaxis general de las sentencia para realizar consultas sobre wrappers. Es necesario indicar el tipo y nombre del wrapper, y una lista opcional de condiciones, en el formato <value>, <operador binario>, <value> (ver sintaxis general de valores de condiciones en sección 4.8.1). No permite operadores unarios ni binarios multivaluados. Se trata de una versión simplificada de consulta, orientada a realizar pruebas sobre los wrappers. QUERY WRAPPER ARN | DF | GS | JDBC | CUSTOM | ODBC | WS | XML <name:identifier> [ ( <value> <binary operator> <value> [, <value> <binary operator> <value> ]* ) ] <value> ::= (ver sección 4.8)

Figura 95 Sintaxis de las sentencias de consulta de wrappers

La sintaxis de la sentencia de consulta de un wrapper ITPilot es un poco diferente y se muestra en la Figura 96. Sólo permite indicar una lista de pares clave=valor, separados por comas, que serán directamente recibidos por el contexto de ejecución del wrapper.



QUERY WRAPPER ITP <name:identifier> [ ( <name:identifier> = <value:literal> [, <name:identifier> = <value:literal>]* ) ]

Figura 96 Sintaxis de la sentencias de consulta de wrappers ITPilot


Características Avanzadas 130

18 CARACTERÍSTICAS AVANZADAS

En esta sección se describen algunas características avanzadas de Virtual DataPort que, si bien no siempre son necesarias en las labores de administración más habituales, pueden ser de interés en ciertos casos.

18.1 GESTIÓN DE VALORES DE TIPOS COMPUESTOS

Virtual DataPort posee dos clases de tipos: los tipos simples y los tipos compuestos. Los tipos compuestos (array y register) permiten representar fácilmente datos con estructura jerárquica en las vistas y relaciones base de DataPort. Por lo tanto, es necesario definir algún mecanismo que permita navegar por la estructura interna de un valor compuesto para acceder a sus subelementos (simples o compuestos) en cualquier nivel del árbol. NOTA: En Virtual DataPort un elemento de tipo array debe ser visto como una subrelación; en realidad un array DataPort siempre tendrá asociado internamente un tipo register. Cada subelemento contenido en el array pertenecerá a dicho tipo de datos register. De esta forma, los campos de este registro pueden verse como el esquema de la subrelación que está modelando. Es importante tener esto en cuenta a la hora de aplicar operadores sobre subelementos de un campo compuesto. Los valores en Virtual DataPort están siempre contenidos dentro de vistas (también llamadas relaciones). Una vista posee un esquema, es decir: una lista de atributos, cada uno de ellos perteneciente a un tipo de dato. Todo valor de un atributo de una vista puede ser identificado unívocamente dentro de una tupla mediante una expresión llamada URI. El URI asociado al valor de un atributo perteneciente a un tipo simple consiste simplemente en el nombre del atributo. Por el contrario, el valor de un atributo de tipo compuesto se representa mediante un árbol, en el cuál las hojas son valores atómicos (esto es, pertenecientes a tipos de datos simples). En estos árboles, existen dos tipos de nodos no hoja:

• Arrays (tipo array): Desde ellos sale un arco hacia cada uno de los nodos que representan a los subelementos que componen el array (todos pertenecerán a un mismo tipo de dato register). Cada arco está etiquetado con el índice de posición del subelemento del array al que apunta, escrito entre los símbolos "[" y "]".

• Registros (tipo register): Desde ellos sale un arco hacia cada uno de los nodos que representan a los subelementos que componen el registro (cada subelemento puede pertenecer a un tipo de dato diferente). Cada arco está etiquetado con el nombre del subelemento.

Además, la raíz del árbol es apuntada por un arco con el nombre del atributo. Dado este árbol, el URI que identifica a un nodo del mismo se obtiene comenzando por la raíz, y bajando por el árbol, concatenando (separados por el carácter ".", salvo en los casos de índices de arrays en los cuáles se indica sólo el valor del índice entre corchetes) los nombres de los diferentes arcos que es necesario atravesar hasta llegar al nodo deseado. Finalmente, se concatena al principio de la cadena, el nombre del atributo. Además, si en un URI, para un nodo de tipo array, no se especifica ninguno de sus arcos salientes (mediante el correspondiente índice), entonces el URI apuntará a la lista de valores que se obtiene atravesando todos los arcos del array que no fue indexado. Por lo tanto, desde el punto de vista de la evaluación de URIs sobre tuplas, pueden distinguirse dos tipos:

• Las que apuntan a un valor de tipo simple o de tipo register.



• Las que apuntan a una lista de valores, consecuencia de no haber indexado un elemento de tipo array que se encuentra en la estructura de árbol del tipo. Un URI de este tipo apunta a una serie de nodos que se encuentran en el mismo nivel del árbol. Estos URIs se corresponden con valores de tipo array DataPort y, por tanto, pueden verse como una subrelación donde cada elemento del array es una tupla y el esquema de dicha tupla viene definido por los campos del elemento register que el array lleva asociado.

Los URIs del primer tipo pueden ser siempre utilizados en la cláusula SELECT de las consultas o como atributos de agrupación en una cláusula GROUP BY. Si además el valor apuntado es de tipo simple, entonces este URI puede ser utilizado de la misma forma que cualquier otro atributo de tipo simple en una sentencia de consulta: en las cláusulas SELECT, WHERE, GROUP BY, etc. Utilizando los constructores ROW y ‘‘ ‘’ (ver sección 6.3.1) es también posible construir valores compuestos y utilizarlos en la parte derecha de una condición. En este caso las condiciones sólo podrán utilizar los operadores ‘=’ y ‘<>’, y los tipos de las URIs de la parte derecha y la parte izquierda de la condición deben ser compatibles (es decir, sus árboles deben ser iguales exceptuando los nombres de los arcos). Respecto a los URIs del segundo tipo pueden aparecer en los siguientes casos:

• En las condiciones de las cláusulas WHERE, cuando estas URIs aparecen en la parte izquierda de una condición y en la parte derecha aparece una URI del primer tipo. En este caso las condiciones se evalúan como si se tratase de una condición sobre la subrelación modelada por la URI.

• En una FLATTEN VIEW utilizada en la claúsula FROM. Ver sección 6.1.2.

• Las funciones de agregación (ver sección 6.4.1) soportan este tipo de URIs. Por ejemplo, la función de agregación LIST, cuando recibe este tipo de URIs como parámetro, devuelve como resultado un array de registros que tienen como único subelemento a cada uno de los valores referenciados por ese URI.

Además de los árboles que representan valores, existen también árboles para representar la estructura interna de los tipos de dato compuestos. En este caso, los nodos de tipo array tienen un solo subelemento (el nodo registro que representa a su registro asociado), ya que se pretende representar la estructura interna del tipo, y no una instancia con valores.

18.1.1 Manejo de Tipos Compuestos: Ejemplo

Supóngase que se desea definir una relación que modele libros con un título y varios autores. Podríamos tener los atributos:

• TITLE, de tipo simple (text, por ejemplo)

• AUTHOR, de tipo compuesto. Más concretamente, podemos tener varios autores y, para cada autor, se desea representar su nombre, sus apellidos y una lista de direcciones de contacto. Como ya se ha explicado anteriormente, un tipo array modela una subrelación, con lo cual es necesario indicar mediante un tipo registro el esquema de esa relación. La subrelación AUTHOR tendrá pues asociado un tipo registro con subatributos de tipo simple NAME, SURNAME y otro atributo compuesto de tipo array para contener la lista de direcciones de contacto (CONTACTADDRESS). CONTACTADDRESS representa otra subrelación, con un esquema compuesto por los subatributos MAIL y ADDRESS; MAIL tiene tipo simple y ADDRESS es un registro compuesto por los subatributos: STREET, CITY y COUNTRY.

El árbol del tipo AUTHOR se muestra en la Figura 97. El tipo de dato para representar elementos de tipo AUTOR puede crearse con las siguientes sentencias: CREATE TYPE address AS REGISTER OF ( STREET:text,



Figura 97

CITY:text, COUNTRY:text ); CREATE TYPE contactAddress AS REGISTER OF ( MAIL:text, ADDRESS:address ); CREATE TYPE contactAddressArray AS ARRAY OF contactAddress; CREATE TYPE author AS REGISTER OF ( NAME:text, SURNAME:text, CONTACTADDRESS:contactAddressArray ); CREATE TYPE authorArray AS ARRAY OF author;

text register

text text register

NAME

SURNAME

CONTACTADDRESS

text register

MAIL

ADDRESS

text text register

CITYSTRE

ET

COUNTRY

Árboles de tipos compuestos

En la Figura 98 se muestra un ejemplo de tupla de esta vista y su representación interna: TITLE AUTHOR Book1 NAME SURNAME CONTACTADDRESS

Name1 Surname1

MAIL ADDRESS [email protected] STREET CITY COUNTRY

Street1 City1 Country1 MAIL ADDRESS [email protected] STREET CITY COUNTRY

Street2 City2 Country2



NAME SURNAME CONTACTADDRESS Name3 Surname3 MAIL ADDRESS

[email protected] STREET CITY COUNTRY Street3 City3 Country03

MAIL ADDRESS [email protected] STREET CITY COUNTRY

Street4 City4 Country04

Figura 98

Figura 99

Figura 100

Tupla con elementos compuestos

La estructura del árbol de valores se muestra en la Figura 99.

book1

register

name1 surname1 array

NAME

SURNAMECONTACTADDRESS

array

register

name3 surname3 array

NAME

SURNAME

CONTACTADDRESS

[0] [1]

register

[email protected]

register

MAILADDRESS

street1 city1 country1

CITYSTRE

ET

COUNTRY

register

[email protected]

register

MAILADDRESS


CITYSTRE

ET

COUNTRY

register

[email protected]

register

MAILADDRESS


CITYSTRE

ET

COUNTRY

register

[email protected]

register

MAILADDRESS


CITYSTRE

ET

COUNTRY

[1] [1][0][0]

Árbol de valores de tipos compuestos

A continuación, puede crearse una relación base que modele esta relación: CREATE TABLE BOOK I18N es_euro ( TITLE:text (SEARCH), AUTHOR:authorArray );

Creación de una relación base con tipos compuestos

Será necesario también crear un wrapper para la relación. Nótese que, como siempre, el esquema de los datos devueltos por el wrapper debe ser compatible con el esquema de la relación, lo que en este caso significa que el wrapper precisará devolver sus datos en la forma de valores compuestos. Por ejemplo, la siguiente figura muestra parte de una sentencia VQL para la creación de un wrapper ITPilot para obtener la información deseada. Nótese cómo el esquema de salida definido es compatible con el de la relación:



Figura 101

Figura 102

CREATE WRAPPER ITP BOOK_sm1 OUTPUTSCHEMA ( TITLE, AUTHOR:ARRAY OF AUTHOR:REGISTER OF ( NAME, SURNAME, CONTACTADDRESS:ARRAY OF CONTACTADDRESS:REGISTER OF ( MAIL, ADDRESS:ARRAY OF ADDRESS:REGISTER OF ( STREET, CITY, COUNTRY ) ) ) ) … Wrapper definition …;

Creando un método de búsqueda con tipos compuestos

Una vez creado el wrapper, puede definirse un método de búsqueda para la relación BOOK. Normalmente, sólo los URIs que apunten a tipos de datos simples tendrán definidas restricciones de consulta (esto es coherente con el hecho de considerar los atributos de tipos compuestos como si se tratase de subrelaciones). Sin embargo también es posible añadir restricciones para URIs que apunten a tipos compuestos (en ese caso, recuérdese que los operandos de la parte derecha de las condiciones se construirán con los constructores ROW y ‘‘ ‘’ y que sólo podrán utilizarse los operadores ‘=’ y ‘<>’). La siguiente sentencia añade un posible método de búsqueda (nótese que se ha incluido una restricción para la URI compuesta AUTHOR.CONTACTADDRESS): ALTER TABLE BOOK ADD SEARCHMETHOD BOOK_SM1 ( CONSTRAINTS ( ADD TITLE NOS ZERO () ADD AUTHOR.NAME NOS ZERO () ADD AUTHOR.SURNAME NOS ZERO () ADD AUTHOR.CONTACTADDRESS NOS ZERO () ADD AUTHOR.CONTACTADDRESS.MAIL NOS ZERO () ADD AUTHOR.CONTACTADDRESS.ADDRESS.STREET NOS ZERO () ADD AUTHOR.CONTACTADDRESS.ADDRESS.CITY NOS ZERO () ADD AUTHOR.CONTACTADDRESS.ADDRESS.COUNTRY NOS ZERO () ) OUTPUTLIST (TITLE, AUTHOR) WRAPPER (ITP book) );

Adición de un método de búsqueda con tipos compuestos

NOTA: En el caso de especificación de atributos compuestos en condiciones de consulta y para evitar ambigüedades entre nombre de tabla y nombre de atributo, los nombres de atributo (opcionalmente <nombre de tabla>.<nombre de atributo>) se especificarán entre paréntesis, especificando los campos de los elementos compuestos a continuación (separados por puntos o indexados con un entero entre corchetes). Finalmente, se muestran algunos ejemplos de consultas que podrían realizarse sobre la relación: 1. Para todos los libros que contienen en su título la palabra ‘java’, se obtiene su título y el nombre de cada uno de sus autores. SELECT TITLE, LIST((AUTHOR).NAME) AS AUTHORLIST FROM BOOK WHERE TITLE like '%java%' GROUP BY TITLE;



2. Para todos los libros que contienen en su título la palabra ‘java’, se obtiene el título y la lista de contactos de cada uno de sus autores. SELECT TITLE, LIST((AUTHOR).CONTACTADDRESS) AS AUTHORLIST FROM BOOK WHERE TITLE like '%java%' GROUP BY TITLE; 3. Para todos los libros que contienen en su título la palabra ‘java’, se obtiene su título y la primera dirección de correo de cada uno de sus autores. SELECT TITLE,LIST((AUTHOR).CONTACTADDRESS[0].MAIL) AS AUTHORLIST FROM BOOK WHERE TITLE like '%java%' GROUP BY TITLE; 4. Para todos los libros que contienen en su título la palabra ‘java’ y que tengan al menos un autor con alguna dirección de correo que contenga la palabra ‘.es’, se obtiene el título y el nombre de cada uno de sus autores. SELECT TITLE, LIST((AUTHOR).NAME) AS AUTHORLIST FROM BOOK WHERE (TITLE like '%java%') AND ( (AUTHOR).CONTACTADDRESS.MAIL like '%.es%' ) GROUP BY TITLE; 5. Para todos los libros que contienen en su título la palabra ‘java’ y que tengan al menos un autor con alguna dirección en la calle ‘Real’, se obtiene el título y el nombre de cada uno de sus autores. SELECT TITLE, LIST((AUTHOR).NAME) AS AUTHORLIST FROM BOOK WHERE (TITLE like '%java%') AND ((AUTHOR).CONTACTADDRESS.ADDRESS.STREET like '%Real%') GROUP BY TITLE; 6. Se obtienen los libros con algún autor que tenga una única dirección de contacto cuyo e-mail sea [email protected], y que viva en la ciudad de Madrid (España) en la calle Real. SELECT TITLE, AUTHOR FROM BOOK WHERE (AUTHOR).CONTACTADDRESS = ROW('[email protected]',ROW('Real', 'Madrid', 'España'))

18.2 OPTIMIZACIÓN DE CONSULTAS

Esta sección describe diversos aspectos de interés con respecto a la optimización de las consultas efectuadas mediante Virtual DataPort. En primer lugar se discuten las posibles estrategias de ejecución para las operaciones de join y cómo escoger la estrategia más adecuada para una vista o una consulta. A continuación se discuten las opciones de configuración de la cache DataPort para una vista determinada. Finalmente se describe cómo configurar la política de “swapping” a disco de DataPort durante la ejecución de consultas que involucren resultados intermedios de gran tamaño.

18.2.1 Optimización de Operaciones de join

Un aspecto clave de la optimización de consultas en Virtual DataPort es la elección de la estrategia más adecuada para la realización de las operaciones de join. Si bien Virtual DataPort intentará utilizar la estrategia más adecuada en cada caso basándose en información de costes interna, es posible forzar una determinada estrategia de ejecución para la operación de join que se desee.

mailto:[email protected]



Una estrategia de ejecución para un join consta de dos elementos: el método utilizado para implementar la operación de join y el orden en el que deben considerarse las relaciones de entrada del join. Virtual DataPort soporta los siguientes métodos de ejecución:

• MERGE. Sólo puede ejecutarse en aquellos casos en los que los datos de las relaciones de entrada están ordenados por los atributos de join. En ese caso, esta estrategia suele ser la más eficiente y la que menos memoria consume. En el caso de que los datos no estén ordenados, será posible la utilización de esta técnica de join si las fuentes involucradas son todas bases de datos (accedidas a través de los wrappers JDBC u ODBC) ya que en ese caso DataPort puede recuperar los datos ordenados de las fuentes origen. Si se intenta forzar el uso de esta estrategia en un caso en el que no sea aplicable, DataPort producirá un mensaje de error.

• NESTED: Este método de ejecución obtiene en primer lugar las tuplas de la primera relación de entrada que verifican la condición de join y posteriormente, para cada combinación de valores obtenida para los atributos que participan en el join, se emite una sub-consulta que obtiene las tuplas que se corresponden con dicha combinación de valores en la segunda relación de entrada. En el caso de que la segunda relación de entrada provenga de una base de datos, DataPort optimizará este proceso emitiendo una sola sub-consulta que recupere todos los datos necesarios de la segunda relación. Este método suele ser altamente eficiente cuando la primera relación de entrada es relativamente pequeña con respecto a la segunda y, además, la latencia por consulta de la segunda fuente es baja. Al utilizar este método es especialmente importante el orden de las relaciones de entrada de forma que la primera sea la de menor tamaño esperado.

• NESTED PARALLEL: Este método de ejecución es similar al método NESTED. La diferencia es que las sub-consultas emitidas sobre la segunda relación de entrada pueden emitirse en paralelo, mientras que en el caso de NESTED se emiten secuencialmente. Admite un parámetro adicional que especifica el número máximo de sub-consultas emitidas en paralelo.

• HASH. Este tipo de join suele ser el más eficiente cuando los datos en las relaciones de entrada no están ordenados y son grandes. También suele ser el más eficiente cuándo los tiempos de latencia de consulta de las fuentes de las que proceden los datos son altos (e.g. fuentes web), ya que este tipo de join minimiza el número de sub-consultas efectuadas sobre las fuentes.

Al crear una vista de tipo join o al escribir una consulta es posible especificar el método de ejecución deseado especificando los modificadores NESTED, NESTED PARALLEL, MERGE o HASH. Ejemplos:

FROM view1 HASH JOIN view2 ON (joinCondition) FROM view1 MERGE LEFT OUTER JOIN view2 ON (joinCondition) FROM view1 NESTED NATURAL INNER JOIN view2 FROM view1 NESTED PARALLEL JOIN 5 view2 ON (joinCondition)

Nótese cómo en el ultimo ejemplo se limita a 5 el número máximo de subconsultas en paralelo ejecutadas mediante el método NESTED PARALLEL. Adicionalmente es possible fijar el orden deseado de las relaciones de entrada utilizando los modificadores ORDERED (indica que las relaciones de entrada deben considerarse en el orden especificado en la cláusula join) y REVERSEORDER (indica que las relaciones de entrada deben considerarse en el orden inverso al especificado en la cláusula join). Ejemplos:

FROM view1 NESTED ORDERED JOIN view2 ON (joinCondition) FROM view1 NESTED REVERSEORDER LEFT OUTER JOIN view2 ON (joinCondition)



18.2.1.1 Elección dinámica de la estrategia de join

Cuando se ejecuta una consulta que utiliza en su claúsula FROM vistas derivadas y la definición de dichas vistas derivadas involucra operaciones de join, es posible especificar dinámicamente una estrategia de ejecución para cada una de estas operaciones (cambiando sólo para esta consulta la estrategia que se hubiese especificado en el momento de creación de la vista). Para especificar dinámicamente la estrategia de ejecución debe utilizarse la cláusula CONTEXT con la opción QUERYPLAN. Asimismo es también posible utilizar la sentencia ALTER VIEW (ver sección 7.1) para modificar la estrategia de ejecución de los joins que participan en la definición de una vista determinada. La sintaxis formal de la opción QUERYPLAN puede verse en la Figura 103 . QUERYPLAN = <query_plan> <query plan> ::= | [<view name:identifier> : <view plans>]+ <view plans> ::= <view plan> | [ ( [<view plan>] ) ]+ <view plan> ::= <any method type> <any order type> | NESTED PARALLEL [nestedParallelNumber:integer] <any order type> <any method type> ::= <method type> | ANY <any order type> ::= <order type> | ANY <method type> ::= HASH | NESTED | MERGE <order type> ::= ORDERED | REVERSEORDER

Figura 103 Sintaxis de QUERYPLAN

Considérese el siguiente ejemplo. Supongamos tres relaciones base V1, V2 y V3. V1 está compuesta por los atributos A y B, V2 por los atributos B y C, y V3 por los atributos C, D y E. Supongamos ahora que se ejecutan las siguientes sentencias VQL:

CREATE VIEW V4 AS SELECT A,B,C FROM V1 MERGE JOIN V2 USING (B)

y

CREATE VIEW V5 AS SELECT A,B,C,D,E FROM V4 NESTED ORDERED JOIN V3 USING (C) WHERE A>a

La Figura 104 muestra el árbol de definición de la vista V5 (este árbol puede obtenerse fácilmente con ayuda de la herramienta de administración gráfica de Virtual DataPort. Ver [3]). Cómo puede verse hay dos operaciones de join que forman parte del árbol: la utilizada al crear la vista intermedia V4 (dónde se fuerza el método de ejecución MERGE) y la utilizada para crear V5 (dónde se fuerza el método de ejecución NESTED con V4 como primera relación).



Figura 104

Árbol de definición de la vista V5

Supóngase ahora que se desea ejecutar la consulta VQL:

SELECT * FROM V5 WHERE D=d En este caso puede desearse forzar una estrategia de ejecución diferente para los joins que componen el árbol de V5. Por ejemplo, es posible que haya muy pocas tuplas en V3 que verifiquen la nueva condición D=d, con lo cuál sería esperable que entren al join de creación de V5 menos tuplas por parte de V3 que por parte de V4. En esas condiciones, y sólo para esta consulta, sería deseable cambiar el orden de las relaciones de entrada para que V3 sea considerada como primera relación y V4 como segunda. Esto puede hacerse mediante la opción QUERYPLAN de la cláusula CONTEXT. Para cada operación join que haya en el árbol de nuestra consulta, podemos especificar el nombre de la vista intermedia que la utiliza y la preferencia para el método de ejecución y el orden de las relaciones de entrada. ANY se utiliza para indicar que se desea que la elección la realice DataPort. Así, en nuestro ejemplo podríamos forzar para esta consulta que el join de creación de V5 se realice con el orden deseado:

SELECT * FROM V5 WHERE D=d CONTEXT ('QUERYPLAN ' = 'V5:NESTED REVERSEORDER')

También sería posible cambiar la estrategia de ejecución del join utilizado para crear V4. Por ejemplo, si deseásemos cambiar dicha estrategia para utilizar el método HASH y dejando que sea DataPort quién escoja el orden de las relaciones de entrada, escribiríamos:

SELECT * FROM V5 WHERE D=d CONTEXT ('QUERYPLAN ' = 'V5:NESTED REVERSEORDER V4:HASH ANY ')



Cómo ya se ha comentado, la opción QUERYPLAN está también disponible en la sentencia ALTER VIEW para modificar las estrategias de ejecución de los joins involucrados en la definición de una vista determinada. Por ejemplo, si deseásemos modificar las estrategias de ejecución de los joins de la vista V5 podríamos escribir:

ALTER VIEW V5 QUERYPLAN = V5:NESTED REVERSEORDER V4:HASH ANY;

18.2.2 Uso de la Cache

Los comandos de modificación de una relación base (ALTER TABLE. Ver sección 5.1) y de modificación de una vista (ALTER VIEW. Ver sección 7.1) permiten activar el sistema cache (opción CACHE) para, respectivamente, una relación base o una vista derivada. En ese caso se materializarán en la base de datos local que actúa como cache las tuplas que se vayan obteniendo como resultado de la ejecución de consultas sobre la vista. El comando ALTER DATABASE (ver sección 12.3.2) permite fijar la configuración por defecto para las relaciones base y las vistas de una base de datos determinada. Nótese, que si una vista tiene activada esta opción, puede utilizarse también para la realización de precargas periódicas simplemente ejecutando sobre la relación, con la periodicidad que se desee, una consulta que obtenga los datos a precargar. El sistema caché permite configurar dos tipos de comportamiento diferentes:

- Caché de consulta exacta: En este caso el sistema indicará un acierto caché sólo si previamente se ha realizado una consulta idéntica a la actual. Este modo será el utilizado al utilizar la opción CACHE ON en los comandos antes mencionados.

- Caché de consulta más general: (opción CACHE POST). Si esta opción 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), 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 alguna consulta previa. El uso de esta opción 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 resultado 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.

Si no se desea utilizar la caché en la relación base, basta usar la opción CACHE OFF. También se permite la modificación del tiempo de vida de los datos en caché, es decir, el timeout de expiración de los datos en la caché, utilizando la propiedad TIMETOLIVEINCACHE (expresado en segundos).

18.2.2.1 Uso de DELEGATEUNNAMEDVIEWS con Cache

La cláusula CONTEXT permite modificar el contexto de ejecución para una consulta determinada (ver sección 6.8). Entre sus opciones incluye el parámetro DELEGATEUNNAMEDVIEWS, cuyo uso presenta ciertas implicaciones en el comportamiento de la cache. Dichas implicaciones se describen en esta sección. El parámetro DELEGATEUNNAMEDVIEWS puede tomar los valores ‘YES’ o ‘NO’. Si no se indica, se asume el valor ‘YES’.



Al crear vistas utilizando la herramienta de administración gráfica de Virtual DataPort, es posible que el sistema cree vistas intermedias adicionales (normalmente, de tipo proyección). Estas vistas reciben un nombre interno creado por DataPort y, por ello, se denominan “vistas sin nombre”. Por ejemplo, supóngase que se crea gráficamente una vista tipo unión a la que llamaremos U, que se obtiene en base a dos vistas A y B. Si durante el proceso de creación gráfica de la vista, el usuario elimina un atributo de la vista unión procedente de la vista base A, DataPort añadirá transparentemente al árbol de U una vista proyección sin nombre por encima de A. DataPort también puede generar una vista sin nombre cuando se ejecuta una consulta que realiza una proyección o agregación sobre una vista existente. Por ejemplo, considérese la siguiente consulta: SELECT ATTR1, ATTR2 FROM VIEW Para ejecutar esta consulta, DataPort creará por encima de VIEW una vista proyección temporal sin nombre, que será la encargada de quedarse con los atributos ATTR1 y ATTR2 (en este sentido, es interesante notar que una consulta como SELECT * FROM VIEW no requiere crear ninguna vista adicional). Por otro lado, DataPort intenta delegar siempre la mayor cantidad de procesamiento que sea posible a las fuentes de datos origen para optimizar los tiempos de ejecución de consultas. En ciertos casos, la delegación a la fuente de las operaciones efectuadas por las vistas sin nombre puede llevar a que en ciertas consultas no se utilice la cache de una vista, incluso aunque la cache haya sido activada. En estos casos, el usuario puede decidir fijar el valor de esta propiedad a ‘NO’. Considérese el ejemplo anterior de una vista unión U compuesta a partir de las vistas base A y B. A se corresponde con una tabla en una base de datos relacional mientras que B se corresponde con una operación de un Servicio Web. Al crear U gráficamente, se eliminó un atributo procedente de la vista A, por lo que en el árbol de U DataPort introdujo una vista proyección sin nombre sobre A. Supóngase también que la cache está activada para la vista A. Si ahora se ejecuta una consulta sobre U, la cache de A nunca entrará en funcionamiento. La razón es la siguiente: DataPort, al alcanzar durante el proceso de ejecución el nodo del árbol de U correspondiente la vista proyección sin nombre por encima de A, detectará que es posible delegar a la base de datos fuente tanto la subconsulta que el plan de ejecución especifique sobre A como la proyección sin nombre a aplicar sobre ella. Por lo tanto, el proceso de ejecución no descenderá hasta el nodo que representa a la vista base A y no se considerará su cache. Por el contrario, si se escoge la opción ‘NO’ para DELEGATEUNNAMEDVIEWS, DataPort no delegará a la fuente las operaciones que se corresponden con proyecciones sin nombre. Por lo tanto, en nuestro ejemplo, la cache de A sí sería considerada.

18.2.3 Configuración de Políticas de “Swapping”

Durante la ejecución de consultas que involucren el manejo y combinación de grandes volúmenes de datos es posible que DataPort precise realizar de forma automática operaciones de “swapping” a disco para evitar posibles errores de desbordamiento de memoria. Los comandos de modificación de una relación base (ALTER TABLE. Ver sección 5.1), de modificación de una vista (ALTER VIEW. Ver sección 7.1) y de ejecución de una consulta (cláusula CONTEXT del comando SELECT. Ver sección 6.8) permiten habilitar o deshabilitar el swapping a disco de resultados intermedios mediante la opción SWAP ON o SWAP OFF. El comando ALTER DATABASE (ver sección 12.3.2) permite fijar la configuración por defecto para las relaciones base y las vistas de una base de datos determinada. DataPort realizará “swapping”cuándo se haya escogido SWAP ON y además algún resultado intermedio producido durante la ejecución de la consulta o vista supere un determinado tamaño máximo. Este tamaño puede indicarse (en



megabytes) utilizando la opción SWAPSIZE de los comandos anteriormente mencionados (el valor por defecto es de 50 Mb). Para evitar operaciones de acceso a disco innecesarias que pueden ralentizar la ejecución, puede ser conveniente deshabilitar el swapping para una determinada vista o para una determinada consulta en la que no se prevean desbordamientos de memoria. También puede ser conveniente incrementar para una vista o consulta el valor de SWAPSIZE. Esto es útil cuando es posible que algún resultado intermedio supere el valor por defecto pero, aún en ese caso, sabemos que el sistema tendrá memoria suficiente para que no se produzca un desbordamiento. Como norma general, se recomienda que el valor de SWAPSIZE 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. Ejemplos: 1) Deshabilitar el swapping en una vista:

ALTER VIEW V SWAP OFF; 2) Habilitar el swapping en una vista, fijando un SWAPSIZE de 100 Mb:

ALTER VIEW V SWAP ON SWAPSIZE 100; 3) Ejecutar una consulta deshabilitando el swapping:

SELECT … CONTEXT ('SWAP' = 'OFF') 4) Ejecutar una consulta con swapping habilitado y un SWAPSIZE de 100 Mb:

SELECT … CONTEXT ('SWAP' = 'ON', 'SWAPSIZE'= '100' )

18.3 CREACIÓN DE CONFIGURACIONES DE INTERNACIONALIZACIÓN

Virtual DataPort puede trabajar con datos que provienen de un conjunto de paises/localizaciones diferentes. Para cada uno de los paises/localizaciones de los que pueden proceder los datos que maneja el servidor, existe una configuración de internacionalización, que se representa por medio de un mapa. Existen varios parámetros configurables para cada una de las localizaciones contempladas. Algunos ejemplos de parámetros configurables son: moneda, símbolos utilizados como separadores decimales y de miles para la moneda, formato de fecha, etc. Si bien DataPort incluye configuraciones de internacionalización ya creadas para las situaciones más comunes, crear nuevas configuraciones es un proceso muy sencillo. Esta sección describe detalladamente dicho proceso. Los parámetros de internacionalización de una localización se pueden dividir en varios grupos. A continuación se citan los diferentes grupos y se describen en detalle cada uno de los parámetros que los componen: NOTA: Los parámetros de internacionalización no son sensibles a mayúsculas y minúsculas; por ejemplo, “timeZone” y “timezone” corresponden a la misma clave.

• Genéricos

o language – Indica el lenguaje que se utiliza en esta localización. Es un código ISO de lenguaje válido. Estos códigos se especifican con dos letras en minúsculas tal y como se define en ISO-639 [1]. Ejemplos: es (Español), en (Inglés), fr (Francés).



o country – Especifica el país asociado a esta localización. Es un código ISO de país válido. Estos códigos se corresponden con dos letras en mayúsculas, definidos por ISO-3166 [2]. Ejemplos: ES (España), ES_EURO (España con moneda EURO), GB (Inglaterra), FR (Francia), FR_EURO (Francia con moneda EURO), US (Estados Unidos).

o timeZone – Indica la franja horaria de la localización (e.g., Europe/Madrid para España = GMT+01:00 = MET = CET).

• Configuración de la moneda: Permite configurar diferentes propiedades de los valores de tipo money.

o currencyDecimalPosition – Número de decimales que admite la moneda de la localización. Por ejemplo, para el euro este valor es 2.

o currencyDecimalSeparator – Carácter que se utiliza como separador decimal en la moneda. Por ejemplo, el separador decimal para el euro es la coma.

o currencyGroupSeparator – Separador de grupos en la moneda que se utiliza para la localización. Por ejemplo, para el euro el separador de grupos es el punto.

o currency – Nombre de la moneda. Ejemplo: EURO, LIBRA, FRANCO.

o moneyPattern – Especifica el formato para las monedas. Para el formato de monedas siempre se utiliza la coma como separador de miles y el punto como separador de decimales. El carácter ‘¤’ representa el símbolo de la moneda, e indica en qué lugar se debe posicionar el carácter o caracteres que lo representa. Ejemplo: ###,###,###.## ¤. Para analizar las monedas se utilizan los patrones que define la clase java.text.DecimalFormat, de la API estándar Java Developer Kit (véase su documentación Javadoc [9] para más información).

• Configuración del tipo de dato time:

o timePattern – Unidad de tiempo en la que se expresan los valores de este tipo en esta localización. Los valores posibles son: SECOND, MINUTE, HOUR, DAY, WEEK, MONTH y YEAR.

• Configuración de fechas: Configuración del tipo de dato date.

o datePattern – Indica el formato para las fechas. Para especificar el formato de fechas, se utilizan caracteres ASCII para indicar las diferentes unidades de tiempo. En la Tabla 8 se muestra el significado de cada uno de los caracteres reservados que se utilizan en el formato de una fecha, su presentación y un ejemplo de su utilización. Ejemplo de un formato de fecha: d-MMM-yyyy H'h' m'm'. Para más información, ver [9], clases java.text.DateFormat y/o java.text.SimpleDateFormat.

Símbolo Significado Presentación Ejemplo G Especifica una Era (Texto) AD y Año (Número) 1996 M Mes en año (Texto & Número) July & 07



d Día en mes (Número) 10 h Hora en am/pm (1~12) (Número) 12 H Hora en día (0~23) (Número) 0 m Minuto en hora (Número) 30 s Segundo en minuto (Número) 55 S Milisegundo (Número) 978 E Día de la semana (Texto) Tuesday D Día del año (Número) 189 F Día de la semana en el mes (Número) 2(2nd Web in July) w Semana del año (Número) 27 W Semana en mes (Número) 2 a Marca de am/pm (Texto) PM k Hora en el día (1~24) (Número) 24 K Hora en am/pm (0~11) (Número) 0 z Zona horario (Texto) Pacific Standard Time ' Carácter de escape para texto (Delimitador) '' Comilla simple (Literal) ‘

Tabla 8 Caracteres reservados para el formato de una fecha

En la Tabla 8, para indicar la presentación de los caracteres reservados, se utilizan diferentes valores. El formato concreto de representación de salida depende del número de repeticiones de los diferentes elementos:

o Texto: con 4 o más caracteres para utilizar forma completa; menos de 4 caracteres para utilizar la forma abreviada.

o Número: utiliza el mínimo número de dígitos posibles. A los números más cortos se le añaden los 0’s a su izquierda. El año es un caso especial: si el número de ‘y’ es 2, el año se truncará a 2 dígitos.

o Texto & Número: 3 o más caracteres para representarlo como texto; en otro caso usa un número.

En un formato de fecha, los caracteres que no se encuentran en los rangos ['a'..'z'] ni ['A'..'Z'], se consideran como texto entrecomillado. Es decir, caracteres como ':', '.', ' ', '#' y '@' aparecerán en la fecha resultante incluso aunque no vayan entrecomillados en el texto de formato.

• Configuración de los números reales: Permiten configurar los tipos de datos float y double.

o doubleDecimalPosition – Indica el número de posiciones decimales a utilizar para representar un valor de tipo double o float (un número real).

o doubleDecimalSeparator – Representa al separador de decimales que se utiliza en un número real.

o doubleGroupSeparator – Especifica cual es el separador de grupos para los números reales.

A continuación se muestra la sentencia necesaria para la creación de la configuración de internacionalización es_euro, que contiene los valores utilizados habitualmente en España: CREATE MAP i18n i18n_es_euro (



'language' = 'es' 'country' = 'ES_EURO' 'timezone' = 'Europe/Madrid' 'currencydecimalposition' = '2' 'currencydecimalseparator' = '' 'currencygroupseparator' = '' 'currencysymbol' = '' 'currency' = 'EURO' 'timepattern' = 'DIA' 'datepattern' = 'd-MMM-yyyy H\'h\' m\'m\'' 'moneypattern' = '###,###,###.## ¤' 'doubledecimalposition' = '2' 'doubledecimalseparator' = '' 'doublegroupseparator' = '' );

Figura 105

c

Internacionalización es_euro

18.3.1 Acceso y Mantenimiento de la Información de Cambio de Divisas

Los valores de cambio de divisas que se utilizan para la conversión de monedas, se obtienen a través de una vista predefinida dentro de la base de datos admin de Virtual DataPort llamada CURRENCY. La vista CURRENCY posee tres campos para especificar el nombre de un país (COUNTRY), el cambio de su moneda con respecto al euro (CHANGE) (es decir, cuántas unidades de esa moneda constituyen un euro) y una descripción (DESCRIPTION). Los tres campos son de tipo text. El formato para los códigos de país es el de un código de país ISO válido [2]. DataPort podrá realizar conversiones entre cualesquiera monedas para las que exista una entrada válida en la vista CURRENCY. Para alimentar automáticamente la vista CURRENCY con datos actualizados pueden importarse en el sistema fuentes externas que proporcionen esta información. Por ejemplo la web del Banco Central Europeo [7] proporciona los cambios con respecto al euro de las principales monedas del mundo en formatos HTML, XML y CSV. El conversor de divisas on-line OANDA [8] también proporciona información a este respecto. Por defecto, la vista CURRENCY contiene los valores de cambio fijo de varias antiguas monedas europeas con respecto al EURO.

18.4 CONTEXTO DE EJECUCIÓN DE UNA CONSULTA Y CADENAS DE INTERPOLACIÓN

En esta sección se describen los conceptos de contexto de ejecución y cadena de interpolación. Estos instrumentos se utilizan en Virtual DataPort para parametrizar ciertas expresiones utilizadas por el wrapper o el datasource asociado a una determinada relación base en función de las consultas efectuadas sobre dicha relación (véase sección 17). El contexto de ejecución de una consulta está compuesto por un conjunto de variables que toman la forma de pares clave-valor, dónde tanto la clave como el valor son cadenas de caracteres. Cuando se ejecuta una determinada consulta, por cada condición de consulta se añade una variable al contexto. El nombre asociado a esta variable es el nombre del atributo junto con el operador utilizado en la condición, separados por el carácter ‘#’ (ATRIBUTO#operador). El valor asociado a la variable será el valor indicado en la parte derecha de la condición. Si la consulta sólo incluye una condición de consulta para ese atributo, puede utilizarse también el nombre de variable ATRIBUTO, sin especificar operador. NOTA: La variables pueden fun ionar incorrectamente cuándo el wrapper reciba más de una condición de consultautilizando el mismo atributo y operador.



Las variables contenidas en el contexto de ejecución pueden utilizarse en las denominadas cadenas de interpolación. Una cadena de interpolación es una expresión en función de las variables del contexto de ejecución, que genera como resultado una cadena de caracteres. Una variable en una cadena de interpolación debe especificarse prefijada con el símbolo “@”, seguido del nombre de la variable, siempre que dicho nombre sea una cadena de caracteres alfanumérica (letras y los caracteres ‘#’ y ‘_’). Pueden especificarse variables cuyo nombre incluya cualquier otro carácter, aunque no sea alfanumérico, incluyendo el nombre entre los símbolos “@“ y ‘’. NOTA: Cuando en las partes constantes de la cadena de interpolación aparezca alguno los símbolos ‘@’, ‘\’, ‘^’, ‘‘, ‘’, deben ser escapados con el carácter ‘\’ (i.e. \@, \\, \^, \, \). Nótese que esto implica que al especificar rutas de tipo fichero local en Sistemas Operativos Windows es necesario escapar el carácter ‘\’ como ‘\\’. Considérense el siguiente ejemplo a efectos de obtener una idea intuitiva del funcionamiento de las cadenas de interpolación. Ejemplo: Supongamos que tenemos un servidor web que permite acceder a ciertos informes de los departamentos de una determinada empresa codificados en XML. La ruta para acceder al informe de cada departamento es la misma excepto por el nombre del fichero, que coincide con el nombre del departamento (e.g. http://examplesite.com/exampleroute/reports/DPT1.xml http://examplesite.com/exampleroute/reports/DPT2.xml ...). Supongamos ahora que deseamos construir una relación base de DataPort que nos permita acceder a dichos informes. Para ello deberemos crear un datasource de tipo XML (ver sección 17.3.4) y un wrapper de tipo XML (ver sección 17.4.7). Deseamos que esta relación base (a la que llamaremos DPT_REPORTS) contenga una tupla para cada departamento. Cada tupla tendrá dos atributos: DPT_NAME (de tipo text) y REPORT (que contendrá los datos del informe. Tipicamente este atributo será de un tipo compuesto DataPort. Ver sección 18.1). A la hora de crear el datasource para esta relación base, nos surge el problema de que el fichero de datos que debe accederse depende de a qué departamento se refiere la consulta efectuada. Para solucionar este problema podríamos especificar en el parámetro ROUTE una ruta http con una cadena de conexión como: http://examplesite.com/exampleroute/reports/@DPT_NAME.xml De esta forma, podríamos ejecutar consultas tales como: SELECT REPORT FROM DPT_REPORTS WHERE DPT_NAME = ‘DptName’ Y el sistema accedería transparentemente a los datos del fichero correspondiente al departamento especificado para contestar la consulta. Por ejemplo, para la consulta anterior la ruta accedida sería: http://examplesite.com/exampleroute/reports/DptName.xml Por último, cuando una variable de interpolación tiene como valor una lista de elementos (esto ocurre en los casos de operadores que permiten una lista de valores como operandos), el valor asociado a la variable será la concatenación de los elementos simples separados por el carácter ‘+’. Esto puede ser utilizado en la parametrización de ciertos aspectos de los wrappers ITPilot (ver sección 17.4.5).

http://examplesite.com/exampleroute/reports/DPT1.xml

http://examplesite.com/exampleroute/reports/DPT2.xml

http://examplesite.com/exampleroute/reports/@DPT_NAME.xml

http://examplesite.com/exampleroute/reports/DptName.xml


Apéndices 146

19 APÉNDICES

19.1 SINTAXIS DE EXPRESIONES DE BÚSQUEDA DEL OPERADOR CONTAINS

Esta sección describe la sintaxis de expresiones de búsqueda del operador contains de DataPort.

19.1.1 Términos y Frases exactas

Una consulta se compone de términos y operadores. Existen dos tipos de términos: Términos Individuales y Frases exactas. Un Término Individual es una única palabra. Una frase es un grupo de palabras entre comillas dobles. Los términos pueden combinarse entre sí mediante el uso de operadores Booleanos para formar consultas complejas (véase más abajo).

19.1.2 Modificadores de términos

Se admite el uso de los siguientes modificadores:

19.1.2.1 Comodines de búsqueda

El símbolo “?” sustituye el ? por un único carácter en la palabra. El símbolo “*” sustituye el * por 0 o más caracteres. Por ejemplo, si se desea buscar “información” o “informática”, se introduciría el siguiente término:

inform*

19.1.2.2 Búsquedas difusas (Fuzzy Searches)

Se permiten búsquedas difusas (las fuentes pueden implementar esta funcionalidad utilizando, por ejemplo, técnicas de distancia de edición de cadenas). Para realizar búsquedas difusas es necesario usar el símbolo "~" al final de un término sencillo. Por ejemplo, para buscar términos que se escriban de forma similar a "tarjeta" se usaría la siguiente búsqueda difusa:

Tarjeta~

Esta encontraría términos como “tarjta”. Se puede añadir un parámetro (opcional) que especifique la similitud mínima requerida. Por ejemplo:

tarjeta~0.8

19.1.2.3 Búsquedas por proximidad

Se permiten búsquedas de términos entre los que haya cierta cercanía espacial. Para realizarla se utiliza el símbolo "~" al final de una frase exacta. También se puede especificar el número máximo de palabras que pueden separar los


Apéndices 147

términos. Por ejemplo, para buscar "denodo" y "technologies" con una distancia de hasta 8 palabras en el mismo documento se utilizaría la búsqueda:

"denodo technologies"~8

19.1.2.4 Búsquedas por rango

Las búsquedas por rango permiten recuperar documentos cuyo/s valores se encuentren dentro de un rango determinado. El rango especificado puede incluír los límites inferior y superior o no. Los rangos inclusivos se especifican mediante corchetes y los exclusivos mediante llaves. La clasificación se lleva a cabo siguiendo el orden lexicográfico. Por ejemplo:

[20020101 TO 20030101]

Esta consulta encuentra los documentos cuyo valor posea valores entre 20020101 y 20030101, inclusive. La búsqueda por rango no está limitada a los campos que contengan fechas como valor:

Aida TO Carmen

Esta consulta recupera todos los documentos cuyos títulos se encuentren entre Aida y Carmen, no inclusive.

19.1.2.5 Aumento del nivel de relevancia de un término

Es posible aumentar el peso de un término de la búsqueda en el cálculo del nivel de relevancia utilizando el símbolo "^" con un factor de incremento (un número) al final del término de búsqueda. Cuanto más alto sea ese factor más relevante será ese término en la búsqueda. Esto permite controlar la relevancia de un documento aumentando el nivel de relevancia de sus términos. Por ejemplo, si se desea buscar

denodo technologies

y se desea que el témino "denodo" sea más relevante se utilizaría el símbolo ^ con un factor de aumento del nivel de relevancia al lado del término:

denodo^4 technologies

Con esto se consigue que los documentos en los que aparece el témino "denodo" resulten más relevantes para la búsqueda. Esta técnica también se puede utilizar con frases.


Apéndices 148

El factor de relevancia por defecto es 1. Debe ser un número positivo, pero puede ser menor que 1 (por ejemplo 0.2).

19.1.3 Operadores Booleanos

Los operadores Booleanos permiten combinar términos mediante operadores lógicos. Se admiten los siguientes operadores Booleanos: AND, OR, y NOT. (Nota: Los operadores Booleanos deben escribirse en mayúsculas).

19.1.4 Agrupaciones

Se permite el uso de paréntesis. Por ejemplo, para buscar "Corp" o "Inc" y "Denodo" se usaría la consulta: (Corp OR Inc) AND denodo

19.1.5 Escapar caracteres especiales

La lista de caracteres especiales es:

( ) [ ] ^ " ~ * ? : \ Para escapar estos caracteres se utiliza \ antes del carácter.

19.2 SOPORTE PARA EL OPERADOR CONTAINS DE CADA TIPO DE FUENTE

La sintaxis del lenguaje de búsqueda sobre información no estructurada utilizado con el operador contains se describe en la sección 19.1. Sin embargo, es necesario tener presente que las opciones de búsqueda disponible dependen de las capacidades proporcionadas nativamente por la fuente de datos. Por ejemplo, Google Mini no soporta diversas características del lenguaje de búsqueda como, por ejemplo, las búsquedas por proximidad. Por lo tanto, cuando se utilice el operador contains con atributos procedentes de fuentes Google Mini, dichas capacidades no estarán disponibles. Esta sección detalla con exactitud las capacidades de búsqueda soportadas para cada tipo de fuente. Estas capacidades se especifican también en las Propiedades de Configuración de cada fuente de datos (ver sección 17.3.10.1) consultables mediante la sentencia DESC VIEW (ver sección 13). En la actualidad, los tipos de fuente de datos que permiten el uso del operador contains son las fuentes de tipo Aracne (ver sección 17.3.6), Google Mini (ver sección 17.3.7) y Custom (ver sección 17.3.9). Las siguientes secciones describen, respectivamente las capacidades soportadas para los wrappers Aracne y Google Mini. Los wrappers de tipo Custom pueden especificar qué capacidades soportan a través de las Propiedades de Configuración (ver sección 17.3.10.1 y sección 17.4.11).

19.2.1 Aracne

Las siguientes características del lenguaje de búsqueda del operador contains no están soportadas en fuentes de tipo Denodo Aracne:

- Los comodines ? y * no pueden aparecer en la primera posición de un término. - Las búsquedas con el operador de proximidad ~ deben especificar obligatoriamente el número máximo de

palabras que pueden separar los términos de la frase.


Apéndices 149

- Para funcionar correctamente, el operador lógico NOT debe aparecer al mismo nivel que un operador lógico AND. Ejemplo: la búsqueda (term1 AND NOT term2) funcionaría correctamente, no así la búsqueda (term1 OR NOT term2).

El resto de capacidades del lenguaje de búsqueda están soportadas en fuentes de tipo Denodo Aracne.

19.2.2 Google Mini

Las siguientes características del lenguaje de búsqueda del operador contains no están soportadas en fuentes de tipo Google Mini:

- Las búsquedas por frase exacta no están soportadas en el atributo site. Sí lo están en el resto de atributos.

- Los comodines, las búsquedas difusas, las búsquedas por proximidad, las búsquedas con aumento de relevancia y las búsquedas por rango no están soportadas.

- Las búsquedas con los operadores lógicos AND, OR y NOT en los atributos title, url y site sólo son válidas si las condiciones son terminos simples o frases exactas (es decir, en las búsquedas sobre estos atributos no es posible anidar condiciones lógicas). Esta restricción no existe para el resto de atributos.

- Para funcionar correctamente, el operador lógico NOT debe aparecer al mismo nivel que un operador lógico AND. Ejemplo: la búsqueda (term1 AND NOT term2) funcionaría correctamente, no así la búsqueda (term1 OR NOT term2).


Apéndices 150

BIBLIOGRAFÍA

[1] Código de lenguaje ISO-639 (http://www.ics.uci.edu/pub/ietf/http/related/iso639.txt)

[2] Código de país ISO-3166 (http://www.chemie.fu-berlin.de/diverse/doc/ISO_3166.html)

[3] Guía del Administrador de Virtual DataPort 4.0. Denodo Technologies, 2007.

[4] Documentación Javadoc de la API del Desarrollador. DENODO_HOME/docs/vdp/api/index.html

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

[6] Manual de usuario de ITPilot 4.0. Denodo Technologies, 2007.

[7] Tabla de cambios de moneda del Banco Central Europeo http://www.ecb.int/home/eurofxref.htm

[8] Conversor de divisas on-line OANDA http://www.oanda.com

[9] Documentación Javadoc de la API estándar Java Developer Kit 1.4.2

[10] Microsoft Internet Explorer. http://www.microsoft.com/windows/ie/default.asp

[11] Expresiones regulares en JAVA. http://java.sun.com/j2se/1.4.2/docs/api/java util/regex/Pattern.html/

[12] Formatos de fecha JAVA. http://java.sun.com/j2se/1.4.2/docs/api/java text/SimpleDateFormat.html/

[13] XPath Language. http://www.w3.org/TR/xpath

[14] X/Open Company Ltd. Distributed Transaction Processing: The XA Specification. The Open Group, February 1992. [15] Apache Lucene, http://lucene.apache.org/

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

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

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

http://www.ics.uci.edu/pub/ietf/http/related/iso639.txt

http://www.chemie.fu-berlin.de/diverse/doc/ISO_3166.html

http://www.ecb.int/home/eurofxref.htm

http://www.oanda.com/

http://www.microsoft.com/windows/ie/default.asp

http://java.sun.com/j2se/1.4.2/docs/api/java/util/regex/Pattern.html

http://java.sun.com/j2se/1.4.2/docs/api/java/text/SimpleDateFormat.html

http://www.w3.org/TR/xpath

http://lucene.apache.org/

http://www.google.com/enterprise/mini/

VIRTUAL DATAPORT 4.0 GUÍA AVANZADA DE VQL · Virtual DataPort 4.0 Guía Avanzada de VQL 12.3.5...

Documents

Transcript of VIRTUAL DATAPORT 4.0 GUÍA AVANZADA DE VQL · Virtual DataPort 4.0 Guía Avanzada de VQL 12.3.5...