Re: The original version

On Mar 11, 4:28 am, vldm10 <vld..._at_yahoo.com> wrote:

> (ii) Let E1 be the entity in the "Anchor Model" whose anchor key = 234
> and which has three attributes that in time t1 have the values v1, v2,
> v3 respectively. One can insert another entity whose anchor key = 567
> and whose three attributes at the same time t1 have again the values
> v1, v2, v3 respectively.
> So we get two entities which have the same attribute values in the
> database. This implies that we have two entities in the real world,
> which have the same attributes in the time t1. These two entities have
> different surrogate keys. We know that this is nonsense in the ER
> model and Relational model. But we also see that "Anchor Model"
> supports this nonsense. So anybody can enter the same entities with
> different suroggates.
> In this example, a variety of combinations and variations can occur,
> especially since the authors of Anchor Modeling allow the deletion of
> erroneous data.

1.
Sometimes we need additional techniques in order for a database solution to work. We need additional techniques because the solution does not work on its own. In this case “Anchor Modeling” needs some additional technique.

2.
Here is another example:
Let E1 be an entity from the real world with three attributes that have values v1,v2, v3 respectively at time t1. In “Anchor Modeling” the following situation is possible: one who wants to contest the “Anchor Modeling”, can enter the following: First step: (12, v1, t1), (12, v2, t1), third attribute is null. 12 is the surrogate key, in parenthesis are the corresponding “historized attributes”, all of which belong to the entity E1. Note that a person can enter any number of instances of the entity E1 when one or more attributes have null value.

Second step: Later, the data entry person can enter (for example) the following: (12,v4,t1) - which is intentionally a wrong value (v4) for the third attribute of entity E1. The company sues client E1.

Third step: Then, the data entry person deletes (12,v4,t1) as wrong data - since the authors of “Anchor Modeling” allow the deletion of erroneous data - and enters (12,v3,t1), which is correct. The company loses the case because it no longer possesses evidence.

In this example, a variety of combinations and variations can occur, especially since the authors of “Anchor Modeling” allow the deletion of erroneous data and that one or more attributes can have null values.

> (iii) Today the vast majority of keys use the industry standard,
> probably more than 90% of databases use this type of keys. For
> example, VIN, Bank account, SSN, etc. In this case too "Anchor
> Modeling" does not make sense.

3.
A surrogate key cannot solve fundamental problems in database design theory.
To clearly portray this statement, I will use the following example: A Honda dealer receives 200 Honda Civics to sell. All these Hondas have the same attributes.
If we were to use a surrogate key here, we would get 200 Hondas with the same attributes but different surrogate keys. Of course, this is nonsense. The VIN (vehicle identification number) , which is not a surrogate key, was introduced.

From this example, we can clearly see the following: - “Anchor Modeling” (Surrogate Key) cannot solve a large number of problems of this type
- I am not sure that the authors of “Anchor Modeling” understand important theoretical issues related to this example. - In my paper, this topic has been theoretically explained and resolved. In my paper at http://www.dbdesign10.com (from December 2007) I introduced “distinguishing” which can be applied for the identification of entities. We can note that “distinguishing” implies that in this case Leibniz's law doesn’t hold true. (see also my paper at http://www.dbdesign11.com from 2008, section 5)

4.
Here are a few well-known weaknesses of the surrogate keys:  (i) ) It is impossible to externally verify a surrogate key, while industry-standard keys are externally verifiable. For example a bar code or passport id are externally verifiable. (ii)
Different companies can assign different surrogate keys, defined on distinct domains that denote the same entities.

On this user group, there were detailed discussions about the surrogate key related to my paper from 2005. Here is the link to my thread from September 23, 2005 on this user group: Database design, Keys and some other things Here you can see some interesting posts, for example, posts 27, 25 and 62 from Anith Sen, Joe Celko and James Goulding.

5.
I introduced the idea of an identifier of an entity and of an identifier of a relationship in my paper from 2005 at http://www.dbdesign10.com . In Section 1.1 of this paper, I wrote “…every entity has an attribute which is the Identifier of the entity or can provide identification of the entity. This Identifier has one value for all the states of one entity or relationship. ”
Note that in this definition I wrote “… or can provide identification of the entity”.
This refers to anything that can provide identification of an entity (including a surrogate key if it can provide identification of the entity). The surrogate key is a special sub case of the mentioned definition. The surrogate key is a very limited solution. My papers are more general, they are about identifications rather then about keys.

Without my procedure (a) surrogate keys are worthless (I described procedure (a) in this thread in my post from 26 May) . Procedure (a) is important for databases, but by itself, it cannot be a solution for databases. There are others things which must be implemented.

Procedure (a) is also important for semantics and for identification, see for example Ship of Theseus. It the first time solves these problems.

Vladimir Odrljin Received on Mon May 09 2011 - 12:29:14 CEST