Preface
This book began life as a comparatively short chapter in a book called Database in Depth: Relational Theory for Practitioners (OReilly, 2005). That book was superseded by SQL and Relational Theory: How to Write Accurate SQL Code (OReilly, 2009), where the design material, since it was somewhat tangential to the main theme of the book, ceased to be a chapter as such and became a (somewhat longer) appendix instead. I subsequently began work on a second edition of this latter book.[
Three points arise immediately from the foregoing:
First, the present book does assume youre familiar with material covered in the SQL and Relational Theory book (in particular, it assumes you know exactly what relations , attributes , and tuples are). I make no apology for this state of affairs, however, since the present book is aimed at database professionals and database professionals ought really to be familiar with most of whats in that earlier book, anyway.
Second, the previous point notwithstanding, theres unavoidably a small amount of overlap between this book and that earlier book. Ive done my best to keep that overlap to a minimum, however.
Third, there are, again unavoidably, many references in this book to that earlier one. Now, most references in this book to other publications are given in full, as in this example:
Ronald Fagin: Normal Forms and Relational Database Operators, Proc. 1979 ACM SIGMOD Int. Conf. on Management of Data, Boston, Mass. (May/June 1979).
In the case of references to the earlier book in particular, however, from this point forward Ill give them in the form of the abbreviated title SQL and Relational Theory alone. Whats more, Ill take that abbreviated title to mean the second edition specifically (where it makes any difference).
Actually Ive published several short pieces over the years, in one place or another, on various aspects of design theory, and the present book is intended among other things to preserve the good parts of those earlier writings. But its not just a cobbling together of previously published material, and I sincerely hope it wont be seen as such. For one thing, it contains much new material. For another, it presents a more coherent, and I think much better, perspective on the subject as a whole (Ive learned a lot myself over the years!). Indeed, even when some portion of the text is based on some earlier publication, the material in question has been totally rewritten and, I trust, improved.
Now, theres no shortage of books on database design; so what makes this one different? In fact I dont think theres a book quite like this one on the market. There are many books (of considerably varying quality, in my opinion) on design practice, but those books (again, in my not unbiased opinion) usually dont do a very good job of explaining the underlying theory. And there are a few books on design theory, too, but they tend to be aimed at theoreticians, not practitioners, and to be rather academic in tone. What I want to do is bridge the gap; in other words, I want to explain the theory in a way that practitioners should be able to understand, and I want to show why that theory is of considerable practical importance. What Im not trying to do is be exhaustive; I dont want to discuss the theory in every last detail, I want to concentrate on what seem to me the important parts (though, naturally, my treatment of the parts I do cover is meant to be precise and accurate, as far as it goes). Also, Im aiming at a judicious blend of the formal and the informal; in other words, Im trying to provide a gentle introduction to the theory, so that:
You can use important theoretical results to help you actually do design, and
Youll be able, if youre so inclined, to go to the more academic texts and understand them.
In the interest of readability, Ive deliberately written a fairly short book, and Ive deliberately made each chapter fairly short, too. (Im a great believer in doling out information in digestible chunks.) Also, every chapter includes a set of exercises (answers to most of which are given in at the back of the book), and I do recommend that you have a go at some of those exercises if not all. Some of them are intended to show how to apply the theoretical ideas in practice; others provide (in the answers if not in the exercises as such) additional information on the subject matter, over and above whats covered in the main body of the text; and still others are meantfor example, by asking you to prove some simple theoretical resultto get you to gain some understanding as to whats involved in thinking like a theoretician. Overall, Ive tried to give some insight into what design theory is and why it is the way it is.
Prerequisites
My target audience is database professionals: more specifically, database professionals with a more than passing interest in database design. In particular, therefore, I assume youre reasonably familiar with the relational model, or at least with certain aspects of that model ( for further details.
Logical vs. Physical Design
This book is about design theory; by definition, therefore, its about logical design, not physical database design. Of course, Im not saying physical design is unimportant (of course not); but I am saying its a distinct activity, separate from and subsequent to logical design. To spell the point out, the right way to do design is as follows: