Re: some information about anchor modeling

> In this example, I have two identifiers, both belonging to one database structure. The first identifier identifies a real object car; while the second identifier identifies an abstract object that is a state of this car. Everything else in this relation represents the knowledge about one attribute. Once again, notice that the state of an object is an abstract object. For example, you can not touch the state, while the object car you can.
>
> A state of an entity, I have defined as any knowledge about that entity, which has some subject. As I said, these two identifiers are linked and are located in one database structure, which I call the state of an entity. The identifier of the state identifies the state of the entity, but can not identify the entity. The identifier of the entity identifies the entity, but can not identify a state of the entity. However, the state structure connects these two identifiers. This is my solution, which connects the identification of an abstract object with the identification of the real object, and vice verse.
>
>
>
>
>
> Obviously, my solution is not a surrogate.
 

1. Now I would like to separate this subject, and to give it the appropriate title. I think this will help a better understanding of this very complex matter.

How a database stores an object and how a database can remember of its objects?

So how the stuff work? Is there a general algorithm that manages the objects in the database? Such an algorithm should have the following steps:

First, I will define the basic concepts. In the database, each object was selected using a procedure which performs the identification of this object. Each object in the database has its identifier. All objects stored in the databases are treated as abstract objects. In the general case, we have the following three kinds of abstract objects:

1. The abstract object that represents a real object. In this case, the real object and the corresponding abstract object in the database have the same identifier.
2. This kind of abstract object is the result of the human imagination. (for example horse Pegasus, Mickey Mouse etc.). These abstract objects do not represent the real objects. I wrote about these objects; see my comments on November 28, 2007 on this user group.
3. These are abstract objects, which do not represent real objects, but they represent some specific abstraction of the real objects. For example, a s state of an entity is one such abstract object. This kind of abstract object is a special database structure. This structure contains the corresponding identifiers that determine the identification of the abstract object. The structure has link between the corresponding identifiers. The main part of my model are the states: the state of an entity (object) and the state of a relationship. In my previous post I explained, how to realize the identification of the abstract object, that is, how to identify the state of an entity.

Here it is shown that this is the identification of abstract objects in my db model. And in my model there are only the states. However, entities, relationships, attributes, and states are fairly general terms. It is very important that in my model, knowledge is associated with attributes, objects, relationship and condition. Note that the abstract objects are well defined in my model. I wrote about the abstract object in my papers. For example see my paper “Semantic databases and semantic machines”, section 1 at http://www.dbdesign11.com I introduce m-attributes, m-entities, m-relationships and m-states. These objects are interpretations and abstractions of their corresponding real world objects. I name them abstract objects. Note that the four mentioned “m” objects are objects of a most general character.

Properties of abstract objects are:
(i) Abstract objects are recorded, meaning that they are permanent.

       (This implies that abstract objects need a language.) (ii) Abstract objects hold meaning for corresponding subjects. (iii) Abstract objects differ in the way they are constructed.

1. The simplest of them – m-attributes, are direct abstractions of the real world through our perceptual abilities.
2. More complex abstract objects are constructed from simpler ones. For instance, m-entities are constructed from m-attributes.

            Therefore, hierarchy among abstract objects is determined by the 
            level of abstraction of their corresponding real world objects.  

(iv) We identify abstract objects through their identifiers.

Here in this post I'm trying to write a little more about the identification. In connection with the identification I have done some other things besides this written in here. I'll mention the identification of attributes, entities, relationship and states. See my post “ Does the phrase " Russell's paradox " should be replaced with another phrase? ” . Also see my paper “Semantic databases and semantic machines” section 5.6

B. Here is another example with regard to low theoretical level in RM/T. E.Codd often did the transition from ER model into RM model and vice versa. He works with the entities, associations and relations, but he did not show how it works these transitions between data models. He did not even notice that he has to explain and prove it. If you want to see how to build a theory of the mapping between data models, then you can refer to the works of other authors. (for example, see Ron Fagin, Phil Bernstein, S. Alagić, S. Melnik, …) You can see my solution for the mapping between data models, in my post of February 13, 2013, see 11th case.

C. The identifiers defined in my solution are the keys, because they belong to objects. They belong to the real objects or they belong to the abstract objects. The surrogates don't belong to a real objects, so, as Derek noticed they are in contradiction with the definition of the relation keys.

Note that key defined in my solution is general solution. Surrogate key is just a special case. Key defined in my solution can do the following: (i) My key can do what the surrogate key can. (ii) My key can do what the surrogate key can not. (For example, my key is able to identify the states and can maintain a "history." When we work with surrogates, it may happen that two surrogate keys have all the same attributes. My key can maintain this case.)

With this my message I wanted to show that surrogates are just "technical detail", but that there are other things which are more important.

Vladimir Odrljin Received on Mon Feb 25 2013 - 13:16:26 CET