Pedro Bases de Datos Activas

BASES DE DATOS ACTIVAS
Asignatura: BASES DE DATOS AVANZADAS
Docentes : Lic. Pablo Bogado

Lic. María Emilia Llorente
A.S. Javier Besso
Facultad de Ciencia y Tecnología - UADER

Una Base de Datos Activa es aquella capaz

de detectar situaciones de interés y de
actuar en consecuencia.
Debe ser capaz de monitorizar y reaccionar

ante eventos de manera oportuna y
eficiente.
COMPORTAMIENTO PASIVO
El marido sabe cómo cocinar.

La esposa solicita explícitamente al marido que lo
haga.
OBJETO FUENTE VS OBJETO RECEPTOR.
COMPORTAMIENTO ACTIVO
El marido sabe cómo cocinar y cuando cocinar.

OBJETO OBSERVADOR VS OBJETO OBSERVADO.
Los SGBD Activos:
Proporcionan mecanismos para definir el

cuando y el qué mediante la definición de
Reglas Activas. (Modelo de Conocimiento).
Realizan un seguimiento del cuando y

gestionan el qué, procesamiento de las
Reglas Activas. (Modelo de Ejecución).
Deben tener la capacidad de almacenar las

Reglas Activas.
Comportamiento Activo = CUANDO + QUÉ
Ejemplos: Gestión de Stocks:
cuando ITEM < 10

entonces solicitar nuevo ITEM al proveedor
Productos Perecederos
Cuando fecha_caducidad - fecha_actual < 7

entonces reducir el precio del producto
Comportamiento Activo = CUANDO + QUÉ
“Actualizar la hoja de ruta del transporte

escolar con cada incorporación de un nuevo
alumno a la escuela”
cuando se incorpora un alumno

entonces actualizar la hoja de ruta del
transporte escolar
Una Base de Datos Activa tiene mayor

independencia de datos que una No Activa,
porque en la misma se encuentran definidas
las reglas de integridad que se deben cumplir,
de esta manera las aplicaciones son más
independientes porque deben realizar menos
“controles” sobre ellos y un cambio en estas
no implica la propagación del cambio en las
aplicaciones.
Un sistema de bases de datos activas es un

sistema de gestión de bases de datos
(SGBD) que contiene la capacidad de
definición, almacenamiento y gestión de
reglas activas.
Una Regla Activa es un conjunto de acciones

que el SGBD ejecuta cuando se produce un
evento determinado. Mediante estas reglas
se pueden hacer respetar reglas de
integridad, generar datos derivados,
controlar la seguridad, realizar auditorías,
implementar reglas de negocios o dar alertas
ante eventos que tienen lugar en la base de
datos que se esta monitorizando.
Una Base de Datos Activa utiliza reglas de

Evento – Condición – Acción (ECA).
La ocurrencia de varios tipos de

acontecimientos (por ejemplo, transiciones
de la base de datos, acontecimientos del
tiempo o señales externas), acciona la
evaluación de una condición, y si la condición
resulta verdadera la acción se realiza.
Arquitectura básica de Sistemas de

Bases de Datos Activas
Básicamente se encuentra compuesto por:
A) EVENTOS
• Eventos primitivos
-Eventos temporales
-Eventos definidos por los usuarios
-Eventos de la base de datos
• Eventos compuestos
Arquitectura básica de Sistemas de

Bases de Datos Activas
B) CONDICIONES
C) ACCIONES
• Externas
• Internas
D) REGLAS ECA
E) BASE DE DATOS
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).

componentes:
La condición que determina si la acción de

la regla se debe ejecutar. Una vez que 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
evalúa a verdadero.

componentes:
La acción a realizar puede ser una o más

operaciones sobre la base de datos
(transacción) o un programa externo que se
ejecutará automáticamente.
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.
Eventos
Un evento se concibe como una pareja

{<Tipo de evento>, <Toc>}, donde el tipo
de evento es la descripción o especificación
del evento a detectar y toc (tiempo de
ocurrencia) corresponde al punto en el
tiempo cuando ocurre dicho tipo de evento.
Eventos
Los tipos de eventos pueden ser situaciones

dentro de la base de datos o sucesos en el
ambiente. En el caso de bases de datos
relacionales, las operaciones insert, delete o
update pueden ser consideradas como tipos
de eventos, mientras que en bases de datos
orientadas a objeto, éstos corresponden a la
creación o borrado de objetos así como el
llamado a métodos.
Eventos
El tiempo también puede ser considerado un

tipo de evento interesante tal como un punto
absoluto en el tiempo (“9 de julio de 2013'')
o puntos relativos o periódicos en el tiempo
(“cada viernes a las 14:30 hs.'').
Eventos
Generalmente, un evento posee parámetros
adicionales a su tiempo de ocurrencia tales
como el identificador de la transacción que lo
ocasionó, el identificador del usuario que
inició la transacción o por ejemplo el nombre
del método, identificador del objeto y
argumentos en el llamado a un método en
bases de datos orientadas a objetos. Estos
parámetros pueden ser referenciados
tanto en la condición como en la acción
de la regla.
Eventos
Se denomina historia de eventos al conjunto

de todos los eventos sucedidos en el tiempo.
La historia inicia desde el momento en que
se define el primer tipo de evento en la base
de datos.
Clasificación de los Eventos
Eventos primitivos: Corresponden a

ocurrencias de tipos de eventos que pueden
ser detectados directamente por la base de
datos.
Eventos compuestos: se definen como

expresiones de eventos utilizando un
conjunto de operadores de eventos tales
como: disyunción “|”, conjunción “&” el
operador secuencia “;”.
Suponiendo dos eventos primitivos A y B,
A & B ocurre cuando A y B ocurren,
A | B ocurre cuando A o B ocurren y
A ; B ocurre cuando ocurre A y luego B.

Los eventos primitivos se clasifican en:
- Eventos de la base de datos,
- Temporales y
- Explícitos.
Los eventos de la base de datos

corresponden a las operaciones de la base de
datos, por ejemplo insert, update, delete (en
el modelo relacional) y los métodos (en el
modelo orientado a objetos).
Los eventos temporales se clasifican en

absoluto y relativo.
Temporal Absoluto: se definen como eventos

de tiempo que estipulan una fecha fija. El
evento sucede cuando dicha fecha suceda.
Temporal Relativo: Evento de tiempo que

estipula la ocurrencia de un lapso de tiempo
con respecto a la ocurrencia de otro evento.
Los eventos explícitos (definidos por el

usuario) son esos eventos que son
detectados junto con sus parámetros por
programas de aplicación (es decir, fuera del
DBMS) y manejados por el DBMS.
Condición
Una condición puede ser un predicado sobre

los parámetros del evento que disparó la
regla, puede ser una consulta sobre la base
de datos (si retorna filas la condición se
cumple), o el llamado a un procedimiento o
método que debe retornar verdadero o falso
o una combinación de los anteriores. La
condición no debe modificar la base de datos
ni causar efectos colaterales.
Condición
Se trata de una expresión que debe ser

satisfecha para que se pueda proceder al
disparo de la acción.
En el caso que las reglas son disparadas por
modificaciones en los datos, se permite
referenciar tanto en la condición como en la
acción a los valores previos (old) y
posteriores a la modificación (new). Estos
mecanismos se denominan condiciones de
transición.
Acción
La acción puede realizar consultas o

modificaciones sobre la base de datos
(select, insert, update, delete), operaciones
de control sobre las transacciones (Rollback,
Commit), o llamar uno o más procedimientos
o métodos arbitrarios. Debido a que la acción
puede realizar modificaciones sobre la base
de datos, ésta puede ocasionar la ocurrencia
de nuevos eventos y por tanto provocar el
disparo en cascada de nuevas reglas.
Acción
Las acciones se dividen en:
-Acciones Externas: Se dan cuando son

especificadas por aplicaciones, por ejemplo
enviar un correo electrónico (email), imprimir
una orden de compra.
- Acciones Internas: Son acciones de la base

de datos, como un insert, update, select.
Acoplamiento entre Evento Condición y

Acción
El modo de acoplamiento o ensamble hace

referencia al momento en que es evaluada la
condición y ejecutada la acción con respecto
a la transacción.
Acoplamiento entre Evento Condición y

Acción
Las alternativas son:

-Inmediato: ejecución inmediata de
transacción de la regla cuando el evento es
detectado.
-Diferido: la transacción de la regla es
ejecutada al final de la transacción que
detecta el evento (justo antes del commit).
-Desacoplado: la transacción de la regla es
ejecutada en una transacción separada.
Selección de Reglas - Conflicto
Cuando dos o más reglas se disparan al mismo

punto en el tiempo se dice que existe un
conjunto de reglas en conflicto. Debido a que
distintas órdenes de ejecución de reglas pueden
ocasionar estados distintos en la base de datos,
el ADBMS debe ofrecer un mecanismo de
resolución de conflictos. Un mecanismo puede ser
el uso de prioridades en reglas, según el cual, la
prioridad indica el orden en que deben ser
ejecutadas. La resolución de conflictos es parte
del modelo de ejecución de reglas.
El Modelo de Conocimiento es el que

permite mantener algún mecanismo para que
los usuarios describan la conducta reactiva
de la base de datos, a través de las reglas
ECA.
El Modelo de ejecución es el que supervisa

y reacciona frente a las circunstancias
pertinentes mediante una conducta
proactiva, señalando qué pasos se ejecutan
desde que se recibe la señal del evento hasta
la ejecución de la acción.
MODOS DE ACOPLAMIENTO
FUENTE OCURRENCIA
REGLAS REGLAS REGLAS
DE DE
DISPARADAS EVALUADAS SELECCIONADAS
EVENTOS EVENTOS
señalar disparar evaluar planificar ejecutar
Modo de acoplamiento Modo de acoplamiento

evento-condición condición-acción
MODELO DE EJECUCION
Se realiza un seguimiento de la situación y

gestiona el comportamiento activo. Especifica
cómo un conjunto de reglas es tratado en tiempo
de ejecución, se encarga de realizar el
seguimiento de la situación, gestionando el
comportamiento activo.
MODELO DE EJECUCION
- Señalización: En la señalización ocurre la
aparición de las ocurrencias en el evento.
- Activación: en la activación se toman los
eventos producidos y se dispara las reglas
correspondientes.
- Evaluación: Se selecciona una regla activada y
se evalúa su condición.
- Planificación: en la planificación se indica
cómo se procesa el conjunto de reglas.
- Ejecución: la ejecución es la que lleva a cabo
las acciones de las reglas escogidas.
MODELO DE ACOPLAMIENTO INMEDIATO
INICIO DE TRANSACCION
EVENTO EVALU. CONDICI. EJEC. ACCION
FIN DE TRANSACCION
MODELO DE ACOPLAMIENTO INMEDIATO
En este caso la condición (acción) es

evaluada (ejecutada) inmediatamente
después del evento(condición). Los modos
inmediatos del acoplador se pueden utilizar,
por ejemplo, para hacer cumplir apremios de
la seguridad o propagos de actualizaciones.
MODELO DE ACOPLAMIENTO DIFERIDO

INICIO DE TRANSACCION
EVENTO
EVALU. CONDICI. EJEC. ACCION
FIN DE TRANSACCION
MODELO DE ACOPLAMIENTO DIFERIDO
En este caso la condición (acción) se evalúa

(ejecuta) dentro de la misma transacción que
el evento (condición) de la regla, pero no
necesariamente en la primera oportunidad.
MODELO DE ACOPLAMIENTO DESACOPLADO

Independiente: este se produce cuando la
condición (Acción), se evalúa (Ejecuta), en una
transacción diferente en la que se evalúa el
evento (Condición).
Dependiente: se produce cuando la
condición(Acción), se evalúa(Ejecuta), en una
transacción diferente en la que se evalúa el
evento (Condición); pero en este caso la
ejecución es dependiente de la grabación
(commit) de la transacción en la que el evento
tiene lugar o en la que se evalúa la condición.
INDEPENDIENTE
INICIO DE TRANSACCION T1
EVENTO EVALU. CONDICI.
EJEC. ACCION
FIN DE TRANSACCION T1
DEPENDIENTE
EVENTO EVALU. CONDICI.
EJEC. ACCION
MANIFIESTO DE LOS SGBDA
Características de los SGBDA

Un SGBDA es un SGBD.
Un SGBDA tiene un modelo de reglas ECA.
Un SGBDA debe soportar la gestión de reglas.
Un SGBDA debe gestionar la historia de eventos.
Un SGBDA debe implementar resolución de conflictos.
Características de ejecución de reglas ECA

Un SGBDA tiene un modelo de ejecución.
Un SGBDA debe ofrecer diferentes modelos de
acoplamiento.
SGBD PASIVO
optimizador
sentencias SQL
consultas USUARIO
O
procesador
consultas resultado APLICACION
datos
SGBD ACTIVO
optimizador optimizador
consultas reglas
prog.
de APLICACION
reglas
procesador gestión
consultas eventos
datos reglas
En la figura anterior se muestran las partes esenciales de

un sistema de administración de bases de datos activa. En
la parte inferior vemos una representación del lugar donde
se guardan los datos y las reglas almacenadas.
-Aplicación: sistema con las necesidades particulares del

negocio, el cuál se complementa con la BDA.
-Procesador de consulta: se encarga de convertir una

consulta o manipulación de la base de datos, que puede
estar expresada en un nivel muy alto (ejemplo, como
consulta en SQL), en un serie de peticiones de datos
almacenados.
-Optimizador de Reglas: se encarga de que todas las

operaciones se realicen de la manera apropiada. En
concreto, la ejecución apropiada requiere que las
propiedades ACID, abreviatura de los cuatro requisitos
principales de la ejecución: Atomicidad, Consistencia,
Aislamiento, Durabilidad.
-Optimizador de Consultas: es el encargado de

seleccionar un buen plan de consulta o sea una serie de
peticiones al sistema de almacenamiento que las atenderá.
-Programación de Reglas: se encarga de la programación

de las reglas de la base de datos. Estas reglas son
programadas en la base de datos para mantener la
consistencia y la integridad de los datos.
-Gestor de Eventos: encargado de la detección de los
eventos (ej. Insert, Update, Delete).
VENTAJAS DE UNA BD ACTIVA
Centralización de la Información: esto

permite un mejor mantenimiento, ya que las
reglas son almacenadas dentro de la Base de
Datos, si es necesaria alguna modificación se
hace sólo una vez en la BD en lugar de
hacerlo en cada Programa. También permite
una mayor Productividad, ya que los
programas se simplifican.
VENTAJAS DE UNA BD ACTIVA
Encapsulamiento de Procedimientos: esto

permite una mayor productividad ya que se
pueden normalizar los procesos, sacando
factor común de cierta lógica de los
programas que se almacena una sola vez de
forma centralizada. Permite la reutilización del
código, ya que esta disponible cada vez que
se necesite.
APLICACIONES DE UNA BD ACTIVA
INTERNAS
• Comprobación de la integridad
• Notificación de condiciones.
• Generación de datos derivados
(materialización de vistas).
• Control de la seguridad (accesos permitidos y
auditoria).
EXTERNAS
• Definición de las reglas de funcionamiento
interno de la organización.
Ej.: COMPROBACION DE LA INTEGRIDAD
CREATE TRIGGER CompruebaSalario

BEFORE INSERT OR UPDATE OF Salario, Puesto ON Empleado
FOR EACH ROW
DECLARE
minsal NUMBRER;
maxsal NUMBER;
Salario_Fuera_Rango EXCEPTION;
BEGIN
SELECT minsal, maxsal INTO minsal, maxsal
FROM Salarios
WHERE Puesto = :NEW.Puesto;
IF (:NEW.Salario < minsal OR :NEW.Salario > maxsal)
THEN RAISE Salario_Fuera_Rango;
END IF;
GENERACION DE DATOS DERIVADOS

A diferencia de las vistas "normales" una vista materializada
almacena físicamente los datos resultantes de ejecutar la
consulta definida en la vista. Este tipo de vistas materializadas
realizan una carga inicial de los datos cuando se definen y
posteriormente con una frecuencia establecida se actualizan los
datos de la misma. Con la utilización de vistas materializadas
logramos aumentar el rendimiento de las consultas SQL además
de ser un método de optimización a nivel físico en modelos de
datos muy complejos y/o con muchos datos. Una vez definida
una vista materializada uno de los problemas que nos
encontramos es el de la actualización de los datos. Para
resolver este problema podemos hacer uso de las Reglas
Activas.
CONTROL DE LA SEGURIDAD
ACCESO PERMITIDOS Y AUDITORIA
Las transacciones activas en el SGBD tiene asociado el usuario
que “disparo” la misma, por lo que es posible controlar la
ejecución de la misma de acuerdo al usuario, además la
posibilidad de saber el usuario nos permite mantener
información necesaria para auditorias.
Ej. Incorporar el Usuario y la Fecha Actual al momento de
realizar un INSERT.
CREATE TRIGGER Actualizo_Clientes FOR Clientes
BEFORE INSERT AS
BEGIN
New.Cliente_Usuario = CURRENT_USER;
New.Cliente_Fecha = CURRENT_DATE;
END
Ej.: FUNCIONAMIENTO INTERNO
CREATE TRIGGER Ordenar_Produccion
AFTER UPDATE OF Cantidad ON Inventario
FOR EACH ROW
WHEN NEW.Cantidad < NEW.Cantidad_Minima
DECLARE
X NUMBER;
Y NUMBER;
BEGIN
SELECT SUM(Cantidad) INTO X FROM Orden_Produccion
WHERE Nro_Pieza = NEW.Nro_PIEZA;
Y:= NEW.Cant_Minima – (X + NEW.Cantidad);
INSERT INTO Orden_Produccion(Nro_Pieza, Cantidad,
Fecha)
VALUES(NEW.Nro_Pieza,Y,SYSDATE)
END
REGLAS RESTAURADORAS DE LA CONSISTENCIA
En un sistema de base de datos, el cambio en el mundo real se modela
mediante la ejecución de transacciones de usuario que modifican un estado
generando otro que representa la nueva situación. Este nuevo estado
puede violar las restricciones de integridad del esquema, restricciones que
representan las propiedades de ese mundo. La reacción más frecuente de
los sistemas de bases de datos ante la violación de la integridad consiste
en rechazar la transacción que la ha provocado, devolviendo la base de
datos al estado anterior a su ejecución. Esta solución tan simple es, sin
embargo, usualmente poco satisfactoria para sistemas reales. Una
alternativa a este comportamiento consiste en que el sistema modifique el
estado inconsistente de forma que se repare la violación provocada por la
transacción de usuario respetando los cambios propuestos por ésta. Se
dice entonces que el sistema ha restaurado la consistencia de la base de
datos. Para la restauración de la consistencia utilizan las reglas activas.
Estas reglas se han denominado reglas restauradoras.
FIN

Pedro Bases de Datos Activas

Diunggah oleh

Informasi Dokumen

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Pedro Bases de Datos Activas

Diunggah oleh

Hak Cipta:

Format Tersedia

BASES DE DATOS ACTIVAS

Asignatura: BASES DE DATOS AVANZADAS

Docentes : Lic. Pablo Bogado

Facultad de Ciencia y Tecnología - UADER

Una Base de Datos Activa es aquella capaz

Debe ser capaz de monitorizar y reaccionar

El marido sabe cómo cocinar.

El marido sabe cómo cocinar y cuando cocinar.

Los SGBD Activos:

Proporcionan mecanismos para definir el

Realizan un seguimiento del cuando y

Deben tener la capacidad de almacenar las

Comportamiento Activo = CUANDO + QUÉ

Ejemplos: Gestión de Stocks:

cuando ITEM < 10

Cuando fecha_caducidad - fecha_actual < 7

Comportamiento Activo = CUANDO + QUÉ

“Actualizar la hoja de ruta del transporte

cuando se incorpora un alumno

Una Base de Datos Activa tiene mayor

Un sistema de bases de datos activas es un

Una Regla Activa es un conjunto de acciones

Una Base de Datos Activa utiliza reglas de

La ocurrencia de varios tipos de

Arquitectura básica de Sistemas de

Básicamente se encuentra compuesto por:

Arquitectura básica de Sistemas de

En el modelo ECA una regla tiene tres

El evento (o eventos) que dispara la regla.

En el modelo ECA una regla tiene tres

La condición que determina si la acción de

En el modelo ECA una regla tiene tres

La acción a realizar puede ser una o más

Los sistemas relacionales incorporan reglas

Los eventos son sentencias SQL de manejo

Un evento se concibe como una pareja

Los tipos de eventos pueden ser situaciones

El tiempo también puede ser considerado un

Se denomina historia de eventos al conjunto

Clasificación de los Eventos

Eventos primitivos: Corresponden a

Eventos compuestos: se definen como

Clasificación de los Eventos

Suponiendo dos eventos primitivos A y B,

A & B ocurre cuando A y B ocurren,

A | B ocurre cuando A o B ocurren y

A ; B ocurre cuando ocurre A y luego B.

Clasificación de los Eventos

Los eventos primitivos se clasifican en:

- Eventos de la base de datos,

Clasificación de los Eventos

Los eventos de la base de datos

Clasificación de los Eventos

Los eventos temporales se clasifican en

Temporal Absoluto: se definen como eventos

Temporal Relativo: Evento de tiempo que

Clasificación de los Eventos

Los eventos explícitos (definidos por el

Una condición puede ser un predicado sobre

Se trata de una expresión que debe ser

La acción puede realizar consultas o

Las acciones se dividen en:

-Acciones Externas: Se dan cuando son

- Acciones Internas: Son acciones de la base