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

From: Brian Selzer <>
Date: Fri, 28 Dec 2007 01:18:09 -0500
Message-ID: <By0dj.3119$>

"David Portas" <> wrote in message
> "Brian Selzer" <> wrote in message
> news:lTXcj.3065$

>> "David Portas" <> wrote in message 
>>> "Brian Selzer" <> wrote in message 
>>> news:j9Ocj.1147$
>>>>>> Here is the problem with treating assignment as the only primitive 
>>>>>> operation.  With assignment, all you have available is the before and 
>>>>>> after images of the data, but there may be many different 
>>>>>> transformations that could have produced the after image from the 
>>>>>> before image, and there's no way to tell which transformation 
>>>>>> actually occurred.
>>>>> Yes there is.
>>>> I suspect you would have a difficult time proving that.
>>> I think I would have no difficulty at all. If you can show a single 
>>> example where any such information is preserved after an update then I 
>>> can show you the equivalent assignment to preserve the same information. 
>>> It ought to be self-evident that such an assignment always exists.
>> You're sidestepping the issue.  The information need not be preserved in 
>> the database in order to be useful: it may only be needed to decide 
>> whether or not to permit an update.

> I'm not sidestepping anything. An assignment can preserve exactly as much
> information as is required. That same information is therefore available
> to a transition constraint in deciding whether or not to permit an update.

But wouldn't you have to add a bunch of extra attributes? --Attributes that once the update had been permitted would contain stale and useless information? How, for example, could you determine whether a tuple refers to a completely new individual, or to an existing individual that differs in appearance? How, again using only assignment, could you determine whether an existing individual now differs in appearance or whether it no longer exists?

>> In any case, your demonstration would not prove that there is /always/ a 
>> way to tell which transformation actually occurred.

> I think the onus must be on you to prove the opposite - to demonstrate how
> you can achieve some result via an UPDATE that cannot be achieved through
> assignment alone. Your example failed to do that so I ignored it rather
> than state the obvious.

I thought that my example demonstrated exactly that!

> Your reluctance over so many posts to show anything concrete to back up
> your assertions is truly astounding. It seems like you are not going to
> get to the point any time soon so I think I'd better leave it there. I've
> really nothing more to say than I already have.


> --
> David Portas

> Received on Fri Dec 28 2007 - 07:18:09 CET

Original text of this message