Now we come to what in many ways is the most important part of this chapter. The essence of it is this: There’s another way to think about relvars. I mean, most people think of relvars as if they were just files in the traditional computing sense—rather abstract files, perhaps (disciplined might be a better word than abstract), but files nonetheless. But there’s a different way to look at them, a way that I believe can lead to a much deeper understanding of what’s really going on. It goes like this.
Consider the suppliers relvar S. 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 looks like this:
Supplier SNO is under contract, is named SNAME, has status STATUS, and is located in city CITY.
This predicate is the intended interpretation—in other words, the meaning, also called the intension (note the spelling)—for relvar S.
In general, you can think of a predicate 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, SNAME, STATUS, and CITY (corresponding of course to the attributes of the relvar), and they stand for values of the applicable types (CHAR, CHAR, INTEGER, and CHAR, respectively). 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, Smith, 20, and London, respectively. Then we obtain the following statement:
Supplier S1 is under contract, is named Smith, has status 20, and is located in city London.
This statement is in fact a proposition, which in logic is something that’s unequivocally either true or false. 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 specifically, as I now explain:
First of all, every relvar has an associated predicate, called the relvar predicate for the relvar in question. (The predicate shown above is thus the relvar predicate for relvar S.)
Let relvar R have predicate P. Then every tuple t appearing in R at some given time can be regarded as representing a certain proposition p, derived by invoking (or instantiating) P at that time with the attribute values from t as arguments.
And (very important!) we assume by convention that each proposition p that’s obtained in this manner evaluates to TRUE.
Given our usual sample value for relvar S, for example, we assume the following propositions all evaluate to TRUE at this time:
Supplier S1 is under contract, is named Smith, has status 20, and is located in city London.
Supplier S2 is under contract, is named Jones, has status 10, and is located in city Paris.
Supplier S3 is under contract, is named Blake, has status 30, and is located in city Paris.
And so on. 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 assume the corresponding proposition is false at that time t. For example, the tuple
TUPLE { SNO 'S6' , SNAME 'Lopez' , STATUS 30 , CITY 'Madrid' }is—let’s agree—a plausible supplier tuple but doesn’t appear in relvar S at this time, and so we’re entitled to assume it’s not the case that the following proposition is true at this time:
Supplier S6 is under contract, is named Lopez, has status 30, and is located in city Madrid.
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 (see Appendix A and Appendix C for more on this topic).
More terminology: Again, let P be the relvar predicate, or intension, for relvar R, and let the value of R at some given time be relation r. Then r—or the body of r, to be more precise—constitutes the extension of P at that time. Note, therefore, that the extension for a given relvar varies over time, but the intension does not.
Two final points regarding terminology:
You’re probably familiar with the term predicate already, since SQL uses it extensively to refer to what this book calls a boolean expression (i.e., SQL talks about “comparison predicates,” “IN predicates,” “EXISTS predicates,” and so on). Now, this usage on SQL’s part isn’t exactly incorrect, but it does usurp a very general term—one that’s extremely important in relational contexts—and give it a rather specialized meaning, which is why I prefer not to follow that usage myself.
Talking of usurping general terms and giving them specialized meanings, there’s another potential confusion in this area. It has to do with the term statement. As you might have realized, logic uses this term in a sense that’s very close to its natural language meaning. By contrast, programming languages give it a different and rather specialized meaning: They use it to mean a construct that causes some action to occur, such as defining or updating a variable or changing the flow of control. And I’m afraid this book uses the term in both senses, relying on context to make it clear which meaning is intended. Caveat lector.