Some Important Consequences


Now I want to highlight some important consequences of the foregoing definitions. The first is: no tuple ever contains any nulls. The reason is that, by definition, every tuple contains a value (of the appropriate type) for each of its attributes, and we saw in Chapter 1 that nulls aren't values.[*] Of course, if no tuple ever contains any nulls, then no relation does either, a fortiori; so right away we have at least a formal reason for rejecting the concept of nulls but I'll give some more pragmatic reasons as well, in the section "Why Nulls Are Prohibited," later in this chapter.

[*] Despite the fact that SQL often (though not always) refers to them explicitly as null values.

The next consequence is:every subset of a tuple is a tuple and every subset of a heading is a heading. For example, given our usual tuple for supplier S1, what we might call "the {SNO,CITY} value" within that tuple is itself another tuple:


Its heading is as indicated, and its type is:

     TUPLE { SNO SNO, CITY CHAR }

In the same way, the following is a tuple too (its type is TUPLE {SNO SNO}):


So if we want to access the actual attribute value SNO('S1') in the example we have to extract it somehow from its containing tuple. Tutorial D uses syntax of the form SNO FROM t for this purpose (where t is any expression that denotes a tuple with an SNO attribute). SQL uses dot qualification: t.SNO.

NOTE

We saw in Chapter 2 that a tuple t and a relation r that contains just that tuple t aren't the same thing. Analogously, a value v and a tuple t that contains just that value v aren't the same thing, either; in particular, they're of different types.

Now, I'm sure you know that the empty set is a subset of every set. It follows that a tuple with an empty heading, and therefore an empty set of components, is a valid tuple! though it's a little hard to draw a picture of such a tuple on paper, and I'm not even going to try. A tuple with an empty heading has type TUPLE{} (it has no components); indeed, we sometimes refer to it explicitly as a 0-tuple, to emphasize the fact that it is of degree zero. We also sometimes call it an empty tuple. Now, you might think such a tuple is unlikely to be of much use in practice; in fact, it turns out, perhaps rather surprisingly, to be of crucial importance. I'll have more to say about it in the section See "TABLE_DUM and TABLE_DEE," later in this chapter.

The last "important consequence" I want to discuss here has to do with the notion of tuple equality. (Recall from Chapter 2 that the "=" comparison operator is defined for every type, and tuple types are no exception.) Basically, of course, two tuples are equal if and only if they're the very same tuple (just as, for example, two integers are equal if and only if they're the very same integer). But it's worth spelling out the semantics of tuple equality explicitly, since so much in the relational model depends on it for example, candidate keys, foreign keys, and most of the operators of the relational algebra are all defined in terms of it. Here then is a precise definition:

Definition: Tuples t1 and t2 are equal if and only if they have the same attributes A1, A2, ..., An in other words, they're of the same type and, for all i (i = 1, 2, ..., n), the value v1 of Ai in t1 is equal to the value v2 of Ai in t2.

Also (this might seem obvious, but it needs to be said), two tuples are duplicates if and only if they're equal.

By the way, it's an immediate consequence of this definition that all 0-tuples are duplicates of one another. For this reason, we're within our rights if we talk in terms of the 0-tuple instead of a 0-tuple, and indeed we usually do.

Observe finally that the comparison operators "<" and ">" don't apply to tuples (see Exercise 3-11 at the end of the chapter).



Database in Depth
Database in Depth: Relational Theory for Practitioners
ISBN: 0596100124
EAN: 2147483647
Year: 2006
Pages: 127
Authors: C.J. Date

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net