Re: Another view on analysis and ER

From: JOG <>
Date: Tue, 11 Dec 2007 03:37:29 -0800 (PST)
Message-ID: <>

On Dec 10, 6:33 pm, Jan Hidders <> wrote:
> On 9 dec, 22:10, JOG <> wrote:
> > On Dec 9, 5:20 pm, Jan Hidders <> wrote:
> > > On 9 dec, 04:04, JOG <> wrote:
> > > > Now in ontology, it is generally accepted that an
> > > > object, or entity, is nothing more than a compressence of a collection
> > > > of properties - i.e. (attribute, value) pairs.
> > > [....]
> > > I'm also not comfortable with the usage of "is" here. I'd agree that
> > > this is how entities can be described, but saying that they "are"
> > > these descriptions seems wrong to me.
> > Why are you uncomfortable with that. An entity is nothing more and
> > nothing less than the 'compressence' of its _full_ set of all its
> > attributes.
> > > After all, different descriptions may describe the same entity.
> > Well, I haven't talked about describing entities, rather we're
> > defining them. This is an entity as our model sees it, not how it is
> > seen in the real world (obviously there are concessions, given the set
> > of possible attributes is probably infinite).
> But that is what I'm saying, isn't it? These sets of properties are
> part of your model of a piece of reality and as such *represent*
> entities that are part of that reality, Saying that they *are* these
> entities is sloppy use of language and confuses the map with the
> territory. If I didn't know any better I'd almost think you could be
> accused of muddled thinking. :-)

Ha, I'll have you know that it would only be a case of muddled writing not muddled thinking sir! In my defence I'd refer you back to some posts I made a while back in another thread where I was promoting a distinction between a "construct" and an "entity" to try and avoid the very ambiguity that you are talking about. I hold little hope of changing anyones terminology though, however worthwhile I think that would be ;)

I would say though that the internal entity (henceforth referred to as a construct by myself) and the external entity, /must/ share the same identifiers for them to be consistent with each other. Its a simple rule, but without it one ends up in a artificial quagmire of hidden surrogates or OID's (which have no correspondence whatsoever with data as observed out in the wild), or worse still, broken databases.

A construct is a finite set of attributes, whereas the external entity's attribute set is obviously going to be huge if not infinite. However, if you have the right identifiers then all those other attributes exist as the consequents of material implication (i.e. if the identifier is thus, then the other attributes are...). Its the identifiers that are crucial.

> I'm afraid I have to leave it at that today because duty is calling. I
> picked this point because it seemed important and yet something we
> might soon agree on. If you want you can indicate which point you'd
> like me to address first after this one.

Well, I have always been irked by the inclusion of attribute names into 'relationships', so that seems like an interesting point to pick up. Their inclusion certainly takes us away from FOL predicates and mathematical relations. However the information content, attributenames  and all, is trivially represented in FOL if one just takes the view that the inclusion of attribute names is in fact generating an 'associative entity' - as per my previous example (2).

In other words, given the requisite for attribute-names in data modelling, entities and relationships are both just constructs, and there is nothing but benefits to be made in viewing them thus. In fact I think the benefits can be extended to solve a whole load of traditional db issues.

> -- Jan Hidders
Received on Tue Dec 11 2007 - 12:37:29 CET

Original text of this message