BD Activas: Motivación

Presentación del tema: "BD Activas: Motivación"— Transcripción de la presentación:

1 BD Activas: Motivación
Los SGBD convencionales son “pasivos”. Sólo ejecutan preguntas o transacciones realizadas por los usuarios o por los programas de aplicación. Para representar la semántica del mundo real proporcionan: MODELO DE DATOS Estructuras de Datos Operadores para trabajar con las estructuras Reglas de integridad MODELO DE TRANSACCIONES Posibilidad de definir transacciones pero sólo si los usuarios o aplicaciones lo solicitan explícitamente

2 BD Activas: Motivación (2)
Los SGBD “pasivos” NO SON BUENOS para modelar comportamiento dirigido por sucesos. Ejemplo: si el stock de un producto baja de un cierto umbral entonces solicitar más. Para implementarlo: 1) En toda aplicación que modifique el stock de algún producto hay que añadir código que compruebe si se baja del umbral para solicitar más. La semántica está distribuida por las aplicaciones. Posiblemente es una fuente de errores. 2) Realizando un programa que periódicamente “sondee” todas las condiciones (¿ stock(i) < umbral(i) ?) Frecuencia de sondeo alta --> INEFICIENCIA Frecuencia de sondeo baja --> INCONSISTENCIAS Tenemos una BD con información sobre productos: BD productos Cod Nombre Stock Stock_min H3 Lavadora ACME Si se desea que cuando se cumpla Stock < Stock_min se pidan más, entonces: 1) Hacerlo en todas las aplicaciones que modifiquen el stock. Aplicación: Venta si para el producto vendido se cumple Stock < Stock_min entonces “pedir más” Aplicación: Envío de productos a otra tienda (de la misma cadena) si para el producto enviado se cumple Stock < Stock_min 2) O si no, realizar un programa que sondee esas condiciones: para todo producto si Stock < Stock_min entonces “pedir más” Si el programa de sondeo se ejecuta cada minuto es posible que se ralentice todo el sistema. ¡Una operación de venta podría tener que esperar! Si el programa de sondeo se ejecuta a las noches entonces no se ralentizará el sistema (la tienda estará cerrada) pero... ¡ igual se quedan sin lavadoras para vender a la tarde !

3 BD Activas: Definición y Modelo de Conocimiento
Un Sistema de Bases de Datos Activas es un sistema que monitoriza situaciones de interés y que, cuando ocurren, dispara o activa la ejecución de una serie de acciones. El comportamiento deseado se expresa en forma de Reglas Evento-Condición-Acción (ECA) ON evento IF condición THEN acción Nota: Las reglas ECA provienen del paradigma de las Reglas de Producción (IF condición THEN acción) tratado en Inteligencia Artificial (sobre todo en Sistemas Expertos) En Sistemas Expertos: BASE DE HECHOS BASE DE REGLAS Reglas: IF condición THEN acción las cuales modifican la Base de Hechos. Existe un motor de inferencia que aplica las reglas y que decide qué regla hay que aplicar cuando existe un conjunto conflicto de reglas que se pueden aplicar a la vez. Cuando queremos expresar secuencialidad en las reglas (primero que se ejecute una y luego otra, etc.) hay que añadir condiciones en las reglas para conseguirlo. Podemos meternos en ciclos infinitos de reglas que se activan, etc. Programar BIEN con reglas puede ser complicado ya que unas disparan a otras. Ahora volvemos a algo parecido: BASE DE DATOS BASE DE REGLAS ECA que modifican la BASE DE DATOS. Existirá el problema de que ciertas modificaciones activarán otras reglas ECA (o triggers). En ORACLE tendremos el problema de las tablas mutantes.

4 Modelo de Conocimiento
ON evento IF condición THEN acción evento puede ser un suceso primitivo: ocurre una operación con la BD (insert, ...) comienza / termina una transacción (commit,..) suceso externo: bajada de tensión suceso temporal: es primer día de mes suceso abstracto: violada una regla de integridad o un suceso compuesto: S1 OR S2 (sucede el suceso S1 o el S2) S1 AND S2 (suceden ambos sucesos) S1 ; S2 (sucede S1 y después S2)

5 Modelo de Conocimiento (2)
ON evento IF condición THEN acción Se cumple una determinada condición en la BD el valor de un atributo es uno determinado el valor nuevo a insertar es menor que el viejo etc. Se dice que se ejecute algo automáticamente un abort o rollback mandar un mensaje al usuario introducir / modificar datos en la base de datos Ejemplos: ON acceso al salario de los empleados IF usuario no autorizado THEN rechazar el acceso ON cambio en el salario de un empleado IF el nuevo salario es menor que el que existía THEN rechazar la operación ON último día de mes IF true THEN imprimir las nóminas ON cambio en la tarea asignada a un empleado THEN introducir datos en una tabla histórica

6 Modelo de Ejecución Es el comportamiento de las reglas en tiempo de ejecución. Se debe conocer: 1) Cuándo se evalúan los eventos (la frecuencia, si se evalúan dentro de transacciones, etc.) Durante la ejecución de una transacción puede haber momentos en los que la BD está inconsistente 2) A qué reglas ECA se les evalúa antes la condición de entre las activadas por los eventos ¿Los eventos que ya han activado reglas pueden seguir activando otras? Ej: el evento “es el primer día del mes” 3) Qué regla ECA se ejecutará la primera de entre las que cumplen la condición. Relacionado con el problema del conjunto conflicto detectado por el motor de inferencia en S. Expertos

7 Triggers en ORACLE 7 EVENTO CONDICIÓN ACCIÓN
CREATE [OR REPLACE] TRIGGER nombre_de_trigger {BEFORE | AFTER} {DELETE | INSERT | UPDATE [OF nom_atr [, nom_atr] ...]} [OR {DELETE | INSERT | UPDATE [OF nom_atr [, nom_atr] ...]}] ... ON nom_tabla [ [REFERENCING { OLD [AS] old [NEW [AS] new] | NEW [AS] new [OLD [AS] old] } ] [FOR EACH ROW [WHEN (condición)] ] bloque_PL/SQL EVENTO CONDICIÓN ACCIÓN

8 Triggers en ORACLE 7 (2) OR REPLACE --> Reemplaza el trigger si ya existe BEFORE/AFTER DELETE, INSERT, ... ON tabla Indica si la acción (PL/SQL) se debe ejecutar antes o después de que se produzca el borrado, inserción o modificación de la tabla. FOR EACH ROW indica que se ejecute la acción (si se cumple la condición) para cada tupla insertada, borrada,... WHEN --> Es una condición SQL. No puede contener una pregunta SQL. Sólo SE PUEDE PONER la parte WHEN en triggers del tipo FOR EACH ROW El bloque PL/SQL es la parte acción que ORACLE ejecuta cuando se produce el evento y se cumple la condición

9 Triggers en ORACLE 7 (3) Cuando los triggers son del tipo FOR EACH ROW, dentro del bloque PL/SQL se pueden utilizar las variables: :NEW que contiene el NUEVO valor INSERTADO o MODIFICADO El valor de :NEW se puede cambiar en triggers del tipo BEFORE INSERT/UPDATE pero no en triggers del tipo AFTER así se podrá controlar el valor que se va a introducir. :OLD que es el valor BORRADO o el valor viejo MODIFICADO. Con REFERENCING OLD AS mi_old ... podemos renombrar OLD para que no haya problemas de nombres. Ej: una tabla se llama OLD Dentro del bloque PL/SQL se pueden realizar distintas acciones según se esté insertando, borrando o actualizando: IF INSERTING THEN ... END IF; IF DELETING THEN ... END IF; IF UPDATING (‘nom_atr’) THEN ... END IF;

10 Restricciones en triggers Oracle
El bloque PL/SQL que forma la parte acción no puede contener sentencias como COMMIT o ROLLBACK (ni CREATE..., ALTER...) No se pueden crear triggers sobre tablas del sistema que forman el catálogo. Sería bueno para realizar acciones cada vez que se creara, borrara, etc. una tabla en la BD !! Dentro de un trigger no se puede ni hacer SELECT de una tabla mutante, ni se puede cambiar la clave primaria, una clave ajena o claves únicas de una tabla restringida. Una tabla mutante es aquella sobre la que se está haciendo un INSERT, un DELETE, un UPDATE o una tabla que puede ser afectada debido a una restricción DELETE CASCADE. Una tabla restringida es aquella que es usada dentro de un trigger, por una sentencia SQL o para mantener una integridad referencial. Una tabla no es considerada mutante ni restringida para triggers que NO SON del tipo FOR EACH ROW (excepto si el trigger se ha lanzado debido a una restricción DELETE CASCADE).

11 Consejos sobre Triggers Oracle
No definir triggers para definir restricciones de integridad que es posible definir de manera declarativa como REFERENCES, atributos NOT NULL, UNIQUE, etc. Sí pueden servir para implementar los siguientes (no soportados todavía por Oracle) ON DELETE / UPDATE SET NULL, ON DELETE / UPDATE SET DEFAULT No construir triggers recursivos.