Database Reference
In-Depth Information
Intraquery Parallelism This method requires the dividing up of a query into its
various operations. Then these individual operations of a single query may be
distributed among the processors for execution in parallel. After the completion
of all operations, the result sets are assembled together to produce the final result
set. This method calls for pipelining the output of one operation as the input for
the next.
Intraquery parallelism may be applied to a query in two ways:
Intraoperation parallelism . A transaction may consist of operations such as select,
sort, project, or join. Each operation itself may be parallelized. For example, if the
transaction has to sort 100,000 records, the sort itself may be split into groups of
records and shared by multiple processors.
Interoperation parallelism . You can accelerate the processing of a single query by
executing the various operations in parallel. Let us say that a query consists of select,
sort, and join. The select operation can run on one processor, the sort on another,
and the join on a third.
Hybrid Parallelism This method is a combination of interquery parallelism and
intraquery parallelism.
Active Databases
Assume that you have implemented a database for your organization and one of
the applications supported by the database is inventory control. Suppose your orga-
nization sells a few critical products that contribute to bulk of the revenue. Your
marketing vice president is very concerned about ensuring that sufficient inventory
of these critical products is always available . How can you satisfy the requirements
of this executive?
If your database is a passive database, then periodically you should run queries
to determine the inventory levels of these critical products. On the other hand, if
your database is an active database, it can automatically alert the marketing vice
president when inventory levels fall below prescribed minimum quantities. Active
databases do not just store data; they can perform defined actions based on stipu-
lated events. This concept is catching on. Many relational systems support this prin-
ciple and can be used to behave as active databases.
Events that trigger actions are usually changes to data values in the database.
Inserts, updates, and deletes are events that can set into action a particular response.
Also, actions can be triggered by temporal events such as the arrival of a certain
day or time. When an event occurs, it can initiate application of defined rules. The
database system verifies the conditions of the rules and triggers appropriate actions.
Rules may be applied for monitoring events. They may also be applied for enforc-
ing integrity constraints.
Active databases work on the event-condition-action paradigm as noted below:
ON
event
IF
condition
THEN
action
Search WWH ::




Custom Search