Databases Reference
In-Depth Information
Precise definitions are given in Chapter 5.
2.10 Two values of any kind are equal if and only if they're the very same value (meaning they must be of the
same type, a fortiori). In particular, (a) two tuples t and t′ are equal if and only if they have the same attributes A1 ,
..., An and for all i ( i = 1, ..., n ), the value of Ai in t is equal to the value of Ai in t′ ; (b) two relations r and r′ are equal
if and only if they have the same heading and the same body (i.e., their headings are equal and their bodies are
equal). Note in particular, therefore, that two “empty relations” (i.e., relations without any tuples) are equal if and
only if their headings are equal.
2.11 Yes! However, we would of course want such operators always to produce a valid tuple as a result (i.e., we
would want closure for such operations, just as we have closure for relational operations─see the answer to Exercise
2.16 below). For tuple union, for example, we would want the input tuples to be such that attributes with the same
name have the same value (and are therefore of the same type, a fortiori). By way of example, let t1 and t2 be a
supplier tuple and a shipment tuple, respectively, and let t1 and t2 have the same SNO value. Then the union of t1
and t2 , UNION{ t1 , t2 }, is─to use Tutorial D syntax─a tuple of type TUPLE {SNO CHAR, SNAME CHAR,
STATUS INTEGER, CITY CHAR, PNO CHAR, QTY INTEGER}, with attribute values as in t1 or t2 or both (as
applicable). E.g., if t1 is (S1,Smith, 20,London) and t2 is (S1,P1,300)─to use the shorthand notation for tuples
introduced in the body of the chapter─then their union is the tuple (S1,Smith,20,London,P1,300). Note: This
operation might reasonably be called tuple join instead of tuple union.
By the way, it's not just the usual set operators that might be adapted to apply to tuples─the same goes for
certain of the well known relational operators, too (as in fact I've just suggested). One important example is the
tuple projection operator, which is a straightforward adaptation of the relational projection operator. For example,
let t be a supplier tuple; then the projection t {SNO,CITY} of t on attributes {SNO,CITY} is that subtuple of t that
contains just the SNO and CITY components from t . (Of course, a subtuple is itself a tuple in its own right.)
Likewise, t {CITY} is that subtuple of t that contains just the CITY component from t , and t {} is that subtuple of t
that contains no components at all (in other words, it's the 0-tuple─see the next exercise). In fact, it's worth noting
explicitly that every tuple has a projection on the empty set of attributes whose value is, precisely, the 0-tuple.
2.12 The empty tuple (note that there's exactly one such; equivalently, all empty tuples are equal to one another)
is the same thing as the 0-tuple, mentioned in the answer to the previous exercise. As for uses for such a tuple, I'll
just say that, conceptually at least, the fact that such a tuple does exist is crucially important in numerous ways. In
particular, the empty tuple is the only tuple in the special relation TABLE_DEE, already mentioned in the answer to
Exercise 2.8.
2.13 To say relvar R has an empty key is to say R can never contain more than one tuple. Why? Because every
tuple has the same value for the empty set of attributes─namely, the empty tuple (see the answers to the previous
two exercises); thus, if R had an empty key, and if R were to contain two or more tuples, we would have a key
uniqueness violation on our hands. And, yes, constraining R never to contain more than one tuple could certainly be
useful. I'll leave finding an example of such a situation as a subsidiary exercise.
2.14 A predicate with an empty set of parameters is a proposition. (In other words, a proposition is a degenerate
predicate; all propositions are predicates, but “most” predicates aren't propositions.)
Definitions of projection and join are given in Chapter 5, but here's a definition of RENAME:
Definition: Let r1 be a relation, let A be an attribute of r1 , and let r1 not have an attribute named B . Then
the renaming r1 RENAME { A AS B } is a relation r2 with (a) heading identical to that of r1 except that
Search WWH ::

Custom Search