Relvars and Predicates

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 (maybe disciplined would 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.

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 to the attributes of the relvar, of course), and they stand for values of the applicable types (SNO, NAME, 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 proposition:

Supplier S1 is under contract, is named Smith, has status 20, and is located in city London.

In general, a proposition in logic is a statement that's unconditionally 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 propositions must always be true ones! However, the ones I'm talking about in connection with relvars are supposed to be true ones specifically, as I now explain:

• First, every relvar has an associated predicate, called the relvar predicate for the relvar in question.

• 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.

Hence, given our usual sample value for relvar S, we assume the following propositions all evaluate to TRUE:

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 a certain tuple plausibly could appear in some relvar at some time but in fact doesn't, then we assume the corresponding proposition is false at that time (in other words, we adopt what's called the Closed World Assumption). For example, the tuple:

     TUPLE { SNO SNO('S6'), SNAME NAME('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 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.

In other words, a given relvar contains, at any given time, all and only the tuples that represent true propositions (true instantiations of the predicate) at that time.

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 varies over time, but the intension does not.

Relational Expressions

The ideas I've been discussing in this section all extend in a natural way to apply to arbitrary relational expressions. For example, consider this expression, which represents the projection of suppliers on all attributes but CITY:

     S { SNO, SNAME, STATUS }

The result contains 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 S for some CITY value c. In other words, the result represents the current extension of a predicate that looks like this:

There exists some city CITY such that supplier SNO is under contract, is named SNAME, has status STATUS, and is located in city CITY.

Observe that this predicate has just three parameters and the corresponding relation (the projection of suppliers on all but CITY) has just three attributes CITY is not a parameter but what the logicians instead call a bound variable, owing to the fact that it's "quantified" by the phrase there exists some city. (See Appendix A for further explanation of bound variables and quantifiers.) A possibly clearer way of making the same point 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 in some city (in other words, somewhere, but we don't know where).

It follows from all of the above that views in particular represent certain predicates. For example, if view SST is defined as follows:

     VAR SST VIRTUAL ( S { SNO, SNAME, STATUS } ) ;

then the relvar predicate for SST is precisely:

Supplier SNO is under contract, is named SNAME, has status STATUS, and is located in some city.

There's one last point I want to make here about predicates and propositions. I've said a predicate has a set of parameters. As usual, however, that set might be empty and if it is, the predicate becomes a proposition! (Certainly it's a statement that's unconditionally either true or false.) In other words, a proposition is a degenerate predicate; all propositions are predicates, but most predicates aren't propositions.