Databases Reference
In-Depth Information
The next two sections (which are heavily based on material from
SQL and Relational Theory
) elaborate on
these ideas.
RELATIONS AND RELVARS
Take another look at Fig. 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 Fig. 2.1 below. That figure shows (a) on the left, a
very much reduced version of the shipments relation from Fig. 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.
relvar SP at time
T1
relvar SP at time
T2
┌─────┬─────┬─────┐ ┌─────┬─────┬─────┐
│ SNO │ PNO │ QTY │ │ SNO │ PNO │ QTY │◄
───
heading
├═════┼═════┼─────┤ ├═════┼═════┼─────┤◄──┐
│ S1 │ P1 │ 300 │ │ S1 │ P1 │ 300 │ │
│ S2 │ P1 │ 300 │ │ S2 │ P1 │ 300 │ ├─
body
└─────┴─────┴─────┘ │ S1 │ P2 │ 200 │ │
▲ └─────┴─────┴─────┘◄──┘
│ ▲
└───────────────────────────┘
relations
Predicate:
Supplier SNO supplies part PNO in quantity QTY
Propositions:
Supplier S1 supplies part P1 in quantity 300
(etc.)
Fig. 2.1: Relation values and variables—an example
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 topic, such as further normalization). In this
topic, 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 topic).
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
