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 







The Current State of Object Technology

Oracle Database Tips by Donald Burleson

There has been a huge debate about the benefits of adding objects into mainstream database management.  For years a small but highly vocal group of object-oriented bigots preached the object revolution with an almost religious fervor.  However, the object-oriented databases languished in the backwaters until the major relational database vendors made a commitment to incorporate objects into their relational engines.  Now that object-orientation is becoming a reality, Oracle developers are struggling to understand how the new object extensions are going to change their lives.

Oracle's commitment to objects was not just acknowledgment of a fad; the benefits of being able to support objects is very real, and the exciting new extensions of Oracle are going to create the new foundation for database systems of the twenty first century.

When glancing at the Oracle documentation, these extensions seem very mundane.  These new features essentially consist of user-defined data types, pointers to rows, and the ability to couple data with behavior using methods.  However, these new additions are anything but mundane.  They are going to change the way that databases are designed, implemented and used in ways that Oracle developers have not been able to imagine.

Oracle database designers will no longer need to model their applications at their most atomic levels.  The new ?pointer? construct of Oracle will allow for the creation of aggregate objects, and it will no longer be necessary to create Oracle ?views? to see composite objects.  Relational databases need to be directly able to represent the real world.  The object-oriented advocates argued that it does not make sense to dismantle you car when you arrive at home each night, only to re-assemble your car every time that you want to drive it.  In Oracle7 we must assemble aggregates using SQL joins every time that we want to see them.  Finally, relational designers will be able to model the real-world at all levels of aggregation and not just at the third normal form level.

This ability to pre-build real-world objects will allow the Oracle designer to model the world as it exists, without having to re-create objects from their pieces each time that they are needed.  These real-world objects also have ramifications for Oracle's SQL.  Rather than having to join numerous tables together to create an aggregate object,  the object will have an independent existence, even if it is composed entirely of pieces from atomic tables (Figure 1).

Figure 1  Object are made up of atomic relational entities

This modeling ability also implies that a whole new type of database access.  Rather than having to use SQL, Oracle databases may be ?navigated?, going from row-to-row, chasing the pointer references without ever having to join tables together.  Navigational data access will allow Oracle designers to create faster links between tables, avoiding some of the time-consuming SQL join operations that plague some systems.

Finally, the ability of Oracle to tightly couple data and behavior will change everything.  Rather than having all of your process logic in external programs, the process code with move into the Oracle database and the Oracle engine will manage both the data and the processes that operate on the data.  These ?Methods? were first introduced into the object-oriented model to provide encapsulation and reusability.  Encapsulation refers to the requirement that all data inside an object can only be modified by invoking one of its methods.  By having these pre-tested and reliable methods associated with the object, an Oracle object ?knows? how to behave and the methods will always function in the same manner regardless of the target objects.  Reusability is achieved by eliminating the ?code hunt?.  Before methods were introduced, an Oracle programmer would have to scan through Pro*C programs or stored procedures searching for the code that they desired.  With methods, the developer only needs to know the name of the class associated with the object, and the list of methods can easily be displayed.  The availability of these re-usable methods will change the role of the Oracle programmer from being code craftsmen.  Just as the introduction of reusable parts changed the way American manufacturing functioned, the introduction of reusable code with change the way that Oracle systems are constructed and maintained.     

However, this reusability does not come without a price.  The structure of the aggregate objects must be carefully defined, and the Oracle developer must give careful thought to the methods that are associated with objects at each level of aggregation.  Libraries of reusable code will develop to be used within new Oracle systems.

Now that we have seen the compelling benefits of object/relational databases, let's take a closer look at how Oracle has implemented these features.  Oracle has implemented the object/relational model in stages, introducing objects in Oracle 8.0 and inheritance in Oracle 8.2. 

1.  User-defined Data Types

The ability of Oracle to support user-defined data types (sometimes called abstract data types, or ADT's) has profound implications for Oracle design and implementation.  User-defined data types will allow the database designer to: 

1. Create aggregate data types.  These are data types that contain other data types.  For example a type called full_address could contain all of the sub-fields necessary for a complete mailing address.

2. Nesting of user-defined data types.  Data types can be placed within other user-defined data types to create data structures that can be easily re-used within Oracle tables and PL/SQL.  For example, a data type called customer could be defined that contains a data type called customer_demographics, which in-turn contains a data type called job_history, and so on.

2.     Pointers and Oracle

One of the new user-defined data types in the object-relational model is a "pointer" data type.  Essentially a pointer is a unique reference to a row in a relational table.  The ability to store these row ID's inside a relational table extends the traditional relational model and enhances the ability of an object-relational database to establish relationships between tables.  The new abilities of pointer data types include:

a) Referencing "sets" of related rows in other tables.

It is now possible to violate first normal form and have a cell in a table that contains a pointer to repeating table values.  For example, an employee table could contain a pointer called job_history_set, which, in turn contains pointers to all of the relevant rows in a job_history table.  This technique also allows for aggregate objects to be pre-built, such that all of the specific rows that comprise the aggregate table could be pre-assembled.

b)  Allow "pointers" to non-database objects in a flat file. 

For example, a table cell could contain a pointer to a flat file that contains a non-database object such as a picture in GIF or JPEG format.

c) The ability to establish one-to-many and many-to-many data relationships without relational foreign keys.

This would alleviate the need for relational JOIN operations, since table columns could contain references to rows in other tables.  By de-referencing these pointers, rows from other tables could be retrieved without ever using the time consuming SQL JOIN operator.

Now that we have a high-level understanding of these Oracle features, let's take a closer look at how they are implemented.




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.