Re: Surrogate primary key plus unique constraint vs. natural primary key: data integrity?

On 12 mar, 20:56, Roy Hann <specia..._at_processed.almost.meat> wrote:
> Cimode wrote:
> > Any theory is nothing but natural, including relational theory.
>
> Huh?  Is that what you intended to write?  That makes no sense as it
> stands.
Apologies but I have no other way to say this. It means exactly what it says.

> >> value assigned outside the enterprise of interest that is a key
> >> used within it is "natural".
> > An *enterprise of interest* does not say anything about the fact
> > that a surrogate key may at some future point in time be considered a
> > natural key.
>
> The enterprise of interest (EoI) doesn't "say" anything, ever.  It is
> merely the context for a conceptual model.

> The EoI is whatever my
> customer/user tells me it is. If my customer tells me he is given some
> information and I am satisfied it uniquely determines an entity in his
> EoI then it is a natural key in his EoI. There really is no room to
> argue that it is not.

A design effort should also be an as-faithful-as-possible representation of a segment of reality in time. As I mentioned, I am not interested discussing this specific subject at length.

> > But the point is that subjectivity can not be taken from
> > the equation in any scheme involving establishing a unique identifier.
>
> I think you have abbreviated this argument excessively.  I really don't
> see your point.
I believe the hidden point of the thread was about what would give the impression that there is such thing as a natural or primary key since there is not.

I rephrase my take on that :

1> Any key is at some point in time a surrogate key . There is no such thing as a natural key.
2> A design effort to represent a segment of reality is bound to designer's subjectivity. (Designers are not machines). 3> Tuple distinguishibility is a part of the design effort, involving upgrade of surrogate to natural key.

1 + 2 + 3 implies designer's own subjectivity partly explains the impression hat there would be such thing as a primary key.

> >> A credit card number is a synthetic/surrogate key in the card issuer's
> >> database but it's a natural key in the merchant's database.
> > See above.
>
> See what above?  And why?  Your brevity borders on cryptic.
I make the exact same point you are making. I am merely using different terminology.

> > Explaining distinguishibility seems a more important challenge
>
> Another cryptic squib.  What is challenging about it?
Explaining distinguishibility of tuples vs distinguishibility of physical rows is a challenge to most developers since most of them confuse Logical/Physical Layers. .

> Roy
Received on Tue Mar 12 2013 - 22:09:34 CET