Unless you have the right tools, mixing objects and tables is like mixing oil and water.
A few years ago, the days of relational databases seemed numbered. Migration toward object-oriented (OO) databases seemed inevitable because they could better handle complex data structures and storage of binary content such as images, video, and audio. The application development community accepted objects and OO databases as the new paradigm for application development, along with OO development tools such as C++ and Smalltalk and the many specialized client/server tools. Today's reality, however, is much different than the experts guessed. Relational databases are still the dominant model in most development organizations, and relational databases such as Sybase, Oracle, and Informix still rule the world of client/server. Object databases simply haven't grown legs.
The resulting problem is one of model mixing. Today's client/server developers must learn how to use non-object relational databases directly from their OO development environments. Developers usually accomplish this by reverting to traditional procedural API-based programming to access the relational information they need, circumventing the power of OO development by not addressing data as objects, and causing a disconcerting shift in paradigms.
There is a much better way. As OO and relational models clash in modern system development, new methods let you communicate with relational databases as virtual persistent objects by adding object-to-relational translation and mapping layers. Moreover, a new generation of relational database servers stores information as objects. Let's look at object-to-relational solutions and the higher-level architectural problems that they solve, as well as object-to-relational translation products that let client/server developers live in the best of both worlds.
What will move relational databases into the next millennium are the simplicity of the relational model, the performance, and the number of existing systems that leverage the services of relational database engines. Relational databases are easier to design and understand than other database models, such as the OO, hierarchical, and multidimensional database models. Grouping data into tables is a logical process of creating tables and relationships. Developers don't have to worry about inheritance, encapsulations, polymorphism, or other OO tricks.
Performance of relational database engines is largely a result of the research and development dollars that database giants pour into performance enhancements. The relational model is inherently inefficient, although relational database engines gain an edge over other database architectures with new hashing schemes, buffers, cache, and the ability to bypass the overhead of the operating system. However, many performance benefits of today's relational database engines may be lost in the object-to-relational mapping layer that must exist between the objects and the relational tables.
Objects, on the other hand, let you model complex data structures and large amounts of binary information in a more natural way than with traditional relational database modeling. You can leverage the OO development model and features such as inheritance, encapsulation, and polymorphism to reuse as much code, data, and data structures as possible.
Thus if relational databases are here to stay but objects are a better architecture, developers must find a way to mix both worlds to create working, stable systems. This dilemma confronts not only developers but also the hundreds of tool and database vendors who want to carve out the best path between the dual paradigms.
There is a debate as to how developers and DBAs can best map data from a relational to an object world. Many people map relational tables (sometimes more than one related table) to classes. This process, however, can limit your ability to manage relational data as objects. Chris Date in his Third Manifesto writings (co-authored by Hugh Darwen) argues that domains, not tables, are the relational analog to an OO class. However, because RDBMS vendors offer such poor support for true domains, the practical reality is that users can deal only with tables.
To access relational databases, most Smalltalk tool vendors offer object-to-relational mapping mechanisms as well as relational wrappers. Object-to-relational mapping mechanisms let you link the properties of an object or group of objects to the properties of a relational database. (See Figure 1.) This displays the relational database as persistent objects inside the development environment.
Usually this means making a connection between a data element that exists in an object and a data element that exists in a relational database. You can map a single object directly to a single table, several tables to an object, or several objects to a single table. Once the mapping process is complete, any data modified in a mapped object will automatically modify any linked tabs or tables.
At the heart of this mechanism is the relational wrapper, the layer that sits between the objects and the database. The relational wrapper detects a change in the contents of an object and automatically generates the SQL to make the changes in the linked relational database. At the same time, it also detects changes to the relational database and moves that information back into the local objects. Developers access the database objects as they would access any other application objects. The object-to-relational model translation is transparent to both the developer and the end users.
VisualWorks, for example, provides mechanisms such as ObjectLens and Visual Data Modeler to remap relational databases into true objects that reside in a Smalltalk environment. ObjectLens is really just a set of Smalltalk classes that lets you access relational data as native Smalltalk objects.
If you think that this object-to-relational wrappering happens at the expense of additional overhead, you're right. Extra CPU cycles are required to make the translation, and performance can be an issue with database-intensive applications such as OLTP systems. This makes many Smalltalk tools that use relational databases (as well as other tools that translate from objects to tables) less desirable in environments for which performance is a critical success factor. However, Smalltalk systems perform well when used with true OO databases such as GemStone. There is no wrappering and thus no overhead.
Persistence from Persistence Software Inc. is a sophisticated middleware layer that restructures relational data into a set of common objects and hosts them as a virtual object server (which Persistence calls an application server). Persistence comes with two major components: a development tool and an object server. The development tool automates the object-to-relational mapping. The object server manages the object data integrity and optimizes the system.
Developers build applications using Persistence through the Persistence Object Builder and Snap-In Database Objects subsystems. The Persistence Object Builder generates the database objects that manage the mapping with the relational database. The Snap-In Database Objects provide an OO interface between the application objects and relational data using the Persistence Object Server. (See Figure 2.)
Building an application using Persistence is a three-step process: Model the data, generate database objects, and add application objects to drive the application. When modeling the data, you have the option of reverse-engineering the object model from an existing relational database schema. Once the mapping between the object model and the relational schema is present, you can generate the database objects. As you might have guessed, the Database Objects lets you access the relational database as objects. Having done that, you can add custom C++ code to the generated objects and add presentation objects and objects for business-related processing. This brings the objects from the data layer to the presentation layer. Once that's complete, all you do is compile and deploy the application.
Like Persistence, Enterprise Objects Framework (EOF) from NeXT Software Inc. links traditional relational databases to objects found in the NextStep application development environment. Enterprise objects are simply Objective C (NeXT Computer's OO development environment) objects mapped to a relational database.
EOF has two conceptual layers: the access layer and the user-interface layer, with links between them. The interface layer can display information on the screen. The access layer deals with the relational database, moving information back and forth from runtime objects. The access layer accesses the features of the underlying relational database (such as stored procedures), sends the proper SQL dialect, and provides performance enhancements. There are two portions to the EOF access layer: the database level and the adapter level. The adapter level translates physical rows found in the relational database into a dictionary (a proprietary repository), and the database level moves the information in the dictionary into enterprise objects.
DBtools.h++ from Rogue Wave Software Inc. is basically a set of C++ classes that lets you access any number of relational databases. DBtools.h++ deals with the relational database access for you, transforming rows and columns into true C++ objects for easy manipulation inside the application. DBtools.h++ supports both Unix and Windows.
The key feature of DBtools.h++ is its ability to provide C++ developers with a transparent OO view of the relational data. There is a base class known as RMDBTable that gives you a common access layer to the relational data, no matter what relational database is in use or where it resides. This consistent interface frees you from dealing with the dirty little details of relational database manipulation that you encounter when using traditional procedural database libraries such as the ODBC SDK or native database APIs.
DBtools.h++ provides a core library with just the basics. There are separate access libraries for the various database servers it supports. These access libraries are dynamically linked at runtime, which lets you swap database servers without relinking the application. Another product that provides OO C++ access to relational databases is Zinc DataConnect from Zinc Software Inc.
Specialized client/server tools such as Borland's popular Delphi, Powersoft's PowerBuilder, and Microsoft's Visual Basic take a different approach toward database access. Rather than "wrapper" relational databases as objects, they let you revert to a non-OO procedural world to access tables as tables and rows as rows.
Specialized client/server development tool vendors made an architectural decision not to wrap databases as objects. They gambled that most developers are more comfortable accessing data using traditional relational operations (SQL), and the objects serve a better purpose as an application-construction paradigm. As time passes, more specialized client/ server tool vendors will consider the concept of accessing relational data the same way they access native application objects. As hybrid databases become a more prevalent part of the landscape, relational database wrappers could become a standard option for most client/server development environments.
Hybrid databases can appear as both relational and OO databases, depending on the needs of the application. For example, OO databases are naturally better at storing complex data structures and binary information such as images, audio files, Web content, or even videos. To store the same type of content within a relational database, you might rely on the database's ability to handle binary large objects (BLOBs). In the relational world, BLOBs are opaque, meaning that information inside the BLOB is invisible to the database engine. OO databases solve this problem.
Some existing OO databases offer links to relational databases and provide realtime replication capabilities, including translation and mapping services. GemStone's RDBMS Interface, for example, bridges object-based data with relational data stored in Sybase or Oracle. You can set up the GemStone RDBMS Interface to replicate and map data from GemStone's OO database to a relational database automatically. When the OO database is updated with new information, a separate process automatically writes the same data to the relational database in the proper format. You can also set up the GemStone Interface to move information in the other direction, from relational to object.
The GemStone Interface uses a set of classes that, when added to the GemStone repository, lets applications link and translate data to relational database engines. The connection classes initiate interactions with the database using SQL. Other OODBMSs also support relational capabilities, including Object Design.
All eyes, however, are still on the "Big Three" relational database vendors (Oracle, Informix, and Sybase) trying to support objects. In February, Oracle introduced its long-awaited Universal Server, brought quickly to market because of Informix's early announcement of plans to release its own Universal Server. Oracle's Universal Server integrates Oracle7.3 with several special-purpose servers that include text, video, OLAP, message, spatial (geographic) data, and HTML. Although this is not the Universal Server previously promised for Oracle8, Oracle7.3 moves Oracle closer to the universal server concept.
Informix, on the other hand, intends to support objects through the acquisition of Illustra. Informix plans to integrate its relational capabilities with Illustra's OO and relational capabilities, and the company is now struggling to mix the code from the two products to make an aggressive release date. Informix announced a three-stage release of the Universal Server, and only the first stage - a gateway API - is shipping.
Sybase takes a slightly different approach. In a partnering relationship with Persistence Software Inc., Sybase plans to provide a middleware layer between the user and the relational database engine that handles the object-to-relational translation on the fly. This type of architecture will enable Sybase to handle objects sooner than the other database vendors, because the base relational engine remains intact. However, the exclusion of object processing capabilities from its base engine could hurt Sybase in the long run. It's difficult to solve the inevitable performance problems because the data must pass through layers.
There are other database vendors in the universal database world as well, including IBM, Microsoft, and Computer Associates (CA). IBM is already creating object extensions to DB2 that will support images, audio, and video. Microsoft will push OLE DB, an OO interface that treats images, documents, and email as objects that exist inside SQL Server. CA is promoting Jasmine, which uses an OO database built by Fujitsu that can replicate to CA's OpenIngres relational database.
In the long term, the movement toward relational and OO data mixing will occur at the back end. Universal databases give you a choice as to how to present data to the application. These databases will support legacy applications using the traditional procedural and relational access methods, and they will support OO features at the same time. Clearly, this is the future of object-to-relational integration.
| DBtools.h++ 1.0 Rogue Wave Software, P.O. Box 2328, Corvallis, OR 97339; 800-487-3217, 503-754-3010, or fax 541-757-6650; http://www.roguewave.com. | Delphi Borland International Inc., 100 Borland Way, Scotts Valley, CA 95066; 800-245-7367, or fax 408-431-4122; http://www.borland.com. | Enterprise Objects Framework (EOF) NeXT Software Inc., 900 Chesapeake Dr., Redwood City, CA 94063; 800-879-6398, 415-366-0900, or fax 415-780-3714; http://www.next.com. |
| GemStone GemStone Systems Inc., 15400 N.W. Greenbrier Pkwy., Ste. 280, Beaverton, OR 97006; 800-243-9369, 503-629-8383, or fax 503-629-8556; http://www.gemstone.com. | HyBase 3.0 Answer Software Corp., 20045 Stevens Creek Blvd., Ste. 1E, Cupertino, CA 95014; 408-253-7515 or fax 408-253-8430. | IDB Object Database 2.5 Persistent Data Systems Inc., P.O. Box 38415, Pittsburgh, PA 15238; 412-963-1843 or fax 412-963-1846. |
| Informix Universal Server Informix Software Inc., 4100 Bohannon Dr., Menlo Park, CA 94025; 800-331-1763, 415-926-6300, or fax 415-926-6593; http://www.informix.com. | NeoAccess NeoLogic Systems, 1450 Fourth St., Ste. 12, Berkeley, CA 94710; 800-919-6353, 510-524-5897, or fax 510-524-4501; http://www.neologic.com. | O2 ODMG Database System O2 Technology, 3600 W. Bayshore Rd., Ste. 106, Palo Alto, CA 94303; 415-842-7000 or fax 415-842-7001; http://www.o2tech.com. |
| Objectivity/DB 4.0 Objectivity Inc., 301B E. Evelyn Ave., Mountain View, CA 94041; 800-767-6259, 415-254-7100, or fax 415-254-7171; http://www.objectivity.com. | ObjectStore 4.0 Object Design Inc., 25 Burlington Mall Rd., Burlington, MA 01803; 800-962-9620, 617-674-5000, or fax 617-674-5010; http://www.odi.com. | Object Studio VMark Software Corp., 50 Washington St., Westboro, MA 01581; 800-966-9875, 508-366-3888, or fax 508-366-3669; http://www.vmark.com. |
| Persistence 3.2 Persistence Software Inc., 1700 S. Amphlett Blvd., Ste. 250, San Mateo, CA 94402; 800-803-8491, 415-341-7733, or fax 415-341-8432; http://www.persistence.com. | Persistence Framework Cincom Systems Inc., 2300 Montana Ave., Cincinnati, OH 45211; 800-543-3010, 513-662-2300, or fax 513-481-8332; http://www.cincom.com. | Phyla Mainstay, 591A Constitution Ave., Camarillo, CA 93012; 800-484-9817, 805-484-9400, or fax 805-484-9428; http://www.mstay.com |
| POET 3.0 POET Software Corp., 999 Baker Way, Ste. 100, San Mateo, CA 94404; 800-950-8845, 415-286-4640, or fax 415-286-4630; http://www.poet.com. | Polyhedra Polyhedra PLC, Queensway House, Queensway, Bletchley, Milton Keynes MK2 2ED, United Kingdom; 44-0-1908-366844 or fax 44-0-1908-366824; http://www.polyhedra.com. | PowerBuilder Powersoft Corp. (subsidiary of Sybase Inc.), 561 Virginia Rd., Concord, MA 01742; 800-395-3525, 508-287-1500, or fax 508-287-1600; http://www.powersoft.com. |
| Professional IDL 1.4 Persistent Data Systems Inc., P.O. Box 38415, Pittsburgh, PA 15238; 412-963-1843 or fax 412-963-1846. | Raima Object Manager (ROM) Raima Corp., 1605 N.W. Sammamish Rd., Ste. 200, Issaquah, WA 98027; 800-275-4724, 206-557-0200, or fax 206-557-5200; http://www.raima.com. | SQL*C++ MITI, 2895 Temple Ave., Long Beach, CA 90806; 800-366-6484, 310-424-4399, or fax 310-426-8910; http://www.miti.com. |
| Sybase System 11 Sybase Inc., 6475 Christie Ave., Emeryville, CA 94608; 800-879-2273, 510-922-3500, or fax 510-922-9441; http://www.sybase.com. | Universal Server Oracle Corp., 500 Oracle Pkwy., Redwood Shores, CA 94065; 800-633-0596, 415-506-7000, or fax 415-506-7200; http://www.oracle.com. | UniSQL/M Multidatabase System 3.0 UniSQL/X Database Management System 3.0 UniSQL Inc., 8911 N. Capital of Texas Hwy., Ste. 2300, Austin, TX 78759; 800-451-3267, 512-343-7297, or fax 512-343-7383; http://www.unisql.com. |
| Versant ODBMS 4.0 Versant Object Technology Corp., 1380 Willow Rd., Ste. 201, Menlo Park, CA 94025; 800-837-7268, 415-329-7500, or fax 415-325-2380; http://www.versant.com. | VisualAge for Smalltalk IBM Software Solutions, Old Orchard Rd., Armonk, NY 10504; 800-426-3333 or 914-765-1900; http://www.ibm.com. | Visual Basic Microsoft Corp., One Microsoft Way, Redmond, WA 98052; 800-426-9400, 206-882-8080, or fax 206-936-7329; http://www.microsoft.com. |
| VisualWave Parts Relational Data Interface VisualWorks 2.0 Visual Smalltalk Enterprise 3.1 ParcPlace-Digitalk Inc., 999 E. Arques Ave., Sunnyvale, CA 94086; 800-759-7272, 408-481-9090, or fax 408-481-9095; http://www.parcplace.com. | Zinc DataConnect Zinc Software Inc., 405 S. 100 E., 2nd Fl., Pleasant Grove, UT 84062; 800-638-8665, 801-785-8900, or fax 801-785-8996; http://www.zinc.com. |