Triggers in SQL allow users to specify actions that are automatically performed in response to insert, update, or delete events on a table. Triggers can be defined to execute before, after, or instead of the triggering event. Triggers have access to old and new values of rows that are inserted, updated, or deleted. Care must be taken with triggers on mutating tables to avoid inconsistent data access or infinite recursion.

1. Triggers in SQL
1
Fall 2001 Database Systems 1
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
Fall 2001 Database Systems 2
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.

2. Triggers in SQL
2
Fall 2001 Database Systems 3
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;
/
Fall 2001 Database Systems 4
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)

3. Triggers in SQL
3
Fall 2001 Database Systems 5
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.
Fall 2001 Database Systems 6
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.

4. Triggers in SQL
4
Fall 2001 Database Systems 7
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.
Fall 2001 Database Systems 8
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.

5. Triggers in SQL
5
Fall 2001 Database Systems 9
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.
Fall 2001 Database Systems 10
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.

6. Triggers in SQL
6
Fall 2001 Database Systems 11
Mutating tables
Fall 2001 Database Systems 12
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.

7. Triggers in SQL
7
Fall 2001 Database Systems 13
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!
Fall 2001 Database Systems 14
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 ;
/

8. Triggers in SQL
8
Fall 2001 Database Systems 15
SQL Environment
Schema
Schema
Catalog
Catalog
Cluster = maximum
scope of a DB
operation
Cluster
Environment =
installation of
DBMS
• A schema contains
tables, views, assertions,
domains,indices, etc.
• A catalog contains a
collection of schemas
• A cluster is a collection of
catalogs.
– each user has a cluster
that is the set of all
catalogs accessible to
the user
• An environment is an
installation of a DBMS
Fall 2001 Database Systems 16
System catalogs
• All DBMSs maintain system catalogs as ordinary
relations
– these tables can be queried using SQL in the same
way as any ordinary table
• For ORACLE:
– ALL_ALL_TABLES (OWNER, TABLE_NAME, … )
– ALL_COL_PRIVS(GRANTOR, GRANTEE, TABLE_SCHEMA,
TABLE_NAME, COLUMN_NAME, PRIVILEGE, GRANTABLE)
– also ALL_TAB_PRIVS
– ALL_CONSTRAINTS (OWNER, CONSTRAINT_NAME,
CONSTRAINT_TYPE, TABLE_NAME, SEARCH_CONDITION,
DELETE_RULE, STATUS, DEFERRABLE, … )
– ALL_VIEWS, ALL_TABLES, ALL_USERS, ALL_ROLES, etc.