Re: Objects and Relations
Date: Wed, 14 Feb 2007 14:38:54 GMT
Message-ID: <2aFAh.6379$R71.96054_at_ursa-nb00s0.nbnet.nb.ca>
JOG 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.
>
> 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 - 15:38:54 CET