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: JOG <jog_at_cs.nott.ac.uk>
Date: 14 Feb 2007 07:22:40 -0800
Message-ID: <1171466560.218311.163070@j27g2000cwj.googlegroups.com>


On 14 Feb, 13:12, "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.

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

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

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

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.

I have been feeling /decidedly/ left out in this area of late. Received on Wed Feb 14 2007 - 09:22:40 CST

Original text of this message

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