Re: The original version

In my paper a concept of entity has only intrinsic properties. By intrinsic properties, I mean properties which an entity (or relationship) has itself; intrinsic properties are independent of other concepts. This means that if we have the two concepts C1(id, A1) and C2(id, A2) then there is one concept C(id, A1, A2). The common identifier says this.
So an entity is constructed by the intrinsic properties and the identifier. This entity corresponds to a relation that has an identifier and corresponding mutually independent attributes. This relation satisfies all normal forms and can be decomposed into binary relations (see 6.4 and 6.5 in my paper at http://www.dbdesign11.com ).

In contrast, Anchor Modeling just constructs an entity without any control of the attributes, and then maps the entity to RM. If this entity is in fact constructed from two other entities, then there is the question of what the identifier of the mapped entity identifies?

Now, the authors of Anchor Modeling apply Sixth Normal Form. As I already explained, 6NF does not make sense when we have a relation with mutually independent attributes. 6NF also does not have a technique that shows how to put a relation into 6NF - this problem is left up to the users to solve.
Therefore, in order to do the history of an entity, we must first construct the entity well. I first showed that a different db design is necessary for databases which maintain changes than for databases that do not maintain changes. Also, I showed that the creating of binary structures differs in the two mentioned database types.

In my paper from 2008, I showed how a mapping is done between different database models (ER into RM and vice versa):

1. A mapping is done between the db schemas.
2. Every entity from ER must have the corresponding tuple in RM (and vice versa). (This is a second mapping, which is between instances from the corresponding data models)
3. The semantics must be the same in both models. This means that instances from both data models denote the same real world objects.
4. A mapping must be done on the level of binary structures. The mapping of binary structures from ER into RM and the corresponding inverse mapping are both completely defined with the identifier of state of an entity. For databases that do not record history, this mapping is determined by the identifier of an entity (section6.4 and 6.5 in my paper). This is done for relationships in a similar way.

The authors of Anchor Modeling have only done the first step, and have failed to understand the others. They included this in their paper only after my critiques (explanations) on this user group, because this hadn’t been done at all in their first version of Anchor Modeling. This movement from Anchor Modeling into RM ( and probably the inverse?) was mystified by 6NF. I will again mention that I solved schema mapping in 2008. My intention in defining schema mapping was for it to be coordinated with Model Theory.

I would like to conclude this message with the following: 1. In Anchor Modeling there is no criteria for the construction of an entity’s attributes. One can just add an attribute to the entity during db design or during “evolving data warehouse” without any criteria. In contrast, in my db design and db model there are criteria for the introduction of attributes, as I explained in this message and in my message from 13 December in this thread. 2. In Anchor modeling there is no guarantee or explanation that knots, attributes and anchors form an entity or a whole in a given point in time. To be more precise, what is the theoretical basis for creating this type of entity? When I say entity, I mean in terms of entity/ relationship theory. In Anchor Modeling, this part is not at all explained. Received on Sun Jan 02 2011 - 01:07:17 CET