| As noted in the introduction to this chapter, the purpose of this book has been to explain the relational model primarily to people, especially database practitioners, who already know something about it but realize they need to know more. Since this is the final section of the final chapter in the entire book, it seems appropriate to review here what's been covered in the book as a whole. So here goes: Chapter 1, Introduction, set the stage by describing (not very formally) the original model. As I put it in that chapter, my primary purpose was to tell you what I hoped you knew already. But I also discussed the important logical differences between relations and relvars, and between values and variables in general, and between the model and its implementation. This last in particular led to a discussion of data independence. In Chapter 2, Relations Versus Types, I argued that domains were just types by another name and, further, that those types could be of arbitrary complexity. The question as to what types are supported is orthogonal to the question of support for the relational model itself ("Types are orthogonal to tables"). Chapter 3, Tuples and Relations, gave precise definitions for these fundamental concepts and discussed several consequences of those definitions. It also gave some pragmatic arguments for prohibiting both duplicates and nulls, and it introduced the important special relations TABLE_DUM and TABLE_DEE. Chapter 4, Relation Variables, was where I first considered the crucial notion of relvar predicates. I showed that types and relations are both necessary and sufficient to represent any data we like at the logical level. I explained the details of candidate and foreign keys, and I took a much closer look at views (also known as virtual relvars). Chapter 5, Relational Algebra, was the longest chapter in the book. I stressed the importance of closure and introduced a set of relation type inference rules. I described many of the most important algebraic operators (especially join, which includes both intersection and product as special cases). I gave a conceptual algorithm for evaluating SQL SELECT - FROM - WHERE expressions. I briefly discussed the relevance of the algebra to optimization and to the update operators, and I described relational comparison operators. In Chapter 6, Integrity Constraints, I explained the two basic kinds of constraints, type constraints and database constraints. I also briefly discussed "possreps," selectors, and THE_ operators. Type constraints are checked as part of the execution of selector operators; database constraints are checked "at semicolons." I also discussed multiple assignment, The Golden Rule, and the difference between correctness and consistency. And I claimed that constraints were crucial ("I don't care how fast your system runs if I can't trust the answers it gives me"). Chapter 7, Database Design Theory, concentrated on the theory of logical database design. That theory isn't really part of the relational model as such but uses that model as a base on which to build. I stressed the fact that logical design is intimately bound up with constraints and predicates. A large part of design theory has to do with reducing redundancy: normalization reduces redundancy within relvars, orthogonality reduces it across relvars. I discussed FDs, BCNF, JDs, and 5NF, and briefly mentioned 6NF, elaborating on the idea that "it's all really formalized common sense." Don't denormalize! I also discussed orthogonality, and I offered a few generic remarks on physical design as well. Finally, the present chapter, What Is the Relational Model?, has taken a look at some of the issues raised by the question in the title. I gave a terse, precise, and possibly not immediately understandable answer to that question, identifying five components of the model and elaborating on each in turn. I also listed Codd's objectives for his model. Next, I summarized the various principles--The Information Principle and the rest that we encountered earlier in the text. I tried to show why other "models" aren't in the same ballpark as the relational model; as far as I can tell, in fact, the relational model is still the only one to have been defined before implementations were attempted, and it's still the only one that rigidly excludes all implementation considerations. Last, I discussed a variety of ways in which we might continue to move this whole field forward.
|
