La idea de tener disparadores en una BD no es nueva. Estos mecanismos aparecieron primero en CODASYL en forma de On Condition Do. El sistema R (IBM Aplicación 1976-77) proporcionó los disparadores como un mecanismo para reforzar las restricciones de integridad [Gehani, 1991]. Durante varios años, muchos trabajos de investigación han tenido como objetivo reforzar los sistemas de BD tradicionales con capacidades activas [Berghe, 2000]. Por eso, se han desarrollando muchos prototipos de investigación y la tecnología activa ha sido aplicada con éxito a nuevos dominios de aplicación. A continuación se presentarán algunos prototipos de investigación relevantes, clasificados según los modelos de datos donde se hayan apoyado.
1. El sistema ARIEL
El sistema ARIEL es una aplicación desarrollada dentro de un SGBD relacional que implementa un sistema de reglas activas cuyas características principales son [Hanson, 1996].
• Diseño de un lenguaje conveniente para expresar las reglas activas.
• Diseño de un mecanismo eficiente para comprobar las condiciones de las reglas, y permitir el proceso rápido de la transacción.
• Integración de la comprobación de la condición y la ejecución de la regla con el sistema de proceso de transacción.
En ARIEL, las reglas se activan por las transiciones que actualizan la BD a través de una sentencia o una secuencia de sentencias ejecutadas por el usuario. Una sentencia de actualización de datos en ARIEL es una operación orientada al conjunto de tuplas, estas actualizaciones pueden ser inserción, borrado, o modificación. La granularidad mínima del proceso de las reglas es una operación orientada a nivel de tupla. Las sentencias ejecutadas pueden constituir una transacción entera, por eso la granularidad máxima del proceso de las reglas es una transacción entera. El proceso de las reglas se invoca automáticamente al final de cada transición y será parte de la misma transacción.
Una característica importante de ARIEL que lo distingue de STARBURST o POSTGRES es que el evento es opcional, es decir, ARIEL principalmente soporta las reglas de tipo condición-acción (CA) [Paton y Díaz, 1999]. Las condiciones son comprobaciones sobre el estado de la BD y las acciones pueden ser sucesiones arbitrarias de recuperación y actualización sobre cualquier información en la BD. Si se deshace la acción de una regla (ROLLBACK), se termina inmediatamente el proceso de la transacción y se regresa al estado original de la BD antes de la actualización.
El modelo de ejecución en ARIEL utiliza la estrategia recogniza-act cycle para controlar las reglas activas, esta estrategia contiene lo siguiente:
Initial match
While (rules left to run) { Conflict resolution
Act Match }
Cuando un evento ocurre, la fase MATCH encuentra todas las reglas que son elegibles para ejecutar. En la fase CONFLICT RESOLUTION se selecciona una de estas reglas para ejecutar. Al final, la fase ACT ejecuta las sentencias de las actualizaciones contenidas en la acción de la regla. Este ciclo de fases se repite hasta que no se encuentra ninguna regla activa.
En ARIEL, las reglas tienen prioridades numéricas. A cada regla se le asigna un número entre -1000 y 1000, si ningún número se especifica explícitamente entonces el valor que se asigna por defecto es 0. Las asignaciones no necesitan ser únicas. Cuando se activan las reglas múltiples, la resolución del conflicto en ARIEL procede de la siguiente forma:
• Se selecciona la regla con la prioridad más alta.
• Si dos o más reglas tienen la misma prioridad y sus condiciones son satisfactorias, estas reglas se ejecutan juntas, pero si estas condiciones son satisfactorias en distintas transiciones, entonces se consideran sólo aquellas que tienen condiciones satisfechas por la última transición.
• Si queda más de una regla, se selecciona una arbitrariamente.
Finalmente, cuando se procesan las reglas de ARIEL después de una transición, las reglas consideran la estrategia del efecto neto de las actualizaciones. En la mayoría de los casos, el efecto neto será igual que las actualizaciones individuales. Es decir, si una tupla se modifica en varias transiciones, el efecto neto es realizar sola una modificación. Si una tupla se modifica y luego se borra, el efecto neto es borrar la tupla original. Si una tupla se inserta y luego se modifica, el efecto neto es insertar la tupla modificada. Si una tupla se inserta y luego se borra, el efecto neto no realiza ninguna actualización.
Aunque el sistema activo ARIEL es muy potente y tiene muchas características que los SGBDs relacionales comerciales no tienen, las reglas activas de este sistema no son compatibles con el estándar SQL3; nuestro principal objetivo en esta tesis doctoral. Tampoco tiene ningún soporte en una herramienta CASE comercial que puede facilitar a los usuarios el desarrollo de las reglas activas o detectar la no- terminación cuando no existe prioridades en su ejecución.
2. El modelo EXACT
La diversidad de los sistemas activos hace que encontrar una estrategia de ejecución común para todas las aplicaciones sea una tarea complicada. Por eso, las estrategias de ejecución flexibles se convierten en un requisito esencial en el desarrollo de un SGBD activo. EXACT, es un modelo EXtensible de SGBD orientado a objeto ACTivo [Díaz y Jaime, 1997] [Díaz, 1998] que permite aplicar las ventajas del paradigma de modelo orientado a objetos al SGBD activo y tiene una estrategia flexible de ejecución.
En general, el objetivo del modelo orientado a objeto es integrar los aspectos estructurales y los comportamientos de las reglas en los modelos conceptuales [Winter, 1998]. De esta manera, usando el modelo OO no sólo las reglas se describen en el modelo conceptual, sino también la estrategia del proceso de estas reglas. Cuando se describe el proceso de las reglas usando el modelo OO, este modelo dispondrá de una jerarquía de modelos de ejecución que permite al usuario elegir el modelo más conveniente con la semántica de la aplicación. Donde el usuario conoce la semántica del concepto soportado, por eso puede no sólo incluir la definición básica de las reglas sino también la información del control sobre cómo estas reglas tienen que ser ejecutadas. El modelo de ejecución de las reglas no suele aplicarse a una sola regla, porque es compartido con un conjunto de reglas que soportan el mismo concepto o funcionalidad (por ejemplo, el mantenimiento de restricción de integridad, etc.).
El objetivo del proyecto EXACT es la definición del modelo de ejecución de las reglas activas caracterizado por siguientes propiedades:
• Flexible: se puede encontrar distintas estrategias de ejecución de distintos conjuntos de reglas activas, dónde cada conjunto de estas puede soportar una semántica distinta.
• Declarativo: se puede definir el modelo de ejecución de las reglas activas a través de un conjunto de parámetros en lugar de codificar este modelo según la estrategia de la ejecución deseada.
• Extensible: se puede extender el modelo de ejecución fácilmente refinando las características existentes o introduciendo otras nuevas.
EXACT es un sistema activo construido sobre BDOO ADAM [Paton, 1989]. Este sistema soporta las reglas como objetos de primera clase (first-class objects), es decir, las reglas se definen y se tratan como cualquier otro objeto en el sistema usando atributos y métodos. Las clases de reglas pueden colocarse como una jerarquía tal y como se muestra en la figura 2.15. La clase de la regla genérica (generic-rule) almacena la descripción común de una regla a través de los atributos evento, condición, acción, prioridad, y IS-IT-ENABLED, este último atributo es un atributo booleano que describe el estado de la regla, es decir, si la regla se encuentra activa o no. La regla puede ser SWITCHED ON o SWITCHED OFF a través de la modificación del valor de este atributo. En cuanto al comportamiento activo, se canaliza a través de los métodos: evaluating-condition el cual comprueba si la condición de la regla está satisfecha, execution-action que ejecuta la acción de la regla, y el método FIRE que invoca la evaluación de la regla y, sí está satisfecha, invoca la ejecución de su acción. Todos estos atributos y métodos son reunidos en la clase de la regla genérica que puede especializarse para responder a las necesidades, donde estos atributos y métodos se introducen con cada una de las subclases system- rule, integrity-rule, y dynamic-display-rule que representan un uso particular de la regla.
Generic-Rule
is_a
System-Rule Integrity-Rule Dynamic-
Display-Rule
Figura 2.15. Jerarquía de las reglas en EXACT
La aproximación del modelo EXACT consiste en dividir las reglas según la clase a la que pertenecen. Cada clase realiza un uso determinado (por ejemplo, mantenimiento de restricciones de integridad, etc.), y este uso no sólo incluye la descripción de la regla, sino también, el comportamiento de esta regla en tiempo de la ejecución. Esto se realiza usando las metaclases. La figura 2.16 muestra los tres niveles de definición del comportamiento activo en EXACT.
Figura 2.16. Los tres niveles de definición del comportamiento activo EXACT
• En la metaclase rule-manager se describe el modelo de ejecución a través de un conjunto de meta-atributos que son: modo evento-condición-acoplamiento, modo condición-acción-acoplamiento, modo de planificación, modo de recuperación de error, y modo de resolución de conflictos. En este último atributo se almacena las
prioridades de ejecución de las reglas.
• En la clase rule-manager se almacena la descripción de dos métodos principales que son; el método NEW, que se utiliza para crear instancias de reglas, y el método scheduling, que se usa para crear el conjunto de conflicto y dispara las reglas de forma adecuada.
• La instancia 1#GENERIC-RULE donde se definen las reglas individuales.
En la ejecución de las reglas pueden activarse en cascada. La cascada de una regla puede suspender la ejecución de la regla principal, y entrar en un nuevo nivel del proceso de ejecución donde se consideran los efectos de la nueva regla. Se utiliza para solucionar el conjunto entre las reglas activadas, un árbol de ejecución que representa el ciclo de los eventos señalados y las reglas activadas por estos eventos. Por ejemplo, el evento E1 activa las reglas {R1, R2, R3} y el evento E2 activa las
reglas {R4, R5}. Ahora, si durante la ejecución de R1 se produce E2, en este caso se
suspende la ejecución de R1 hasta que las reglas asociadas con el evento E2 terminan
(o sea R4 y R5). Una vez que todo este proceso termina, R1 puede continuar su
ejecución y el proceso acaba con la ejecución de R2 y R3.
Las inconvenientes de este modelo, EXACT, es que algunas dimensiones que caracterizan la ejecución de un módulo aparecen en la expresión de las reglas. Esto puede confundir al programador, y puede conducir a redundancias o incluso a inconsistencias. También el modelo estándar de la ejecución es bastante sencilla (existe sólo una estrategia de la ejecución para un módulo de regla) y el programador tiene que codificar los métodos para llevar a cabo el modelo de la ejecución deseada [Coupaye y Collet, 1998]. Además, el modelo EXACT es un sistema activo orientado a objeto y no tiene extensión a los sistemas relacionales, ni las reglas activas en él son compatibles con el estándar SQL3. Como en el sistema ARIEL, el modelo EXACT no tiene ningún soporte en una herramienta CASE comercial que puede facilitar a los usuarios el desarrollo de las reglas activas o detectar el problema de la no terminación cuando este ocurra.
3. Metodología IDEA
La Metodología IDEA es un nuevo paradigma para diseño de software y por lo tanto, el diseño de una BDOO forma parte de la misma [Ceri et al., 1995] [Ceri y Fraternalli, 1997] [Ceri et al., 1997]. El objetivo principal de este proyecto es investigar y favorecer el uso del modelo orientado a objeto y las tecnologías de las reglas activas en los sistemas de información. La Metodología IDEA contiene varias herramientas para ayudar a los diseñadores a lo largo de todas las fases del ciclo de vida de las aplicaciones. La metodología considera que las reglas son componentes que permiten una representación natural de las necesidades del usuario y facilitan el diseño, implementación, y el mantenimiento de Las BDs.
Requisitos Análisis . . Modelo de Aplicación Modelo Dinámico Modelo de Objetos y Operaciones Modelos Conceptuales Diseño Prototipo . . Modelo y Lenguaje CHIMERA
Implementación SGBDOO Activa SGBDR Activo SGBDOO Deductiva Requisitos Análisis . . Modelo de Aplicación Modelo Dinámico Modelo de Objetos y Operaciones Modelos Conceptuales . . . . Modelo de Aplicación Modelo Dinámico Modelo de Objetos y Operaciones Modelos Conceptuales Diseño Prototipo . . Modelo y Lenguaje CHIMERA
Prototipo .
. . . Modelo y Lenguaje CHIMERA
Implementación SGBDOO Activa SGBDR Activo SGBDOO Deductiva
Figura 2.17. Las fases de la metodología IDEA
En la figura 2.17 se muestra la Metodología IDEA que cubre las fases tradicionales del desarrollo del software, es decir, análisis, diseño, prototipado, e implementación de las aplicaciones activas, teniendo en cuenta las ventajas de los modelos del
desarrollo de BD orientadas a objetos. El interés principal y la mayoría de las contribuciones originales de la Metodología de IDEA son el diseño, y la implementación de reglas deductivas y reglas activas que significativamente enriquecen la semántica soportada dentro de Las BDs.
• Fase de análisis: El análisis en la metodología IDEA se deriva de las metodologías OMT [Rumbaugh, 1991], FUSIÓN [Coleman et al., 1994], SYNTROPY [Cook y Daniels, 1994], y el Método BOOCH [Booch, 1994]. Se realiza el análisis en tres perspectivas: la estructura (definición de atributos y relaciones), conocimiento (definición de las restricciones y los objeto dinámicos) y los requisitos funcionales (descripción de servicios deseados). En general, y como hemos dicho antes, la Metodología IDEA no tiene como interés principal el enfoque en la fase del análisis, así cualquier diseñador o compañía que está acostumbrado a usar un método de análisis específico y desea usar la Metodología IDEA no tiene porque cambiar su sistema de análisis.
• Fase de diseño: Esta fase incluye la especificación de las reglas. La Metodología IDEA usa el lenguaje de Chimera [Ceri y Manthey, 1994] [Widom y Ceri, 1996] que consiste de un modelo conceptual (Chimera Model) que proporciona las facilidades del modelo orientado a objeto, y un lenguaje conceptual (Chimera Language) que proporciona las definiciones de los datos, reglas y restricciones. En esta fase, las restricciones declarativas (declarative features) se transfieren a especificaciones de procedimientos de Chimera. Por ejemplo, las acciones de integridad referencial del modelo de objeto se convierten en disparadores de Chimera que mantienen las relaciones correctas entre los objetos, después de realizar una operación de actualización. En particular, esta fase se divide en, primero el diseño del esquema teniendo en cuenta principalmente las interrelaciones entre los tipos, clases, relaciones, y operaciones, y segundo el diseño de las reglas, que se subdivide en el diseño de las reglas deductivas y el diseño de las reglas activas. El diseño de las reglas activas define los componentes principales como: evento, condición, acción, y prioridad, y sus opciones semánticas de: efecto neto y los modos de acoplamientos.
• Fase de prototipado: Esta fase produce una versión ejecutable de la aplicación activa y comprueba la coincidencia de la aplicación con los requisitos de usuario. Las actividades principales realizadas durante el prototipado son las siguientes:
o La modulación: Un problema serio del diseño de las reglas activas es manejar y controlar la complejidad semántica de un conjunto grande de reglas. La modulación es una técnica que permite hacer la gestión de las reglas más sencilla. Un conjunto de las reglas más pequeñas que construye un módulo es más fácil de manipularlo que la colección de todas las reglas de la aplicación. Se pueden organizar reglas de un tipo de restricciones específicas en una capa de reglas que controla estas restricciones. Si las capas se realizan según un proceso bien definido, se puede asegurar la calidad de unir todas estas capas de una aplicación [Baralis et al., 1996]. Las reglas se dividen en capas para que el diseñador pueda actuar localmente sobre el comportamiento de cada una de estas capas y puede controlar el comportamiento de todas las reglas en las capas. Verificar la consistencia de cada capa consiste en ordenar sus reglas para evitar resultados inesperados.
o Análisis de Reglas: El análisis de las reglas en IDEA está basado en las aproximaciones de [Baralis et al., 1995]. IDEA soporta el análisis basado en el gráfico de desencadenamiento (triggering graph) (sección 2.2.4.1). Para un gráfico dado, el análisis consiste en comprobar cada arco (Ri, Rj), si es
posible conocer que la condición de Rj no será verdadera por la ejecución de
Ri, en este caso aunque Rj se activa por la acción de Ri se puede descartar este
arco del gráfico. El análisis de las reglas se realiza en tiempo de compilación, es decir, cuando se crean las reglas, por lo tanto, es una técnica estática. Los problemas que se solucionan a través de este análisis son de terminación y de confluencia.
• Fase de implementación: La implementación es el proceso de mapear las especificaciones conceptuales a esquemas, objetos, y reglas activas del SGBD elegido. Mapear es el proceso de transformar el modelo de objeto de Chimera a un SGBD comerciales. Por ejemplo, en el caso de ORACLE, el modelo de
objetos de Chimera se transforma a tablas relacionales. Durante este proceso parte de la semántica del esquema orientado a objeto generado por Chimera se perderá porque las características del SGBD seleccionado influyen mucho en el proceso de la implementación. Algunas veces, el problema de transformar las reglas de Chimera a los disparadores de los SGBDs relacionales comerciales será más difícil de solucionar por las limitaciones de estos sistemas. Se puede realizar esta fase a través de dos aproximaciones como se muestra a continuación:
o Meta-Triggering: Esta aproximación se caracteriza en que la mayor semántica de la BD puede traspasarse a un meta-trigger que propaga eventos, resuelve conflictos de las prioridades, e invoca procedimientos. Por ejemplo, según esta aproximación la metodología IDEA trata las limitaciones de ORACLE a través de crear un procedimiento almacenado para cada regla de Chimera y se lleva a cabo la parte activa de la regla con las estructuras adicionales (principalmente los disparadores y las tablas especializadas). Esta aproximación exige agregar estructuras de datos auxiliares y disparadores para que estos procedimientos almacenados sean invocados correctamente. La ventaja de esta solución es que los procedimientos almacenados conserven la semántica de las reglas Chimera. La desventaja consiste en que la activación de los disparadores es indirecta, con un impacto sobre el rendimiento y la transformación más difícil de entender e implementar.
o Macro-Triggering: En esta aproximación se agregan las reglas de Chimera que se definen sobre una tabla, para constituir un solo disparadores en el SGBD solucionado. Por ejemplo, en el caso de ORACLE, las reglas de Chimera se clasifican según los eventos y los objetos. Estas reglas se reúnen para construir un disparador de ORACLE. Esta aproximación se realiza principalmente cuando el conjunto de reglas es pequeño y poca su complejidad.