Re: General semantics

"Clifford Heath" <no_at_spam.please.net> wrote in message news:4bf7b594$0$3516$afc38c87_at_news.optusnet.com.au...
> Nilone wrote:
>> On May 21, 7:42 pm, Bob Badour <bbad..._at_pei.sympatico.ca> wrote:
>>>> Sorry, Bob, I think that came out the wrong way. I meant a direct
>>>> description of OOP in a RM would require a domain called OID over
>>>> which we can define relations. In current SQL systems, I could use an
>>>> integer of the same width as the address bus. I certainly don't want
>>>> to change the RM in any way.
>>> Sorry, Nilone, it's still sounds like a lousy idea to me.
>> Would you mind telling me why?
>
> I'd like to try. Codd's main insight in the RM is that anything of which
> we can speak must be distinct, that is, it must be identifiable from other
> things, especially other things of the same kind. If we can't distinguish
> a thing, then we can't safely indicate it (make reference to it), so we
> can
> never be clear of what we speak. Consequently we must require that the
> identity of a thing be intrinsic - it cannot be extrinsic.
>
> The fundamental error in OOP is the believe that an OID is a sufficient
> identifier for an object. If the OID is just a memory address, and there
> is no intrinsic identifier contained within the data stored at that
> location,
> then what happens when the object gets copied? It's a new object, and
> nothing
> intrinsic to the copy can firmly and forever associate it with the object
> from which it was copied. Consequently you are likely to be constantly
> falling
> into errors where you have the "wrong" object - meaning the wrong copy.
>
> Codd saw that a tuple must contain *within itself* a key. The keyspace
> defines a set, and then all the wonderful mathematics of sets comes into
> play, and that's the RM.

You're oversimplifying. It is not necessary for keys to be permanent identifiers. Just because a tuple contains *within itself* a key doesn't necessarily mean that that key permanently identifies an object in the domain. For example, suppose that you have a relation Bins with heading {Aisle#, Bin#} for the inventory bins in the warehouse. There is one tuple for each bin in the warehouse, and to start out with there were 10 Aisles numbered 1 through 10, each with up to 50 Bins numbered 1 through 50. Then someone with pointy hair decides to reorganize the warehouse so that there are 20 Aisles with up to 25 Bins each. While there is the same number of bins now as there were before the reorganization, what had been {Aisle#7,Bin#35} before may be {Aisle#18,Bin#13} now. It is clear that although {Aisle#,Bin#} is a key for relation Bins, instances of {Aisle#,Bin#} are not sufficient to permanently identify bins.

The wonderful world of sets is a domain that cannot change, and I think it is the ignorance of the possibility of change that is at the root of your oversimplification. Things can change; sets can't. In a domain which includes things that can change, OIDs can serve as permanent identifiers for those things when the situation demands it. (I don't think it really matters how identifiers are assigned to objects as long as they always identify the same object.)

> This idea of intrinsic identity actually comes from formal logic, so is at
> least hundreds of years older than Codd's application of the idea. Yet I
> believe that it was this connection between data and intrinsic identity
> that
> forms the core of Codd's insight and the main value of the RM - not the
> relational arithmetic or algebra that follows from it.
>
> Perhaps that goes some way to explaining why RM and OOP people are always
> going to be at odds? Sure, it's possible to model any OO system using
> relations, and likewise any RM system using objects, but that's not the
> point.
>
> The point is that *only* when you adopt the policy of requiring intrinsic
> identification do you get formal semantics, which in turn gives you the
> ability to define, detect and avoid errors.
>
> That's why it's unfortunate that Object Role Modeling uses the term
> object.
> Since Halpin's formalisation (and not prior, in NIAM - and still not even
> now in Nijssen's CogNIAM!!!), Object Role Modelling has always required
> intrinsic identification. As such, it's firmly in Codd's camp, not OOP's.
>
> Bob - if you're interested in more detail on why Nijssen's current system
> is
> inherently unsound, you'll have to take it offline with me. I won't
> discuss
> the flaws in his approach publicly, other than what I've already said.
> Suffice
> to say it's still causing problems, much to certain others' frustration.
>
> Clifford Heath.
Received on Sat May 22 2010 - 18:09:54 CEST