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

Conventional DBMS:Inventory

Product Quantity

x 5DBMS

Sale of 2 items of product x

Available items of product X?

Order 100 items of product x

3

12

3

Cont…

Active DBMS: Active rule A: if quantity <=4 then orders 100 items

Inventory

Active Rule A

Product Quantity

x 5ADBS

Sale of 2 items of product x

Order 100 items of product x 3

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)

Applications

(updates)

Applications

periodic

polling

Passive DBMS

check

reply

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)

Passive DBMS Applications:

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)

Queries andupdates

Active DBMS External Events

Specification of the situations to be monitored

(re) actions

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 An active 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 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;

Condition

Example: Trigger Definition

CREATE TRIGGER Total_sal1

AFTER INSERT ON EmployeeFOR EACH ROW

WHEN (NEW.Dno is NOT NULL)

UPDATE DEPARTMENTSET Total_sal = Total_sal + NEW.

SalaryWHERE Dno = NEW.Dno;

The condition

The action

Can be FOR, AFTER, INSTEAD OF

Can be INSERT, UPDATE, DELETE

Can be CREATE or ALTER

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

An active 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 TriggersPotential 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