Advertisements for oneself are usually pretty offensive. Just this once, however, I crave your indulgence. Regular readers of Database Programming & Design will know that, along with my colleague Hugh Darwen, I've been working for some time on something we call The Third Manifesto--the Manifesto for short. The Manifesto is, at long last, ready for general publication; in fact, barring unforeseen delays, the book version should be available by the time this column appears in print. Therefore, in this column, I thought I'd try to give you some idea of what the Manifesto is all about and what we're trying to achieve with it.
The Third Manifesto is intended as a blueprint (or a candidate for such a blueprint, at any rate) for the future direction of data and database systems. More specifically, it consists of a model--one that's meant to be abstract, formal, robust, rigorous, and well defined--that can serve as a basis for the design and implementation of DBMSs, including in particular, object/relational (O/R) DBMSs (also known as universal servers). An extended version of that model, which is also described in detail in the book, provides a comprehensive and detailed proposal for type inheritance support (a topic about which there seems to be a certain amount of confusion in the industry at large, at least at the time of writing).
Despite the fact that several O/R products already exist, it seems to us that those products lack a truly solid theoretical foundation--one that will stand the test of time. In particular, most of them seem to have committed at least one of what we call "The Two Great Blunders" (and some have committed both). Perhaps I should immediately add that we don't think O/R systems are just a fad, soon to be replaced by some other briefly fashionable idea; on the contrary, we think an O/R system is in everyone's future--a fact that makes it even more important to get the logical foundation right while we still have time to do so. And that's what the book is all about.
The key technical insight underlying the Manifesto is a pretty simple one, and I've discussed it at some length in earlier installments (see, for example, my October 1994 column "Oh Oh Relational ... "). In essence, it's simply this: We need do nothing to the relational model in order to achieve object functionality. (Nothing, that is, except implement it, something that doesn't yet seem to have been tried in the commercial world.) To be more specific, it's our position that the relational model already provides the capabilities we need, thanks to its support for domains. To elaborate:
• The sole useful (and arguably novel) aspect of "the object model" is the ability for users to define their own data types, and that facility is provided by domains in the relational model.
• Hence, a relational DBMS that supported domains properly would be able to deal with all those "complex" kinds of data that (it's often claimed) object systems can handle and relational ones can't: time-series data, biological data, financial data, engineering design data, office automation data, and so on.
• Therefore, a true "object/relational" system would be nothing more nor less than a true relational system--which is to say, a system that supports the relational model, with all that such support entails.
In fact, we would go further: We would suggest that a database that isn't relational isn't really a proper database! After all, what's a database? We would argue that it's a repository, not just for data (despite the name "database"), but for facts: true statements, that is, regarding the enterprise or activity to which the database in question pertains. And what's a fact? It's what logicians call a proposition--more precisely, a proposition that evaluates to true, not false (strictly speaking, a "false fact" is a contradiction in terms). So a database is, abstractly, just a collection of true propositions. And relational theory supports this view of databases very directly, because tuples in relations (rows in tables, if you prefer) are directly interpretable as such true propositions.1 Conceptually, therefore, a database must be relational, by definition.
It follows that the term "object/relational" is really not very apt--but we're stuck with it (probably), and in any case the term "relational" has become so devalued that it's impossible (probably) to restore it to its proper and rightful meaning. On the other hand, terms such as "extended relational" are extremely inappropriate and inaccurate--not to say misleading--and they need to be resisted, firmly.
Given the opinions I just expressed, you won't be surprised to hear that the Manifesto does stay very firmly in the relational tradition. Indeed, we believe the Manifesto can serve among other things as a definitive statement of just what the relational model itself currently consists. (The relational model itself has grown somewhat over the years and will doubtless continue to do so.) We certainly aren't trying to supersede the relational model in any way; rather, we're using that model as a foundation and building on it. Thus, we regard our Manifesto as being very much in the spirit of E.F. Codd's original work and continuing along the path he originally laid down. We're interested in evolution, not revolution.
Now it must be said that the Manifesto itself is (deliberately, though perhaps unfortunately) rather terse and not all that easy to read or understand--which is why we decided to produce a book-length version, of course, with plenty of examples and supporting material. The book's full title is Foundation for Object/Relational Databases: The Third Manifesto (Addison Wesley, 1998). And there's a subtitle, too: A detailed study of the impact of objects and type theory on the relational model of data, including a comprehensive proposal for type inheritance--quite a mouthful, to be sure, but we wanted to give as clear an idea as we could of the book's scope, right up front.
The book is arranged into four parts and a set of appendices. The following brief synopsis focuses on what we see as some of its major features:
• Part I covers some important preliminaries: background, objectives, guiding principles, and so on, including in particular an explanation of The Two Great Blunders.
• Part II contains the Manifesto itself (a "no frills" version, consisting of just 10 or so pages). It also includes a definition of a new and simplified relational algebra, which we call A; among other things, it shows how functionality equivalent to that of Codd's original algebra2 and that of EXTEND and SUMMARIZE--which were added later3--can all be achieved with just two operators. And it also describes a language, which we call Tutorial D, that realizes the ideas of the Manifesto in concrete syntactic form and could serve as the basis for a practical implementation.
• Part III consists of a careful point-by-point examination and exposition of the ideas of the Manifesto, with copious examples expressed in Tutorial D and detailed explanations.
• Part IV is in some respects the most original part of the book. It consists of a detailed and comprehensive proposal for a model of type inheritance, with (again) numerous examples and much supporting discussion. Our model includes support for single and multiple inheritance and for scalar, tuple, and relation inheritance. Note: We're not necessarily claiming that our ideas here are 100 percent novel, but we aren't aware of a comparably complete proposal in the literature.
The appendices include an extensive and annotated set of references, comparisons between the ideas of the Manifesto and those of SQL3 and the ODMG, an examination of something called "subtables and supertables," a discussion of certain related database design issues, and several other items.
I'd like to conclude this shameless advertisement with another little squib I composed recently. As with my previous effort in this vein,4 I make no claims of great artistic merit for this piece--it's just something I scribbled down over breakfast one morning--but it does provide a not-too-serious summary of some of the major themes of the Manifesto, and an important message does lie not too far below the surface. I call it "A Call for Common Sense":
Objects and relations: Can they work together? An interesting question! It all depends on whether We first agree on what Objects per se might be There's surely no consensus-- In fact, it's hard to see Why so much current int'rest Is focused on the notion Of object databases. The famous magic potion Of Astýrix the Gaul Makes just about as much sense (At least it seems to me) As "object data." Hence What we really need to do Is figure out precisely Just what the real problem is And then attack it nicely By thinking very clearly Not being swayed by fashion Though truth to tell it's tough: Thought oft gives way to passion. (Sigh) Contemplating clearly Is very hard to do! My thoughts are often muddled My guess is yours are, too. By dint of application, though, My good friend Hugh and I Have tackled this great question And grappled with the Why Of objects and relations And (more germane) the How And so we're pleased to offer you Our Manifesto now. The Manifesto (sadly) Is many pages long And so I've tried to précis it In this, my little song. Careful and exhaustive search Through all the object hype Reveals a single good idea-- The Abstract Data Type. Of course, we want to follow The principles of Codd: Be relationally pure! It would be very odd Not to support relations At this stage in our history And so the issue facing us (Some might say the mystery) Is this: What do we need to do To "tables" (if you please) That they might thus be able To deal with ADTs? The answer is: Do nothing! This answer I explain By claiming that an ADT Is simply a domain! That is, the single good idea Of objects--ADTs-- Can be combined with tables As leaves combine with trees. Codd's model of relations Already had support For object functionality! The trouble is, none thought To implement that model. And so we never got A product that delivered More than a part of what Codd's vision should have led to. Now 20-some years later The pundits are proclaiming Relations cannot cater To "complex" applications And "high performance" needs. And yet it's all so silly!-- As anyone who reads The Manifesto clearly Will surely understand. No: What we really need to do To do the job at hand Is get back to our future, To our relation roots; Build a true RDMS And hence enjoy the fruits Of true relational support Including ADTs. So: Read the Manifesto And do the right thing--please.
References
1. Darwen, H. and C. J. Date. "Introducing ... The Third Manifesto." Database Programming & Design 1(8): 25-35, January 1995.
2. Codd, E. F. "Relational Completeness of Data Base Sublanguages." R. Rustin (ed.): Data Base Systems: Courant Computer Science Symposia 6. Prentice-Hall, 1972.
3. Date, C. J. "What's in a Name?" Database Programming & Design. 11(5):19-20. November, 1992.
4. Date, C. J. "The Art of the Possible." Database Programming &
Design. 6(9):17-19, June 1996.
C. J. Date is an independent author, lecturer, researcher, and consultant specializing
in relational database systems. His most recent books are A Guide to the SQL Standard (4th edition,
1997) and Foundation for Object/Relational Databases: The Third Manifesto (1998), both coauthored
with Hugh Darwen and published by Addison-Wesley. You can send correspondence to him in care of
Database Programming & Design, 411 Borel Ave., Ste. 100, San Mateo, CA 94402.