Recall now from Chapter 5 that every relvar has a certain relvar predicate, which is, loosely, what the relvar means. For example, the predicate for the suppliers relvar S is:
Supplier SNO is under contract, is named SNAME, has status STATUS, and is located in city CITY.
What I didn’t mention in Chapter 5, however, is that the foregoing notion extends in a natural way to apply to arbitrary relational expressions. For example, consider the projection of suppliers on all attributes but CITY
S { SNO , SNAME , STATUS }This expression denotes a relation containing all tuples of the form
TUPLE { SNO s , SNAME n , STATUS t }such that a tuple of the form
TUPLE { SNO s , SNAME n , STATUS t , CITY c }currently appears in relvar S for some CITY value c. In other words, the result represents the current extension of a predicate that looks like this (see Chapter 5 if you need to refresh your memory regarding the notion of a predicate’s extension):
There exists some city CITY such that supplier SNO is under contract, is named SNAME, has status STATUS, and is located in city CITY.
This predicate thus represents the meaning of the relational expression S{SNO,SNAME,STATUS}. Observe that it has just three parameters and the corresponding relation has just three attributes—CITY isn’t a parameter to that predicate but what logicians call a “bound variable” instead, owing to the fact that it’s “quantified” by the phrase There exists some city (see Chapter 10 for further explanation of bound variables and quantifiers).[87] Note: A possibly clearer way of making the same point—viz., that the predicate has just three parameters, not four—is to observe that the predicate in question is logically equivalent to this one:
Supplier SNO is under contract, is named SNAME, has status STATUS, and is located somewhere [in other words, in some city, but we don’t know which].
Remarks analogous to the foregoing apply to every possible relational expression. To be specific: Every relational expression rx always has an associated meaning, or predicate; moreover, the predicate for rx can always be determined from the predicates for the relvars involved in that expression, together with the semantics of the relational operations involved. As an exercise, you might like to revisit some of the relational (or SQL) expressions shown earlier in this chapter, with a view to determining what the corresponding predicate might look like in each case.
[87] One reviewer asked why CITY is mentioned in the predicate at all, since it isn’t part of the result of the projection. This is an important question! A short answer is: Because that result is obtained by projecting away the CITY attribute specifically, nothing more and nothing less. A much longer answer can be found in my book Logic and Databases: The Roots of Relational Theory (Trafford, 2007), pages 387-391 (see Appendix G). Further relevant discussion can be found in the book Normal Forms and All That Jazz: A Database Professional’s Guide to Database Design Theory (again, see Appendix G).