Base de datos activa
INTRODUCCION
El concepto de Bases de Datos Activas (conocidas
también bajo las siglas SGBDA) se define en la capacidad del motor de manejar
eventos al momento en que los datos sufren cambios como modificación,
eliminación o actualización (más adelante se verá que existen otros eventos),
es decir, cuando se producen ciertas condiciones ejecuta de forma automática
ciertas acciones, además el motor de BD debe ser capaz de monitorizar y
reaccionar ante eventos de manera oportuna y eficiente.
Estas características de reaccionar ante
condiciones son definidas en el esquema de base de datos, de manera que, se
elimina la responsabilidad de la aplicación que hace uso de la misma a
gestionar tales eventos; la manera más común de definirlos en el esquema es a
través de “triggers”, característica esta que maneja la gran mayoría de los
motores de BD más conocidos en el mercado. Mediante los triggers (disparadores
en español) se define el evento a recoger, y, mediante el propio lenguaje del
motor escogido, se escriben las acciones a tomar. Mediante estas reglas se
puede hacer respetar reglas de integridad, generar datos derivados, controlar
la seguridad o implementar reglas de negocio.
La característica que se viene utilizando para
especificar bases de datos activas es el modelo evento–condición–acción, por
ejemplo:
Tras la modificación de la tabla persona, se
chequea su fecha de nacimiento y se procede a actualizar el campo edad, de
todos los registros.
Por supuesto esta definición descrita en lenguaje
fácilmente entendible para nosotros humanos, debe traducirse al lenguaje de
programación del motor, haciendo uso de los triggers para disparar la acción
tras el evento modificación.
Tradicionalmente, los SGBD han sido pasivos; ejecutan consultas o
transacciones sólo cuando un usuario o un programa de aplicación les solicita
explícitamente que lo hagan. Sin embargo, muchas aplicaciones como el control
de procesos, las redes de generación / distribución de energía eléctrica, el
control automatizado del flujo de trabajo de una oficina, el intercambio de
programas, la gestión de batallas y la vigilancia de pacientes hospitalarios no
reciben un servicio adecuado de estos SGBD "pasivos". En estas
aplicaciones restringidas por el tiempo, es preciso vigilar la ocurrencia de
condiciones definidas sobre estados de la base de datos y, en caso de ocurrir,
invocar acciones específicas, quizá sujetas a ciertas restricciones de tiempo.
Una posible situación en la fabricación automatizada consistiría en vigilar la
ocurrencia de un suceso, evaluar una condición y emprender una o más acciones.
En todo esto puede caber el acceso a bases de datos compartidas que varios
usuarios estén actualizando constantemente y que deban mantenerse en un estado.
Básicamente se han adoptado dos enfoques para resolver las necesidades
de las aplicaciones restringidas por el tiempo.
El
primero consiste en escribir un programa que consulte periódicamente la BD para
determinar si ha ocurrido la situación que se espera. Es difícil de implementar
porque no es fácil determinar la frecuencia de sondeo óptima El
segundo consiste en incorporar código en cada uno de los programas que
actualizan la BD de modo que verifiquen si se ha presentado la situación que se
vigila. Pone en peligro la modularidad y la reutilización del código.
Representación de una Base de Datos Activa.
El poder
especificar reglas con una serie de acciones que se ejecutan automáticamente
cuando se producen ciertos eventos, es una de las mejoras de los sistemas de
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 han realizado 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 especificar bases de datos activas es el modelo
evento–condición–acción (ECA).
Dentro de
este modelo las reglas que se utilizan para especificar situaciones con sus
acciones, se les llaman reglas del tipo (ECA) o reglas que siguen el paradigma
de (ECA).
Elementos Constitutivos.
Las Bases de Datos Activas manejan la
vigilancia de condiciones (con disparadores y alertas). Un SGBD
activo vigila continuamente el estado de la BD y reacciona espontáneamente
cuando ocurren sucesos predefinidos. Desde el punto de vista funcional, un
Sistema de Gestión de Bases de Datos Activas vigila condiciones disparadas
por sucesos que representan acciones de bases
de datos.
Esto es: La evaluación de la
condición resulta verdadera, se ejecuta la acción, ofreciendo
modularidad y respuesta oportuna en la acción.
El formato genérico de estas reglas es:
Características de las reglas activas
Además de
las características que poseen los disparadores que incorporan los sistemas
relacionales, algunos sistemas más avanzados y algunos prototipos de bases de
datos activas ofrecen algunas características que incrementan la expresividad de
las reglas activas:
•
Respecto a los eventos, estos pueden ser temporales o definidos por el usuario.
Los eventos temporales permiten utilizar expresiones dependientes del tiempo,
como por ejemplo: cada viernes por la tarde, a las 17:30 del 29/06/2002. Los
eventos definidos por el usuario son eventos a los que el usuario da un nombre
y que son activados por los programas de usuario. Por ejemplo, se podría
definir el evento de usuario ¨ nivel_alto_azufre ¨ y que una aplicación lo
activara; esto activaría la regla que reacciona al evento.
•
La activación de los disparadores puede que no dependa de un solo evento sino
que dependa de un conjunto de eventos relacionados en una expresión booleana
que puede ser una simple disyunción o una combinación más compleja que refleje
la precedencia entre eventos y la conjunción de eventos.
•
La consideración y/o ejecución de reglas se puede retrasar. En este caso, la
consideración y/o la ejecución tienen lugar durante transacciones distintas,
que pueden ser completamente independientes o pueden estar coordinadas con la
transacción en la que se ha verificado el evento.
•
Los conflictos entre reglas que se activan por el mismo evento se pueden
resolver mediante prioridades explícitas, definidas directamente por el usuario
cuando se crea la regla. Se pueden expresar como una ordenación parcial
(utilizando relaciones de precedencia entre reglas), o como una ordenación
total (utilizando prioridades numéricas). Las prioridades explícitas sustituyen
a los mecanismos de prioridades implícitos que poseen los sistemas.
•
Las reglas se pueden organizar en conjuntos y cada conjunto se puede habilitar
y deshabilitar independientemente.
Propiedades de las reglas activas
No es difícil
diseñ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
diseñ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 concluyente 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 una
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.
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 diseñ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 diseñar, depurar y monitorizar reglas
activas que puedan ayudar a los usuarios en el diseño y depuración de sus
reglas.
Aplicaciones de las BD activas
Las
aplicaciones del paradigma de base de datos activas son muy variadas. Una
primera clasificación de las aplicaciones lo establece el uso de las reglas
para labores internas del DBMS, o sea, reglas generadas por el sistema, no
visibles a los usuarios, o para labores externas, las cuales son especificadas
por el usuario y permiten realizar labores específicas dependientes del dominio
del problema. Algunos ejemplos de las actividades que se pueden realizar en
estas aplicaciones se muestran a continuación.
Internas:
Soportar las características clásicas del manejo o administración de las bases
de datos. Ejemplos de estas aplicaciones son:
•
Control de integridad. (Restricciones implícitas y explícitas.)
•
Mantenimiento de vistas y datos derivados, los cuales pueden existir
virtualmente o ser materializados.
•
Administración de copias de los datos (duplicación).
•
Seguridad. Recuperación ante fallas.
Existen
otras aplicaciones internas potenciales, pues hasta el momento no han sido
explotadas por los DBMS, entre ellas se encuentran: mantenimiento de versiones,
administración de la seguridad, “tracking” de eventos.
Externas:
Estas aplicaciones contienen conocimiento de la aplicación, expresándola en
forma de reglas, a las cuales comúnmente se les llama reglas del negocio.
Con
respecto al control de integridad las restricciones que se pueden establecer
con las reglas activas son:
•
Restricciones estáticas: Se evalúan sobre un estado de la base de datos, un
ejemplo de estas son las restricciones de dominio.
•
Restricciones dinámicas: Se evalúan sobre la transición de un estado a otro,
por ejemplo: el sueldo de un empleado sólo puede aumentar.
Independientemente
de si las restricciones son estáticas o dinámicas, dependiendo de quién las
especifica, se pueden dividir en:
•
Restricciones “built-in”: Son restricciones fijas y especificadas con cláusulas
del lenguaje de Definición de Datos (DDL), por ejemplo: referential integrity
(foreign keys, REFERENCES) y claves primarias (PRIMARY KEY).
•
Restricciones genéricas: Son restriccionesespecificadas por el usuario, por
ejemplo con la definición de CONSTRAINTS; algunos ejemplos de estos son: NOT
NULL, UNIQUE y CHECK.
Ventajas y desventajas de Base de Datos Deductivas y Base de Datos Activas
Bases de Datos Deductivas.
ü Ventajas.
· Almacenamiento de pocos datos.
· Reglas que permiten crear combinaciones de datos.
ü Desventajas.
· Encontrar criterios de interpretación para las reglas deductivas.
· Replantear un contexto deductivo.
· Desarrollar procedimientos eficaces de deducción.
Ø Bases de Datos Activas.
ü Ventajas.
· Mayor productividad.
· Mejor mantenimiento.
· Reutilización de código.
· Reducción del tráfico de mensajes.
· Posibilidad de optimización semántica.
· Facilitar el acceso a la BD a usuarios finales.
ü Desventajas.
· Escritura de programas que consulten periódicamente el estatus de la BD.
· Incorporación de código en cada uno de los programas que actualizan la BD.
· Encontrar criterios de interpretación para las reglas activas.
MAPA CONCEPTUAL
ESCRITO POR :
CHRISTELL CAROLINA HERRERA ARIAS
http://www.buenastareas.com/ensayos/Base-De-Datos-Activa/1103508.html
http://www.quadernsdigitals.net/datos_web/hemeroteca/r_1/nr_502/a_6850/6850.htm
