Modificaciones en la generación de la regla de Cálculo.

Como se analizó anteriormente existen tres alternativas para el patrón que caracteriza las reglas de tipo cómputo, definidas como:

ü <determinante><resultado> es calculado como <algoritmo>

ü <determinante><resultado> en <sujeto> para <atributo> es calculado como <algoritmo>.

Para las reglas pertenecientes a este patrón en cualquiera de sus alternativas es necesario la generación de una función como recurso de BD. El número y el tipo de los parámetros de esta función se corresponden con los atributos llaves primarias de la tabla sujeto. En la primera variante al no estar presente el sujeto, la función no posee parámetros.

Durante el proceso de prueba fueron detectados varios errores en la generación de este tipo de regla. En las dos primeras alternativas los errores se centraron mayoritariamente en errores en el código generado respecto a la sintaxis del lenguaje SQL, por lo que las soluciones brindadas no constituyen modificaciones de mucha relevancia en cuanto a la forma de generar estas reglas. No sucede de esta manera para las reglas pertenecientes a la tercera variante por lo que se propone un análisis más detallado referente a su funcionamiento, los errores detectados y la solución encontrada.

Modificaciones en la generación de las reglas de cálculo en su tercera variante

Esta nueva variante de regla de computo surge en (Pérez Pedraza 2012), y su funcionalidad es almacenar en la columna <atributo>, de la tabla <sujeto>, los valores numéricos retornados por <algoritmo> específicamente para las filas de la tabla <sujeto> .

Un ejemplo de esta regla puede ser: Lenguaje Natural:

ü RN#22: El REND de un equipo es calculado como promedio de los lugares obtenidos en los criollos donde participó dividido por el promedio de todos los lugares de los equipos que participaron en los Criollos

Lenguaje LPT

ü RN#22: El REND en Equipo para rendimiento es calculado como avg(sujeto.Deporte.Compite.Criollos.lugar)/

Por lo tanto una vez activada esta regla el LPT-SQL debe generar e insertar automáticamente los recursos de BD necesarios para lograr la funcionalidad explicada anteriormente.

Durante la ejecución de la prueba de software, fueron detectados varios errores en el funcionamiento de esta variante, luego de un detallado proceso de análisis se concluye que los recursos generados en LPT-SQL v1.2 (Pérez Pedraza 2012), no garantizan el correcto funcionamiento de este tipo de reglas cuando aparecen caminos de navegación que no parten del sujeto de la regla y/o caminos de navegación donde se ven involucradas más de dos tablas.

Ejemplos:

ü Equipo.Deporte.Compite.Criollos.lugar

ü sujeto.Deporte.Compite.Criollos.lugar

Con los recursos utilizados anteriormente no se encuentra una solución factible para esta problemática, por lo que se estima conveniente la utilización de un nuevo recurso de base de datos como las vistas. Este recurso ha sido utilizado en la implementación de las reglas de tipo restricción y fueron analizadas sus ventajas y desventajas en el epígrafe 1.6 como recurso de BD. Se siguen generando los restantes recursos pero con objetivos distintos. Atendiendo a esta nueva implementación los recursos adoptan la siguiente estructura general para el caso de SQLServer sin muchas diferencias significativas con respecto a la estructura general de PostgresSQL, más allá de las diferencias de los propios lenguajes:

CREATEFUNCTION<resultado> ( <parámetros> ) RETURNS float AS

BEGIN DECLARE @y float SET @y = <cálculo asociado> RETURN @y END

CREATEVIEW <nombre de la vista> AS SELECT <cuerpo del select>

CREATEPROCEDURE <nombre del procedimiento> AS UPDATE <sujeto> SET <atributo> = <resultado> WHERE EXISTS <consulta select>

/**Realiza un join entre las filas de la vista y la tabla sujeto, donde exista la relación actualiza**/

CREATETRIGGER <nombre>

ON <tablas> /**nombre de cada tabla implicada**/ FOR <evento> /**eventos de Update, Insert o Delete**/ AS

BEGIN EXEC <nombre del procedimiento> END

De este modo al activarse una regla de cálculo asociada a esta variante el proceso de ejecución sería el siguiente:

ü Se crea una función con nombre <resultado>, que recibe como parámetro los elementos que conforman la llave primaria de la tabla <sujeto>.

ü Se crea la vista que contiene las llaves primarias de las filas de la tabla <sujeto>, donde la columna <atributo> difiere del valor definido por la función <resultado> para esa llave primaria.

ü Se crea un procedimiento almacenado el cual se encarga de verificar si existen filas de la tabla <sujeto> donde la columna <atributo> difiere del valor que retorna la función <resultado> para esa fila, dicho de otra manera, verifica que si la vista está vacía, en caso de no estarlo actualiza las filas de la tabla <sujeto> donde la columna <atributo> no coincide con el valor asociado por <resultado>.

ü Se generan los disparadores necesarios, atendiendo a la lista de eventos, los que se encargan de ejecutar el procedimiento cuando se realiza una operación sobre la BD, que pueda modificar el valor de <resultado>.