Re: Objects and Relations

On Feb 6, 12:29 am, "JOG" <j..._at_cs.nott.ac.uk> wrote:
> 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.

Ah I think I understand what you're saying. However I regard the label as an attribute and therefore by your assumption that changes as well.

> With an OID you are mistakenly assuming that it is
> somehow the same thing.

No because the label was changed.

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

We don't always label things, but we often do and it can be very useful.

I think I understand your perspective but don't particularly like the way you're saying it!

In a sense I regard every attribute value as a label. For example 57 is a label for one of the integers (a mathematical entity). A relation is stating postulates about external entities (either mathematical or "real" like a particular human) that can be identified in some way.

Attributes are value types not object types. For example two different instances of the number 57 (perhaps appearing as attribute values in different tuples) represent the same underlying Platonic mathematical entity. By contrast object types have an identity separate from their value - hence the difference between identity testing and value testing.

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

I shall!

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

I think you're talking about the subjective nature of how to represent knowledge about external entities, rather than a problem associated with labeling external entities. The difficulties you site have to do with a type analysis of entities, such as asking what attributes an entity type needs in your model.

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

I'm not clear why you think I'm confused about that. It seems we agree that a label is just one of the attributes (and optional at that). That is inconsistent with your earlier reasoning used to show that an OID is a "needless mechanism".

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

Again I differ in the explanation. The entities aren't illusionary or abstract. The problem is with entity types. A particular human can be labeled and take part in all sorts of well defined and specific relationships in a relational model. It is the type analysis of humans that is illusionary or abstract.

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

I agree with that but don't see how that explains why E/R diagrams can be problematic. The claim that entities are illusionary or abstract doesn't appeal to me.

As I see it RM makes no attempt to provide complete models of the external entities, and in a way that's what the closed world assumption is all about. The idea that an entity is completely characterised by the (currently modeled) attributes doesn't ring true to me. I would rather say that the model only tries to store a subset of all possible facts that could be made about the external entities.

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

Agreed. Received on Tue Feb 06 2007 - 06:26:31 CET