View
225
Download
0
Category
Tags:
Preview:
Citation preview
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
Recommended