Re: Newbie question about db normalization theory: redundant keys OK?

"Brian Selzer" <brian_at_selzer-software.com> wrote in message news:542aj.25103$4V6.21112_at_newssvr14.news.prodigy.net...
>
> You're right about DELETE and INSERT, but not about UPDATE. If you look
> at UPDATE in TTM (pps. 112-113), you can see what happens:
>
> UPDATE r ( Ai := X, Aj := Y)
>
> where i <> j is supposedly equivalent to
>
> ( ( EXTEND r ADD ( X AS Bi, Y AS Bj ) ) { ALL BUT Ai, Aj } )
> RENAME ( Bi AS Bk, Bj AS Aj, Bk AS Ai )
>
> where Bi, Bj, and Bk are arbitrary distinct attribute names that do not
> appear in r.
>
> Now if you look at the result of
>
> EXTEND r ADD ( X AS Bi, Y AS Bj ),
>
> you'll notice that each tuple has both the old values and the new values
> for each affected attribute. Clearly if Ai or Aj is prime, then that
> information that ties each tuple in the result to its corresponding tuple
> in r is projected away by "{ ALL BUT Ai, Aj }". Information is lost. The
> result may be the same, but how that result was arrived at is lost in
> translation, and therefore cannot be verified.
>

"Information is lost" but no-one ever said that relational operators have to be reversible. I don't know what you mean by "cannot be verified" - the result is what it is. Assignment is still primitive because you haven't shown how an UPDATE can give a result that cannot be obtained by assignment.

-- 
David Portas