Re: Entity and Identity

Walter Mitty wrote:
> 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.

To define the boundaries of the natural concept "object" isn't easy in the real world. For example, what is a tornado? Even a human is just a thermodynamic process occurring within an illdefined  and ever-changing set of atomic particles. In the OO community, the problem is finessed; the identity is assumed to exist just as the identity of a human or a tornado is assumed to exist; then the programmer makes use of the known behaviour of their machines to make that assumption to appear as mostly true.

The RM is a self-contained model, and as such, can circumscribe the identity of a tuple, and it requires specifying a means to identify every tuple.

> if two objects are identical in state, then
> they are the same object, even if they differ in location

On the other hand, it's both possible and expected that two different running programs have a given tuple in memory at the same time, or at the same time that the row still exists in storage We like to pretend that all these instances are the same tuple. We can get away with that pretense *only* because of the fact that we manipulate the tuples only within the confines of a DBMS that conforms to ACID restrictions.

Even if you use a definition of "object" which *does* have formal semantics (as, for example, it does in Terry Halpin's "Object Role Modeling"), concurrency still requires that we create this pretense.

Terry's book "Information Modeling and Relational Databases" presents Object Role Modeling (ORM2; an unfortunate conflict of acronyms with O/RM) and compares it with various ER languages and with UML class diagrams, showing the drawbacks of all the languages. ORM2 is fact-oriented, which is isomorphic with RM in the same way (and because) set theory and first-order logic are isomorphic. ORM2 tools map to the relational model and generate also SQL. It's a very important book that should be read by everyone who has to design a database. Easy to read, replete with good examples, but long... it's a big subject!

My derivative of ORM2, the Constellation Query Language, is a controlled natural language which, as well as SQL, generates object-oriented class libraries. These classes do not have the same drawbacks as common object systems, because:

• every object is either a value or an entity
• values are identified by their lexical representation
• entities are identified by a set of one or more functional roles
• objects exist only within a Constellation
• a Constellation never contains a duplicate object
• an object cannot be created or destroyed, only asserted or denied within a Constellation.

For more details, see the ActiveFacts project page at http://dataconstellation.com/ActiveFacts

--
Clifford Heath, Data Constellation, http://dataconstellation.com
Agile Information Management and Design