What s a Tuple?

What's a Tuple?

Is this a tuple?

Well, no, of course it isn't it's a picture of a tuple, not a tuple as such (and note that for once I've included the type names as well as the attribute names in that picture). As we saw in Chapter 1, there's a difference between a thing and a picture of a thing, and that difference can be very important. For example, tuples have no left-to-right ordering to their attributes, and so the following is an equally good (or bad?) picture of the very same tuple:

Thus, while I'll certainly be making use of pictures like these in the sections to follow, please keep in mind that they're only pictures, and they can sometimes suggest some things that aren't true.

With that caveat out of the way, I can now say exactly what a tuple is:

Definition: Let T1, T2, . . . ,Tn (n 0) be type names, not necessarily all distinct. Associate with each Ai; each of the n attribute-name:type-name combinations that results is an attribute. Associate with each attribute a value vi of type Ti; each of the n attribute:value combinations that results is a component. The set of all n components thus defined, t say, is a tuple value (or just a tuple for short) over the attributes A1, A2,..., An. The value n is the degree of t; a tuple of degree one is unary, a tuple of degree two is binary, a tuple of degree three is ternary,..., and more generally a tuple of degree n is n-ary. The set of all n attributes is the heading of t.

For example, with reference to either of the earlier pictures (of our usual tuple for supplier S1), we have:

Degree

Four. The heading is also said to have degree four.

Type names

SNO, NAME, INTEGER, and CHAR.

Corresponding attribute names

SNO, SNAME, STATUS, and CITY.

Corresponding attribute values

SNO('S1'), NAME('Smith'), 20, and 'London'.

NOTE

I showed most of these attribute values in simplified form in the pictures (and I'll continue to make use of similar simplifications in such pictures throughout this book). However, it's strictly incorrect to say that, for example, the SNO value in the tuple we're talking about is just 'S1' or (even sloppier) just S1. A value of type SNO is a value of type SNO, not a value of type CHAR! and the expression SNO('S1') is a literal of type SNO. (More precisely, it's an invocation of the SNO selector, as we saw in Chapter 2. A literal is, precisely, a selector invocation in which the arguments are themselves all literals in turn.)

Heading

The easiest thing to do here is show another picture:

Of course, this picture represents a set, and the order of attributes is arbitrary. Here's another picture of the same heading:

Exercise: How many different pictures of this same general nature could we draw to represent this heading? (Answer: 4 * 3 * 2 * 1 = 24.)

Now, a tuple is a value; like all values, therefore, it has a type (as we already know from Chapter 2), and that type, like all types, has a name. In Tutorial D, such names take the form TUPLE{H}, where {H} is the heading. In our example, the name is:

     TUPLE { SNO SNO, SNAME NAME, STATUS INTEGER, CITY CHAR }

(but the order in which the attributes is specified is arbitrary).

To repeat, a tuple is a value. Like all values, therefore, it must be returned by some selector invocation (a tuple selector invocation, of course, if the value is a tuple). Here's a tuple selector invocation for our example (Tutorial D again):

     TUPLE { SNO SNO('S1'), SNAME NAME('Smith'),                        STATUS 20, CITY 'London' }

(where the order in which the components is specified is arbitrary). Observe that in Tutorial D each component is specified as just an attribute-name:attribute-value pair; the attribute type is omitted because it can always be inferred from the type of the expression denoting the attribute value.

NOTE

A remark on syntax: As you can see, the keyword TUPLE does double duty in Tutorial D it's used in connection with both tuple selector invocations and tuple type names. An analogous remark applies to the keyword RELATION (see the upcoming section See "What's a Relation?").

Finally, a word about SQL. Of course, SQL supports rows, not tuples; in particular, it supports row types, a row type constructor, and row value constructors, which are somewhat analogous to tuple types, the TUPLE type generator, and tuple selectors, respectively. But these analogies are loose at best. For example, this SQL expression:

     ROW ( 1, 2 )

which is an example of a row value constructor, (a) has components that are unnamed and (b) doesn't represent the same row as the row value constructor ROW (2,1). (There are other differences, too, between SQL's row support and our tuple support, but they're beyond the scope of the present discussion.)

NOTE

The keyword ROW in an SQL row value constructor is optional.