Triggers and Active Databases

CS561

Practical Applications of Triggers and Constraints: Successes and Lingering Issues

Stefano Ceri Roberta J. Cochrane Politecnico di Milano IBM Almaden Research Center

Jennifer Widom Stanford University

Information in presentation based on VLDB’2000 “test-of-time” paper

What are Triggers, and why ?

Idea of triggers were developed for “data constraints”

Example: Relation of baseball players and salary. If new player added, trigger will check to see if team is over salary cap and will impose a penalty to team.

Triggers make a passive database “active” Database reacts to certain situations

Event Condition Action rule : on event insert/update/delete, if condition C is true then do action A

Brief History 1975: Idea of “integrity constraints” Mid 1980-1990: research in constraints & triggers

Languages and algorithms SQL-92: constraints

Key constraints; referential integrity, domain constraints Declarative spec and procedural interpretation

SQL-99: triggers/ECA (limited) Early acceptance; Widely-varying support in products;

“execution semantics” differ, how far to go ? Now :

New “hot” incarnation in streaming …

Uses / Advantages

To move application logic and business rules into database

This allows more functionality for DBAs to establish vital constraints/rules of applications

Rules managed in some central “place”Rules automatically enforced by DBMS, no

matter which applications later come on line

Active DB vs Rule Systems Expert Systems/AI:

Focus primarily on “reasoning” (in place of algorithmic solution), e.g., <if A then B holds>

Typically, no “active action” can be takenTypically no notion of “triggering” based on

“events”, but rather chaining of facts togetherTypically little data (all in main memory)Typically, limited performance (RETE

network)Typically no notion of concurrent users and

transactions

Classification of Triggers

Two Types of TriggersGenerated: based on some higher-level

specificationHandcrafted: usually specific to some

application

Theme : Generated

Triggers (active rules) are difficult to write correctly

Idea: Trigger application specified at higher level

(declarative) Actual triggers to implement the application generated

from specification Semi-automatic Correctness guaranteed

Example : Constraints

Specify acceptable database states<condition X must hold>

Mapping:When <potentially invalidating operations> If <constraint violated>Then <fix it>

Example : Constraints Constraint : Predicate not to hold on table Example : Every employee’s department must exist

Emp: not exists (select * from dept where dno = emp.dno) System produces in general:

Create rule <name> on table When <invalidating ops> if exists (select * from <table> where <predicate>) Then <action>

System produces for our example: Create rule <name> on emp When inserted, , updated (dno) if exists (select * from emp where not exists (select * from dept where

dno=emp.dno)) Then <Reject update>

Similar rule created for dept table, and delete and updates on it.

Classification of Triggers

Two Types of Triggers Generated: based on some higher-level specification Handcrafted: usually specific to some application

Three Classes of Usage Kernel DBMS: hard coded into kernel DBMS services: enhances database functionality External applications: creating triggers specific to

application

Generated Triggers

DBMS KernelReferential integrity

If foreign key in a table is deleted or updated, it causes an action usually specified by user: set null/cascade

Materialized views Set of triggers that keep data consistent

Either re-computes view, or Better changes view each time base data is changed

Generated Triggers

DBMS Services Alerter

When data changes, message can be sent to user Example: A sensor will notice that only one milk carton is left

on the shelf, and a message could be send to manager.

Replication If a table is copied, a trigger will observe updates to that original

table and will change copied table.

Audit Trails, Migration, Extenders, etc. Big Success Story :

Services simple to specify; yet procedural semantics. Only moderately configurable.

Example: IBM DB2 has numerous such trigger-based services

Generated Triggers

External Applications

Workflow managementExternal tools with support for generation of

“Process Rules/Models”

Handcrafted Triggers

Embedded DBMS KernelMetadata management Internal audit trails

But:Triggers excellent for prototyping; but often

replaced by code directly

Handcrafted Triggers

DBMS Services

Not generally used here

Handcrafted Triggers External Applications

Straightforward use of triggers Application specific

Additional forms of “data integrity” Could be used to compute derived columns Or, enforce arbitrarily complex application-specific semantics

Examples: Business rules, supply chain management, web applications, etc.

But : Triggers are challenging to use for complex applications Need wizard to let developer specify trigger in higher level

language

Classification

Generated Constraint preserving Invalidating Materializing Metadata Replication Extenders Alerters

Handcrafted Application specific

Challenges

Challenge : Semantics ?

What causes a rule to be triggered? (states, ops, transitions)

At what granularity are rules triggered ? (after tuple change, set level change, transaction, etc).

What happens when multiples rules are triggered? (arbitrary order, numeric or priorities suggested)

Can rules trigger each other, or themselves?

In general, many subtle design choices exist !

Support for Triggers in DBMS?

DDL : Add/Disable triggers; scope DML : What can rule do Extra support for rule execution: e.g., “delta

tables” Query optimization : also consider rules Query execution : interrelationship with constraints Indexing and rules Transaction management and rules (coupled or

not)

Challenges – Triggers in Products No uniformity among trigger support in products Triggers simple : typically cannot encode complex

conditions (optimization problem; poor performance)

Typically, no time-based events Semantics: transactional; interrelationships; etc. Triggers aren’t scalable (one per table often, or so) Triggers difficult to use (if many of them)

Trigger interaction analysis No high-quality trigger design tools

Challenge: Rule Analysis Termination: produces a final state Confluence : terminates and produces a final state that does not depend

on order of execution Observable Determinism : all visible actions performed by rules are the

same at all states of processing

Termination : Find cycles Examine rules in cycle for behavior Could determine that terminate in some cases Data dependent : even if at compile-time has cycle, still may be useful In general , undecidable ( ~ FOL with predicates and implication)

In practice (Oracle) : Optimistic solution Terminate after 25 trigger invocations, and rollback

Trigger Implementation Two methods (Postgres):

Tuple-level marking Query rewriting

Pros and Cons : Tuple-level marking – works well for lots of rules

applying to few tuples Query rewriting – works well for few rules applying to

lots of tuples

But: Semantics may differ

Implementation : Marking Place markers on all tuples for which

rules apply : If markers encountered during executionCall rule processor

Note:Markers must be maintained through

modificationsPlace stubs on tables with potential markers

Marking Example

Define rule FredJoeOn new to emp.salWhere emp.name = “Fred”Then do replace emp (sal=new.sal) where emp.name = “Joe”

Pace marker : on emp tuples with name = “Fred”

Maintain marker : if name modified, then marker is dropped

Place stub on emp table to catch new “Fred’s”

Query Rewriting : Example

Inset modules between parser and query optimizer Query + Rules Set of QueriesExample:On replace to emp.salThen do append to audit (cur.sal, new.sal)+ Replace emp (sal = sal * 1.1 )append to audit (emp.sal, 1.1 * emp.sal)replace emp (sal = sal * 1.1 )

Transactions – Coupling Modes

Specify transaction relationship of when rules execute relative to triggering user actions

Result: Nested Transaction Model

Fore-runner : HIPAC at HP

Transactions – Coupling Modes

Specify transaction relationship between:Event and Condition : E-C Coupling Condition and Action : C-A Coupling

Coupling modes: ImmediateDeferred : at end of transactionSeparate : run as separate transaction

Transactions – Rule Processing

1. Event triggers set of rules R1 to Rn2. For each rule Ri in set, schedule transaction to:

Evaluate condition If true, schedule transaction to execute action

Processing of transaction scheduling based on coupling modes

Notes: Rule-generated operations in 2(a) and (b) may recursively invoke

1/2 Multiple triggered rules yield concurrent transactions Recursive invocations yield trees of nested transactions

Conclusion on Triggers + DBMS

A huge area with challenging Issues, both at semantics and performance level

Potential for many practical usages

Products have only incorporated a small subset of features; there is an SQL standard (SQL99), and yet there is not 100% uniformity

Application of theories and techniques are and will have impact beyond static databases and rule processing