Databases Reference
In-Depth Information
database applications, we will be able to easily write portable programs for non
traditional database applications such as a direct simulation over a large number
of CAD DB objects.
In such database applications, the number and topology of objects to be
processed by an application program cannot be determined prior to run time.
However, most parallel programming languages designed and developed for
scientific computation are based on the
data-parallel approach
9)
and therefore
assume the number and topology of objects are fixed at compilation time.
In order to overcome this problem, an
object-parallel approach
for database
programming languages is proposed. Unlike most data-parallel programming
languages, the proposed language can execute parallel operations over an arbitrary
set of objects and supports object references through object identifiers (OIDs).
Since there is no restriction on the number or topology of the objects to be processed
in parallel, application programs can receive objects that satisfy a certain condition
and have complex reference structures among these objects.
Basic Features
In the proposed language, an exclusively parallel construct, designated
a for
all
is designed for parallel operations. The basic syntax is defined as follows.
for all
class variable
in
union
[such that
condition
]
do
method-invocation
The above lines apply a
method-invocation
(or a sequence of multiple method
invocations) over an arbitrary
union
of sets of objects pointed by
variable
in parallel,
where in a
such that
clause can be used as a filter to eliminate irrelevant objects in
the union.
Programmers need not consider the number or topology of objects to be
processed. Rather, the union of object sets and the operation to be applied to
those objects need only be specified. The object sets are actually distributed over
processing elements (PEs) of a distributed-memory parallel computer such as a
workstation cluster.
However, the number and topology of objects cannot be determined at
compilation time in database applications. Therefore, this language requires the
following two features.
1.
A location-independent object reference mechanism
Since database objects are not packed in an array and the relationships
among objects are expressed by OIDs, the reference mechanism cannot be
based on array subscripts. In addition, the reference mechanism must also
be location-independent, because the next feature requires object relocation
at run time.
