SQL and Relational Theory, 2nd Edition

CONCLUDING REMARKS

This brings us to the end of this preliminary chapter. For the most part, my aim has just been to tell you what I rather hope you knew already (and you might have felt the chapter was a little light on technical substance, therefore). Anyway, just to review briefly:

• I explained why we’d be concerned with principles, not products, and why I’d be using formal terminology such as relation, tuple, and attribute (at least in relational contexts) in place of their more “user friendly” SQL counterparts.

• I gave an overview of the original model, touching in particular on the following concepts: type (or domain), n-ary relation, tuple, attribute, candidate key (key for short), primary key, foreign key, entity integrity, referential integrity, relational assignment, and the relational algebra. (I also briefly mentioned the relational calculus.) With regard to the algebra, I mentioned the closure property and very briefly described the operators restrict, project, product, intersection, union, difference, and join.

• I discussed various properties of relations, introducing the terms heading, body, cardinality, and degree. Relations have no duplicate tuples, no top to bottom tuple ordering, and no left to right attribute ordering. I also discussed the difference between base relations (or base relvars, rather) and views. And I explained that every subset of a tuple is a tuple, every subset of a heading is a heading, and every subset of a body is a body.

• I discussed the logical differences between model and implementation, values and variables in general, and relations and relvars in particular. The model vs. implementation discussion in particular led to a discussion of physical data independence.

• 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, the fact that SQL tables have a left to right column ordering, and the fact that SQL doesn’t clearly distinguish between table values and table variables—and we’ll see many more in the pages to come.

One last point (I didn’t mention this explicitly before, but I hope it’s clear from everything I did say): Overall, the relational model is declarative, not procedural, in nature; that is, it always favors 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 on and on.

Note: After I first wrote the foregoing paragraph, 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.