Active Databases. 2 Active Database Systems Ref: Modern Database Systems, Won Kim (ed), Addison Wesley, 1994 (chapter 21). Conventional databases are.

Active Databases

2

Active Database Systems

Ref: Modern Database Systems, Won Kim (ed), Addison Wesley, 1994 (chapter 21).Conventional databases are passiveActive databases Monitor situations of interest Trigger a timely response when the situations occur

E.g., Inventory control systems monitor the quantity in stock. When the stock falls below a threshold, a reordering activity may be initiated

Possible Implementations Check inventory level periodically (not timely) Check the semantics of the condition in every

program that updates the inventory database (poor software engineering approach)

These methods are not general.

3

A General Approach (Active Databases)

Express the derived behavior in rules(conditions ---> actions) The rule can be shared by many application

programs Implementation can be optimized

Contains an inference engine which: Applies all the rules in the system Matches the condition parts of the rules

with the data in the working memory Selects and finds the rule that best matches

the conditions

4

A General Approach (Active Databases)

The action part of the rule may modify the working memory, which may cause further actions. The cycle continues until no more rules match.on eventif conditionthen actionRules can be triggered by the following events: Database operations Occurrence of database status Transitions between database status

5

Characteristics of Rules

Rules are: Defined and stored in the database Evaluated by the database system Subject to:

Authorization Concurrency control Recovery

Rules can be used to: Enforce integrity constraints Implement triggers and actions Maintain derived data Enforce access constraints Implement version control policies Gather statistics for database reorganization

6

Rule Models And Languages

Rules are defined as metadata in the schema together with table, view, and integrity constraints.

Rules operations are provided to: Add Drop Modify

Rules are structured objects with the components of: Events Conditions Action

Special operations of rules are: Fire (triggers a rule) Enable (activates a rule) Disable (deactivates a rule)

7

Triggering an event may be implicit or explicit.

Explicit: flexibility in expressing transactions. e.g., Keep Bob and Alice’s salaries the same.

If Alice’s salary constraint changes, then change Bob’s too. If Bob’s constraint is violated because of changes by the user

transaction, then abort the transaction.

Implicit: any change to the database that can cause the condition to become true is treated as a triggering event.

Languages vary based on the complexity of specified events, conditions, and actions.

8

Event Specification

Explicitly triggered by database modificationRelational database

define rule monitor new eventson insert to employerif...then...where employer is a table of employee information

Object-Oriented Databasedefine rules check raiseson employee salary raisesif...then...where salary raises are a method defined by our objects in anemployee class

9

Rules to be triggered by data retrieval:

define rule monitor sal access

on retrieve salary

from employee

if...

then...

10

Temporal eventsabsolute (8:00 on January 1, 1994)relative (5 seconds after take-off)periodic (17:00 hour every Friday)

In object-oriented databases, events can be: generic database operations (retrieve, insert, delete, update) type-specific operations (method invocation) an operation on rule objects transaction operations external events (messages or signals from devices) a composition of events (disjunction, sequence, and repetition)

Events are defined to have formal parameters.Salary-raise (e: employee, oldsal: integer, newsal: integer)

e of type employee oldsal and newsal of type integer

11

Condition Specification

The condition is satisfied by a predicate or query over data in the database.The condition is satisfied if the predicate is true or if the query returns a non-empty answer.Rule condition are arbitrary predicates over database status, thus modified data can be referenced and transition conditions can be specified.

define rule monitor raiseon update to employee.salaryif employee.salary is > 1.1 old employee.salarythen...

12

Action Specification

Action part of a rule usually performs: inserts deletes updates

Data in the working memory based on data matching the rule’s conditiondefine rule favor employeeor insert to employeethen deletes employee e where e.name = employee.name

Whenever a new employee is inserted, its action deletes any existing employees with the same name.Rule actions can also be: arbitrary database operations transaction operations rule operations signals for the occurrence of user-defined events calls to application procedures

13

Event-Condition-Action BindingDatabase production rule language may have explicitly specific events.There is a need to specify different and varied conditions and actions.The motion of binding is different from Al production rules (e.g. triggering an event of a rule may be parameterized and the parameters may be referenced in the rule’s condition and action.)e.g. If rule is triggered by salary. raise (e: employee; oldsal: integer;newsal: integer),then e in the condition or action refers to the employee object. Oldsal and newsal refer to the intergers bound when events occurred.Composite event allows events (eg. salary raise) to occur one or more times (set of queries)Rules can be triggered by insertions, deletions, and/or updates on a particular table. For example:Create trigger DepDelbefore deletion on departmentwhen department budget<100,000delete employeewhere employee.dno=department.dno

The rule is triggered before the deletion of a department. The condition(where clause) and action refer to the department being deleted.

14

Key words, old and new, can also be used.

define rules form new empson append to employeethen delete employee when employee.name = new.name

define rules Ave Too Bigon update to employee.salaryof (select ave (salary) from new updated) > 100then rollback

Abort the transaction whenever the average of the update exceeds 100.

15

Rule Ordering

Choice of which rule to execute when more than one has been triggered is made: arbitrary numeric priorities partially ordered

For any 2 rules, one rule can be specified as having higher priority than the other rule, but an ordering is not required.

In HiPAC, multiple trigger rules can be executed concurrently.

The rules are relatively ordered for serialization (concurrency control).

16

Rule Organization

In relational systems Rules are defined in the schema Rules refer to particular tables Rules subject to the same controls as other meta data objects (e.g. views, constraints) If a table dropped, all rules defined for it are no longer operative

In HiPAC (object oriented systems) Rules are first class objects Rules are organized in types like other objects Rule types are participants in system hierarchies; they can have attributes in relation to

other objects Rules can be included in collections which can be explicitly named or defined by

queries

r In Flight-rule Where Effective Date (r) After 1/1/90

+ Flight rule is rule type

+ Effective date is an attribute defined for this query

+ Collections of rules can be selectively activated or deactivated

by the enable or disable operation

17

Rule Execution Semantics

Rule behavior can be complex and unpredictable so a precise execution semantics is important

Using an inference engine is not adequate in a database system

Active database system rule processing must integrate with conventional database activities:

Queries Modifications Transactions

which cause the rules to be triggered and initiate rule processing.

Granularity of rule processing Set of tuples

firing the rules after modifying each tuple or firing after modifying all the tuples Set of objects

firing the rule after the end of a transaction

Triggering of more than one rule by the same event Conflict resolution

Nested triggering (termination)

18

Error Recovery

Cause for generating an error during execution of database rule Data has been deleted Data access privileges have been revoked Dead lock is created from concurrently executing transactions System generates error Rule action has uncovered an error condition

Error recovery techniques Delete data and revoke access privilege, invalidating the corresponding

rules Abort the current rule processing if error occurred Propagate the failure to its parent which may initiate other sub-

transactions to repair the error Handle error recovery during system crashes

For recoverable events, their occurrences and parameter bindings have to be reliability logged

For the decoupled conditions and actions, restart uncommitted transactions

19

Implementation Issues

Active databases must provide mechanisms for

Event detection and rule triggering

Condition testing

Rule action execution

User development of rule applications

20

Characteristics Of Representative SystemsARIEL (build using the Exodus database tool kit)

Curey et.al.1991.

A rule manager/rule catalog for handling rule definition and manipulation tasks.

A rule execution monitor for maintaining the set of triggered rules and scheduling their execution.

A rule execution planner to produce optimized execution strategy.

21

POSTGRES

Tuple level processing (run time approach) Places a marker on each tuple for each rule that has a condition matching

that tuple When a tuple is modified or retrieved

If a tuple has one or more marker on it, then the rule or rules associated with the marker(s) are located and their actions are executed.

Marker installed when rules are created Marker deleted when rules are deleted

Query rewrite (compiler time approach) A module is added between command parser and the query processor to

intercept user command Argument with additional commands reflecting the effect of rules (triggering

by the original command) which may trigger other rules Recursively triggering may not terminate

Compiled time approach can be more efficient than runtime approachSelect which mechanism to use when a rule is created

22

STARBURST (IBM Research, Hass et. al. 1990)

Extensibility

Use attachment feature to monitor data modification that are of interest to the rules

Modifications are stored in a transaction log

Rules are processed at the end of a transaction or a user command

Trigger rules are indexed according to the priorities

Reference to transition tables are implemented

Mechanisms are provided for concurrency control, authorization, and crash recovery

23

HiPAC (An Object Oriented Database System), Dayal,U. et al, 1988, SIGMOD Record, Vol. 17, No. 7, pp. 51-70

Rule manager Coordinates rule processing Stores rule objects Implements operations

Implements the coupling modes of the execution model. Concurrency control Recovery for rule object

Event detector detects different eventsBi-directional interaction between application programs and database rule system Application can invoke database operations Rules running inside the database can invoke application

operation

24

Rule Programming Support

Trace rule execution

Display the current set of trigger rules

Query and browse the set of rules

Cross reference rules and data

Activate and deactivate the selected rules for processing the database transactions

25

Rule Termination

Impose sufficient syntactic restrictions on rule definitions (limit the expressiveness of the rules)

Impose a rule triggering limit. The limit is specified by the use or system default (needs to monitor the number of rules executed during the rule processing).

Detect if the same rule is triggered a second time with the same set of parameters

26

Future Directions

Support for application development Application developments treat database rules as an

assembly language Rules are generated automatically from high level

specifications An increase in communication capabilities between

database rules and applications

Increasing expressive power of rules Improved algorithmsDistribution and parallelism Distribution and parallelism Algorithms that guarantee equivalence with centralized

rule processing

27

Mediators In The Architecture Of Future Information Systems

Reference: Gio Wiederhold, IEEE Computer Magazine, March 1992, pp. 38-49.

28

29

30

Abstraction Functions

31

Mismatches in Data Resources

32

Knowledge and Data Feedback Loops and Their Interaction

33

34

Mediators

A mediator is a software module that exploits encoded knowledge about certain sets of subsets of data to create information for a higher layer of applications.

Requirements:small and simpleinspectable by potential users (for selection)meta mediator (e.g., catalog list of mediators and data resource)

Given a data source, locate a knowledgeable mediator; for a desirable mediator, locate an adequate data resource.

35

36

Mediator Interfaces

User’s workstation interface to the mediatorsA language is needed to provide flexibility, composability, iteration, and evaluation in this interface

Descriptive but static interface specification unable to support the variety of control and information flow

The language should provide incremental growth and support new functionality as additional mediator joins the network

Machine and communication friendly interfaces

Support high level functions for decision making

37

Three Layers of a Mediator Architecture

38

Interfaces for Information Flow

39

40

41

42

43

44

45

Interface of Mediator to the Database Management Systems

SQLRDASELECTION and VIEW are good starting points

A mediator combines information from multiple databases, can use its knowledge to control the merging process, specifying relational operations directly.New access languages are needed to manage sensor-based and simulation process (e.g., abstraction, fusion).Mediator can create objects for a wide variety of orthogonal views.Making complex objects persistent.

46

Sharing Of Mediator Modules

Process tasks needed within a mediator:

selection, fusion, reduction, abstraction, and generalization

effective use of mediator modules - sharing use for different applications

e.g., mediator for inflation adjustment can be used by many applications mediator understands postal codes can be used by post offices, express delivery services, and corporate mailrooms.

47

48

Distribution Of Mediators

Locality of maintenanceEconomy for accessAutonomy

Reasons For Mediators Not Attached To DB:

Mediator contains knowledge beyond the scope of DB e.g., factory production control system cannot expect to foresee all

the strategies used of the collected information

Concept of abstraction is not part of DB technology todayIntelligent processing data will involve dealing with uncertaintyMediator may access multiple DB and combine disjoint sets of data prior to analysis and reduction

49

50

51

52

53

54

55

56

Active Infomediation Services

57

Layered Information Architecture & Processes