Bases de datos activas

Bases de datos activas

Bases de datos activas.En muchas aplicaciones, la base de datos debe evolucionar independientemente de la intervención del usuario como respuesta a un suceso o una determinada situación. En los sistemas de gestión de bases de datos tradicionales (pasivas), la evolución de la base de datos se programa en el código de las aplicaciones, mientras que en los sistemas de gestión de bases de datos activas esta evolución es autónoma y se define en el esquema de la base de datos.

Introducción

El poder especifica reglas con una serie de acciones que se ejecutan automáticamente cuando se producen ciertos eventos, es una de las mejoras de los sistemasde gestión de bases de datos que se consideran de gran importancia desde hace algún tiempo. Mediante estas reglas se puede hacer respetar reglas de integridad, generar datos derivados, controlar la seguridad o implementar reglas de negocio. De hecho, la mayoría de los sistemas relacionales comerciales disponen de disparadores (triggers ). Se ha hecho mucha investigación sobre lo que debería ser un modelo general de bases de datos activas desde que empezaron a aparecer los primeros disparadores. El modelo que se viene utilizando para especificarbases de datos activas es el modelo evento–condicion–acción. Mediante los sistemas de bases de datos activas se consigue un nuevo nivel de independencia de datos: la independencia de conocimiento. El conocimiento que provoca una reacción se elimina de los programas de aplicación y se codifica en forma de reglas activas. De este modo, al encontrarse las reglas definidas como parte del esquema de la base de datos, se comparten por todos los usuarios, en lugar de estar replicadas en todos los programas de aplicación. Cualquier cambio sobre el comportamiento reactivo se puede llevar a cabo cambiando solamente las reglas activas, sin necesidad de modificar las aplicaciones. Además, mediante los sistemas de bases de datos activas se hace posible el integrar distintos subsistemas (control de accesos, gestión de vistas, etc.) y se extiende el ámbito de aplicación de la tecnología de bases de datos a otro tipo de aplicaciones. Uno de los problemas que ha limitado el uso extensivo de reglas activas, a pesar de su potencial para simplificar el desarrollo de bases de datos y de aplicaciones, es el hecho de que no hay técnicas fáciles de usar para disenñar, escribir y verificar reglas. Por ejemplo, es bastante difícil verificar que un conjunto de reglas es consistente, es decir, que no se contradice. También es difícil garantizar la terminación de un conjunto de reglas bajo cualquier circunstancia. Para que las reglas activas alcancen todo su potencial, es necesario desarrollar herramientas para disenñar, depurar y monitorizar reglas activas que puedan ayudar a los usuarios en el disenño y depuración de sus reglas.

El modelo evento–condición–acción

Un sistema de bases de datos activas es un sistema de gestión de bases de datos (SGBD) que contiene un subsistema que permite la definición y la gestión de reglas de producción(reglas activas). Las reglas siguen el modelo evento–condición–acción (modelo ECA): cada regla reacciona ante un determinado evento, evalúa una condición y, si esta es cierta, ejecuta un acción. La ejecución de las reglas tiene lugar bajo el control de un subsistema autónomo, denominado motor de reglas, que se encarga de detectar los eventos que van sucediendo y de planificar las reglas para que se ejecuten. En el modelo ECA una regla tiene tres componentes:

• El evento (o eventos) que dispara la regla. Estos eventos pueden ser operaciones de consulta o actualización que se aplican explícitamente sobre la base de datos. También pueden ser eventos temporales (por ejemplo, que sea una determinada hora del día) u otro tipo de eventos externos (definidos por el usuario).
• La condición que determina si la acción de la regla se debe ejecutar. Una vez ocurre el evento disparador, se puede evaluar una condición (es opcional). Si no se especifica condición, la acción se ejecutará cuando suceda el evento. Si se especifica condición, la acción se ejecutará sólo si la condición se evaluá a verdadero.
• La acción a realizar puede ser una transacción sobre la base de datos o un programa externo que se ejecutar´a automáticamente.

Casi todos los sistemas relacionales incorporan reglas activas simples denominadas disparadores (triggers ),que están basados en el modelo ECA:

• Los eventos son sentencias SQL de manejo de datos (INSERT, DELETE, UPDATE).
• La condición (que es opcional) es un predicado booleano expresado en SQL.
• La acción es un secuencia de sentencias SQL, que pueden estar inmersas en un lenguaje de programación integrado en el producto que se esté utilizando (por ejemplo, PL/SQL en Oracle).

El modelo ECA se comporta de un modo simple e intuitivo: cuando ocurre el evento, si la condición es verdadera, entonces se ejecutala acción. Se dice que el disparador es activado por el evento, es considerado durante la verificacion de su condición y es ejecutado si la condición es cierta. Sin embargo, hay diferencias importantes en el modo en que cada sistema define la activacion, consideración y ejecución de disparadores. Los disparadores relacionales tienen dos niveles de granularidad: a nivel de fila y a nivel de sentencia. En el primer caso, la activación tiene lugar para cada tupla involucrada en la operación y se dice que el sistema tiene un comportamiento orientado a tuplas. En el segundo caso, la activación tiene lugar sólo una vez para cada sentencia SQL, refiriéndose a todas las tuplas invocadas por la sentencia, con un comportamiento orientado a conjuntos. Además, los disparadores tienen funcionalidad inmediata o diferida. La evaluación de los disparadores inmediatos normalmente sucede inmediatamente después de levento que lo activa (opción después), aunque también puede precederlo (opción antes) o ser evaluados en lugar de la ejecución del evento (opción en lugar de). La evaluación diferida de los disparadores tiene lugar al finalizar la transacción en donde se han activado (tras la sentencia COMMIT). Un disparador puede activar otro disparador. Esto ocurre cuando la acción de un disparador es también el evento de otro disparador. En este caso, se dice que los disparadores se activan en cascada.

Propiedades de las reglas activas

No es difícil disenñar reglas activas de modo individual, una vez se han identificado claramente el evento, la condición y la acción. Sin embargo, entender el comportamiento colectivo de las reglas activas es más complejo ya que su interacción suele ser sutil. Por este motivo, el problema principal en el disenño de las bases de datos activas está en entender el comportamiento de conjuntos complejos de reglas. Las propiedades principales de estas reglas son terminación, confluencia e idéntico comportamiento observable.

• Un conjunto de reglas garantiza la terminación cuando, para cada transacción que puede activar la ejecución de reglas, esta ejecución produce un estado final en un número finito de pasos.
• Un conjunto de reglas garantiza la confluencia cuando, para cada transacción que puede activar la ejecución de reglas,la ejecución termina produciendo un estado final único que no depende del orden de ejecución de las reglas.
• Un conjunto de reglas garantiza un comportamiento observable idéntico cuando, para cada transacción que puede activar la ejecución de reglas, esta ejecución es confluyente y todas las acciones visibles llevas a cabo por la regla son idénticas y producidas en el mismo orden.

Estas propiedades no tienen la misma importancia. Concretamente, la terminación es una propiedad esencial; se debe evitar la situación en que las transacciones, activadas por el usuario, causan ejecuciones infinitas por la activación recursiva de reglas. Por otra parte, la confluencia y el idéntico comportamiento observable no son esenciales. El proceso del análisis de reglas permite la verificación de si las propiedades deseadas se cumplen en un conjunto de reglas. Una herramienta esencial para verificar la terminación es el grafo de activación, que representa interacciones entre reglas. El grafo se crea incluyendo un nodo para cada regla y un arco de la regla R1 a la regla R2 cuando la acción de R1 contiene un sentencia del lenguaje de manejo de datos que es también uno de los eventos de R2. Una condición necesaria para la no terminación es la presencia de ciclos en el grafo de activación: sólo en este caso podemos tener una secuencia infinita de ejecución de reglas. Los sistemas que tienen muchas reglas activas suelen ser cíclicos. Sin embargo, sólo unos pocos ciclos son los que provocan situaciones críticas. De hecho, el que un grafo sea cíclico es condición necesaria pero no suficiente para la no terminación.

Aplicaciones de las bases de datos activas

Las aplicaciones clásicas de las reglas activas son internasa la base de datos: el gestor de reglas activas trabaja como un subsistema del SGBD implementando algunas de sus funciones. En este caso, los disparadores son generados por el sistema y no son visibles por parte de los usuarios. La característica típica de las aplicaciones internas esla posibilidad de dar una especificación declarativa de las funciones, a partir de la que derivar las reglas activas. Ejemplos de ello son el mantenimiento dela integridad referencial (FOREIGN KEY) y el mantenimiento de restricciones de integridad (CHECK). Por ejemplo, cuando una clave ajena es compuesta, la regla de integridad referencial dice lo siguiente: “si en una relación hay alguna clave ajena, sus valores deben coincidir con valores de la clave primaria ala que hace referencia, o bien, deben ser completamente nulos.” En Oracle es el propio sistema quien se encarga de hacer respetar la primera parte de esta regla,una vez que el usuario ha definidolas claves ajenas:

               FOREIGN KEY (ColX,ColY) REFERENCES Tabla 

Sin embargo, la segunda parte de la regla se debe hacer respetar mediante una restricción:

              CHECK( (ColXIS NULL AND ColY IS NULL) OR
                      (ColX IS NOT NULL AND ColY IS NOT NULL) )

En este sistema, la condición de las restricciones expresadas mediante la cláusula CHECK debe cumplir lo siguiente:

• debe ser una expresi´on booleana que se pueda evaluar usando los valores de la fila que se inserta o que se actualiza;
• no puede contener subconsultas;
• no puede incluirlas funciones SYSDATE, UID, USER, USERENV;

lo que hace que en muchas ocasiones no se puedan establecer restricciones de integridad mediante esta cláusula y sea necesario el uso de disparadores. También se pueden utilizar reglar activas para mantener datos derivados, como puede ser el importe total de una factura o la nota media del expediente de un estudiante. Una aplicación similar es la de utilizar reglas activas para mantener la consistencia de las vistas materializadas cuando cambian los datos de las relaciones base sobre las que están definidas. Esta aplicación tiene más relevancia cuando se piensa en la tecnología de los grandes almacenes de datos (data warehousing). Y otra aplicación también relacionada es el mantenimiento de la consistencia de tablas replicadas, especificando reglas que modifiquen las réplicas cuando las tablas originales son modificadas. Una aplicación importante es el permitir la notificación de que está ocurriendo algún suceso de interés. Por ejemplo, se puede utilizar un sistema de bases de datos activas para monitorizar la temperatura de un horno industrial. La aplicación puede insertar periódicamente en la base de datos las lecturas de los sensores de tempertatura y se pueden crear reglas que se activen cuando se alcancen niveles peligrosos, disparando una alarma. También se pueden utilizar reglas activas para mantener la seguridad y para realizar auditorías sobre el acceso a los datos. Otra aplicación de las bases de datos activas es el mantenimiento de otras reglas, clasificadas como externas, que expresan conocimiento específico de la aplicación y que están mas allá de los esquemas predefinidos y rígidos. Estas reglas son las denominadas reglas de negocio ya que expresan las estrategias de una organización para llevar a cabo sus funciones primarias. En el caso de las reglas de negocio no hay técnicas de derivación de reglas basadas en las especificaciones. Es por ello que cada problema se debe afrontar por separado.

Fuentes

• Asignatura de Bases de Datos por Pedro Pablo Alarcón Cavero
• Lenguaje SQL por Pedro Pablo Alarcón Cavero
• basededatos-activas.blogspot.com/?
• www.buenastareas.com
• www.aulaclic.es/sqlserver/t_1_12.htm?
• www.linguee.es/espanol-ingles/traduccion/base+de+datos+activa.html?