Re: pro- foreign key propaganda?

"paul c" <toledobysea_at_ac.ooyah> wrote in message news:hS1_j.163913$Cj7.63718_at_pd7urf2no...
> Brian Selzer wrote:
> ... And by the way, I suggest you read Codd's book.
>> Pages 89-90 describe the Update operator and the justification for it.
>> ...
>>
>> I could cite other instances, but I think these sufficiently show that
>> you're interpretation of Codd's use of the word 'update' is faulty.
>> ...
>
>
> That is a rather legalistic opinion of an informal, conversational
> sentence. Clearly, he is talking about an operator, not just a word.
> That aside, his intentions on this topic have often perplexed me.
>

Unless and until you agree that

(1) a database value is a snapshot of the micro-world that the database is supposed to model,
(2) values within that snapshot map to objects in that micro-world and (3) an object in the micro-world can differ in appearance between snapshots, yet still be the same object,

then you will remain perplexed. For example:

Suppose that in one snapshot you have represented three people in line at the bank: one is wearing a read coat, one is wearing a blue coat, and one is wearing a green coat.
And that in the very next snapshot you also have represented three people in line, but in this case one is wearing a read coat, one is wearing a brown coat, and one is wearing a green coat.

Is the person wearing a brown coat represented in the second snapshot a different person from the one represented in the first? Or is it the same person with a different coat?

You can't tell by simply examining the snapshots side by side as would be the case if the second snapshot were the result of a delete followed by an insert--there's no stated correlation between what is deleted and what is inserted (the person in the brown coat could be the person in the blue coat's twin), but if the second snapshot was the result of an update that targeted the value that maps to the person wearing the blue coat, then there would be no doubt as to whether the person in the blue coat is the person in the brown coat.

Clearly there is a significant difference between an update and a delete followed by an insert. It should be obvious that D&D's alternative definition that you refer to below does not acknowledge that difference, since it projects away that which correlates the existing values to the proposed values, making it impossible to differentiate between an update and a delete followed by an insert.

>
> 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.)
Received on Sun May 25 2008 - 04:43:17 CEST