An Interview with Chris Date
Pages: 1, 2, 3, 4, 5
Tony: Since the first edition of Codd and Date we have seen many trends, from 4GLs to object-oriented databases. Any that have appealed or do you feel they are a flash in the pan?
Chris: First, a small point (or perhaps it's not so small): I don't quite know what you mean by "the first edition of Codd and Date." For some years Ted and I did have a consulting company called Codd and Date, but your phrasing suggests we might have collaborated on a book. In fact we never did. The history is like this. Ted was a genius; there's no question about that, and he came up with these wonderful ideas. But like so many geniuses, he wasn't too good at communicating his ideas to ordinary mortals. So that was my job: to be that ordinary mortal! Once I'd understood the ideas myself, I was able to explain them to other people ... and that's what I did. In particular, I wrote a book called An Introduction to Database Systems, which was a textbook on database management that covered the relational model in particular (though it covered a lot of other things too). The first edition of that book appeared in 1975 (it's in its eighth edition now). But yes, I agree that many things have happened since that first edition, if that's what you meant. So let me turn to your question regarding the "many trends" ... Once again I fear my answer has to be fairly lengthy; please bear with me.
Actually, I rather like your use of the word "trends" here. Because the truth is, so many of the things that have arisen over the years have indeed been just that, trends. The relational model is not and never was a mere "trend." The relational model is a solid scientific theory. Nothing has appeared on the horizon to replace it, and in my opinion it's extremely unlikely (I don't say impossible, you never know what's around the next corner) that anything ever will. The reason I say this is that the relational model is based on set theory and predicate logic, elements of which go back well over 2,000 years. These disciplines in their various forms have been studied, analyzed, used, and extended by huge numbers of very smart people over the past two millennia (I refer here to logicians and mathematicians, of course); thus, it seems to me very unlikely that there's anything seriously wrong with them. By contrast, alleged competitors to the relational model--things like the so-called object "model" or the so-called semistructured "model" (and I set the term "model" in quotes very deliberately here)--simply don't have the same kind of pedigree as the relational model does, nor do they enjoy the same kind of scientific respectability.
So I certainly don't find "appealing" any of the things that (it's been claimed at one time or another) are supposed to replace the relational model. And in this connection I'd like to say explicitly that I reject, as proposed "replacements" for the relational model, both (a) XML and the semistructured "model," which I see as reinventing the old failed hierarchic "model," and (b) objects and the object-oriented "model," which I see as reinventing the old failed network "model."
But the trouble with the relational model is, it's never been implemented--at least, not in commercial form, not properly, and certainly not fully. So while it's true that there have been a couple of developments in the marketplace over the past few years that I do quite like, I like them primarily because I see them as attempts to implement pieces of the relational model that should have been implemented years ago but weren't. I refer here to (a) "business rules" and (b) "object/relational DBMSs." I'll take them one at a time.
- Business rules: Business rule systems are a good idea, but they certainly aren't a new idea. Without going into a lot of detail, business rule systems can be seen as systems that attempt to implement the integrity piece of the relational model (which today's mainstream SQL products still--over 35 years after the model was first described!--so signally fail to do).
- Object/relational DBMSs: To a first approximation, "object/relational" just means the domains over which relations are defined can be of arbitrary complexity. As a consequence, we can have attributes of relations--or columns of tables, if you prefer--that contain geometric points, or polygons, or X rays, or XML documents, or fingerprints, or arrays, or lists, or relations, or any other kinds of values you can think of. But this idea too was always part of the relational model! The idea that the relational model could handle only rather simple kinds of data (like numbers, and strings, and dates, and times) is a huge misconception, and always was. In fact, the term object/relational, as such, is just a piece of marketing hype ... As far as I'm concerned, an object/relational system done right would simply be a relational system done right, nothing more and nothing less.
That said, I must now add that, as so often, "Between the idea / And the reality / ... Falls the shadow" (T. S. Eliot--one of my favorites). While business rules and object/relational systems are both good ideas in principle, it doesn't follow that today's commercial realizations of those ideas are well done. In particular, today's object/relational systems (and the SQL standard)--in what I regard as a totally misguided attempt to accommodate certain ideas from object systems--have introduced pointers into SQL databases! Ted Codd very deliberately excluded pointers from the relational model, for all kinds of good reasons, and I think the addition of pointers to SQL has to be seen as the final nail in the coffin of any claims SQL might ever have had of being a true relational language.
Enough of this grousing. The next thing I want to say is that, while the relational model is certainly the foundation for "doing databases right," it's only the foundation. There are various ways we can build on top of the relational model, and various attempts have been made to do such a thing over the past 25 years or so. Here are a couple of examples:
- Higher-level interfaces: It was never the intention that every user should have to wrestle with the complexities of something like SQL (or even the complexities, such as they are, of the relational algebra). I always rather liked the visual interfaces provided by Query-By-Example and the "visual programming" front-ends to Ingres, for instance. And there are many other attractive front-ends that simplify the business of building applications on top of a relational (or at least SQL) DBMS. 4GLs too can be regarded as a higher-level interface--but I was never very impressed by 4GLs as such, in part because they never seemed to be precisely defined anywhere; the idea might have been OK, but without a formal definition of the semantics of the language some very expensive mistakes can be (and were) made. Natural-language systems are another example; I still have an open mind about these, but I don't think anyone could claim they've been a huge success as yet.
- Special-purpose applications: I think the right way to view things like OLAP and data mining is as special-purpose applications that run on top of the DBMS. I mean, I don't think these things should be part of the core DBMS (I could be wrong). Either way, however, I do want to complain about the CUBE stuff in SQL, which takes one of the worst aspects of SQL--its support for nulls--and "exploits" it to make it even worse. But that's a particular hobbyhorse of mine ... I think I'd better stop right here.
