Databases Reference
In-Depth Information
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 for relvar S, for example, the parameters are
SNO, SNAME, STATUS, and CITY (corresponding of course to the attributes of the relvar), and
they stand for values of the applicable types (CHAR, CHAR, 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. We obtain:
Supplier S1 is under contract, is named Smith, has status 20, and is located in city London.
This latter sentence is in fact a
proposition
, which in logic is a sentence that has no
parameters and evaluates unequivocally to either true or false. (In the case at hand, of course, the
proposition is a true one, or so at least we assume for the sake of the example.) Which brings me
to another important principle,
The Closed World Assumption:
Definition:
Let relvar
R
have predicate
P
. Then
The Closed World Assumption
(CWA)
says (a) if tuple
t
appears in
R
at time
T
, then the instantiation
p
of
P
corresponding to
t
is
assumed to be true at time
T
; conversely, (b)
if tuple
t
has the same heading as
R
but
doesn't appear in
R
at time
T
, then the instantiation
p
of
P
corresponding to
t
is assumed to
be false at time
T
. In other words, tuple
t
appears in relvar
R
at a given time if and only if it
satisfies the predicate for
R
at that time.
15
For example, with reference to Fig. 2.1 once again, it's currently a “true fact” that supplier
S1 supplies part P1 in quantity 300, because the tuple (S1,P1,300) currently appears in relvar SP.
But if we were to delete that tuple from that relvar, we would be saying (in effect) that
it's no
longer the case that
supplier S1 supplies part P1 in quantity 300.
Now, so far I've discussed predicates in connection with relvars specifically. In fact,
however, all of the foregoing notions extend in a natural way to arbitrary relational expressions.
For example, consider the projection of suppliers on all attributes but CITY (note the
Tutorial D
syntax for projection):
16
S { SNO , SNAME , STATUS }
15
I'd like to stress that “if and only if.” It has at least one important corollary. To be specific, let relvars
R1
and
R2
have
predicates
P1
and
P2
, respectively; then if
P1
and
P2
are both satisfied by the same tuple
t
, it follows that
t
must appear in both
R1
and
R2
. (As a rule of thumb, it might be a good idea to ensure that
P1
and
P2
are specific enough to preclude the foregoing
possibility. Note, however, that we'll see some deliberate violations of this suggested discipline in Chapters 4 and 9-11.)
16
I remark in passing that we find it convenient to give projection the highest precedence of all of the relational operators in
Tutorial D
.
