From: Jesper Larsson, Apptus Technologies

To: Editor

Date: 17 Oct 2004

I have found your work immensely useful in understanding database principles. I and a few colleagues have spent the better part of two years implementing our own data storage platform, observing those principles as best we have been able to, with very satisfying results. There are many details that I would be thrilled to discuss with you if you were interested, but right now I would particularly like to contribute my views on the relationship between the relational model and object oriented techniques. Since our system is implemented in an object environment, I have been forced to give this some thought, and I have come to think that you, in your (rightful) criticism of object databases, spend much energy on details while often skipping over the fundamental problem.

The object paradigm, as you frequently point out, is not a strictly defined model, and not based on mathematics. Instead, it is powered by analogies with the physical world. The user (or programmer) in an object environment grasps the entities of the system by using concepts from the real world as metaphors, visualizing the interaction between parts of the system as interaction between physical objects. The key to good object design is to choose the metaphors well: to decide which concepts are objects and which are not, which objects are actors and which are passive containers being passed around, which operations belong to which object, and so on. It is not quite true that "everything is an object". Actions are, for instance, not objects, and properties are really not objects either -- although both actions and properties may be carried or represented by objects. A badly designed system, with badly chosen metaphors, is full of objects with counter-intuitive behavior, and clumsy intricate code.

In AN INTRODUCTION TO DATABASE SYSTEMS (8th ed.) you exemplify object systems whose basic fault, in my view, is that they convey data as objects -- a metaphor that inevitably leads in the wrong direction. An object is a thing, has a location (and can thus be referenced through a pointer), can be copied, moved, and so on, and can frequently perform some sort of action. Furthermore, two exactly equal objects are still two distinct objects. Data, quoting your text, are given facts. None of the natural properties of objects make sense for data. Facts have no location (except for in the universe or not in the universe, i.e. true or false), and copying them makes as much sense as duplicate tuples in relations. Objects can indeed carry data in a number of ways: they can either be active entities that "know" certain facts, or they can act as media for facts (analogies to the notebooks and magnetic disks of the real world), but they cannot reasonably be perceived as data themselves.

The systems you describe insert data into the database essentially by creating objects. A well designed database system implemented in an object oriented environment may certainly create one or more objects as a consequence of insertion, which is perceived as allocating storage. But actually equating insertion with object creation is very strange. This is to confuse the data with its storage, a bad metaphor, and simply bad object design. If you will allow a loose analogy, these object databases seem not to be able to distinguish between a recipe collection and a refrigerator containing food that was cooked using the recipes. It is my apprehension that all the problems you note with object databases, including the two blunders of object-relational systems, can be derived from this confusion.

I find no conflict whatsoever between the relational model and the object paradigm. They belong to separate domains and it is hard to see how there could be a conflict. The concept of "object databases" is strange however. There are no "object word processors" for instance, so why should there be object databases? The user of the system has no reason to know about such implementation details, unless he or she is a programmer rooting around deeper below the surface than any secure system could allow. This is not to say that object techniques are not suitable when it comes to implementing database systems. On the contrary, they are just as powerful tools in this as in other programming tasks.

In some of your writings you touch on topics that are quite controversial among people who endorse object oriented techniques, such as for instance what inheritance should really mean (extension or specialization) and how it should be used. These topics are indeed relevant and should be discussed in their own right, and the programming field could certainly use someone clearing out the concepts like you are doing for databases. However, in my opinion the object wars are hardly relevant for database theory. The relational model is not really affected by the inheritance mechanisms (if any) of the data type system. I think that the impact of your work suffers when you take sides on these issues, since it distracts people from the principles of database theory, and distances people who find themselves on the other side. Also, as I am sure many people have pointed out, it makes you seem a bit careless when you allow some object mechanisms to be discredited (rightly or not) based only on how they are implemented in current products. This is like dismissing the relational model based on the fallacies of SQL. I think you would do better if you would stick to addressing the fundamentals.

C. J. Date Responds: Larsson's message is very good!  I agree with almost everything in it.  I'd just like to make it clear that my criticisms of objects and "object orientation" have always been aimed at their usefulness or otherwise in a database context and not necessarily in any other.  The following is a direct quote from the forthcoming third edition of the book by Hugh Darwen and myself on THE THIRD MANIFESTO (DATABASES, TYPES, AND THE RELATIONAL MODEL (to be published by Addison-Wesley next year): 

[We are] interested in this book in the field of database management.  We are therefore interested in—among many other things—the applicability of object concepts and technology to that field.  Please note, therefore, that all remarks made in this book concerning object concepts and technology must be understood in this light.  We offer no opinion whatsoever regarding the usefulness of object ideas in any other context.

Posted 2/4/05