Figure 1-3 shows a relation with the formal names of the basic components marked. Those of you who know something about relational design will recognize that the relation is not in normal form. That's okay; it still qualifies as a relation because it's arranged in row and column format and its values are scalar.
Figure 1-3. The Components of a Relation
The entire structure is, as we've said, a relation. Each row of data is a tuple (rhymes with "couple"). Technically, each row is an n-tuple, but the "n-" is usually dropped. The number of tuples in a relation determines its cardinality. In this case, the relation has a cardinality of 18. Each column in the tuple is called an attribute. The number of attributes in a relation determines its degree. The example relation has a degree of 3.
The relation is divided into two sections, the heading and the body. The tuples make up the body, while the heading is composed of, well, the heading. Note that in its relational representation the label for each attribute is composed of two terms separated by a colonfor example, UnitPrice:Currency. The first part of the label is the name of the attribute, while the second part is its domain. The domain of an attribute is the "kind" of data it representsin this case, currency. A domain is not the same as a data type. We'll be discussing this issue in detail in the next section. The specification of domain is often dropped from the heading.
The body of the relation consists of an unordered set of zero or more tuples. There are some important concepts here. First, the relation is unordered. Think of a relation as a brown paper bag (or perhaps a Ming bowl if you're feeling poetic) containing all the tuples in no particular order. Record numbers, a common mechanism to access records in non-relational databases, do not apply to relations. Second, a relation with no tuples (an empty relation) still qualifies as a relation. Third, a relation is a set. The items in a set are, by definition, uniquely identifiable. Therefore, for a table to qualify as a relation, each record must be uniquely identifiable and the table must contain no duplicate records.
If you've read the Access or SQL Server documentation, you might be wondering why you've never seen any of these words before. They're the formal terminology used in the technical literature, not the terms used by Microsoft. I've included them just so you won't be embarrassed at cocktail parties (at least not about n-tuples of third degree, anyway).
Unfortunately, not only do Microsoft products not conform to formal terminology, they're not consistent. The terms used by the two products are shown in Table 1-1. I'll use the formal terminology in this book.