Databases Reference
In-Depth Information
heading.
4
And I would probably agree with you, if that were all there was to it; I mean, in that case life would be
fairly simple and this chapter could stop right here (it might not even be worth dignifying such a very obvious rule
with the rather grand label “principle”). But, of course, there's quite a lot more to be said on the matter. In order to
explore the possibilities further, I first need to take a closer look at the relationship between tuples and propositions.
TUPLES vs. PROPOSITIONS
As we know, every tuple appearing in some given relvar
R
at some given time represents a certain proposition, the
proposition in question being an instantiation of the relvar predicate for that relvar
R
that (by convention) is
understood to be true at the time in question. For example, here again is the predicate for relvar HP from Figs. 14.2
and 14.3:
Part PNO is named PNAME, has color COLOR and weight WEIGHT (which is greater than or equal to
17.0), and is stored in city CITY.
This relvar contains (among other things) a tuple for part P6, and that tuple represents the following instantiation of
the foregoing predicate:
Part P6 is named Cog, has color Red and weight 19.0 (which is greater than or equal to 17.0), and is stored
in city London.
Loosely speaking, then, we can say the database “contains propositions.” Now, I've said several times at
earlier points in the topic that the database involves some redundancy if and only if it says the same thing twice.
Now I can make this statement a little more precise:
Definition:
The database involves
redundancy
if and only if it contains two distinct representations of the
same proposition.
Now, given that tuples represent propositions, it's tempting to translate the foregoing definition into the
following one: The database involves some redundancy if and only if it contains two distinct appearances of the
very same tuple.
5
Unfortunately, this latter “definition” is, at best, considerably oversimplified. Let's examine it
more carefully.
First of all, it's at least true that we don't want the same tuple to appear more than once in the same relvar
(at the same time, that is), because such a state of affairs would certainly constitute “saying the same thing twice.”
(As I once heard Codd remark: If something is true, saying it twice doesn't make it any more true.) Of course, the
relational model itself takes care of this requirement─by definition, relations never contain duplicate tuples, and the
same is therefore true for relvars, and so we can ignore this possibility.
Note:
In other words, it might be argued
that a desire to avoid redundancy is one of the motivations (perhaps a minor one) for choosing sets─which don't
4
In this chapter, unlike previous chapters, the fact that the heading concept includes the pertinent attribute types is sometimes important; thus, the
term
heading
must be (re)interpreted accordingly, where it makes any difference. By way of example, the headings {PNO CHAR, WEIGHT
RATIONAL} and {PNO CHAR, WEIGHT INTEGER}, though they involve the same attribute names, aren't the same heading, precisely
because the two WEIGHT attributes are of different types. All of that being said, for simplicity I'll continue to ignore attribute types as much as I
can throughout the rest of the chapter.
5
One reviewer argued strongly that this “temptation” wasn't tempting at all! Maybe not, but I still think it's worth discussing.
