Active Database Systems

Introduction and motivation. Traditionally, the database management system (DBMS) has been viewed as a passive repository of large quantities of data that are of interest for a particular application, which can be accessed/retrieved in an efficient manner.

The typical commands for insertion of data records, deletion of existing ones, and updating of the particular attribute values for a selected set of items are executed by the DBMS upon the user’s request and are specified via a proper interface or by an application program.

Basic units of changes in the DBMS are the transactions, which correspond to executions of user programs/requests, and are perceived as a sequence of reads and/or writes to the database objects, which either commit successfully in their entirety or abort. One of the main benefits of the DBMS is the ability to optimize the processing of various queries while ensuring the consistency of the database and enabling a concurrent processing of multiple users transactions.

However, many applications that require management of large data volumes also have some behavioral aspects as part of their problem domain which, in turn, may require an ability to react to particular stimuli. Traditional exemplary settings, which were used as motivational scenarios for the early research works on this type of behavior in the DBMS, were focusing on monitoring and enforcing the integrity constraints in databases.

Subsequently, it was recognized that this functionality is useful for a wider range of applications of DBMS. For example, a database that manages business portfolios may need to react to updates from a particular stock market to purchase or sell particular stocks, a database that stores users preferences/profiles may need to react to a location-update detected by some type of a sensor to deliver the right information content to a user that is in the proximity of a location of interest (e.g., deliver e-coupons when within 1 mile from a particular store).

An active database system (ADBS) extends the traditional database with the capability to react to various events, which can be either internal—generated by the DBMS (e.g., an insertion of a new tuple as part of a given transaction), or external—generated by an outside DBMS source (e.g., a RFID-like location sensor).

Originally, the research to develop the reactive capabilities of the active databases was motivated by problems related to the maintenance of various declarative constraints (views, integrity constraints). However, with the evolution of the DBMS technologies, novel application domains for data management, such as data streams, continuous queries processing, sensor data management, location-based services, and event notification systems (ENS), have emerged, in which the efficient management of the reactive behavior is a paramount.

The typical executional paradigm adopted by the ADBS is the so-called event-condition-action (ECA) which describes the behavior of the form:

The basic tools to specify this type of behavior in commercially available DBMS are triggers—statements that the database automatically executes upon certain modifications. The event commonly specifies the occurrence of (an instance of) a phenomenon of interest.

The condition, on the other hand, is a query posed to the database. Observe that both the detection of the event and the evaluation of the condition may require access not only to the current instance of the database but also to its history.

The action part of the trigger specifies the activities that the DBMS needs to execute—either a (sequence of) SQL statement(s) or stored procedure calls. As a motivational example to illustrate the ECA paradigm, consider a scenario in which a particular enterprise would like to enforce the constraint that the average salary is maintained below 65K.

The undesired modifications to the average salary value can occur upon: (1) an insertion of a new employee with aboveaverage salary, (2) an update that increases the salaries of a set of employees, and (3) a deletion of employees with below- average salary.

Hence, one may set up triggers that will react to these types of modifications (event) and, when necessary (condition satisfied), will perform corrective actions. In particular, let us assume that we have a relation whose schema is Employee(Name, ID, Department, JobTitle, Salary) and that, if an insertion of a new employee causes the average salary-cap to be exceeded, then the corrective action is to decrease everyone’s salary by 5%.

The specification of the respective trigger in a typical DBMS, using syntax similar to the one proposed by the SQL-standard, would be:

This seemingly straightforward paradigm has generated a large body of research, both academic and industrial, which resulted in several prototype systems as well as its acceptance as a part of the SQL99 standard that, in turn, has made triggers part of the commercially available DBMS. In the rest of this article, we will present some of the important aspects of the management of reactive behavior in ADBS and discuss their distinct features. In particular, in the section on formalizing and reasoning, we motivate the need to formalize the active database behavior.

In the section on semantic dimensions, we discuss the various parameters and the impact of the choice of their possible values, as they have been identified in the literature. In the overview section we present the main features of some prototype ADBS briefly, along with the discussion of some commercially available DBMS that provide the triggers capability.

Finally, in the last section, we outline some of the current research trends related to the reactive behavior in novel application domains for data management, such as workflows, data streams, moving objects databases, and sensor networks.