Re: Trying to define Surrogates

erk wrote:
> JOG wrote:
> > My name is an identifier for me.
> > My fingerprint is an identifier for me.
> >
> > Say we don't have the ability to digitise the photos we have of
> > fingerprints. Then we produce:
> >
> > 532673294 is a identifier for my fingerprint, which is a identifier for
> > me.
> >
> > The 2nd level of indirection in the last line indicates use of a
> > representative for an attribute that existed naturally before the
> > design of the database. It is not that it is just wasn't 'familiar', it
> > didn't exist at all - we have made the domain up specifically to
> > facilitate the information modelling process. We have not just modelled
> > the propositions we have added to them.
> >
> > That for me is the distinction made when I see the word surrogate in
> > context of databases.
>
> I think this is a fairly specific case where the natural key isn't
> easily manipulated, but it's a bit of a hack, and a fairly specific
> case. I think the more common use of a surrogate key is where no
> natural key exists - to separate cans of Campbell's chicken noodle
> soup, you need to give them an artificial label. This label sometimes
> makes it into the real world as well.

are you telling me that two Cans of Campbell's have no identity without an artificial label? If that were true you would not be able to distinguish them, yet you can. What, then, is that distinguishing property?

>
> In the case of fingerprints (a domain about which I'm speculating), I
> suspect that as implied by CSI there are specific points and tangents
> on the print that, collectively, act as a hash function to some numeric
> value. That value is derived entirely from the digital scan, and can be
> the key. The case of two fingerprints hashing to the same key would be
> a problem, of course - but probably no more than that of SSNs.
>
> Either way, the key would be not an identifier for the print, but
> derived directly from the print domain. That's different than a
> surrogate key as normally defined.
>
> - erk
Received on Thu Aug 17 2006 - 17:48:51 CEST