INDICE

• Introducción………………………………………………………………………………….. 2

• Análisis de Objetivos…………………………………………………………………………. 3

 Objetivos Generales…………………………………………………………………. 3

 Objetivos Específicos………………………………………………………………... 3

• Caso de Estudio……………………………………………………………………………….. 5 – 13

 Desarrollo…………………………………………………………………………….. 5

 Ilustración – Figura 1.1………………………………………………………………. 5

 Ilustración – Figura 1.2………………………………………………………………. 6

 Modelos Implementación Base de datos Activa………………………………………. 6

 Ilustración – Figura 1.3………………………………………………………………… 7

 Ilustración – Figura 1.4………………………………………………………………… 8

 Semántica en la Ejecución de Reglas………………………………………………….. 8

 Aplicación Base de Datos Activa……………………………………………………… 9

 Modelo Evento-Condición-Acción…………………………………………………… 10

 Ilustración - Figura 2.1………………………………………………………………… 12

 Propiedades de las Reglas Activas…………………………………………………….. 12

 Conclusión…………………………………………………………………………….. 13

 Bibliografía……………………………………………………………………………. 14
 INTRODUCCIÓN

Hace algunos años atrás, cuando los computadores recién estaban siendo incorporados en el ámbito de las empresas,
la función principal de estos era la automatización de algún procedimiento o gestión dentro del rubro. Esta incursión
tuvo un fuerte remesón en la gestión de los datos involucrados en la empresa, condicionando la función de la
informática que en ese tiempo estaba a cargo de procesos, a una manera de manejar volúmenes de datos. Es así como
a final de los años sesenta se crea la primera generación de base de datos en red.

Podemos definir una base de datos como un conjunto de datos relacionados entre sí, donde la palabra dato está
enfocado a algún hecho registrado. Cuando Codd propuso el modelo relacional nunca se imagino que su teoría
matemática se convertiría en una nueva generación de Bases de Datos, la que actualmente domina el mercado.

En los últimos años venimos asistiendo a un avance espectacular en la tecnología de bases de datos. Temas que
hasta hace poco parecían exclusivos de laboratorios y centros de investigación, comienzan a aparecer en las
últimas versiones de algunos SGBD y en nuevos productos: bases de datos multimedia, activos, deductivos,
orientados a objetos, seguras, temporales, móviles, paralelas, etc.

Para el transcurso del presente trabajo se ocupara la abreviación Base de Datos como BD, y en su defecto Sistema de
gestión de base de datos como SGBD.

Dentro de todas estos SGBD, nos centraremos en las BD activas, ¿Cuál es su función? Una base de datos funciona
como un conjunto de reglas y preguntas las cuales están condicionadas por acciones por y para hacer. Lo más
convencional es que ocurra un hecho a través de programa o por acción del usuario y la BD responda, pero con las
BD activas, esta puede reaccionar si se cumple cierta condición, sin necesidad de que esté involucrado un software o
el usuario. Pero esta característica solo es posible si se conocen los modelos de BD activas y la manera en que
necesitamos hacer las consultas. Mediante los sistemas de bases de datos activas se consigue un nuevo
nivel de inde- pendencia 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 da- tos, 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.

2
En los sistemas de BD activas se hace posible integrar distintos subsistemas (control de accesos, gesti´on de vistas,
etc.) y se extiende el ´ambito de aplicacion de la tecnolog´ıa de bases de datos a otro tipo de aplicaciones.

ANALISIS DE OBJETIVOS

• Objetivos Generales:

Actualmente muchas de las bases de datos convencionales están en la categoría de pasivas o “muertas”, ya que
depende de una acción efectuada por el usuario o por una aplicación de programa, para que actúe la base de datos; y
esta no reacciona a operaciones efectuadas sobre ella.

De este modo y a raíz de los diferentes modelos que puede tener una base de datos, surgen las bases de datos activas.
Supongamos que estamos creando una BD para una bodega, en la cual se necesita llevar un inventario de productos,
para asegurar su stock dentro de la bodega, con una BD activa, al momento de quedar sin unidades de un producto la
BD automáticamente actúa ante esta acción y genera una orden de pedido al proveedor; cosa que una BD pasiva no
podría hacer, o dependería de una acción previa.

¿Pero que se necesita para llevar a cabo una BD activa? Necesitamos especificar reglas y ciertas condiciones que se
ejecutaran según el evento.

¿Dónde se aplican 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 para labores externas, las cuales son especificadas por el usuario y permiten realizar labores espec
´ıficas dependientes del dominio del problema.

• Objetivos Específicos:

Anteriormente hablamos de reglas necesarias, pero estas reglas necesitan de una semántica específica, ya que en BD
nada queda al azar o por mera coincidencia, todo responde a un evento ocurrido.

También existen ciertos modelos que determinan el comportamiento de la BD (Modelo Conocimiento, Modelo
Ejecución).

3
 CASO DE ESTUDIO

• Desarrollo:

Lo primero en ver, será la diferencia entre una BD pasiva y una activa, como ya vimos anteriormente, la mayor
diferencia surge en la forma en que la BD reacciona frente a una acción previa.

Optimizador Sentencias SQL

Consultas

Resultado
Procesador
APLICACIO
Consultas N

SGBD PASIVO

Base de
Datos
Figura 1.1

Como se puede apreciar en la figura 1.1, el SGBD pasivo requiere las consultas, según el motor de BD y un
procesamiento y optimización de las mismas, para luego ir a buscar a la BD la los datos necesitado. Donde la BD
responde a la consulta realizada. Dichas consultas a la BD necesariamente tienen que ser realizadas de la aplicación y
en ningún momento la BD actúa de manera independiente.

Ahora bien, ¿qué pasaría con el diagrama anterior si gestionamos la BD de manera activa?

4
 Optimizador Optimizador
Consultas Reglas

Programación
de Reglas APLICACIO
N
Procesador Gestión de
Consultas Eventos

SGBD ACTIVO

Base de Figura 1.2

Reglas
Datos

El diagrama anterior con respecto a la figura 1.2 se aprecia claramente la diferencia entre ambos SGBD añadiendo un
conjunto de reglas que harán que la base de datos responda si se cumplen ciertas condiciones, por ejemplo si tenemos
un campo SALARIO y además tenemos JEFE y EMPLEADOS, el salario del EMPLEADO no puede ser mayor que
el del JEFE. En caso que esto ocurra la BD tiene la autonomía de gestionar esto y dar aviso a través de un mensaje o
aumentar automáticamente el salario cumpliéndose la condición de que el SALARIO_JEFE >
SALARIO_EMPLEADO.

Modelos para la Implementación de una BD Activa:

Para implementar estos SGBD se han tomado básicamente dos enfoques o modelos:

1. El primero, el modelo de CONOCIMIENTO 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.

5
 2. El segundo, el modelo de EJECUCIÓN 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. (Elmasri R. y Navathe S.B.)

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.

Las principales ventajas que se pueden apreciar a primera vista son una mayor productividad, mejor mantenimiento,
la reutilización de código, reducción en el tráfico de mensajes, posibilidad de optimización semántica y el facilitar el
acceso a la BD de los usuarios finales.

APLICACION APLICACIÓN
SISTEMA DE
MATRICULACIÓN

SGBD
GESTION ACTIVA
COLEGIO Datos Alumnos…
Datos Títulos…
Datos etc…

APLICACION

GESTION
COLEGIO

CUANDO…. APLICACION
ENTONCES…. SONDEO
Figura 1.3

6
En el esquema anterior se gestiona una BD activa en modelo de CONOCIMIENTO, donde cada terminal de usuario
puede realizar operaciones en la BD, siendo la aplicación de Sondeo la encargada de revisar periódicamente si se
cumplen ciertas condiciones.

Ahora bien se vamos un poco más allá y nos valemos de la Figura 1.2, podemos modificar el esquema anterior y
agregar la aplicación de sondeo dentro de la BD.

SGBD
ACTIVA

Datos Alumnos…
Datos Títulos…
Datos etc…

CUANDO….
ENTONCES…. Figura 1.4

Esta mejora hace que la BD está en el tipo de modelos de EJECUCIÓN, logrando que mejore la modularidad de la
aplicación, y en vez de tener que estar frecuentemente sondeando para ver si ocurren determinados eventos, aquí la
respuesta es inmediata.

Semántica en la Ejecución de Reglas:

Adicionalmente a la especificación de las reglas, es importante conocer como es la semántica de la

ejecución de las reglas. En particular, existen tres aspectos relevantes en la forma en como se ejecutan las
reglas, que describen el dinamismo de una base de datos, a saber:

1. Granularidad del procesamiento de las reglas.

Es importante saber si una regla se dispara una vez por cada tupla “tocada” o una sola vez por todas las
tuplas “tocadas”. También hay otras opciones, por ejemplo al final de la transacción que se está ejecutando
cuando se despertó la regla.

2. Anidamiento de reglas y terminación.

Otro aspecto importante es si se puede especificar una sola regla por evento o más de una. En el caso en el

7
que se permita más de una regla por evento, en cual orden se ejecutan esas reglas y cuando se termina la
ejecución, son otros aspectos a considerar.

3. Concurrencia con las transacciones.

Finalmente, es necesario determinar si las reglas se van a ejecutar como parte de la transacción donde
se disparen o si se van a ejecutar como transacciones aparte. Esto es fundamental por la propiedad de
atomicidad que se debe garantizar para las transacciones de una base de datos.

Aplicaciones 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 SGDB o para labores externas,
las cuales son especificadas por el usuario y permiten realizar labores especificas 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:

1. Control de integridad. (Restricciones i m p l í c i t a s y e x p l i c i t a s .)

2. Mantenimiento de vistas y datos derivados, los cuales pueden existir virtualmente o ser
materializados.

3. Administración de copias de los datos (duplicación).

4. 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,

8
“tracking” de eventos, bitácoras.
Externas:

Estas aplicaciones contienen conocimiento de la aplicación, expresado en la 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:

1. Restricciones estáticas: se evalúan sobre un estado de la base de datos, un ejemplo de las cuales son
las restricciones de dominio.
2. Restricciones dinámicas: se evalúan sobre la transición de un estado a otro, por ejemplo: el sueldo de
un empleado solo puede aumentar.

Independientemente de si las restricciones son estáticas o dinámicas, dependiendo de quien la especifique,

se pueden dividir en:

• restricciones “BUILT-IN”: son fijas y especificadas con clausulas del DDL, por ejemplo: referential
integrity (foreign keys, REFERENCES) y claves primarias (PRIMARY KEY).

• Genéricas: especificadas por el usuario, por ejemplo con la definición de CONSTRAINTS; algunos
ejemplos de ´estos son: NOT NULL, UNIQUE y CHECK.

EL Modelo EVENTO-CONDICION-ACCION

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 una a c c i ó 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

9
 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
ejecutara cuando suceda el evento. Si se especifica condición, la acción se ejecutara solo si la
condición se evalúa a verdadero.
• La acción a realizar puede ser una transacción sobre la base de datos o un programa externo que se
ejecutara 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 ejecuta la acción. Se dice que el disparador es activado por el evento, es
considerado durante la verificación 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 activación, 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 o l o u n a 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 del evento 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.

Un disparador puede activar otro disparador. Esto ocurre cuando la acción de un disparador es

10
 también el evento de otro disparador. En este caso, se dice que los disparadores se activan en cascada.

Figura 2.1

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 esta 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 numero 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 ú n i c o que no depende del orden
de e j e c u c i ó 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

11
por la regla son idénticas y producidas en el mismo orden.

Estas propiedades no tienen la misma importancia. Concretamente, la t e r m i n a c i ó 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áli s i s 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 c o n d i c i ó n necesaria para la no terminación es la
presencia de ciclos en el grafo de activación: solo 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, solo 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 t e r m i n a c i ó n .

12
 CONCLUSIÓN

Actualmente alrededor de todo el mundo, las personas o instituciones están ocupando algún tipo de
almacenamiento de datos, con la aparición hace algún tiempo atrás de los SGBD se ha podido mejorar la manera
en que esta información esta almacenada. Los incalculables volúmenes de papeles, registros, etc. Que tenían
empresas, personas, etc. Eran muy difíciles de ordenar o simplemente consultar un archivo específico.

Estos sistemas se introdujeron de manera que los datos estuvieran contenidos en un solo lugar, cambiando todo
el espacio que había almacenado por papeles, a un solo ordenador.

Muchos de los actuales sistemas que permiten manejar esta información, son sistemas basados en una serie de
consultas, las cuales se procesan hasta llegar a la BD y rescatar la información deseada. Pero las BD de tercera
generación, como lo es la BD Activa, van un poco mas allá de una simple consulta y respuesta.

Estas BD Activas son capaces de hacer sondeos cada cierto tiempo o de manera automática y ver si se cumplen
ciertas reglas sin necesidad de que una aplicación o usuario interfieran. Esto mediante a los diferentes modelos
con el que se puede asimilar un BD activa.

También se aclaro la semántica de las reglas que una BD activa puede tener, así como los campos de aplicación,
y errores en las consultas.

Se espera que en una próxima generación de BD estas estén cada vez mas adaptadas a realizar operaciones
autónomamente, todo esto dependerá de los futuros motores de BD y la capacidad que tenga el programador de
crear un buen modelo para su aplicación.

13
 BIBLIOGRAFÍA

 Piattini & Díaz (2000). Advanced Database Technology and Design. Capt. 3

 Elmasri & Navathe (2000). Fundamentals of DBS, Capt. 23.1

 Garcia-Molina, Ullman & Widom 2002. DBS, Capt. 7.4

 Atzeni et al. (1999) bases de datos activas en el Cap. 12

 http://www.quadernsdigitals.net/index.php?accionMenu=hemeroteca.DescargaArticuloIU.descar
ga&tipo=PDF&articulo_id=6850

14
 Alejandro Farías F.

Ramón Labbé

15 Fecha: 21 de Abril del 2009

Prof.: José Miguel Rubio