Re: A real world example

"Brian Selzer" <brian_at_selzer-software.com> wrote in message news:MNCDg.8096$9T3.560_at_newssvr25.news.prodigy.net...
>
> "Bob Badour" <bbadour_at_pei.sympatico.ca> wrote in message
> news:fqmDg.39802$pu3.533163_at_ursa-nb00s0.nbnet.nb.ca...
>
> [snip]
>
>> A natural key is simply a familiar surrogate. Nothing more. Nothing less.
>
> I disagree. A the value of a surrogate (at least according to Codd, and
> also Date, if I recall correctly) should permanently identify something.

The only way one can have an attribute whose values never change is by violating information principle.

> That has always been my understanding, and that has always been how I've
> used the term. Natural keys can change and still refer to the same thing.

Nothing in surrogacy suggests immutability of values.

> It's easy to prove. Consider a relation schema that describes employees
> and has two candidate keys, Social Security Number and Badge Number. If
> an employee gets a new Badge Number because he lost his badge, does the
> new Badge Number refer to the same employee? The answer is obvious: if it
> didn't, then the fact that the Social Security Number didn't change
> contradicts that. The definition of a candidate key guarantees that the
> propositions in a single relation value are unique; therefore, a candidate
> key value can identify a tuple, but only within a single relation value.
> In order to span multiple database states, that value must be permanent.
> Codd understood this even if you can't get it through your head: I refer
> you to the paper he wrote in 1979, "Extending the Database Relational
> Model to Capture More Meaning."

Perhaps you may want to read through the contradictions in Codd's RM/T paper.
http://www.intelligententerprise.com/db_area/archives/1999/990106/online1.jhtml

--
Anith


>

> [snip]

>

>