Elmasri/Navathe, Fundamentals of Database Systems, 4th Edition

Chapter 24
Enhanced
Data Models
For
Advanced
Applications
Elmasri/Navathe, Fundamentals of Database Systems, 4th Edition
 Chapter Outline
Active Databases and Triggers

Temporal Database Concepts

Multimedia Databases

Introduction to Deductive Databases

Elmasri/Navathe, Fundamentals of Database Systems, 4th Edition

Active Databases and Triggers
Triggers is a technique for specifying certain
types of active rules.

The Event-Condition-Action (ECA) is a model

for specifying active database rules. A rule in ECA
model has three components:
The event would be a database update operations,
temporal events, or other kinds of external events.

The condition determines whether the rule action

should be executed.

The action is a sequence of SQL statements,

transactions, or an external program that will be
automatically executed.
Elmasri/Navathe, Fundamentals of Database Systems, 4th Edition
Active Databases and Triggers
Example: Consider a simplified version of
the Company database

In this version, the TOTAL_SAL attribute is a

derived attribute, whose value should be the sum
of the salaries of all employees who are assigned
to the particular department.
Elmasri/Navathe, Fundamentals of Database Systems, 4th Edition
Active Databases and Triggers
Maintaining the correct value for TOTAL_SAL can
be done via an active rule. The events that may
cause a change in the value of TOTAL_SAL are:

1) Inserting new employee tuples.

3) Changing the salary of existing employees.

5) Changing the assignment of existing employees from

one department to another.

7) Deleting (one or more) employee tuples.

Elmasri/Navathe, Fundamentals of Database Systems, 4th Edition

 Active Databases and Triggers
FIGURE 24.2
Specifying active
rules as triggers
in Oracle notation.
(e) Triggers for
automatically
maintaining the
consistency of
TOTAL_SAL of
DEPARTMENT.

Elmasri/Navathe, Fundamentals of Database Systems, 4th Edition

 Active Databases and Triggers
FIGURE 24.2 (continued)
Specifying active rules as triggers in Oracle notation.
(b) Trigger for comparing an employee’s salary with that of his or
her supervisor.

Elmasri/Navathe, Fundamentals of Database Systems, 4th Edition

Active Databases and Triggers
The optional FOR EACH ROW clause is known as
a row-level trigger (i.e., the rule is triggered
separately for each tuple).

If FOR EACH ROW clause was left out, the trigger

would be known as a statement-level trigger
(i.e., the rule would be triggered once for each
triggering statement).

The keywords NEW and OLD can only be used

with row-level triggers.

Elmasri/Navathe, Fundamentals of Database Systems, 4th Edition

 Active Databases and Triggers
FIGURE 24.3
A syntax summary for specifying triggers in the Oracle system
(main options only).

Elmasri/Navathe, Fundamentals of Database Systems, 4th Edition

Design Issues for Active Databases
The first issue concerns, activation,
deactivation, and grouping of rules.
The activate command will make the rule active again.

The deactivate command will make the trigger event

not be triggered.

The delete command deletes the rule from the system.

The rule set option can be used to group rules (so, the
whole set of rules can be activated, deactivated, or
dropped).

The PROCESS RULES command can triggers a rule or

rule set.
Elmasri/Navathe, Fundamentals of Database Systems, 4th Edition
Design Issues for Active Databases
The second issue concerns whether the triggered
action should be executed before, after, or
concurrently with the trigger event.

A related issue is whether the action being

executed should be considered as a separate
action or whether it should be part of the
same transaction that triggered the rule.

The rule condition evaluation is also known as

rule consideration.

Elmasri/Navathe, Fundamentals of Database Systems, 4th Edition

Design Issues for Active Databases
Three main possibilities for rule consideration:

Immediate consideration: the condition is evaluated

as part of the same transaction as the trigger event,
and is evaluated immediately; in one of the following
forms
– Before executing the trigger event.
– After executing the trigger event.
– Instead of executing the trigger event.

Deferred consideration: the condition is evaluated at

the end of transaction that include the trigger event.

Detached consideration: the condition is evaluated

as a separate transaction.

Elmasri/Navathe, Fundamentals of Database Systems, 4th Edition

Design Issues for Active Databases
Difficulties with using active rules:
To verify that a set of rules is consistent.
To guarantee termination of a set of rules under all
circumstances.

FIGURE 24.4
An example to illustrate the termination problem for active rules.

Elmasri/Navathe, Fundamentals of Database Systems, 4th Edition

Potential applications for Active Databases
To allow notification of certain conditions that
occur (e.g., to monitor the temperature of an
industrial furnace).

To enforce integrity constraints by specifying

the types of events that may cause the
constraints to be violated.

Automatic maintenance of derived data (e.g.,

the derived attribute TOTAL_SAL in the simplified
version of Company schema).

Elmasri/Navathe, Fundamentals of Database Systems, 4th Edition

Temporal Database Concepts
Temporal databases encompass all database
applications that require some aspect of time
when organizing their information (e.g.,
reservation system in hotels, airline, etc.).

For temporal databases, time is considered to be

an ordered sequences of points (e.g., seconds,
minutes, day, etc.).

Is SQL2, the temporal data types include DATE,

TIME, TIMESTAMP, INTERVAL, and PERIOD

Elmasri/Navathe, Fundamentals of Database Systems, 4th Edition

Temporal Database Concepts
A temporal database will store information
concerning when certain events occur.

Types of temporal information:

Point events: associated in the database with a single
time point (e.g., 15/08/1998).
Duration events: associated in the database with a
specific time period (e.g., [15/08/1998, 15/08/2000]).

An interpretation of a temporal database in which

the associated time with their events is a valid
time in the real world, is known as a valid time
database.

Elmasri/Navathe, Fundamentals of Database Systems, 4th Edition

Temporal Database Concepts
An interpretation of a temporal database in which
the associated time with their events is the value
of the system time clock, is known as a
transaction time database.

Incorporating time in relational databases can be

done by adding attributes VST (Valid_START_TIME)
and VET (VALID_END_TIME) into an ordinary
relation.

Each tuple, V, represents a version of the entity

member that is valid in the interval [V.VST, V.VET].

The current version has a special value, now.

Elmasri/Navathe, Fundamentals of Database Systems, 4th Edition
 Temporal Database Concepts
FIGURE 24.7 Different types of temporal relational databases.
(b) Valid time database schema.
(c) Transaction time database schema.
(d) Bitemporal database schema.

Elmasri/Navathe, Fundamentals of Database Systems, 4th Edition

Temporal Database Concepts
The special value, now, is a temporal variable
that implicitly represents the current time as time
progresses.

In order to update a tuple, a new version is

created and the current version is closed (by
changing its VET to the end time).

In proactive update, the database is updated

before it becomes effective in the real world.

In retroactive update, the database is updated

after it becomes effective in the real world.
Elmasri/Navathe, Fundamentals of Database Systems, 4th Edition
Temporal Database Concepts
To deleting a tuple the current version is closed.

To insert a new entity member, create the first

tuple version and make it the current version
(i.e., VST being the effective time, and VET= new).

Note: in a valid time relation, the nontemporal

key, such as SSN in EMPLOYEE relation, is no
longer unique in each version. The new relation
key for EMP_VT is a combination of the
nontemporal key and the valid start time attribute
VST.

Elmasri/Navathe, Fundamentals of Database Systems, 4th Edition

 Temporal Database Concepts
FIGURE 24.8
Some tuple versions in the valid time relations EMP_VT and
DEPT_VT.

Elmasri/Navathe, Fundamentals of Database Systems, 4th Edition

Temporal Database Concepts
Attributes that change over time are called time-
varying attributes.

Attributes that do not change over time are called

non-time-varying attributes.

In tuple versioning approach, whenever an

attribute value in changed a whole new tuple
version is created.

In attribute versioning approach , a single

complex object is used to store all the temporal
changes of the object.
Elmasri/Navathe, Fundamentals of Database Systems, 4th Edition
 Temporal Database Concepts
FIGURE 24.10
Possible ODL
schema for a
temporal valid
time
Employee_VT
object class
using attribute
versioning

Elmasri/Navathe, Fundamentals of Database Systems, 4th Edition

 Multimedia Databases
Spatial databases store objects that have
spatial characteristics that describe them (e.g.,
cartographic databases store maps).

The main extensions that are needed for spatial

databases are models that can interpret spatial
characteristics.

The basic extensions needed are to include two

dimensional geometric concepts such as points,
lines, circles, polygons, and arcs.

Elmasri/Navathe, Fundamentals of Database Systems, 4th Edition

 Multimedia Databases
Typical types of spatial queries:

Range query: finds the objects of a particular type

that are within a given spatial area (e.g., finds all
hospitals in a given suburb or city).

Nearest neighbor query: finds an object of a

particular type that is closest to a given location (e.g.,
finds the nearest shopping center).

Spatial joins or overlays: joins the objects of two

types based on some spatial conditions (e.g., finds all
homes that are within two km of a lake).

Elmasri/Navathe, Fundamentals of Database Systems, 4th Edition

 Multimedia Databases
One of the best known technique, in order to
answer spatial queries, is the use of R-trees and
their variations.

R-trees group together objects that are in close

spatial physical proximity on the same leaf nodes
of a tree-structured index.

Other spatial storage structures include

quadtrees and their variations.

Quadtrees divide each space into equally sized

areas, and proceed with the subdivisions of each
subspace to identify the positions of various
objects.
Elmasri/Navathe, Fundamentals of Database Systems, 4th Edition
 Multimedia Databases
Multimedia databases provide features that
allow users to store and query different types of
multimedia information (e.g., images, video clips,
audio clips, and documents).

The main types of database queries involve

locating multimedia sources that contain objects
of interest. These types of queries are called
content-based retrieval queries.

Identifying the contents of multimedia sources is

a difficult and time-consuming task.

Elmasri/Navathe, Fundamentals of Database Systems, 4th Edition

 Multimedia Databases
Two main approaches to content-based retrieval:

Automatic analysis: uses different techniques

depending on the type of multimedia source (e.g.,
image, text, video, or audio).

Manual identification: depends on the objects and

activities of interest in each multimedia source and on
using this information to index the source.It requires a
manual preprocessing phase where a person has to
scan each multimedia source to identify and catalog the
objects and activities it contains.

Elmasri/Navathe, Fundamentals of Database Systems, 4th Edition

 Deductive Databases
A database system that includes capabilities to
define (deductive) rules, which can deduce or
infer additional information from the facts that
are stored in the database is called a deductive
database.

Rules are specified through a declarative

language –we specify what to achieve rather
than how to achieve it.

The model used for deductive databases is

related to the logic programming and the
prolog language.

Elmasri/Navathe, Fundamentals of Database Systems, 4th Edition

 Deductive Databases
A variation of Prolog called Datalog is used to
define rules declaratively in conjunction with an
existing set of relations.

Two main types of specifications:

Facts: similar to the way relations are specified, except

that it is not necessary to include the attribute names
(note that a tuple in a relation describes some real-
world facts).

Rules: similar to relational views –that are not actually

stored but can be formed from the facts by applying
inference mechanisms based on the rule specifications.

Elmasri/Navathe, Fundamentals of Database Systems, 4th Edition

 Prolog/Datalog Notation
A logic program can be thought of:

A set of facts (assuming that these are all the fact in our
modeled mini-world)

A set of permissible deductions (proof rules)

A method of deducting

A goal to prove (or a query to answer)

An important difference between rules and facts

is that, rules specify things that are true if some
conditions are satisfied.

Elmasri/Navathe, Fundamentals of Database Systems, 4th Edition

 Prolog/Datalog Notation
A predicate has an implicit meaning and a fixed
number of arguments.

If the arguments are all constant values, the predicate

states a fact.

If the arguments contains variables, then it is either a

query or as part of a rule or constraint.

Constant values in a predicate are either numeric or

strings – stating with lowercase letters.

Variable names always start with an uppercase letter.

Elmasri/Navathe, Fundamentals of Database Systems, 4th Edition

 Prolog/Datalog Notation
A rule is of the form head :- body, where

The head or left-hand side (LHS) or conclusion is a

single predicate.

The body or right-had side (RHS) or premise

consists of one or more predicates.

A predicate with constants as arguments is called

ground or an instantiated predicate.

Elmasri/Navathe, Fundamentals of Database Systems, 4th Edition

 Prolog/Datalog Notation
FIGURE 24.11 (a) Prolog notation. (b) The supervisory tree.

Elmasri/Navathe, Fundamentals of Database Systems, 4th Edition

 Prolog/Datalog Notation
A program contains a number of built-in
predicates. Two main types of built-in predicates:

1) The binary comparison predicates <, <=, >, >=

(corresponding to less, less_or_equal, greater,
greater_or_equal) over ordered domains.

3) The comparison predicates =, /= (corresponding to

equal, not_equal) over unordered domains.

A program is built from basic objects called

atomic formulas. Atomic formulas are literals
of the form p(a1, a2, …, an), where p is the
predicate name and n (the arity or degree of p)
is the number of arguments.

Elmasri/Navathe, Fundamentals of Database Systems, 4th Edition

 Prolog/Datalog Notation
A literal is either an atomic formula (in this case it
is called a positive literal), or it is an atomic
formula preceded by not (in this case it is called
a negative literal).

Prolog/Datalog has an internal inference engine

that can be used to process and compute the
results of queries.

Prolog inference engine return one result to the

query at a time, but Datalog returns results set-
at-a-time.

Elmasri/Navathe, Fundamentals of Database Systems, 4th Edition

 Prolog/Datalog Notation
Two interpretation of rules:
Proof-theoretic: considers the facts and rules to be
true statements, or axioms.
– Facts are ground axioms –have no variables

– Rules are deductive axioms –can deduce new facts.

Model-theoretic: assigns to a predicate every possible

combination of values as arguments and specifies the
combination of the arguments that make the predicate
true.
An interpretation is called a model for a specific
set of rules if the rules are always true under that
interpretation.

Elmasri/Navathe, Fundamentals of Database Systems, 4th Edition

 Prolog/Datalog Notation
FIGURE 24.12
Proving a new fact.

Elmasri/Navathe, Fundamentals of Database Systems, 4th Edition

 Prolog/Datalog Notation
A model is called minimal model for a set of
rules if we cannot change any fact from true to
false and still get a model for these rules.

Two main method of defining the truth values of

predicates in Datalog programs:
Fact-defined predicates (or relations): listing all the
combinations of values (the tuples) that make the
predicate true.

Rule-defined predicates (or views): being the LHS

of one or more Datalog rules. They correspond to virtual
relations whose content can be inferred by the inference
engine.

Elmasri/Navathe, Fundamentals of Database Systems, 4th Edition

 Prolog/Datalog Notation
FIGURE 24.14
Fact predicates
for part of the
database from
Figure 5.6.

Elmasri/Navathe, Fundamentals of Database Systems, 4th Edition

 Prolog/Datalog Notation
FIGURE 24.15 Rule-defined predicates.

Elmasri/Navathe, Fundamentals of Database Systems, 4th Edition

 Prolog/Datalog Notation
Many operations of the relational algebra can be
specified in the form of Datalog rules.

We do not need to specify the attribute names.

The arity (degree) of each predicate and the

domain (data type) of each attribute is important
for operations such as UNION, INTERSECTION,
and JOIN.

Elmasri/Navathe, Fundamentals of Database Systems, 4th Edition

 Prolog/Datalog Notation
FIGURE 24.16
Predicates for
illustrating
relational
operations.

Elmasri/Navathe, Fundamentals of Database Systems, 4th Edition