Note: This section consists of a revised version of material from Appendix D (“What Is a Database?”) from the book Databases, Types, and the Relational Model: The Third Manifesto, by Hugh Darwen and myself (see Appendix G).

I mentioned in the previous section that databases are really variables (as I said in that section, if a database can be updated, then it’s a variable by definition). In other words, we can draw a distinction between database values and database variables, precisely analogous to the one we already draw between relation values and relation variables. As a matter of fact, we—i.e., Darwen and myself—did draw exactly such a distinction in the first version of The Third Manifesto. Here’s an edited quote:

And of course I’ve done the same thing—I mean, I’ve used the term database in the traditional way, and I haven’t used the terms database variable or dbvar at all—throughout the present book, prior to this point. However, the most recent edition of the Manifesto book, after quoting the foregoing text, goes on to say:

That same book gives arguments in support of this position, of course, but I don’t need to get into those arguments here; the simple fact is, a database simply is a variable (its value changes over time), regardless of whether we call it a “dbvar” or just a database.

Now, it follows from the foregoing that when we “update some relvar” (within some database), what we’re really doing is updating the pertinent dbvar. (For clarity, I’ll adopt the term dbvar for the remainder of the present section.) For example, the Tutorial D statement

DELETE SP WHERE QTY < 150 ;

“updates the shipments relvar SP” and thus really updates the entire suppliers-and-parts dbvar (the “new” database value for that dbvar being the same as the “old” one except that certain shipment tuples have been removed). In other words, while we might say a database “contains variables” (viz., the applicable relvars), such a manner of speaking is only approximate, and in fact quite informal. A more formal and more accurate way of characterizing the situation is this:

A dbvar is a tuple variable.

The tuple variable in question has one attribute for each relvar in the dbvar (and no other attributes), and each of those attributes is relation valued. In the case of suppliers and parts, for example, we can think of the entire dbvar as a tuple variable of the following tuple type:

     TUPLE { S  RELATION { SNO CHAR , SNAME CHAR ,
                           STATUS INTEGER, CITY CHAR } ,
             P  RELATION { PNO CHAR , PNAME CHAR ,
                           COLOR CHAR , WEIGHT RATIONAL , CITY CHAR } ,
             SP RELATION { SNO CHAR , PNO CHAR , QTY INTEGER } }

Suppose we call the suppliers-and-parts dbvar (or tuple variable) SPDB. Then the DELETE statement shown above might be regarded as shorthand for the following tuple assignment:

     SPDB := TUPLE { S  ( S FROM SPDB ) ,
                     P  ( P FROM SPDB ) ,
                     SP ( ( SP FROM SPDB ) WHERE NOT ( QTY < 150 ) ) } ;

Explanation: The expression on the right side of this assignment is a tuple selector invocation, and it denotes a tuple with three attributes called S, P, and SP, each of which is relation valued. Within that tuple, the value of attribute S is the current value of relvar S; the value of attribute P is the current value of relvar P; and the value of attribute SP is the current value of relvar SP, minus tuples for which the quantity is less than 150.

In sum: A dbvar is a tuple variable, and a database (i.e., the value of some given dbvar at some given time) is a tuple. What’s more, given a relational assignment of the form

R := rx

(where R is a relvar reference—i.e., a relvar name—and rx is a relational expression), that relvar reference R is really a pseudovariable reference (see the paragraph immediately following). In other words, the relational assignment is shorthand for an assignment that “zaps” one component of the corresponding dbvar (which is, to repeat, really a tuple variable). It follows that “relation variables” (at least, relation variables in the database) aren’t really variables at all; rather, they’re a convenient fiction that gives the illusion that the database—or the dbvar, rather—can be updated in a piecemeal fashion, individual relvar by individual relvar.

A note on pseudovariables: Essentially, a pseudovariable reference consists of an operational expression appearing in an assignment in the target position. For example, let X be a variable of type CHAR, and let ‘Middle’ be the current value of X. Then the assignment SUBSTR(X,2,1) := ‘u’ has the effect of “zapping” the second character position within X, replacing the ‘i’ by a ‘u’. The expression on the left side of that assignment is a pseudovariable reference. The paper “On the Logical Differences Between Types, Values, and Variables” (see Appendix G) discusses the concept in detail.