Again consider the shipments relvar SP. Like all relvars, that relvar is supposed to represent some portion of the real world. In fact, I can be more precise: The heading of that relvar represents a certain predicate, meaning it’s a kind of generic statement about some portion of the real world (it’s generic because it’s parameterized, as I’ll explain in a moment). The predicate in question is quite simple:
Supplier SNO supplies part PNO in quantity QTY.
This predicate is the intended interpretation—in other words, the meaning—for relvar SP.
Aside: Perhaps I should say a little more about the way I use the term predicate in this book. First of all, you’re probably familiar with the term already, since SQL uses it extensively to refer to boolean or truth valued expressions (it talks about comparison predicates, IN predicates, EXISTS predicates, and so on). However, while this usage on SQL’s part isn’t exactly incorrect, it does usurp a very general term—one that’s extremely important in database contexts—and give it a rather specialized meaning, which is why I prefer not to follow that usage myself.
Second, I should explain in the interest of accuracy that a predicate isn’t really a statement as such; rather, it’s the assertion made by that statement. For example, the predicate for relvar S is what it is, regardless of whether it’s expressed in English or Spanish or whatever. For simplicity, however, I’ll assume in what follows that a predicate is indeed just a statement per se, typically expressed in natural language. Note: Analogous remarks apply to propositions also (see below).
Finally, I’ve now explained what I mean by the term, but you should be aware that—the previous paragraph notwithstanding—there seems to be little consensus, even among logicians, as to exactly what a predicate is. In particular, some writers regard a predicate as a purely formal construct that has no meaning in itself, and regard what I’ve called the intended interpretation as something distinct from the predicate as such. I don’t want to get into arguments about such matters here; for further discussion, I refer you to the article “What’s a Predicate?” in Database Explorations: Essays on The Third Manifesto and Related Topics, by C. J. Date and Hugh Darwen (Trafford, 2010). End of aside.
You can think of a predicate, a trifle loosely, as a truth valued function. Like all functions, it has a set of parameters; it returns a result when it’s invoked; and (because it’s truth valued) that result is either TRUE or FALSE. In the case of the predicate just shown, for example, the parameters are SNO, PNO, and QTY (corresponding of course to the attributes of the relvar), and they stand for values of the applicable types (CHAR, CHAR, and INTEGER, respectively, in this simple example). And when we invoke the function—when we instantiate the predicate, as the logicians say—we substitute arguments for the parameters. Suppose we substitute the arguments S1, P1, and 300, respectively. Then we obtain the following statement:
Supplier S1 supplies part P1 in quantity 300.
This statement is in fact a proposition, which in logic is something that evaluates to either TRUE or FALSE, unconditionally. Here are a couple of examples:
Edward Abbey wrote The Monkey Wrench Gang.
William Shakespeare wrote The Monkey Wrench Gang.
The first of these is true and the second false. Don’t fall into the common trap of thinking that propositions must always be true! However, the ones I’m talking about at the moment are supposed to be true ones, as I now explain:
First of all, every relvar has an associated predicate, called the relvar predicate for the relvar in question. (So the predicate shown above—Supplier SNO supplies part PNO in quantity QTY—is the relvar predicate for relvar SP.)
Let relvar R have predicate P. Then every tuple t appearing in R at some given time T can be regarded as representing a certain proposition p, derived by invoking (or instantiating) P at that time T with the attribute values from t as arguments.
And (very important!) we assume by convention that each proposition p obtained in this manner evaluates to TRUE.
Given the sample value shown for relvar SP on the left of Figure 2-1, for example, we assume the following propositions both evaluate to TRUE at time T1:
Supplier S1 supplies part P1 in quantity 300.
Supplier S2 supplies part P1 in quantity 300.
What’s more, we go further: If at some given time T a certain tuple plausibly could appear in some relvar but doesn’t, then we’re entitled to assume the corresponding proposition is false at that time T. For example, the tuple
( 'S1' , 'P2' , 200 )
(to adopt an obvious shorthand notation) is certainly a plausible SP tuple; but it doesn’t appear in relvar SP at time T1—I’m referring to Figure 2-1 again—and so we’re entitled to assume it’s not the case that the following proposition is true at time T1:
Supplier S1 supplies part P2 in quantity 200.
(On the other hand, this proposition is true at time T2.)
To sum up: A given relvar R contains, at any given time, all and only the tuples that represent true propositions (true instantiations of the relvar predicate for R) at the time in question—or, at least, that’s what we always assume in practice. In other words, in practice we adopt what’s called The Closed World Assumption. And since that assumption is so crucial—it underlies just about everything we do when we use a database, even though it’s seldom acknowledged explicitly—I’d like to spell it out here for the record:
Definition: Let relvar R have predicate P. Then The Closed World Assumption (CWA) says (a) if tuple t appears in R at time T, then the instantiation p of P corresponding to t is assumed to be true at time T; conversely, (b) if tuple t plausibly could appear in R at time T but doesn’t, then the instantiation p of P corresponding to t is assumed to be false at time T. In other words (albeit a trifle loosely): Tuple t appears in relvar R at a given time if and only if it satisfies the predicate for R at that time.