1. Fall 2001Database Systems1 Triggers Assertions –Assertions describe rules that should hold for a given database. –An assertion is checked anytime a table mentioned in it is changed. –If an assertion is violated, then the change that caused the violation is rejected. Triggers –Triggers explicitly specify when they should be checked (i.e. insert, delete, update) –They describe a condition that activates the trigger if it evaluates to true –Triggers describe what is to be done upon activation

2. Fall 2001Database Systems2 Designing triggers Use triggers to guarantee that when a specific operation is performed, related actions are performed. Do not define triggers that duplicate the functionality already built into Oracle. For example, do not define triggers to enforce data integrity rules that can be easily enforced using declarative integrity constraints. Limit the size of triggers. If the logic for your trigger requires much more than 60 lines of PL/SQL code, then it is better to include most of the code in a stored procedure and call the procedure from the trigger. Use triggers only for centralized, global operations that should be fired for the triggering statement, regardless of which user or database application issues the statement. Do not create recursive triggers. For example, creating an AFTER UPDATE statement trigger on the Emp_tab table that itself issues an UPDATE statement on Emp_tab, causes the trigger to fire recursively until it has run out of memory. Use triggers on DATABASE judiciously. They are executed for every user every time the event occurs on which the trigger is created.

3. Fall 2001Database Systems3 Example CREATE OR REPLACE TRIGGER Print_salary_changes BEFORE DELETE OR INSERT OR UPDATE ON Emp_tab FOR EACH ROW WHEN (new.Empno > 0) DECLARE sal_diff number; BEGIN sal_diff := :new.sal - :old.sal; dbms_output.put('Old salary: ' || :old.sal); dbms_output.put(' New salary: ' || :new.sal); dbms_output.put_line(' Difference ' || sal_diff); END; /

4. Fall 2001Database Systems4 Triggers – activation A trigger can be activated BEFORE/AFTER/INSTEAD OF an activating event, usually insert/delete/update to one or more relations The action can refer to both old and new values of tuples that were inserted/deleted/updated in the event that triggered the action. CREATE TRIGGER probation_trigger AFTER UPDATE OF gpa ON student A condition may include a WHEN clause –the trigger action is executed only if the condition holds when the triggering event occurs The WHEN clause takes any boolean condition WHEN (gpa < 2.0)

5. Fall 2001Database Systems5 Trigger - course of action The programmer has the option of specifying that the action is performed either –once for each modified tuple, or –once for all the tuples that are changed in one database operation FOR EACH ROW UPDATE student SET probation_date = SYSDATE WHERE student.sid = OldTuple.sid The trigger body can use any valid PL/SQL statement, IF THEN ELSE, WHILE, etc.

6. Fall 2001Database Systems6 Trigger - exceptions If a predefined or user-defined error condition or exception is raised during the execution of a trigger body, then all effects of the trigger body, as well as the triggering statement, are rolled back (unless the error is trapped by an exception handler). Therefore, a trigger body can prevent the execution of the triggering statement by raising an exception. User-defined exceptions are commonly used in triggers that enforce complex security authorizations or integrity constraints.

7. Fall 2001Database Systems7 Triggers - row level Insertions create new tuples –There is no corresponding “old” value Updates change a tuple from an old value to a new value –You can refer to both values: “old” and “new” of the tuple in the trigger Deletes remove a tuple –There is no new value for the tuple (it is null) Old/New values can only be accessed for each row, statement level triggers cannot access values of individual rows that are being changed.

8. Fall 2001Database Systems8 Triggers Activation –BEFORE -- the WHEN condition is tested before the triggering event if the condition is true, the trigger action is executed then the event that triggered the update is executed –INSTEAD OF -- the action is executed if the WHEN condition is met the triggering event is never executed. –AFTER – the action is executed if the WHEN condition is met after the triggering event is completed. In BEFORE/AFTER trigger, the triggering event is rejected only if an exception is raised.

9. Fall 2001Database Systems9 Mutating tables A mutating table is a table that is currently being modified by an UPDATE, DELETE, or INSERT statement, or it is a table that might need to be updated by the effects of a declarative DELETE CASCADE referential integrity constraint. A constraining table is a table that a triggering statement might need to read either directly, for an SQL statement, or indirectly, for a declarative referential integrity constraint. A table is mutating or constraining only to the session that issued the statement in progress. Tables are never considered mutating or constraining for statement triggers unless the trigger is fired as the result of a DELETE CASCADE. Views are not considered mutating or constraining in INSTEAD OF triggers.

10. Fall 2001Database Systems10 Mutating tables For all row triggers, or for statement triggers that were fired as the result of a DELETE CASCADE: –The SQL statements of a trigger cannot read from (query) or modify a mutating table of the triggering statement. –The statements of a trigger cannot change the PRIMARY, FOREIGN, or UNIQUE KEY columns of a constraining table of the triggering statement. There is an exception to this restriction: For a single row INSERT, constraining tables are mutating for AFTER row triggers, but not for BEFORE row triggers. INSERT statements that involve more than one row, such as INSERT INTO Emp_tab SELECT..., are not considered single row inserts, even if they only result in one row being inserted. These restrictions prevent a trigger from seeing an inconsistent set of data.

11. Fall 2001Database Systems11 Mutating tables

12. Fall 2001Database Systems12 Example TOOK(ssn, cid, semester, year, section, grade) Students may not enroll in more than one section of a class in the same semester and year. If this happens, delete all records for this student in other sections and insert him/her in the new section.

13. Fall 2001Database Systems13 Example CREATE OR REPLACE TRIGGER took_trg AFTER INSERT ON took REFERENCING NEW AS x FOR EACH ROW BEGIN DELETE FROM took t WHERE t.cid = :x.cid AND t.semester=:x.semester AND t.year = :x.year AND t.ssn = :x.ssn AND t.section <> :x.section ; END ; / Problem: took is mutating!

14. Fall 2001Database Systems14 Example – correct solution CREATE VIEW tookv AS SELECT * FROM took ; CREATE OR REPLACE TRIGGER took_trg INSTEAD OF INSERT ON tookv REFERENCING NEW AS x FOR EACH ROW BEGIN DELETE FROM took t WHERE t.cid = :x.cid AND t.semester=:x.semester AND t.year = :x.year AND t.ssn = :x.ssn AND t.section <> :x.section ; INSERT INTO took(cid, semester, year, section, ssn) VALUES(:x.cid,:x.semester,:x.year,:x.section,:x.ssn) ; END ; /