Re: some information about anchor modeling
Date: Wed, 12 Sep 2012 14:03:22 -0700 (PDT)
Message-ID: <73d6a2ff-d799-4ec8-83f8-e656c1f7c912_at_googlegroups.com>
On Tuesday, July 24, 2012 4:12:56 PM UTC+2, Erwin wrote:
> The only thing you have done is renamed DELETE (to CLOSE, IIRC). Doing that does not eliminate update anomalies. At best, you only replace DELETE anomalies with CLOSE anomalies.
Let me give you two examples. These two examples show that the combination of “Surrogate key” and “Delete” is a very bad combination.
Example1.
State1. Person X from a company that supplies consumers with electricity reads a device for measuring the energy consumption for a person Y. Person X writes down on paper that, on May 1st, 2011, person Y fully spent 128 units of energy. State2. Person X submits this list to the IT department on June 1st, 2011, a month later. State3. The person from the IT department has put this list in a drawer and forgotten about it. After two months, he was reminded of this list and promptly handed it over to the person doing data entry. State4. Thus, the data was entered into the database on September 1st, 2011. State5. Then the IT department filed a lawsuit against a person Y, because this person has not paid the electricity consumed. State6. However, it turns out person Y passed away on May 15th, 2011. State7. During the trial it is determined that the person who entered the data, made a mistake and entered 728 instead of 128 (as the amount of energy consumed).The son of person Y is a good lawyer represents in court his late father.
In this example, it is clear who created each state. We also know the procedure responsible for creating this state. Finally, we have an operation assignment. More formally, we have the “who” from the real world, “which procedure” in the db and the “name” of the location in a memory in which the “state” became permanent (assigned).
However, if one uses existing db theory (write and delete), then he doesn’t know what is going on and who is responsible for some particular data.
Example2.
Let there be a data relation that represents the entity Car. Aside from other attributes, car has the attribute VIN (vehicle identification number). If we use the surrogate key, then one of the binary relations has the following scheme : R1 (SurrogateKey, VIN). For example, one of the possible instances of this scheme can be the following relation : R1(SurrogateKey228, VIN1).
In the OO-approach, “RM/T” Codd’s approach and in Anchor Modeling, it is possible to delete this binary relation. Anchor modeling allows the deleting of “erroneous data”. Thus, using the mentioned theories, we can delete R1. Later, we can insert the following new R1(SurrogateKey228, VIN2). Here, VIN1 and VIN2 are two real VIN numbers.
This example shows that anyone can change the identification of an entity. Of course, this is nonsense. We can notice that the “VIN” identification is determined in accordance with international standards, procedures and laws. So, it is possible that a malicious data entry person or insider/outsider/car company can change the identity of a car. In this way, any country can change someone’s identity. My point here is that this is a kind of "disaster" database design.
Codd, and the authors of OO-approach did not do anything that is relevant to the “history” of events.
Vladimir Odrljin Received on Wed Sep 12 2012 - 23:03:22 CEST