I turned 35 the day the Sybase Adaptive Server 11.5 (Sybase's new name for SQL Server) rolled out at IT Forum in New York, so you can kind of say we share the same birthday. Hundreds of people crammed into a large hall at the Javits Center to view the new "save the company" product from Sybase. However, in the end most people were even more confused about the state of database technology. The questions were: Why are we changing? What are the business drivers? And most important, what's the future model of the database?
Back to the press conference. Adaptive Server is moving away from the Universal Server model that is now such a big part of the Informix, Oracle, and IBM products. In lieu of the object/relational model, Adaptive Server supports, among others, specialty datatypes (SDTs). SDTs are datatypes for large and complex objects not supported by traditional relational databases. Adaptive Server provides access to these SDTs through its Component Integration Layer, using both ActiveX and Java Beans. In other words, Adaptive Server is moving to components, not true objects.
Let's not pick on Adaptive Server. The heart of the matter is the divergence from the relational model to the object-oriented model, or the pseudo-object-oriented models (such as SDTs). Like other new technologies, the interest in these new relational-something hybrids is driven more by database vendors looking to gain market share than users demanding the technology. What's more (and as usual), the vendors are doing this in their own little proprietary way. In fact, we're quickly getting to a point where you're going to find that it's much easier to swap out a body part than it is to swap out a database.
So what's the value in leaving the relational model? Clearly, object-oriented DBMSs can store more complex data using object features such as user-defined types, user-defined functions, large objects, OIDs, composite objects, multiple inheritance, and new query languages. (See "Universal Servers: The Players" in DBMS, July 1997, for the details on object/relational [Universal] databases.) Once all the smoke has cleared, however, you'll see that the object-oriented DBMS model really serves special niches, such as a providing a better solution for the storage and management of binary or very complex datasets.
Applications for object databases include repositories, multimedia data storage, or even Web site content storage. For instance, Computer Associates' Jasmine multimedia and Web development tool leverages an object-oriented model to store multimedia content. Object-oriented applications, such as those built using Smalltalk, Java, or C++, may leverage object-oriented databases to provide object storage.
The rubber really meets the road when considering the data management issues. When using traditional relational databases, developers separate the methods and the data; the object-oriented model combines data and methods together. The object-oriented model lets you process complex database structures quickly, because the objects existing on an object-oriented database are addressable through a unique global object identifier. This technology allows a speedy lookup of individual objects, because the data exists with the methods used to access the data.
Things are changing. Relational database vendors, such as Oracle Corp. and Sybase Inc., are getting better at database-bound application logic, such as stored procedures, database objects, and triggers. The object-oriented model itself provides better logical performance, however, relational databases have matured to the point where they can work around many of the performance limitations of the relational model. Considering these issues, the value of using the object-oriented model decreases. In fact, it's safe to say that there is little you can do using an object-oriented database that you can't do using a traditional relational database considering the state of the technology, although you use very different approaches.
The real considerations here are the application and the practicality of using one model over the other or mixing models using object/relational DBMSs. While you could force the object-oriented database model on any application (it's happened to me more than once), the tradeoff is the cost and risk of using a nonrelational database. Let's face it folks, "true" object-oriented databases, and even the object halves of the object/relational databases, don't enjoy the same level of tool support as their relational cousins. In order to realize the value of the object-oriented database, you must build the application using an object-oriented language. You should consider the object-to-relational alternatives as well. For instance, I can certainly create links from object-oriented languages to a relational database, making it appear as a set of objects, using wrapping mechanisms such as those sold by Rogue Wave Software Inc. or Persistence Software Inc.
I understand that the object/relational database vendors are making the argument that hybrid systems provide the best of both worlds. Although it's certainly true that you'll be able to access the same information both as a relational and object database, the same issues still apply. What's more, it's going to be difficult for database architects to create a schema that's both object and relational safe. Take my word for it, it's either going to be a good object database model and a bad relational database design, or vice versa. The notion that you can have your cake and eat it too is not yet feasible in the real world. There are always tools on the horizon to solve this problem, but for now I would recommend that you go one way or the other.
Those who argue for the unification of the object and relational model make two assertions. First, neither the relational nor the object model provides all the features we need to manage data. They argue that users need to leverage existing skills and knowledge gathered in the relational world while supporting a new generation of applications.
Second, relational databases continue to be the dominant data repository for the majority of application development projects. However, for the last 10 years objects have become the best way to build applications. The migration to the object model, either as pure OODBMS or through object/relational products, is supposed to solve the model-mixing problem.
While I see the points they are making here, I fail to see the practicality of it all, at least through 1998. To the points I made already, RDBMSs -- simply through the sheer number of implementations -- impose the least amount of risk. What's more, relational databases are finally moving to standards such as SQL-92. Finally, relational databases are the most scalable, supporting the latest server technology such as symmetric multiprocessing, multithreaded/multiclient client/server architecture, I/O reduction techniques, stored procedures, triggers, and performance modeling tools.
However, even the most tried-and-true relational bigots will concede that the relational model lacks the ability to model and efficiently manage complex objects such as images, documents, video, audio, animation, and composite objects (such as a nested bill of materials or time series). But most business systems either don't need these features or are able to add these features using existing relational database mechanisms. In addition, most application architects will find that the object-oriented model provides the most flexibility and modularity. However, the object-oriented model is not suitable for parallel query processing, does not support a standard, widely supported query language, and lacks a granular security system, even with the new generation of object/relational products.
The relational model describes a system by information, using relations, attributes, domains, and tuples. In contrast, the object-oriented model describes a system using objects that define identity, state, behavior, encapsulation, and inheritance. Objects are an abstraction beyond abstract datatypes (ADTs), merging data and variables into a single entity.
An object's identity, as the name implies, distinguishes an object from the other objects. The state defines the current value of an object. An object's behavior is a collection of methods and interfaces that responds to messages. Encapsulation hides the data from external entities, forcing data access to occur through methods. Inheritance allows objects to take advantage of features and functions of other objects. Object/relational database architects would map objects to tuple attribute values when mapping one model to the other, and the concept of normalization would be replaced by eliminating redundancy in the object-oriented model. What's more, views now in the relational model exist as object attributes and relational integrity constraints would have to map to type-based inheritance.
If object/relational databases are in your future, you need modeling tools, and there are a few available. Vendors working on modeling tools to support object/relational DBMSs include Logic Works Inc., Computer Systems Advisers Inc., and InfoModelers Inc.
Logic Works is working on a version (in beta at press time) of its object/relational modeling tool for universal server databases known as Universal Modeling Architecture (UMA). This tool provides database architects with a visual modeling environment, allowing them to switch between a relational and an object/relational database model. The idea is to model the database as an object-oriented or relational database, then switch the model depending on your requirements. UMA provides such subsystems as a Model Explorer and an Object Property Inspector. UMA is able to link to the object/relational database as well.
Not to be outdone, Computer Systems Advisers ships an object/relational modeling tool called Universal Modeler (see Figure 1). Like UMA, Universal Modeler is a graphical database modeling tool that lets you create object/relational models supporting the Unified Modeling Language (UML) standard. One of the key features of Universal Modeler is a Dual Canvas Modeling subsystem where data components from two different design elements or canvases are used to build an object/relational model. There are two types of canvases; a type canvas to support the graphical modeling of datatypes and functions, and a data canvas to support object/relational modeling.
While tools such as these will enable us to create object/relational models, architects still must deal with the complexities of it all. Chances are there will be a lot of model-dependent design considerations, such as how we handle integrity constraints in the relational model versus the object-oriented model. Thus, we end up supporting two instances of the same schema. Add the client and application requirements on top of that, and you're going to need a few more brain cells to work with the database -- but I'm glad to see that tools such as these are arriving.
It's easy to make the argument that the relational model is working just fine, and for all practical purposes there is really no need for most application development shops to switch at this time. The object-oriented model serves a niche, but its integration into the mainstream is a long way off. As an industry we tend to want to make dramatic changes every few years, and we tend to do so for the sake of technology -- not for the sake of the business needs. That's just too expensive, if you ask me. Well, maybe I'm just getting old and set in my ways.
Figure 1.
Universal Modeler is a graphical database modeling tool providing database architects with the ability to create object relational models supporting the UML standard.
David S. Linthicum is is the author of David Linthicum's Guide to Client/Server and Intranet Development from John Wiley & Sons (1997). He's a widely published author, speaker, and senior manager with AT&T Solutions Systems Integration Practice in
Chantilly, Virginia. You can email David at linthicum@worldnet.att.net.