Re: Objects and Relations

From: Cimode <>
Date: 14 Feb 2007 07:46:39 -0800
Message-ID: <>

> I can't even understand the grammer of this sentence.

If I am not mistaken, it is *grammar*. What I meant is that LegoBlock and Location concepts should be separated if LegoBlock is to be considered a relation. A relation *must* have a stable primary key. Location is not a stable primary key therefore it does not identify LegoBlock. Please be sincere.

> > 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.
> Location always identifies something.
And why would that be? Locations just locates. One identifies by describing its characteristics, shape etc...Location is too unstable(depends on the referential) to constitute a universal identifier for relations.

> Two things cannot be in the same
> place. It's sort of a law of physics, and I've got to be honest,
> knowing it has tended to help me in daily life. Like if my tv is in
> the corner of the room my car probably isn't there too.
I understand. I can understand the practical aspect of things but RM characterictics of a pk are well defined. Locations are not But that's no reason for calling them alike.

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

> Hi Cimode. Your post has more mistakes in it than I have time to point
> out.
What mistakes? Which part does not seem logical ?

> Given that I disagree with what you have just (apparantly randomly)
> splurged onto the page (yet posting it in the demeanour of an expert)
> so wholeheartedly, I was wondering if perhaps I could claim a 'Fraud'
> number.
Until now, I have not considered you as a Fraud, but I am afraid and hope not that BB's brainwash is about to pay off.

I am trying to help you get another pov about RM that is way too wide to be locked up in BB's or my definitions. Received on Wed Feb 14 2007 - 16:46:39 CET

Original text of this message