Un ejemplo teórico de trigger podría ser éste:

Transcripción

1 9. TRIGGERS EN LA BASE DE DATOS Un trigger (disparador sería la traducción técnica) es un bloque PLSQL que se ejecuta implícitamente cuando ocurre un evento y pueden ser de base de datos o de aplicación. Los triggers de aplicación son los que muchos de vosotros ya conoceréis como eventos dentro de un aplicación Delphi, VB, etc Nosotros vamos a hablar aquí de los triggers de la base de datos, que permiten automatizar tareas y acciones en la base de datos, simplemente cuando toquemos una tabla. Los triggers de base de datos se lanzan automáticamente cuando se ejecuta una sentencia INSERT, UPDATE ó DELETE contra la tabla asociada al trigger. Da absolutamente lo mismo qué usuario esté realizando las acciones ó que aplicación se esté usando. Esto último es muy importante ya que permite ejecutar las acciones programadas en los triggers sin importar quien o qué está manejando las tablas (Developer, VB, Delphi, C#, sentencias manuales, etc). Los triggers de base de datos sólo pueden definirse sobre tablas, no sobre vistas. Sin embargo si se lanza una operación DML sobre una vista, sí que se lanzan los triggers asociados a las tablas que forman parte de la vista. Utilizaremos triggers para garantizar que cuando se realiza una operación, se realizan las operaciones asociadas. Utilizaremos triggers para realizar acciones globales independientemente de quién o que aplicación emita la sentencia correspondiente. No debemos crear triggers para duplicar o reemplazar funcionalidades ya existentes. Por ejemplo, sería absurdo utilizar triggers para validar condiciones que ya estén definidas como CONSTRAINTS. El uso excesivo de triggers puede provocar demasiadas interdependencias, dificultando el mantenimiento posterior de las aplicaciones. Usarlos solo cuando sea necesario y tener mucho cuidado con los efectos recursivos y en cascada. Un ejemplo teórico de trigger podría ser éste: Queremos modificar el salario de uno o varios empleados, pero tenemos una tabla que establece los salarios máximos y mínimos de cada departamento. Y cada empleado pertenece a un departamento (en principio). Por lo que podemos crear un trigger que compruebe si el valor que queremos grabar en el campo salario del empleado, está dentro del rango de los salarios permitidos para su departamento. Si es así, perfecto, pero si no es así, no dejarle hacerlo, o grabar un registro de auditoría en una tabla habilitada a tal efecto. IMPORTANTE: El orden en que se ejecutan múltiples triggers del mismo tipo es arbitrario, por lo que para asegurar que los triggers del mismo tipo se ejecuten en un orden en particular, debemos consolidar los triggers en uno solo que llame a los procedimientos separados en el orden deseado. Pág 1 de 6

2 9.1. CONCEPTOS PREVIOS SOBRE TRIGGERS Antes de ponernos a crear un trigger, debemos conocer ciertos aspectos referentes a ellos y que hay que determinar antes: 1. Momento: Cuando se tiene que ejecutar el trigger con relación al evento. Puede ser antes (BEFORE) o después (AFTER). 2. Evento: Qué sentencia DML causa la ejecución del trigger (INSERT, UPDATE ó DELETE). 3. Nombre de la tabla: Tabla sobre la que se crea el trigger (ON TABLE). 4. Tipo de trigger: Cuantas veces se ejecuta el cuerpo del trigger (ROW, STATEMENT). 5. Clausula WHEN: Condición 6. Cuerpo del trigger: Bloque PLSQL (DECLARE END) Momento de ejecución Esta es una cuestión importante: Cuando debería dispararse?. Antes o después de la sentencia DML?. Claro, esto dependerá de lo que vayamos a hacer en el cuerpo del trigger. En el ejemplo anterior, claramente debería dispararse antes de la actualización del salario, pero si imaginamos ahora que tras actualizar del salario queremos añadir un registro a una tabla donde se almacenan los salarios históricos de cada empleado por fecha, está claro que esto deberíamos realizarlo después de la actualización. BEFORE triggers: Son los que se ejecutan antes de la sentencia DML. Este tipo de triggers se utiliza frecuentemente cuando la acción del trigger debe determinar si se debe permitir que se complete la sentencia DML. AFTER triggers: Estos son los que se ejecutan después de la sentencia DML. Este tipo de triggers se utilizan normalmente cuando queremos que la sentencia DML se complete antes de ejecutar la acción del trigger. Por supuesto puede existir un BEFORE trigger y un AFTER trigger para la misma sentencia. Hay un tipo de trigger especial que nos va a permitir manipular vistas. Antes dijimos: Sin embargo si se lanza una operación DML sobre una vista. Pero si una vista no es modificable, como vamos a hacerlo?. Solución: los INSTEAD OF triggers. Estos triggers sustituyen la acción que provoca su ejecución, es decir: podemos lanzar un DELETE sobre una vista no modificable y que se dispare un trigger INSTEAD OF DELETE que se encargue de borrar los registros de las tablas que componen el registro de la vista que queremos borrar. Vamos que podemos escribir sentencias normales INSERT, UPDATE y DELETE sobre una vista y el trigger INSTEAD OF correspondiente, de manera invisible, realice las acciones codificadas en su cuerpo sobre las tablas correspondientes. Aunque luego veremos la sintaxis de creación de un trigger, para este caso seria algo así: Pág 2 de 6

3 CREATE TRIGGER nombre_trigger INSTEAD OF delete insert update ON vista FOR EACH ROW.... END Evento Curso de PLSQL Es la operación u operaciones que provocarán la ejecución del trigger. Cuales son?. Pues un INSERT, un UPDATE, un DELETE o una combinación de ellas sobre una tabla. Dicha tabla es la que tendrá asociado el trigger. Cuando el evento es un UPDATE se puede incluir en la definición del trigger una lista de columnas que son las que pueden provocar el disparo del mismo si se intentan actualizar. En el caso de un INSERT o un DELETE es evidente que no hay lista de columnas ya que afectan a registros enteros. El evento puede contener varias sentencias DML. De esta forma, podemos diferenciar qué parte del código del trigger ejecutar dependiendo de la sentencia que hace que se dispare (IF INSERTING THEN, IF DELETING THEN,). Lo veremos más adelante con ejemplos Nombre de la tabla Sin comentarios. El nombre de la tabla a la que se asocia el trigger que vamos a crear Tipo de Trigger Esto determinará cuantas veces debe ejecutarse el cuerpo del trigger cuando ocurre el evento. En el caso de STATEMENT, el cuerpo solo se ejecuta una vez para el evento, y éste es el comportamiento por defecto. Ejemplo: Tras actualizar, insertar o borrar uno o varios registros de la tabla de empleados, queremos que se grabe un registro de auditoría en una tabla llamada AUDIT_EMP que especifique qué usuario de sistema lo ha hecho y a que hora, añadiendo también si fue un borrado, una inserción o una actualización, en un campo llamado ACCION. Bien, pues está claro que el cuerpo del trigger (un INSERT en la tabla AUDIT_EMP) solo se ha de ejecutar una vez no?. Además en este caso, dentro del cuerpo del trigger usaríamos las sentencias IF INSERTING THEN, IF DELETING THEN, IF UPDATING THEN para determinar qué grabamos en el campo de ACCION. Un trigger de tipo STATEMENT se ejecutará una sola vez aunque no hayan registros afectados por la(s) sentencia(s) DML que lo dispararon. En el caso de un trigger ROW, éste se ejecuta una vez para cada registro afectado. Si el evento no afecta a ningún registro, el trigger no se ejecuta. Los ROW triggers son útiles si la acción del disparador depende de los datos de los registros afectados, o de los datos proporcionados por el evento mismo. Pág 3 de 6

4 Clausula WHEN Especifica la restricción de un trigger. La condición se evalúa para cada registro para determinar si se ejecuta el cuerpo del trigger o no. Es decir, se utiliza para los ROW triggers y permite excluir algún registro afectado por la sentencia que disparó el trigger para que no se ejecute el cuerpo para ese registro Cuerpo del Trigger Aquí es donde escribimos el código PLSQL del cuerpo del trigger. Se trata de escribir la(s) accion(es) a realizar. El cuerpo del trigger se define mediante un bloque anónimo. Es importante reseñar que dentro del cuerpo del trigger tenemos acceso a los valores nuevos y viejos del registro que se está procesando. Normalmente estos valores se referencian por :OLD y :NEW aunque ya veremos que se pueden cambiar. [DECLARE] [EXCEPTION] 9.2. CREACION DE TRIGGERS La sintaxis para crear un trigger es la siguiente: CREATE [OR REPLACE] TRIGGER nombre_trigger momento evento [OR evento2 OR evento3] ON nombre_tabla BLOQUE_PLSQL ; momento: Indica el momento en el que se ejecuta el trigger en relación al evento. BEFORE ó AFTER evento: Indica la operación DML que provoca el disparo del trigger. INSERT, UPDATE [OF column nombre_columna], DELETE CREACION DE TRIGGERS STATEMENT Ahora si que vamos ya con los ejemplos prácticos para esclarecer los conceptos. He aquí un trigger STATEMENT: CREATE OR REPLACE TRIGGER horario BEFORE INSERT ON empleados IF TO_CHAR(sysdate,'HH24') NOT BETWEEN '08' AND '19' THEN RAISE_APLLICATION_ERROR(-20500, 'ERROR: Solo puede insertar empleados de 8 a 19 horas'); Este código lo que hace es comprobar si la hora actual está comprendida entre las 8 y las 19 horas. Si no es así, da un mensaje de error mediante RAISE_APPLICATION_ERROR. Como podéis ver es un trigger BEFORE INSERT, por lo que se ejecuta antes de la inserción y puede Pág 4 de 6

5 evitarla. El trigger se define sobre la tabla empleados, por lo que solo se disparará para los INSERT lanzados contra esa tabla. Ahora vamos a modificar el trigger anterior para evitar cualquier operación si no es dentro del horario. CREATE OR REPLACE TRIGGER horario BEFORE INSERT OR UPDATE OR DELETE ON empleados IF TO_CHAR(sysdate,'HH24') NOT BETWEEN '08' AND '19' THEN IF INSERTING THEN RAISE_APLLICATION_ERROR(-20500, 'ERROR: Solo puede insertar empleados de 8 a 19 horas'); ELSIF DELETING THEN RAISE_APLLICATION_ERROR(-20500, 'ERROR: Solo puede borrar empleados de 8 a 19 horas'); ELSIF UPDATING ('salario') THEN RAISE_APLLICATION_ERROR(-20500, 'ERROR: Solo puede modificar el salario de los empleados de 8 a 19 horas'); ELSE RAISE_APLLICATION_ERROR(-20500, 'ERROR: Solo puede modificar datos de los empleados de 8 a 19 horas'); Como veis, además hemos determinado qué acción se iba a realizar y hemos mostrado el mensaje personalizado para cada caso. También es de importancia observar que en la condición de UPDATING podemos colocar qué campo puede estar siendo actualizado. Bueno, y como yo soy muy purista vamos a modificar el trigger para evitar tanto código os parece?. De paso usaremos la clausula DECLARE: CREATE OR REPLACE TRIGGER horario BEFORE INSERT OR UPDATE OR DELETE ON empleados DECLARE texto VARCHAR2(100):=''; IF TO_CHAR(sysdate,'HH24') NOT BETWEEN '08' AND '19' THEN IF INSERTING THEN texto := 'insertar'; ELSIF DELETING THEN texto := 'borrar'; ELSIF UPDATING ('salario') THEN texto := 'modificar el salario de los'; ELSE texto := 'modificar datos de los'; RAISE_APLLICATION_ERROR(-20500,'ERROR: Solo puede ' texto ' empleados de 8 a 19 horas'); Pág 5 de 6

6 Ahora vamos a ver un ejemplo de un trigger AFTER STATEMENT. En el primer ejemplo de dijimos: Tras actualizar, insertar o borrar uno o varios registros de la tabla de empleados, queremos que se grabe un registro de auditoría en una tabla llamada AUDIT_EMP que especifique qué usuario de sistema lo ha hecho y a que hora, añadiendo también si fue un borrado, una inserción o una actualización, en un campo llamado ACCION Pues vamos a ello: CREATE OR REPLACE TRIGGER audita_emp AFTER INSERT OR UPDATE OR DELETE ON empleados DECLARE v_usuario VARCHAR2(50); v_accion VARCHAR2(15); --- Recuperamos el usuario de sistema operativo y no --- el de Oracle por si todos usan el mismo usuario de --- Oracle por tener gestión de usuarios propia la aplicación --- (sí moebius, va por tí, jejeje) --- Ojo!! hay que tener permisos para hacer SELECT sobre la --- tabla v$session SELECT osuser INTO v_usuario FROM v$session WHERE audsid = USERENV('SESSIONID'); --- Determinamos que acción es IF INSERTING THEN v_accion := 'INSERCION'; ELSIF DELETING THEN v_accion := 'BORRADO'; ELSIF UPDATING THEN v_accion := 'MODIFICACION'; --- Finalmente insertamos el registro de auditoria --- INSERT INTO AUDIT_EMP(usuario, fecha, accion) VALUES (v_usuario, sysdate, v_accion); EXCEPTION WHEN OTHERS THEN RAISE_APPLICATION_ERROR(-20400, 'Error al insertar auditoría.'); Para los curiosos, echadle un vistazo a la tabla v$session porque tiene algún campo que otro que os puede interesar, como puede ser la máquina desde donde está conectado el usuario, con qué programa está conectado a la base de datos.. ;-) Pág 6 de 6