Re: Objects and Relations

On Feb 5, 6:40 pm, "JOG" <j..._at_cs.nott.ac.uk> wrote:
> On Feb 5, 5:09 am, "David BL" <davi..._at_iinet.net.au> wrote:
>
>
>
>
>
> > On Feb 3, 11:33 pm, "Walt" <wami..._at_verizon.net> wrote:
>
> > > "David BL" <davi..._at_iinet.net.au> wrote in message
>
> > > > Many of the wars between the OO and RM camps end up in side issues,
> > > > often with unsubstantiated performance or scalability claims or
> > > > discussions about whether physical independence is good or bad.
>
> > > > AFAIK these discussions ignore something simple and fundamental, which
> > > > I will describe in this post.
>
> > > > I have previously discussed this on comp.object (with mixed results),
> > > > and I'm interested in feedback from the relational camp.
>
> > > > Consider a web server. This can be seen at a number of different
> > > > "levels of abstraction"
>
> > > > 1. Elementary particles
> > > > 2. Atoms
> > > > 3. Molecules
> > > > 4. Electronic components
> > > > 5. Digital circuits
> > > > 6. Computer
> > > > 7. Executing process
> > > > 8. Abstract computational machine
> > > > 9. Web server
>
> > > > All of these "levels of abstraction" are equally valid. I don't want
> > > > to get into boring discussions about what's physical versus logical,
>
> > > I think I get what you're driving at with multiple "levels of abstraction",
> > > but before I get into the substance of your discussion, I want to react to
> > > your introduction.
>
> > > Layers 1 though 4 are too detailed for this discussion, and are a
> > > distraction. You can collapse them all into one big layer, the "analog
> > > layer", where digital signals are stored, transmitted, and manipulated
> > > using the Physics (and maybe Chemistry and Biology) of the underlying
> > > material world.
>
> > > The "digital circuits" layer is something many of us know only as "the layer
> > > below the last one we have studied". It deserves the mention you gave it.
>
> > > Between "computer" and "executing process", I would insert several layers
> > > of abstraction. Here are some possibilities, just off the top of my head:
>
> > > "Operating system" (Unix or Windows, etc.)
> > > "DBMS" (Oracle, DB2, etc.)
> > > "virtual machine" (like the Java virtual machine)
> > > "runtime environment" (different for various languages and for different
> > > implementations of some languages).
>
> > > And finally, "application object library". Essentially the "object world"
> > > in which all the application objects reside. It's not clear to me whether
> > > this layer is at a lower or higher level of abstraction than the executing
> > > process.
>
> > > As I said, this is off the top of my head. I'll probably change my mind
> > > later
>
> > My intention was merely to drive home the point that virtually all our
> > names for "real" objects around us can in fact be regarded as merely
> > abstractions. I have no problem calling a lump of physical matter a
> > "computer" one day and "garbage" the next when it is taken to the
> > rubbish tip. The way we interpret the world has as much to do with
> > our perception as any underlying reality (which might be strings or
> > branes in 10 or 11 spacetime dimensions according to string theorists,
> > but who knows?). I see no problem calling a collection of pixels
> > displayed on a touch screen (together with hardware/software that
> > allows it to function) a real "button".
>
> > You may well wonder why I went to the trouble to set this mindset. On
> > comp.object some people argued that the criterion of whether an object
> > represents itself wasn't meaningful because objects always represent
> > something else. For example, an instance in memory may represent a
> > pure mathematical abstraction like a "stack". On its face this is
> > quite true. However if an instance of a class called "stack" indeed
> > behaves like a mathematical stack at a certain level of abstraction
> > (in the abstract computational machine) then there is a sense in which
> > the instance is not pretending to be something else. Contrast this
> > to an Employee instance that claims to be a human. The difference is
> > that an actual human is not a part of the abstract machine. Actual
> > humans are complex, somewhat illogical entities that have no right to
> > be directly confused with objects in a running process.
>
> > Objects by definition must represent the proverbial "it". They must
> > be the "real deal". This is what object identity means. To screw
> > that up is to create lies in the program. I'm amazed that so many OO
> > programmers are happy to do this, even when it is pointed out to them.
>
> > BTW in the context of this thread, when I say "OO" I'm thinking
> > predominantly about how an instance of a data structure is thought to
> > encapsulate state, behavior and identity. I'm not particularly
> > characterizing OO by the presence of class hierarchies or by the use
> > of polymorphism.
>
> > It's my impression that a poor understanding of object identity leads
> > to designs with excessive class hierarchies. For example an Employee
> > class can be specialised in many ways, such as SalariedEmployee,
> > WagedEmployee, SalesEmployee. The fact of the matter is that
> > external entities like humans are often capable of countless
> > behaviors. Humans can be gardeners, psychopaths, circus performers,
> > parents, carnivores, mammals and so on (and often all at once). RM is
> > much better at stating factual information about humans without
> > pretending to actually represent one for real. The information about
> > a given human can and should be spread across lots of relations.
>
> First, In the outside world we only identify things by the values of
> the attributes they exhibit, and not by some omiscient OID.

I'm not sure I follow. I don't see anything innately wrong or difficult with labelling external entities with unique identifiers. I agree that entities don't generally come already labelled. Is that what you mean?

> Second the
> 'things' and 'its' of which you speak are not absolute -
> interpretation of their scope varies from individual to individual,
> and their boundaries cross and blur. Trying to 'encapsulate' one is a
> fool's errand, as they don't really exist.

I'm not sure what you mean. Can you give me an example where it matters that the scope of an external entity is subjective?

> So, Identity does not exist outside observable attributes, and
> symbolic entities do nothing but generate query bias at the logical
> layer.

I agree with the query bias but not your reason for it. For example, I see no difficulty in assigning a label to a particular human. To the extent that facts about that human will be recorded in a typical RM application there is no confusion about the scope or boundary of the human.

For me it is the problem with trying to record all conceivable information about a human in a single data structure that is problematic, and explains why OO has a hard time of it. I don't see how labelling a human in itself has any difficulties. The problem seems to have far more to do with type analysis (ie classifying humans) in order to know what attributes need to be recorded. This is the fool's errand.

> Most database theorists recognize these facts and so rely on
> liebniz equality, value based-addressing and the recording of
> propositions, and not the mythical nature of OID's and entities. Given
> this I think you may well be preaching to the wrong audience.

Probably, although it is interesting we have come to the same conclusion for quite different reasons (or do I misunderstand you)

Note that I also make claims about the limitations of RM, and these are relevant to this newsgroup.

> (As a
> side-note it is worth mentioning that E/R modelling, with its object
> based approach, was originally intended as a direct competitor to
> relational modelling, but was quickly consigned to being an
> organizational tool, useful only prior to the real data management
> work being done.)

I agree that E/R modelling should be "consigned to being an organizational tool", but again for different reasons. Unlike you I see no problem with saying entities have identity. An E/R diagram is similar in principle to a UML class diagram, in the sense that it implicitly tries to *classify* entities - ie in terms of what attributes or relations they are allowed to have or form with other entities. This is where the evil begins.

It is interesting that relations are based on "allow anything except what we prohibit", whereas E/R diagrams are based on "allow nothing except what we permit". Consider the relation

    father(F,C) :- F is father of C.

As it stands this would allow any two entities in the DB to have a father-child relationship. We use foreign key constraints to a person(P) relation to specify that F,C must be human.

Contrast this with an E/R diagram: for a given entity type, only the attributes or relationships depicted on the diagram are permitted. Received on Mon Feb 05 2007 - 14:25:43 CET