Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

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

Re: Objects and Relations

From: David BL <davidbl_at_iinet.net.au>
Date: 14 Feb 2007 05:38:24 -0800
Message-ID: <1171460304.426640.259970@a34g2000cwb.googlegroups.com>


On Feb 14, 9:09 pm, "JOG" <j..._at_cs.nott.ac.uk> wrote:
> On Feb 14, 8:08 am, "David BL" <davi..._at_iinet.net.au> wrote:
>
>
>
>
>
> > On Feb 14, 2:42 pm, "Keith H Duggar" <dug..._at_alum.mit.edu> 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.

I have decided to completely change my approach. I am trying to completely ignore the subconscious urge to see things in the way I feel comfortable with, to try to see it from your shoes. I chose the Lego example because I thought maybe you were going to show me how it was useful to not think of the pieces as entities. That hasn't been the case in this example because the location information ends up uniquely identifying the Lego pieces anyway. However it does show how it can be useful to employ a natural key rather than a surrogate. I guess in the end that hasn't really been a source of confusion for me. I have no problem thinking of surrogate identifiers as merely attributes.

I assure you that my intentions are sincere.

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

If we indeed choose to introduce a surrogate identifier then I don't see why we can't call it an entity identifier. The article in Wikipedia appears to confirm that.

Is there some other reason why you say that a key shouldn't (generally) be regarded as an entity identifier? Perhaps you could refer me to the relevant literature or a previous thread on cdt.

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

You lost me there. What do you mean by implemented? In what sense does it /become/ a natural key? Received on Wed Feb 14 2007 - 07:38:24 CST

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US