6.4.2 Descripción General

El Transformador Estructural necesita del Módulo de Análisis Estructural para descomponer una consulta compleja en varias consultas básicas relacionadas mediante funciones que procesan los resultados de las mismas. Existen sistemas que intentan clasificar las consultas en base a la distribución de los conceptos en la misma, comparándola con plantillas o patrones previamente obtenidos de un conjunto de datos (consultas) de entrenamiento. Una vez identificado el tipo de consulta, el módulo de traducción a SQL se encarga de aplicar un conjunto de reglas dependiendo del tipo de consulta, que genera un marco o marcos semánticos, como paso previo a la traducción SQL propiamente dicha. La idea de clasificación parece interesante, pues permite enfocar el problema de la traducción, simplificando en gran parte el proceso y asegurando en cierta medida el correcto procesamiento (traducción) de la consulta. En el sistema que hemos implementado esta idea también subyace pero ha sido implementada en base a un analizador estructural (algoritmo de análisis con una gramática conceptual y la posibilidad de generar el árbol asociado a la consulta). El árbol o estructura de la consulta es el indicativo del tipo de la misma, es decir, del nivel o grado de complejidad que existe y de las reglas que deben aplicarse sobre ella.

Fig. 6.13 Diagrama de bloques del Módulo de Transformación Estructural, y su ubicación relativa en la arquitectura del sistema.

Además de las reglas que se ven en el diagrama, también se aplican un conjunto de reglas especiales, encargadas de identificar los conceptos contenido (elementos de la claúsula WHERE) de los conceptos pregunta (elementos de la claúsula SELECT).

Analicemos con algún detalle los dos problemas básicos que, en el dominio de nuestra aplicación, resolvemos con el Módulo de Transformación Estructural:

[Proceso de Consultas que implican un Acceso a Tablas con Información Temporal]

Es posible que en determinados dominios de aplicación existan consultas con una dimensión temporal. En nuestro caso, algunas tablas de las BD de la aplicación (Servicio de Obtención de Información con Acceso a BD),  tienen uno o varios campos FECHA, almacenando información histórica respecto a alguna entidad de la misma (por ej. POSICION, INFORMES, PROMOCION, DESEMPLEO, FLOTA son tablas con histórico).

No siempre es necesario procesar las consultas con las reglas del Módulo de Transformación Estructural. Veamos algunos casos:

• Consultas que implican el acceso a varias tablas de la BD pero ninguna es de tipo histórico
• Consultas con acceso a una o varias tablas sin histórico y una con histórico, con una única referencia temporal. Por ej.: la posición de un barco en una fecha concreta, o el informe que emitió una nave en una fecha, etc

Pero en otras ocasiones sí que es necesario que el Módulo de Transformación actúe:

• Consultas que implican el acceso a una o a varias tablas no históricas , y una de ellas histórica, con varias referencias temporales (distintas fechas). Por ej.: barcos situados en el mar el 12 de octubre (pasado) y que está en otra posición actualmente. Estos casos suponen dos consultas, al menos de acuerdo con nuestra implementación, aunque si bien es cierto que podrían realizarse mediante una única consulta SQL.

[Proceso de Consultas con Funciones Binarias]

La elipsis es un fenómeno habitual en una lengua natural, en la estructura superficial de las frases, y que plantea un problema importante a la hora de traducir a SQL, al no poder traducir todos los elementos (conceptos) de la consulta que está afectada por la misma, pues las reglas no pueden aplicarse sobre conceptos inexistentes. En estos casos, el Módulo de Transformación Estructural se encarga de resolver la elipsis (completar) en aquellas consultas que están afectadas, antes de enviarlas al Traductor a SQL. Veamos algunos ejemplos que ayuden a entender mejor el funcionamiento de este módulo.

Ej. “ ¿Es la eslora del Trueno mayor que la del Bribón? ”

Fig. 6.14   Árbol  asociado a la frase anterior, donde se observa una función binaria (mayor que) con “que” para descomponer la frase., así como los elementos que tienen las distintas subconsultas.

En esta frase existe una consulta que debe ser descompuesta en dos consultas básicas con las que se obtendrán las esloras de cada uno de los barcos (Trueno, Bribón). Para el segundo barco existe elipsis en el término eslora pues no aparece en la estructura superficial de la consulta pero debe ser incorporado antes de intentar traducir a SQL cada una de ellas.

Ej. “ ¿Qué barcos del Mediterráneo con grado seis se encontraban en puerto el lunes? “

Fig. 6.15  Diagrama de bloque inicial, en él se observan los elementos que pertenecen a la única consulta que existe.

Existe una sóla consulta pero hay dos accesos a la misma tabla (POSICION), con dos instantes de tiempo diferentes, lo que presupone dos consultas básicas en la estructura profunda y el Módulo de Control se encargará de si gestión.

Fig. 6.16   En él se puede observar cómo la única consulta que existe se modifica, dándo lugar a una nueva consulta básica que además será completada para poder ser interpretada correcatmente por el Módulo de Traducción a SQL.

Anterior   I  Siguiente   I  Índice capítulo 6   I  Índice General