Re: Objects and Relations

On Feb 5, 1:25 pm, "David BL" <davi..._at_iinet.net.au> wrote:
> On Feb 5, 6:40 pm, "JOG" <j..._at_cs.nott.ac.uk> wrote:
> [snip]
> > 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?

Say you record an item, and then everything about it changes - every single attribute value for it is replaced, well then it is then a different item. With an OID you are mistakenly assuming that it is somehow the same thing. Hence, not only are OID's a needless mechanism as they add no value, but they also do not analogise to how we identify items in the real world, and it is a mistake to think they do. I recommend doing a good googling for identity, OID's and the information principle (especially in the archives here) for a better explanation than I can give in the few minutes I have to spend on this post.

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

Consider the person example you have mentioned in a previous post somwhere - is a person defined by his job? Some would say "I *am* a teacher", others would say "my job is a teacher". Is teacher the name of the class or the value of one of its attributes? There is no correct answer to this. When does this matter? Schema evolution in a db, or changing/expanding requirements for an application spec.

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

I think you might be confusing 'surrogates' and OID's - the label you give a human is just one of his attributes, not some external god-like barcode. I spent a lot of time vociferously confusing the two before I was corrected.

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

Agreed. Thats another why one should record propositions, statements of communicated fact, and not try to model some illusionary, abstract notion of 'entities'.

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

Yes that is possible.

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

I have never said that. What I have argued is that they are identified by their attributes and not some imaginary hidden barcode.

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

I am not a big fan of E/R. I have to teach it and I find it causes far more confusion than good when it comes to learning the principles of how to build an unbiased database. Received on Mon Feb 05 2007 - 16:29:52 CET