Databases Reference
In-Depth Information
a.
It includes certain possibilities that we normally wouldn't regard as redundancies at all. For example,
suppose the suppliers-and-parts database is subject to the constraint that every part must be supplied
by at least one supplier. Then the projection of relvar SP on {PNO} will necessarily be equal to the
projection of relvar P on {PNO}, and we'll have a “strong redundancy” on our hands. Note: Perhaps
a more realistic example to illustrate the same point would be a constraint on a personnel database to
the effect that every department must have at least one employee.
b.
At the same time, it excludes many possibilities that we certainly would regard as redundancies─see,
e.g., the example of light vs. heavy parts in Chapter 14 (second version, as illustrated in Fig. 14.3).
Several further examples are given in later sections of the present chapter.
Even more to the point, the references to projections in the 1970 definition should be replaced by references
to projections that correspond to components of irreducible JDs . (The first of the two objections in the
previous bullet item would then go away.)
One last point on Codd's definitions: Codd did at least say (in both papers) that “we shall associate with [the
database] a collection of statements [that] define all of the redundancies” in that database. The “statements” Codd is
referring to here are Tutorial D CONSTRAINT statements (or something logically equivalent to such statements, of
course). In other words, Codd certainly wanted the system to be aware of the redundancies, and he wanted those
redundancies to be managed accordingly. Unfortunately, however, he then went on to say:
The generation of an inconsistency ... could be logged internally, so that if it were not remedied within some reasonable
time ... the system could notify the security officer [ sic ]. Alternatively, the system could [inform the user] that such and
such relations now need to be changed to restore consistency ... Ideally, [different remedial actions] should be possible ...
for different subcollections of relations.
Note: “Inconsistencies” (or, as I would prefer to call them, integrity violations) can certainly be caused by
redundancy─more precisely, by redundancy that's inadequately managed─but not all integrity violations are caused
by redundancy, of course. More to the point, I believe the database should never be allowed to contain any
inconsistencies, at least as far as the user is concerned; as I said in the previous chapter, you can never trust the
results you get from an inconsistent database. In other words, “remedying inconsistencies” needs to be done
immediately, at the level of individual statements (not even at the transaction level). 4 See the section “Managing
Redundancy” later in this chapter.
DATABASE DESIGN IS PREDICATE DESIGN
Although I've had a lot to say in previous chapters about both predicates and constraints, I haven't explicitly called
out the difference between these concepts. So let me remedy that deficiency now. First, the predicate─sometimes
more explicitly the relvar predicate, for definiteness─for a given relvar R is the intended interpretation , or meaning ,
for R . Of course, every user of a given relvar R is supposed (or assumed!) to understand the corresponding
predicate; note, however, that─at least in today's implementations─predicates are stated in natural language and are
therefore somewhat informal in nature, necessarily.
4 See SQL and Relational Theory for a defense of this possibly rather unorthodox opinion. Let me add, with little by the way of elaboration,
that the position implies a requirement for the system to support multiple assignment , which is a form of assignment that allows several
variables─in particular, several relvars─to be updated “simultaneously” (i.e., within the confines of a single statement).
Search WWH ::




Custom Search