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 







Object-Oriented Database Model Technology

Oracle Database Tips by Donald Burleson

Objects were developed by Xerox Corporation's Palo Alto Research Center in the early 1970's.  In Object-Oriented databases, the focus is on objects, not functions.  Object-oriented (OO) technology requires a totally new mindset; developers create models that are mapped to real world processes.

The object-oriented approach emphasizes a more natural representation of the data.  In today's environment, the data models are more demanding.  They need to handle audio, video, text, graphics, etc.  These requirements demand a more flexible storage format than hierarchical, network, and relational databases can provide.  Only object-oriented databases will be able to support this kind of demand.

Three of the fundamentals of OO technology are classes, objects, and messages.  A class describes a group of objects that have common relationships, behaviors, and also have similar properties.  An object encompasses related data and functions into a completely self contained package.  Because objects are "stamped" out from a common class definition, each instance of an object within a class inherits all of the same behaviors and data definitions.  The heart of an object-oriented database is object persistence, and it is the process of storing and retrieving objects that comprises the heart of object data management.

A database object may have a different OID each time that it is loaded onto the heap (memory), and the OODBMS must manage and assign the OID's according to the memory location after the object has been retrieved from disk..

Lets take a look at how behaviors or methods are invoked within an object database.  For example, assume that we have an object of class order with an object id of 123.  The object oriented call to compute the total of order 123 might look like this:


In this case, the message compute_order_total is being sent to the order class definition along with the oid that will be the target of the message.  A method by the name compute_order_total will then be executed against order 123 and the desired data manipulation will take place.

In distributed systems, messaging becomes more important because the class definitions that contain the behaviors may reside on geographically remote processors.  For more information on distributed message processing see chapter 7, Distributed object technology and database management.

Each time an object is created, a unique OID (object identifier) is added to the OODBMS (object-oriented database management system) identifier table.  When an application references an object via its OID, the OODBMS converts the OID into a virtual memory address.  This means that the object can be found quickly regardless of where the object is stored.  For example, local memory, a remote hard disk, or a device in a networked system.  The OID is independent of the value of an object or any data contained in the object.  You can change any or all of the variables in an object and the system will still access the correct object.  An OID once assigned to an object by the system, lasts the lifetime of an object.  An OID is much different from the concept of a key in a relational database.  In a relational database, the key, is defined by one or more values of the fields of a table.  The key in a relational table can be modified. In an OODBMS, the identity of an object is system generated and cannot be changed.  Any two objects are different because of their OID, even if they have the same value.

Let's show how OODBMS relate to RDBMS.  Object classes correspond to relational tables, object attributes correspond to columns, and instances of objects correspond to rows in a table.  Objects are related to each other by the OID, this corresponds to primary and foreign keys in the relational model. For more information on this technique, see Chapter 9, Interfacing an object-oriented application with a relational database.

The object technology model also provides for the encapsulation of data and operations inside an object.  As long as the external interfaces remain unchanged, developers can modify encapsulated data and operations in an object without affecting other objects.  Encapsulation makes the data and procedures private within an object.

As you can see, OODBMS have many new terms, concepts and ways of doing things.  The potential benefits of the object databases are faster development, higher quality, easier maintenance, and increased scalability and adaptability.  In addition the object databases claim to allow the MIS personnel to better model the real-world, resulting in better information structures and reduced costs for systems.  Potential concerns with object databases are

1.     lack of maturity

2.     the need for better tools

3.     the need for standards

4.     the availability of qualified personnel

5.     the costs of data conversion

The object-oriented approach is not only concerned with data storage, data relationships, and easy data access, but also the behavior storage.  This fundamental difference will revolutionize the way that databases function.  Rather than having all of the DML in hundreds of external application programs, the DML will be tightly coupled with the class definition for their associated objects, and will reside in the DBMS along with the data.  This implies that business processes and data will share a common ground.

Object Persistence

Object persistence is  one of the most fundamental services provided by  an OODBMS.  First let's define what persistence means.  A persistent object  is an object that is always available and an object's state will remain unchanged from one invocation to the next, as opposed to an object that is no longer available.

Objects that are no longer available are called transient objects.  Depending on the application, some objects may need to change their state from transient to persistent, and the OODBMS will manage the conversion from persistent to transient.  The OODBMS assigns each object an object identifier (OID), this unique identifier is used primarily to establish relationships between persistent objects. OODBMS provide the recovery services that ensure persistence objects survive any kind of system failure.  The ORB(Object Request Broker) will send a request for a particular object  to the OODBMS, which will use the OID to retrieve and invoke the object.  There are two methods that the OODBMS uses to access persistent objects, virtual memory address pointers and hash tables.  A persistent object will always be ready to be invoked, and its state can and will be preserved and survive any kind of system failure. 

Remember, persistent objects are stored on disk and transient objects exist in RAM memory.  In an OODBMS, an object may traverse between states.

The following are some of the actions that a OODBMS will perform for object persistence, the most important, of course, being the management of objects as they are retrieved from disk and assigned new OID's in RAM memory:

1.     will assign space in persistent storage

2.     will automatically increase space when needed

3.     will manage the free space in persistence storage

4.     will interface the I/O system with persistent storage

5.     will ensure that persistent objects can be recovered

6.     will manage buffers

7.     will map between the physical addresses and the OIDs.



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.