Now onto trying to show how the Relational Algebra gives us ‘something’, ‘somebody’, ‘someone’, and so on.

When I talk about database relations in the following, I am, unless I state otherwise, talking about the abstract object, not those relations concretely realized in an RDBMS.

A brief explanation of the Relational Algebra: Posit a world all of whose people are members of the set {John, Cliff, Charles, Genghis Khan, Leon Trotsky}. Moreover, suppose that currently, the predicate:

*x* is standing to the left of *y *

generates the Database Relation pictured below when all the members of this set are substituted for the parameters x and y:

TO_THE_LEFT_OF (0)
PERSON_ON_THE_LEFT |
PERSON_ON_THE_RIGHT |

Charles |
Genghis Khan |

Dan |
Leon Trotsky |

Cliff |
Genghis Khan |

(The above picture, by the way, is just that — a picture of the Relation. It is not the Relation itself.) As indicated by the number 0 in the name, this Relation is a **base Relation**, i.e., what we have before any operations are applied to it.

The Relational Algebraic operation RESTRICT is a function that takes the Relation pictured above as input and produces another Relation as output. For example, the following RESTRICTion, expressed in Tutorial D:

TO_THE_LEFT_OF where PERSON_ON_THE_LEFT = ‘Charles’; (Yes, I’ve suddenly gone from the flesh and blood Charles as member of a set to the name ‘Charles’; God only knows what confusions this sudden shift will introduce.)

generates the Relation pictured below:

TO_THE_LEFT_OF (1)
PERSON_ON_THE_LEFT |
PERSON_ON_THE_RIGHT |

Charles |
Genghis Khan |

Dan |
Leon Trotsky |

Cliff |
Genghis Khan |

The operation RESTRICT has given us a Relation comprising a single proposition expressed by the sentence ‘Charles is standing to the left of Genghis Khan.’ As indicated by the number 1, this is a **Derived Relation**, produced as output from a function that took as input the Base Relation. The charcoal-grayed out portions of the picture are meant to convey that the derived relation is tied to the base relation in a way in which I will discuss later.

As with RESTRICT, the Relational Algebraic operation PROJECT takes the Base Relation as input and generates a Derived Relation as output. The following RESTRICT and PROJECT operations, expressed in Tutorial D:

(TO_THE_LEFT_OF where PERSON_ON_THE_LEFT = ‘Charles’ ){PERSON_ON_THE_LEFT}

generates the Relation pictured below:

TO_THE_LEFT_OF (2)
PERSON_ON_THE_LEFT |
PERSON_ON_THE_RIGHT |

Charles |
Genghis Khan |

Dan |
Leon Trotsky |

Cliff |
Genghis Khan |

whose body is the set containing the tuple or proposition expressed by the sentence “Charles is to the left of somebody.”

But wait — all we see in this picture is the value Charles. (Or, more precisely, the name ‘Charles’ appearing as a set of black pixels on a screen.) Isn’t this a tuple in a one-place relation? And if it is, wouldn’t it be a proposition belonging to one-place relation, a proposition such as “Charles laughs”, or “Charles runs”, or “Charles eats”?

Well, if it were such, it could be *any* proposition belonging to a one-place relation. The only way to constrain which proposition this tuple is to just one proposition is to place it in its context, the source from which it is derived, i.e., the base relation TO_THE_LEFT_OF. By performing the Projection, we are for the moment blacking-out the identity of Genghis Khan, the person to whom Charles is to the left, so that we can focus on the identity of Charles. But we haven’t forgotten that we are working with the relation TO_THE_LEFT_OF, so we know that Charles is to the left of *somebody*. We haven’t suddenly switched to the relations LAUGHS, or RUNS, or EATS.

To turn for the moment for relations concretely implemented in an RDBMS running in some stuff made out of the same substance as the red paint on the Golden Gate Bridge, complete chaos would ensue, the world would become a topsy-turvey place, objects would start falling up, if, say, a Projection on EMPLOYEE_NAME in the EMPLOYEE (select EMPLOYEE_NAME from EMPLOYEE) would result, not in the set of people employed by the company (more precisely, the set of propositions ‘John, employee of Widgets_R_US’, ‘Jesse, employee of Widgets_R_US’, and so on), but the set of people designated to live on Mars one moment, the set of ambassadors to Vietnam the next moment, and the set of of Pulitzer Prize winners the third moment.

So the meaning of a Projection on an attribute (“column”) of a relation is constrained by the relation from which it is standing out (“projecting”), so to speak. The derived relation never ceases to, well, derive its meaning from the base relation. It never ceases to be a derived relation. Charles never ceases to be one member of a pair whose member on his right is being ignored or blacked-out for the moment.

(Compare this argument with C.J. Date’s argument in LOGIC AND DATABASES, pp. 387-391.)

Let’s trace then what happens, in this relational model, when we plug in Charles to replace *x *in the predicate:

Person *x*, to the left of somebody

The ‘somebody’ is not a parameter — no argument gets plugged into it — but it along with the x indicate that the base relation we are dealing with is TO_THE_LEFT_OF. It tells us that one of the ‘central participants in the situation’ is some person to the right. The relevant Relational Algebra Operations — the relevant RESTRICT and the relevant PROJECT — are then performed to generate the proposition:

Charles, to the left of somebody.

According to the Closed World Assumption, a Relation contains all and only those tuples — those propositions — those states of affairs — that obtain, and for which plugging in arguments to the parameters of the predicate defining the Relation results in a true sentence. Therefore, each tuple in the Relation is paired with the truth value TRUE, and of course, within the Range comprising the two truth values, only the truth value TRUE.

So the set of tuples in a Relation and the set of Truth Values is a function. So, finally — if I may end this string of ‘therefores’ and ‘so’s’ (“Feel free to come to the point when you finally decide what it is, I hear someone say”), when a single tuple is *selected*, as was done when the RESTRICT and PROJECT were performed on the Relation TO_THE_LEFT_OF, we can see this as the application of the function on that tuple, an application which returns TRUE. So (this really is the final ‘so’ — I promise) plugging in the argument ‘Charles’ into the parameter x in the predicate:

*x* is to the left of somebody

triggers a RESTRICT and PROJECT on the Relation TO_THE_LEFT_OF, which in turn constitutes a selection of a single tuple in that relation, which in turn returns TRUE, which lets us regard the predicate as a function returning TRUE when ‘Charles’ is plugged into the parameter marked by x.

Just so, when the RESTRICT and PROJECT fail to select a tuple, as it does when we substitute ‘John’ for *x* (John is standing to the right of everyone else, including Genghis Khan), FALSE is returned.

Voila! We now we have *somebody *(or, as the case may be, *nobody*).

It is clear that the predicate:

*x* is to the left of *y*

can be treated the same way.

Treating verbs aka predicates relationally this way — that is, as functions implemented by Relations and operations on Relations — has two advantages over simply seeing them as functions in the way described by Kroch and Santorini. First, we get a semantics for ‘somebody’, ‘something’, etc. Second, we have a way of conceptualizing in terms of operations of the Relational Algebra the select that occurs when, to use the verb laughs as our example, Luke is selected and the truth value TRUE is returned. The notion of select is no longer a primitive.

Updated on 05/10/2012 to correct an obvious oversight.