Non-relational Parallel Database Machines

While open research issues remain in the area of parallel database machines
for relational database systems, building a highly parallel database machine for
an object-oriented database system presents a number of new challenges.
One of the first issues to resolve is how declustering should be handled. For
example, should one decluster all sets (such as set-valued attributes of a 
complex object) or just top-level sets? Another question is how should inter
object references be handled. In a relational database machine, such references
are handled by doing a join between the two relations of interest, but in an
object-oriented DBMS references are generally handled via pointers.
In particular, a tension exists between declustering a set in order to parallelize
scan operations on that set and clustering an object and the objects it references
in order to reduce the number of disk accesses necessary to access the
components of a complex object. Since clustering in a standard object-oriented
database system remains an open research issue, mixing in declustering makes
the problem even more challenging.



Another open area is parallel query processing in an OODBMS. Most OODBMS
provide a relational-like query language based on an extension to relational algebra.
While it is possible to parallelize these operators, how should class-specific methods
be handled? If the method operates on a single object it is certainly not worthwhile
parallelizing it However, if the method operates on a set of values or objects that are
declustered, then it almost must be parallelized if one is going to avoid moving all the
data referenced to a single processor for execution. Since it is, at this point in time,
impossible to parallelize arbitrary method code, one possible solution might be to
insist that if a method is to be parallelized that it be constructed using the primitives
from the underlying algebra, perhaps embedded in a normal programming language.

Parallelization of the Application Program

While machines like Teradata and Gamma separate the application
program running on a host processor from the database software
running on the parallel processor, both the Tandem and Bubba systems
use the same processors for both application programs and the parallel
database software. This arrangement has the disadvantage of requiring a
complete, full-function operating system on the parallel processor, but it
avoids any potential load imbalance between the two systems and allows
parallel applications. Missing, however, are tools that would allow the 
application programs themselves to take advantage of the inherent
underlying parallelism of these integrated parallel systems. While automatic
parallelization of applications programs written in Cobol may not be
feasible, library packages to facilitate explicitly parallel application programs
are needed. Support for the SQL3 NOWAIT option in which the application
can launch several SQL statements at once would be an advance. Ideally the
SPLIT and MERGE operators could be packaged so that applications
could benefit from them.

Next-generation parallel database systems

The penetration of database technology into new application areas with different
requirements than traditional business data processing has motivated the notion
of next-generation database systems. One major objective is that
the data model to be supported must be more powerful than the relational
model, without compromising its advantages (data independence and high-level
query languages). When applied to more complex application domains such as
engineering, office information systems, and expert systems, the relational data
model exhibits limitations in terms of rule management, type system and complex
object support.

To address these issues, two important technologies, KBMSs and
OODBMSs, are currently being investigated. Initially considered antagonistic,
many believe today that a combination of their capabilities into deductive and
object-oriented database (DOOD) systems will shape next-generation, universal
database systems. For the same reasons which led to parallel relational database
systems, implementing KBMSs and OODBMSs on parallel computers can be
cost-effective. Obviously, this presents new, challenging research problems in
addition to the current issues of KBMSs and OODBMSs.