Portals eNewsletters Web Seminars dataWarehouse.com DM Review Magazine
DM Review | Covering Business Intelligence, Integration & Analytics
   Covering Business Intelligence, Integration & Analytics Advanced Search

Resource Portals
Analytic Applications
Business Intelligence
Business Performance Management
Data Integration
Data Quality
Data Warehousing Basics
More Portals...


Information Center
DM Review Home
Conference & Expo
Web Seminars & Archives
Current Magazine Issue
Magazine Archives
Online Columnists
Ask the Experts
Industry News
Search DM Review

General Resources
Industry Events Calendar
Vendor Listings
White Paper Library
Software Demo Lab
Monthly Product Guides
Buyer's Guide

General Resources
About Us
Press Releases
Media Kit
Magazine Subscriptions
Editorial Calendar
Contact Us
Customer Service

Notes from the Giga Advisor:
Object-Oriented or Relational?

  Column published in DM Review Magazine
September 2001 Issue
  By Lou Agosta

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.


For more information on related topics visit the following related portals...

Lou Agosta is the lead industry analyst at Forrester Research, Inc. in data warehousing, data quality and predictive analytics (data mining), and the author of The Essential Guide to Data Warehousing (Prentice Hall PTR, 2000). Please send comments or questions to lagosta@acm.org.



Solutions Marketplace
Provided by IndustryBrains

Bowne Global Solutions: Language Services
World's largest language services firm offers translation/localization, interpretation, and tech writing. With offices in 24 countries and more than 2,000 staff, we go beyond words with an in depth understanding of your business and target markets

Award-Winning Database Administration Tools
Embarcadero Technologies Offers a Full Suite of Powerful Software Tools for Designing, Optimizing, Securing, Migrating, and Managing Enterprise Databases. Come See Why 97 of the Fortune 100 Depend on Embarcadero!

Online Backup and Recovery for Business Servers
Fully managed online backup and recovery service for business servers. Backs up data to a secure offsite facility, making it immediately available for recovery 24x7x365. 30-day trial.

NEW Glasshouse White Paper from ADIC
Learn to integrate disk into your backup system; evaluate real benefits and costs of different disk backup approaches; choose between disk arrays and virtual tape libraries; and build long-term disaster recovery protection into a disk backup system.

Test Drive the Standard in Data Protection
Double-Take is more affordable than synchronous mirroring and enables you to recover from an outage more quickly than tape backup. Based upon the Northeast blackout and the west coast wild fires, can you afford to be without it?

Click here to advertise in this space

View Full Issue View Full Magazine Issue
E-mail This Column E-Mail This Column
Printer Friendly Version Printer-Friendly Version
Related Content Related Content
Request Reprints Request Reprints
Site Map Terms of Use Privacy Policy
SourceMedia (c) 2005 DM Review and SourceMedia, Inc. All rights reserved.
Use, duplication, or sale of this service, or data contained herein, is strictly prohibited.