Call now: 252-767-6166  
Oracle Training Oracle Support Development Oracle Apps

 E-mail Us
 Oracle Articles
New Oracle Articles

 Oracle Training
 Oracle Tips

 Oracle Forum
 Class Catalog

 Remote DBA
 Oracle Tuning
 Emergency 911
 RAC Support
 Apps Support
 Oracle Support

 SQL Tuning

 Oracle UNIX
 Oracle Linux
 Remote s
 Remote plans
 Application Server

 Oracle Forms
 Oracle Portal
 App Upgrades
 SQL Server
 Oracle Concepts
 Software Support

 Remote S


 Consulting Staff
 Consulting Prices
 Help Wanted!


 Oracle Posters
 Oracle Books

 Oracle Scripts

Don Burleson Blog 







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.      




Oracle Training at Sea
oracle dba poster

Follow us on Twitter 
Oracle performance tuning software 
Oracle Linux poster


Burleson is the American Team

Note: This Oracle documentation was created as a support and Oracle training reference for use by our DBA performance tuning consulting professionals.  Feel free to ask questions on our Oracle forum.

Verify experience! Anyone considering using the services of an Oracle support expert should independently investigate their credentials and experience, and not rely on advertisements and self-proclaimed expertise. All legitimate Oracle experts publish their Oracle qualifications.

Errata?  Oracle technology is changing and we strive to update our BC Oracle support information.  If you find an error or have a suggestion for improving our content, we would appreciate your feedback.  Just  e-mail:  

and include the URL for the page.


Burleson Consulting

The Oracle of Database Support

Oracle Performance Tuning

Remote DBA Services


Copyright © 1996 -  2020

All rights reserved by Burleson

Oracle ® is the registered trademark of Oracle Corporation.