To quote the start of that section: "In managing a database, it may be
necessary occasionally to change the values of one or more components of
one or more rows that already exist within a relation. This is usually
distinguished from inserting entirely new rows because the components to
be changed in value represent a very small percentage of the number of
components in each row."
This strikes me as typical Codd pragmatism, also it is informal, really
just about motivation, and he is hinting very strongly that 'update'
should be fundamental (he doesn't mention delete before 'insert', as if
'insert' could mean wholesale replacement of the original relation). I
don't object to pragmatism at all, but this paragraph jars with the one
preceding it which is about insert and which specifically mentions set
union as a way to think of insert.
Granted in advance that I am talking only of snippets from a longish
book that has interleaved caveats and references among different
chapters but I especially note the contrast of this chapter with the
one on view updateability where he rejects certain updates as logically
ambiguous, such as insert to disjoint views that don't have enough
attributes to make the insert un-ambiguous logically. But how logical
is it to suggest an update operator without saying that it is
fundamental or providing an alternative definition, such as Date and
Darwen do, that depends on additional notions, such as their "EXTEND"?
Maybe I'm misreading and Codd is really trying to make the avoidance of
all possible ambiguities a paramount goal,eg., to protect data
designers from themselves when they overlook the Information Principle
but it seems to me that eg., it is just as logical (and pragmatic) to
allow such an insert, distributed over the relations mentioned in a
union view. Is the result of such an insert logically true? I think
George Boole would have said yes, even if he might also say today that
the intention of the user-designer combination is ambiguous as far as
the dbms is concerned. It seems to me that logic often results in
ambiguity for the human interpreter and no logical system can prevent
this totally, trying to 'picking the spots' to try to do that seems an
arbitrary exercise to me. (Regarding the recent mention of 'metrics',
I've always liked binary ones, such as "does the user find the dbms's
behavviour consistent?" or "is it intuitive?". I also noticed that Codd
advocates that users should be aware of view definitions, contrary, I
think, to D&D!)
(When if comes to implementations, I think that Codd is in basic harmony
with D&D with his emphasis on "assignment". Also, it's been many years
since I read that book all the way through and I was certainly even less
competent then to read between the lines, so if anybody else wants to
discount my reading, I'd be glad to hear that. Also, for those who are
interested, acm.org lets you download this book for free, all you have
to do is enable their 'free web' account.)