Databases Reference
In-Depth Information
stop at new students addresses. Two options are available to the administra-
tor of a passive DB system who is seeking to support such a requirement.
One is to add the additional monitoring functionality to all enrollment pro-
grams so the situation is checked for each time a student is added. However,
that approach leads to the semantics of the monitoring task being distrib-
uted, replicated, and hidden among different application programs. The sec-
ond approach relies on a polling mechanism that periodically checks the
addresses of the students. Unlike the first approach, here the semantics of
the application are represented in a single place, but the difficulty stems from
ascertaining the most appropriate polling frequency. If too high, there is a
cost penalty. If too low, the reaction may be too late (e.g., the students are
left on the pavement until the polling program is run again).
An active DB would support the application by moving the reactive
behavior from the application (or polling mechanism) into the DBMS.
Active DBs are thus able to monitor and react to specific circumstances of
relevance to an application. The reactive semantics are both centralized and
handled in a timely manner.
The advantages that can be drawn from this migration are numerous
[1]. First, it promotes code reusability. Rather than replicating code in dis-
tinct applications, the code resides in a single place from which it is implicitly
invoked. Such centralization accounts for increasing consistency because no
application can bypass the policy, and maintenance is eased as changes to
the policy are localized in a single piece of code. Moreover, in a client/server
environment, centralized reactive behavior reduces network traffic, as the
reaction associated with the event is executed locally as the single implicit
invocation arises. By contrast, if the reaction were embedded within the
application, the distinct SQL statements would have been executed across
the net.
The rest of this chapter is structured as follows. Section 3.2 introduces
an example that will be used to illustrate distinct aspects of reactive behavior
through the rest of the chapter. Reactive behavior is generally supported
using rules. Rules can be seen as an implementation mechanism, but imple-
mentation must be preceded by analysis and design. Thus, Section 3.3
provides some insights on how rules can be ascertained from business poli-
cies during analysis. At design time, rules need to be described and their
behavior understood. Section 3.4 illustrates the subtleties of rule behavior
through distinct examples and presents graphical notations for rule descrip-
tion. Section 3.5 addresses implementation issues, illustrating features using
the rule system of Oracle. Finally, Section 3.6 tackles the maintenance of
rule sets.
