Re: Objects and Relations

From: Kevin Kirkpatrick <kvnkrkptrck_at_gmail.com>
Date: 14 Feb 2007 07:36:10 -0800
Message-ID: <1171467370.842784.26350_at_l53g2000cwa.googlegroups.com>


On Feb 14, 7:12 am, "Cimode" <cim..._at_hotmail.com> wrote:
> [Snipped crap from Keith Duggar]
>
> > Nevertheless, for the benefit of other readers if nothing else, let me
> > state that Keith has hit the nail on the head.
>
> No. Keith has just once shown more misunderstanding of RM and
> arrogance.
>
> > 1) Lego blocks are /not/ the same. They always have a different
> > location attribute.
>
> BS. LegoBlock are indeed the same if they are to be a relation.
>
> Stating that location attribute is a primary natural key for a
> LegoBlock is arbitrary and does not reflect the reality of
> LegoBlocks. Imagine a M:N cardinality between LegoBlock and Location
> Entity. In that case LocationEntity has a natural identifier (X, Y,
> Z). The natural identifier of a lego block could be a combination of
> its shape, color but certainly not its location.
>
> > 2) Hence their x,y,z position attribute always identifies them.
>
> False.
>
> > 3) However this identifer is very hard to record and keep track of,
> > even though it exists.
>
> In the mind of people which pointer's obsessed maybe...
> There is nothing complex about the identifier of a location is a
> concatenation of XYZ and a referential.
>
> > 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).
>
> In other words, Surrogate identifier has only the advantage of being
> *familiar*.
>
> > 5) OID's are hence not needed, and everything is just a value, as it
> > should be.
>
> OID = Implementation of Surrogate Key IF AND ONLY IF
> --> unicity contraint has been implemented on the implementation of
> the natural key
> --> unicity constraint implemented on the OID
> --> contraint of cardinality implemented 1:1 between the
> implementation of the natural key and the OID....
>
> In other words, almost never happens...
>
> > 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.
>
> Guess we all went through this at some point in time...
>
> [rest snipped]

I have to agree with Cimode - Keith's contribution seemed a little... off. Assuming lego blocks are of the simple cuboid variety with standard male and female connectors, a configuration can be expressed as tuples in the following relation (asterisks indicate the natural key columns):

CONNECTION  (male_color*, male_thickness*, male_num_cols*,
male_num_rows*, male_column*, male_row*, female_color*,
female_thickness*, female_num_cols*, female_num_rows*, female_column*,
female_row* , rotational_angle)

Of course, this is not a complete schema - depending on application needs, one might add other base relations to enforce entegrity and store other information; for instance:
LEGO_BLOCK (color*, thickness*, num_cols*, num_rows*, price, inventory, ...)
COLOR (color*)

But the point is that there is NO need for "lego block entity" identifiers (which makes sense: an entity id might give the impression that instantiating a new red 2x3x3 LegoBlock object with OID #254 and swapping it out for an existing red 2x3x3 LegoBlock object with OID #120 somehow changes the configuration). Received on Wed Feb 14 2007 - 16:36:10 CET

Original text of this message