Re: A real world example

anithsen_at_gmail.com wrote:

> "Brian Selzer" <brian_at_selzer-software.com> wrote in message
> news:MNCDg.8096$9T3.560_at_newssvr25.news.prodigy.net...
> 

Cite? The value of a candidate key is it permanently identifies something; hence, the importance of stability as a design criterion. That is as true for natural keys as for surrogates.

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

How so? I agree that hiding an attribute violates the information principle, but I don't see how precluding changes does.

>>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.

Selzer's understanding is flawed. I suggest he should try harder to use correct terms.

> Nothing in surrogacy suggests immutability of values.

Hear! Hear!

>>It's easy to prove.

If one accepts Selzer's definitions of terms, then by definition nothing needs proof. However, his definitions of terms differ greatly from the generally accepted definitions, which makes any pretense of communication with him pointless.

   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 badge number logically identifies a badge and does so immutably. The attribute describing the employee merely describes the current assignment of a badge to the employee.

Suppose a criminally minded individual finds the lost badge and uses it to gain unauthorized access to the employer's resources. Where does Selzer's proposed schema record who the badge is assigned to?

In the example he gave above, he proposed two arbitrarily assigned numbers as candidate keys. What is a surrogate if not an arbitrarily assigned number?

The numbers happen to be somewhat familiar because the employee already uses the SSN for his taxes, and the badge number presumably appears on a physical artifact handed to the employee: ie. the badge. The familiarity of the keys makes them natural keys.

   The answer is obvious: if it
>>didn't, then the fact that the Social Security Number didn't change
>>contradicts that.

Ironically, the idiot is too stupid to realize that SSN's are just as mutable as badge numbers. While one may not legally have two SSN's at the same time, transcription errors and identity theft mean SSN's do change over time from the perspective of the organization.

   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

True.

, but only within a single relation value.

Bullshit. See foreign key references.

>>In order to span multiple database states, that value must be permanent.

Well, duh. This is why stability is an important design criterion for choosing candidate keys. Saying that stability is an important design criterion is a wholly unremarkable statement. If that is what the idiot was trying to say, why didn't he just say it?

>>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

Indeed. Thank you. Received on Mon Aug 14 2006 - 15:44:56 CEST