Databases Reference
In-Depth Information
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 topic—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 topic, 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 Fig. 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 Fig. 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 topic, 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 topic that attributes SNO and PNO are each of type CHAR (character strings of arbitrary
length) and attribute QTY is of type INTEGER (integers).
1
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 topic 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.
2
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,
1
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 topic.
2
I say “any” relation with that body, but actually two distinct relations can have the same body if and only if the body in question is empty. If it
isn't, then there's exactly one relation having that body (see the formal definition of
relation
in Chapter 5).
