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 Object Database Management Group (ODMG)

Oracle Database Tips by Donald Burleson

The ODMG (Object Database Management Group) will be covered in detail in chapter 5. This is an introduction to the function and purpose of the ODMG.  The ODMG is a sub-group of the OMG (Object Management Group).  The OMG is a consortium of hundreds of object vendors whose purpose is setting standards for object technology.  The ODMG is the standards setting group for object database technology that is made up of a consortium of object-oriented DBMS vendors.

In 1993 the first release of the ODMG was published called ODMG-93, by members of the Object Database Management Group (ODMG).  This was the result of over a year's work defining standards for OODBS (Object-Oriented Database System).  The ODMG-93 standard included a common architecture and definition for an OODBMS, definitions for an object model, an object definition language (ODL), an object query language (OQL), and for bindings to C++ and Smalltalk.  ODMG-93 used the OMG object model as it's starting point and then extended it for database needs.

As a result of ODMG-93 and the standards that were created applications become more portable and the whole OODBMS (Object Oriented Database Management System) technology received a much needed uplift.  The ODMG-93 model will be updated as needed and new releases will be published by the ODMG.

Object/Relational Hybrid Model

The object/relational database is the latest in the ongoing craze of hybrid database architectures.  This model has come about because of the large investment that corporate America has in relational databases and the large retraining effort that would be involved to go from relational to object oriented databases.

OODBMS lack some of the features that all users and the information systems community have come to expect:  simple and easy query capabilities like relational SQL, excellent OLTP (On-line Transaction Processing), and an independent software industry providing utilities and application solutions.  OODBMS at the present time do not have the infrastructure in place to overtake relational databases as relational did to hierarchical and network databases.

What companies like Oracle, Informix, Sybase, and IBM are doing is developing an OR (object/relational) database, these databases enhance the relational database in two ways first by adding an object infrastructure and second by building relational extenders.  The object infrastructure is added to the database itself to support user defined data types, rules, and functions.  Relational extenders are needed to utilize the added object infrastructure productively.  For example relational extenders are needed to handle complex objects, and inheritance, among others.  New relational extenders are being developed all the time.

OR databases are gaining support because many administrators and the information system community recognize the need to update their databases, but feel uncomfortable jumping directly into OO technology.  The OR approach will let developers become familiar with the OO technology at a comfortable pace.  They also will not have to convert their relational or other databases to the new OO data formats, thereby saving both time and money.  The OR database is a way to bridge the gap between OODBMS and RDBMS, by allowing companies to take advantage of OO technology's greater productivity and complex data types without losing their existing investment in relational applications and data.


After computers were invented, flat file systems came about, these systems developed storage and access methods that are stilled used in today's database systems.  One of the first databases was the hierarchical database, concepts developed for hierarchical like pointers are used today in object-oriented databases. Many people felt that the hierarchical model was too restrictive and wanted more flexibility.

To improve on the hierarchical model, the Network model was developed in the late 1960's.  It was commonly called the CODASYL model.  This database can be thought of as a matrix organization.  Network databases were more flexible, but as a result, they were also more complex. The access language was complex and not user friendly.  Ad hoc queries are infrequent.  CODASYL worked well in transaction processing environments.  The CODASYL specifications that were developed by CODASYL DBTG became a cornerstone for all databases.  In fact, some of the CODASYL specifications could be used in the object-oriented database specifications that the OMG group is putting together for OODBMS.  With modifications and updating, who knows, maybe the CODASYL model will reemerge as the model for object-oriented technology. 

Because of the complex nature of both hierarchical and network databases users wanted and needed a simpler design.

The relational model was the simpler design that was needed, but it took 10 to 15 years for computer technology to catch up.  The relational model can be thought of as a collection of two dimensional arrays called tables that have rows and columns.  It has a very simple and easy to use language called SQL, making ad hoc queries frequent and easy.  Today, the relational model is the most widely accepted and popular database model.  Even with all of the improvements that the relational model has over hierarchical and network models, and the fact that technology has and is changing, we now have and need to store audio, video, text, graphics, etc.,   users want more.

So, we now have object-oriented databases. The distinguishing characteristic of the object-oriented database is its ability to store data behavior, but how does the behavior of the data get incorporated into the database?  At first glance, this may seem to be a process for moving application code from a program into a database.  While it is true that an object-oriented database stores "behaviors", these databases must also have the ability to manage many different objects, each with different data items. 

Now that we have reviewed the basic data structures that make up commercial database management system, we can move on to take a look at object-oriented systems analysis.  By understanding the internals of database management and the constructs of object-oriented analysis, we can develop a firm understanding of database objects and their use in the real world.



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.