At a recent conference, a Giga client expressed a concern to me. He said, "Object-oriented programmers have a strong voice in our installation; they are using object-oriented technology as an excuse to question why we need the data group, which I head, to help with integration. They say that objects will do that for them. Is the relational database approach a valid foundation for system integration, and where does the relational approach support or intersect with object-oriented technology (OOT)?"

First things first. Both data and methods (processes, procedures) are required for a complete application. The data without the method is meaningless; the method without the data is empty. Both are required. So what is the issue? The issue is that we really are dealing with different paradigms in comparing object-oriented programming and relational database technologies.

An object includes both methods and data – but what happens when there is a vast supplier or customer database or parts database? Presumably, the data cannot be cached in main memory at all times, and it must be persisted – that is, stored – for reasons of both performance and data integrity. That is where the relational database with object-extensions comes to the fore.

Isn't it foolish to try to decide between the data and methods (or functions) of processing data? In many instances, both objects and relations are needed. In fact, the object- oriented paradigm can be created out of the relational one by designating relational entities as objects and stored procedures or database functions as methods. While the mapping is not perfect, the result is a near paraphrase of the functionality. As usual in computing, there is latency – difference in speed and type of process between the object-oriented run-time process and the storage paradigm by which the process is preserved (stored).

In the final analysis, a conversation between the object-oriented programming team and the data management team results in exercises such as mapping entity- relationship terms to UML (unified modeling language) to facilitate translation and cooperation: entity is class, relationship is association, structural constraints are multiplicities, specialization is classification, and roles and attributes are the same in both classes.

It seems like a false choice to me to try to decide between objects and data – what would the object methods process if not data? Where is the data persisted and stored when it is not being processed? A relational database entity is an object without methods. When the methods are added by way of stored procedures or other functions, you are half way to object-relational technology. Of course, for certain kinds of real-time embedded systems in airplanes, cell phones or complex processes in power plants or pipelines, the importance of data storage is significantly less.

Because the client then asked for something to read, I recommended Object Solutions: Managing the Object-Oriented Project by Grady Booch. Booch has excellent insight into processes that are data-centric versus those that emphasize other important components such as the user interface, distributed, legacy systems, computation-centric, real time and architecture- centric. In fact, a good way to break out of the impasse that mistakenly opposes OOT to relational technology is to look at some of the other perspectives, such as architecture and distributed systems, where both approaches are needed in differing degrees.

I am just guessing, because the information available in the conversation was limited, but the problem or issue could be that the OOT team wants to buy an object-oriented database such as UniSQL, ObjectStore, Illustra or Omniscience. That is not necessarily bad if there is a specific application that requires one of these niche databases. However, these databases will not be suitable for a general commercial business application such as vendor management, parts inventory or customer relations. The head of the data group, with whom I was having the conversation, will have to communicate the trade-offs to the team at large. For example, in 1996 Informix acquired Illustra, and all the other major database vendors (IBM, Oracle, Sybase) began moving toward object-relational products. Then, a consensus on the object-relational data model features emerged in the SQL-3 standard, and all the major database vendors (IBM, Oracle, Sybase, Informix) have released object-relational products that reflect this consensus.

When all is said and done, the relational paradigm is still the dominant design in database management systems for commercial business applications. That means all the other alternatives (and paradigms) such as object databases, XML databases and in-memory databases will eventually be (and in some cases have already been) assimilated to the relational model. These other databases will still have relevance in special-purpose niche applications where they are needed because of their special capabilities – such as XML in publishing, object-oriented in engineering complex artifacts and in-memory in Web caching – but they are unlikely to break out of their respective niches to attain widespread commercial application in the average business process.

Register or login for access to this item and much more

All Information Management content is archived after seven days.

Community members receive:
  • All recent and archived articles
  • Conference offers and updates
  • A full menu of enewsletter options
  • Web seminars, white papers, ebooks

Don't have an account? Register for Free Unlimited Access