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.

Summary

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.
 

---