Tutorial disparadores
0 recomendaciones219 vistas
Este documento proporciona una guía sobre los disparadores en bases de datos. Explica que un disparador es un procedimiento almacenado asociado a una tabla que se ejecuta cuando se realizan operaciones como INSERT, DELETE o UPDATE en la tabla. También describe cómo diseñar, crear y utilizar disparadores, incluyendo consideraciones como evitar disparadores recursivos, el uso de predicados condicionales como INSERTING y DELETING, y el acceso a valores viejos y nuevos de filas afectadas.
Tutorial disparadores
- 1. Guía de Disparadores Un disparador (o trigger) es un procedimiento almacenado asociado a una tabla que se ejecuta al realizar una operación “básica” (INSERT, un DELETE o un UPDATE) sobre ésta. La operación básica que despierta al trigger es conocida como sentencia disparadora. La ejecución del disparador puede ser antes o después de llevar a cabo la sentencia disparadora. Es posible especificar condiciones adicionales para la ejecución d disparador (restrictores). el Dado que una sentencia disparadora puede afectar una o más filas de una tabla, es necesarioespecificar si se quiere que el disparador se ejecute para cada una de las filas afectadas o para el bloque en general. El objetivo de este documento es servir de apoyo en su proceso de familiarización con los disparadores. A continuación se presenta tópicos relacionados con el diseño, creación y utilización de disparadores. Diseño de disparadores Los disparadores pueden ser utilizados para cumplir con alguna de las siguientes tareas: o Evitar la ejecución de transacciones inválidas o Garantizar el cumplimiento de restricciones de integridad o Garantizar el cumplimiento de reglas del negocio o Generar, automáticamente, valores de columnas derivadas Cuando se diseñan disparadores es necesario tomar en cuenta las siguientes consideraciones: o El disparador no debe ser utilizado para garantizar el cumplimiento de restricciones de integridad que puedan ser definidas a nivel de esquema. Por ejemplo, no tiene sentido implementar un disparador para verificar que al insertar una tupla en la tabla Empleado que su tipo debe ser ‘A’, si es administrativo, ‘O’, si es obrero o ‘D’, si es docente. Esta restricción puede garantizarse al definir el atributo tipo_empleado de la tabla Empleado. La manera de hacerlo es colocando la restricción CHECK (tipo_empleado IN (‘A’,’O’,’D’)) o Hay que evitar crear disparadores recursivos. Por ejemplo, el crear un disparador que se active después de actualizar la tabla Empleado, que a su vez realiza una actualización de la tabla Empleado, provoca una ejecución recursiva del disparador que agota la memoria.
- 2. o Dado que los disparadores son compilados la primera vez que se activan, se recomienda que la cantidad de instrucciones de un disparador no sea muy grande (máximo 60 líneas). De esta manera, el efecto que tiene la primera ejecución sobre el rendimiento del sistema será menor. Si un trigger tiene demasiadas líneas es preferible incluir el código de éste en un procedimiento almacenado (que se almacena ya compilado). De esta forma, el trigger puede llamar al procedimiento, reduciendo así el tiempo de compilación al momento de ejecución. Para diseñar un trigger es necesario identificar cada uno de l s elementos definidos para él o (sentencia disparadora, etc). A continuación se presenta un ejemplo de un disparador implementado para garantizar una restricción de integridad. Suponga que se tienen las siguientes relaciones, asociadas al otorgamiento de préstamos en un banco: Prestatario(ci,nombre,dir,tel,empresa,tel_ofic) almacena todos los prestatarios actuales del banco. Préstamo(num_prest,ci,tasa,monto) almacena todos los préstamos que aun no han sido cancelados. El atributo ci referencia a Prestatario y es candidato a clave pues el banco no otorga simultáneamente dos préstamos a la misma persona. Cuota(num_prest,num_cuota,f_venc,f_pago) Almacena todas las cuotas de los préstamos actuales (tanto las pagadas como las pendientes). El atributo num_prest referencia a Préstamo. Se tiene como política que toda cuota debe ser pagada antes de su fecha de vencimiento. Al implantar el esquema sobre el RDBMS ORACLE se obtiene lo siguiente: CREATE TABLE Prestatario ( ci VARCHAR(8) NOT NULL PRIMARY KEY, nombre VARCHAR(50) NOT NULL, dir VARCHAR(100) NOT NULL, tel VARCHAR(10) NOT NULL, empresa VARCHAR(100) NOT NULL, tel_ofic VARCHAR(10) NOT NULL); CREATE TABLE Prestamo ( num_prest NUMBER(5) NOT NULL PRIMARY KEY, ci VARCHAR(8)UNIQUE REFERENCES Prestatario(ci), tasa NUMBER(4,2) NOT NULL, monto NUMBER(8)NOT NULL CHECK(monto > 0)); CREATE TABLE Cuota ( num_prest NUMBER(5) NOT NULL, num_cuota NUMBER(2) NOT NULL, f_venc DATE NOT NULL, f_pago DATE, CONSTRAINT pk_cuota PRIMARY KEY (num_prest,num_cuota),
- 3. CONSTRAINT fk_cuota_prest num_prest REFERENCES Prestamo(num_prest)); En la creación de las tablas se incluyeron todas las restricciones, excepto aquella que dice que toda cuota debe ser pagada antes de su fecha de vencimiento. A continuación se presenta el diseño de el disparador que garantiza el cumplimiento de esta restricción: o Sentencia Disparadora: Como en la BD están todas las cuotas (pagadas o no) asociadas a los préstamos, la fecha de pago se actualiza. Por lo tanto, la sentencia disparadora es la actualización de fecha de pago en la tabla Cuota. o Antes/Después: La restricción de integridad no se puede violar, por lo tanto el trigger debe ser disparado antes de realizar la actualización. o Para Todas/Para el bloque : La verificación de la restricción se hace para todas las filas que se actualicen al ejecutar la sentencia disparadora. o Restrictor: Se debe impedir la actualización, sólo cuando la fecha de pago sea mayor que la fecha de vencimiento de la cuota. o Acción: Dar un error por violación de la restricción. Creación de Disparadores Los disparadores se crean utilizando el comando CREATE TRIGGER. Este comando puede utilizarse con cualquier herramienta interactiva (como SQL*Plus o SQL*DBA). Cuando se usan estas herramientas interacticas, se indica que se terminó de especificar la instrucción CREATE TRIGGER, colocando un slash ("/") en la última línea. A continuación se especifica el trigger asociado con la tabla cuota: CREATE TRIGGER BUpCUOTA BEFORE UPDATE OF f_pago ON Cuota FOR EACH ROW WHEN (new.f_pago > old.f_venc) BEGIN raise_application_error(-19746, ‘Cuota ‘ || TO_CHAR(:old.num_cuota) || ‘ del prestamo ‘ || TO_CHAR(:old.num_prest) || ‘ vencida. Favor dirigirse a la gerencia.’); END; / A continuación se presentan algunos aspectos generales con respecto a la definición de triggers: o Los nombres de los triggers deben ser únicos dentro de un esquema dado. Los nombres no tienen por qué ser únicos con respecto a otros objetos del esquema (por
- 4. ejemplo, tablas, vistas, etc.). Sin embargo, se recomienda usar nombres distintos para evitar confusiones. o Alguna de las dos, BEFORE o AFTER, debe ser utilizada en el CREATE TRIGGER. De esta manera se especifica exactamente cuando se despierta el disparador, en relación con la ejecución de la sentencia activadora. La opción BEFORE o AFTER se especifica justo antes de especificar la sentencia activadora. El trigger BUpCUOTA es un before trigger. o En algunos casos da lo mismo si el trigger se ejecuta antes o después de realizar la sentencia activadora. En estos casos, un after trigger es ligeramente más eficiente que un before trigger, pues con estos últimos los registros de datos afectados son leidos (lógicamente) dos veces: u para el disparador y otra para la sentencia disparadora. na Con los after triggers se leen los registros de datos sólo una vez. o La sentencia activadora especifica el tipo de operación que despierta el disparador (DELETE, INSERT o UPDATE). Una, dos o incluso las tres operaciones pueden ser incluidas en la especificación de la sentencia activadora. o En la sentencia activadora se especifica la tabla asociada al trigger. Note que puede especificarse exactamente una tabla (no una vista) en la sentencia activadora. o Si la sentencia activadora especifica un UPDATE se puede incluir una lista de columnas en dicha sentencia. Si se incluye la lista de columnas, el trigger se activa por un UPDATE sólo si una de las columnas especificadas es actualizada. Si se omite la lista, el trigger se activa cuando cualquier columna de la tabla se actualiza. No se puede especificar lista de columnas para INSERT o DELETE. o La presencia o ausencia de la opción FOR EACH ROW determina si el disparador es a nivel de filas (row trigger) o a nivel de sentencia activadora (statement trigger). Si está presente, esta opción especifica que el cuerpo del trigger se ejecuta individualmente para cada una de las filas de la tabla que haya sido afectada por la sentencia activadora. La ausencia de la opción FOR EACH ROW implica que el trigger se ejecuta una sola vez, para la ejecución de una sentencia activadora. o Opcionalmente, se pueden incluir restricciones en la definición de un row trigger. Para ello se especifica, en una cláusula WHEN, una expresión boolena de SQL. Si se incluye una cláusula WHEN, la expresión se evalúa para cada una de las filas que el disparador afecta. Si el resultado de la evaluación es TRUE, se ejecuta el cuerpo del trigger sobre la fila que hizo cierta la expresión. Si el resultado de la evaluación es FALSE o NOT TRUE (desconocido, como con los valores nulos) para una fila dada, el cuerpo del trigger no se ejecuta para dicha fila. o La expresión en una cláusula WHEN no puede incluir subqueries. o El cuerpo de un trigger es un bloque de PL/SQL que puede incluir instrucciones de PL/SQL y de SQL. Este bloque de instrucciones se realiza si se ejecuta la sentencia activadora especificada para el trigger y, si existe una cláusula WHEN ésta es TRUE. o La instrucción CREATE TRIGGER falla si hay algún error en el bloque PL/SQL.
- 5. o El cuerpo de un row trigger puede incluir ciertos elementos especiales: nombres de correlación y los predicados condicionales predicates INSERTING, DELETING y UPDATING. o En el cuerpo de un disparador, el código PL/SQL y las instrucciones de SQL tienen acceso a los valores nuevos y viejos de las columnas de la fila actual afectada por la sentencia activadora. Existen dos nombres de correlación para cada columna de la tabla que está siendo modificada: uno para el valor viejo y otro para el valor nuevo. o Dependiendo del tipo de sentencia activadora, algunos nombres de correlación pueden no tener sentido. En un trigger activado por un INSERT sólo tiene sentido hablar de los valores nuevos. En un trigger activado por un UPDATE tiene sentido hablar de los valores nuevos y los viejos tanto para los before triggers como para los after triggers. En un trigger activado por un DELETE, sólo tiene sentido hablar de los valores viejos. o Los valores nuevos son referenciados utilizando “:new.” antes del nombre de la columna, mientras que los viejos utilizan “:old.” (los “:” son necesarios dentro del bloque de PL/SQL para indicar que es un valor que viene de afuera de la expresión SQL). En el ejemplo se usa “:new.num_prest” en el cuerpo del trigger. o La expresión en una cláusula WHEN de un row trigger puede incluir nombres de correlación. Note que los calificadores se usan sin los “:”. o Si un before row trigger cambia el valor de algún “:new.columna”, un after row trigger para la misma sentencia activadora verá el cambio realizado por el before row trigger. o Si un trigger puede ser activado por más de un tipo de operación (por ejemplo, "INSERT OR DELETE OR UPDATE OF Cuota"), el cuerpo del trigger puede utilizar los predicados condicionales INSERTING, DELETING y UPDATING para ejecutar bloques específicos de código, dependiendo del tipo de operación que activó el disparador. Por ejemplo, si se tiene INSERT OR UPDATE ON Cuota dentro del código del trigger se pueden incluir las siguientes condiciones: IF INSERTING THEN . . . END IF; IF UPDATING THEN . . . END IF; la primera condición es cierta sólo si la operación que disparó el trigger es un INSERT. La segunda condición es cierta sólo si la operación que disparó el trigger es un UPDATE. ? En un UPDATE, se puede especificar el nombre de una columna en un predicado condicional UPDATING para determinar si la columna especificada ha sido actualizada. Por ejemplo: CREATE TRIGGER . . . . . . UPDATE OF sal, comm ON emp . . . BEGIN . . . IF UPDATING ('sal') THEN . . . END IF;
- 6. END; La siguiente instrucción dispara el trigger anterior y hace que el predicado condicional the UPDATING (sal) se evalúe comoTRUE: UPDATE emp SET sal = sal + 100; o Si se produce una excepción o condición de error (predefinida o definida por el usuario) durante la ejecución del cuerpo del disparador, se hace ROLLBACK de todos los efectos del cuerpo del trigger y de la sentencia activadora (a menos que se haga un manejo específico de la excepción). Por lo tanto, el cuerpo de un trigger puede evitar la ejecución de una sentencia activadora produciendo una excepción. o Sólo se puede definir un trigger de cada tipo por tabla. Esto da doce posibilidades: BEFORE UPDATE row AFTER UPDATE row BEFORE DELETE row AFTER DELETE row BEFORE INSERT row AFTER INSERT row BEFORE UPDATE statement AFTER UPDATE statement BEFORE DELETE statement AFTER DELETE statement BEFORE INSERT statement AFTER INSERT statement Cada tabla puede tener hasta cuatro UPDATE triggers (BEFORE/AFTER, statement/row), sin importar si los triggers son disparados sólo cuando se actualizan algunas columnas de la tabla. o El cuerpo de un trigger puede incluir cualquier instrucción del DML SQL, incluyendo SELECT (que debe ser un SELECT-INTO o un SELECT en la definición de un cursor), INSERT, UPDATE y DELETE. No se permiten instrucciones del DDL ni instrucciones para el control de transacciones (ni ROLLBACK, ni COMMIT ni SAVEPOINT). o Una instrucción SQL dentro de un trigger puede insertar datos en una columna de tipo LONG o LONG RAW. Sin embargo, no se pueden declarar variables de estos tipos en el cuerpo del disparador. Además, ni :NEW ni :OLD pueden ser usados con columnas de tipo LONG o LONG RAW. o No se deben crear triggers que dependan del orden en el cual las filas sean procesadas. Recuerde que una BD relacional no garantiza el orden de las filas al ser procesadas por una instrucción SQL. o Cuando una instrucción de un trigger produce que se dispare otro trigger, se dice que estos están “en cascada”. ORACLE permite hasta 32 triggers en cascada. o Una tabla que está “mutando” es una tabla que está siendo modificada por un INSERT, un DELETE o un UPDATE o una tabla que podría modificarse por los efectos de un DELETE CASCADE (integridad referencial). Una tabla está “restringiendo” si una sentencia activadora podría necesitar leerla directamente, por una sentencia SQL, o indirectamente, por una restricción de integridad referencial. Una tabla no se considera ni mutando ni restringiendo para los triggers. Sin embargo, hay dos restricciones importantes con respecto a las tablas que mutan o que restringen:
- 7. 1. Las instrucciones de un row trigger no pueden ni leer ni modificar una tabla que está mutando. 2. Las instrucciones de un row trigger no pueden cambiar ni la clave primaria, ni claves foráneas, ni atributos únicos de tablas que estén restringiendo. Esta restricción tiene una excepción: un before row trigger disparado por un INSERT de una sola fila de una tabla con una clave foránea, puede modificar cualquier columna de la tabla primaria siempre que no se viole ninguna de las restricciones de integridad referencial. Depurando disparadores Los triggers pueden ser depurados utilizando las mismas facilidades disponibles para depurar procedimientos y paquetes. Modificando disparadores Un trigger no puede ser alterado explícitamente. Debe ser reemplazado por una nueva definición. Cuando se reemplaza un disparador se debe incluir la opción OR REPLACE en la instrucción CREATE TRIGGER. Por ejemplo, CREATE OR REPLACE TRIGGER BUpCUOTA . . . Otra alternativa es eliminar el trigger y volverlo a crear. Por ejemplo, DROP TRIGGER BUpCUOTA; CREATE TRIGGER BUpCUOTA . . . Los triggers pueden estar habilitados o deshabilitados. Los triggers están habilitados por default. Los triggers pueden deshabilitarse si: o Un objeto al que hace referencia no está disponible. o Se tienen que realizar cargas masivas de datos y se quiere proceder sin disparar triggers. o Se están volviendo a cargar datos. o Cualquier otro caso en el que se considere necesario. Para deshabilitar un trigger se utiliza el comando ALTER TRIGGER con la opción DISABLE. Por ejemplo: ALTER TRIGGER BUpCuota DISABLE;
- 8. Es posible deshabilitar todos los triggers asociados a una tabla utilizando la opción ALL TRIGGERS con el ALTER TABLE. Por ejemplo, ALTER TABLE Cuota DISABLE ALL TRIGGERS; Para volver a habilitar un trigger, se utiliza el comando ALTER TRIGGER con la opción ENABLE. Por ejemplo, ALTER TRIGGER BupCuota ENABLE; Para habilitar todos los triggers asociados a una tabla se utiliza la opción ALL TRIGGERS con el ALTER TABLE. Por ejemplo, ALTER TABLE Cuota ENABLE ALL TRIGGERS; Ejemplos A continuación se presentan algunos ejemplos de triggers, tomados del manual de ORACLE: o Para garantizar restricciones de integridad CREATE TRIGGER salary_check BEFORE INSERT OR UPDATE OF sal, job_classification ON emp FOR EACH ROW DECLARE minsal NUMBER; maxsal NUMBER; salary_out_of_range EXCEPTION; BEGIN /* Retrieve the minimum and maximum salary for the employee's new job classification from the SALGRADE table into MINSAL and MAXSAL. */ SELECT minsal, maxsal INTO minsal, maxsal FROM salgrade WHERE job_classification = :new.job_classification; /* If the employee's new salary is less than or greater than the job classification's limits, the exception is raised. The exception message is returned and the pending INSERT or UPDATE statement that fired the trigger is rolled back. */ IF (:new.sal < minsal OR :new.sal > maxsal) THEN RAISE salary_out_of_range; END IF; EXCEPTION WHEN salary_out_of_range THEN raise_application_error (-20300, 'Salary '||TO_CHAR(:new.sal)||' out of range for '
- 9. ||'job classification '||:new.job_classification ||' for employee '||:new.name); WHEN NO_DATA_FOUND THEN raise_application_error(-20322, 'Invalid Job Classification ' ||:new.job_classification); END; o Para generar valores de columnas derivadas: BEFORE INSERT OR UPDATE OF ename ON emp /* Before updating the ENAME field, derive the values for the UPPERNAME and SOUNDEXNAME fields. Users should be restricted from updating these fields directly. */ FOR EACH ROW BEGIN :new.uppername := UPPER(:new.ename); :new.soundexname := SOUNDEX(:new.ename); END;