Re: Objects and Relations

On Feb 15, 3:54 am, Joe Thurbon <use..._at_thurbon.com> wrote:
> JOG wrote:
> > On Feb 14, 8:08 am, "David BL" <davi..._at_iinet.net.au> wrote:
>
> [...]
>
>
>
> > 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.
> > 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).
> > 5) OID's are hence not needed, and everything is just a value, as it
> > should be.
>
> I've found this thread really interesting, especially since it took a
> turn towards this topic. I'd like some feedback as to whether I'm
> understanding your point - I think I am.

Hi Joe, good to see you are still about.

>
> There seems to be some similarity between an OID (as I understand it)
> and a surrogate identifier as you describe it above.

Avoid this at all costs - I once stuggled with the ssme issue. An OID is not an attibute, whereas a surrogate is, and this is crucial. A value that represents a distinction in the real world must not be hidden.

Consider two twins identical in all possible ways (including name = suspend disbelief), apart from the fact they are clearly two different people (and hance have two different positions in space). They apply for a job, and the company database wants to keep track of them. A surrogate identifier such as an employee ID is used to distinguish them. They can now also be identified in the real world (at a meeting for example). Any changes in their details (perhaps one gets a pay rise) can now also be reflected in recorded propositions with their corresponding employee ID's. If we had used an internal OID we would not be able to make these distinctions in the real world.

Remember we need something *in the real world* to identify the things we talk about. The problem has to be dealt with way before we even get to the database.

>
> Would I be correct in saying that all OIDs are surrogate identifiers,
> but that not all surrogate identifiers are OIDs?

No. OID's are a programming mechanism - they are pointers.

>
> In particular, it seems that the difference is that, given some entity
> which we would like to model:
>
> (1) No two entities can share the same value for their surrogate
> identifier,

Correct, otherwise it would not identify them uniquely.

> BUT one entity can have two values for the surrogate identifier.

No. Well it is /possible/ but it is a mistake outside the databaseone  person could have two employee ID's for example, but this would cause a lot of confusion. I once ended up with two payroll numbers and it caused havoc.

>
> (2) No two entities can share the same OID, AND no entity can have two OIDs.

Again thinking in terms of entities is the path to confusion. Take a step back and think about what we are actually communicating and recording - propositions.

>
> Cheers,
> Joe

OID's and surrogates are both mechanisms to represent uniquencess. Surrogates are externally visible attribute values (goodness). OID's are obtuse, hidden pointers (badness), Received on Thu Feb 15 2007 - 11:02:01 CET