Re: The anatomy of plagiarism that was made by authors of "Anchor Modeling"
Date: Sun, 24 May 2015 06:38:39 -0700 (PDT)
Message-ID: <5d1d20d2-2f75-4703-aba8-072fd78aa301_at_googlegroups.com>
In this thread I paid special attention to surrogate keys and 6NF. The reason is that the authors of Anchor modeling presented surrogates and 6NF as something special in their work. Here in one place I will briefly presented part of plagiarism and serious errors in Anchor modeling. These are only the consequences related to anchor-surrogate keys.
1.
The surrogate key are done in detail in my work in a much broader context
than the Anchor Modeling (RM / T) did. In the my work the surrogate keys are
presented in the context of the theory of identification. In the my papers
are given the conditions under which we can construct surrogates. It was
introduced Simple Form. In the Anchor modeling (and RM / T) are not
presented conditions for the construction of surrogates.
In the my writings on this user group, it was pointed out that surrogate
keys can be applied to a small number of insignificant cases. Therefore, it
makes no sense to build a data model that is based on surrogates.
Authors of "Anchor modeling" overlooked that today in almost all databases,
keys were introduced as an international-standard keys or as locally defined
keys. These keys are fundamentally different from the anchor-surrogates.
Most importantly, these keys are not surrogates, they are real.
It should be noted that Codd's surrogate keys does not fall within the domain of science. In the database theory, especially in database design there are no "invisible" keys.
2.
Anchor modeling is incorrect. This was demonstrated in my threads, "the
original version," some information about anchor modeling "and in this
thread. I will mention in this post only those errors in the "Anchor
modeling" that are related to the "surrogate key".
So in this post I put earlier presented examples of serious errors of Anchor
Modeling, which are related to the anchor-surrogate keys. The reason is that
these examples are located at various sites, as I have in recent years
discussed the "Anchor Modeling".
Anchor Modeling cannot maintain incorrect data. We know that every serious
company has much wrongly-entered data, and that there are often whole
departments which correct this data.
Example 1.
In Anchor Modeling, the history of attributes is maintained in the structure
"Historized Attribute", which had the schema Hatt(C,D,T), where C represents
ID, D represents an attribute, T represents time, and (C,T) is the primary
key.
If the value D is wrong, then it is impossible to enter a correct value,
because it will generate a duplicate key. So this structure can't maintain
history in this important case. In Anchor Modeling, they "must" delete wrong
data, otherwise they will have duplicate key. If a company has taken legal
action on the basis of wrongly entered data (for instance, if a company sues
a client based on wrong data) then the company must save the history, that
is, it must save the incorrect and the later corrected incorrect data.
Example2
If incorrect data is entered in T, then the situation is even worse because
then two rows are wrong. If we were to enter corrected data, then we would
have to have four rows for one attribute change. In this example, things can
get even more complicated, ( involved
relationships, recurring mistakes upon repairing, etc.)
Example3
Suppose that the schools purchased Anchor Modeling software because it
maintains history. Suppose that the teacher Smith gave grade A to student
John. By using a data entry screen, Smith entered the grade A in the
corresponding database. He deliberately made a mistake when entering a grade
A. John's realistic knowledge corresponds in fact to the grade D. After two
months, John was admitted to a good college, thanks to grade A. Smith then
declared that the grade A is a mistake and delete it, since the authors of
Anchor Modeling allow the deletion of the wrong data. So everybody is OK.
John didn't make a mistake; John's college even does not know what is
happened with his diploma. Smith made mistake and fixed it. The authors of
Anchor modeling are responsible in this case, because they claim that their
solution maintain the history, although it is not correct. Even more they
obviously do not understand what the history is. Otherwise, if they
understand the history, then they will not allow the delete of data.
We note that history works well with the insert operation. However, if one
is allowed to insert and delete, then it means that the update operation is
also allowed. So Anchor modeling implicitly introduced classical db. What is
bad here, it is that the authors of Anchor modeling are not aware of it.
This example is of extreme importance. It talks about the online (or
Internet) databases. These databases can not afford department for data
entry and subsequent troubleshooting. On-line db must respond immediately.
So these databases operate much like "living systems", that is, must respond
immediately.
Example4
In historized Attributes Hatt(C,D,T), the attribute T is wrongly designed. T
is the time when the value of a property is no longer valid and also the
time that a new value of the property becomes valid. However, this is
incorrect. For instance, let us consider the property: the color of a car. A
car can be sent to the mechanic to be fixed. The old color can be removed
right away and the company can enter this into a database. After a serious
of repair jobs, the new
color can be painted on 10 days after the previous color was removed.
This data may be entered into the database 12 days after the car has been in
the shop. Therefore, one of the design foundations in Anchor Modeling is
flawed.
Example5
It may happen that a business decision of the company is to enter only every
third change of a certain attribute. In this case, the entire construction
of Hatt (C, D, T) is broken.
Conclusion
Here are presented examples that show serious errors at the level db design of award-winnig paper on ER09. Here are given examples only relating to surrogate keys. For a serious analysis of identifiers of entities, including surrogates, I think that it can be based on my post from 19th May, 2015 in this thread.
Vladimir Odrljin Received on Sun May 24 2015 - 15:38:39 CEST