There are many people in the IT industry who believe that relational databases are inappropriate for building complex systems requiring many interactions, incapable of supporting complex structures and that object-oriented databases are superior in all ways. This is false. You can create small, simple systems or large and arbitrarily complex structures for a wide variety of system types with relational databases.

I cannot comment of the appropriateness of using relational databases for systems such as real-time air traffic control or robotic support for manufacturing systems; but for all of the typical payroll, retail, manufacturing and all other standard transaction-based systems, relational databases are adequate. I have built many of these.

Nevertheless, relational databases will become the COBOL of the new millennium. Just as COBOL declined when newer languages such as C, and C++ came into being, relational databases will slowly decline in influence as OR technology takes hold. Of course, just as COBOL still clings to life, relational databases will continue to survive for many years. The successful relational products will evolve and take advantage of OO concepts. In his Foreword to Oracle8 Design Using UML Object Modeling book (Oracle Press, 1999), Martin Fowler, a leading object-oriented database theorist, commented: "I do think that object databases will gain ground, but their share of the world’s data will still be very small. The big change will come from the relational databases as they extend their databases to support more object-oriented features."

We’ve been hearing about object-relational (OR) databases for years. Over the last few years, my own papers and books have also included discussions of this important shift in the database community. C.J. Date’s book Foundation for Object/Relational Databases describes one vision of OR theory. OR databases are the next paradigm shift in the database community.

We are currently in the middle of this major paradigm shift. When completed, it will be just as dramatic a jump in technology as going from ISAM/VSAM files to relational databases in the early 1980’s. However, these paradigm shifts do not happen overnight. The first relational databases still looked very similar to their ISAM/VSAM predecessors. The revolution of building normalized structures did not catch on until the mid-to-late 1980’s. For the last ten years, we have taken advantage of relational database technology as the relational database paradigm has matured and been widely accepted.

Over the last five years, there has been a growing recognition of the importance of encapsulating more and more "business rules" (for lack of a better term) into data, making relational databases more flexible and robust. Object-orientation has already arrived in the relational community, independent of Oracle8 objects or Oracle8i extensions. Object-orientation is being applied using traditional relational database technology. The so-called "Generic" modeling movement, exemplified by David Hay, Ulka Rodgers, Dale Lowery and myself espouses the application of object-oriented thinking to relational databases. However, this shift towards object-relational databases requires changes in the tools used to build these structures.

Object-relational databases have many advantages, but these types of databases will not be prevalent until vendors evolve their products to support the object-relational paradigm. Oracle has attempted to do this; but basic object-oriented features such as inheritance and polymorphism have not yet been fully implemented in the DBMS. We still don’t have the tools required to take advantage of the full potential of object-relational databases. However, this does not mean that we cannot take advantage of object-relational thinking right now. Dulcian started applying object-oriented thinking to relational systems design a few years ago with the result that the size of the systems being built greatly decreased, requiring smaller data models and fewer applications.

In order to fully realize the vision of truly object-relational databases, strictly relational tools are no longer adequate. My thinking has evolved beyond what the relational tools can provide. I cannot efficiently implement my designs in a strictly relational environment. System developers and designers have evolved beyond the relational paradigm. We are ready for a new set of tools. What types of tools are needed? There are two major features that will be required:

1. Abstract datatypes
2. Complex attributes and methods

In order to apply object-oriented thinking to the systems I build, I want to be able to declare that there is a "thing" called "Person" with various name fields (first name, last name, etc.), demographic structures (address, phone number, etc.) and associated behaviors and information (relevant dates, numbers, etc.). Using UML diagramming conventions, the relevant data structure for "Person" would look like Figure 1.

This structure is a simple example but could be made more complex.

In the main data model for a standard system including Employees and Customers, I should be able to draw a diagram as shown in Figure 2.

The ideal development tools would allow me to add structures such as those shown in Figures 1 and 2 easily to my systems.

What would I expect the database to provide to support these complex structures?

I want to be able to use the following code:

At this point, EMP.FNAME should be a valid attribute. Anything attached to PERSON such as valid addresses or dates should now be directly attached to EMPLOYEES.

In order to take full advantage of object-relational thinking, I would also like to be able to add attributes and methods about each of the Person, Employee and Customer classes. This would allow developers to create large, complex structures very simply. The "Person" class would also include attributes and other associated classes.

These generalizations and abstract objects are large macro constructs. We also need to have database support for micro constructs such as "super-attributes" described by the UML diagram shown in Figure 3.

Using this type of construct, in our main data model we should be able to use Address_type as a defined datatype.

Not only do I need the database to support these types of Complex OBjects (COBS – as I have named them) but I also need all of the applications to support them. With support from both database and applications, when I build a new system, all I need to do is to declare a generalization and get all of the underlying functionality automatically. If abstract objects and super attributes were included within the DBMS and were both supported by the application tools, over time, the size of the systems we build would decrease by at least 50% with improved functionality. It is not just about building one system, but about creating reusable components and structures that can be used across many systems. This concept can revolutionize the way in which systems are developed.

In order to build these types of systems, a variety of techniques must be used. This section will outline four broad concepts necessary for creating "object-influenced" relational databases using object-oriented thinking:

If you can abstract the objects you are modeling to a higher level you can support a greater variety of objects and have a more stable model. As an example, we built a system for a small retail organization. Instead of using the traditional concepts such as Invoice, Purchase Order, etc., we thought more abstractly and came up with the notion of "Merchandise Movement" which included all of the merchandise-oriented transactions associated with a retail operation. This one simple shift allowed us to create a system with many fewer tables, applications and reports while delivering more flexibility and functionality. This was evident midway through the project when it was discovered that, in gathering requirements, no one had mentioned the need for making inter-store transfers of merchandise. In a traditional model, this would have been disastrous and would have required extensive reworking of the original data model. In our system, no extra effort was needed since the inter-store transfers were simply included as another type of Merchandise Movement already accounted for in the data model.

Business rule storage and implementation is a popular topic at database conferences. Modelers are using a variety of approaches to model business rules. The first is to try to come up with a general business rule engine that allows for the specification of any business rule. A second approach is to limit the domain of the business rules and create a more explicit model that supports the specification of rules in a relatively precise context. As yet, the generalized rule approach seems not to have been as successful. Although there have been some attempts to create a business rule grammar, these attempts seem to be too complex for most modelers to be able to use. On the other hand, context-specific grammars have generally been successful. These engines can be as specific as a simple rule engine that automatically calculates the status of an event, to complex generalized workflow engines. Even state transition diagrams and workflow rules can also be stored as objects in the database. This is done by creating code generators to build the necessary PL/SQL packages automatically.

Using these higher levels of abstraction leads to fewer necessary tables and applications. Once these types of structures are built, you have greatly expanded the functionality of your system. If your rule-based system is generic enough to support Rule A and Rule B, it is highly likely that when the inevitable Rules C and D crop up, they can be supported as well without expensive changes to the data model. Many different types of business rules can be stored as data.

In purely relational systems, it is common for systems to include hundreds of reports using a different report for each specific business purpose. In an object-relational environment, fewer structures and fewer applications also mean fewer reports. Many reports such as Invoices and Purchase Orders may look different but use very similar queries. Other than changes in the labels and the fields displayed, the basic structure is very similar. In order to build the types of reports needed for object-relational systems, a sophisticated reporting tool such as the Reports component of Oracle Developer can be used to flexibly pass information (sorts, breaks and filters) and allow users to dynamically select fields. Creating these kinds of flexible reports can reduce the number of reports needed from hundreds to a handful. Although this smaller number of more complex reports may require more development skill, creating flexible reports has the added benefit that when the database changes, only one or two reports may need to be modified.

In many systems development efforts, you will find yourself building a structure with very similar functionality to ones built for other systems. Sometimes, you may be using the same type of structure multiple times within the same system. Not only can this type of thinking be applied to small reusable components such as a Calendar GUI widget, but it is also possible to build much larger and more complex structures with their own small associated databases and applications. One such example is a demographic information structure. The address and phone number of a customer is the same type of information as the address and phone number of an employee or internal organization unit. It is sensible to take such functionality and encapsulate it, thereby creating one large application component object (in this case, Demographics) that can be reused whenever necessary. If a development organization adopts this philosophy, over time, a larger and larger percentage of new application development can be supported through these Complex OBjects (COBS). In systems that we now build, 20-40% of the development effort is supported by pre-built COBs enabling us to focus all of our attention on the parts of the system that are unique.

A second example of a good candidate for COB development is a workflow system. Many organizations have similar workflows. On the surface, the workflow steps may have different names, but recognizing core similarities across different businesses is a key step in creating reusable application components. In one project, we noticed that the procedure associated with purchase order processing was similar to that of the project approval process. Initially, the client identified nine separate workflow processes. Instead of building nine different workflows in our application, we were able to genericize a single workflow engine that could be attached to any portion of the system. This was particularly useful when the client discovered that there were actually twelve different workflows. Using our generic model, this discovery required no additional work.

At Dulcian, we are now building reusable structures for Demographics, Comments, History, Security, Budgeting, General Ledger and Workflow. Currently, the implementation and support of Oracle Applications is very difficult. If Oracle Applications were built as a series of these types of bolt-together components (COBs), then we could greatly decrease the cost of implementing large applications.

If these object-oriented concepts can deliver on the promises described, why aren’t Oracle customers clamoring for this type of support from Oracle? The reason is that this way of thinking about system development is still too new. There are only a handful of relational database designers who have caught on to the possibilities available to them.

The object-oriented database community has already embraced this kind of thinking. A common question asked by object-oriented developers is "I need to do XYZ in my system. Is there an existing reusable component to accomplish this?" There are whole books written on this topic, such as:

• Analysis Patterns : Reusable Object Models by Martin Fowler (Addison-Wesley Object Technology: Addison-Wesley Object Technology Series, 1996)

Only recently have the ideas from this book started to filter into the relational database community.

• Data Model Patterns : Conventions of Thought by David C. Hay (Dorset House, 1995)

This book is an early attempt focusing on logical data models and doesn’t really include the full object-relational paradigm.

• The Data Model Resource Book : A Library of Logical Data and Data Warehouse Models by Len Silverston, William H. Inmon, Kent Graziano (John Wiley & Sons, April 1997)

This book still does not fully embrace the idea of reusable constructs.

Does this mean that even if Oracle builds the right product, no one will care?

The problem is that what Oracle has built is not useful enough. There are several problems with the existing structure of Oracle8 objects:

1. I need to build an object type for every object table. This means creating twice as many database objects as before. With ERDs, one entity usually translates to one table. In object-oriented constructs, one class should correspond to one object table and one abstract class to one database abstract class. Oracle has shackled database designers with a level of complexity that has no obvious advantages.
2. There are no dramatic performance improvements realized by using Oracle objects. OIDs should virtually provide the physical location of the object. This would mean that object joins should be an order of magnitude faster than traditional relational database joins. With Oracle8 objects, we have the same performance problems as relational databases with fewer tools for performance optimization.
3. I can base a table on an object type but I cannot add additional attributes to the table.
4. Once I have created the abstract type and instantiated an object table, I can’t modify the object type.

For all of these reasons, there is no motivation to move to the current object-relational Oracle products.

I do not foresee any serious competition from object-oriented databases. Objectivity and other companies in the industry have little marketplace visibility and lack the resources to compete effectively with Oracle. Even though Sybase and Informix have been working in the object-oriented development environment, I do not perceive these products as a threat either. The biggest threat might come from IBM or Microsoft. Microsoft is behind the object-relational curve but possesses the resources to catch up. IBM could enter the market at any time.

The core of object-relational thinking is the ability to incorporate greater levels of abstraction into our data models. This idea represents a major shift in the way that data modeling is done. Current relational databases are usually highly normalized models with little abstraction. Each "thing of interest" is instantiated as a relational table. As a result, systems frequently require hundreds of database tables and an equal number of screen modules and reports. The program modules are usually based directly on these tables with user workflow only instantiated through the way that the hundreds of screen modules interact.

A quiet revolution is taking place. A small number of data modelers are incorporating object-oriented thinking into their system designs. The enormous benefits of object-relational databases cannot be overstated. Systems that required 600 tables, 300-500 screen modules and hundreds of reports can now be built with a 50-table data model, a few dozen screen modules and less than twenty flexible reports. These OO-based systems deliver more functionality, are easier to maintain and will more easily support changes over time.

I believe that the development and performance improvements of a true object-relational environment are so great that the first major player to create a workable solution will have a large market advantage. I urge Oracle to move head full speed with development of products to support the object-relational paradigm.

The object-relational movement is clearly the right direction for the future of the database world. Oracle has the ability to take the intellectual lead in the industry and bring about a reengineering in the way we think about system architecture.

^©1999 Dulcian, Inc.