Relational Theory for Computer Professionals

Preface

The relational model of data is one of the great technical inventions of the last hundred years. It’s the foundation of everything we do in the database field; indeed, it’s what made database management a science, instead of what it was formerly, viz., little more than an ad hoc collection of tricks, techniques, and rules of thumb. Thus, everyone professionally involved in database management, even to the smallest degree, owes it to himself or herself to acquire a reasonable knowledge and understanding of the relational model—for without it, fully effective and productive job performance is impossible.

Unfortunately, it isn’t as easy as it should be to come by the aforesaid “reasonable knowledge and understanding.” There are several reasons for this state of affairs, but one of the biggest is the language SQL, which is the official standard “relational” language^[1] and is supported in some shape or form by just about every database product on the market today. It’s widely recognized—at least, it should be widely recognized—that, considered as a concrete realization of the abstract ideas of the relational model, SQL is very deeply flawed (that’s why I put “relational” in quote marks in the previous sentence). And since for obvious practical reasons everyone in the database world has to know something about SQL, the emphasis in almost all relational (or would-be relational) education tends to be on SQL as such, instead of on the underlying theory. As a consequence, it’s all too common for people to think that, just because they know SQL, they know relational theory. Sadly, however, the truth is that if you know only SQL as such, then you most certainly don’t know that theory. And what you don’t know can hurt you.

The principal aim of this book, then, is to teach relational theory, very carefully (indeed, as carefully as I can). A secondary aim is to describe SQL—or what might be regarded as the core features of SQL, at any rate—from the standpoint of that theory. Which brings me to another point ... Some readers will be aware that not all that long ago I published another book on such matters, with the title SQL and Relational Theory: How to Write Accurate SQL Code (2nd edition, O’Reilly, 2012). Unlike the present book, however, that earlier book was aimed at database practitioners specifically, meaning, typically, people with at least three or four years experience “working in the trenches” with a database system and using it regularly as part of their normal job (and therefore certainly having a working knowledge of SQL). What that book tried to do was show how to apply relational principles to the use of SQL, thereby making SQL behave almost as if it were a truly relational language (a discipline I referred to in that book as “using SQL relationally”). Now, there’s unavoidably some overlap between that book and the present one; indeed, there are places in the present book where text has been copied and pasted from the earlier book, sometimes almost verbatim. Nonetheless, what you’re looking at now is definitely a different book, in part because it’s aimed at a different audience (see further explanation below). Of necessity, however, there are frequent references in what follows to that earlier book, and in the interest of brevity all such references are given in the form of the abbreviated title alone (viz., SQL and Relational Theory). What’s more, I think it’s only fair to say that if you’re familiar with that earlier book, then you probably won’t have much to gain from the present one. Of course, I don’t want to discourage you from reading it!—but if you do, I doubt whether you’ll find much that’s really new to you.

Who Should Read This Book

My target audience is computer professionals. Thus, I assume you know something about computers and programming in general, and I assume you’re reasonably familiar with at least one conventional programming language. But I don’t assume you know anything about databases, relational or otherwise, nor about SQL in particular. Of course, you very likely do at least know that modern database systems are almost all supposed to be “relational” (whatever that might mean), but I won’t rely even on that assumption. Please note, however, that if you do happen to know something about databases already, then you probably need to pay extra careful attention to what this book has to say!—you might find you have some unlearning to do (and unlearning, as we all know, can be very difficult). The point is, existing database products, even those that are labeled “relational,” are in fact not so—they depart from the theoretical relational ideal in far too many ways, as you’ll soon discover. As I wrote in SQL and Relational Theory:

I apologize for the possibly offensive tone here [, but] if your knowledge of the relational model derives only from your knowledge of SQL, then I’m afraid you won’t know the relational model as well as you should, and you’ll probably know “some things that ain’t so.” I can’t say it too strongly: SQL and the relational model aren’t the same thing.

Note: I’d like to mention that I have a live seminar available based on the material in this book. For further details, please go to the website www.justsql.co.uk/chris_date/chris_date.htm. A video version is available too—please go to http://oreilly.com/go/date.

Structure of the Book

The book is divided into three main parts, plus a collection of appendixes. Part I, is concerned with the relational model as such—in other words, with the theory underlying relational database technology (though it does also stress the practical applications of that theory throughout). Part II, is devoted to a discussion of certain material that (a) you do need to know in order to understand what databases in general, and relational databases in particular, are all about, but (b) doesn’t really have all that much to do with the relational model as such (except inasmuch as it does build on that model as a foundation). Part III, then revisits the material of Part I and shows how the concepts discussed in that first part are realized in the SQL language as such. As for the appendixes, they’re something of a mixed bag (as appendixes tend to be), and I don’t think it’s worth my while trying to describe them further here.

Note: Review questions and exercises are an integral part of most of the chapters, and I’d like to recommend that you try answering those questions and exercises for yourself before going on to read the ensuing discussion of the answers. In particular, you should be aware that those exercises frequently, and of course intentionally, go some way—sometimes a fairly long way—beyond the material as described in the immediately preceding text.

Acknowledgments

Once again I’d like to begin by thanking my wife Lindy for her support throughout the production of this book, as well as all of its predecessors. I’d also like to thank David Livingstone for originally suggesting the idea of this particular book—or one something like it, at any rate!—and Allen Noren for pressuring me to write it. (Allen’s idea was that my other O’Reilly books needed a foundation on which to build, and a book like this could provide that foundation. And I believe he’s correct. Certainly that’s the book I’ve tried to write.) Finally, I’d like to thank the attendees at live classes, too numerous to mention individually, whose questions and comments helped me structure the book appropriately, and helped me also to decide what to include and what to exclude. As always, of course, any errors, of either fact or judgment, remain my own responsibility.

C. J. Date

Healdsburg, California

2013

---

^[1] The SQL standard has been through several versions, or editions, over the years. The version current at the time of writing is the 2011 version (“SQL:2011”). Here’s the formal reference: International Organization for Standardization (ISO), Database Language SQL, Document ISO/IEC 9075:2011. Chapter 10 and Appendix E each have a little more to say about this reference, and Chapter 10 in particular briefly reviews the pertinent history.