There has been a huge debate about the benefits
of adding objects into mainstream database management. For years a small but
highly vocal group of object-oriented bigots preached the object revolution with
an almost religious fervor. However, the object-oriented databases languished
in the backwaters until the major relational database vendors made a commitment
to incorporate objects into their relational engines. Now that
object-orientation is becoming a reality, Oracle developers are struggling to
understand how the new object extensions are going to change their lives.
Oracle's commitment to objects was not just
acknowledgment of a fad; the benefits of being able to support objects is very
real, and the exciting new extensions of Oracle are going to create the new
foundation for database systems of the twenty first century.
When glancing at the Oracle documentation, these
extensions seem very mundane. These new features essentially consist of
user-defined data types, pointers to rows, and the ability to couple data with
behavior using methods. However, these new additions are anything but mundane.
They are going to change the way that databases are designed, implemented and
used in ways that Oracle developers have not been able to imagine.
Oracle database designers will no longer need to
model their applications at their most atomic levels. The new ?pointer?
construct of Oracle will allow for the creation of aggregate objects, and it
will no longer be necessary to create Oracle ?views? to see composite objects.
Relational databases need to be directly able to represent the real world. The
object-oriented advocates argued that it does not make sense to dismantle you
car when you arrive at home each night, only to re-assemble your car every time
that you want to drive it. In Oracle7 we must assemble aggregates using SQL
joins every time that we want to see them. Finally, relational designers will
be able to model the real-world at all levels of aggregation and not just at the
third normal form level.
This ability to pre-build real-world objects
will allow the Oracle designer to model the world as it exists, without having
to re-create objects from their pieces each time that they are needed. These
real-world objects also have ramifications for Oracle's SQL. Rather than having
to join numerous tables together to create an aggregate object, the object will
have an independent existence, even if it is composed entirely of pieces from
atomic tables (Figure 1).
Figure 1 Object are made up of atomic
relational entities
This modeling ability also implies that a whole
new type of database access. Rather than having to use SQL, Oracle databases
may be ?navigated?, going from row-to-row, chasing the pointer references
without ever having to join tables together. Navigational data access will
allow Oracle designers to create faster links between tables, avoiding some of
the time-consuming SQL join operations that plague some systems.
Finally, the ability of Oracle to tightly couple
data and behavior will change everything. Rather than having all of your
process logic in external programs, the process code with move into the Oracle
database and the Oracle engine will manage both the data and the processes that
operate on the data. These ?Methods? were first introduced into the
object-oriented model to provide encapsulation and reusability. Encapsulation
refers to the requirement that all data inside an object can only be modified by
invoking one of its methods. By having these pre-tested and reliable methods
associated with the object, an Oracle object ?knows? how to behave and the
methods will always function in the same manner regardless of the target
objects. Reusability is achieved by eliminating the ?code hunt?. Before
methods were introduced, an Oracle programmer would have to scan through Pro*C
programs or stored procedures searching for the code that they desired. With
methods, the developer only needs to know the name of the class associated with
the object, and the list of methods can easily be displayed. The availability
of these re-usable methods will change the role of the Oracle programmer from
being code craftsmen. Just as the introduction of reusable parts changed the
way American manufacturing functioned, the introduction of reusable code with
change the way that Oracle systems are constructed and maintained.
However, this reusability does not come without
a price. The structure of the aggregate objects must be carefully defined, and
the Oracle developer must give careful thought to the methods that are
associated with objects at each level of aggregation. Libraries of reusable
code will develop to be used within new Oracle systems.
Now that we have seen the compelling benefits of
object/relational databases, let's take a closer look at how Oracle has
implemented these features. Oracle has implemented the object/relational model
in stages, introducing objects in Oracle 8.0 and inheritance in Oracle 8.2.
1. User-defined Data Types
The ability of Oracle to support user-defined
data types (sometimes called abstract data types, or ADT's) has profound
implications for Oracle design and implementation. User-defined data types will
allow the database designer to:
1. Create aggregate data types. These are data
types that contain other 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. Data
types can be placed within other user-defined data types to create data
structures that can be easily re-used within Oracle tables and PL/SQL. 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.
2.
Pointers and Oracle
One of the new user-defined data types in the
object-relational model is a "pointer" data type. Essentially a pointer is 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:
a) Referencing "sets" of related rows in other
tables.
It is now possible to violate first normal
form and have a 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 technique also allows for aggregate objects to
be pre-built, such that all of the specific rows that comprise the aggregate
table could be pre-assembled.
b) 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.
c) 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 time consuming SQL JOIN operator.
Now that we have a high-level understanding of
these Oracle features, let's take a closer look at how they are implemented.
and include the URL for the page.
