ACTIVE DATABASES
By,
Radhika Kumaran
09MW13
Passive DBMS Vs Active DBMS
Conventional DBMS are passive: they execute
operations only upon explicit request
Often, however, there is the need of reactive
capabilities: that is the DBMS should
autonomously react to some events and execute
specified operations
We refer to DBMS for which we can specify
active rules, also called triggers as active DBMS
Example
Automated management of a store in
which if the available quantity of a product
goes below 4, 100 items of such product
must be ordered
Inventory
Conventional DBMS:
Product Quantity
3
Order 100 items of DBMS x 5
product x
3
Available items of Sale of 2 items of
2 product X? product x 1
Cont…
Active DBMS:
Active rule A: if quantity <=4 then orders 100 items
Inventory
Product Quantity
ADBS x 5
Order 100 items of
product x 3
Active Rule
A
Sale of 2 items of
product x
Applications Of Active Databases
The following are the common application:
integrity constraints
alerting
auditing
security
statistics
views
Approaches to implement applications
requiring automatic execution of actions
There are three main approaches to
implement the concept in question
Passive approach (two application
method)
Passive approach (one application
method)
Active approach
Architectural approaches
Approach 1 :Passive DBMS: (two types of
application)
check
Applications Applications
(updates) Passive DBMS periodic
reply
polling
Problem: to determine the optimal polling frequency
●
Too frequent: inefficiency
●
Too seldom: situations requiring a reaction may be “lost”
Architectural approaches
Passive DBMS: approach 2 (only one type of
application)
Applications:
Passive DBMS Code for modifying the
database
+
Monitoring code
●
Problem:
●
It compromises code modularity and re-usability
●
If the monitored condition changes, the application has to
be changed
Architectural approaches
Active DBMS (integrated approach)
Specification of the situations
to be monitored
Queries and
(re) actions updates
Active DBMS
External Events
Active databases
An active database is a database in
which some operations are automatically
executed once a given situation arises
The situation may correspond to the fact
that:
Some specified events arise, or
Specific conditions or state transitions are
detected
Anactive rule (trigger) is a language
construct for defining the system
reactions
Specification of active rules
the ECA paradigm
The most common form of triggers is thus:
ON event IF condition THEN action
1. If the event arises, the condition is evaluated
2. if the condition is satisfied, the action is
executed
The active rule paradigm originates from the
notion of production rules of Artificial Intelligence
Production rules do not typically have events;
they have the form (CA):
IF condition THEN action
Event-Condition-Action (ECA) Model
Triggers follow an Event-condition-action (ECA)
model
Event:
Database modification
• E.g., insert, delete, update),
Condition:
Any true/false expression
• Optional: If no condition is specified then condition is always
true
Action:
Sequence of SQL statements that will be
automatically executed
Trigger Example
When a new employees is added to a department, modify
the Total_sal of the Department to include the new
employees salary
Logically this means that we will CREATE a TRIGGER, let us call the
Condition
trigger Total_sal1
This trigger will execute AFTER INSERT ON Employee
table
It will do the following FOR EACH ROW
• WHEN NEW.Dno is NOT NULL
• The trigger will UPDATE DEPARTMENT
• By SETting the new Total_sal to be the sum of
old Total_sal and NEW. Salary
WHERE the Dno matches the NEW.Dno;
Example: Trigger Definition
CREATE TRIGGER Total_sal1 Can be CREATE or
ALTER
Can be FOR,
AFTER, INSTEAD
AFTER INSERT ON Employee OF
FOR EACH ROW Can be INSERT,
UPDATE, DELETE
WHEN (NEW.Dno is NOT NULL) The condition
UPDATE DEPARTMENT
SET Total_sal = Total_sal + NEW. Salary
The
WHERE Dno = NEW.Dno; action
Condition
Any true/false condition to control whether a
trigger is activated on not
Absence of condition means that the trigger will
always execute for the even
Otherwise, condition is evaluated
before the event for BEFORE trigger
after the event for AFTER trigger
Row-Level versus Statement-level
Generalized Model (contd.)
Triggers can be
Row-level
FOR EACH ROW specifies a row-level trigger
Statement-level
Default (when FOR EACH ROW is not specified)
Row level triggers
Executed separately for each affected row
Statement-level triggers
Execute once for the SQL statement,
Action
Action can be
One SQL statement
A sequence of SQL statements enclosed
between a BEGIN and an END
Action specifies the relevant modifications
Active Database Concepts and
Triggers
Anactive database allows users to make
the following changes to triggers (rules)
Activate
Deactivate
Drop
Events
An event can be considered in 3 ways
Immediate consideration
Deferred consideration
Detached consideration
Types of Events
Immediate consideration
Part of the same transaction and can be one of the
following depending on the situation
Before
After
Instead of
Deferred consideration
Condition is evaluated at the end of the transaction
Detached consideration
Condition is evaluated in a separate transaction
Active Database Concepts and
Triggers
Potential Applications for Active Databases
Notification
Automatic notification when certain condition occurs
Enforcing integrity constraints
Triggers are smarter and more powerful than constraints
Maintenance of derived data
Automatically update derived data and avoid anomalies
due to redundancy
• E.g., trigger to update the Total_sal in the earlier example
Thank you
