Select Magazine - July 1998

 

Object-Relational Databases: Their Time has Come…Almost
Dr. Paul Dorsey

 

Overview

Object-relational databases are coming. "Object-oriented" has been the hottest buzzword in the computer industry for the last decade. It is hard to pick up any magazine in the computer industry without seeing some article dealing with object-orientation. Often, mistakenly used as a synonym for reusable code, object orientation implies a precise set of theoretical computer science structures that can impact every aspect of the system including programming languages, tools, and databases.

The main impact of this technology has been on programming. Object orientation has transformed how programming is done. We should recognize, however, that not every program in C++ is object-oriented. The most important aspect of the system that must be object oriented is the thinking of the design team. It is still common for programs to be written with no reusable components or standards. A while back, I audited a large system failure that was written in C++ in which every programmer had set his/her own standards. Only one small part of the system was written using object-oriented programming standards.

To some extent, this object-oriented revolution has already had an impact on the database community. The move towards generic models so strongly espoused by leading database modelers is a reflection of this revolution. Likewise, the almost universal use of templates with reusable object components in application development is now the norm in leading programming shops. At this point, arguably trailing what has already become the standard object-oriented way of thinking, Oracle is now enhancing the RDBMS, Designer/2000 and Developer/2000 to better support this object-orientation.

Object-Oriented Products

In Forms 4.5 we had our first taste of object orientation through property classes. We could set and enforce standard sets of properties for any object in our applications. PL/SQL used with libraries and object groups was a rich enough set of features to provide us with some ability to create reusable program components. A few of us even went so far as to encapsulate whole parts of our applications into reusable structures. Now the products are starting to better support this evolution to object-oriented thinking.

In the RDBMS, starting with release 8.0 (released June, 1997), Oracle provided our first taste of an object-relational database. In the object extension, primary keys were replaced with OIDs, traditional referential integrity was replaced with object pointers, and two non-1st normal form constructs were added: nested tables and tables of references.

Developer/2000 2.0, first released in March, 1998, provided explicit template and object library support even though many of us were doing workarounds to produce this template functionality for years. The inheritance model was improved so that referenced objects could be modified. Finally, the ability to hook blocks to PL/SQL procedures was added, acting as a precursor to attach blocks to Oracle 8 object extensions, a feature added in version 2.1 (June, 1998).

Designer/2000, v. 2.1 (June, 1998) presented the first object extension by including a new component called the Object Database Designer (ODD). This component gave us the ability to use a subset of Universal Modeling Language (UML) class diagrams to generate the Oracle8 object extensions DDL code. More about UML will be discussed later in this article.

With the object extensions in the RDBMS, Developer/2000 support to write applications against the object extensions and Designer/2000 support of DDL generation, are we now ready to create object-relational systems? Not quite. So far, this combination of relational and object-oriented databases is still very new. As of this writing, we still don’t have inheritance of attributes or methods in Oracle 8. Oracle 8 nested tables have serious performance problems because of the chaining algorithm used. When using object tables, we cannot use traditional referential integrity in Oracle8.

In Designer/2000’s ODD, many of the important features of UML have not yet been implemented. This does not mean that object-relational databases are a bad idea, just that they are still evolving. In the next few years, object-relational databases will completely supplant traditional relational databases as the standard for new systems.

What does Object-Relational Really Mean?

If you ask a half-dozen experts what object-relational means, you will get at least a half-dozen answers. We are still trying to integrate the relational paradigm with the object paradigm. Combining the two is not going to be easy.

True object databases are a very tiny portion of the market and object-relational databases are still evolving. The problem is deciding what we really want in this new paradigm. We have 20 years of relational history during which relational technology has matured into a very sophisticated environment. We finally have full referential integrity, stored procedures, triggers, and many of us have figured out how to avoid mutating tables. Similarly, object-oriented programming started taking off at about the same time as relational databases, providing an additional 20-year history. Object oriented programming is now the standard for the best programmers.

 

Creating Object-Relational Systems

What advantages does the object-relational paradigm have that simple relational databases do not?

What is it about using an object-relational approach that provides these advantages? Object relational thinking is an improvement over traditional relational databases. Every time a supertype or subtype is modeled, object-oriented thinking is being used. Unfortunately, there is no analog in a relational database to explicitly implement supertypes and subtypes.

Traditionally we have thought about data and applications separately. In Designer/2000 we connect functions to entities through interaction matrices. In Developer/2000 applications are hooked to data in the same way that programs have always interacted with data structures. Logically, data and code should not be considered separately. The object oriented idea that data objects and their respective operations and methods should be considered together is a much more natural and logical approach.

If we can get the RDBMS and tools to be more consistent with this object oriented approach, we will be able to build better systems faster.

The Unified Modeling Language (UML)

Recently, some of the leading thinkers in the object community have created Unified Modeling Language (UML). With the advent of increasingly complex systems, a clear and concise way of representing them visually became increasingly important. The Unified Modeling Language (UML) was developed by Grady Booch, Jim Rumbaugh and Ivar Jacobson as a response to that need. In an attempt to create a single system for modeling and documenting information systems and business processes, UML was created with an underlying object-oriented analysis and design philosophy. In order to build successful systems, a sound model is essential. It communicates the overall system plan to the entire development team. Like any language, UML has its own elements and guidelines and will be used throughout this book to illustrate examples of various modeling patterns and actual systems we have built.

As stated in the UML Summary Document (downloadable from the Rational web site – www.rational.com), the primary goals in designing UML were the following:

For all of the reasons stated above, we believe that UML is the language of choice for building object-oriented systems.

Unified Modeling Language (UML) will not answer all of our modeling needs. We will still deal with an environment where some of the data-related business rules cannot be represented by the UML class data model. However, UML certainly gives us a more flexible system that allows us to accurately represent a much greater percentage of the data-related business rules. As the limitations of ER modeling are enumerated, hopefully, you will understand why there is a compelling need to replace the current industry standard of ER modeling with the much more flexible and robust object-oriented UML.

 

Using UML

For people familiar with ER modeling, the important thing to recognize is that the shift to UML will not be a traumatic one. Serious modelers are well acquainted with the limitations of Entity Relationship Diagrams. With UML, some, but by no means all, of the limitations are eliminated. Some of the things we dislike about ERDs are still present with UML.

It is important to be clear about the terms being used with regard to relational and object modeling. Keep in mind that the notion of an "Entity" in ER modeling is being replaced with the notion of a "Class" in UML. The proper definition of an class in this context is broader than that of an entity. You can use objects to describe process information as well. However, for this discussion, "object" will be used in the context of data objects. An class is something of interest to the organization or a means of classifying something of interest. The crucial point is that an entity or class always represents something in the real world. This is one of the key mechanisms you can use to check the validity of your data model. Can you articulate precisely the real-world "thing" that each Class corresponds to? If it cannot be precisely articulated, then you do not have a valid data model.

For ER modelers, simply think of an Class as being synonymous with an Entity. However, there is one very significant difference, namely that Classes are associated with "Methods." Methods can be thought of as PL/SQL functions and procedures that act on the Class. If you think about Classes translating into tables, Methods are PL/SQL functions that interact with the tables. For example, for an Employee Class, the associated Methods would include Hire, Fire, Give Raise, Assign to Dept., Assign to Committee. It is possible to make this list of methods exhaustive so that developers need only interact with these Methods rather than directly manipulating the data in the Classes. This ability to isolate the developers from the physical structure of the Classes is considered a primary advantage of the UML technique.

Advantages of an Object-Oriented Approach

I think that, with Oracle8, we are still conceptually in roughly the same environment as we were with Oracle6. With Oracle6, we could declare referential integrity constraints but the database didn’t enforce them. Similarly, we have some object-oriented structures in Oracle8 but they are not yet fully implemented.

This does not mean that we shouldn’t start creating object-oriented designs. There are some places where we might take advantage of the new Oracle8 structures. Even if we choose to implement our object-oriented designs using version 7.3 constructs, our designs will be better if we shift our thinking in an object-oriented direction.

I started shifting my logical database design towards object-oriented structures about two years ago. Since that time, I have seen my database designs improve greatly because of the object-oriented approach. Specifically, the biggest advantage I’ve noticed is that the number of entities (and ultimately tables) in my models have greatly decreased. The structures are much more robust and flexible so that, as the inevitable new user requirement pops up, the probability that I will have to make a significant change to the data model is greatly reduced. Two recent examples have made this advantage very clear to me.

In designing a retail system, there was a large number of small sets of structures that all looked similar from a structural standpoint, namely PO Requests, POs, Invoices, Receipts of Goods and Inter-company Transfers. Applying object-oriented thinking allowed me to recognize that, in all of these cases, we were talking about movement if merchandise. As a result, instead of having separate structures for all of these constructs, we created a single structure called "Merchandise Movement" that greatly simplified the model. The model was also more robust. Late in the design process, the users came up with a new requirement to support Purchase Returns back to vendors. Because of the object-oriented approach, we were able to easily accommodate these changes without any changes to the data model. Later in the project, the client decided to add a distribution warehouse. Again, no changes were required to support this change to the business.

In another situation at a large financial organization, we were faced with different aggregation paths for stock portfolios. The existing legacy system required two sets of structures, one for the main aggregations and a separate one for the ad hoc rollup structure. This required a great deal of manual intervention and maintenance. Because of the two separate structures, the original database had 81 entities. After redesign using object-oriented structures, the total number of entities was reduced to 27. This not only created a smaller, easier to maintain system, but also included more flexibility and capabilities than the original system.

In both of these cases, object-oriented thinking resulted in cleaner data models, increased system flexibility and easier maintenance. However, because we were still waiting for fully functional UML products to hit the market, both systems were created using Designer/2000 1.x.

Using UML will not magically make you design object-oriented databases any more than using ERDs made you develop 3nf data structures. It will be just as easy to build bad databases using UML as it has been to build bad databases using ERDs. In addition, because UML products such as Oracle’s Object Database Designer (the UML portion of Designer/2000) will generate some Oracle8 structures automatically, there may be a greater likelihood of building databases that are completely unusable than was the case with the more limited 7.3 structures.

Conclusion

It is clear that object-relational databases are the wave of the future. However, we are not ready to build production object-relational systems. First, the Oracle 8 object extensions need to go through another iteration. At a minimum we need inheritance in the RDBMS. We also need improved performance and some improved ability to modify object structures once they are built.

In Designer/2000 we need a full implementation of the UML class diagrams in the Object Database Designer and we need to see some other parts of UML make their way into the product. We also need to be able to generate modules to the object structures.

I would like to encourage you all to get involved in the object extensions to the Oracle products. The products are still being developed. If you use the products and make your opinions heard, you can have a significant impact on the future of these tools. This is perhaps the most important shift in database since relational theory. Let’s all put our heads together and make sure we do this right.

 

About the Author

Dr. Paul Dorsey is the President of Dulcian, Inc., an Oracle consulting firm. He specializes in logical design and application development. Paul is co-author with Peter Koletzke of Oracle Press’ Designer/2000 Handbook. Paul is also collaborating on a book on Developer/2000 for O’Reilly Press and a book on Oracle8 Object Modeling and Database Design for McGraw-Hill. Paul is Vice President of the New York Oracle User Group and very active in the Oracle user community. He can be contacted at pdorsey@dulcian.com

 

Oracle Consulting Services | Application Development | Custom Training | Data Migration | Data Warehousing

Database Administration | About Dulcian | Papers & Presentations | Related Links

Publications | Employment Opportunities | Products | Home | Contact Us

©2000 Dulcian, Inc.