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
These new features may change the way that DRM
addresses database management, especially with the incorporation of
multidimensional, text, and object architectures.
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
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:
Create aggregate data types.
For example a type called full_address could contain all of the sub-fields
necessary for a complete mailing address.
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
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.
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.
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.
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
method after determining the target object for
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.
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
You can buy it direct from the publisher for 30%-off and get
instant access to the code depot of Oracle tuning scripts.