Like winemakers, database management people don't favor pouring old wine into new bottles. Call them conservative, but given the mass of data stored in existing relational and mainframe databases, the tendency is to look askance even at new data going into new types of containers. That, in a metaphoric nutshell, is the situation faced by object-oriented database management systems (ODBMSs) as they seek to become mainstream products.
There isn't much question that the computing world has become object-oriented. Object-oriented programming is everywhere. It's difficult to find a new non-object-oriented development tool. Object-oriented design and analysis are now mainstream and quickly becoming the standard (thanks in part to the support for Unified Modeling Language developed by Rational Software Corp.). Applications created from distributed objects are the leading edge of technology, pushed by the powerful surge of the Internet. Will this seemingly overwhelming acceptance of objects play itself out for object-oriented database management as well? Three answers: yes, no, and maybe.
Yes, the acceptance of objects will impact the fortunes of ODBMS vendors, but they won't get exclusive rights to object orientation. No, ODBMSs won't take over the world of database management anytime soon. However, they may be able to use the Internet as a vehicle to get them into the mainstream of database management. Let's start with a real-world example that will highlight some of the issues involved.
Let's say you're starting a Web site for a catalog of designer clothing, and you want potential customers to have an experience that approximates what they would get if they went to the couturier's studio. You might have only 100 items in the catalog, but each one needs to be presented like a gem. The presentation must be hip, seamless (pardon the expression), and done in real time. If you have any doubts about the complexity involved, here's an abbreviated checklist of the specifications:
Think about it: We're accustomed to databases that contain the results of transactions or that passively record ongoing information. When was the last time you wrote a database application in which the database played a sophisticated role in the selling (in the broadest sense of the word)? In my example, database information provides static images, video, 3D graphics, voice, probably music, and traditional data all with the purpose of providing customized information and atmosphere to the site visitor.
This particular Web site, although relatively sophisticated in its requirements, is typical of what is envisioned for some kinds of electronic commerce. Complex is the operative word, because the site requires complex data (sometimes called multimedia or nontraditional data) and has considerable data complexity. Data complexity means that many of the data items are related to one another or are contingent on the values of other data. These two types of complexity, complex data and data complexity, are driving many of the current changes in database management.
As complex data management began to move into corporate applications, and above all because of the explosion of datatypes found on the Web, it became clear that simple storage of complex data wouldn't be enough. Several big RDBMS companies (Oracle Corp., Informix Software Inc., IBM Corp., and Sybase Inc.) began to look for ways to incorporate complex datatypes so that they could also be manipulated, parsed for content, validated, indexed, and searched.
The answer provided by the major RDBMS companies is now called a universal database (or universal server). This is a hybrid of a relational system that one way or another incorporates complex data as objects. These systems are more correctly labeled object-relational DBMSs (ORDBMS). The vendors have taken different architectural approaches, but what they do have in common -- and this is equally true for the ODBMS products -- is that they partner with other companies that provide the expertise and code that can manipulate complex datatypes.
It is true that ODBMSs have incorporated complex data from the beginning and can more naturally model the data as objects. However, stripped of the vendor hype, the situation with complex data boils down to this: Performance and scalability will be persistent issues and will probably depend on the details of architecture and quality of implementation. The level of sophistication in dealing with complex objects will depend on the partner's software far more than any inherent quality of the host database.
So many of the ORDBMS products have yet to come to market (much less be used in production systems) that it's way too early to say anything about relative performance or design merits. What can be said, however, is that in the area of complex data, the ORDBMS products should be competitive with ODBMS products.
Here is where ORDBMSs and ODBMSs part company. ODBMS systems may also use indexes to locate key objects rapidly, but once in the neighborhood, they switch to various navigational routines (such as hash algorithms) based on pointers that lead to other objects. This may resemble the old hierarchical database structures (such as CODASYL) or take on the appearance of memory-pointer systems similar to those used in the C++ language. In any case, the navigational pointers make it possible for an ODBMS to reach a large number of subsidiary or associated objects quickly.
The pointer-based lookups can be very quick even for complicated relationships between objects; however, the navigational systems of ODBMS products do have limitations. Sometimes the network of pointers can become so dense that they create performance and human comprehension problems. The ODBMS will make an effort to shield the user from complexity, but like most systems, the ability to tune and modify at fundamental levels may still be required for best performance.
It has also been one of the raps against the ODBMS products that they do not perform or scale as well as the RDBMS systems. This seems to be both true and untrue. Most of the ODBMS vendors will admit that, for very large databases with relatively static and simply structured data, the RDBMS approach will work best. They counter, however, with examples from the telecommunications, airline, and financial industries, where ODBMS engines are working with terabytes of data in mission-critical situations. The key to success in these cases seems to lie with the ability of ODBMSs to model the relationships between objects.
Most of the ODBMS vendors have reached a point where their database engines have gone through many revisions (typically five). As with the RDBMS vendors of a few years ago, emphasis is now moving away from the fundamental capabilities of the engine and into the applications, interfaces, and services that are delivered with the database engine.
Despite the speed of development in all things Internet-related, electronic commerce and its enabling technologies such as distributed objects are not going to emerge overnight. Most of the ODBMS vendors understand this and have devised strategies to increase their Internet presence incrementally by exploiting niches. In some cases this has meant partnering with other companies and licensing the database engine. Almost all of the vendors have embraced Java as an alternative to C++ and as an interface to the object-oriented database engine, and some vendors are following the path Java opens for Internet application development. Not all of the efforts by ODBMS companies are aimed directly at the Net, but you can get a good picture of their future with a quick look at the areas in which they are expanding.
Object repository. Object reuse is the leitmotif of object-oriented programming, but as the number of software development projects increases within an organization and the complexity of the relationships among objects grows, it becomes very difficult to track and coordinate use of objects. This is where an object repository becomes a vital tool. In a sense, an object repository is like an extended data dictionary that contains a great deal of information about the objects (metadata) and that also stores the objects (or class hierarchy code) itself. Using the object repository, the information and resources can be allocated to programmers with both version control and checks for object integrity. The better repositories actively support application development with visual tools and modeling of object structures. Given this approach, it makes sense that an object-oriented database system should be used to store objects, and most of the ODBMS vendors (notably Versant and Object Design Inc.) have aggressively developed repository projects with clients and partners.
Persistent object storage. In the pure Java scheme of things, Java applets are transmitted to the client program, executed, and then disappear when no longer needed. This works well enough in the finished product, but during development and in other circumstances, such as in some Java applications, it's necessary to save objects and their information -- to give them "persistence." This can be done via a couple of procedures such as serialization (saving to disk), but this approach lacks the flexibility and reliability of using a DBMS for storing the objects. ODBMS vendors -- for example, O2 Technology Inc.'s O2 ODMG Database System with Java Bindings, POET Software Corp.'s POET Java Software Development Kit, and Object Design Inc.'s (ODI) ObjectStore PSE -- have provided tools for Java developers that behave much like an object repository DBMS. Again, as a storage system for objects, the ODBMS products are a natural fit.
Front end to an RDBMS. In some situations where a large pool of data in relational systems needs to be integrated with object-oriented data, ODBMS systems are being used as front ends for the data. That's why almost all of the ODBMS vendors have provided object-to-relational links, either through native database drivers or ODBC. Some even support a kind of "passthrough SQL," where you can use SQL queries to fetch relational data that is then manipulated with the object-oriented layer of modeling and data management. On a more permanent basis, this is what Informix did when it purchased Ilustra Information Technologies Inc. and built that company's ODBMS technology into the Informix Universal Server.
ORB data manager. An object request broker (ORB) by definition manages the metadata about objects, which is why many of the ORB companies (including Visigenic Software Inc. and IONA Technologies Inc.) have partnered with ODBMS vendors (such as ODI, Versant Object Technology Corp., GemStone Systems Inc., and Objectivity Inc.) to store and organize the metadata.
Proxy server cache manager. Another use for ODBMS engines is in Internet proxy servers, which store the most frequently accessed HTML pages (and other objects) to reduce the amount of inbound traffic through an Internet firewall. As an example of this approach, Versant recently partnered with Spyglass Inc. to provide the ODBMS engine as cache manager for SurfWatch ProServer.
Application server. Given the large number of factors that are involved with applications, many people feel that application servers may be the real workhorses (and profit centers) of the Net. Whether it's a partitioning scheme or just an accommodation for the quirks of HTTP and HTML (such as stateless operation), it seems clear that all but the simplest of applications are going to need application services. Most of these services will need data management. Some of the ODBMS vendors -- for example, GemStone -- have revamped their business model to cast their database engine in a pivotal role for application servers. In GemStone's case, the company is tuning the ODBMS engine (in a product called GemStone/J) to be a high-speed OLTP system that uses GemStone's own Java virtual machine. In a similar vein, Objectivity recently formed a new division, Aziza, to produce services such as Web server management and content control.
The GemStone and Objectivity strategies represent a move by ODBMS vendors into the middle ground of the Internet -- the area between the client (browser) and the Web server --where they can run their databases and provide server-side features. Not only do many ODBMS vendors have the robust data management required, but their native object orientation also simplifies the development of application services.
Unfortunately this growing army of object-oriented programmers and designers doesn't connect well with the majority of ODBMS companies. With a few exceptions, ODBMS vendors are accustomed to working with the MIS departments of very large (Fortune 1,000) corporations. Their database engines are typically priced at $10,000 and up, with development seats running above $2,500. At this point, few of the ODBMS companies have the corporate culture or the financial resources to gain mindshare among the rising Internet generation.
This doesn't mean that the opportunity presented by the Internet will be missed and that the ODBMS message won't take hold, but rather that the message is not gaining the kind of popularity it might. Object-oriented database management could use a high-profile champion, but the realities are that revenue estimates for the ODBMS vendors are under $50 million even for the largest (ODI), and all of them together have less revenue than Oracle spends on advertising.
It's not hard to imagine what would happen if Microsoft were to adopt an ODBMS (okay, buy one) and tell everybody in Microsoft's inimitable way that this is how Web site data should be managed. But it hasn't happened yet. In fact, Microsoft seems to be taking a hands-off position on both complex data and data complexity. The Microsoft approach, roughly articulated as OLE DB, envisions a layer of middleware that can coordinate data coming from all kinds of traditional and nontraditional sources and supplying this data (through ADO and ADC) to applications.
Perhaps it's a good thing that ODBMS vendors don't have to compete directly with Microsoft. They've got their hands full dealing with the huge marketing efforts of the universal database companies such as Informix and Oracle. Between the fierce competition and the normally cautious adoption of new database approaches, ODBMS vendors will have to be very adroit and opportunistic. It's well known that a technology advantage is no guarantee of success, much less dominance. ODBMS companies think that they need to survive until the realities of complex data management that are inherent in the Internet bring the mountain to their Mohammed. Perhaps so, but in the history of American business, it's usually the movers of mountains that prevail.
See also the Sidebar, "What's Inside the ODMG-93 Standard" by Brian Jepson
What did you think of this article? Send a letter to the editor.