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