26.6 Summary 983
The main function of an inference mechanism is to compute the facts that corre-
spond to query predicates. This can be accomplished by generating a relational
expression involving relational operators as
SELECT, PROJECT, JOIN, UNION, and
SET DIFFERENCE (with appropriate provision for dealing with safety issues) that,
when executed, provides the query result. The query can then be executed by utiliz-
ing the internal query processing and optimization operations of a relational data-
base management system. Whenever the inference mechanism needs to compute
the fact set corresponding to a nonrecursive rule-defined predicate p, it first locates
all the rules that have p as their head. The idea is to compute the fact set for each
such rule and then to apply the
UNION operation to the results, since UNION corre-
sponds to a logical
OR operation. The dependency graph indicates all predicates q
on which each p depends, and since we assume that the predicate is nonrecursive,
we can always determine a partial order among such predicates q. Before computing
the fact set for p, first we compute the fact sets for all predicates q on which p
depends, based on their partial order. For example, if a query involves the predicate
UNDER_40K_SUPERVISOR, we must first compute both SUPERVISOR and
OVER_40K_EMP. Since the latter two depend only on the fact-defined predicates
EMPLOYEE, SALARY, and SUPERVISE, they can be computed directly from the
stored database relations.
This concludes our introduction to deductive databases. Additional material may be
found at the book’s Website, where the complete Chapter 25 from the third edition
is available. This includes a discussion on algorithms for recursive query processing.
We have included an extensive bibliography of work in deductive databases, recur-
sive query processing, magic sets, combination of relational databases with deduc-
tive rules, and GLUE-NAIL! System at the end of this chapter.
26.6 Summary
In this chapter we introduced database concepts for some of the common features
that are needed by advanced applications: active databases, temporal databases, spa-
tial databases, multimedia databases, and deductive databases. It is important to
note that each of these is a broad topic and warrants a complete textbook.
First we introduced the topic of active databases, which provide additional func-
tionality for specifying active rules. We introduced the Event-Condition-Action
(ECA) model for active databases. The rules can be automatically triggered by
events that occur—such as a database update—and they can initiate certain actions
that have been specified in the rule declaration if certain conditions are true. Many
commercial packages have some of the functionality provided by active databases in
the form of triggers. We discussed the different options for specifying rules, such as
row-level versus statement-level, before versus after, and immediate versus deferred.
We gave examples of row-level triggers in the Oracle commercial system, and
statement-level rules in the STARBURST experimental system. The syntax for trig-
gers in the SQL-99 standard was also discussed. We briefly discussed some design
issues and some possible applications for active databases.