Professional Documents
Culture Documents
Denodo Libro
Denodo Libro
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
3 CARACTERÍSTICAS................................................................................................................................ 9
3.1 TIPOS DE DATOS ................................................................................................................................... 9
3.2 INTERNACIONALIZACIÓN.................................................................................................................. 10
3.3 CAPACIDADES DE CONSULTA.......................................................................................................... 11
3.4 REGLAS DE REESCRITURA................................................................................................................. 11
10 PROCEDIMIENTOS ALMACENADOS................................................................................................ 61
10.1 IMPORTACIÓN DE UN PROCEDIMIENTO ALMACENADO............................................................ 61
10.2 USO DE PROCEDIMIENTOS ALMACENADOS................................................................................. 61
10.3 CREACIÓN DE NUEVOS PROCEDIMIENTOS ALMACENADOS .................................................... 62
10.4 PROCEDIMIENTOS PREDEFINIDOS.................................................................................................. 64
19 APÉNDICES......................................................................................................................................... 146
19.1 SINTAXIS DE EXPRESIONES DE BÚSQUEDA DEL OPERADOR CONTAINS ............................ 146
19.1.1 Términos y Frases exactas.................................................................................................................... 146
19.1.2 Modificadores de términos................................................................................................................... 146
19.1.3 Operadores Booleanos.......................................................................................................................... 148
19.1.4 Agrupaciones ........................................................................................................................................ 148
19.1.5 Escapar caracteres especiales.............................................................................................................. 148
19.2 SOPORTE PARA EL OPERADOR CONTAINS DE CADA TIPO DE FUENTE................................. 148
19.2.1 Aracne ................................................................................................................................................... 148
19.2.2 Google Mini........................................................................................................................................... 149
ÍNDICE DE FIGURAS
ÍNDICE DE TABLAS
PREFACIO
ALCANCE
Este documento proporciona una visión de Virtual DataPort desde el punto de vista del administrador avanzado.
RESUMEN DE CONTENIDOS
Más concretamente, en este documento:
• 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 Guía Avanzada de VQL
1 INTRODUCCIÓN
Denodo Virtual DataPort es una solución global para la integración de fuentes de información heterogéneas y
dispersas en tiempo real.
Virtual DataPort utiliza el lenguaje VQL (Virtual Query Language) como lenguaje de consulta, actualización y
definición de datos. VQL permite crear, actualizar y manipular los elementos que constituyen el diccionario de datos
del sistema, así como la realización de consultas y actualizaciones sobre las vistas integradas de información. VQL es
un lenguaje muy similar a SQL pero que incluye además construcciones específicas para tratar con las peculiaridades
de un sistema de integración de información virtual en tiempo real.
En este documento se describe VQL y la forma de utilizarlo para realizar las labores de administración de Virtual
DataPort. Es importante resaltar que en general no es necesario utilizar VQL directamente. En la Guía del
Administrador [3] se describe el uso de las herramientas gráficas de Virtual DataPort, que permiten realizar la
mayoría de las labores de administración de forma gráfica.
Introducción 2
Virtual DataPort 4.0 Guía Avanzada de VQL
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.
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.
Cada atributo de una relación pertenecerá a un tipo de dato. El tipo de un determinado atributo delimita qué
operadores de consulta pueden aplicarse sobre él, así como ciertas restricciones que los elementos de ese tipo
deben cumplir. Algunos tipos de datos usuales soportados por Virtual DataPort son: cadenas de caracteres, enteros,
divisas, fechas, etc. Están soportados también los tipos de dato array (para representar datos multi-valuados) y
register (para representar datos de tipo registro). Combinando estos dos tipos de dato, pueden también representarse
fácilmente en el modelo unificado estructuras de datos jerárquicas.
Además, cada relación base describirá explícitamente sus capacidades de consulta mediante los denominados
métodos de búsqueda. Esto es necesario porque algunas fuentes de datos (e.g. fuentes web o servicios web) no
permiten realizar cualquier consulta sobre sus datos, sino que presentan interfaces limitadas para esos efectos (e.g.
formularios HTML o las operaciones definidas a través de un Servicio Web). Si una relación no tiene ningún método
de búsqueda, entonces no podrá realizarse ninguna consulta sobre ella.
Cada método de búsqueda estará compuesto por una serie de 5-uplas. Cada 5-upla representa una restricción que
una consulta determinada debe cumplir para que pueda ser ejecutada sobre la fuente utilizando ese método de
búsqueda.
• operadores es el conjunto de operadores que puede ser utilizado en las consultas sobre esa fuente y con
ese método de búsqueda. ‘ANY’ representa a cualquier operador admitido por el tipo de dato del atributo.
• obligatoriedad puede tomar tres valores: ‘OBL’ indica que el atributo debe obligatoriamente aparecer en
cualquier consulta sobre la fuente. ‘OPT’ indica que el atributo puede aparecer o no en la consulta (es
opcional) y ‘NOS’ indica que las consultas por ese atributo no están permitidas en la fuente.
• multiplicidad indica por cuántos valores puede consultarse a la vez la fuente para el atributo y el
operador dados. Si no es posible realizar consultas por ese atributo (valor “NOS” en el campo
obligatoriedad) el valor es forzosamente 0. ‘ANY’ indica un número de valores mayor que 0 pero sin límite
superior.
• valores_posibles es la lista de valores por los que puede consultarse el atributo. Si contiene el valor
‘ANY’ significa que el rango de búsqueda no está acotado (dentro del rango asociado al tipo de dato del
atributo) y puede consultarse el atributo por cualquier valor. Si el campo obligatoriedad está fijado en la 5-
upla al valor ‘NOS’, entonces forzosamente toma el valor de un conjunto vacío.
En fuentes tales como bases de datos relacionales habitualmente será permitida cualquier consulta. En ese caso las
relaciones base creadas a partir de dichas fuentes tendrán típicamente un único método de búsqueda con una 5-upla
por cada atributo de la relación. Cada 5-upla indicará que el atributo puede aparecer o no en las consultas (valor
‘OPT’ en obligatoriedad) y con cualquier multiplicidad (valor ‘ANY’ en multiplicidad).
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.
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.
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:
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.
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.
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.
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:
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
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.
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.
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.
3 CARACTERÍSTICAS
Virtual DataPort permite de manera rápida y sencilla, extraer y combinar en tiempo real información procedente de
múltiples fuentes heterogéneas estructuradas, semi-estructuradas y no estructuradas.
Virtual DataPort proporciona un lenguaje de definición y manejo de datos llamado Denodo VQL (Virtual Query
Language), cuya sintaxis es similar a SQL (Structured Query Language) con algunas extensiones necesarias para un
entorno de integración virtual de fuentes de información heterogéneas y distribuidas. Por ejemplo, VQL incluye
diversas construcciones que facilitan la consulta de información no estructurada y su combinación con información
estructurada.
En este apartado se describen algunas características importantes de Virtual DataPort que es necesario conocer
previamente para comprender el resto del documento.
• A continuación, se describen los mecanismos de internacionalización de los diferentes tipos de datos del
sistema.
• Por último, se introduce el sistema de reglas de reescritura, que permite solventar dificultades derivadas de
las heterogeneidades semánticas de las fuentes.
Características 9
Virtual DataPort 4.0 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 Guía Avanzada de VQL
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.
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 Guía Avanzada de 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 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 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:
• 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.
• 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.
La sentencia INSERT permite insertar una nueva tupla de datos en una vista, actualizando directamente la fuente
de datos. Soporta las siguientes cláusulas:
• INTO: indica la vista sobre la que se realizará la inserción de datos y los atributos de la misma.
• VALUES: indica el valor para cada atributo de la vista de la nueva tupla insertada.
• SET: sintaxis alternativa al uso de la cláusula VALUES para especificar el valor de cada atributo de la
nueva tupla.
La sentencia UPDATE permite modificar una o varias tuplas de datos de una vista, actualizando directamente la
fuente de datos. Soporta las siguientes cláusulas:
• 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.
La sentencia DELETE permite eliminar una o varias tuplas de una vista, actualizando directamente la fuente de
datos. Soporta las siguientes cláusulas:
• CONTEXT: utilizada para modificar determinadas opciones de configuración para la ejecución de una
sentencia.
• 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.
• ‘<’: 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’:
• ‘contains’: Admite como operandos 2 elementos de tipo text. El primer operando será un
atributo de tipo text procedente de un índice de información no estructurada externo (e.g. datasources
tipo Aracne y/o Google Mini). El segundo operando será una expresión de búsqueda booleana escrita en el
lenguaje de búsqueda sobre información no estructurada de DataPort.
La sintaxis del lenguaje de búsqueda sobre información no estructurada se describe en la sección 19.1. Sin
embargo, es necesario tener presente que las opciones de búsqueda disponible dependen de las
capacidades proporcionadas nativamente por la fuente de datos. Por ejemplo, Google Mini no soporta
diversas características del lenguaje de búsqueda como, por ejemplo, las búsquedas por proximidad. Por lo
tanto, cuando se utilice el operador contains con atributos procedentes de fuentes Google Mini, dichas
capacidades no estarán disponibles. La sección 19.2 detalla con exactitud las capacidades de búsqueda
soportadas para fuentes Google Mini y para fuentes Aracne. Los wrappers de tipo Custom que permitan el
acceso a otras fuentes de datos pueden especificar qué capacidades del lenguaje de búsqueda para
contains soportan a través de las Propiedades de Configuración (ver sección 17.3.10.1).
En el caso de vistas derivadas, las capacidades de búsqueda soportadas para un atributo son calculadas
por DataPort en función de las capacidades de los atributos de sus vistas base. Es posible ver las
capacidades de cada atributo haciendo uso de la sentencia DESC VIEW para consultar el valor de sus
Propiedades de Configuración (ver secciones 17.3.6 y 17.3.10.1).
Ejemplos: La siguiente consulta devuelve aquellas tuplas de la vista aracneview cuyo atributo
searchablecontent contenga las palabras ‘acme’ e ‘incorporated’:
• ’containsor’: Admite como operandos 2 ó más elementos de tipo text. Comprueba si la primera
cadena contiene al menos una de las restantes cadenas que recibe.
• ‘isContained’: Admite como operandos 2 o más elementos de tipo text. Comprueba si la primera
cadena está contenida en todas las restantes cadenas que recibe.
• ‘is not NULL’: Se aplica sobre un único operando, que puede pertenecer a los siguientes tipos de
dato: int, long, float, double, boolean, text, enumerated, date, time, money
y link. Comprueba si el valor no es nulo, es decir, si tiene algún valor.
• ‘is NULL’: Recibe un operando que puede ser de uno de los siguientes tipos de dato: int, long,
float, double, boolean, text, enumerated, date, time, money y link. Evalúa si
su valor es nulo, es decir, si no tiene valor.
• ‘is TRUE’: Se aplica sobre un único operando de tipo boolean. Devuelve el valor lógico del
operando (es decir, true sí y sólo sí su valor es true; false en caso contrario).
• ‘is FALSE’: Recibe un operando de tipo boolean. Devuelve la negación del valor lógico del
operando (es decir, true sí el operando se evalúa a false; false en caso contrario).
• ‘in’: Recibe una lista de operandos que puede ser de uno de los siguientes tipos de dato: int,
long, float, double, text, enumerated, date, time, money y link.
Devuelve true si el operando de la parte izquierda está incluido en la lista de operandos de la parte
derecha. La lista de operandos puede ir o no entre paréntesis.
Ejemplo: Las dos siguientes sentencias producen el mismo resultado: seleccionan aquellas tuplas de la
vista internet_inc tales que su valor para el atributo taxid es igual o bien al valor
'B78596011' o al valor 'B78596012':
• ‘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):
• ‘~’. 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:
NOTA: Los valores de tipo de dato blob no pueden participar en condiciones de consulta.
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).
• SUM: La función suma recibe un número variable de argumentos (mayor o igual a dos) y devuelve como
resultado un nuevo elemento del mismo tipo conteniendo la suma de los anteriores. La versión infija de
esta función recibe dos argumentos y se representa con el símbolo ‘+’.
• SUBTRACT: La función resta recibe dos argumentos y devuelve un nuevo elemento del mismo tipo con el
resultado de restar del primer argumento el valor del segundo. La versión infija de esta función recibe dos
argumentos y se representa con el símbolo ‘-‘.
• MULT: La función producto recibe un número variable de argumentos (mayor o igual a dos) y devuelve un
nuevo elemento del mismo tipo con el resultado del producto entre los diferentes argumentos. La versión
infija de esta función recibe dos argumentos y se representa por el símbolo ‘*’.
• DIV: La función división recibe dos argumentos de tipo numérico y devuelve un nuevo elemento del mismo
tipo con el resultado de dividir el primer argumento por el segundo. Si los argumentos son enteros, el
resultado de la división será también entero. La versión infija de esta función recibe dos argumentos y se
representa con el símbolo ‘/’.
• MIN: La función mínimo recibe un número variable de argumentos (mayor o igual a dos) y devuelve como
resultado el valor del menor argumento de la lista.
• MAX: La función máximo recibe un número variable de argumentos (mayor o igual a dos) y devuelve como
resultado el valor del mayor argumento de la lista.
• ABS: La función valor absoluto recibe un único argumento de tipo numérico y devuelve como resultado su
valor absoluto.
• MOD: La función módulo recibe dos argumentos de tipo numérico o money devuelve el resultado de la
operación módulo entre el primer argumento y el segundo (el resto de la división entera entre el primer
argumento y el segundo). La versión infija de esta función recibe dos argumentos y se representa con el
símbolo ‘%’.
• CEIL: Esta función recibe un argumento numérico y devuelve el menor entero, mayor o igual que el
argumento, más próximo al argumento. Si el argumento es de tipo int, devuelve un valor de tipo int.
Si el argumento es de tipo long, float o double, el valor devuelto es de tipo long. Si el
argumento es de tipo time o money, el valor devuelto es del mismo tipo.
• FLOOR: Esta función recibe un argumento numérico y devuelve el mayor entero, menor o igual que el
argumento, más próximo al argumento. Si el argumento es de tipo int, devuelve un valor de tipo int.
Si el argumento es de tipo long, float o double, el valor devuelto es de tipo long. Si el
argumento es de tipo time o money, el valor devuelto es del mismo tipo.
• ROUND: Esta función recibe un argumento numérico y devuelve como resultado el número entero más
próximo al argumento. Si el argumento es de tipo int, devuelve un valor de tipo int. Si el argumento
es de tipo long, float o double, el valor devuelto es de tipo long. Si el argumento es de tipo
time o money, el valor devuelto es del mismo tipo.
• POWER: Esta función recibe dos argumentos numéricos, el segundo de los cuáles debe ser entero.
Devuelve como resultado un valor de tipo double obtenido mediante la exponenciación del primer
argumento con el segundo como exponente.
• SQRT: Esta función recibe un argumento numérico y devuelve un valor de tipo double con el resultado
de obtener la raíz cuadrada del argumento.
• LOG: Esta función recibe un valor numérico y devuelve un valor de tipo double con el resultado de
obtener el logaritmo en base 10 del argumento.
• 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).
• 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.
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.
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”.
• LOWER: Esta función recibe un argumento de tipo texto y lo devuelve a la salida con todos los caracteres
que lo forman convertidos a minúsculas.
• UPPER: Esta función recibe un argumento de tipo texto y lo devuelve a la salida con todos los caracteres
que lo forman convertidos a mayúsculas.
• SUBSTRING: La función substring recibe como parámetros un argumento de tipo texto y dos números
enteros. Devuelve a la salida la parte del substring del primer argumento que se corresponde a las
posiciones indicadas por el segundo (inicio) y tercer (fin) argumentos.
• REGEXP: Esta función permite realizar transformaciones sobre cadenas de caracteres basadas en
expresiones regulares. Recibe tres argumentos: un elemento de tipo texto, una expresión regular “de
entrada” y una expresión regular “de salida”. Las expresiones regulares deben expresarse utilizando la
sintaxis de expresiones regulares del lenguaje JAVA [11]. La función se comporta de la forma siguiente: la
expresión regular de entrada se evalúa contra el texto del primer argumento y la expresión regular de
salida puede incluir los “grupos” definidos en la expresión regular de entrada. Las porciones de texto que
hayan encajado con los mismos se sustituirán en la expresión de salida. Por ejemplo, el resultado de
evaluar:
REGEXP(‘Shakespeare,William’,‘(\w+),(\w+)’,‘$2 $1’)
• 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.
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:
• NOW: Esta función no recibe ningún argumento y crea un objeto de tipo date conteniendo la fecha actual.
• GETDAY: Recibe un argumento de tipo date y devuelve un objeto de tipo long que representa el día de la
fecha recibida.
• GETHOUR: Recibe un argumento de tipo date y devuelve un objeto de tipo long que representa la hora
de la fecha recibida.
• GETMINUTE: Recibe un argumento de tipo date y devuelve un objeto de tipo long que representa el
minuto de la fecha recibida.
• GETSECOND: Recibe un argumento de tipo date y devuelve un objeto de tipo long que representa el
segundo de la fecha recibida.
• GETTIMEINMILLIS: Recibe un argumento de tipo date y devuelve un objeto de tipo long que
representa el número de milisegundos transcurridos desde el 1 de Enero de 1970 a las 00:00:00 GMT hasta
la fecha recibida como parámetro. el segundo de la fecha recibida.
• GETMONTH: Recibe un argumento de tipo date y devuelve un objeto de tipo long que representa el mes
de la fecha recibida.
• GETYEAR: Recibe un argumento de tipo date y devuelve un objeto de tipo long que representa el año de
la fecha recibida.
• TO_DATE: Permite convertir cadenas de texto que representan fechas en elementos de tipo date.
Recibe tres argumentos de tipo texto. El primero de ellos representa un patrón para expresar fechas
(siguiendo la sintaxis estándar en el lenguaje JAVA especificada en [12]) mientras el segundo será una
fecha expresada de acuerdo al mencionado patrón. El tercero, opcional, es un parámetro de tipo texto que
indica la configuración de internacionalización que representa el “locale” de la fecha a procesar. Como
resultado se devuelve un elemento de tipo date equivalente a la fecha especificada.
• 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:
• 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.
• 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.
<person>
<name> John Smith </name>
<age> 25 </age>
</person>
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.
• 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:
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(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 "")
Las funciones de agregación reciben como parámetro una expresión indicando el nombre del atributo sobre el que se
aplica. Opcionalmente, este parámetro puede estar precedido por uno de dos modificadores: ALL ó DISTINCT.
Estos modificadores afectan a la semántica de algunas funciones de agregación, aplicándolas sobre todas las tuplas
de un grupo o sólo sobre las que presenten distinto valor para el atributo considerado.
A continuación se enumeran las diferentes funciones de agregación:
• AVG: Utilizada para calcular el promedio de los valores de un atributo determinado. Aplicable sobre
atributos de tipo int, long, float, double, time y money. Devuelve un valor de tipo
double.
• COUNT: Utilizada para devolver el número total de tuplas resultado de una operación de selección (si se
especifica como atributo el carácter especial ‘*’) o el número de tuplas que tienen valor no nulo para un
atributo concreto. Aplicable sobre cualquier tipo de atributo. Se puede utilizar esta función de agregación
sin especificar una clausula de GROUP BY, pero en ese caso, sólo puede aplicarse sobre el atributo de
carácter especial ‘*’ para contabilizar el número total de tuplas devueltas.
• SUM: Utilizada para devolver la suma de todos los valores de un atributo determinado que no sean nulos.
Aplicable sobre atributos de tipo int, long, float, double, time y money.
• MAX: Utilizada para devolver el valor más alto de un atributo especificado. Aplicable sobre atributos de
tipo int, long, float, double, time y money. La implementación de esta función
ignora el modificador ALL/DISTINCT.
• MIN: Utilizada para devolver el valor más bajo de un atributo especificado. Aplicable sobre atributos de
tipo int, long, float, double, time y money. La implementación de esta función
ignora el modificador ALL/DISTINCT.
• FIRST: Utilizada para devolver el valor de un atributo de la primera tupla de cada grupo de valores.
Aplicable sobre cualquier tipo de atributo. La implementación de esta función ignora el modificador
ALL/DISTINCT.
• LAST: Utilizada para devolver el valor de un atributo de la última tupla de cada grupo de valores.
Aplicable sobre cualquier tipo de atributo. La implementación de esta función ignora el modificador
ALL/DISTINCT.
• LIST: Función de agregación que devuelve una lista con todos los valores de un atributo especificado,
para cada grupo. Aplicable sobre cualquier tipo de atributo.
• 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 corchetes ([]) indican elementos opcionales. También se utiliza para acceder a elementos de un array
o para definir un parámetro multivaluado de una función. En estos casos se especifica entrecomillada para
indicar explícitamente que deben aparecer, y que no indican elementos opcionales.
• El asterisco (*) indica que un elemento se puede especificar cero o más veces. Ejemplo:
[<search_method_clause>]* indica que el elemento [<search_method_clause>]
se puede repetir tantas veces como sea necesario. Posee un significado especial cuando se utiliza en la
sentencia SELECT o con la función de agregación COUNT.
• El signo suma (+) indica que un elemento se puede especificar una o más veces. Ejemplo:
[<field>]+ indica que el elemento [<field>] debe aparecer al menos una vez y se puede repetir
tantas veces como sea necesario.
• Elementos separados por el carácter "|", y agrupados entre llaves ({}), indican elementos alternativos. Por
ejemplo: {elemento1 | elemento2} indica que en esa posición habrá que escribir el
elemento1 o el elemento2.
• Las comas (,) se utilizan en construcciones sintácticas para separar elementos de una lista.
• Los paréntesis (()) sirven normalmente para agrupar expresiones y reforzar la precedencia. En algunos casos
se exigen como parte de la sintaxis particular de una sentencia.
• El punto (.) se utiliza en las constantes numéricas y para separar nombres de tablas, columnas y campos.
• El carácter de espacio en blanco puede ser un espacio, un tabulador, un retorno de carro o un salto de
línea.
• Identificadores (<identifier>). Los identificadores permiten asociar nombres a los diferentes elementos del
catálogo y son en general alfanuméricos a los que se exige que no puedan comenzar por un número.
Existen una serie de palabras reservadas que no pueden ser utilizadas como identificadores (ver Figura 3).
• Números (<number>). Un número es una combinación de dígitos, que pueden estar precedidos por un signo
‘-‘ y pueden incluir un punto como carácter separador decimal y opcionalmente un exponente (si se trata de
números reales).
• 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”.
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.
<value> ::=
<field name>
| <number>
| <boolean>
| <literal>
| <function>
<function> ::=
<identifier> ( [ [<function modifier>] <function parameter>
[, <function parameter>]* ] )
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.
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.
<field> ::=
<name:identifier>:<type:identifier> [ ( <property list> ) ]
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.
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.
[ ( <value_1:value> [ , <value_i:value> ]* ) ]
|
NOS { ZERO | 0 } ()
}
| DROP <integer>
<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>
• Operadores – es el conjunto de operadores que puede ser utilizado en las consultas sobre esa fuente y con
ese método de búsqueda. ‘ANY’ representa a cualquier operador admitido por el tipo de dato del atributo.
Si el campo de obligatoriedad (explicado más adelante) es ‘NOS’, no se especifica su valor.
• Obligatoriedad – puede tomar cuatro valores: ‘OBL’ indica que el atributo debe obligatoriamente
aparecer en cualquier consulta sobre la fuente. ‘OPT’ indica que el atributo puede aparecer o no en la
consulta (es opcional). ‘NOS’ indica que las consultas por ese atributo no están permitidas en la fuente.
• Multiplicidad – indica por cuántos valores puede consultarse a la vez la fuente para el atributo y el
operador dados. Puede tomar los valores ‘ZERO’ (que equivale a ‘0’), ‘ONE’ (que equivale a ‘1’),
‘ANY’ y cualquier número entero. Si no es posible realizar consultas por ese atributo (valor ‘NOS’ en el
campo obligatoriedad) este parámetro es opcional. ‘ANY’ indica un número de valores mayor que ‘0’ pero
sin límite superior.
• Valores Posibles – es la lista de valores por los que puede consultarse el atributo. Si contiene el valor
‘ANY’ significa que el rango de búsqueda no está acotado (dentro del rango asociado al tipo de dato del
atributo) y puede consultarse el atributo por cualquier valor. Si el campo obligatoriedad está fijado en la 5-
upla al valor ‘NOS’, este parámetro es opcional.
Después de especificar las restricciones de consulta, se indican los atributos que aparecen a la salida de las
consultas realizadas a través del método de búsqueda. Los atributos de salida de un método de búsqueda, se
especifican enumerando los atributos separados por comas.
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
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.
• 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.
• Las expresiones-patrón o patrones asociados a la regla de reescritura. Sirven para indicar la estructura que
deben seguir las condiciones de consulta que serán reescritas mediante esta regla de reescritura. Una
expresión-patrón se compone de varias condiciones-patrón. Cada condición-patrón consta de dos
elementos: un atributo de la relación y un conjunto de operadores. Una condición de consulta encaja o
verifica una condición patrón, si tiene como parte izquierda el atributo de la condición-patrón y tiene como
operador alguno de los operadores que contiene la condición-patrón. Las expresiones-patrón deben
construirse de modo que ninguna condición encaje con varias condiciones-patrón. Una expresión-patrón se
verifica para una condición de consulta si: 1) para cada condición patrón existe una condición simple que la
satisface, y 2) si las condiciones simples que cumplen cada una de las condiciones patrón no están
contenidas en ninguna condición OR y NOT.
• La función de transformación. Es la función que reescribe las condiciones que han encajado con las
expresiones-patrón, produciendo a la salida un nuevo conjunto de condiciones de consulta que tomarán el
lugar de las encajadas en la consulta original. Una función de transformación es una función predefinida
(cuya sintaxis se explica en el Apartado 4.8) parametrizada por valores individuales o listas de valores
individuales.
• La posición que toma la regla de reescritura en la lista de reglas de reescritura asociadas al método de
búsqueda sobre el que actúa.
El resultado de una reescritura de condiciones es el subconjunto de condiciones que no ha encajado con ninguna
expresión-patrón, más el resultado de aplicar la función de transformación sobre el subconjunto de condiciones que
sí han sido encajadas.
Como podemos ver en el Apartado 4.8, una función de transformación de una regla de reescritura de entrada se
compone de un nombre y una serie de parámetros. Los parámetros son opcionales, van separados por comas y
pueden ser elementos simples (literal, número o nombre de atributo, con la sintaxis general definida en el apartado
4.8) o listas. Las listas se delimitan por los caracteres ’[’ y ’]’, sus elementos se separan con el carácter ‘,’ y pueden
ser cualquier elemento simple.
Las funciones de transformación de entrada que Virtual DataPort incluye ya implementadas son:
REMOVEACCENTS(), REGEXP(), MAP() y CHANGEOPERATOR(). Los siguientes subapartados se
ocupan, respectivamente, de cada una de ellas.
5.3.1.1 REMOVEACCENTS
La función de transformación REMOVEACCENTS()elimina los acentos de los literales de búsqueda. Esta función
no recibe ningún parámetro.
5.3.1.2 REGEXP
La función REGEXP() realiza transformaciones sobre los valores resultado de evaluar la parte derecha de las
condiciones, desde un formato de entrada a un formato de salida, parametrizados ambos formatos por variables. Esta
función recibe dos parámetros: una expresión regular de entrada y otra de salida.
Las expresiones regulares deben expresarse utilizando la sintaxis de expresiones regulares del lenguaje JAVA[11].
En la Figura 9 se muestra un ejemplo de una regla de reescritura de entrada que utiliza la función de transformación
REGEXP(). Dicha regla de reescritura, sobrescribe las condiciones de la forma (AUTHOR like <value>),
dónde <value> es una cadena que representa el nombre y los apellidos del autor separados por una coma,
intercambiando el orden del nombre y apellidos y eliminando la coma. Por ejemplo, dicha regla de reescritura
sustituiría la condición (AUTHOR like ‘Smith, John ') por (AUTHOR like ’John Smith’).
);
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
)
);
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.
• 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).
• 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).
5.3.2.1 REMOVEACCENTS
La función de transformación de salida REMOVEACCENTS(), elimina los acentos de los valores de un conjunto
de atributos. El parámetro que recibe es la lista de atributos de tipo texto sobre los que debe actuar, eliminando los
acentos de las cadenas que tienen como valores dentro de la tupla. La lista de atributos se especifica entre
corchetes, separados por comas (p.e. [field1, field2] ).
5.3.2.2 REGEXP
La función de transformación de salida REGEXP(), reescribe los valores para un conjunto de atributos de una
tupla, que concuerdan con una expresión regular de entrada, a un formato de salida, parametrizados ambos formatos
por variables. Las expresiones regulares de entrada y salida siguen la misma sintaxis que los utilizados por la función
de transformación de entrada del mismo nombre (descrita en el Apartado 5.3.1.2). Esta función recibe tres
parámetros: la lista de atributos de la tupla que reescribe (entre corchetes y separados por comas), los patrones de
entrada y los patrones de salida. Los dos últimos indican el formato de los valores de entrada y salida para dichos
atributos, respectivamente.
5.3.2.3 MAP
La función MAP() reescribe una tupla aplicando mapas de correspondencia directa sobre determinados campos de
la misma. Recibe como parámetros la opción de internacionalización a aplicar, la lista de nombres de los atributos
sobre los que se aplican los mapas (entre corchetes y separados por comas) y la lista de mapas a aplicar a cada uno
de los atributos especificados en el atributo anterior.
Como ejemplo, supóngase que tenemos una tienda electrónica de libros que, para la información de formato, puede
devolver uno de los siguientes valores: ‘eBook’, ’Hardcover’ o ‘Paperback’, mientras que la relación base
que representa a dicha fuente tiene un atributo FORMAT, que pertenece a un tipo de dato enumerado que admite
los siguientes valores: ’EB’, ’HC’ o ‘PB’. Podríamos definir un mapa que realizase la conversión entre unos y otros
valores y, posteriormente, utilizar una función de reescritura MAP para reescribir adecuadamente los resultados
obtenidos de la fuente.
En la Figura 12 se muestra cómo se añadiría una regla de reescritura tipo raw sobre resultados que reescribe el valor
del campo FORMAT aplicando el mapa “testBookFormat” (expresado según la configuración de
internacionalización “es_euro”) sobre todas las tuplas resultado de ejecutar el método de búsqueda
bookview_sm1.
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).
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> ::=
SELECT [DISTINCT] <select fields>
FROM <view> [ , <view> ]*
WHERE <condition>
GROUP BY <group by field> [ , <group by field> ]*
HAVING <condition>
<join type> ::= LEFT [OUTER] | RIGHT [OUTER] | FULL [OUTER] | INNER
<method type> ::= HASH | NESTED | MERGE
<order type> ::= ORDERED | REVERSEORDER
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:
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.
donde view1 y view2 son las vistas involucradas y joinCondition especifica la condición de join deseada.
• 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:
• 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:
• 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:
• 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:
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:
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.
En Virtual DataPort un elemento de tipo array debe ser visto como una subrelación; en realidad un array
DataPort siempre tendrá asociado internamente un tipo register. Cada subelemento contenido en el array
pertenecerá a dicho tipo de datos register. De esta forma, los campos de este registro pueden verse como el
esquema de la subrelación que está modelando.
En ocasiones puede ser deseable “aplanar” un campo compuesto que contenga un array de registros. Esto es
especialmente frecuente al tratar fuentes de tipo XML y Web services. Esta sección describe como hacerlo.
Supóngase que tenemos un Servicio Web con una operación getAverageMonthlySales. Esta operación no
recibe ningún parámetro y devuelve información sobre las ventas mensuales de todos los clientes de una empresa
mediante un array de objetos dónde cada objeto tendrá dos propiedades: taxId y revenue.
La relación base creada sobre esta nueva operación tendrá típicamente un único atributo de tipo array
conteniendo elementos de un tipo register y una única tupla dónde se encontrará toda la información devuelta
por el servicio web. De cara a la combinación de la información con otras fuentes puede ser mucho más útil una
vista que tenga dos atributos (taxId y revenue) y una tupla por cada cliente. Esto puede realizarse mediante
una operación de “aplanamiento” sobre la vista original. A continuación se describe dicho proceso.
En la cláusula FROM se puede utilizar un constructor especial (FLATTEN) para la definición de consultas sobre
visiones “aplanadas” de vistas con tipos de datos compuestos (ver sección18.1). El constructor FLATTEN permite
generar tuplas a partir de los subcampos compuestos de tipo array de las tuplas originales de una vista determinada.
Su sintaxis (ver Figura 14) permite las siguientes alternativas:
- Especificando el nombre de un atributo de una vista de tipo array, genera una vista que tiene como
esquema el del registro contenido en el array indicado. El nombre del subelemento array especificado
puede encontrarse contenido dentro de una o varias estructuras de registros (pero no puede atravesar
ningún otro array).
- Especificando el nombre de una vista y un alias, es posible obtener la representación aplanada de un array
que podría estar a su vez contenido en otros arrays. Además en este caso se conservan el resto de campos
de la vista.
La sintaxis se especifica indicando inicialmente un alias para la vista original, y a continuación el elemento
array sobre el que aplicar la operación FLATTEN. Si se desea aplicar sobre un array que está
contenido en otro, será necesario añadir un alias al último array indicado y sobre éste especificar el
elemento array que interese (si se desea atravesar más elementos array, se procede de forma similar).
El esquema resultante contendrá los campos de la vista original (excepto sobre el que se realice la
operación de FLATTEN) y todos los elementos de todos los registros involucrados en el aplanamiento.
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:
Si se especifica el carácter “*” en la cláusula SELECT, significa que se seleccionan todos los atributos de las
vistas sobre las que se realiza la consulta.
Como resultado de una consulta sobre Virtual DataPort, se obtiene una relación o vista cuyo esquema viene dado por
los nombres y tipos de los atributos especificados en la cláusula SELECT. También es posible definir alias para las
columnas obtenidas, permitiendo de esta forma modificar el nombre de algún atributo.
En el caso de atributos derivados, no es obligatorio definir un alias para indicar el nombre del nuevo campo de la
relación (véase el apartado 6.2.1). Si no se especifica, entonces el sistema asociará como alias el nombre de la
función generadora del atributo derivado, en el caso de las funciones, y el nombre del último subcampo referenciado
en el caso de un subelemento de un campo compuesto.
En una consulta, si un campo no tiene alias y es una referencia a un campo de una vista inferior, su nombre es el
nombre de la vista de la que proviene seguida del nombre del campo (separados por el caracter '.'). En cambio, en
una vista, el nombre de sus campos nunca encapsulan el nombre de una vista inferior; por tanto, en una vista el
nombre de un campo sin alias que es una referencia a un campo de una vista inferior, será simplemente el nombre
del campo en la vista inferior sin ningún nombre de vista.
En las consultas y en las vistas, no se permite que haya dos campos con el mismo nombre, siendo necesario
renombrar (mediante alias) alguno de ellos de forma diferente.
Finalmente, puede incluirse el modificador DISTINCT. En ese caso se eliminarán del resultado aquellas tuplas
duplicadas.
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.
<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>
Una condición es una secuencia de elementos condición separados por los operadores lógicos AND, OR o NOT. Cada
condición, representa una operación de comparación, que al evaluarse obtiene como resultado un valor positivo
(verdadero) o negativo (falso). Las condiciones pueden agruparse entre los símbolos ‘(’ y ‘)’ para variar su
precedencia.
Una condición se compone de un argumento, que es el elemento sobre el cuál se aplica la condición y que se
corresponderá con el primer operando, seguido de un operador de comparación. Este operador, a su vez, y siempre
que no sea unario (IS NULL, IS NOT NULL, IS TRUE o IS FALSE), va seguido de uno o varios
argumentos dependiendo de la naturaleza del mismo. Los operadores de comparación que soporta Virtual DataPort
se especifican en el apartado 4.5, e incluyen operadores de igualdad, de comparación mayor/menor, de contención
de cadenas, etc.
Se puede decir que una condición se compone de tres elementos: una parte izquierda (que será el operando sobre el
que se aplica la operación de comparación), un operador y una parte derecha (que es opcional y que contiene el resto
de los operandos que se compararán con el de la parte izquierda).
Un operando de una condición puede ser el nombre de un atributo, un literal, un número, un valor lógico, una
expresión a evaluar o un valor compuesto (ver sección 6.3.1). Una expresión como operando de una condición es una
función predefinida y parametrizada como la que se utiliza para la especificación de un atributo derivado dentro de la
cláusula SELECT, pero con una particularidad añadida: en la mayoría de los casos es obligatorio que uno de los
operandos sobre el que se aplica la condición (es decir, en el operando de la parte izquierda o en alguno de los de la
derecha), esté parametrizado por al menos el nombre de un atributo (no es así, por ejemplo con la función
TEXTCONSTANT("texto"), porque TEXTCONSTANT devuelve siempre como resultado un elemento de
tipo "text").
Como ya se ha adelantado, algunos operadores pueden admitir operandos de varios tipos de dato, pero en una
misma condición, todos sus operandos deben pertenecer al mismo tipo. Por ejemplo, el operador ‘=’, sirve para
comparar elementos de cualquier tipo de dato (tipo texto, entero, real, etc), pero dentro de una condición específica,
es necesario que todos los operandos sean del mismo tipo (no se pueden comparar, por ejemplo, un valor tipo entero
con un valor tipo texto, aunque es posible utilizar la función CAST para realizar las conversiones de tipo precisas
antes de la comparación).
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:
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.
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.
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:
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:
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.
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.
También es posible especificar los atributos de ordenación por su número de orden en la cláusula SELECT. Por
ejemplo:
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).
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).
• 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.
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.
• 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.
• Parámetros avanzados. Proporcionan más detalle sobre cada tipo de nodo. Por ejemplo:
o En el caso de nodos de tipo wrapper, se indican las subconsultas exactas ejecutadas sobre cada
fuente de datos, así como los datos de conexión utilizados para acceder a cada una de ellas.
o Para cada nodo de tipo vista, se indica si se ha utilizado o no la cache, si ha sido necesario
realizar swapping, si existen reglas de reescritura asociadas a la misma, etc.
• Condiciones de error. La traza indica también los posibles errores producidos durante la ejecución del nodo.
INTERNET_INC es una vista base creada sobre una tabla del mismo nombre accesible a través de una fuente de
datos JDBC.
BASE PLAN (
name = INTERNET_INC
startTime = Wed Jan 10 17:50:01 850 GMT+01:00 2007
endTime = Wed Jan 10 17:50:04 063 GMT+01:00 2007
responseTime = Wed Jan 10 17:50:04 053 GMT+01:00 2007
numRows = 4
state = OK
completed = true
fields = [IINC_ID, SUMMARY, TTIME, TAXID, SPECIFIC_FIELD1,
SPECIFIC_FIELD2]
search conditions = []
filter conditions = []
numOfFilteredTuples = 0
numOfDuplicatedTuples = 0
numOfSwappedTuples = 0
swapping = false
inputRewriteFunctions = false
outputRewriteFunctions = false
inputRawRewriteFunctions = false
outputRawRewriteFunctions = false
JDBC WRAPPER (
name = internet_inc
startTime = Wed Jan 10 17:50:02 070 GMT+01:00 2007
endTime = Wed Jan 10 17:50:04 063 GMT+01:00 2007
responseTime = Wed Jan 10 17:50:04 063 GMT+01:00 2007
numRows = 4
state = OK
completed = true
searchConditions = []
orderByFields = []
projectedFields = [IINC_ID, SUMMARY, TTIME, TAXID,
SPECIFIC_FIELD1, SPECIFIC_FIELD2]
JDBC ROUTE (
name = internet_inc#0
startTime = Wed Jan 10 17:50:03 782 GMT+01:00 2007
endTime = Wed Jan 10 17:50:04 063 GMT+01:00 2007
responseTime = Wed Jan 10 17:50:04 063 GMT+01:00 2007
numRows = 4
state = OK
completed = true
SQLSentence = SELECT t0.iinc_id, t0.summary, t0.ttime,
t0.taxId, t0.specific_field1, t0.specific_field2 FROM test_vdb.internet_inc t0
parameters = []
DBUri = jdbc:mysql://localhost/test_vdb
userName = vdb
connectionTime = 0
cachedStatus = false
)
)
)
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.
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.
G
I∪ R
A 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
• La configuración de las políticas de “swapping” de DataPort mediante las opciones SWAP y SWAPSIZE
(ver sección 18.2.3)
La sentencia ALTER VIEW permite al administrador de Virtual DataPort realizar todas estas operaciones. Su
sintaxis se muestra en la Figura 21.
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>
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,
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.
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.
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.
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.
• 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).
• Una vista que utilice una función de agregación (aunque no haya cláusula GROUP BY) no es actualizable.
Por ejemplo, la siguiente sentencia añade una nueva tupla en la vista internet_inc:
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.
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 ]
<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>
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
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.
UPDATE internet_inc
SET specific_field1="10", specific_field2="10"
WHERE iinc_id=6
<condition> ::=
<condition> AND <condition>
| <condition> OR <condition>
| NOT <condition>
| ( <condition> )
| <value> <binary operator> <value> [ , <value> ]*
| <value> <unary operator>
Por ejemplo, la siguiente sentencia borra las tuplas de la vista internet_inc cuyo valor para el atributo
iinc_id sea mayor que 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.
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.
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.
9 TRANSACCIONES EN DATAPORT
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 Guía Avanzada de VQL
10 PROCEDIMIENTOS ALMACENADOS
DataPort soporta la creación de procedimientos almacenados escritos en el lenguaje JAVA. Esta sección describe
cómo crearlos y cómo importarlos en DataPort utilizando el lenguaje VQL. La distribución de DataPort contiene
diversos ejemplos de procedimientos almacenados (incluyendo su código fuente) en la ruta
DENODO_HOME/samples/vdp/storedProcedures. El fichero README en dicha ruta contiene
instrucciones para compilar e instalar dichos procedimientos.
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.
La interpretación de las cláusulas CLASSNAME y CLASSPATH es la misma que para la sentencia CREATE
PROCEDURE.
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:
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.
o Obtener referencias a una función del servidor (método lookupFunction), para poder
ejecutarlas,
Procedimientos Almacenados 62
Virtual DataPort 4.0 Guía Avanzada de VQL
• 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.
Procedimientos Almacenados 63
Virtual DataPort 4.0 Guía Avanzada de 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.
• 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.
Procedimientos Almacenados 64
Virtual DataPort 4.0 Guía Avanzada de VQL
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.
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.
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).
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.
Figura 34 Creación de un tipo de dato array y del tipo register que contiene
• 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 clave-
valor que forman parte del mismo.
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.
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.
• 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.
Denodo Virtual DataPort soporta los siguientes tipos de permisos globales sobre una base de datos:
• Permisos de lectura: Si un usuario dispone de este permiso sobre una base de datos a nivel global, puede
realizar las siguientes tareas sobre la misma:
o Ver la lista de relaciones base, vistas y/o procedimientos almacenados de la base de datos (se
corresponde con el comando VQL LIST). Si un usuario no tiene permisos de lectura sobre una
base de datos pero sí sobre alguna de sus vistas y/o procedimientos almacenados, el comando
LIST podrá ejecutase pero sólo mostrará el conjunto de vistas y procedimientos sobre las que
el usuario tiene permisos de lectura.
o Ver la información relativa a una relación base, vista o procedimiento almacenado de la base de
datos. Por ejemplo, ver el esquema, métodos de búsqueda, configuración de caché y “swapping”,
etc., de una vista base (se corresponde con el comando VQL DESC).
o Ejecutar consultas sobre cualquier vista y/o procedimiento almacenado de la base de datos (se
corresponde con el comando VQL SELECT).
• Permisos de creación: Si un usuario dispone de este permiso sobre una base de datos a nivel global, puede
realizar las siguientes tareas sobre la misma:
o Creación de DataSources, vistas, relaciones base y procedimientos almacenados en la base de
datos (se corresponde con el comando VQL CREATE).
• Permisos de escritura. Disponer del permiso de escritura implica disponer también automáticamente del
permiso de lectura. Si un usuario dispone de este permiso sobre una base de datos puede realizar sobre
ella las siguientes tareas adicionales:
o Borrado de cualquier vista, relación base y/o procedimiento almacenado de la base de datos.
También podrá borrar cualquier DataSource de la base de datos que haya sido creado por él pero
no podrá borrar DataSources creados por otros usuarios (se corresponde con el comando VQL
DROP).
o Modificación de cualquier vista, relación base y/o procedimiento almacenado de la base de
datos. También podrá modificar cualquier DataSource de la base de datos que haya sido creado
por él pero no podrá modificar DataSources creados por otros usuarios (se corresponde con el
comando VQL ALTER).
• Permisos de conexión. Si un usuario dispone de este permiso sobre una base de datos entonces puede
conectarse a la misma, no pudiendo conectarse en caso contrario. Este tipo de permiso es útil si, por
ejemplo, se desea revocar temporalmente el acceso de un usuario a una base de datos sin por ello tener
que modificar el resto de sus privilegios habituales de forma manual.
Denodo Virtual DataPort también soporta la particularización de los privilegios a vistas y procedimientos
almacenados concretos. Los tipos de permisos que pueden aplicarse a una vista y/o a un procedimiento almacenado
de una base de datos son:
• Permisos de lectura: Si un usuario dispone de este permiso sobre una vista o procedimiento almacenado,
puede realizar las siguientes tareas sobre dichos componentes:
o Ver la información relativa a una relación base, vista o procedimiento almacenado. Por ejemplo,
ver el esquema, métodos de búsqueda, configuración de caché, “swapping”, ... de una vista (se
corresponde con el comando VQL DESC).
o Ejecutar consultas sobre la vista o procedimiento almacenado (se corresponde con los comandos
VQL SELECT o CALL).
o Crear nuevas vistas que lo utilicen, siempre que disponga de permisos de creación dentro de la
base de datos a la que pertenece. Se corresponde con el comando VQL CREATE VIEW.
o Si un usuario no tiene permisos de lectura sobre una base de datos pero sí sobre alguna de sus
vistas y/o procedimientos, el comando LIST podrá ejecutase pero sólo mostrará dichos
componentes.
• Permisos de escritura. Disponer del permiso de escritura implica disponer también automáticamente del
permiso de lectura. Si un usuario dispone de este permiso sobre una vista y/o procedimiento almacenado
puede realizar sobre ella las siguientes tareas adicionales:
o Borrado del componente (se corresponde con el comando VQL DROP).
o Modificación del componente (se corresponde con el comando VQL ALTER).
• Permisos de Inserción. Permite insertar tuplas en la vista a través de sentencias INSERT. No aplicables a
procedimientos almacenados.
• Permisos de Borrado. Permite borrar tuplas de la vista a través de sentencias DELETE. No aplicables a
procedimientos almacenados.
Al instalar el servidor se crea un usuario de administración por defecto cuyo nombre de usuario es admin y su
contraseña es también admin.
Las siguientes secciones describen, respectivamente, cómo crear nuevas bases de datos, cómo modificarlas o
borrarlas, cómo crear nuevos usuarios y, finalmente, cómo modificar o borrar los usuarios existentes.
Una vez creada una base de datos, un usuario administrador puede modificar su descripción utilizando la sentencia
ALTER DATABASE (ver Figura 38).
{ DEFAULT |
[ON | OFF] (
[SWAPSIZE <megabytes:integer>]
[BLOCKSIZE <megabytes:integer>]
)
}
]
[ <grant> ]*
<grant> ::= (see section 12.3.6.1)
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.
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:
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).
[ <grant> ]*
<authentication> ::=
<password:literal> [ENCRYPTED]
| LDAP (
DATASOURCE <databaseName:identifier>.<dataSourceName:identifier>
USERNAME <name:literal>
)
Un usuario administrador puede eliminar usuarios del servidor utilizando la sentencia DROP (ver apartado 15). No es
posible borrar el administrador predefinido “admin”.
<authentication> ::=
PASSWORD <password:literal>
| LDAP (
[DATASOURCE
<databaseName:identifier>.<dataSourceName:identifier> ]
[ USERNAME <name:literal> ]
)
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.
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>
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>
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>
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”.
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 SESSION
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.
- 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).
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.
LIST PROCEDURES
Por ejemplo, para listar las bases de datos existentes se ejecuta la siguiente sentencia:
LIST DATABASES;
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:
Y para listar los operadores que operan sobre el tipo de dato int se utiliza la sentencia:
El servidor Virtual DataPort también permite eliminar un elemento específico del diccionario de datos, mediante la
sentencia DROP.
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:
16 OTROS COMANDOS
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.
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.
La sentencia HELP, si no recibe ningún parámetro, presenta su propia sintaxis. Opcionalmente, admite como
parámetro el nombre del comando para el que se desea la ayuda. Por ejemplo, la sentencia de la Figura 51 permite al
usuario conocer en detalle la sintaxis del comando ALTER TABLE.
HELP <topic>
<topic> ::=
ALTER DATABASE
| ALTER DATASOURCE { ARN | CUSTOM | DF | GS | JDBC | LDAP | ODBC | WS |
XML }
| ALTER PROCEDURE
| ALTER TABLE
Otros Comandos 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
}
| CREATE DATASOURCE { ARN | CUSTOM | DF | GS | JDBC | LDAP | ODBC | WS |
XML }
| DELETE
| DESC
| DROP
| HELP HELP
| INSERT
| LIST
| QUERY WRAPPER { ARN | CUSTOM | DF | GS | ITP | JDBC | MY | ODBC | WS |
XML }
| ROLLBACK
| SELECT
| UPDATE
| XML2BIN
Es posible obtener información detallada respecto a la sintaxis general VQL utilizando la sentencia HELP HELP.
Otros Comandos 83
Virtual DataPort 4.0 Guía Avanzada de VQL
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.
• ITPilot: Se utiliza para incorporar en el sistema wrappers para fuentes semi-estructuradas creados con
Denodo ITPilot [6]. Estas fuentes pueden estar accesibles desde el sistema de ficheros local, vía web, o vía
FTP. El tipo de fuente más importante para el que se utiliza este envoltorio son las fuentes web, pero puede
ser utilizado para otras fuentes semi-estructuradas (ver documentación de Denodo ITPilot [6]).
• JDBC: Extraen datos desde una Base de Datos Remota vía JDBC.
• ODBC: Extraen datos desde una Base de Datos Remota vía ODBC.
• Servicios Web: Extraen datos realizando invocaciones a operaciones definidas por servicios web.
• XML: Son aquellos que permiten extraer datos encapsulados en ficheros XML, que pueden seguir
opcionalmente una cierta DTD o esquema.
• DF: Extraen datos de ficheros de texto planos, que utilizan determinados caracteres como delimitadores de
tupla y campo. Entre los ficheros soportados se encuentran aquellos en formato CSV que suelen obtenerse
como resultado de volcar datos de bases de datos o documentos Excel.
• ARACNE. Permiten acceder a índices sobre información no estructurada creados utilizando Denodo Aracne
[16].
• GOOGLE MINI. Permiten acceder a índices sobre información no estructurada creados con la herramienta
de búsqueda Google Mini [17].
• CUSTOM (también llamados MY): Extraen la información de una fuente, a través de una implementación
Java específica. Este tipo de wrapper permite la construcción ad-hoc de un programa envoltorio para un
tipo de fuente específico.
Para todos los wrappers excepto los de tipo ITPilot existen elementos datasource para encapsular cierta información
de acceso y configuración a la fuente de datos. Adicionalmente existe un tipo de datasource para representar los
servidores LDAP que pueden ser utilizados para autenticar a usuarios de DataPort (ver sección 12.3.3). Los
datasources LDAP no tienen wrappers asociados.
En esta sección se describe la forma de crear en Virtual DataPort nuevos wrappers (y sus datasources) de cualquiera
de estos tipos.
El resto de esta sección se estructura cómo sigue. Las secciones 17.1 y 17.2 definen aspectos de interés general para
el resto de la sección: las conversiones válidas de tipos entre los wrappers y las relaciones base en Virtual DataPort,
y las formas de especificar rutas a recursos dentro de Virtual DataPort. La sección 17.3 especifica cómo añadir al
sistema fuentes de datos (DataSources) de los diversos tipos disponibles. Finalmente, la sección 17.4 muestra cómo
crear wrappers para cada uno de estos tipos de fuente.
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]).
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.
Tabla 3 Otras conversiones válidas entre tipos JAVA y tipos Virtual DataPort
Por otra parte, los wrappers pueden proporcionar elementos compuestos como arrays y registros, que se asocian
directamente a arrays y registros utilizados por el servidor VDP.
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.
double double
float float
int int
string java.lang.String
url java.lang.String
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.
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.
byte java.lang.Byte
unsignedbyte
Double java.lang.Double
Float java.lang.Float
short java.lang.Short
unsignedshort
Boolean java.lang.Boolean
string java.lang.String
normalizedString
token
base64Binary
hexBinary
duration
dateTime
date
time
gYearMonth
gMonthDay
En Virtual DataPort existen tres tipos de rutas, que se describen a continuación junto con los parámetros que es
necesario especificar habitualmente para cada una de ellas en una sentencia VQL:
• LOCAL: Ruta que accede a un recurso dentro de un sistema de ficheros local. Necesita los siguientes
parámetros:
o El nombre de la clase utilizada para implementar la conexión utilizada por la ruta. Para este tipo
de rutas, se proporciona una única clase conexión: LocalConnection.
• 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:
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.
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]).
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.
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.
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> ]* ] )
]
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.
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.
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> ]* ] ) ]
[, <operator:identifier> ]* ] ) }
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.
<source configuration property> ::= (see CREATE DATASOURCE ODBC for details)
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.
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.
<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>
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.
<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>
17.3.5 DataSources DF
Este tipo de origen de datos permite que Denodo Virtual DataPort pueda acceder a los datos contenidos en ficheros
planos en formato CSV (Comma Separated Values) o similar.
Para definir un origen de datos de fichero delimitado es necesario especificar los siguientes elementos:
- ROUTE: La ruta al fichero de texto de tipo delimitado del que extraer la información. Puede incluir variables
de interpolación para parametrizar la ruta de acceso en función de las condiciones de la consulta efectuada
sobre el datasource (ver sección 18.4).
- COLUMNDELIMITER: Cadena de caracteres utilizada como separador de elementos en el fichero
delimitado.
- ENDOFLINEDELIMITER: Cadena de caracteres utilizada como separador de tuplas de datos en el fichero
delimitado (por defecto se utilizará el retorno de carro, \n).
- BEGINDELIMITER: Expresión regular (en formato JAVA) que identifica el lugar del fichero delimitado dónde
se comenzará a buscar tuplas (o cabeceras si la opción “header” ha sido seleccionada). Si no se especifica
se asume como valor el comienzo del fichero. Si se añade el modificador ISDATA entonces el texto que
encaje con la expresión regular se considerará como parte del espacio de búsqueda.
- ENDDELIMITER: Expresión regular (en formato JAVA) que identifica el lugar del fichero delimitado hasta el
que se buscarán tuplas. Si no se especifica se asume como valor el fin del fichero. Si se añade el
modificador ISDATA entonces el texto que encaje con la expresión regular de fin se considerará como
parte del espacio de búsqueda de tuplas.
- HEADER: Permite especificar si la primera tupla de datos del fichero debe utilizarse como cabecera, es
decir, como metainformación que proporciona el nombre de los diferentes campos que componen una tupla
del fichero delimitado.
El modificador OR REPLACE permite que, si ya existe un origen de datos con el mismo nombre, su definición sea
reemplazada por la nueva.
<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>
<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>
- 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.
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.
- 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.
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.
- 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.
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.
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.
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 GROUP BY (DELEGATEGROUPBY, DS: JDBC, ODBC). Indica si la fuente permite la delegación
de la cláusula GROUP BY. Por defecto, el valor es “true” para fuentes JDBC y ODBC.
• Delegate HAVING clause (DELEGATEHAVING, DS: JDBC, ODBC). Indica si la fuente permite la
delegación de la cláusula HAVING. Por defecto, el valor es “true” para fuentes JDBC y ODBC.
• Delegate Inner Join (DELEGATEINNERJOIN, DS: JDBC, ODBC). Indica si la fuente permite la
delegación del operador Inner Join. Por defecto, el valor es “true” para fuentes JDBC y ODBC.
• Delegate Join (DELEGATEJOIN, DS: JDBC, ODBC). Indica si la fuente permite la delegación del
operador Join. Por defecto, el valor es “true” para fuentes JDBC y ODBC.
• Delegate Left Function (DELEGATELEFTFUNCTION, DS: JDBC, ODBC). Indica si la fuente permite
delegar condiciones con funciones en la parte izquierda. Por defecto, el valor es “true” para fuentes JDBC y
ODBC.
• Delegate Left Literal (DELEGATELEFTLITERAL, DS: JDBC, ODBC). Indica si la fuente permite delegar
condiciones con constantes en la parte izquierda. Por defecto, el valor es “true” para fuentes JDBC y ODBC.
• Delegate Natural Outer Join (DELEGATENATURALOUTERJOIN, DS: JDBC, ODBC). Indica si la fuente
permite la delegación del operador Natural Outer Join. Por defecto, el valor es “false” para fuentes JDBC y
ODBC.
• Delegate NOT Condition (DELEGATENOTCONDITION, DS: JDBC, ODBC). Indica si la fuente permite la
delegación de la condición NOT. Por defecto, el valor es “true” para fuentes JDBC y ODBC.
• Delegate 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 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 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.
• 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 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 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 Scalar Functions List (DELEGATESCALARFUNCTIONS, DS: JDBC, ODBC). Indica qué
funciones escalares son delegables. En las fuentes JDBC y ODBC, la lista está compuesta por las funciones
ABS, CEIL, COALESCE, CONCAT, DIV, FLOOR, GETDAY, GETHOUR,
GETMINUTE, GETSECOND, GETMONTH, GETYEAR, LEN, LOG, LOWER, MOD,
MULT, NOW, POWER, REPLACE, ROUND, SQRT, SUBTRACT, SUM,
TEXTCONSTANT, TRIM y UPPER.
• Delegate Operators List (DELEGATEOPERATORSLIST, DS: JDBC, ODBC). Indica qué operadores son
delegables. En las fuentes JDBC y ODBC, la lista está compuesta por los operadores =, <>, <, <=,
>, >=, in, between, contains, containsor, like, is null, is not
null, is true e is false.
• Operator Properties. Permite especificar propiedades sobre el soporte proporcionado por la fuente de datos
para un operador específico. Para cada operador, se especifica su nombre (atributo operator_name) y
su lista de propiedades. En la actualidad, estas propiedades existen solamente para el operador
contains (ver sección 17.3.10.1).
Ejemplo: Supóngase que la creación de un DataSource procedente de una fuente relacional MySQL de una versión
muy antigua no admite la cláusula USING en joins. Por defecto, VDP tiene este parámetro con un valor “true”, por lo
que es necesario cambiarlo. Para ello, es necesario modificar el valor en la sentencia de creación de la siguiente
manera:
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.
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.
• 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:
• 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:
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.
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.
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.
<field> ::=
<name:identifier> [ = <mapping:literal> ] : <type:literal>
[ ( { OBL | OPT } ) ] [ <inline constraints> ]*
| <name:identifier> [ = <mapping:literal> ] : ARRAY OF (<register field> )
[ <inline constraints> ]*
| <name:register field>
<source configuration property> ::= (see CREATE WRAPPER JDBC for details)
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.
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.
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).
<field> ::=
<name:identifier> [ = <mapping:literal> ] : <type:literal>
[ ( { OBL | OPT } ) ] [ <inline constraints> ]*
| <name:identifier> [ = <mapping:literal> ] : ARRAY OF (<register field>)
[ <inline constraints> ]*
| <name:register field>
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.
<source configuration property> ::= (see CREATE WRAPPER ODBC for details)
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.
<field> ::=
<name:identifier> [<regexp>] [ ( { OBL | OPT } ) ]
[ ( <alias:literal> [, <alias:literal> ]* ) ]
[ <inline constraints> ]*
| <name:identifier>:ARRAY OF ( <register field> ) [ <inline constraints>
]*
| <name:register field>
<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> )
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
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).
• CONNECTIONNAME: Clase Java utilizada para realizar la conexión. Una conexión se crea a partir de una
cadena de caracteres compuesta por dos partes: el nombre de la conexión y los parámetros de
inicialización de la misma (opcionales, pueden indicarse sin asociar ningún valor). Ambos elementos deben
ir separados por comas. La clase especificada aquí actúa como clase por defecto para aquellas rutas del
wrapper que no especifiquen explícitamente su clase conexión. Por defecto se utilizará la clase
http.HTTPClientConnection.
Virtual DataPort incluye diversas clases conexión para los diversos tipos de rutas disponibles. En la
descripción de la sintaxis de cada tipo de ruta (ver sección 17.2) se muestran las clases conexión
disponibles.
• CREATENEWINSTANCE: Si es necesario crear una nueva conexión para cada petición o se deben
intentar reutilizar conexiones existentes (este parámetro sólo se tiene en cuenta en las rutas que no
especifiquen su propia clase conexión).
• La lista de rutas a las que es necesario acceder para obtener la información de la fuente externa. La
especificación de rutas se realiza tal y como se vio en la sección 17.2, añadiendo una especificación de
extracción de los datos que contiene el recurso apuntado por la ruta definida (la especificación debe estar
escrita utilizando el lenguaje de extracción de datos DEXTL de ITPilot [6]). Además, los patrones de acceso
pueden ser parametrizados utilizando variables del contexto y funciones de interpolación (ver sección 18.4).
Otra consideración importante a la hora de construir el wrapper, es que los resultados devueltos por la consulta
efectuada deben ser compatibles con el esquema de la relación base a la que dicho wrapper está asociado en Virtual
DataPort. Más concretamente, los nombres de los atributos obtenidos como resultado de la extracción de datos,
deben coincidir con los de la relación base, y además sus valores deben ser compatibles con sus tipos de datos en la
relación base.
A la metainformación general que se puede indicar relativa al esquema de salida que proporciona el wrapper (ver
apartado 17.4.2), se puede además añadir sobre los campos de tipo simple una expresión regular con la que deben
encajar todos los resultados (se descartarán aquellas tuplas en las que el valor para un campo no encaje con su
expresión regular asociada). En el caso de los wrappers ITPilot de versiones anteriores a ITPilot 4.0, los campos de
tipo simple son todos textuales.
También es posible añadir una lista de alias para cada campo del wrapper. Estos alias podrán ser utilizados por
ITPilot para las labores de mantenimiento automático de los wrappers (véase [6] para más información).
Adicionalmente, tanto en la sentencia de creación como de modificación de un wrapper ITPilot es posible indicar si
se desea activar el mantenimiento automático para el wrapper.
17.4.5.2.1 Sustituciones
Los wrappers ITPilot utilizados con las versiones de ITPilot anteriores a la 4.0 pueden ser configurado para utilizar
secuencias de acceso diferentes en función de las condiciones de la consulta que Virtual DataPort le pide resolver.
Para ello, el administrador puede especificar las denominadas sustituciones. Una sustitución especifica:
• Una lista de precondiciones sobre los atributos incluidos en la consulta. Una precondición representa un
requisito que deben satisfacer las condiciones de consulta.
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.
diferentes parámetros requeridos para la ejecución de la operación y qué datos de salida formarán parte del
resultado del wrapper.
<field> ::=
<name:identifier> = <mapping:literal> [ VALUE <literal> ]
[ ( { OBL | OPT } ) ] [ <inline constraints> ]*
| <name:identifier> = <mapping:literal> : ARRAY OF ( <register field> )
[ <inline constraints>]*
| <name:register field>
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.
<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>
Un wrapper XML se define a través de un datasource XML, que identifica un recurso XML local o remoto.
El wrapper XML analiza la estructura del documento XML y devuelve como atributos las etiquetas XML de primer
nivel (utilizando su nombre como nombre de atributo), encapsulando el resto de elementos en tipos compuestos.
Pueden utilizarse operaciones de “aplanamiento” (ver sección 6.1.2) para transformar la relación base resultante de
la forma deseada.
Al igual que en el resto de wrappers, es posible especificar el esquema de salida de los datos proporcionados por el
wrapper, permitiendo seleccionar sólo aquellos elementos del documento XML que interesan e incluso cambiar su
nombre (en mapping se especifica el nombre en el wrapper; name almacena el nombre externo).
La sentencia de creación del wrapper también admite el modificador OR REPLACE. En caso de ser especificado, si
ya existiese un wrapper con el mismo nombre, su definición sería reemplazada por la nueva.
Por último, también se permite especificar ciertas propiedades del wrapper (SOURCECONFIGURATION) que
DataPort tendrá en cuenta para determinar qué operaciones pueden realizarse sobre el mismo. En la declaración de
la sentencia correspondiente se indican las propiedades aplicables (Figura 81), y son explicadas en la sección
17.4.12.
17.4.8 Wrapper DF
Virtual DataPort soporta la creación de wrappers de ficheros delimitados CSV y similares. Para crear un wrapper de
este tipo es necesario indicar el nombre del origen de datos (cómo acceder al fichero que contiene los datos) –
DATASOURCENAME -. De forma opcional como en el resto de wrappers, es posible especificar el esquema de
datos devuelto por el wrapper (OUTPUTSCHEMA).
La sentencia de creación del wrapper también admite el modificador OR REPLACE. En caso de ser especificado, si
ya existiese un wrapper con el mismo nombre, su definición sería reemplazada por la nueva.
Por último, también se permite especificar ciertas propiedades del wrapper (SOURCECONFIGURATION) que
DataPort tendrá en cuenta para determinar qué operaciones pueden realizarse sobre el mismo. En la declaración de
la sentencia correspondiente se indican las propiedades aplicables (Figura 83), y son explicadas en la sección
17.4.12.
NOTA: En este tipo de wrappers, actualmente no se soporta el “mapping” ni la especificación de registros o arrays
como elementos del outputschema.
<field> ::=
<name:identifier> [ = <mapping:literal> ]
[ ( { OBL | OPT } ) [ EXTERN ] ]
[ ( [ <value:literal> [, <value:literal> ]* ) ] ]
[ <inline constraints> ]*
| <name:register field>
Para crear un wrapper de este tipo es necesario indicar el nombre del origen de datos – DATASOURCENAME – y
el nombre del manejador Aracne – HANDLERNAME – a partir del cuál se va a crear el wrapper.
Como en el resto de wrappers, es posible especificar el esquema de datos devuelto por el wrapper
(OUTPUTSCHEMA). En este caso, el esquema debe contener una serie de atributos fijos que deben estar presentes
siempre que el manejador escogido de Denodo Aracne los exporte. De estos atributos fijos sólo será posible
modificar su nombre. Además, el esquema puede incluir también atributos específicos que se correspondan con otros
campos específicos exportados por el manejador Aracne.
A continuación se describen los atributos fijos (véase [16] para más detalle):
• TASK. Nombre de la tarea Aracne que obtuvo e indexó este documento. Es de tipo cadena de caracteres.
• PUBDATE. Fecha de publicación del documento. Sólo aparece en el caso de que el índice contenga
documentos de tipo RSS. Es de tipo cadena de caracteres.
• TITLE. Título generado por Aracne para el documento. Es de tipo cadena de caracteres.
• ANCHORTEXT. Si se trata de un documento que Aracne obtuvo mediante un proceso de crawling web,
contiene el texto del enlace utilizado para acceder al documento. Es de tipo cadena de caracteres.
• SUMMARY. Resumen generado por Aracne para el documento. Es de tipo cadena de caracteres.
• URL. En el caso de documentos obtenidos a través de la web, contiene laURL original del documento. En el
caso de documentos RSS se corresponde con el valor del campo link del item RSS. En el caso de documentos
obtenidos de un sistema de ficheros local, contiene la ruta al mismo. En el caso de documentos obtenidos a
partir de un servidor de correo electrónico contiene el nombre del servidor de correo y el nombre de la cuenta a
la que pertenece el correo. Es de tipo cadena de caracteres.
• IDENTIFIER. URL normalizada. Es de tipo cadena de caracteres.
• CONTENT. Contenido “útil” del documento generado por Aracne. Véase la Guía del Administrador de Aracne
[16] para más detalle. Es de tipo cadena de caracteres.
• DESCRIPTION. Sólo aparece en el caso de que el índice contenga documentos de tipo RSS. En ese caso
toma el valor del elemento DESCRIPTION del documento RSS. Es de tipo cadena de caracteres.
• MODIFIED. Fecha de última modificación del documento en el índice.
• SEARCHABLECONTENT. Campo añadido por DataPort que almacena la concatenación del contenido de los
principales campos fijos textuales del índice (título, resumen, contenido, anchortext,…), así como de los campos
específicos que el índice pueda contener. Es el campo sobre el que se suelen realizar las búsquedas.
• LEVEL Nivel de profundidad de crawling en el que se obtuvo el documento. Es de tipo cadena de caracteres.
• TYPE. Tipo de contenido: html, pdf, rss, etc. Es de tipo cadena de caracteres.
• TITLEXML. Título del documento en XML con información sobre la estructura visual del contenido (párrafos).
Este campo se utiliza para la representación visual del título, no para búsquedas. Es de tipo cadena de
caracteres.
• SUMMARYXML. Resumen del documento en XML que informan sobre la estructura visual del contenido
(párrafos). Este campo se utiliza para la representación visual del resumen, no para búsquedas. Es de tipo
cadena de caracteres.
• PATH. En el caso de que el servidor Aracne guarde una copia local al documento, contiene la ruta al mismo. Es
de tipo cadena de caracteres.
• SCORE. Indicación de la relevancia relativa del documento para la consulta. Habitualmente los resultados de
una búsqueda se devuelven ordenados decrecientemente por SCORE. Es de tipo flotante.
• MAXDOCS. Atributo añadido por DataPort que permite restringir el número máximo de resultados devueltos por
una búsqueda. Es de tipo entero.
• CATEGORIES. Sólo puede aparecer en el caso de que el índice contenga documentos de tipo RSS que
contengan un elemento CATEGORIES. En ese caso toma el valor de dicho elemento del documento RSS. Es de
tipo cadena de caracteres.
Además, Denodo Aracne es capaz de generar automáticamente las palabras más relevantes de un documento o de
un campo del mismo, de acuerdo a la medida de relevancia TFIDF (Term Frequency Inverse Document Frequency).
Estos términos pueden ser incluidos en campos adicionales del esquema del wrapper DataPort. El uso de la cláusula
FILTERMAINTERMS está también relacionado con esta funcionalidad. Véase la sección 17.4.9.1.
La sentencia de creación del wrapper también admite el modificador OR REPLACE. En caso de ser especificado, si
ya existiese un wrapper con el mismo nombre, su definición sería reemplazada por la nueva. La sintaxis de creación
se muestra en la Figura 88.
<field> ::=
<name:identifier> = <mapping:literal> [ VALUE <literal> ] :
<type:literal>
[ ( { OBL | OPT } ) ]
| <name:identifier> = <mapping:literal> : ARRAY OF ( <register field> )
[ <inline constraints>]*
| <name:register field>
En la siguiente figura se muestra un ejemplo de creación de un wrapper Aracne. Los campos del wrapper deben
incluir los antes expuestos siempre que el manejador escogido de Denodo Aracne también los incluya. En esos
campos, para que el wrapper funcione correctamente, la única modificación posible es posible cambiar su nombre.
En el ejemplo, el nombre del campo TITLE es cambiado por DOCNAME. En el ejemplo, también se añade un
campo para contener los términos más relevantes del documento (ver sección 17.4.9.1).
);
<field> ::=
<name:identifier> = <mapping:literal> [ VALUE <literal> ] :
<type:literal>
[ ( { OBL | OPT } ) ]
| <name:identifier> = <mapping:literal> : ARRAY OF ( <register field> )
[ <inline constraints>]*
| <name:register field>
<name:identifier> = <mapping:literal> :
REGISTER OF ( [ <field> [, <field> ]* ] )
• 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:
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.
• SITECOLLECTIONS. Este parámetro es obligatorio. Especifica, dentro del servidor GoogleMini, sobre qué
colecciones buscar. Las colecciones son creadas por el administrador del servidor Google Mini. Su nombre es
sensible a mayúsculas/minúsculas. Es posible especificar varias colecciones separadas por comas. En ese caso,
se buscará por todas ellas. Si se está accediendo a un servidor externo, la colección a buscar puede obtenerse
normalmente examinando el valor del parámetro site en los URLs de invocación.
• CLIENT: Este parámetro es opcional. Identifica al cliente que realiza las consultas. El servidor Google Mini
puede estar configurado para comportarse de forma diferente en función del cliente que emita una consulta.
• LANGUAGES: Este parámetro es opcional. Si se especifica, se devolverán sólo documentos en el lenguaje
especificado. El lenguaje debe ser un valor de los enumerados en la documentación de Google Mini [18].
• NUMKEYMATCH: Este parámetro es opcional. Google Mini permite al administrador
determinar manualmente la prioridad de las páginas a la hora de mostrarse en
los resultados de una búsqueda. Este parámetro recibe un valor entero entre 0 y 5, dónde 5 siginifica la máxima
prioridad. Si se
establece este valor, las búsquedas sólo devolverán las páginas cuya
prioridad sea la especificada o superior.
Como en el resto de wrappers, es posible especificar el esquema de datos devuelto por el wrapper
(OUTPUTSCHEMA). En este caso, el esquema debe constar de una serie de campos fijos y sólo será posible
modificar su nombre. A continuación se describe cada campo:
• TITLE. Título generado por Google Mini para el documento. Es de tipo cadena de caracteres.
• SUMMARY. Resumen generado por Google Mini para el documento. Es de tipo cadena de caracteres.
• URL. URL del documento. Es de tipo cadena de caracteres.
• MIMETYPE. Tipo MIME del documento. Es de tipo cadena de caracteres.
• RATING. Prioridad asignada manualmente por el administrador de Google Mini para el documento. Puede
tomar valores entre 0 y 5, donde 5 significa máxima prioridad. Es de tipo entero.
• MAXDOCS. Campo añadido por DataPort que permite restringir el número máximo de resultados devueltos por
una búsqueda. Es de tipo entero.
• METAS. Atributo compuesto de tipo array de registros (ver sección 18.1) que contiene los tags meta del
documento. Cada registro tiene dos campos de tipo cadena de caracteres, que indican el nombre del metatag
(metakey) y su valor (metavalue).
• CONTENT. Contenido del documento. Es el campo utilizado habitualmente para las búsquedas. Es de tipo
cadena de caracteres.
• SITE. Permite restringir los documentos devueltos a aquellos que pertenezcan a un dominio determinado (e.g.
‘acme.com’). Es de tipo cadena de caracteres.
• FILETYPE. Extensión del fichero del documento. Es de tipo cadena de caracteres.
La sentencia de creación del wrapper también admite el modificador OR REPLACE. En caso de ser especificado, si
ya existiese un wrapper con el mismo nombre, su definición sería reemplazada por la nueva. La sintaxis de creación
se muestra en la Figura 88.
<field> ::=
<name:identifier> = <mapping:literal> [ VALUE <literal> ] :
<type:literal>
[ ( { OBL | OPT } ) ]
| <name:identifier> = <mapping:literal> : ARRAY OF ( <register field> )
| <name:register field>
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.
<field> ::=
<name:identifier> = <mapping:literal> [ VALUE <literal> ] :
<type:literal>
[ ( { OBL | OPT } ) ]
| <name:identifier> = <mapping:literal> : ARRAY OF ( <register field> )
| <name:register field>
Para crear un nuevo wrapper de tipo CUSTOM, es necesario extender dos clases Java:
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.
• 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.
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 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]).
• doRun. (obligatorio) Este método será invocado por DataPort para ejecutar una consulta sobre el wrapper.
Recibe como parámetro la lista de condiciones de consulta que DataPort delega al wrapper para su
ejecución sobre la fuente. Esta lista está compuesta por objetos de tipo
com.denodo.vdb.engine.wrapper.condition.WrapperCondition (ver
documentación Javadoc[4]).
• doInsert. En el caso de que el wrapper soporte inserciones, este método será invocado por DataPort
para ejecutar una sentencia INSERT. Recibe como parámetro una lista de nombres de atributos y una
lista de los valores a insertar.
• doUpdate. En el caso de que el wrapper soporte actualizaciones, este método será invocado por
DataPort para ejecutar una sentencia UPDATE. Recibe como parámetros una lista de los atributos a
modificar, una lista con los nuevos valores y una lista de condiciones de consulta compuesta por objetos
com.denodo.vdb.engine.wrapper.condition.WrapperCondition (ver
documentación Javadoc [4]).
• doDelete. En el caso de que el wrapper soporte borrados, este método será invocado por DataPort para
ejecutar una sentencia DELETE sobre el wrapper. Recibe como parámetro una lista de condiciones de
consulta compuesta por objetos
com.denodo.vdb.engine.wrapper.condition.WrapperCondition (ver
documentación Javadoc[4]).
• prepare. En el caso de que el wrapper soporte transacciones, este método será invocado para preparar
una transacción.
• commit. En el caso de que el wrapper soporte transacciones, este método será invocado para confirmar
una transacción.
• rollback. En el caso de que el wrapper soporte transacciones, este método será invocado para
deshacer los cambios de una transacción.
• stop. (obligatorio) Este método será invocado por DataPort para detener la ejecución de un wrapper.
La implementación de estos métodos puede acceder al valor de los parámetros de configuración del wrapper a través
del método Map getParameters(). Para cada parámetro, existe una clave en el mapa de la forma
MetaPayRollWrapper.PNAME donde PNAME es el nombre del parámetro.
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)
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.
La Figura 91 muestra la sintaxis de creación de un wrapper de tipo CUSTOM. El único parámetro obligatorio que
recibe en su creación –además de un nombre que lo identifica- es el nombre del datasource a partir del cuál se
creará (ver sección 17.3.9).
Si los wrappers del datasource admiten parámetros de configuración, la cláusula PARAMETERS permite
especificarlos.
También se admite el modificador OR REPLACE. En caso de ser especificado, si ya existiese un wrapper con el
mismo nombre, su definición sería reemplazada por la nueva.
Por último, también se permite especificar ciertas propiedades del wrapper (SOURCECONFIGURATION) que
DataPort tendrá en cuenta para determinar qué operaciones pueden realizarse sobre el mismo. En la declaración de
la sentencia correspondiente se indican las propiedades aplicables (Figura 91), y son explicadas en la sección
17.4.12.
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.
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.
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:
o Default: VDP asigna un valor por defecto dependiendo del tipo de fuente. En el caso de fuentes
relacionales, el valor por defecto es “true”.
o true: la fuente de datos permite las operaciones de inserción.
o false: la fuente de datos no permite las operaciones de inserción.
- Allow Delete (ALLOWDELETE): indica si la fuente de datos subyacente admite operaciones de borrado de
filas. Es aplicable a bases de datos relacionales (accesibles mediante JDBC y ODBC) y wrappers CUSTOM. Los
posibles valores son:
o 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.
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:
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.
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.
18 CARACTERÍSTICAS AVANZADAS
En esta sección se describen algunas características avanzadas de Virtual DataPort que, si bien no siempre son
necesarias en las labores de administración más habituales, pueden ser de interés en ciertos casos.
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 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.
• 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.
• 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:
CITY:text,
COUNTRY:text
);
CO
text register
NT
AC
E
M
TA
NA
DD
SURNAME
RE
SS
L
AI
DR
M
ES
S
text register
CO
T
EE
UN
R
TRY
ST
CITY
TITLE AUTHOR
Book1 NAME SURNAME CONTACTADDRESS
Name1 Surname1 MAIL ADDRESS
Author1@authors.com STREET CITY COUNTRY
Street1 City1 Country1
MAIL ADDRESS
Author2@authors.com STREET CITY COUNTRY
Street2 City2 Country2
book1 array
[0] [1]
CO
CO
register register
NT
NT
AC
AC
E
E
M
M
TA
TA
NA
NA
DD
DD
SURNAME SURNAME
RE
RE
SS
SS
[0] [1]
[1] [0]
AD AD AD AD
L L L L
AI DR AI DR
AI DR AI DR
M ES M ES M ES M ES
S S S S
CO
CO
CO
ET
ET
ET
ET
UN
UN
UN
UN
RE
RE
RE
RE
TR
TR
TR
TR
ST
ST
ST
ST
street1 city1 country1 street2 city2 country2 street3 city3 country3 street4 city4 country4
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
);
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:
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):
NOTA: En el caso de especificación de atributos compuestos en condiciones de consulta y para evitar ambigüedades
entre nombre de tabla y nombre de atributo, los nombres de atributo (opcionalmente <nombre de
tabla>.<nombre de atributo>) se especificarán entre paréntesis, especificando los campos de los
elementos compuestos a continuación (separados por puntos o indexados con un entero entre corchetes).
Finalmente, se muestran algunos ejemplos de consultas que podrían realizarse sobre la relación:
1. Para todos los libros que contienen en su título la palabra ‘java’, se obtiene su título y el nombre de cada uno de
sus autores.
SELECT TITLE, LIST((AUTHOR).NAME) AS AUTHORLIST
FROM BOOK
WHERE TITLE like '%java%'
GROUP BY TITLE;
2. Para todos los libros que contienen en su título la palabra ‘java’, se obtiene el título y la lista de contactos de cada
uno de sus autores.
SELECT TITLE, LIST((AUTHOR).CONTACTADDRESS) AS AUTHORLIST
FROM BOOK
WHERE TITLE like '%java%'
GROUP BY TITLE;
3. Para todos los libros que contienen en su título la palabra ‘java’, se obtiene su título y la primera dirección de
correo de cada uno de sus autores.
SELECT TITLE,LIST((AUTHOR).CONTACTADDRESS[0].MAIL) AS AUTHORLIST
FROM BOOK
WHERE TITLE like '%java%'
GROUP BY TITLE;
4. Para todos los libros que contienen en su título la palabra ‘java’ y que tengan al menos un autor con alguna
dirección de correo que contenga la palabra ‘.es’, se obtiene el título y el nombre de cada uno de sus autores.
SELECT TITLE, LIST((AUTHOR).NAME) AS AUTHORLIST
FROM BOOK
WHERE (TITLE like '%java%')
AND ( (AUTHOR).CONTACTADDRESS.MAIL like '%.es%' )
GROUP BY TITLE;
5. Para todos los libros que contienen en su título la palabra ‘java’ y que tengan al menos un autor con alguna
dirección en la calle ‘Real’, se obtiene el título y el nombre de cada uno de sus autores.
SELECT TITLE, LIST((AUTHOR).NAME) AS AUTHORLIST
FROM BOOK
WHERE (TITLE like '%java%')
AND ((AUTHOR).CONTACTADDRESS.ADDRESS.STREET like '%Real%')
GROUP BY TITLE;
6. Se obtienen los libros con algún autor que tenga una única dirección de contacto cuyo e-mail sea
john@mail.com, y que viva en la ciudad de Madrid (España) en la calle Real.
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.
Una estrategia de ejecución para un join consta de dos elementos: el método utilizado para implementar la operación
de join y el orden en el que deben considerarse las relaciones de entrada del join. Virtual DataPort soporta los
siguientes métodos de ejecución:
• MERGE. Sólo puede ejecutarse en aquellos casos en los que los datos de las relaciones de entrada están
ordenados por los atributos de join. En ese caso, esta estrategia suele ser la más eficiente y la que menos
memoria consume. En el caso de que los datos no estén ordenados, será posible la utilización de esta
técnica de join si las fuentes involucradas son todas bases de datos (accedidas a través de los wrappers
JDBC u ODBC) ya que en ese caso DataPort puede recuperar los datos ordenados de las fuentes origen. Si
se intenta forzar el uso de esta estrategia en un caso en el que no sea aplicable, DataPort producirá un
mensaje de error.
• NESTED: Este método de ejecución obtiene en primer lugar las tuplas de la primera relación de entrada
que verifican la condición de join y posteriormente, para cada combinación de valores obtenida para los
atributos que participan en el join, se emite una sub-consulta que obtiene las tuplas que se corresponden
con dicha combinación de valores en la segunda relación de entrada. En el caso de que la segunda relación
de entrada provenga de una base de datos, DataPort optimizará este proceso emitiendo una sola sub-
consulta que recupere todos los datos necesarios de la segunda relación. Este método suele ser altamente
eficiente cuando la primera relación de entrada es relativamente pequeña con respecto a la segunda y,
además, la latencia por consulta de la segunda fuente es baja. Al utilizar este método es especialmente
importante el orden de las relaciones de entrada de forma que la primera sea la de menor tamaño
esperado.
• NESTED PARALLEL: Este método de ejecución es similar al método NESTED. La diferencia es que
las sub-consultas emitidas sobre la segunda relación de entrada pueden emitirse en paralelo, mientras que
en el caso de NESTED se emiten secuencialmente. Admite un parámetro adicional que especifica el
número máximo de sub-consultas emitidas en paralelo.
• HASH. Este tipo de join suele ser el más eficiente cuando los datos en las relaciones de entrada no están
ordenados y son grandes. También suele ser el más eficiente cuándo los tiempos de latencia de consulta
de las fuentes de las que proceden los datos son altos (e.g. fuentes web), ya que este tipo de join minimiza
el número de sub-consultas efectuadas sobre las fuentes.
Al crear una vista de tipo join o al escribir una consulta es posible especificar el método de ejecución deseado
especificando los modificadores NESTED, NESTED PARALLEL, MERGE o HASH. Ejemplos:
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:
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>
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)
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).
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:
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:
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:
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 uso de esta opción puede no ser deseable si un wrapper no devuelve siempre todos los resultados de
una consulta efectuada sobre una determinada fuente. Por ejemplo, si un wrapper que accede a una fuente
web devuelve sólo los primeros 100 resultados devueltos por la fuente para la consulta select *
from view where field1 = a , entonces el resultado de aplicar la condición de post-
procesado (field2 = b) sobre los resultados de la consulta puede ser diferente del resultado
obtenido al ejecutar directamente sobre la fuente select * from view where field1 =
a and field2 = b.
Si no se desea utilizar la caché en la relación base, basta usar la opción CACHE OFF. También se permite la
modificación del tiempo de vida de los datos en caché, es decir, el timeout de expiración de los datos en la caché,
utilizando la propiedad TIMETOLIVEINCACHE (expresado en segundos).
El parámetro DELEGATEUNNAMEDVIEWS puede tomar los valores ‘YES’ o ‘NO’. Si no se indica, se asume el
valor ‘YES’.
Al crear vistas utilizando la herramienta de administración gráfica de Virtual DataPort, es posible que el sistema cree
vistas intermedias adicionales (normalmente, de tipo proyección). Estas vistas reciben un nombre interno creado por
DataPort y, por ello, se denominan “vistas sin nombre”. Por ejemplo, supóngase que se crea gráficamente una vista
tipo unión a la que llamaremos U, que se obtiene en base a dos vistas A y B. Si durante el proceso de creación
gráfica de la vista, el usuario elimina un atributo de la vista unión procedente de la vista base A, DataPort añadirá
transparentemente al árbol de U una vista proyección sin nombre por encima de A.
DataPort también puede generar una vista sin nombre cuando se ejecuta una consulta que realiza una proyección o
agregación sobre una vista existente. Por ejemplo, considérese la siguiente consulta:
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.
Los comandos de modificación de una relación base (ALTER TABLE. Ver sección 5.1), de modificación de una
vista (ALTER VIEW. Ver sección 7.1) y de ejecución de una consulta (cláusula CONTEXT del comando SELECT.
Ver sección 6.8) permiten habilitar o deshabilitar el swapping a disco de resultados intermedios mediante la opción
SWAP ON o SWAP OFF. El comando ALTER DATABASE (ver sección 12.3.2) permite fijar la configuración
por defecto para las relaciones base y las vistas de una base de datos determinada.
DataPort realizará “swapping”cuándo se haya escogido SWAP ON y además algún resultado intermedio producido
durante la ejecución de la consulta o vista supere un determinado tamaño máximo. Este tamaño puede indicarse (en
megabytes) utilizando la opción SWAPSIZE de los comandos anteriormente mencionados (el valor por defecto es
de 50 Mb).
Para evitar operaciones de acceso a disco innecesarias que pueden ralentizar la ejecución, puede ser conveniente
deshabilitar el swapping para una determinada vista o para una determinada consulta en la que no se prevean
desbordamientos de memoria.
También puede ser conveniente incrementar para una vista o consulta el valor de SWAPSIZE. Esto es útil cuando
es posible que algún resultado intermedio supere el valor por defecto pero, aún en ese caso, sabemos que el sistema
tendrá memoria suficiente para que no se produzca un desbordamiento. Como norma general, se recomienda que el
valor de SWAPSIZE no sea mayor que la tercera parte de la memoria disponible para la máquina virtual JAVA en la
que se ejecuta el servidor DataPort.
Ejemplos:
Si bien DataPort incluye configuraciones de internacionalización ya creadas para las situaciones más comunes, crear
nuevas configuraciones es un proceso muy sencillo. Esta sección describe detalladamente dicho proceso.
Los parámetros de internacionalización de una localización se pueden dividir en varios grupos. A continuación se
citan los diferentes grupos y se describen en detalle cada uno de los parámetros que los componen:
NOTA: Los parámetros de internacionalización no son sensibles a mayúsculas y minúsculas; por ejemplo,
“timeZone” y “timezone” corresponden a la misma clave.
• Genéricos
o language – Indica el lenguaje que se utiliza en esta localización. Es un código ISO de lenguaje
válido. Estos códigos se especifican con dos letras en minúsculas tal y como se define en ISO-639
[1]. Ejemplos: es (Español), en (Inglés), fr (Francés).
o country – Especifica el país asociado a esta localización. Es un código ISO de país válido. Estos
códigos se corresponden con dos letras en mayúsculas, definidos por ISO-3166 [2]. Ejemplos:
ES (España), ES_EURO (España con moneda EURO), GB (Inglaterra), FR (Francia), FR_EURO
(Francia con moneda EURO), US (Estados Unidos).
• Configuración de la moneda: Permite configurar diferentes propiedades de los valores de tipo money.
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).
o timePattern – Unidad de tiempo en la que se expresan los valores de este tipo en esta
localización. Los valores posibles son: SECOND, MINUTE, HOUR, DAY, WEEK, MONTH y
YEAR.
o datePattern – Indica el formato para las fechas. Para especificar el formato de fechas, se
utilizan caracteres ASCII para indicar las diferentes unidades de tiempo. En la Tabla 8 se muestra
el significado de cada uno de los caracteres reservados que se utilizan en el formato de una
fecha, su presentación y un ejemplo de su utilización. Ejemplo de un formato de fecha: d-MMM-
yyyy H'h' m'm'. Para más información, ver [9], clases java.text.DateFormat y/o
java.text.SimpleDateFormat.
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.
• Configuración de los números reales: Permiten configurar los tipos de datos float y double.
'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' = ''
);
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.
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.
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
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).
19 APÉNDICES
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).
inform*
Tarjeta~
Se puede añadir un parámetro (opcional) que especifique la similitud mínima requerida. Por ejemplo:
tarjeta~0.8
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
[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.
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.4 Agrupaciones
Se permite el uso de paréntesis. Por ejemplo, para buscar "Corp" o "Inc" y "Denodo" se usaría la consulta:
(){}[]^"~*?:\
Para escapar estos caracteres se utiliza \ antes del carácter.
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 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.
- Las búsquedas por frase exacta no están soportadas en el atributo site. Sí lo están en el resto de
atributos.
- Los comodines, las búsquedas difusas, las búsquedas por proximidad, las búsquedas con aumento de
relevancia y las búsquedas por rango no están soportadas.
- Las búsquedas con los operadores lógicos AND, OR y NOT en los atributos title, url y site sólo
son válidas si las condiciones son terminos simples o frases exactas (es decir, en las búsquedas sobre
estos atributos no es posible anidar condiciones lógicas). Esta restricción no existe para el resto de
atributos.
- Para funcionar correctamente, el operador lógico NOT debe aparecer al mismo nivel que un operador
lógico AND. Ejemplo: la búsqueda (term1 AND NOT term2) funcionaría correctamente, no así la
búsqueda (term1 OR NOT term2).
Apéndices 149
Virtual DataPort 4.0 Guía Avanzada de VQL
BIBLIOGRAFÍA
Apéndices 150