Re: Entity and Identity

"Clifford Heath" <no.spam_at_please.net> wrote in message news:xESvm.230730$0e4.33128_at_newsfe19.iad...
> Walter Mitty wrote:
>> I intended no pugnacity in my response.
>
> No, and I'm sorry I left that inference. I was referring
> to earlier messages in the thread, where anyone who even
> mentions the word "object" gets jumped on.
>

I'm glad you cleared that up.

My initial motive in starting the thread was precisely to get some kind of rational discussion going between people who find value in object models and people who find value in relational models. I count myself among the latter, even though my own connection with RM is much more practical than theoretical.

> My comment about not reading clearly was because I wrote
> to draw the very same distinction you reinforced. The fact
> that o-o programmers don't use mathematically pure notions
> doesn't appear to stop them producing functional systems, and
> it doesn't mean that all the concepts of object orientation
> are useless and wrong, which seems to be the mood here.
>
>> For a variety of reasons, I prefer the word "representation" to
>> "instantiation". And, in the cases you outlined, what we have is not
>> multiple representations of the same tuple, but multiple copies of the
>> same representation. It's inherent in data that data can be copied. A
>> lot of (real world) objects cannot be copied. Managing data in such a
>> way that the multiple copies of the same representation of a tuple are
>> bound together in some fashion that relates to ACID is not a pretense, by
>> any stretch of the imagination.
>
> Well, that's a fair clarification. By "pretense", I mean
> that we can pretend that the object is not even being copied.
> That pretense is not possible with almost any o-o system,
> which gives the lie to Brian's assertion that location is
> part of state. In other words, I wrote to support your side
> of the argument.
>

I should have added in the above that multiple copies necessarily occupy multiple locations. Therefore, attaching identity to location necessarily creates confusion between the identity of data structures and the identity of the entities the data is intended to represent.

AFAIK, it's always been a central concept to the relational model that the logical structure of the data is inherent in the data itself, and not in the location (read "address") of the data. If identity by means of location is central to O-O (and I don't know that it is) then that would seem to be the inital point of departure between O-O and RM. I've got more to say on this, at least from the RM side of the fence, but that can wait.

In the meantime, I want to address one point you made in your intial response. The identity (or at least the boundaries) of such things as tornadoes and persons is somewhat more subjective than logical thinkers would like to believe is the case. I think that's what you were driving at. I agree, but with a big proviso, which follows.

When we take on the task of building an information system that represents some part of the universe (read "real world"), we accept as given the division of that universe into identifiable component parts (what I call "entities"). This division is inherent in the problem statement for the information system we are to build. In our view, only mystics insist that the underlying unity of the universe is all that is real. (I'm saying "our" as if your view and mine coincide in this regard. Correct me if they don't.) Justifiably so, in my view.

If my practical experience is any guide, the community of stakeholders often has a hazy idea about just what those entities are, and very haphazard notions about how to identify them. Different parts of the community will use different identifiers to identify the same entity, and even the same identifier to identify different (although closely related) entities. Sorting that confusion out is (part of) data analysis (in the case of building a database), and it has to be done regardless of whether one intends to take a O-O or an RM view of the data. Received on Mon Sep 28 2009 - 08:47:44 CEST