Take another look at Figure 1-1, the suppliers-and-parts database, in Chapter 1. That figure shows three relations: namely, the relations that happen to exist in the database at some particular time. But if we were to look at the database at some different time, we would probably see three different relations appearing in their place. In other words, S, P, and SP are really variables—relation variables, to be precise—and just like variables in general, they have different values at different times. And since they’re relation variables specifically, their values at any given time are, of course, relation values.
As a basis for examining these ideas further, consider Figure 2-1 below. That figure shows (a) on the left, a very much reduced version of the shipments relation from Figure 1-1; (b) on the right, the relation that results after a certain update has been performed. Using the terminology of the previous paragraph, then, we can say, that (a) on the left of the figure we see the relation value that’s the value of relation variable SP at some particular time T1; (b) on the right, we see the relation value that’s the value of that same relation variable at some presumably later time T2, after an additional tuple has been inserted.
So there’s a logical difference between relation values and relation variables. The trouble is, the database community has historically used the same term, relation, to stand for both concepts, and that practice has certainly led to confusion (not least in contexts that are the subject of the present book, such as further normalization). In this book, therefore, I’ll distinguish very carefully between the two from this point forward—I’ll talk in terms of relation values when I mean relation values and relation variables when I mean relation variables. However, I’ll also abbreviate relation value, most of the time, to just relation (exactly as we abbreviate integer value most of the time to just integer). And I’ll abbreviate relation variable most of the time to relvar; for example, I’ll say the suppliers-and-parts database contains three relvars (more precisely, three base relvars; views are relvars too, but I have little to say about views as such in this book).
Aside: Actually, there’s one thing I do want to say about views. The Principle of Interchangeability (of views and base relvars) says, in effect, that—at least as far as the user is concerned—views are supposed to look and feel just like base relvars. (I don’t mean views that are defined as mere shorthands, I mean views that are intended to insulate the user from the “real” database in some way. See Chapter 15 for an elaboration of this point.) In general, in fact, the user interacts not with a database that contains base relvars only (the “real” database), but rather with what might be called a user database that contains some mixture of base relvars and views. But that user database is supposed to look and feel just like the real database as far as the user is concerned; thus, all of the design principles to be discussed in this book—e.g., the principles of normalization—apply equally well to such user databases, not just to the real database. For this reason, I’ll feel free to use the unqualified term relvar throughout this book, relying on context to indicate whether the term refers equally to base relvars and views or just to base relvars (or just to views) specifically. End of aside.
Let’s get back to Figure 2-1. As that figure indicates, relations have two parts, a heading and a body. Basically, the heading is a set of attributes, and the body is a set of tuples that conform to that heading. For example, the two relations shown in Figure 2-1 both have a heading consisting of three attributes; also, the relation on the left of that figure has a body consisting of two tuples and the one on the right has a body consisting of three. Note, therefore, that a relation doesn’t really contain tuples, at least not directly (it contains a body, and that body in turn contains the tuples). In practice, however, we do usually talk as if relations contained tuples directly, for simplicity. Points arising:
The terminology of headings and bodies extends in the obvious way to relvars too. Of course, the heading of a relvar (like that of a relation) never changes—it’s identical to the heading of all possible relations that might ever be assigned to the relvar in question. By contrast, the body does change; to be specific, it changes as updates are performed on the relvar in question.
When I get to the more formal treatment in Part II of this book, I’m going to (re)define a heading as a set of attribute names. The difference between the two definitions isn’t important for present purposes, however.
In fact, it would be still more correct to define a heading as a set of attribute-name/type-name pairs (and to require the attribute names in question all to be distinct). For example, I’m going to assume in examples throughout this book that attributes SNO and PNO are each of type CHAR (character strings of arbitrary length) and attribute QTY is of type INTEGER (integers).[15] And when I talk about tuples conforming to some heading, I mean each attribute value within the tuple in question must be a value of the pertinent type. For example, in order for a tuple to conform to the heading of relvar SP, it must have attributes SNO, PNO, and QTY (and no others), and the values of those attributes must be of types CHAR, CHAR, and INTEGER, respectively. (All of that being said, I must now say too that types aren’t very important for the purposes of relational design theory. That’s why I feel free in this book to simplify my definition of what a heading is. What’s more, I’ll also feel free, in many of my sample relvar definitions, to give the attribute names only and not even mention the types.)
The number of attributes in a given heading is the degree of that heading. It’s also the degree of any relation or relvar with that heading. Likewise, the number of tuples in a given body is the cardinality of that body, and it’s also the cardinality of any relation or relvar with that body.[16] Note: The term degree is also used in connection with both tuples and keys (including foreign keys). For example, the tuples of relvar SP are all, like that relvar itself, of degree three, the sole key of that relvar is of degree two, and the two foreign keys in that relvar, {SNO} and {PNO}, are each of degree one.
The degree (of a heading or relation or ...) can be any nonnegative integer. Degree 1 is said to be unary; degree 2, binary; degree 3, ternary; ... and, more generally, degree n is said to be n-ary.
[15] It would be more appropriate to define QTY to be of type NONNEGATIVE_INTEGER (with the obvious semantics), but few DBMSs if any support such a type. Of course, we could introduce it as a user defined type, but I don’t want to get into details of user defined types in this book.