Databases Reference
In-Depth Information
a certain constructor, such as the list or the array? There are many factors that
can determine the best design of a database schema. Nonetheless, it is possi-
ble to devise methodological guidelines that can help the database designer.
The rest of this section presents a methodological approach that sup-
ports the design of an object-oriented database schema. The approach that
we present must be understood as only a set of guidelines, because there is no
unique and exact method to design databases.
To a large extent, the object-oriented paradigm has changed the appli-
cation design process, chiefly because the gap among the various design
phases is reduced. In the same way, conceptual, logical, and implementation
models in object-oriented databases (always object models) are closer than
their corresponding models in relational databases (E/R and relational mod-
els). However, in spite of using the same paradigm in all design phases,
object-oriented conceptual models generally are richer than object-oriented
design and implementation models. Some of the concepts that are usually
supported by conceptual models, and that are not provided by most of
the design and implementation models, are: n-ary relationships, relationships
with attributes, different kinds of generalizations (such as complete/incom-
plete or disjoint/overlapping generalizations), aggregations, constraints (such
as the ordered constraint in a relationship), and so on. In addition, there are
some decisions that must be taken at design level, such as, for example, the
final representation of a multivalued attribute, because the conceptual
schema must not specify when a multivalued attribute has to be defined as an
array, as a list, or as a set.
The first step in a database design process is to define a conceptual
schema in a language (usually called model ) which has to be close to the
user and independent of the final implementation (see Chapter 1). The
model used in this step should be able to represent every users requirements;
therefore, it must be as expressive as possible. It would also be recommend-
able that the model should be supported by most of the CASE tools (see
Chapter 13). We could use the Unified Modeling Language (UML) notation
[17], which, apart from being the OMG standard notation, fulfills the previ-
ously mentioned characteristics.
Once the conceptual schema has been defined, it often can be directly
translated into the final implementation in a specific OODBMS. Another
possibility consists of getting, as an intermediate step, a schema described in
ODL [3], which would represent the design details independently of the final
product (improving portability, understandability, etc.) (see Figure 7.3). Even
though we advise getting the implementation schema in three steps (from
conceptual design to implementation design, going through the standard
