Further Important Consequences

Most of the properties of relations I talked about in Chapter 1 are direct consequences of the definitions in the previous section, but there are a couple I didn't call out explicitly before, and I want to elaborate on some of the others.

The first point I didn't mention before is that every subset of a body is a body (loosely, every subset of a relation is a relation). In particular, therefore, since the empty set is a subset of every set, a relation can have a body that consists of an empty set of tuples (and we call such a relation an empty relation). For example, suppose there are no shipments right now. In this case, relvar SP will have as its current value the empty shipments relation, which we might draw like this:^[*]

^[*] I now revert to the convention by which we omit the type names from a heading in informal contexts. Throughout the remainder of this book, in fact, I'll feel free to regard headings as either including type names or excluding them whichever best suits my purpose at the time.

Note that, given any particular relation type, there's exactly one empty relation of that type but empty relations of different types aren't the same thing, precisely because they're of different types. For example, the empty suppliers relation isn't equal to the empty parts relation; their bodies are equal but their headings aren't.

The second point I deliberately didn't mention before is this. Recall from Chapter 1 that, while a relation can be pictured as a table, a relation isn't a table. (To say it one more time, a picture of a thing is not the same as the thing.) Of course, it can be convenient to think of a relation as a table; after all, tables are "user-friendly"; indeed, it's the fact that we can think of relations, informally, as tables sometimes more explicitly as flat or two-dimensional tables that makes relational systems intuitively easy to understand and use, and makes it intuitively easy to reason about the way such systems behave. In other words, it's a very nice property of the relational model that its basic data structure, the relation, has such an intuitively attractive pictorial representation.

Unfortunately, many people seem to have been blinded by that attractive pictorial representation into thinking that relations as such are "flat" or "two-dimensional." But they're not. Rather, if relation r has n attributes, then each tuple in r represents a point in a certain n-dimensional space(and the relation overall represents a set of such points). For example, each of the five tuples appearing in our usual sample value for the suppliers relvar S represents a certain point in a certain 4-dimensional space, and the relation overall can thus be said to be 4-dimensional. Thus, relations are n-dimensional, not two-dimensional!^[*] As I've written elsewhere (in quite a few places, in fact): let's all vow never to say "flat relations" ever again.

^[*] Indeed, I think it could be argued that one reason we hear so much about the need for "multidimensional databases" (for decision support applications in particular) is precisely because so many people think relations aren't multidimensional.

Now I turn to the issues I want to elaborate on. There are three of them: duplicate tuples, nulls, and relations with no attributes. I'll discuss each in its own section.