Re: Objects and Relations

On Feb 14, 3:46 pm, "Cimode" <cim..._at_hotmail.com> wrote:
> > 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 no less valid an attribute than colour, temperature, name, and so on.
It is often unstable, so a poor choice for a database key. But that makes it no less an identifier at any point in time.

> Location is too
> unstable(depends on the referential) to constitute a universal
> identifier for relations.

"A universal identifier for relations" - this makes absolutely no sense A relation is identified by its predicate or its enumveration.

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

Again no sense here. Perhaps you are confusing identifiers and keys.

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

Honestly, most of it I found incoherent.

>
> > 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 found my conversation with bob towards the middle of this thread I have found particularly useful. However, rest assured I am more than capable of coming to my own conclusions given what people offer.

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

I unfortunately find it hard to make head nor tail of your posts. Received on Thu Feb 15 2007 - 12:49:27 CET