Designing triggers

When creating a trigger, you must associate it with a table; when creating an INSTEAD OF trigger, you must associate it with a view. This table or view is called the target table of the trigger. The term modify operation refers to any change in the state of the target table.

About this task

A modify operation is initiated by:
  • an INSERT statement
  • an UPDATE statement, or a referential constraint which performs an UPDATE
  • a DELETE statement, or a referential constraint which performs a DELETE
  • a MERGE statement
You must associate each trigger with one of these three types of modify operations. The association is called the trigger event for that particular trigger.

You must also define the action, called the triggered action, that the trigger performs when its trigger event occurs. The triggered action consists of one or more statements which can execute either before or after the database manager performs the trigger event. Once a trigger event occurs, the database manager determines the set of rows in the subject table that the modify operation affects and executes the trigger.

Guidelines when creating triggers:
When creating a trigger, you must declare the following attributes and behavior:
  • The name of the trigger.
  • The name of the subject table.
  • The trigger activation time (BEFORE or AFTER the modify operation executes).
  • The trigger event (INSERT, DELETE, or UPDATE).
  • The old transition variable value, if any.
  • The new transition variable value, if any.
  • The old transition table value, if any.
  • The new transition table value, if any.
  • The granularity (FOR EACH STATEMENT or FOR EACH ROW).
  • The triggered action of the trigger (including a triggered action condition and triggered statement(s)).
  • If the trigger event is UPDATE a trigger-column list if the trigger should only fire when specific columns are specified in the update statement.
Designing multiple triggers:
When triggers are defined using the CREATE TRIGGER statement, their creation time is registered in the database in form of a timestamp. The value of this timestamp is subsequently used to order the activation of triggers when there is more than one trigger that should be run at the same time. For example, the timestamp is used when there is more than one trigger on the same subject table with the same event and the same activation time. The timestamp is also used when there are one or more AFTER or INSTEAD OF triggers that are activated by the trigger event and referential constraint actions caused directly or indirectly (that is, recursively by other referential constraints) by the triggered action.
Consider the following two triggers:
    CREATE TRIGGER NEW_HIRED 
      AFTER INSERT ON EMPLOYEE 
      FOR EACH ROW
      BEGIN ATOMIC 
        UPDATE COMPANY_STATS 
        SET NBEMP = NBEMP + 1; 
      END
  
    CREATE TRIGGER NEW_HIRED_DEPT 
       AFTER INSERT ON EMPLOYEE 
       REFERENCING NEW AS EMP 
       FOR EACH ROW
         BEGIN ATOMIC 
           UPDATE DEPTS 
           SET NBEMP = NBEMP + 1 
           WHERE DEPT_ID = EMP.DEPT_ID; 
         END
The preceding triggers are activated when you run an INSERT operation on the employee table. In this case, the timestamp of their creation defines which of the preceding two triggers is activated first.

The activation of the triggers is conducted in ascending order of the timestamp value. Thus, a trigger that is newly added to a database runs after all the other triggers that are previously defined.

Old triggers are activated before new triggers to ensure that new triggers can be used as incremental additions to the changes that affect the database. For example, if a triggered statement of trigger T1 inserts a new row into a table T, a triggered statement of trigger T2 that is run after T1 can be used to update the same row in T with specific values. Because the activation order of triggers is predictable, you can have multiple triggers on a table and still know that the newer ones will be acting on a table that has already been modified by the older ones.

Trigger interactions with referential constraints:
A trigger event can occur as a result of changes due to referential constraint enforcement. For example, given two tables DEPT and EMP, if deleting or updating DEPT causes propagated deletes or updates to EMP by means of referential integrity constraints, then delete or update triggers defined on EMP become activated as a result of the referential constraint defined on DEPT. The triggers on EMP are run either BEFORE or AFTER the deletion (in the case of ON DELETE CASCADE) or update of rows in EMP (in the case of ON DELETE SET NULL), depending on their activation time.