Re: Objects and Relations

From: JOG <>
Date: 14 Feb 2007 04:09:35 -0800
Message-ID: <>

On Feb 14, 8:08 am, "David BL" <> wrote:
> On Feb 14, 2:42 pm, "Keith H Duggar" <> wrote:
> > David BL wrote:
> > > I've been thinking about the following example: There is a
> > > collection of Lego pieces and we want to store information
> > > about how they have been connected in various configurations.
> > You are begging the question since "Lego pieces" assumes
> > entities. That is, I'm certain in your mind piece = entity.
> I'm trying not to assume anything! But surely in order to state the
> problem, nouns will appear in the natural language sentences.
> > > An interesting question is whether we try to distinguish
> > > pieces that for all intensive purposes look the same.
> > The phrase is "intents and purposes". And "look the same"
> > hardly encompasses all the facts we can state (see below).
> > > It would appear not, otherwise we will be forced to get
> > > out a felt tip pen and give them unique identifiers, and
> > > we don't want to do that. Therefore a particular piece is
> > > only described (but not uniquely identified) by its
> > > attributes (eg its colour and dimensions).
> > You seem to have completely forgotten about /location/ in
> > space even though you started by mentioning "configurations"
> > which has everything to do with location.
> Yes I see that. The pennies are falling!
> I was assuming there happens to be no need to specify exact locations
> of pieces in space using (x,y,z), but we do need to represent the way
> pieces have been snapped together. ie we were told that in the
> problem specification.

I hope that the pennies really are falling. I am seriously dubious as to the intentions of your posts.

Nevertheless, for the benefit of other readers if nothing else, let me state that Keith has hit the nail on the head.

  1. Lego blocks are /not/ the same. They always have a different location attribute.
  2. Hence their x,y,z position attribute always identifies them.
  3. However this identifer is very hard to record and keep track of, even though it exists.
  4. So we represent it with a surrogate identifer (which is hence just an 'untrackable' attribute or, as others refer to it, an unfamiliar attribute).
  5. OID's are hence not needed, and everything is just a value, as it should be.
  6. When I finally understood this (and it was a hard mental slog to shake off my OO mindset) I found it quite revelationary to my perspective on data management.

And that's it. That's how we work everyday. If we ever have to do deal with items that are indistinguishable by anything but physical location (or any characteristic we can't keep track of), we tag them with a surrogate identifier to represent their unique nature. It's just common sense really.

As an addendum, once implemented a surrogate key becomes a natural key. I find this fascinating - it seems somehow analagous to "Nature abhoring a vacuum".

> [rest snipped]
Received on Wed Feb 14 2007 - 13:09:35 CET

Original text of this message