Guía Avanzada de VQL - Denodo Platform Help

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
2.2
VIRTUAL DATAPORT A VISTA DE PÁJARO....................................................................................... 3
CREACIÓN O DEFINICIÓN DE DATOS ................................................................................................ 3
Definición de relaciones base................................................................................................................... 3
Definición de datasources y wrappers ..................................................................................................... 5
Definición de las vistas del esquema global ............................................................................................ 6
EJECUCIÓN DE SENTENCIAS.............................................................................................................. 7
3.1
3.2
3.3
3.4
CARACTERÍSTICAS................................................................................................................................ 9
TIPOS DE DATOS ................................................................................................................................... 9
INTERNACIONALIZACIÓN.................................................................................................................. 10
CAPACIDADES DE CONSULTA.......................................................................................................... 11
REGLAS DE REESCRITURA................................................................................................................. 11
2.1
2.1.1
2.1.2
2.1.3
3
4
4.1
4.2
4.3
4.4
4.5
4.6
4.6.1
4.6.2
4.6.3
4.6.4
4.6.5
4.6.6
4.7
4.8
4.8.1
5
5.1
5.2
5.2.1
5.2.2
5.2.3
5.3
5.3.1
5.3.2
LENGUAJE DE DEFINICIÓN Y MANEJO DE DATOS: VQL ............................................................. 12
SENTENCIAS ........................................................................................................................................ 12
SENTENCIA SELECT: CLÁUSULAS.................................................................................................... 13
INSERT / UPDATE /DELETE: CLÁUSULAS........................................................................................ 13
OPERADORES LÓGICOS...................................................................................................................... 14
OPERADORES DE COMPARACIÓN ................................................................................................... 15
FUNCIONES DE ATRIBUTO DERIVADO Y CONDICIONES............................................................. 18
Funciones Aritméticas............................................................................................................................. 18
Funciones de Manejo de Texto............................................................................................................... 19
Funciones de Manejo de Fechas............................................................................................................. 21
Funciones de Conversión de Tipos.......................................................................................................... 22
Funciones de manejo de XML................................................................................................................. 23
Otras funciones ....................................................................................................................................... 24
FUNCIONES DE AGREGACIÓN .......................................................................................................... 25
CONVENCIONES DE SINTAXIS ......................................................................................................... 26
Sintaxis de funciones y valores de condiciones ..................................................................................... 28
CREACIÓN DE UNA RELACIÓN BASE (O VISTA BASE)................................................................. 30
MODIFICACIÓN DE UNA RELACIÓN BASE ..................................................................................... 30
CAPACIDADES DE CONSULTA: MÉTODOS DE BÚSQUEDA Y WRAPPERS............................... 32
Restricciones de Consulta....................................................................................................................... 32
Asignación de Wrappers a Métodos de Búsqueda ................................................................................ 33
Ejemplo de Creación de un Método de Búsqueda.................................................................................. 33
REGLAS DE REESCRITURA................................................................................................................. 34
Reglas de Reescritura de Entrada........................................................................................................... 34
Reglas de Reescritura de Salida............................................................................................................. 37
Virtual DataPort 4.0
6
6.1
6.1.1
6.1.2
6.2
6.2.1
6.3
6.3.1
6.4
6.4.1
6.5
6.6
6.6.1
6.7
6.8
6.9
7
7.1
7.1.1
8
8.1
8.2
8.3
8.4
9
Guía Avanzada de VQL
CONSULTAS: SENTENCIA SELECT ................................................................................................... 39
CLÁUSULA FROM................................................................................................................................. 41
Operaciones de join ................................................................................................................................ 41
FLATTEN VIEW (Aplanando estructuras de datos) ................................................................................. 42
CLÁUSULA SELECT.............................................................................................................................. 43
Atributos Derivados ................................................................................................................................ 44
CLÁUSULA WHERE.............................................................................................................................. 44
Condiciones con valores compuestos..................................................................................................... 45
CLÁUSULA GROUP BY ........................................................................................................................ 45
Uso de Funciones de Agregación............................................................................................................ 46
CLÁUSULA HAVING............................................................................................................................. 46
CLÁUSULA UNION............................................................................................................................... 47
Especificación de proyecciones en consultas UNION ............................................................................ 47
CLÁUSULA ORDER BY......................................................................................................................... 47
CLÁUSULA CONTEXT .......................................................................................................................... 48
CLÁUSULA TRACE ............................................................................................................................... 49
DEFINICIÓN DE UNA VISTA DERIVADA .......................................................................................... 52
MODIFICACIÓN DE UNA VISTA DERIVADA.................................................................................... 53
Reglas de Reescritura Sobre Vistas Derivadas ...................................................................................... 54
INSERCIONES, ACTUALIZACIONES Y BORRADOS SOBRE VISTAS ........................................... 56
SENTENCIA INSERT ............................................................................................................................ 56
SENTENCIA UPDATE........................................................................................................................... 57
SENTENCIA DELETE ............................................................................................................................ 58
USO DE WITH CHECK OPTION .......................................................................................................... 58
TRANSACCIONES EN DATAPORT .................................................................................................... 60
10
10.1
10.2
10.3
10.4
PROCEDIMIENTOS ALMACENADOS................................................................................................ 61
IMPORTACIÓN DE UN PROCEDIMIENTO ALMACENADO............................................................ 61
USO DE PROCEDIMIENTOS ALMACENADOS................................................................................. 61
CREACIÓN DE NUEVOS PROCEDIMIENTOS ALMACENADOS .................................................... 62
PROCEDIMIENTOS PREDEFINIDOS.................................................................................................. 64
11.1
11.2
DEFINICIÓN DE OTROS ELEMENTOS DEL CATÁLOGO ................................................................. 65
DEFINICIÓN DE UN TIPO DE DATO................................................................................................... 65
DEFINICIÓN DE UN MAPA ................................................................................................................. 66
12.1
12.2
12.2.1
12.2.2
12.3
12.3.1
12.3.2
12.3.3
12.3.4
CREACIÓN DE BASES DE DATOS, USUARIOS Y PERMISOS ....................................................... 68
BASES DE DATOS EN VIRTUAL DATAPORT ................................................................................... 68
ESTRUCTURA DE USUARIOS Y PERMISOS EN VIRTUAL DATAPORT........................................ 68
Tipos de usuarios .................................................................................................................................... 68
Tipos de permisos ................................................................................................................................... 68
SENTENCIAS VQL DE BASES DE DATOS, USUARIOS Y PERMISOS .......................................... 70
Creación de Bases de Datos ................................................................................................................... 70
Modificación y Borrado de Bases de Datos............................................................................................ 70
Creación de usuarios............................................................................................................................... 71
Modificación y Borrado de usuarios ....................................................................................................... 72
11
12
Virtual DataPort 4.0
Guía Avanzada de VQL
12.3.5 Cambio de Base de Datos Activa............................................................................................................ 72
12.3.6 Modificación de los privilegios de un usuario........................................................................................ 73
13
13.1
DESCRIPCIÓN DE ELEMENTOS DEL CATÁLOGO ........................................................................... 76
EXPORTACIÓN DE METADATOS....................................................................................................... 77
14
LISTADO DE ELEMENTOS DEL CATÁLOGO..................................................................................... 78
15
ELIMINACIÓN DE ELEMENTOS DEL CATÁLOGO ........................................................................... 80
16
16.1
16.2
OTROS COMANDOS ............................................................................................................................ 82
BORRADO DE ENTRADAS DE LA CACHÉ DEL DICCIONARIO DE DATOS .................................. 82
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
GESTIÓN DE VALORES DE TIPOS COMPUESTOS........................................................................ 130
Manejo de Tipos Compuestos: Ejemplo ............................................................................................... 131
OPTIMIZACIÓN DE CONSULTAS .................................................................................................... 135
Optimización de Operaciones de join ................................................................................................... 135
Uso de la Cache .................................................................................................................................... 139
Configuración de Políticas de “Swapping”........................................................................................... 140
18.1
18.1.1
18.2
18.2.1
18.2.2
18.2.3
Virtual DataPort 4.0
Guía Avanzada de VQL
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
19.1
19.1.1
19.1.2
19.1.3
19.1.4
19.1.5
19.2
19.2.1
19.2.2
APÉNDICES......................................................................................................................................... 146
SINTAXIS DE EXPRESIONES DE BÚSQUEDA DEL OPERADOR CONTAINS ............................ 146
Términos y Frases exactas.................................................................................................................... 146
Modificadores de términos................................................................................................................... 146
Operadores Booleanos.......................................................................................................................... 148
Agrupaciones ........................................................................................................................................ 148
Escapar caracteres especiales.............................................................................................................. 148
SOPORTE PARA EL OPERADOR CONTAINS DE CADA TIPO DE FUENTE................................. 148
Aracne ................................................................................................................................................... 148
Google Mini........................................................................................................................................... 149
BIBLIOGRAFÍA ............................................................................................................................................................. 150
Virtual DataPort 4.0
Guía Avanzada de VQL
ÍNDICE DE FIGURAS
Figura 1
Figura 2
Figura 3
Figura 4
Figura 5
Figura 6
Figura 7
Figura 8
Figura 9
Figura 10
Figura 11
Figura 12
Figura 13
Figura 14
Figura 15
Figura 16
Figura 17
Figura 18
Figura 19
Figura 20
Figura 21
Figura 22
Figura 23
Figura 24
Figura 25
Figura 26
Figura 27
Figura 28
Figura 29
Figura 30
Figura 31
Figura 32
Figura 33
Figura 34
Figura 35
Figura 36
Figura 37
Figura 38
Figura 39
Figura 40
Figura 41
Figura 42
Figura 43
Figura 44
Figura 45
Figura 46
Figura 47
Figura 48
Figura 49
Figura 50
Figura 51
Figura 52
Formulario de búsqueda para una tienda de libros .................................................................................. 5
Método de búsqueda para una tienda de libros....................................................................................... 5
Primitivas básicas para la especificación de sentencias VQL................................................................ 28
Reglas para la formación de funciones .................................................................................................. 29
Sintaxis de la sentencia CREATE TABLE ........................................................................................ 30
Ejemplo de creación de una vista base .................................................................................................. 30
Sintaxis de la sentencia ALTER TABLE ........................................................................................... 32
Ejemplo de creación de un método de búsqueda con ALTER TABLE ............................................. 33
Adición de una regla de reescritura de entrada REGEXP() .............................................................. 36
Adición de una regla de reescritura sobre condiciones MAP()........................................................... 36
Adición de una regla de reescritura de entrada CHANGEOPERATOR()......................................... 37
Adición de una regla de reescritura de salida con la función MAP().................................................. 38
Sintaxis de la sentencia SELECT......................................................................................................... 40
Sintaxis de una FLATTEN view ............................................................................................................... 43
Sintaxis para una condición.................................................................................................................... 44
Sintaxis para una proyección sobre el resultado de una unión.............................................................. 47
Sintaxis de la cláusula CONTEXT ........................................................................................................ 49
Traza de ejecución .................................................................................................................................. 51
Sintaxis de la sentencia CREATE VIEW ........................................................................................... 52
Ejemplo de definición de una vista en función de otras......................................................................... 53
Sintaxis de la sentencia ALTER VIEW.............................................................................................. 54
Adición de una regla de reescritura de entrada sobre vista derivada ................................................... 55
Borrado de una regla de reescritura de salida de una vista no base..................................................... 55
Adición de una reescritura sobre resultados en una vista derivada ...................................................... 55
Sintaxis de la sentencia INSERT......................................................................................................... 56
Sintaxis de la sentencia UPDATE......................................................................................................... 57
Sintaxis de la sentencia DELETE......................................................................................................... 58
Sintaxis de CREATE PROCEDURE .................................................................................................. 61
Sintaxis de ALTER PROCEDURE ..................................................................................................... 61
Sintaxis de la sentencia CALL .............................................................................................................. 61
Sintaxis de la sentencia CREATE TYPE ........................................................................................... 65
Creación de un tipo de dato enumerated ............................................................................................... 65
Creación de un tipo de dato register ...................................................................................................... 66
Creación de un tipo de dato array y del tipo register que contiene ...................................................... 66
Sintaxis de la sentencia CREATE MAP.............................................................................................. 66
Creación de un mapa de tipo inputrewrite ............................................................................................. 67
Sintaxis de la sentencia CREATE DATABASE ................................................................................ 70
Sintaxis de la sentencia ALTER DATABASE ................................................................................... 71
Sintaxis de la sentencia CREATE USER ........................................................................................... 72
Sintaxis de la sentencia ALTER USER.............................................................................................. 72
Sintaxis de las sentencias CONNECT y CLOSE ................................................................................. 73
Sintaxis de las cláusulas GRANT/REVOKE para Bases de Datos...................................................... 73
Sintaxis de las cláusulas GRANT/REVOKE para Bases de Datos...................................................... 74
Sintaxis de las cláusulas GRANT/REVOKE para vistas...................................................................... 75
Ejemplo de asignación de privilegios a usuarios.................................................................................... 75
Sintaxis de la sentencia DESC .............................................................................................................. 76
Sintaxis de la sentencia LIST .............................................................................................................. 78
Sintaxis de la sentencia DROP .............................................................................................................. 80
Sintaxis de la sentencia CLEAR CACHE ........................................................................................... 82
Sintaxis de la sentencia HELP .............................................................................................................. 83
Sentencia que solicita ayuda sobre el comando ALTER TABLE ..................................................... 83
Sintaxis de la sentencia de creación de un datasource JDBC ............................................................... 92
Virtual DataPort 4.0
Figura 53
Figura 54
Figura 55
Figura 56
Figura 57
Figura 58
Figura 59
Figura 60
Figura 61
Figura 62
Figura 63
Figura 64
Figura 65
Figura 66
Figura 67
Figura 68
Figura 69
Figura 70
Figura 71
Figura 72
Figura 73
Figura 74
Figura 75
Figura 76
Figura 77
Figura 78
Figura 79
Figura 80
Figura 81
Figura 82
Figura 83
Figura 84
Figura 85
Figura 86
Figura 87
Figura 88
Figura 89
Figura 90
Figura 91
Figura 92
Figura 93
Figura 94
Figura 95
Figura 96
Figura 97
Figura 98
Figura 99
Figura 100
Figura 101
Figura 102
Figura 103
Figura 104
Figura 105
Guía Avanzada de VQL
Sintaxis de la sentencia de modificación de un datasource JDBC ........................................................ 93
Sintaxis de la sentencia de creación de un datasource ODBC............................................................... 95
Sintaxis de la sentencia de modificación de un datasource ODBC........................................................ 95
Sintaxis de la sentencia de creación de un datasource WS. ................................................................. 95
Sintaxis de la sentencia de modificación de un datasource WS. .......................................................... 95
Sintaxis de la sentencia de creación de un datasource XML................................................................. 96
Sintaxis de la sentencia de modificación de un datasource XML.......................................................... 96
Sintaxis de la sentencia de creación de un datasource DF.................................................................... 97
Sintaxis de la sentencia de modificación de un datasource DF............................................................. 98
Sintaxis de la sentencia de creación de un datasource Aracne............................................................. 98
Sintaxis de la sentencia de modificación de un datasource Aracne...................................................... 98
Sintaxis de la sentencia de creación de un datasource Google Mini .................................................... 98
Sintaxis de la sentencia de modificación de un datasource Google Mini ............................................. 99
Sintaxis de la sentencia de creación de un datasource LDAP ............................................................... 99
Sintaxis de la sentencia de modificación de un datasource LDAP ........................................................ 99
Sintaxis de la sentencia de creación de un datasource Custom.......................................................... 100
Sintaxis de la sentencia de modificación de un datasource Custom................................................... 100
Ejemplo de modificación de configuración de un datasource. ............................................................. 103
Sintaxis de creación de un wrapper JDBC ........................................................................................... 106
Sintaxis de modificación de un wrapper JDBC .................................................................................... 107
Sintaxis de creación de un wrapper ODBC........................................................................................... 108
Sintaxis de modificación de un wrapper ODBC.................................................................................... 109
Sintaxis de creación de un wrapper de tipo ITPilot.............................................................................. 110
Sintaxis de modificación de un wrapper de tipo ITPilot....................................................................... 110
Ejemplo de wrapper ITPIlot 4.0............................................................................................................. 111
Ejemplo de creación de un wrapper ITPilot ......................................................................................... 112
Sintaxis de creación de un wrapper de servicios Web ........................................................................ 113
Sintaxis de modificación de un wrapper de servicios Web ................................................................. 113
Sintaxis de creación de un wrapper XML............................................................................................ 115
Sintaxis de modificación de un wrapper XML..................................................................................... 115
Sintaxis de creación de un wrapper DF ............................................................................................... 116
Sintaxis de modificación de un wrapper DF ........................................................................................ 117
Sintaxis de creación de un wrapper Denodo Aracne .......................................................................... 118
Ejemplo de creación de un wrapper Denodo Aracne ........................................................................... 119
Sintaxis de modificación de un wrapper Denodo Aracne ................................................................... 120
Sintaxis de creación de un wrapper Google Mini ............................................................................... 122
Ejemplo de creación de un wrapper Google Mini ................................................................................ 122
Sintaxis de modificación de un wrapper Google Mini ........................................................................ 123
Sintaxis de creación de un wrapper tipo CUSTOM .............................................................................. 126
Ejemplo de creación de un wrapper CUSTOM ..................................................................................... 126
Sintaxis de modificación de un wrapper tipo CUSTOM ....................................................................... 126
Ejemplo de configuración de un Wrapper CUSTOM ............................................................................ 128
Sintaxis de las sentencias de consulta de wrappers ........................................................................... 128
Sintaxis de la sentencias de consulta de wrappers ITPilot.................................................................. 129
Árboles de tipos compuestos................................................................................................................ 132
Tupla con elementos compuestos ........................................................................................................ 133
Árbol de valores de tipos compuestos.................................................................................................. 133
Creación de una relación base con tipos compuestos ......................................................................... 133
Creando un método de búsqueda con tipos compuestos..................................................................... 134
Adición de un método de búsqueda con tipos compuestos ................................................................. 134
Sintaxis de QUERYPLAN ................................................................................................................... 137
Árbol de definición de la vista V5........................................................................................................ 138
Internacionalización es_euro................................................................................................................ 144
Virtual DataPort 4.0
Guía Avanzada de VQL
ÍNDICE DE TABLAS
Tabla 1
Tabla 2
Tabla 3
Tabla 4
Tabla 5
Tabla 6
Tabla 7
Tabla 8
Conversiones de tipos permitidas con la función CAST ....................................................................... 23
Conversiones automáticas entre tipos JAVA y tipos Virtual DataPort .................................................. 85
Otras conversiones válidas entre tipos JAVA y tipos Virtual DataPort.................................................. 85
Conversiones de tipos JDBC................................................................................................................... 86
Conversiones de tipos ITPilot.................................................................................................................. 87
Conversiones de tipos de Web Services ................................................................................................ 87
Conversiones de tipos XML .................................................................................................................... 88
Caracteres reservados para el formato de una fecha .......................................................................... 143
Virtual DataPort 4.0
Guía Avanzada de VQL
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.
Prefacio
i
Virtual DataPort 4.0
1
Guía Avanzada de VQL
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.
Introducción
2
Virtual DataPort 4.0
2
Guía Avanzada de VQL
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 relació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.
Virtual Dataport a Vista de Pájaro
3
Virtual DataPort 4.0
Guía Avanzada de VQL
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 5upla 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.
Virtual Dataport a Vista de Pájaro
4
Virtual DataPort 4.0
Guía Avanzada de VQL
Figura 1 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, {})
Figura 2 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
Virtual Dataport a Vista de Pájaro
5
Virtual DataPort 4.0
Guía Avanzada de VQL
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
Virtual Dataport a Vista de Pájaro
6
Virtual DataPort 4.0
•
•
•
Guía Avanzada de VQL
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 Planes 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.
Virtual Dataport a Vista de Pájaro
7
Virtual DataPort 4.0
Guía Avanzada de VQL
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.
Virtual Dataport a Vista de Pájaro
8
Virtual DataPort 4.0
3
Guía Avanzada de VQL
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
9
Virtual DataPort 4.0
•
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).
Guía Avanzada de VQL
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
10
Virtual DataPort 4.0
3.3
Guía Avanzada de VQL
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.
Características
11
Virtual DataPort 4.0
4
Guía Avanzada de VQL
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.
Lenguaje de Definición y Manejo de Datos: VQL
12
Virtual DataPort 4.0
4.2
Guía Avanzada de VQL
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.
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:
4.3
•
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.
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:
Lenguaje de Definición y Manejo de Datos: VQL
13
Virtual DataPort 4.0
Guía Avanzada de VQL
•
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.
Lenguaje de Definición y Manejo de Datos: VQL
14
Virtual DataPort 4.0
4.5
Guía Avanzada de VQL
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.
Lenguaje de Definición y Manejo de Datos: VQL
15
Virtual DataPort 4.0
Guía Avanzada de VQL
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).
Lenguaje de Definición y Manejo de Datos: VQL
16
Virtual DataPort 4.0
•
Guía Avanzada de VQL
‘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
('B78596011','B78596012')
WHERE
taxid
in
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.
Lenguaje de Definición y Manejo de Datos: VQL
17
Virtual DataPort 4.0
4.6
Guía Avanzada de VQL
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 ‘/’.
Lenguaje de Definición y Manejo de Datos: VQL
18
Virtual DataPort 4.0
Guía Avanzada de VQL
•
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).
Lenguaje de Definición y Manejo de Datos: VQL
19
Virtual DataPort 4.0
Guía Avanzada de VQL
•
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
internet_inc
(summary,'test')
AS
new_summary
FROM
•
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.
Lenguaje de Definición y Manejo de Datos: VQL
20
Virtual DataPort 4.0
Guía Avanzada de VQL
•
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.
Lenguaje de Definición y Manejo de Datos: VQL
21
Virtual DataPort 4.0
Guía Avanzada de VQL
•
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
array
blob
boolean
date
double
enumerated
float
int
link
long
Lenguaje de Definición y Manejo de Datos: VQL
Tipos Origen
array
text, blob
text, int, long, float, double, boolean
text, date, long
text, int, long, float, double, time, money
text, enumerated
text, int, long, float, double, time, money
text, int, long, float, double, time, money
text, link
text, int, long, float, double, time, money, date
22
Virtual DataPort 4.0
money
register
text
Guía Avanzada de VQL
text, int, long, float, double, money
xml, register
text, int, long, float, double, boolean, date, time, xml,
money, link, blob, enumerated, register, array
text, long, int, time
text, xml
Time
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
Lenguaje de Definición y Manejo de Datos: VQL
23
Virtual DataPort 4.0
Guía Avanzada de VQL
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:
Lenguaje de Definición y Manejo de Datos: VQL
24
Virtual DataPort 4.0
4.7
Guía Avanzada de VQL
•
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.
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.
Lenguaje de Definición y Manejo de Datos: VQL
25
Virtual DataPort 4.0
Guía Avanzada de VQL
•
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.
Lenguaje de Definición y Manejo de Datos: VQL
26
Virtual DataPort 4.0
Guía Avanzada de VQL
•
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”.
Lenguaje de Definición y Manejo de Datos: VQL
27
Virtual DataPort 4.0
Guía Avanzada de VQL
<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>
Lenguaje de Definición y Manejo de Datos: VQL
28
Virtual DataPort 4.0
Guía Avanzada de VQL
| <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.
Lenguaje de Definición y Manejo de Datos: VQL
29
Virtual DataPort 4.0
5
Guía Avanzada de VQL
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”,
Creación de una Relación Base (o Vista Base)
30
Virtual DataPort 4.0
Guía Avanzada de VQL
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>
Creación de una Relación Base (o Vista Base)
31
Virtual DataPort 4.0
Guía Avanzada de VQL
[ ( <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.
Creación de una Relación Base (o Vista Base)
32
Virtual DataPort 4.0
Guía Avanzada de VQL
•
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 5upla 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
Creación de una Relación Base (o Vista Base)
33
Virtual DataPort 4.0
Guía Avanzada de VQL
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 Reescritura 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
Creación de una Relación Base (o Vista Base)
34
Virtual DataPort 4.0
Guía Avanzada de VQL
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
)
Creación de una Relación Base (o Vista Base)
35
Virtual DataPort 4.0
Guía Avanzada de VQL
);
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.
Creación de una Relación Base (o Vista Base)
36
Virtual DataPort 4.0
Guía Avanzada de VQL
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
Creación de una Relación Base (o Vista Base)
37
Virtual DataPort 4.0
Guía Avanzada de VQL
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).
Creación de una Relación Base (o Vista Base)
38
Virtual DataPort 4.0
6
Guía Avanzada de VQL
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>]* )
Consultas: Sentencia SELECT
39
Virtual DataPort 4.0
Guía Avanzada de VQL
| <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
Consultas: Sentencia SELECT
40
Virtual DataPort 4.0
6.1
Guía Avanzada de VQL
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)
Consultas: Sentencia SELECT
41
Virtual DataPort 4.0
•
Guía Avanzada de VQL
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:
Consultas: Sentencia SELECT
42
Virtual DataPort 4.0
-
-
Guía Avanzada de VQL
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.
Consultas: Sentencia SELECT
43
Virtual DataPort 4.0
Guía Avanzada de VQL
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.
Consultas: Sentencia SELECT
44
Virtual DataPort 4.0
Guía Avanzada de VQL
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
Consultas: Sentencia SELECT
45
Virtual DataPort 4.0
Guía Avanzada de VQL
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
Consultas: Sentencia SELECT
46
Virtual DataPort 4.0
6.6
Guía Avanzada de VQL
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).
Consultas: Sentencia SELECT
47
Virtual DataPort 4.0
6.8
Guía Avanzada de VQL
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.
•
SwapSize: 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> ::=
Consultas: Sentencia SELECT
48
Virtual DataPort 4.0
|
Guía Avanzada de VQL
<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.
Consultas: Sentencia SELECT
49
Virtual DataPort 4.0
o
•
Guía Avanzada de VQL
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_FIELD2]
search conditions = []
filter conditions = []
numOfFilteredTuples = 0
numOfDuplicatedTuples = 0
numOfSwappedTuples = 0
swapping = false
inputRewriteFunctions = false
outputRewriteFunctions = false
inputRawRewriteFunctions = false
outputRawRewriteFunctions = false
SPECIFIC_FIELD1,
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
)
Consultas: Sentencia SELECT
50
Virtual DataPort 4.0
Guía Avanzada de VQL
)
)
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.
Consultas: Sentencia SELECT
51
Virtual DataPort 4.0
7
Guía Avanzada de VQL
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.
Definición de una Vista Derivada
52
Virtual DataPort 4.0
Guía Avanzada de VQL
G
I∪
A
R
B
Figura 20 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> ::=
Definición de una Vista Derivada
53
Virtual DataPort 4.0
Guía Avanzada de VQL
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,
Definición de una Vista Derivada
54
Virtual DataPort 4.0
•
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.
Guía Avanzada de VQL
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
Definición de una Vista Derivada
55
Virtual DataPort 4.0
8
Guía Avanzada de VQL
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:
8.1
•
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.
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:
Inserciones, Actualizaciones Y Borrados sobre Vistas
56
Virtual DataPort 4.0
INSERT
INTO
internet_inc
(iinc_id,
summary,
specific_field1, specific_field2)
VALUES (6,"Error in ADSL Router", "31-mar-2005
"B78596015", "5", "6")
Guía Avanzada de VQL
ttime,
22h
35m
taxid,
24s",
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
Inserciones, Actualizaciones Y Borrados sobre Vistas
57
Virtual DataPort 4.0
Guía Avanzada de VQL
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.
Inserciones, Actualizaciones Y Borrados sobre Vistas
58
Virtual DataPort 4.0
Guía Avanzada de VQL
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.
Inserciones, Actualizaciones Y Borrados sobre Vistas
59
Virtual DataPort 4.0
9
Guía Avanzada de VQL
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).
Transacciones en DataPort
60
Virtual DataPort 4.0
10
Guía Avanzada de VQL
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
Procedimientos Almacenados
61
Virtual DataPort 4.0
Guía Avanzada de VQL
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
executeUpdate),
o
Obtener referencias a otros procedimientos
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),
Procedimientos Almacenados
sobre
el
servidor
DataPort
(métodos
almacenados
del
executeQuery,
servidor
(método
62
Virtual DataPort 4.0
o
Guía Avanzada de VQL
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.
Procedimientos Almacenados
63
Virtual DataPort 4.0
•
Guía Avanzada de VQL
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.
Procedimientos Almacenados
64
Virtual DataPort 4.0
11
11.1
Guía Avanzada de VQL
DEFINICIÓN DE OTROS ELEMENTOS DEL CATÁLOGO
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
);
Definición de Otros Elementos del Catálogo
65
Virtual DataPort 4.0
Guía Avanzada de VQL
Figura 33 Creación de un tipo de dato register
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 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().
•
outputrewrite. 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 clavevalor 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'”
Definición de Otros Elementos del Catálogo
66
Virtual DataPort 4.0
Guía Avanzada de VQL
'viernes' = ”TIMETABLE = 'Friday'”
'sabado' = ”TIMETABLE = 'Saturday'”
'domingo' = ”TIMETABLE = 'Sunday'”
);
Figura 36 Creación de un mapa de tipo inputrewrite
Definición de Otros Elementos del Catálogo
67
Virtual DataPort 4.0
12
Guía Avanzada de VQL
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
Creación de Bases de Datos, Usuarios y Permisos
68
Virtual DataPort 4.0
o
o
Guía Avanzada de VQL
LIST podrá ejecutase pero sólo mostrará el conjunto de vistas y procedimientos sobre las que
el usuario tiene permisos de lectura.
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).
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).
Creación de Bases de Datos, Usuarios y Permisos
69
Virtual DataPort 4.0
Guía Avanzada de VQL
•
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
contraseña es también admin.
admin
y su
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
Creación de Bases de Datos, Usuarios y Permisos
70
Virtual DataPort 4.0
Guía Avanzada de VQL
{ 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>]
Creación de Bases de Datos, Usuarios y Permisos
71
Virtual DataPort 4.0
Guía Avanzada de VQL
[ <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
Creación de Bases de Datos, Usuarios y Permisos
72
Virtual DataPort 4.0
Guía Avanzada de VQL
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.
Creación de Bases de Datos, Usuarios y Permisos
73
Virtual DataPort 4.0
Guía Avanzada de VQL
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
Creación de Bases de Datos, Usuarios y Permisos
74
Virtual DataPort 4.0
Guía Avanzada de VQL
<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
Creación de Bases de Datos, Usuarios y Permisos
75
Virtual DataPort 4.0
13
Guía Avanzada de VQL
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
{
<name:identifier>
I18N
|
INPUTREWRITE
|
OUTPUTREWRITE
|
SIMPLE
}
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
76
Virtual DataPort 4.0
-
Guía Avanzada de VQL
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.
Descripción de Elementos del Catálogo
77
Virtual DataPort 4.0
14
Guía Avanzada de VQL
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 outputrewrite .
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
78
Virtual DataPort 4.0
Guía Avanzada de VQL
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;
Listado de Elementos del Catálogo
79
Virtual DataPort 4.0
15
Guía Avanzada de VQL
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 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,
outputrewrite) 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
80
Virtual DataPort 4.0
Guía Avanzada de VQL
Y para eliminar el mapa tipo i18n es_euro se utilizaría la sentencia:
DROP MAP I18N es_euro;
Eliminación de Elementos del Catálogo
81
Virtual DataPort 4.0
16
16.1
Guía Avanzada de VQL
OTROS COMANDOS
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
| ALTER
XML }
| ALTER
| ALTER
Otros Comandos
DATABASE
DATASOURCE { ARN | CUSTOM | DF | GS | JDBC | LDAP | ODBC | WS |
PROCEDURE
TABLE
82
Virtual DataPort 4.0
Guía Avanzada de VQL
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
ALTER USER
ALTER WRAPPER { ARN | CUSTOM | DF | GS | ITP | JDBC | ODBC | WS | XML }
BEGIN
CALL
CLEAR CACHE
CLOSE
COMMIT
CONNECT
CREATE DATABASE
CREATE MAP
CREATE PROCEDURE
CREATE TABLE
CREATE TYPE
CREATE USER
CREATE VIEW
CREATE WRAPPER { ARN | CUSTOM | DF | GS | ITP | JDBC | ODBC | WS | XML
|
XML }
|
|
|
|
|
|
|
XML }
|
|
|
|
CREATE DATASOURCE { ARN | CUSTOM | DF | GS | JDBC | LDAP | ODBC | WS |
}
DELETE
DESC
DROP
HELP HELP
INSERT
LIST
QUERY WRAPPER { ARN | CUSTOM | DF | GS | ITP | JDBC | MY | ODBC | WS |
ROLLBACK
SELECT
UPDATE
XML2BIN
Figura 50 Sintaxis de la sentencia HELP
HELP ALTER TABLE
Figura 51 Sentencia que solicita ayuda sobre el comando ALTER TABLE
Es posible obtener información detallada respecto a la sintaxis general VQL utilizando la sentencia HELP HELP.
Otros Comandos
83
Virtual DataPort 4.0
17
Guía Avanzada de VQL
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.
Generación de Wrappers y DataSources
84
Virtual DataPort 4.0
Guía Avanzada de VQL
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
int, java.lang.Short, java.lang.Integer
long, java.lang.Long
float, java.lang.Float
double, java.lang.Double
boolean, java.lang.Boolean
java.lang.String
java.util.Date, java.util.Calendar,
java.sql.Date, java.sql.Timestamp, java.sql.Time
byte[], java.sql.Blob
Tabla 2
Tipos Virtual DataPort
int
long
float
double
boolean
text
date
blob
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
long, java.lang.Long
java.lang.String
java.lang.String
java.lang.String
double, java.lang.Double
Tabla 3
Tipos Virtual DataPort
time
enumerated
link
xml
money
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.
Generación de Wrappers y DataSources
85
Virtual DataPort 4.0
Guía Avanzada de VQL
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
ARRAY
BIGINT
BINARY
BIT
BLOB
BOOLEAN
CHAR
CLOB
DATALINK
DATE
DECIMAL
DISTINCT
DOUBLE
FLOAT
INTEGER
JAVA_OBJECT
LONGVARBINARY
LONGVARCHAR
NULL
NUMERIC
OTHER
REAL
REF
SMALLINT
STRUCT
TIME
TIMESTAMP
TINYINT
VARBINARY
VARCHAR
Tipos Java
Clase propietaria JDBCArrayTypeVO
java.lang.Long
java.lang.String
java.lang.Boolean
byte []
java.lang.Boolean
java.lang.String
java.lang.String
java.lang.String
java.sql.Date
java.lang.Double
java.lang.String
java.lang.Double
java.lang.Float
java.lang.Integer
java.lang.String
java.lang.String
java.lang.String
java.lang.String
java.lang.Double
JDBCRegisterTypeVO
java.lang.Float
java.lang.String
java.lang.Short
JDBCRegisterTypeVO
java.sql.Time
java.sql.Timestamp
java.lang.Byte
java.lang.String
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
boolean
date
Generación de Wrappers y DataSources
Tipos Java
boolean
java.util.Calendar
86
Virtual DataPort 4.0
double
float
int
string
url
Guía Avanzada de VQL
double
float
int
java.lang.String
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
xsd:base64Binary
xsd:boolean
xsd:byte
xsd:dateTime
xsd:decimal
xsd:double
xsd:float
xsd:hexBinary
xsd:int
xsd:integer
xsd:long
xsd:QName
Tipos Java
byte[]
boolean
byte
java.util.Calendar
java.math.BigDecimal
double
float
byte[]
int
java.math.BigInteger
long
java.lang.String con formato
"{namespace}localPart"
short
java.lang.String
xsd:short
xsd: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
Positiveinteger
negativeinteger
nonpositiveinteger
nonnegativeinteger
int
unsignedint
gYear
gMonth
gDay
long
unsignedlong
Generación de Wrappers y DataSources
Tipos Java
java.lang.Integer
java.lang.Long
87
Virtual DataPort 4.0
byte
unsignedbyte
Double
Float
short
unsignedshort
Boolean
string
normalizedString
token
base64Binary
hexBinary
duration
dateTime
date
time
gYearMonth
gMonthDay
java.lang.Byte
java.lang.Double
java.lang.Float
java.lang.Short
java.lang.Boolean
java.lang.String
Tabla 7
17.1.1.6
Guía Avanzada de VQL
Conversiones de tipos XML
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:
Generación de Wrappers y DataSources
88
Virtual DataPort 4.0
•
•
Guía Avanzada de 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).
Generación de Wrappers y DataSources
89
Virtual DataPort 4.0
17.3
o
Identificador del usuario que debe ser utilizado para el acceso, y
o
Contraseña para ese usuario.
Guía Avanzada de VQL
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.
Generación de Wrappers y DataSources
90
Virtual DataPort 4.0
Guía Avanzada de VQL
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 }
Generación de Wrappers y DataSources
91
Virtual DataPort 4.0
Guía Avanzada de VQL
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
DELEGATELEFTLITERAL = { true | false | DEFAULT }
DELEGATENATURALOUTERJOIN = { true | false | DEFAULT }
DELEGATENOTCONDITION = { true | false | DEFAULT }
DELEGATEORCONDITION = { true | false | DEFAULT }
DELEGATEORDERBY = { true | false | DEFAULT }
DELEGATEPROJECTION = { true | false | DEFAULT }
DELEGATEREGISTERLITERAL = { true | false | DEFAULT }
DELEGATERIGHTFIELD = { true | false | DEFAULT }
DELEGATERIGHTFUNCTION = { true | false | DEFAULT }
DELEGATERIGHTLITERAL = { true | false | DEFAULT }
DELEGATESELECTION = { true | false | DEFAULT }
DELEGATEUNION = { true | false | DEFAULT }
SUPPORTSAGGREGATEFUNCTIONSOPTIONS = { true | false | DEFAULT }
SUPPORTSBRANCHOUTERJOIN = { true | false | DEFAULT }
SUPPORTSEQOUTERJOINOPERATOR = { true | false | DEFAULT }
SUPPORTSEXPLICITCROSSJOIN = { true | false | DEFAULT }
SUPPORTSFULLEQOUTERJOIN = { true | false | DEFAULT }
SUPPORTSFULLNOTEQOUTERJOIN = { true | false | DEFAULT }
SUPPORTSFUSINGINUSINGANDNATURALJOIN = { true | false | DEFAULT }
SUPPORTSJOINONCONDITION = { true | false | DEFAULT }
SUPPORTSNATURALJOIN = { true | false | DEFAULT }
SUPPORTSUSINGJOIN = { true | false | DEFAULT }
DELEGATEAGGREGATEFUNCTIONS = { DEFAULT | ( <function:identifier>
[, <function:identifier> ]* ] ) }
| DELEGATESCALARFUNCTIONS = { DEFAULT | ( <function:identifier>
[, <function:identifier> ]* ] ) }
| DELEGATEOPERATORSLIST = { DEFAULT | ( <operator:identifier>
[, <operator:identifier> ]* ] ) }
Figura 52 Sintaxis de la sentencia de creación de un datasource JDBC
Existe una sentencia de modificación de un datasource JDBC (ALTER DATASOURCE JDBC). Su sintaxis permite
indicar los mismos parámetros que la sentencia de creación.
ALTER 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>
Generación de Wrappers y DataSources
92
Virtual DataPort 4.0
Guía Avanzada de VQL
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>
Generación de Wrappers y DataSources
93
Virtual DataPort 4.0
Guía Avanzada de VQL
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> ::=
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 }
| DELEGATELEFTLITERAL = { true | false | DEFAULT }
| DELEGATENATURALOUTERJOIN = { true | false | DEFAULT }
| DELEGATENOTCONDITION = { true | false | DEFAULT }
| DELEGATEORCONDITION = { true | false | DEFAULT }
| DELEGATEORDERBY = { true | false | DEFAULT }
| DELEGATEPROJECTION = { true | false | DEFAULT }
| DELEGATEREGISTERLITERAL = { true | false | DEFAULT }
| DELEGATERIGHTFIELD = { true | false | DEFAULT }
| DELEGATERIGHTFUNCTION = { true | false | DEFAULT }
| DELEGATERIGHTLITERAL = { true | false | DEFAULT }
| DELEGATESELECTION = { true | false | DEFAULT }
| DELEGATEUNION = { true | false | DEFAULT }
| SUPPORTSAGGREGATEFUNCTIONSOPTIONS = { true | false | DEFAULT }
| SUPPORTSBRANCHOUTERJOIN = { true | false | DEFAULT }
| SUPPORTSEQOUTERJOINOPERATOR = { true | false | DEFAULT }
| SUPPORTSEXPLICITCROSSJOIN = { true | false | DEFAULT }
| SUPPORTSFULLEQOUTERJOIN = { true | false | DEFAULT }
| SUPPORTSFULLNOTEQOUTERJOIN = { true | false | DEFAULT }
| SUPPORTSFUSINGINUSINGANDNATURALJOIN = { true | false | DEFAULT }
| SUPPORTSJOINONCONDITION = { true | false | DEFAULT }
| SUPPORTSNATURALJOIN = { true | false | DEFAULT }
| SUPPORTSUSINGJOIN = { true | false | DEFAULT }
| DELEGATEAGGREGATEFUNCTIONS = { DEFAULT | ( <function:identifier>
[, <function:identifier> ]* ] ) }
| DELEGATESCALARFUNCTIONS = { DEFAULT | ( <function:identifier>
[, <function:identifier> ]* ] ) }
| DELEGATEOPERATORSLIST = { DEFAULT | ( <operator:identifier>
Generación de Wrappers y DataSources
94
Virtual DataPort 4.0
Guía Avanzada de VQL
[, <operator:identifier> ]* ] ) }
Figura 54 Sintaxis de la sentencia de creación de un datasource 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.
Generación de Wrappers y DataSources
95
Virtual DataPort 4.0
Guía Avanzada de VQL
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 Sintaxis de la sentencia de creación de un datasource 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:
Generación de Wrappers y DataSources
96
Virtual DataPort 4.0
-
-
-
-
Guía Avanzada de VQL
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>
Generación de Wrappers y DataSources
97
Virtual DataPort 4.0
Guía Avanzada de VQL
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 Sintaxis de la sentencia de modificación de un datasource 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.
Generación de Wrappers y DataSources
98
Virtual DataPort 4.0
Guía Avanzada de VQL
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> ]
Generación de Wrappers y DataSources
99
Virtual DataPort 4.0
Guía Avanzada de VQL
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 Sintaxis de la sentencia de modificación de un datasource 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 de
Virtual 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 Projection (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.
Generación de Wrappers y DataSources
100
Virtual DataPort 4.0
Guía Avanzada de VQL
•
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.
Generación de Wrappers y DataSources
101
Virtual DataPort 4.0
•
Guía Avanzada de VQL
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 Explicit 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.
Generación de Wrappers y DataSources
102
Virtual DataPort 4.0
•
Guía Avanzada de VQL
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.
Generación de Wrappers y DataSources
103
Virtual DataPort 4.0
•
Guía Avanzada de VQL
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 Inclusive 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:
Generación de Wrappers y DataSources
104
Virtual DataPort 4.0
Guía Avanzada de VQL
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'
summary contains 'term3')
17.4
AND
(content
contains
'term2'
OR
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.
Generación de Wrappers y DataSources
105
Virtual DataPort 4.0
•
Guía Avanzada de VQL
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>
Generación de Wrappers y DataSources
106
Virtual DataPort 4.0
Guía Avanzada de VQL
[, <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).
Generación de Wrappers y DataSources
107
Virtual DataPort 4.0
17.4.4
Guía Avanzada de VQL
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)
Generación de Wrappers y DataSources
108
Virtual DataPort 4.0
Guía Avanzada de VQL
<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 }
Generación de Wrappers y DataSources
109
Virtual DataPort 4.0
Guía Avanzada de VQL
<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)"
Generación de Wrappers y DataSources
110
Virtual DataPort 4.0
Guía Avanzada de VQL
Figura 77 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 (rutas 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.
Generación de Wrappers y DataSources
111
Virtual DataPort 4.0
Guía Avanzada de VQL
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
Generación de Wrappers y DataSources
112
Virtual DataPort 4.0
Guía Avanzada de VQL
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
Generación de Wrappers y DataSources
113
Virtual DataPort 4.0
Guía Avanzada de VQL
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>]* ) ]
Generación de Wrappers y DataSources
114
Virtual DataPort 4.0
Guía Avanzada de VQL
[ 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.
Generación de Wrappers y DataSources
115
Virtual DataPort 4.0
Guía Avanzada de VQL
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
Generación de Wrappers y DataSources
116
Virtual DataPort 4.0
Guía Avanzada de VQL
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.
Generación de Wrappers y DataSources
117
Virtual DataPort 4.0
•
•
•
•
•
•
Guía Avanzada de VQL
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.
Generación de Wrappers y DataSources
118
Virtual DataPort 4.0
Guía Avanzada de VQL
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> ::=
Generación de Wrappers y DataSources
119
Virtual DataPort 4.0
Guía Avanzada de VQL
<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,
Generación de Wrappers y DataSources
120
Virtual DataPort 4.0
•
•
•
Guía Avanzada de VQL
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> )
Generación de Wrappers y DataSources
121
Virtual DataPort 4.0
Guía Avanzada de VQL
| <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> )
Generación de Wrappers y DataSources
122
Virtual DataPort 4.0
Guía Avanzada de VQL
| <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
Generación de Wrappers y DataSources
123
Virtual DataPort 4.0
Guía Avanzada de VQL
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]).
Generación de Wrappers y DataSources
124
Virtual DataPort 4.0
Guía Avanzada de VQL
•
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
com.denodo.vdb.engine.IRawResult (ver documentación Javadoc [4]).
a
la
interfaz
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.
Generación de Wrappers y DataSources
125
Virtual DataPort 4.0
Guía Avanzada de VQL
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:
Generación de Wrappers y DataSources
126
Virtual DataPort 4.0
Guía Avanzada de VQL
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 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 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 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 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 Projection (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 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 cumple la especificación XA.
o
-
-
-
-
-
Generación de Wrappers y DataSources
127
Virtual DataPort 4.0
o
-
-
Guía Avanzada de VQL
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.
Generación de Wrappers y DataSources
128
Virtual DataPort 4.0
Guía Avanzada de VQL
QUERY WRAPPER ITP <name:identifier>
[
(
<name:identifier> = <value:literal>
[, <name:identifier> = <value:literal>]*
)
]
Figura 96 Sintaxis de la sentencias de consulta de wrappers ITPilot
Generación de Wrappers y DataSources
129
Virtual DataPort 4.0
18
Guía Avanzada de VQL
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.
Características Avanzadas
130
Virtual DataPort 4.0
•
Guía Avanzada de VQL
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,
Características Avanzadas
131
Virtual DataPort 4.0
Guía Avanzada de VQL
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;
RE
DD
TA
AC
NT
CO
register
NA
M
E
text
SURNAME
SS
text
text
register
S
ES
DR
AD
M
L
AI
register
CO
ST
R
CITY
text
RY
text
T
UN
EE
T
text
register
Figura 97 Árboles de tipos compuestos
En la Figura 98 se muestra un ejemplo de tupla de esta vista y su representación interna:
TITLE
Book1
AUTHOR
NAME
Name1
SURNAME
Surname1
CONTACTADDRESS
MAIL
[email protected]
MAIL
[email protected]
Características Avanzadas
ADDRESS
STREET
Street1
ADDRESS
STREET
Street2
CITY
City1
COUNTRY
Country1
CITY
City2
COUNTRY
Country2
132
Virtual DataPort 4.0
NAME
Name3
SURNAME
Surname3
Guía Avanzada de VQL
CONTACTADDRESS
MAIL
[email protected]
ADDRESS
STREET
Street3
ADDRESS
STREET
Street4
MAIL
[email protected]
CITY
City3
COUNTRY
Country03
CITY
City4
COUNTRY
Country04
Figura 98 Tupla con elementos compuestos
La estructura del árbol de valores se muestra en la Figura 99.
book1
array
[0]
[1]
M
E
NA
SURNAME
[0]
ET
ET
ST
RE
ST
RE
author4@au
thors.com
register
street3
CITY
city3
AI
country3
AD
L
DR
ES
S
register
street4
CITY
city4
Y
TR
UN
country2
M
S
CO
city2
DR
ES
Y
TR
UN
street2
CITY
Y
TR
UN
country1
author3@au
thors.com
CO
city1
Y
TR
UN
street1
CITY
register
L
AI
register
CO
author2@au
thors.com
register
M
AD
ST
RE
M
CO
author1@au
thors.com
ET
M
register
AD
DR
ES
S
L
AI
[1]
[0]
register
AD
DR
ES
S
array
surname3
[1]
register
L
AI
name3
ET
array
surname1
ST
RE
name1
SS
SS
RE
RE
DD
TA
DD
TA
SURNAME
AC
NT
register
AC
NT
NA
M
E
CO
CO
register
country4
Figura 99 Á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
);
Figura 100
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:
Características Avanzadas
133
Virtual DataPort 4.0
Guía Avanzada de VQL
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 …;
Figura 101
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
ADD AUTHOR.NAME
ADD AUTHOR.SURNAME
ADD AUTHOR.CONTACTADDRESS
ADD AUTHOR.CONTACTADDRESS.MAIL
ADD AUTHOR.CONTACTADDRESS.ADDRESS.STREET
ADD AUTHOR.CONTACTADDRESS.ADDRESS.CITY
ADD AUTHOR.CONTACTADDRESS.ADDRESS.COUNTRY
)
OUTPUTLIST (TITLE, AUTHOR)
WRAPPER (ITP book)
);
Figura 102
NOS
NOS
NOS
NOS
NOS
NOS
NOS
NOS
ZERO
ZERO
ZERO
ZERO
ZERO
ZERO
ZERO
ZERO
()
()
()
()
()
()
()
()
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;
Características Avanzadas
134
Virtual DataPort 4.0
Guía Avanzada de VQL
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.
Características Avanzadas
135
Virtual DataPort 4.0
Guía Avanzada de VQL
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 subconsulta 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
FROM
FROM
FROM
view1
view1
view1
view1
HASH JOIN view2 ON (joinCondition)
MERGE LEFT OUTER JOIN view2 ON (joinCondition)
NESTED NATURAL INNER JOIN view2
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)
Características Avanzadas
136
Virtual DataPort 4.0
18.2.1.1
Guía Avanzada de VQL
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).
Características Avanzadas
137
Virtual DataPort 4.0
Figura 104
Guía Avanzada de VQL
Á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 ')
Características Avanzadas
138
Virtual DataPort 4.0
Guía Avanzada de VQL
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 postprocesado (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’.
Características Avanzadas
139
Virtual DataPort 4.0
Guía Avanzada de VQL
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
Características Avanzadas
140
Virtual DataPort 4.0
Guía Avanzada de VQL
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).
Características Avanzadas
141
Virtual DataPort 4.0
•
•
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
•
Guía Avanzada de VQL
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
Símbolo
G
y
M
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-MMMyyyy H'h' m'm'. Para más información, ver [9], clases java.text.DateFormat y/o
java.text.SimpleDateFormat.
Significado
Especifica una Era
Año
Mes en año
Características Avanzadas
Presentación
(Texto)
(Número)
(Texto & Número)
Ejemplo
AD
1996
July & 07
142
Virtual DataPort 4.0
d
h
H
m
s
S
E
D
F
w
W
a
k
K
z
'
''
Día en mes
Hora en am/pm (1~12)
Hora en día (0~23)
Minuto en hora
Segundo en minuto
Milisegundo
Día de la semana
Día del año
Día de la semana en el mes
Semana del año
Semana en mes
Marca de am/pm
Hora en el día (1~24)
Hora en am/pm (0~11)
Zona horario
Carácter de escape para texto
Comilla simple
Tabla 8
Guía Avanzada de VQL
(Número)
(Número)
(Número)
(Número)
(Número)
(Número)
(Texto)
(Número)
(Número)
(Número)
(Número)
(Texto)
(Número)
(Número)
(Texto)
(Delimitador)
(Literal)
10
12
0
30
55
978
Tuesday
189
2(2nd Web in July)
27
2
PM
24
0
Pacific Standard Time
‘
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 (
Características Avanzadas
143
Virtual DataPort 4.0
Guía Avanzada de VQL
'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
18.3.1
Internacionalización es_euro
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 funcionar incorrectamente cuándo el wrapper reciba más de una condición de consulta
utilizando el mismo atributo y operador.
Características Avanzadas
144
Virtual DataPort 4.0
Guía Avanzada de VQL
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).
Características Avanzadas
145
Virtual DataPort 4.0
19
Guía Avanzada de VQL
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
146
Virtual DataPort 4.0
Guía Avanzada de VQL
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
147
Virtual DataPort 4.0
Guía Avanzada de VQL
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:
-
Apéndices
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.
148
Virtual DataPort 4.0
-
Guía Avanzada de VQL
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:
-
-
Apéndices
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).
149
Virtual DataPort 4.0
Guía Avanzada de VQL
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
Apéndices
150