Inside the Oracle Object Model Oracle Tips by Burleson Consulting

It is interesting to note that Oracle has not discarded the idea of creating a "universal" database engine.  Oracle is billing Oracle 8 as the "Oracle Universal Server", and has added text, multidimensional and object capabilities to the relational engine.  The most exciting enhancements are the introduction of "Sedona", the incorporation of the Oracle Express MDDB, and the "object layer" that will be tightly coupled with the relational engine. 

These new features may change the way that DRM addresses database management, especially with the incorporation of multidimensional, text, and object architectures.

Sedona

Due to the secrecy around the development of Oracle 8, many Oracle professionals assumed that Sedona was the code name for the Oracle 8 product.  Sedona, however is an extension to the Oracle 8 product which is planned to be delivered several months after the initial roll out of Oracle 8 in 1997.  Sedona's has been billed as a "Universal Object Manager" and it appears that its basic function is to act as an "object consolidator" in the sense that it allows for Oracle methods to be indexes and quickly located across many databases and platforms.  Sedona achieves this by placing an object wrapper around Oracle objects, such that they can be accessed by other distributed systems.  While the details are still sketchy, Sedona will incorporate many of the features of an Object Request Broker (an ORB), with a meta-data dictionary for the distributed management of objects.  With Sedona, object classes may be registered in a central repository, where they will then be available for use transparently across the enterprise.  Oracle has made the interface specifications for Sedona to third-party software vendors in the hopes that these vendors will create application products that utilize Sedona.

Rather than re-build the Oracle engine as an object-oriented architecture, Oracle has decided to keep the base relational engine and add object functionality on top of the standard relational architecture.  While claiming to be an active member in the Object Management Group (OMG), Oracle has departed from the OMG's standard for "pure" object databases as defined by the Object Data Management Group (ODMG). Oracle's intent is to provide a generic relational database while extending the architecture to allow for objects.  The object layer of Oracle 8 claims to have the following features:

User defined data types

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

1. Create aggregate 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.  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.

In addition, one of the user-defined data types in the object-relational model is a "pointer" data type.  While these pointers may have many different names within each commercial DBMS, a pointer is essentially 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:

3. Referencing "sets" of related rows in other tables.

It is possible to violate first normal form and have  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 would also allow for aggregate object to be pre-built, such that all of the specific rows that comprise the aggregate table could be pre-defined.

3a.  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.

3b.    The ability to establish pointers to repeating groups.

This would allow the database designer to violate first-normal form and create a table column that has pointers to an array of row pointers.  For example, a column called order_history could be created in a customer table.  This would contain a pointer to a reference table, which would, in turn contain pointers to the specific rows that represent prior orders for that customer.

3c.    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 expensive SQL JOIN operator.

Polymorphism

This method also creates a framework for representing polymorphism. As we may recall from earlier chapters, polymorphism is a situation where the same method call will result in the invocation of a different process, depending upon the target object.  For example, a common method called spread_it_on would exist for hair_tonic objects as well as for floor_wax objects.  Clearly, the process of spreading it on would be vastly different for each of these objects, and the object engine would call the appropriate

method after determining the target object for the method:

spread_it_on(floor_wax);  This call would invoke a method to apply the wax to the floor and use the buffing machine.

spread_it_in(hair_tonic);  This call would invoke a method to direct the gentle application of the tonic upon the scalp.

Cross-object methods

Attaching methods to objects is relatively straightforward when we are dealing with method that are clearly attached to a single object. The issue becomes more of a problem when we start dealing with methods that are associated with several database objects.

For example, consider the behavior of the backorder_inventory method.  The purpose of this method would be to back order any item that was not in sufficient stock in our item warehouse.  But where would this method reside?  Back ordering would probably be a part of a larger method called place_order, and would therefore most likely be attached to the order_form object.  Or would it?

The processing of back ordering an item would probably have more in common with an item method than an order method.

 

If you like Oracle tuning, see the book "Oracle Tuning: The Definitive Reference", with 950 pages of tuning tips and scripts.  You can buy it direct from the publisher for 30%-off and get instant access to the code depot of Oracle tuning scripts.