Databases Reference
In-Depth Information
like that relvar itself, of degree three, the sole key of that relvar is of degree two, and the two foreign keys in
that relvar, {SNO} and {PNO}, are each of degree one.
The degree (of a heading or relation or ...) can be any nonnegative integer. Degree 1 is said to be
unary
;
degree 2,
binary
; degree 3,
ternary
; ... and, more generally, degree
n
is said to be
n-
ary.
PREDICATES AND PROPOSITIONS
Again consider the shipments relvar SP. 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 is quite simple:
Supplier SNO supplies part PNO in quantity QTY.
This predicate is the
intended interpretation
—in other words, the
meaning
—for relvar SP.
Aside:
Perhaps I should say a little more about the way I use the term
predicate
in this topic. First of all,
you're probably familiar with the term already, since SQL uses it extensively to refer to boolean or truth
valued expressions (it talks about comparison predicates, IN predicates, EXISTS predicates, and so on).
However, while this usage on SQL's part isn't exactly incorrect, it does usurp a very general term—one
that's extremely important in database contexts—and give it a rather specialized meaning, which is why I
prefer not to follow that usage myself.
Second, I should explain in the interest of accuracy that a predicate isn't really a statement as such;
rather, it's the assertion made by that statement. For example, the predicate for relvar S is what it is,
regardless of whether it's expressed in English or Spanish or whatever. For simplicity, however, I'll assume
in what follows that a predicate is indeed just a statement per se, typically expressed in natural language.
Note:
Analogous remarks apply to propositions also (see below).
Finally, I've now explained what I mean by the term, but you should be aware that—the previous
paragraph notwithstanding—there seems to be little consensus, even among logicians, as to
exactly
what a
predicate is. In particular, some writers regard a predicate as a purely formal construct that has no meaning
in itself, and regard what I've called the intended interpretation as something distinct from the predicate as
such. I don't want to get into arguments about such matters here; for further discussion, I refer you to the
article “What's a Predicate?” in
Database Explorations: Essays on The Third Manifesto and Related Topics,
by C. J. Date and Hugh Darwen (Trafford, 2010).
End of aside.
You can think of a predicate, a trifle loosely, 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, PNO, and QTY
(corresponding of course to the attributes of the relvar), and they stand for values of the applicable types (CHAR,
CHAR, and INTEGER, respectively, in this simple example). And 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, P1, and 300, respectively. Then we obtain the following statement:
Supplier S1 supplies part P1 in quantity 300.
