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.
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:
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: Relational Theory for Practitioners

ISBN: 0596100124

EAN: 2147483647

EAN: 2147483647

Year: 2006

Pages: 127

Pages: 127

Authors: C.J. Date

Similar book on Amazon

- Security Architecture and Design
- Business Continuity Planning and Disaster Recovery Planning
- Understanding Certification and Accreditation
- Appendix C The Information System Security Architecture Professional (ISSAP) Certification
- Appendix E The Information System Security Management Professional (ISSMP) Certification

flylib.com © 2008-2017.

If you may any questions please contact us: flylib@qtcs.net

If you may any questions please contact us: flylib@qtcs.net