Re: Trying to define Surrogates

"Bob Badour" <bbadour_at_pei.sympatico.ca> wrote in message news:5T1Fg.50742$pu3.588779_at_ursa-nb00s0.nbnet.nb.ca...
> JOG wrote:
>
> > Bob Badour wrote:
> >
> >>JOG wrote:
> >>
> >>>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.
> >>
> >>We do that every time we create a candidate key. It isn't familiar until
> >>it is used, and then it is.
> >
> > Ok, if you are using the term 'familiar' to correspond to 'did not
> > previously exist prior to the data modelling process' then we agree.
> > Nonetheless I find that use of the term 'familiar' extremely woolly,
> > and think it is likely to cause confusion.
>
> It is woolly, which is why I think the concept of a natural key is not
> altogether useful. The objections to natural keys relate to control. If
> you create and control the key, it doesn't matter to you how familiar
> the key is to others.
>
>
> > I also still contend that the need to create such a surrogate only
> > occurs if we can't encode a natural attribute directly, or if the
> > distinguishing attribute is an extremely unstable one, such as
> > location. Anything else appears sloppiness on the designers part to me.
>
> A surrogate for location is not really all that useful unless one takes
> the additional step of making location unimportant. In other words, if
> the only distinguishing feature is location, assigning an arbitrary
> number won't change that fact unless one also records the number on the
> physical item.

A surrogate key for a location identifies a location, not necessarily an object located there. Objects can be moved around without changing their identity. Using a surrogate key for the location as an identifier for an object at that location is yet another case of attributing to an object an attribute that really described a related object.

The above isn't really clear, so I'm providing an example for other readers: "The can of Cambell's chicken noodle soup that I'm holding in my left hand". Helps to identify the can, but not for long.

Believe it or not, I'm dealing with this very issue in the real world right now. There are these things called "bankers boxes", which are cardboard boxes designed to store a large number of paper documents. In the town hall of my town, we've got these boxes with contents dating back to the Civil War (referred to as "The Great Rebellion".) At the end of each box is a label area, and one field in the label area is marked "location".

Properly used, this field would tell you where a box gets stored, if it's been pulled out of storage. However, some people have mistakenly used "box location" as an identifier for the box. No problem until you reorganize the storage. Come to think of it, this is one of the great problems with the graph data model! And here it surfaces in an environment that has nothing to do with modern computers (until now). Received on Sat Aug 19 2006 - 16:22:35 CEST