Re: Trying to define Surrogates
Date: 19 Aug 2006 21:00:03 -0700
Message-ID: <1156046403.402798.262870_at_i3g2000cwc.googlegroups.com>
David Cressey wrote:
> "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.
You have just arbitrarily created a "location" entity from the ether. I could equally create a "moment" entity and say denoting a presidency's start date, for example, is another case of attributing to an object an attribute that really described a related object. You could do the same for just about anything.
One of the problems of all this of course is the undefinable nonsense of what a thing/entity/object is.
>
> 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.
So it's very unstable in most cases. Granted, but what relevance is that apart from it's not a very stable key choice?
>
> 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.
I don't envy you.I hope they're also numbered to represent their unique location attributes with a bit more stability ;)
> 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 Sun Aug 20 2006 - 06:00:03 CEST