Oracle FAQ Your Portal to the Oracle Knowledge Grid

Home -> Community -> Usenet -> comp.databases.theory -> Re: Objects and Relations

Re: Objects and Relations

From: Bob Badour <>
Date: Wed, 14 Feb 2007 14:38:54 GMT
Message-ID: <2aFAh.6379$>

JOG wrote:

> 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.

To amplify, the location might be familiar and perhaps even unique, but it is neither simple nor stable.

> 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).

The scare quotes are very appropriate, because we do track the identifier. We track it in a relation that acts as a legend mapping the identifier to what it identifies, which might be a location or a location and color or a location, color and size or a location, color, size and orientation.

Think of a legend on a map associating colors and symbols with features of interest. Or think of assembly instructions folded up in the little plastic bag of nuts and bolts and washers--they serve the same purpose of associating a generic item with a specific location.

> 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".

I think it has more to do with the human drive to communicate. Received on Wed Feb 14 2007 - 08:38:54 CST

Original text of this message