Active Database

Basis Data II
Active Database
• Conventional database management systems are passive.
• Commands are executed by the database (query, update, delete, insert) and
and when requested by the user or application program
• It has passive update principle. That is, client controls DBMS updates. •
• However, some situations cannot be effectively modeled by this
pattern.
Problem with Traditional Database Systems:
• Example:
• Consider a railway database where data are stored about trains,
timetables, seats, fares, and so on, which is accessed by different
terminals.
• In some circumstances (e.g., public holidays, cultural events) it may
be beneficial to add additional coaches to specific trains if the
number of spare seats a month in advance is below a threshold value.
• How to administer this situation in the passive database?
Resolution to the Situation
• Two options are possible:
• Add the additional monitoring functionality to all booking programs
so that the preceding situation is checked each time a seat is sold.
• However, this approach leads to the semantics of the monitoring task
being distributed, replicated, and hidden among different application
programs
Other Examples
• Some more examples of real world problem not well suited for
passive update principle:
• Inventory control - reordering items when quantity in stock falls below
threshold.
• Travel waiting list - book ticket as soon as right kind is available
• Stock market - Buy/sell stocks when price below/above threshold
Active Database
• An Active Database Management System means:
• Allows users to specify actions to be taken automatically, without user
intervention, when certain conditions arise.
• Allowing the specification and implementation of reactive behaviour
• ADBMS extend “passive” DBMS with the possibility to specify reactive
behaviour
Active Databases
• General Idea:
• Active DBMS provides: Regular DBMS primitives + definition of application-
defined situations + triggering of application-defined reactions
• It means: ‣ being able to react automatically to situations in the database ‣
allowing the specification and implementation of reactive behavior
• Active DBMSs
• Embed situation-action rules in database
• Support many functionalities: E.g. Integrity control, derived data, change
notification
• Active DBMS functionality commercially available in SQL:99 as triggers
Active Databases
• Recognize predefined situations in database
• Trigger predefined actions when situations occur
• Actions are usually database updates
• Active Rules – rules that are automatically triggered by events in the
database.
Triggers
• Triggers is a concept that is technique for specifying certain types of
active rules in the database.
• A data base that has a set of associated triggers is called an active
data base.
• Trigger is like a procedure that is automatically invoked by the DBMS
in response to specified changes to data base.
• Trigger is like a ‘Daemon that monitors a data base, and is executed
when the data base is modified in a way that matches the event
specification
Event-Condition-Action (ECA)
• Event(s) that triggers the rule
• update operations (adding new rows, deleting rows)
• temporal events
• Condition that determines whether the rule action should be
executed
• SQL condition
• Action to be taken
• SQL + procedures
• All data actions performed by the trigger execute within the same transaction
in which the trigger fires
Event
• An event is something that happens at a point in time
• Possible alternatives:
• Structure operations (insert, update, access)
• Behavior invocation (the message display is sent to an object of type widget)
• Transaction (abort, commit, begin-transaction)
• Abstract or user-defined (response to some information entered by user)
• Exception (an attempt to access some data without appropriate
authorization)
• Clock (the first day of very month)
• External (the temperature reading goes above 30 degrees)
Event Granularity
• Indicates whether an event is defined:
• For every object in a set (e.g. every instance of a class)
• For given subset (e.g., all staff members except professors)
• For specific members of the set (e.g. to prevent unauthorized access to
specific instances)
Condition
• The condition indicates whether rule action should be executed.
• In ECA-rules, the condition is generally optional.
• Once the triggering event has occurred , the condition may be
evaluated. If condition evaluates to be true, the rule action will be
executed.
• If no condition is specified, the action will be executed once the event
occurs.
Action
• The range of tasks that can be performed if the rule condition is
evaluated to be true.
• It is usually a sequence of SQL statements.
• But actions may:
• perform some behavior invocation within the database or an external call,
• inform the user or system administrator of some situation,
• abort a transaction,
• take some alternative course of action using do-instead
Syntax
<trigger> ::= CREATE TRIGGER <trigger name>
( AFTER I BEFORE ) <triggering events> ON <table name>
[ FOR EACH ROW ]
[ WHEN <condition> ]
<trigger actions> ;
<triggering events> ::= <trigger event> {OR <trigger event> }
<trigger event> ::= INSERT I DELETE I UPDATE [ OF <column name> { , <column
name> } ]
<trigger action> ::= <PL/SQL block>
• We assume that NULL is allowed for Dno in table EMPLOYEE
• Total_sal attribute is sum of the salaries of all employees who are assigned
to the particular department
• Events that may cause a change in the value of Total_sal, which are as
follows:
1. Inserting (one or more) new employee tuples
2. Changing the salary of (one or more) existing employees
3. Changing the assignment of existing employees from one department to another
4. Deleting (one or more) employee tuples
 Event 1: Inserting (one or more) new
employee tuples
• recompute Total_sal if the new employee is immediately assigned to a
department.
• if the value of the Dno attribute for the new employee tuple is not NULL,
this is the condition to be checked
• update the value of total_sal, this is the action

R1: CREATE TRIGGER Total_sal1

AFTER INSERT ON EMPLOYEE
FOR EACH ROW
WHEN ( NEW.Dno IS NOT NULL )
UPDATE DEPARTMENT
SET Total_sal = Total_sal + NEW.Salary
WHERE Dno = NEW.Dno;
 Event 2: Changing the salary of existing
employees
• recompute Total_sal if the employee’s salary is changed
• if the value of the Dno attribute for the employee whose salary is
changed is not NULL, this is the condition to be checked
• update the value of total_sal, this is the action

R1: CREATE TRIGGER Total_sal2

AFTER UPDATE OF Salary ON EMPLOYEE
FOR EACH ROW
WHEN ( NEW.Dno IS NOT NULL )
UPDATE DEPARTMENT
SET Total_sal = Total_sal + NEW.Salary – OLD.Salary
WHERE Dno = NEW.Dno;
 Even 3: Changing the assignment of existing
employees from one department to another
• Execute an action to maintain the R3: CREATE TRIGGER Total_sal3
value of Total_sal correctly AFTER UPDATE OF Dno ON EMPLOYEE
• a twofold action is needed: one to FOR EACH ROW
update the Total_sal of the BEGIN
employee’s old department and the UPDATE DEPARTMENT
other to update the Total_sal of the SET Total_sal = Total_sal + NEW.Salary
employee’s new department. WHERE Dno = NEW.Dno;
• no condition is needed UPDATE DEPARTMENT
SET Total_sal = Total_sal – OLD.Salary
WHERE Dno = OLD.Dno;
END;
 Event 4: Deleting (one or more) employee
tuples
• recompute Total_sal if the employee’s salary is changed
• if the value of the Dno attribute for the employee whose salary is changed
is not NULL, this is the condition to be checked
• update the value of total_sal, this is the action

R4: CREATE TRIGGER Total_sal4

AFTER DELETE ON EMPLOYEE
FOR EACH ROW
WHEN ( OLD.Dno IS NOT NULL)
UPDATE DEPARTMENT
SET Total_sal = Total_sal – OLD.Salary
WHERE Dno = OLD.Dno;
Trigger vs Constraint
• A common use of triggers is to maintain database consistency
• Will using integrity constraint achieve the same goals?
• A constraint also prevents the data from being made inconsistent by
any kind of statement,
• whereas a trigger is activated by a specific kind of statement (e.g., an
insert or delete statement)
Example:
• Suppose that we have a table called Orders with fields itemid,
quantity, customerid, and unitprice.
• When a customer places an order, the first three field values are filled
in by the user (in this example, a sales clerk). The fourth field's value
can be obtained from a table called Items.
• We can define a trigger to look up this value and include it in the
fourth field of a newly inserted record.
• In addition to reducing the number of fields that the clerk has to type
in, this trigger eliminates the possibility of an entry error leading to an
inconsistent price in the Orders table
Example
• The purchase is being charged to a credit line issued by the company,
we may want to check whether the total cost of the purchase is
within the current credit limit.
• We can use a trigger to do the check.
Features of Active Database:
• It possess all the concepts of a conventional database i.e. data
modelling facilities, query language etc.
• It supports all the functions of a traditional database like data
definition, data manipulation, storage management etc.
• It supports definition and management of ECA rules.
• It detects event occurrence.
• It must be able to evaluate conditions and to execute actions.
• It means that it has to implement rule execution.
Issues in Designing Active Databases
• Activation, deactivation, and grouping of rules
• A deactivated rule will not be triggered by the triggering event.
• The activate command will make the rule active again
• The drop command deletes the rule from the system
• To group rules into named rule sets, so the whole set of rules can be
activated, deactivated, or dropped
• The triggered action should be execution before, after, instead of, or
concurrently with the triggering event
Advantages
• Enhances traditional database functionalities with powerful rule
processing capabilities.
• Enable a uniform and centralized description of the business rules
relevant to the information system.
• Avoids redundancy of checking and repair operations.
• Suitable platform for building large and efficient knowledge base and
expert systems.
Potential Applications for Active Databases
• To allow notification
• To enforce integrity constraints
• Business role
• Automatic maintenance of derived data