 |
|
Top-down vs. Bottom-Up Object Database Design
Oracle Database Tips by Donald Burleson
|
Object Database Design
There is still a great deal of controversy about
the best way to approach database design for object-oriented systems.
Architecturally, some experts argue that the relational model is not well suited
for use in an object-oriented environment while other experts maintain that
relational architectures are more suitable for traditional data processing.
This has been borne out in the marketplace where we see object-oriented
databases used for non-traditional applications such as telephone billing
system, while the relational model enjoys predominance in business
administration applications.
It is important to recognize that many of the
"pure" object-oriented database management systems do not exploit many of the
features of "classical" database management. To some object-based systems, the
only purpose of an object database (OODBMS) is to provide "object persistence"
and very little attention is paid to concurrency-control, rollback and recovery,
and the other features associated with relational database management.
One very important point: A database does not
have to support all of the formal constructs of the object-oriented approach to
benefit from using the object-oriented approach. For example, while
object-oriented programming languages such as C++ allow for the creation of
abstract data types, the data types offered in most commercial database systems
such as, CHAR, INTEGER, REAL, VARCHAR, and BIT are sufficient for almost all
database applications.
However, the relational vendors recognize the
shortcomings of their architecture. For example, almost every commercial
relational database vendor has promised to deliver user-defined data types in
their future releases. Oracle, the popular relational database for midrange
computers, has announced that Oracle version 8 will support abstract data
typing. This topic is fully discussed in Chapter 5, "Relational Database
Objects and User-defined Data Types".
One must remember that the main difference
between object-oriented and traditional systems is the idea that in an
object-oriented system both data and behavior are stored in the DBMS. In an
object-oriented database, instances of a class may behave differently depending
upon the processing circumstances. Consider a simple example of how an
object-oriented database may differ from traditional systems.
In a traditional database system, all instances
of an order record would share the same data items and processing
characteristics. Under object-oriented databases, an order will contain not
only the order record itself, but the relevant behaviors that are associated
with the order. For example, there may be "rush" orders that exhibit different
behaviors than would a "COD" order.
Now that we understand the basic precepts of
object database design, let's take a look at the major approaches to adding
physical details to the logical object model.
Top-down vs. Bottom-up object database design
There are two approaches for developing any
database, the top-down method and the bottom-up method. While these approaches
appear radically different, they share the common goal of uniting a system by
describing all of the interaction between the processes. Let's examine each
approach:
The top-down method starts from the general and
moves to the specific. Basically, you start with a general idea of what is
needed for the system and then ask the end-users what data they need to store.
The analyst will then work with the users to determine what data should be kept
in the database. Using the top-down method requires that the analyst has a
detailed understanding of the system. The top-down method also can have
shortcomings. In some cases, top-down design can lead to unsatisfactory results
because the analyst and end-users can miss something that is important and is
necessary for the system.
The bottom-up approach begins with the specific
details and moves up to the general. To begin a bottom-up design, the system
analyst will inspect all the interfaces that the system has, checking reports,
screens, and forms. The analyst will work backwards through the system to
determine what data should be stored in the database.
To understand the differences between these
approaches, let's consider some jobs that are bottom-up in nature. In
statistical analysis, analysts are taught to take a sample from a small
population and then infer the results to the overall population. Physicians are
also trained in the bottom-up approach. Doctors examine specific symptoms and
then infer the general disease that causes the symptoms.
An example of jobs that require the top-down
approach include project management and engineering tasks where the overall
requirements must be specified before the detail can be understood. For
example, an automobile manufacturer must follow a top-down approach to meet the
overall specifications for the car. If a car has the requirement that it cost
less than 15,000 dollars, gets 25 miles per gallon, and seating five people.
In order to meet these requirements the designers must start by creating a
specification document and then drilling down to meet these requirements.
The analyst will have no choice but to talk and
work with the users to determine what is important to the users and as a result
determines what data should be stored in the database. What the analyst usually
does is create some prototype reports, screens, and forms to help the users
visualize what the system will look like and how the system will work.
and include the URL for the page.
