Identity modelling (was: dbdebunk 'Quote of Week' comment)

Alexandr Savinov wrote:
[snip]
In general I think that we lack information on "identtity modeling" althoug it is as important as data modeling itself. Identity modeling is a separate topic, a dual part for data modeling. In other words, we can model identity ignoring object properties. And it may well be rather complex model. It will involve entities without properties - only identities. The following properties of identity make this task rather difficult:

- Identity is distributed among many entites. It can be hierarchical. For example, an element of categorization might have several segments each specifying relative position. A fully qualified identifier then is composed of several identifiers (for example, several primary keys taken from different tables - having one primary key is not enough).

- Identity cannot be considered without its scope. For example, a physical address is retricted by the scope of one computer, a primary key might be restricted by one database etc.

- Logical/physical is a relative characterization rather than absolute. Memory handle is really physical for an application program that uses it, but it is logical for operating system w.r.t. to absolute offsets in physical memory (offset may change while memory handle does not change). In this sense all those disputes about lgoical/physical are meaningless without specifying the context. Primary key may well be viewed as a physical identifier from the point of view of some higher level identification mechanism, say, global id. This means that global id is permanent while primary key it substitues may change.

- Any identifier is based on some environemnt that provides a coordinate system that it uses to produce its own identifiers. In other words, any new identification system is based on some lower level identification system (environemtn or context) with its scope and structure.

Currently no one model provides anything that would deal with the topic of identity modeling. We can model columns and object properties more or less successfully. But another side is still in darkness. We have tools to implement identification mechanisms ourselves but we do not have a theory for that.

This deserves - at least - a thread of it's own.
If it would be a /. moderation I'ld have a hard time to choose between 'Insightful' and 'Interesting'.
No time to comment at this time, though :-(

.

Relevant Pages

  • Re: joins
    ... Please read a book on data modeling and the ISO-11179 Standards. ... Let's do a clean up on schema first. ... (prod_type INTEGER NOT NULL PRIMARY KEY, ...
    (microsoft.public.sqlserver.programming)
  • Re: dbdebunk Quote of Week comment
    ... primary key is a pointer. ... In this sense the question about the meaning of pointers/keys relates to data modeling in general rather than to the RM. ... Possibly you mean an illusion of direct access like in OOP where we manipulate object like if they were directly accessible. ... meaningless without specifying the context. ...
    (comp.databases.theory)
  • Re: dbdebunk Quote of Week comment
    ... > we need an element in our model that will denote an end-user ... > althoug it is as important as data modeling itself. ... > from different tables - having one primary key is not enough). ... > Memory handle is really physical for an application program that uses ...
    (comp.databases.theory)
  • Re: FK to part of PK?
    ... >> Problem is I'd like to create a FK constraint to a part of a PK (in ... get a book on data modeling so you will stop using ... (caption_nbr INTEGER NOT NULL PRIMARY KEY, ... caption NVARCHARNOT NULL); ...
    (microsoft.public.sqlserver.programming)