Can database models take all types?

Software Magazine, Dec, 1995 by Don Burleson

Save a personal copy of this article and quickly find it again with Furl.net. It's free! Save it.
The ability to handle complex data types, with speed, is a goal for DBMS vendors today. Objects are the key to a variety of approaches.

The unveiling of E.F. Codd's relational database model more than a decade ago heralded an age when a database could be constructed from a firm mathematical foundation. The IS community and university professors were not shy to proclaim that database science shared the same plateau as hard sciences like physics and engineering.

Nearly 15 years later, we see users demanding that vendors of relational technology provide more functionality than the model is capable of. Meanwhile, the debate over which database model can best handle modern-day requirements continues.

On one side are object advocates. They claim object oriented databases are more robust than relational counterparts. On the other end of the spectrum are the RDBMS players, who are rushing to add object-oriented functionality and features to their offerings.

Somewhere in the middle are companies that have built combination object-relational database systems from scratch. These vendors argue that add-ons to either relational or object databases hinder performance and blunt features.

Even so, relational vendors continue to add object technology, and object database vendors add relational features. The latest movement in the trendy object database marketplace is to incorporate SQL interfaces. Several OODBMS vendors, including Objectivity Inc., Mountain View, Calif., and Ontos Inc., Burlington, Mass., have added SQL extensions to flagship products. UniSQL Inc., Austin, Texas, and Illustra Information Technologies Inc., Oakland, Calif., have found some success selling combination object-relational databases built from scratch.

Still, none of these approaches is ideal for MIS managers. Corporate database administrators will require extensive training to run any of the new environments. Programmers who have mastered SQL will now need to understand the object-oriented dialects of SQL.

Make Mine a Combo

After analyzing relational, object-oriented, and object-relational databases, Millennium Computer Corp., a Rochester, N.Y., consultancy, decided a combination DBMS was best-equipped to handle complex software development. Millennium develops multimedia management packages for software and systems vendors.

"First, we felt that no system [we built] could be successful without a lot of the power to store data, to define transactions and without the data integrity [characteristics] of relational systems," said Harry Ford, senior systems developer. The system also had to store large objects and multimedia data while supporting hierarchical data modeling and inheritance, Ford said.

Millennium installed UniSQL's object-relational DBMS early this year and is working on prototype multimedia applications that should be finished by the end of 1995, said Carl Hyde, director of business and market development.

Despite Millennium's early satisfaction with its combo database, many experts contend that the ad hoc query capability of SQL is inconsistent with the object-oriented principle of encapsulation.

In an object database, an object may only be accessed via its own methods, whereas a row in a relational database may be accessed via external SQL at any time. The question is whether accessing data only through predefined behaviors is advantageous. One of the selling points of a relational database is its ability to quickly formulate ad hoc queries with SQL, independent of the data.

Large users are focusing, for the most part, on how the relational players are adding new functionality to their architectures. Mike Ault, author of Oracle 7.0 Administration and Management, believes the future of database technology lies with hybrid object-relational databases like the Unix players hope to create.

"In this type of database, objects would be stored in the database, not just data items," said Ault. "For example, instead of storing a Blob [binary large object] and then having to provide an application to use it, or even a full 2Mb file and having to have a complete application outside of the database to play it, you would store a media object with the required support structure in a media object data type. By calling the media object via an SQL-like select statement, with the proper arguments, you would get a picture, video clip, sound clip or some combination that would automatically display, play or do both."

With a relational engine thrown in, he said, users would be able to employ a "looks like," "sounds like" or even an "is similar" clause to form groupings of media objects. "With the increasing CPU power available, not to mention cheap memory and disk resources, this type of object-relational database could soon be a reality," he added.

Stanford University's Penguin project, completed two years ago, was a landmark in the effort to integrate object technology into relational databases. "The Penguin project demonstrated that object views could be melded with relational databases. The project is credited by many observers with leading to the development of commercial products such as Persistence [from Persistence Software, San Mateo, Calif.]," said Arthur M. Keller, a senior research scientist at Stanford who oversaw Penguin.

"People are enamored with object technology systems, but things are not fine within object technology," said Keller. "Unlike a relational database, an object database organizes data according to the needs of the application; different object schemas would organize the same data in different forms."

This does not mean, however, that object databases are inferior, he said. "The object databases provide a far richer data representation and they also have benefits with client/server architectures. Relational databases tend to do most of their work on the server, while most object databases tend to do most of their work on the client. The Penguin project developed a way to even out this workload by caching relational data in the client. This reduces network traffic, since all traversals after the initial load will be very fast."

David Taylor, a consultant at Enterprise Engines Inc., San Mateo, Calif., and a pioneer in the object technology approach, is skeptical about relational vendors' ability to add object features. Adding object capabilities to a relational database requires much more than providing support for Blobs to hold pictures and other non-textual data, he said.

The real challenge in extending relational DBMSs, according to Taylor, lies in supporting composition and inheritance. While composite objects, such as bills of materials, can be handled using foreign keys to tie objects to their components, the speed of navigating these keys pales in comparison to using object IDs. A performance differential of 1,000-to-1 is not uncommon, said Taylor. This differential can be reduced through the use of pseudo-IDs -- typically unique integers with optimized indexes -- or by entering addresses as values. The first is an acceptable solution, but resulting performance is still a bit sluggish. The second is faster, but corrupts the underlying principles of relational databases.

Inheritance is an even greater challenge. The problem is that fields that appear in a single object may be defined at many different levels of an inheritance hierarchy, requiring numerous joins to reconstruct the data structure of any particular object. Anyone who has applied a relational DBMS to complex business problems knows that n-way joins destroy the performance of a relational system. Here, too, the navigational access of an object database can improve performance.

It may be several years before RDBMSs provide adequate support for richly structured object models. In the meantime, relational tables can be quite effective in storing the attributes of objects that have minimal inheritance and composition. They also offer the additional advantages of support for ad hoc queries, as well as suppliers who are much more established in the industry than their 00 counterparts.

For its part, Computer Associates International Inc., Islandia, N.Y., believes a "tight" object integration strategy is ideal for its new enhancements to Ca-Ingres. According to Marc Sokol, CA's vice president, product strategies, "An important aspect of the future of relational databases is support for abstract data types. We have looked at ways of enhancing a server to define spatial data types, multimedia and time-series data, but found that the best approach was to marry a relational database with an object database."

The same approach holds true for CA's work with Fujitsu on the latter's ODB2 database, said Sokol. The two firms signed an agreement last June, which calls for "integrating the ODB2 object manager with the Ingres physical engine," Sokol said. This kind of integration, he said, represents "a much better approach than adding an object layer to a relational database."

Harry Stahl, a partner with IISA Software, New York City, a maker of complex financial applications based on CA technology, thinks the vendor is on the right track. "We push the technology very hard, especially in the object technology direction. We use Ingres primarily because of CA-OpenRoad [application development tool]." IISA plans to use the Ca-Ingres/ODB2 DBMS as soon as it's available, Stahl said. A software development kit for the merged DBMS is due out this month and the combined system is slated to ship by mid-1996.

Stahl expects the CA-Fujitsu offering to allow IISA to "implement object-oriented applications with the OODB component while leaving the relational components intact. We have not been impressed with the hybrid architectures, and it takes a lot for a relational database to keep our attention."

Meanwhile, Oracle Corp., Redwood Shores, Calif., contends that users are better off buying relational databases with object extensions. "There is a major change going on today and customers are requesting databases that can manage all types of data," said Jerry Held, senior vice president for server technology.

Oracle recently brought out Oracle Multidimension, which can optimize both relational and multidimensional data, Held said. "The user community has asked us to incorporate other types of data management facilities. They don't want to use multiple databases for different data types. It is important that Oracle provide a smooth evolutionary approach to move from relational and expand to support objects all within a common database environment, without getting rid of [a user's] old environment." The plan calls for continuing to augment the Oracle DBMS "with capabilities previously found only in niche solutions such as object database and specialty decision support systems," Held said.

Jon Sigler, product manager for the FoxPro DBMS at Microsoft Corp., Redmond, Wash., said his firm takes another approach on extensions to the FoxPro database. FoxPro was recently renamed Visual FoxPro with the addition of object-oriented GUI development tools to the relational engine. Object storage capabitities will be left to the OODBMS vendors, Sigler said. "Microsoft's strategy is based on OLE and communications between a three-tiered architecture. The middleware will allow users to plug into numerous back ends, regardless of whether the engine is relational or object-oriented. It would be similar to ODBC, but would use a middle layer to contain the business logic."

Claudio Girolami, president of Softech Information Systems Corp., Rochester, N.Y., specializes in migrating legacy systems from mainframes onto distributed Novell servers using FoxPro. "We use FoxPro because of its great speed, and we find that it performs faster than the legacy system of the mainframe." The company plans to evolve to Visual FoxPro, primarily because of the "promise of inheritance and ability to create class libraries. We see Visual FoxPro as being as strong as C++, and are looking forward to creating our own classes and methods," Girolami said.

At Informix Software Inc., Menlo Park, Calif., "We are focused on building extensions into our engine rather than adding an object wrapper," said David Watson, product marketing manager, servers and connectivity. Said Watson, most of the top RDBMS vendors are targeting three areas: multimedia extensions, decision support and online analytical processing (OLAP), and object-oriented extensions, such as adding methods.

"Our approach of building extensions into the engine is more comprehensive than these single strategies," claims Watson. "We feel that the object wrapper approach suffers with scalability problems and that other approaches, such as adding object management extensions, have problems such as the inability to index on user-defined data types." Informix, he said, "is basing its evolution on the SQL3 standard, specifically in user-defined databases and by allowing pointer-based navigation using object Ids within the database. We also plan to support methods based on the persistent storage module standard of SQL3." Only IBM has joined Informix in promising to support the SQL3 standard.

Watson is also skeptical of the alliances between object database vendors and relational vendors that call for incorporating object technology into the RDBMSs. "We have a close relationship with [OODBMS vendor] Versant [Object Technology Corp., Menlo Park, Calif., and we market Versant as a part of our NewEra [development tool family]. However, we would not consider trying to incorporate Versant into our engine."

Hybrid database vendors claim not to be threatened by the plans of their considerably larger relational brethren to add object technology to their offerings. "It's beyond belief to hear a vendor say that they are going to meld a relational database with an object database and create a whole new product," said Melissa Webster, UniSQL's vice president of marketing. "These are two completely different architectures and they would have to completely rewrite the engine from the ground up."

Webster says RDBMS vendors are moving in the right direction by adding object extensions, but claims a system built from scratch is the choice solution. "UniSQL was the pioneer in combining relational and object technologies. We combined the strengths of relational databases and augmented them with object support three years ago when both camps were saying that relational and object databases were like oil and water."

Will the relational model continue to evolve, or will it be displaced? It's clear that relational vendors are extending their offerings in the hopes of creating a "universal" database that will provide a repository for all types of data. Even if such universal engines can be created, the question remains whether they can drive technology in the next century, or whether they'll be displaced by specialty databases targeting specific data types.