The Relational Model: Information in Formation!
—Anon.: Where Bugs Go
This is the final chapter in this first part of the book. In previous chapters, I’ve described the most important features—at least, the features that are most important from a relational point of view—of a relational DBMS. Now it’s time to review those features and bring them all together, so to speak, by defining the relational model as such and attempting to explain what that definition means. One small point for the record: The term relational model itself is taken from the title of Codd’s famous paper “A Relational Model of Data for Large Shared Data Banks” (CACM 13, No. 6, June 1970), which I’ll have a little more to say about in Appendix A.
I don’t know whether you noticed, but I deliberately gave no definition prior to this point of what exactly the relational model is—even though I tacitly appealed to such a definition on numerous occasions, saying things like:
The relational model has no tuple level operators
The relational model prohibits pointers
The relational model requires immediate integrity checking
and many other things of a similar nature. The closest I came to an actual definition was probably in Chapter 1, when I described the relational model as “a recipe for what the user interface is supposed to look like”—which is true, but is hardly much use as a precise definition. Now, I could alternatively have said the relational model is