| For the most part, the aim of this preliminary chapter has been to tell you what I rather hope you knew already (and you might therefore have felt it was rather light on technical substance). Anyway, just to review briefly: I explained why we'd be concerned in this book with principles, not products, and why I'd be using formal terminology such as relations, tuples, and attributes in place of their more "user-friendly" SQL counterparts. I claimed that SQL and the relational model aren't the same thing. We've seen a few differences already for example, the fact that SQL permits duplicate rows and we'll see many more in later chapters. I gave an overview of the original model, touching in particular on the following concepts: type, n-ary relation, tuple, attribute, candidate key, primary key, foreign key, entity integrity, referential integrity, relational assignment, and the relational algebra. With regard to the algebra, I mentioned closure and very briefly described the operators restrict, project, product, intersection, union, difference, join, and divide. I discussed various properties of relations, introducing the terms heading, body, cardinality, and degree. Relations have no duplicate tuples, no tuple ordering top to bottom, and no attribute ordering left to right. I also discussed views. I discussed the differences between model and implementation, relations and relvars, and values and variables in general. The model versus implementation discussion in particular led to a discussion of data independence.
One last point (I didn't mention this explicitly before, but I hope it's obvious from everything I did say): overall, the relational model is declarative, not procedural, in nature; that is, we favor declarative solutions over procedural ones, wherever such solutions are feasible. The reason is obvious: declarative means the system does the work, procedural means the user does the work (so we're talking about productivity, among other things). That's why the relational model supports declarative queries, declarative updates, declarative view definitions, declarative integrity constraints, and so on.[*] [*] As this book was going to press, I was informed that at least one well-known SQL product apparently uses the term "declarative" to mean the system doesn't do the work! That is, it allows the user to state certain things declaratively (for example, the fact that a certain view has a certain key), but it doesn't enforce the constraint implied by that declaration it simply assumes the user is going to enforce it instead. Such terminological abuses do little to help the cause of genuine understanding. Caveat lector.
|
