Your SlideShare is downloading. ×
CS 240A: Databases and Knowledge Bases
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

CS 240A: Databases and Knowledge Bases

276
views

Published on


0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
276
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
2
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. CS 240A: Databases and Knowledge Bases Introduction to Active Databases Carlo Zaniolo Department of Computer Science University of California, Los Angeles Last revision: January 2002 Notes From Chapter 2 of Advanced Database Systems by Zaniolo, Ceri, Faloutsos, Snodgrass, Subrahmanian and Zicari Morgan Kaufmann, 1997
  • 2. Active Database Systems
    • An integrated facility for creating and executing production rules from within a database system.
    • A typical database production rule:
      • when event
      • if condition
      • then action
  • 3. Active Database Systems (Cont’)
    • Powerful and uniform mechanism for:
    • - Constraint enforcement
    • - Derived data maintenance
    • - Alerting
    • - Authorization checking
    • - Version management
    • - Resource management
    • - Knowledge management
  • 4. Outline of Slides
    • Chapter 2: Syntax and Semantics
    • - A Relational Prototype: Starburst
    • - Two Relational Systems: Oracle and DB2
    • - Features and Products Overview
  • 5. Outline of Slides (Cont’)
    • Chapter 3: Applications
    • - Applications of Active Rules
    • - Deriving Active Rules for Constraint Management
    • - Deriving Active Rules for View Maintenance
    • - Rules for Replication
    • - Rules for Workflow Management
    • - Business Rules
    • View Maintenance: from deductive rules to active ones
  • 6. Outline of Slides (Cont’)
    • Chapter 4: Design Principles
    • - Properties of Active Rules and Rule Analysis
    • - Rule Modularization
    • - Rule Debugging and Monitoring
    • - Rule Design: IDEA Methodology (pointer)
    • - Conclusion
  • 7. Chapter 2: A Relational Example: Starburst
    • Designed and built at IBM Almaden
    • Chief Engineer: Jennifer Widom
    • Syntax based on SQL
    • Semantics is set-oriented
    • - Triggering based on (arbitrary) sets of changes
    • - Actions perform (arbitrary) sets of changes
    • - Conditions and actions can refer to sets of
    • changes
    • Instructions: create, drop, alter , deactivate,
    • activate
  • 8. Rule Creation
    • <Starburst-rule> ::= CREATE RULE <rule-name>
    • ON <table-name>
    • WHEN <triggering-operations>
    • [ IF <SQL-predicate> ]
    • THEN SQL-statements
    • [ PRECEDES < rule-names >]
    • [ FOLLOWS < rule-names> ]
    • <triggering-operation> := INSERTED | DELETED |
    • UPDATED [( column-names>) ]
  • 9. Rule Creation (Cont’)
    • Triggering operations:
    • - inserted , deleted , updated , updated ( c 1 ,.., c n )
    • Condition: arbitrary SQL predicate
    • Actions: any database operations
    • insert , delete , update , select ,
    • rollback , create table , etc.
    • Precedes and Follows: for rule ordering
  • 10. Example Rules
    • Salary control rule:
    • CREATE RULE SalaryControl ON Emp
    • WHEN INSERTED, DELETED, UPDATED(Sal)
    • IF (SELECT AVG (Sal) FROM Emp ) > 100
    • THEN UPDATE Emp
    • SET Sal = 0.9 * Sal
  • 11. Example Rules (Cont’)
    • High paid rule:
    • CREATE RULE HighPaid ON Emp
    • WHEN INSERTED
    • IF EXISTS (SELECT * FROM INSERTED
    • WHERE Sal 100)
    • THEN INSERT INTO HighPaidEmp
    • (SELECT * FROM INSERTED
    • WHERE Sal 100)
    • FOLLOWS SalaryControl
    • ____________________________________
    • Errata: ADS book has “FOLLOWS AvgSal”
  • 12. Transition Tables
    • Logical tables storing changes that triggered rule
    • Can appear anywhere in condition and action
    • References restricted to triggering operations:
      • inserted
      • deleted
      • new-updated
      • old-updated
  • 13. Rule Execution Semantics (1)
    • Rules processed at commit point of each transaction
    • Transaction's changes are initial triggering transition
    • Rules create additional transitions which may trigger other rules or themselves
    • Each rule looks at set of changes since last considered
    • When multiple rules triggered, pick one based on partial ordering
  • 14. Example of Rule Execution
    • Initial state:
    90 90 110 Stefano Patrick Michael Sal Employee
  • 15. Example of Rule Execution (Cont’)
    • Transaction inserts tuples: (Rick, 150) and (John, 120)
    90 90 110 150 120 Stefano Patrick Michael Rick John Sal Employee 90 90 110 Stefano Patrick Michael Sal Employee
  • 16. Example of Rule Execution (Cont’)
    • Rule SalaryControl runs:
    81 81 99 135 108 Stefano Patrick Michael Rick John Sal Employee 90 90 110 150 120 Stefano Patrick Michael Rick John Sal Employee
  • 17. Rule Execution Semantics (2)
    • Rule SalaryControl runs again:
    73 73 89 121 97 Stefano Patrick Michael Rick John Sal Employee 81 81 99 135 108 Stefano Patrick Michael Rick John Sal Employee
  • 18. Rule Execution Semantics (2) (Cont’)
    • Rule Rule HighPaid runs eventually, and inserts into HighPaid only one tuple:
    122 Rick Sal Employee
  • 19. Oracle
    • Supports general-purpose triggers, developed according to preliminary documents on the SQL3 standard
    • Actions contain arbitrary PL/SQL code
    • Two granularities: row-level and statement-level
    • Two types of immediate consideration: BEFORE and AFTER
    • Therefore: 4 Combinations: BEFORE ROW
    • BEFORE STATEMENT
    • AFTER ROW
    • AFTER STATEMENT
  • 20. Syntax
    • <Oracle-trigger> ::= CREATE TRIGGER <trigger-name>
    • { BEFORE | AFTER } <trigger-events>
    • ON <table-name>
    • [[ REFERENCING <references> ]
    • FOR EACH ROW
    • [ WHEN ( <condition> ) ]] <PL/SQL block>
    • <trigger event> ::= INSERT | DELETE | UPDATE
    • [ OF < column-names > ]
    • <reference> ::= OLD AS < old-value-tuple-name> |
    • NEW AS < new-value-tuple-name>
  • 21. Trigger Processing
    • 1. Execute the BEFORE STATEMENT trigger.
    • 2. For each row affected:
    • (a) Execute the BEFORE ROW trigger.
    • (b) Lock and change the row.
    • (c) Perform row-level referential integrity and
    • assertion checking.
    • (d) Execute the AFTER ROW trigger.
    • 3. Perform statement-level referential integrity and
    • assertion checking.
    • 4. Execute the AFTER STATEMENT trigger.
  • 22. Example Trigger in Oracle: Reorder Rule
    • CREATE TRIGGER Reorder
    • AFTER UPDATE OF PartOnHand ON Inventory
    • WHEN (New.PartOnHand < New.ReorderPoint)
    • FOR EACH ROW
    • DECLARE NUMBER X
    • BEGIN SELECT COUNT(*) INTO X
    • FROM PendingOrders
    • WHERE Part = New.Part;
    • IF X=0
    • THEN
    • INSERT INTO PendingOrders
    • VALUES (New.Part, New.OrderQuantity, SYSDATE)
    • END IF;
    • END;
  • 23. Example of execution
    • Initial state of Inventory:
    • PendingOrders is initially empty
    • Transaction(executed on October 10, 1996):
    • T 1 : UPDATE Inventory
    • SET PartOnHand = PartOnHand - 70
    • WHERE Part = 1
    100 200 120 150 500 400 200 780 450 1 2 3 ReorderQuantity ReorderPoint PartOnHand Part
  • 24. Example of execution (Cont’)
    • After the execution of trigger Reorder, insertion into PendingOrders of the tuple (1,100,1996-10-10)
    • Another transaction (executed on the same day)
    • T 2 : UPDATE Inventory
    • SET PartOnHand = PartOnHand - 60
    • WHERE Part >= 1
    • The trigger is executed upon all the tuples, and the WHEN
    • condition holds for parts 1 and 3. But the X=0 condition only holds for part 3, for which a reorder is issued , resulting in the new tuple (3,120,1996-10-10).
  • 25. DB2
    • Triggers for DB2 Common Servers defined at the IBM Almaden Research center in 1996.
    • Influential on the SQL3 standard.
    • As in Oracle: either BEFORE or AFTER their event, and either a row- or a statement-level granularity.
  • 26. DB2 : Syntax
    • <DB2-trigger> :: = CREATE TRIGGER <trigger-name>
    • {BEFORE | AFTER} <trigger-event>
    • ON <table-name>
    • [ REFERENCING <references> ]
    • FOR EACH {ROW | STATEMENT}
    • WHEN ( <SQL-condition> )
    • <SQL-procedure-statements>
    • <trigger-event> :: = INSERT | DELETE | UPDATE
    • [ ON <column-names> ]
    • <reference> :: = OLD AS <old-value-tuple-name> |
    • NEW AS new-value-tuple-name |
    • OLDTABLE AS old-value-table-name |
    • NEWTABLE AS new-value-table-name
  • 27. Semantics of DB2 Triggers
    • Before-triggers :
      • Used to detect error conditions and to condition input values (assign values to NEW transition variables).
      • Read the database state prior to any modification made by the event
      • Cannot modify the database by using UPDATE, DELETE, and INSERT statements (so they do not activate other triggers)
    • Several triggers (with either row- or statement-level granularity) can monitor the same event.
    • A system-determined total order takes into account the triggers’ definition time; row- and statement-level triggers are intertwined in the total order.
  • 28. Semantics of DB2 Triggers (Cont’)
    • General trigger processing algorithm after statement A :
    • 1. Suspend the execution of A, and save its working storage on a stack.
    • 2. Compute transition values (OLD and NEW) relative to
    • event .
    • 3. Consider and execute all before-triggers relative to event E, possibly changing the NEW transition values.
    • 4. Apply NEW transition values to the database, thus making the state change associated to event E effective.
    • 5. Consider and execute all after-triggers relative to event E.
    • If any of them contains an action A I that activates other triggers, then invoke this processing procedure recursively for A I .
    • 6. Pop from the stack the working storage for A and continue its evaluation.
  • 29. Semantics of DB2 Triggers (Cont’)
    • Revised trigger processing with integrity checking :
    • Apply the NEW transition values to the database, thus making
    • the state change associated to event E effective. For each
    • integrity constraint IC violated by the current state change, let
    • A j be the compensating action (if any) specified with IC, then
    • [a.] Compute the transition values (OLD and NEW) relative to A j .
    • [b.] Execute the before-triggers relative to A j , , possibly changing
    • the NEW transition values.
    • [c.] Apply NEW transition values to the database, thus making the
    • state change associated to A j effective.
    • [d.] Push all after-triggers relative to action into a queue of
    • suspended triggers.
    • Until a quiescent point is reached where all the integrity constraints
    • violated in the course of the computation are compensated.
  • 30. Examples of triggers
    • Supplier rule:
    • CREATE TRIGGER OneSupplier
    • BEFORE UPDATE OF Supplier ON Part
    • REFERENCING NEW AS N
    • FOR EACH ROW
    • WHEN (N.Supplier IS NULL)
    • SIGNAL SQLSTATE
    • '70005'
    • ('Cannot change supplier
    • to NULL')
    • Audit rule:
    • CREATE TRIGGER Audit
    • AFTER UPDATE ON Part
    • REFERENCING OLDTABLE
    • AS OT
    • FOR EACH STATEMENT
    • INSERT INTO AuditSupplier VALUES(USER, CURRENTDATE, (SELECT COUNT(*) FROM OT))
  • 31. Example (cont.) Say that the default value is HDD … FOREIGN KEY (Supplier) REFERENCES Distributor ON DELETE SET DEFAULT
    • SIGNAL: rolls back the effect of a statement, while letting the transaction proceed.
    • SIGNAL and SET are often used with before triggers.
    Part 400 HDD 3 800 Jones 4 500 Taylor 2 150 Jones 1 Cost Supplier PartNo Distributor GE Atlanta HDD NJ Newark Taylor CA Palo Alto Jones State City Supplier
  • 32. Execution
    • Event: DELETE FROM Distributor WHERE State =`CA’
    • No rule is specified for this event, but the FK constraint updates Jones with HDD in the first and last tuple of Part the OLD and NEW tables for Part are set accordingly.
    • The before rule is evaluated on the updates of point 2, but it is not fired since the WHEN condition fails.
    • The updates of point 2 are written onto the actual table Distributor (well, the in-memory copy, that will be then written to disk at transaction commit time).
    • It is now the turn of the after rules. The AuditSupplier rule is triggered, which adds to the Audit table the tuple: (Bill, 1996-10-10, 2)
  • 33. Question
    • What happens if we change the FK corrective action to:
    • FOREIGN KEY (Supplier)
    • REFERENCES Distributor
    • ON DELETE SET NULL