I’ll use our usual suppliers relation as a basis for examples in this section. Here’s a picture:
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
And here’s a definition:
Definition: Let {H} be a tuple heading and let t1, t2, ..., tm (m ≥ 0) be distinct tuples, all with heading {H}.[41] Then the combination, r say, of {H} and the set of tuples {t1, t2, ..., tm} is a relation value (or just a relation for short) over the attributes A1, A2, ..., An, where A1, A2, ..., An are all of the attributes in {H}. The heading of r is {H}; r has the same attributes (and hence the same attribute names and types) and the same degree as that heading does. The set of tuples {t1, t2, ..., tm} is the body of r. The value m is the cardinality of r.
I’ll leave it as an exercise for you to interpret the suppliers relation in terms of the foregoing definition. However, I will at least explain why we call such things relations. Basically, each tuple in a relation represents an n-ary relationship, in the ordinary natural language sense of that term, interrelating a set of n values (one such value for each tuple attribute); the full set of tuples in a given relation represents the full set of such relationships that happen to exist at some given time; and, mathematically speaking, that set of tuples is a relation. Thus, the explanation often heard, to the effect that the relational model is so called because it lets us “relate one table to another,” though accurate in a kind of secondary sense, really misses the basic point. The relational model is so called because it deals with certain abstractions that we can think of informally as “tables” but are known in mathematics, formally, as relations.
Now, a relation, like a tuple, is itself a value and has a type, and that type has a name. In Tutorial D, such names take the form RELATION {H}, where {H} is the heading—for example:
RELATION { SNO CHAR , SNAME CHAR , STATUS INTEGER , CITY CHAR }(The order in which the attributes are specified is arbitrary.) Also, every relation value is denoted by some relation selector invocation—for example:
RELATION
{ TUPLE { SNO 'S1' , SNAME 'Smith' , STATUS 20 , CITY 'London' } ,
TUPLE { SNO 'S2' , SNAME 'Jones' , STATUS 10 , CITY 'Paris' } ,
TUPLE { SNO 'S3' , SNAME 'Blake' , STATUS 30 , CITY 'Paris' } ,
TUPLE { SNO 'S4' , SNAME 'Clark' , STATUS 20 , CITY 'London' } ,
TUPLE { SNO 'S5' , SNAME 'Adams' , STATUS 30 , CITY 'Athens' } }The order in which the tuples are specified is arbitrary. Here’s another example (unlike the previous one, this one isn’t a literal):
RELATION { tx1 , tx2 , tx3 }I’m assuming here that tx1, tx2, and tx3 are tuple expressions and are all of the same tuple type. As these examples suggest, a relation selector invocation in Tutorial D consists in general[42] of the keyword RELATION, followed by a commalist of tuple expressions enclosed in braces (and those tuple expressions must all be of the same tuple type).
Most of the properties of relations I talked about in Chapter 1 are direct consequences of the definitions discussed above, but there are some points I didn’t call out explicitly before, and I want to elaborate on some of the others. The first two I want to mention are as follows:
Relations never contain duplicate tuples—because the body of a relation is a set (a set of tuples) and sets in mathematics don’t contain duplicate elements.
Relations never contain nulls—because the body of a relation is a set of tuples, and we’ve already seen that tuples in turn never contain nulls.
But these two points are so significant, and there’s so much I need to say about them, that I’ll defer detailed treatment to the next chapter. In the next few sections, I’ll address a series of possibly less weighty issues (?) arising from the definitions.
[41] A remark on notation: In mathematics, the symbol H enclosed in braces, as in “{H}” here, would denote a set containing a single element H. And so it does in this definition too, of course—but that symbol H in turn must be understood as denoting a composite object (viz., a commalist of attributes, in the case at hand). Now, if I were to say, in mathematics, that the set {X} is a subset of the set {Y}, I could only mean X and Y were identical. But when I say the same thing in the present book (and when X and Y do indeed denote composite objects), then I mean the set of items constituting X is a subset of the set of items constituting Y. I hope that’s clear! Note: The picture is perhaps muddied slightly by the fact that I don’t always use notation of the form {X} to denote sets of attributes. For example, my definition of the term key in Chapter 5 begins: “Let K [i.e., not {K}] be a subset of the heading of relvar R.” In general, in fact, I’ll feel free to include braces or exclude them according to what suits my purpose best at the time. I hope this state of affairs won’t confuse you.
[42] But see Exercise 3.15.