Re: Entity and Identity

On Jul 20, 11:51 am, "Walter Mitty" <wami..._at_verizon.net> wrote:
> I've known for quite some time that better minds than mine have gone astray
> in the attempt to overcome the object relational mismatch.  Just last week,
> I ran across an article that outlines the O-R mapping problem better than I
> ever could.
>
> The article is called "The Vietnam of Computer Science", and here's a
> pointer:
>
> http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Computer+Science...
>
> The article devotes rather too much time to exploring the analogy between
> the Vietnam war and ORM attempts.  And as the article admits, all analogies
> eventually fail.  Leaving that aside, I think the survey of problems
> encountered in crossing the divide is excellent.
>
> I want to draw particular  attention to a heading entitled "Entity Identity
> Issues".  Reading this section gave me a better understanding of the
> disconnect between me and Brian Seltzer over matters concerning entity and
> identity.  My own view of identity is colored by my own experience.  And
> that experience includes some practical work with relational databases,
> preceded by a little formal learning in that area and 20 years of work as a
> programmer.  Unfortunately, none of that work included object oriented
> programming.
>
> Anyway, my view of identity (or of identification, if you prefer) is that an
> object's state is all we have to go on as the basis for identification.  In
> particular, an object's location (as specified by a pointer) or its
> trajectory (a history of pointers over time) are unavailable for purposes of
> identification.  This view of identity fits pretty comfortably into the
> relional model, but it runs afoul of object oriented thinking at least two
> important ways.  Frst, if an object can conceal part of its state
> (encapsulation),  then it necessarily can conceal some of what needs to be
> known to identify it.  Second, if two objects  are identical in state, then
> they are the same object, even if they differ in location (at the same point
> in time).  I'll call this the "Doppelganger effect".

First, it doesn't matter if objects can conceal part of their states provided that the references to those objects can be used to distinguish between them, and second, if two objects are identical in state, then they cannot differ in location, for that would constitute a difference in state. In the OO world, those references are OIDs, whose lifetimes coincide with the lifetimes of their respective objects. Outside the OO world, an identification describes an object, but just at one time: there can be many descriptions of the same object at different times, and what describes one object at one time may describe another object at another time. For objects to be identical, every description must coincide--that is, at each time in their lifetimes, what describes one object must also describe the other.

> When I see an SQL table with two different rows in one table that cannot be
> distinguished by their contents, my reaction is that the database designer
> made a mistake.  Failing in that, the database updaters should have been
> more careful.  Cases where duplication is intentional and carries
> significant information strike me as a misuse of SQL, and a misunderstanding
> of the relational model.
>
> The above doesn't pretend to explain Brian's view.   But I think it sheds a
> little light on why I see things the way I do.
>
> Again, I recommend the article cited above.
Received on Mon Jul 20 2009 - 19:47:46 CEST