Databases Reference
In-Depth Information
DATABASES AND DBVARS
This is the final section of this chapter. In it, I want to draw your attention to the important fact
that just as there's a logical difference between relation values and relation variables (relvars), so
there's also a logical difference between database values and database variables, or what might
be called
dbvars
. Here's a quote from the
Manifesto
topic:
The first version of this
Manifesto
distinguished databases per se (i.e., database values) from database
variables ... [It also] suggested that the unqualified term
database
be used to mean a database value
specifically, and it introduced the term
dbvar
as shorthand for “database variable.” While we still believe this
distinction to be a valid one, we found it had little direct relevance to other aspects of the
Manifesto
. We
therefore decided, in the interests of familiarity, to revert to more traditional terminology.
19
It follows 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
this section.) For example, the
Tutorial D
statement
DELETE ( SP WHERE QTY < 150 ) FROM SP ;
“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” (namely, the applicable relvars), such a manner of speaking is really only
approximate, and is 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 (or “tuplevar”) 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 } }
19
In other words, we went on to use the term
database
to mean sometimes a database variable and sometimes a database value,
and we didn't use the terms
database variable
or
dbvar
at all. However, it turned out later that, for reasons I don't want to go
into here, this was a very bad decision on our part. (Doing something you know is logically wrong is usually a bad idea.) As for
the way I plan to use this terminology in the present topic, please see the remainder of this section.
