24
BB Enhanced Data
ae Models for Advanced
Applications
As the use of database systems has grown, users have demanded acklitional functionaliey
from these sofeware packsges, with ehe purpose of making it easier to implement more
advanced and complex user applications. Object-oriented databases and object-relational
systems do provide features that allow users to extend their systems by specifying addi-
tional abstract daca types for exch application. However, ic is quite useful 0 identify cer-
‘ain common features for some of these advanced applications and eo create models that
‘an represent these common features. In adsicicn, specialized storage structures and
indexing methods can be iroplemented to improve the performance of these common fea
cures. These features can then be implemented as abstract daca type or class libraries and
separately purchased with the basic DBMS software package. The term. datablade has been,
used in Informix and carteidge in Oracle (see Chapter 22) so refer co such optional sub-
modules thae ean be incfuded in a OBMS package. Users can utilize these features ditectly
if they are suitable for their applications, without having to reinvent, reimplement, and
reprogram such common features
This chapter introduces database concepss for some of the coramen features thar are
veeded by advanced applications and that are starting to have widespread wse. The features
‘ve will cover are active rules that ate used in active dotabase applications, empora concepts
that ore wed m temporal database applications, and briefly same af the isaves invalvng
rmulimedia databses. We will abo discuss deductive databases. Ie i important to note chat
cach of these topics is very broad, ane! we can give only a brie introduction to cach ates. In
face, each of these areas can serve as the sole topic for a complete book.
755 756
Chapter 24 Enhanced Data Models for Advanced Applications
In Section 24.1, we will introduce the topic of active databases, which provide
additional functionality for specifying active rules. These mules can be automatically
triggered by events that occur, such as a database updace or a cercain time being reaches,
and can initiate certain actions that have heen specited in the rule declaration ifeeraia
conditions are met. Many commercial packages already have some of the functionality
provided by active databases in the form of triggers. Triggers ate now part of the 321-99
standard
In Section 24.2, we will introduce the concepts of temporal databases, which permit
the dacabase system to store a history of changes, and allow users to query both current
and past states of the database, Some temporal database models also allow users to store
farure expected information, such as planned schedules. I is important fo note that many
database applications ate aiteady temporal, but are ofien implemented without having
much temporal support from the DBMS package—that is, the temporal concepts were
implemented in the application programs that access the database.
Section 24.3 will give a brief overview of spatial and multimedia databases, Spatial
databases provide concepts for databases that keep track of objects in a multidimensional
space. For exarnple, cartographic databases that store maps include two-dimensional
spatial positions of their cbjects, which inchude countries, states rivers, cities, roads, seas,
and s on, Other darahases, such as meteorological darabases for weather informatio, ate
theee-dimensional, since temperatures and other meteorological information are related
tw three-dimeesional spacial points. Multimedia databases. provide features th allow
users to store and query different types of multimedia information, which includes images
(such as pictures or drawings), video clips (such as movies, news reels, or home videos),
audio clips (such as songs, phone messages, or speeches), and documents {such as bocks
or articles).
In Section 24.4, we discuss deductive databases," an area that i atthe intersection
databases, logic, and arrificial intelligence or knowledge bases. A deductive dacabase
system a database system chat includes capabilities tp define (deductive) rules, which
can deduce ot infer adklitional informecion from the facts chat are stored in a dacabase.
Because part of the theoretical foundation for some deductive database systems is
mathematical logic, such rules are often referred 0 as logic databases. Other types of
systems, referred (0 as expert database systems or knowledge-based systems, abo
incorporate reasoning and inferencing capabilities; such systems use techniques thar were
developed in the field of artiicial incelhgence, including semandic networks, frames
production systems, or rules for capturing Jomamn-apocific knowlege.
Readers may choose to peruse the particular topics they are interested in, as the
sections in this chapter are practically independene of one ancthcr
1. Section 244 ipa sammary of Chapter 25 from the third edition. The full chaprer will be avaible
‘onthe book Web site 24.1 Active Database Concepts and Triggers | 757
24.1 ACTIVE DATABASE CONCEPTS AND TRIGGERS
Rales that specify actions shat are automatically triggered by certain events have been
considered as importanc enhancements co a dacabase system for quite some time tn fact,
the concept of triggers—a technique for specifying certain types of active rules—has
existed in eatly vetsions of the SQL specification for relational databases anid criggets ate
now part of the 5-99 standard, Commercial relational BBMSs—such as Oracle, DB2,
‘and SYBASE—have had various versions of triggers available, However, much research
into what a general model for active databases should look like has been done since the
«arly models of triggers were proposed. In Section 24-L.1, we will present the general con-
«cepts thar have been proposed for specifying rules for active databases. We will use the
syntax of the Oracle commercial relational DEMS to illustrate these concep's with specifi:
examples, since Oracle triggers are close co the way cules are specifed in the SQL standacd.
Seetion 24.1.2 will discuss some general design and implementation issues for active data
bases, We chen give examples of how active databases are implemented in the STAR
BURST experimental DBMS in Section 24.1.3, since STARBURST provides for many of the
concepts of generalized active datakases within its framework. Section 24.1.4 discusses
possible applications of active databases. Finally, Section 24.1.5 describes how triggers are
declared in the SQL-99 standatd.
24.1.1 Generalized Model for Active Databases and
Oracle Triggers
The moxie] chat has been used for specifying active database cules is refersed t0 as the
Event-Condition-Action, or ECA model. A rule in the ECA model has three components:
[The event (or events) that criggets the rule: These events are usually database
update opcrations that are explicitly applied to the dacabase. However, in the
general model, chey could also be remporal events? or other kinds of extemal
events.
2. The condition hac determines whether the rule action should be executed: Once
the triggering event has occurred, an optional condition may be evaluated. If no
condition is pecified, the action will be executed once the event occurs. Ifa condi
tion is specified, it is fst evaluated, and only if t evaiuates to me will the rule
aecion be executed
3. The action to be raken: The action is usually a sequence of SQL statements, but it
could also be 2 database transaction of an external program chat will be automat
cally executed,
Let us consider some examples to illustrate these concepts. The examples are based
‘on a much simplified variation of the coaaer dacabase application from Figure 5.7, which
imporal event specified asa periodic ime, suet as: Trigger this rile
2. An example would be a
everyday ar 530 A.M. 758
Chapice 24 Enhanced Data Models for Advanced Applications
ssshown in Figure 24.1, wich each employee having a name (vt), soctel security number
{ss9), salary (se.arr}, department to which chey are currently assigned (own, a foreign key
to oeparTIgnT), ancl a direct supervisor (suremvasor sit, a (recunsive) foreign key to
‘wrlovte), For this example, we assume that null is allowed for ow, indicating that an
employee may be temporarily unassigned to any department. Each department has 2
naine (ase), Sumber {040}, the total salary of all employees assigned 16 the department
(ToraL_sa1), anda manager (mawcen_ss a foreign key 10 Loree).
Notice that che tovaL_sa_ attribute is really a derived atrribure, whose value should be
the sum of the salaries of all employees who are assigned to che particular department.
Maincaining the correct value of such a derived aribuce can be done via an active mle
We first have to determine the events thet may cause 3 change in the value of Toval_sal,
which are a follows:
1. Inserting (one or more) new employee cuples.
2. Changing the salary of (one or more) existing employees
3. Changing the assignment of exicting employees from one department to another.
4, Deleting (one oF more) employce cuples
In the case of event 1, we only need co recompure rorAi sas if che new employee is
immediately ossigned to a deportment—that is if the value of che oxo attribute for the
new employee tuple is net null (assuming null is allowed for ows), Hence, chis would be
the condition to be checked. A similar condition could be checked for event ? (and 4)
determine whether the employee whose salary is changed! (or who is heing deleted} is
currently assigned to a department. For event 3, we will always execute an sction to
tmaintain the value of 7otal_sat correctly, 4 110 condition is needed (the action is always
executed),
The action for events [, 2, and 4 is to automatically update the value of 10a_s for
she employec's department to reflect the newly inserted, updated, o: delesed employee's
salary, In the case of evert 3, a twofold actiot: is needed} one ¢o update the TOTAL_SA of
the employee's old department and the other to update the Tora._sat af the employee’
new department.
‘The four active niles (or triggers) RI, R2, R3, and R4—comresponding to the above
situation—can be specified in the notation of the Oracle DPMS as shown in Figure 24.13
Let us consider rule RU wo illusrate the syacax of ereating tigyers in Oracle. The CREATE
eum ores
uw [ a [ san | owe | soremnson sv |
DEPARTMENT
conawe | ono [Tora SAL
FIGURE 24.1. A simplified cowraw database used for active rule examples. 24.1 Active Database Concepts and Triggers | 759
(a)
CREATE TRIGGER TOTALSALY
AFTER INSERT ON EMPLOYEE
FOREACH ROW
WHEN (NEW.ONOIS NOT NULL)
UPOATE DEPARTMENT
SET TOTAL_SAL®TOTAL_SAL + NEW SALARY
WHERE DNOsNEW.DNO;
RQ: CREATE TRIGGER TOTALSAL?
AFTER UPDATE OF SALARY ON EMPLOYEE
FOR EACH ROW
WHEN (NEW DNOIS NOT NULL)
UPDATE DEPARTMENT
‘SET TOTAL_SAL=TOTAL_SAL + NEW.SALARY - OLD.SALARY
WHERE DNO=NEW.ONO;
3: CREATE TRIGGER TOTALSAL3
AFTER UPDATE OF DNO ON EMPLOYEE
FOREACH ROW
BEGIN
UPDATE DEPARTMENT
SET TOTAL_SAL=TOTAL SAL + NEWSALARY
WHERE DNO=NEW.ONO;
UPDATE DEPARTMENT
SET TOTAL_SAL=TOTAL_SAL— OLD SALARY
WHERE DNO=OLD.DNO:
END;
CREATE TRIGGER TOTALSALA
AFTER DELETE ON EMPLOYEE
FOR EACH ROW
WHEN (OLD.DNO IS NOT NULL}
UPDATE DEPARTMENT
SET TOTAL_SALsTOTAL SAL ~ OLD.SALARY
WHERE DNO=0LD ONO;
®)
RS: CREATE TRIGGER INFORM SUPERVISORY
BEFORE INSERT OR UPDATE OF SALARY, SUPERVISOR_SSN ON EMPLOYEE
FOR EACH ROW
WHEN
(NEW SALARY > (SELECT SAL ARY FROM EMPLOYEE
WHERE SSN=NEW.SUPERVISOR_SSN))
INFORN_SUPERVISOR(NEW. SUPERVISOR_SSN, WEW.SSN};
FIGURE 24.2 Specifying active rules as triggers im Ovacle notation. (a) Triggers for
automatically maintaining the consistericy of Torat_saL of oeparnmenr.(b) Trigger for
comparing an employee's salary with that of his or her supervisor. 760 | Chapter 24 Enhanced Data Models for Advanced Applications
‘TRIGGER statement specifies a crigget (or active rule) name—torasaid for RI, The
AFTEX-clause specifies that che rule will be triggered ofter the events that trigger the rule
‘occur. The triggering events—an insert of a new employce in this example—ore specified
following the AFTER keyword. The ON-clause specifies the relation on which the rule s
specitiec—enP.ovee for RI. The optimal keywords FOR EACH ROW specify chat the rule will
be triggered once for each row that is affected by the triggering event.# The optimal SHEN-
clause is used ta specify any conditions rae need co be checked after the rule is eiggered
hut hefore the action is executed, Finally, the action(s) to be taken are specified as a Pf
SQL block, which typically contains ane or mare SX statements or calls to execute
extemal procedures
“The four ciggers (active rules) RL, R2, R3, and R4 illustrate a number of features of
sctive rules. Fits, the basic events thar can be specified for tiggering the rules ae che
standard SQh update commands: INSERT, PRLETR, and UPDATE. These are specified by the
keywords INSERT, DELETE, and UPDATE in Oracle notation. In the case of UPDATE one
ray specify the attributes to be updated—for example, by writing UPDATE OF Saint,
Second, the tule designer needs to have @ way to refer (0 the tuples that have heen
inserted, deleted, or modified by the triggering event. The keywords NEW and OLD are
used in Oracle notation: NEW is used co refer to a newly inserted or newly updated took,
whereas OLD is used to refer to.a deleted ruple or toa tuple before ie was updated.
“Thus rule 1 is tiggered after an INSERT operation is applied to the eatovee relation.
In Ri, the condition (hew.o40 15 wor NULL) is checked, and if i evaluates to true, meaning
that the newly inserted employee tuple is relared to a department, then the action is
executed, The action updates the veratment cuple(s) relaced to che newly inserted
employee by adkling their salary (yew.sataey) to the Torat_saL atcribute of their related
department
Rule RZ is similar to RU, butt is triggered by an UPDATE operation that updates the
satay of an employee rather chan hy an INSERT. Rule R3 is ciggered by an update tothe
ow attribute of ep.orte, which signifies chenging an employee's assignment from one
department to another: There is no condition to check in R3, so the action is executed
whenever the Ciggering event occurs. The action updates both the old department snd
new department of the reassigned employees by adding their salary co roraL_sat of their
new department ond subtracting their salary from Tora._sat of their old department. Note
that this should work even ifthe value of oo was null, because in this ease no department
will be selected for the rule action *
Ic is important to note the effect of the optional FOR EACH ROW clause, which
signifies thar the rule 4 triggered separately foreach eyple. This is known as 2 row-level
igger If this clause was left out, the trigger would be known asa statement-level trigger
3. As we shall se lares 115 alo possible 1 specify BEIORE fastead of AFTER, which incates that
the rule i wiggered fone che magerng events execute,
4. Again, we shall ee lager that an alteanstve is to wigge the cule andy nce even if mile roms
(euples) ace aflecred by the riggerng event
5.1, R2, and R4 can alo be written without & condition. However, they may ke mere eFicient
execute withthe condition since the sction i ic inked unless i aquired 24.1 Active Database Concepts and! Triggers
and would be triggered once for each triggering starement. To see the difference, consider
the following update operation, which gives 2 10 percenc taise co all employees assigned
co deparment 5. This operation would be an evene thar eriggers rule R2:
Wore EMPLOYEE
ser 1a + say
Because the above statement could update multiple records, a rule using row-level
semantics, such ss R2 in Figure 24.2, would be tiggeted once for each rou, whereas a rule
using statement-level semantics is triggered any once. The Oracle system allows the user to
choose which of the above two options isto be used for each rule. Including the optional
FOR EACH ROW clause creates a row-level nigger, and leaving it out creates a statement-
level trigger. Nore thatthe keywords NEW and OLD can only be used with row-level riggers.
‘Asa second exatnple, suppose we want to check whenever an employee's salary is greater
than the salary of his orher direct supervisor. Several events can trigger this rule: inserting 2
new employee, charging an employee's salary. oF changing an employee's superviso
that the action to take woukl be to call an external procedure rts sirenvrson.® which will
notify the supervisor. The rule coubd then be waitten asin RS (see Figure 24.2b).
Figure 243 shows the syntax for specifying sone of the main uptions avaiable in Oracle
riggers. We will deseribe the syntax for triggers in rhe 21-99 seansdard in Seevion 24.1.5.
24.1.2. Design and Implementation Issues for
Active Databases
The peevious section gave an overview of suine of the main conceprs for specifying active
rules. In this section, we discuss some ackhtional iss concerning how mules are designed
and implemented. The rst issue cortcems accivation, deactivation, and grouping of rules,
-ctigger> = CREATE TRIGGER
(AFTER | BEFORE ) ON
[FOR EACH ROW }
WHEN econditions }
-
