Drawing metaphors from the data

En este apartado vamos a introducir la sintaxis del Lenguaje No Generalizado de Acceso a Acontecimientos refiriendo en cada caso a la sintaxis que corresponda utilizando la notación BNF. La sintaxis completa se incluye en el apartado 7.4.4 y la forma de uso de la notación BNF en el Anexo A.

La sintaxis del Lenguaje No Generalizado de Acceso a Acontecimientos tiene una estructura base en la que se introducen variaciones en función de los dos tipos de consultas contemplados que explicaremos con más detalle en los apartados 7.4.2 y 7.4.3. La forma de especificar esto en notación BNF es la siguiente:

<OccurrenceQL> ::= <longitudinal_structure_query> | <occurrences_query>;

1 Consultas para obtener acontecimientos incluidos en una estructura longitudinal (Longitudinal Structure Queries).

A continuación, mostramos una versión simplificada de la sintaxis de este tipo de sentencias, en el apartado 7.4.4 completaremos la definición:

<longitudinal_structure_query> ::=

SELECT [INITIAL OCCURRENCE OF | FINAL OCCURRENCE OF] <longitudinal_structure_type>

[RELATED TO <structure_element> <structure_element_instance> [OF TYPE <type_name>]]

[BETWEEN <date> AND <date> | ON <date>]

[BEFORE <occurrence_instance> | AFTER <occurrence_instance>];

2 Consultas para obtener acontecimientos o elementos de acontecimientos que no Nivel M3: Meta-Metamodelo

Nivel M2: Metamodelo

(Metamodelo de Bases de Acontecimientos)

Nivel M1: Modelo

(Modelos de Base de Acontecimientos)

Nivel M0: Instancia

III El Lenguaje de Acceso a Acontecimientos

constituyen una estructura longitudinal (Occurrences Queries).

A continuación, mostramos una versión simplificada de la sintaxis de este tipo de sentencias, en el apartado 7.4.4 completaremos la definición:

<occurrences_query> ::=

SELECT [INITIAL | FINAL] OCCURRENCE [OF TYPE <occurrence_type>] | <occurrence_element> [OF TYPE <type_name>]

[RELATED TO <occurrence_element> <occurrence_element_instance> [OF TYPE <type_name>]]

[BETWEEN <date> AND <date> | ON <date>]

[BEFORE <occurrence_instance> | AFTER <occurrence_instance>] [ORDER BY <occurrence_elements_with_order_type>];

La variación más sustancial en la sintaxis de ambos tipos de consulta se encuentra en la especificación de la cláusula SELECT, a través de la cual se indica la información que se desea obtener:

• En las consultas del primer tipo, a través de la cláusula SELECT, se refiere al tipo de estructura longitudinal a representar (<longitudinal_structure_type>) y, opcionalmente a los acontecimientos inicial o final de la misma utilizando respectivamente las palabras reservadas INITIALOCCURRENCE OF y FINAL OCCURRENCE OF.

Los tipos de estructura longitudinal contemplados en una determinada implementación del

Framework OcQF dependen de la estrategia de diseño seleccionada y de cómo se defina la dimensión del lenguaje que refiere a las mismas tal y como hemos indicado en el apartado 4.5.

• En las consultas del segundo tipo es posible referir a acontecimientos y a sus elementos. La expresión [INITIAL | FINAL] OCCURRENCE [OF TYPE <occurrence_type>] especifica la forma en la que es posible referir a acontecimientos como parte de la cláusula SELECT.

La expresión alternativa <occurrence_element> [OF TYPE <type_name>] especifica cómo referir a elementos de un acontecimiento (Objeto, Efecto, Ejecución de Protocolo). A través del símbolo <occurrence_element> estamos introduciendo la posibilidad de referir a

elementos propios de un acontecimiento utilizando las palabras reservadas del lenguaje (OBJECT, ACTIVE STATE y PROTOCOL EXECUTION) siempre que la estrategia de diseño seleccionada lo posibilite; a través del símbolo <type_name>, tal y como indicaremos más

adelante, estamos introduciendo la posibilidad de indicar de qué clase de las especificadas en un modelo de base de acontecimientos es el elemento <occurrence_element>.

Esta diferenciación en la cláusula SELECT viene motivada por el hecho de que las estructuras

longitudinales basadas en acontecimientos están dirigidas a mostrar acontecimientos ocurridos a un determinado objeto o conjunto de objetos, por lo que entendemos que no es procedente referir a información parcial de las mismas.

Siguiendo con las consultas del segundo tipo, a través de la cláusula RELATED TO se establecen los criterios de selección de los acontecimientos sobre los que se pide la información. Por ejemplo, a través de esta cláusula podemos especificar que la información a obtener debe referir a acontecimientos producidos sobre objetos de un determinado tipo, a acontecimientos generados por un determinado tipo de ejecución de protocolo, etc. Como parte de esta cláusula, la expresión <occurrence_element> <occurrence_element_instance> [OF TYPE <type_name>] especifica cómo hay que referir a los elementos propios de un acontecimiento; el símbolo <occurrence_element> especifica al

elemento al que se referirá utilizando las palabras reservadas del lenguaje (OBJECT, ACTIVE STATE y PROTOCOL EXECUTION); el símbolo <type_name> se introduce para permitir especificar de qué clase declarada en un modelo de base de acontecimientos es el elemento indicado; el símbolo <occurrence_element_instance> se introduce para permitir referir a una instancia concreta de la clase indicada a través del símbolo <type_name>.

Como hemos podido ver, las cláusulas SELECT y RELATED TO de una consulta pueden referir

tanto a instancias de elementos como a clases o tipos de elementos. Hablamos de Clase o

Tipo cuando referimos a un elemento especificado en un modelo de base de acontecimientos y para ello hemos incluido el símbolo <type_name> en la sintaxis del lenguaje; como

contraposición, hablamos de Instancia de un elemento para referir a información concreta registrada en una base de acontecimientos. En las expresiones <occurrence_element> [OF TYPE <type_name>] y <occurrence_element> [NOT] <occurrence_element_instance> [OF TYPE <type_name>] se contemplan respectivamente ambos conceptos. Por ejemplo, en una consulta OcAL, el símbolo <type_name> puede tomar valor Sample para referir a una clase declarada en el modelo de la base de acontecimientos de un biobanco; así pues, al declarar

RELATED TO OBJECT ‘bloodSample007’ OF TYPE Sample, estaríamos refiriendo a una instancia de la clase Sample identificada como ‘bloodSample007’; al declarar SELECT OBJECT OF TYPE Sample, estaríamos indicando que deseamos obtener los objetos de la clase

declarada en el modelo como Sample.

Veamos a continuación algunas consultas de ejemplo para mostrar lo que hemos descrito hasta ahora.

Ejemplo:

La siguiente consulta permite obtener los objetos de tipo Sample afectados por la ejecución de protocolo ‘sampleStoringProtocolExecution002’ de tipo SampleAliquotingProtocolExecution:

SELECT OBJECT OF TYPE Sample

RELATED TO PROTOCOL EXECUTION ‘sampleStoringProtocolExecution002’

OF TYPE SampleAliquotingProtocolExecution Consulta 7.1

Ejemplo:

La siguiente consulta permite obtener las ejecuciones de protocolo de tipo

SampleAliquotingProtocolExecutionque han afectado a la muestra ‘bloodSAmple007’: SELECT PROTOCOL EXECUTION OF TYPE SampleAliquotingProtocolExecution

RELATED TO OBJECT ‘bloodSample007 OF TYPE Sample Consulta 7.2

Prosigamos hablando de la cláusula RELATED TO; al inicio de este apartado hemos podido observar que al definir la sintaxis de esta cláusula para las consultas del primer tipo se ha utilizado la expresión <structure_element> [NOT] <structure_element_instance> [OF TYPE <type_name>], mientras que para la sintaxis en el caso de las consultas del segundo tipo se ha utilizado la expresión <occurrence_element> [NOT] <occurrence_element_instance> [OF TYPE <type_name>]. El motivo es que, tal y como

hemos indicado, las consultas del primer tipo van dirigidas a obtener información de estructuras longitudinales y para ello es necesario que refieran a elementos propios de las mismas (<structure_element_xxxxxxxx>). Por el contrario, las consultas del segundo tipo

III El Lenguaje de Acceso a Acontecimientos

van dirigidas a obtener información de acontecimientos, por lo que sus símbolos los especificamos como <occurrence_element_xxxxxxx> al referir a elementos propios de los mismos. Veamos a continuación un ejemplo de consulta del primer tipo:

Ejemplo:

La siguiente consulta permite obtener la línea de vida de la instancia de un contenedor de

muestras identificado como ‘box001’: SELECT LIFELINE

RELATED TO OBJECT ‘box001’ OF TYPE Box

Consulta 7.3

La cláusula BETWEEN … AND y ON es común a los dos tipos de consulta indicados, a través de

ella es posible definir condiciones para acotar los resultados obtenidos a un determinado periodo temporal o a un momento temporal dado respectivamente. El símbolo <date> incluido

como parte de la especificación de esta cláusula hace referencia a la fecha de ocurrencia de los acontecimientos. Por lo general, la fecha de ocurrencia de un acontecimiento suele corresponder con las fechas de ejecución del protocolo que lo ha generado, aunque esta es una de las cuestiones que pueden verse afectadas en función de la estrategia de diseño seleccionada.

Las cláusulas BEFORE y AFTER también son comunes a ambos tipos de consulta y, a través de ellas, es posible acotar los resultados obtenidos a acontecimientos ocurridos con anterioridad o posterioridad al acontecimiento indicado. El símbolo <occurrence_instance> incluido como parte de la especificación de estas cláusulas hace referencia a la instancia del acontecimiento que se desea establecer como cota de la información a obtener.

Por último, la cláusula ORDER BY, que es específica de las consultas para obtener acontecimientos que no constituyen una estructura longitudinal, posibilita establecer los criterios de ordenación (ascendente -ASC- y descendente -DESC-) de los resultados. La sintaxis no contempla el uso de esta cláusula como parte de las consultas para obtener acontecimientos incluidos en una estructura longitudinal dado que la ordenación natural de este tipo de estructuras es el tiempo, por lo que los resultados siempre se obtienen ordenados de forma cronológica.

Sobre la optimización y el rendimiento

Como se ha podido observar en la sintaxis que acabamos de mostrar, la declaración de algunos elementos en una consulta del Lenguaje de Acceso a Acontecimientos es opcional (lo cual, en notación BNF, se denota encerrando el correspondiente símbolo o expresión entre corchetes), esto posibilita construir consultas más simples.

Ejemplo:

En la siguiente consulta que posibilita obtener los estados activos de los acontecimientos producidos por las ejecuciones de protocolos realizadas por el usuario ‘laboratoryAssistant001’

se ha omitido la palabra reservada OF TYPE en la cláusula RELATED TO:

SELECT ACTIVE STATE

RELATED TO PERFORMER ‘laboratoryAssistant001’

Al omitir la referencia al tipo de ejecutor (a la clase declarada en el modelo de la que es

instancia ‘laboratoryAssistant001’) en la consulta anterior se ha logrado una consulta más

simple; no obstante, hay que tener presente que la ejecución de dicha consulta producirá resultados de forma menos eficiente dado que:

1 El traductor deberá determinar los diferentes tipos de ejecutor definidos en el Repositorio de Metadatos.

2 La consulta resultante del proceso de traducción, en función de la estructura de la base de acontecimientos, podría llegar a ser más compleja y por tanto más costosa de ejecutar por el sistema de persistencia dado que a través de ella se deberá determinar de qué tipo

de ejecutor es instancia ‘laboratoryAssistant001’.

Ejemplo:

La siguiente consulta es el resultado de modificar la Consulta 7.4 para mejorar el rendimiento incluyendo la palabra reservada OF TYPE e indicando el tipo de ejecutor de protocolo:

SELECT ACTIVE STATE

RELATED TO PERFORMER ‘laboratoryAssistant001’ OF TYPE UserPerformer Consulta 7.5

Acabamos de introducir algunos conceptos sobre el rendimiento del lenguaje, aspecto que se retomará más adelante.

7.4.2 Consultas para obtener acontecimientos incluidos en una