e, it was impossible to do true queries. ODBMSes were not scalable and required huge amounts of memory.
Many vendors backed away from the early ODBMS products. According to Jeff Jones, IBM's program manager of the data management marketing group in Santa Teresa, California, IBM tried to use a pure ODBMS as the embedded database in Visual Warehouse. It licensed Object Design's ObjectStore for the first releases of the product. However, performance was so poor that IBM replaced it with DB2 in later releases and wound up adding features and reducing the amount of code.
Experiences such as this made the ODBMS little more than a laboratory curiosity. Except for some niche markets such as telecommunications, ODBMSes remained, even for their supporters, a technology in search of a problem to solve. This is where conventional wisdom froze. As ODBMS technology and the needs of users changed, the conventional wisdom was that ODBMSes were inherently flawed. But they a
ren't. Let's take an updated look at six bits of conventional wisdom about ODBMSes. (For more information on ODBMS products, see the Software Lab Report "The Object is to Manage Data".)
1. ODBMSes Are for Niche Markets
This is almost a truism. In some sense, every database product is designed for a
niche market
. According to the Meta Group, the relational DBMS (RDBMS) market in 1995 was $2.5 billion, while ODBMSes had only a $250 million market. Relational databases currently make up about 90 percent of the financial market.
However, relational-database advocates do not often mention that only 12 percent of all business-processing data is on RDBMS products. Most of the world consists of old file systems and legacy data. By this measure, the RDBMS is a niche product. RDBMSes are ideally suited for scalar data such as names, address fields, and amounts. They are extremely stable and fast. It is possible to execute complex queries. These features make RDBMSes ideally su
ited for business and financial applications.
However, the RDBMS model is based on sets of rows with columns, and it can be seen as 2-D. The object model allows for the complex modeling of objects as they exist rather than trying to squeeze the objects into a 2-D structure. The growing interest in multimedia applications and the Internet has created new markets for ODBMSes.
From that perspective, ODBMS technology is ideal for the most popular applications. The huge growth of the Internet, video games, multimedia applications, and the development of distributed databases that do not lend themselves to the relational model are bringing renewed attention to ODBMS. Because Java is an object-oriented language, Internet applications are particularly suited to object databases. Because there are now de facto and de jure standards for object technology, you can deploy an application to the whole world.
Telecommunications is a good market for ODBMSes. We found several vendors whose products model and
control communications networks in real time.
2. ODBMSes Have No Theoretical Foundation
This piece of the conventional wisdom is also true (although less so than in the past). But it ignores history. For example, calculus produced correct and usable results for over a century without a proper theoretical foundation. Newton's infinitesimals were just plain nonsense, and everyone knew it. The real question is whether an object database works for a given application, not whether it has a scientifically approved theoretical framework.
Relational databases have the advantages of a strong mathematical model and a set of well-developed tools for designing databases. ODBMS systems lack a firm theoretical foundation and have no well-developed design tools. Chris Date is particularly critical of this lack of theory in object databases. He and Huge Darwen wrote "The Third Manifesto," which goes into detail on this point.
But so what? A theory lets you design tools. For example, an RDBMS desig
ner can use an entity-relationship diagramming tool to mathematically verify that his or her design is in third normal form. An ODBMS designer does not even have a concept similar to normal forms for his or her objects. Ultimately, the issue of tools is disappearing. For example, Computer Associates' Jasmine has a very good development environment.
3. A Relational Database Can Do Objects
No, it can't. If a vendor says it can, it is lying to you. Let's look at terminology.
You can classify database models as hierarchical, network, relational, object- relational, extended-relational, and object. Nobody cares about the hierarchical and network models anymore -- the relational model replaced them. A relational database represents entities and relationships in tables that contain rows, that contain columns, and that contain scalar data-type values.
Nobody has any trouble telling apart products based on hierarchical, network, and relational models today. But when they were first introduce
d, programmers tried to make relational products behave exactly as a file system. It can be done, but at fantastic performance cost. Dare we say it? We needed a paradigm shift to appreciate the power of a relational system. As Jeff Jones points out, "The shift from IMS [an IBM hierarchical database product] to SQL was pretty painful, because you also had to learn a new paradigm along with the new software. No one really wants to do that again with object databases."
Today, everyone is confused by the extended-relational, object-relational, and (pure) object databases. The biggest problem that the pure ODBMS has is its name. The term should have been
objectbase
instead of
object database
, because the goal is not to store, manipulate, and retrieve data within an object, but to store, manipulate, and retrieve objects themselves. Relational databases allow elaborate queries on simple data. Pure object databases allow relatively simple queries on complex data.
Object-relational products t
ry to have both relational data and objects stored in one system. The difference is that the objects are added as an afterthought or a shell around the database rather than integrating them into the database engine. If you cannot tell the query optimizer, the indexing, and the database-engine functions how to handle the new data types invisibly to the user, they are not integrated.
IBM and Oracle have object-relational offerings for their relational databases. To put it bluntly, the result is like a fish with feathers -- it can neither fly nor swim very well. To quote Esther Dyson, "Using tables to store objects is like driving your car home and then disassembling it to put it in the garage. It can be assembled again in the morning, but one eventually asks whether this is the most efficient way to park a car." (
Release 1.0
, September 1988)
Chris Date advocates an extended-relational model, and Informix implements it with DataBlades. In 25 words or less, an extended-relational database allow
s the creation of more complex user-defined data types and integrates them into the database. But the operations are still relational, and data still exists in tables. This is a good approach for a particular class of common problems and should replace many of the existing simple relational databases, which do not need a full object model. You could use an extended-relational database for employee records with fingerprints or a photograph but not for a multimedia library with interactive objects or for a model of the stock market.
A pure object database has methods, classes, and other things that characterize the object-oriented model in the database engine. Objects are active. Relational data is passive, and you need a host program to do something with it.
Don't confuse ODBMSes with extended-relational and object-relational products. They are designed to solve a different set of problems. To paraphrase Esther Dyson again, using a pure object database to store relational data is like keeping auto
parts fully assembled into cars and disassembling the fleet when you need to count the screws you have in stock. One eventually asks whether this is the most efficient way to conduct an inventory.
4. ODBMSes Have No Standard Language
SQL is literally the only NCITS/ISO standard programming language for databases and is relational. NCITS, the National Committee for Information Technology Standards, was formerly the ANSI X3 committee for information-processing standards before its name changed in January. (NCITS is pronounced "insights.")
The argument is that having a standard language has made relational databases less expensive to build and much more portable across products and platforms. ODBMSes have no such standards, so you have to work with strange proprietary languages and learn a new one each time. Therefore, the argument goes, they are not good for serious development work.
This wisdom is de jure true today, but not de facto true. In the next few years, it may be completely
false.
While the ISO standards process was going on (see the sidebar "SQL3's Object Extensions"), the Object Database Management Group (ODMG), a group of ODBMS vendors, began trying to set standards for object databases outside the ISO framework. The ODMG produced a standard for an ODBMS query language in 1993 under the name OQL.
The Object Database Standard
, edited by Rick Cattell (ISBN 1-55860-302-6, Morgan-Kaufmann), shows what version 2.0 of the project looks like. Sixteen vendors agreed to support OQL.
5. ODBMSes Are Not Scalable
Completely false. Yes, scalability was a major problem with early ODBMS products, because many of them could run only in main memory. If the machine went down, so did your database.
You can get small, medium, and large ODBMS systems. Small desktop systems include Poet. Medium enterprise-level systems include Versant, ObjectStore, and Jasmine. Large systems are at least terabyte-size and include a petabyte-size Objectivity DB project at the Euro
pean Laboratory for Particle Physics (CERN).
These are real databases, with security, backup, and recovery features just like any RDBMS.
6. Object Query Languages Are Hard
This one's true. David Beech of Oracle submitted a paper to the H2 committee in March 1996. It gave a simple SQL3 schema using some new SQL3 declarations. The schema dealt with street addresses. The reader had to submit queries to answer a set of questions. Nobody on the committee submitted correct queries. These are people with a lot of experience with SQL. If they had problems, what will the average programmer do?
Beech said: "Querying may be fun in the era of SQL-92, but will it still be so with SQL3? In the course of working on the SQL3/ODMG paper, I was obliged to become more intimately acquainted with SQL3 queries than I had ever been before, and I was surprised by some of the things I learned.
"This raised in my mind the question of whether the language has perhaps become too difficult for its intende
d users, which could mean that the potential simplification offered by some of the OQL features is not merely an optional luxury, but is an absolute necessity.... Even if committee members solve them all correctly, it may seem that SQL users as a whole (the majority of whom are as yet unborn) would find the language error-prone and should therefore, if possible, be spared some of the problems and lengthy education.... Its [failure to answer the problems] would show that even spending 40 hours with the query parts of the SQL3 foundation document may not be sufficient training for someone with 20 years' acquaintance with SQL and semiformal standards to be relied upon to write correct SQL3 queries."
The New Conventional Wisdom
Object databases are back. They are still maturing, still misunderstood, and still hard to use. But they are gaining acceptance, thanks to the explosive, and somewhat speculative, growth of the Internet and multimedia applications.
Relational vendors that are making noise about object features added to their products are like the nonrelational vendors of several years ago who made false claims about relational features. The object-database model and the relational model coexist because they are designed for different applications.
Put another way: Don't fit the data to the database. Choose the database type and product based on what kind of data you have and how end users will access it. For example, a real estate firm that wants to do a database of home listings should choose a relational database if it will include only descriptive data, such as addresses and phone numbers. If the listing will include floor plans, text, or photographs, an object-relational database may be a better choice. If the database will include 3-D drawings, filmstrips, an animated walk-through, or a variety of complex data types, you should consider an object database. And if you do decide to choose an object database, be sure that it will support the kinds of queries end users will be makin
g.
A final word of warning: The shift to object technology may be hard because of the heavy financial and human investments in relational technology. Projects involving an object database will take longer with an inexperienced staff. But even if you're dealing with experienced object-database people, the project will take longer and be more costly because of the inherent complexity of object technology. If you're prepared for that, you're prepared for an object database.
Where to Find
Computer Associates, Inc.
Islandia, NY
Phone: 516-342-5224
Internet: http://www.cai.com/products/jasmine.htm
Debunking Object-Database Myths
