Re: The anatomy of plagiarism that was made by authors of "Anchor Modeling"
Date: Sat, 4 Apr 2015 17:27:47 -0700 (PDT)
In this post I will write about surrogate keys, since it forms a cornerstone of the "Anchor Modeling".
- All data structures in my model, which are important for the surrogate key, I
published four years prior to the publication of the paper about "Anchor Modeling".
Here in the title I used the word "I published data-structures" and not "I've resolved a data-structure". The reason for this is the following; these datastructures I did long before I published them. With the such complex changes, it was necessary to check many things. -- My model introduced for the first time, the following facts, that are among other things important for surrogates:
As I wrote in my model was introduced and developed the theory of states.
Decomposition of data structures into atomic structures was done by using the theory of states. It is in my opinion the only possible decomposition of data-structures in the general case.
In my data model, all databases are divided on two types; Simple db and General db. In my post of February 13, 2013 in thread "some information about anchor modeling" I presented what General db can solve. General db is a totally new kind of database and it for the first time solves a number of significant problems. The above-mentioned three points give a very broad basis for working with identifiers of entities. This primarily refers to a broad basis to work with surrogates.
I explained in this thread surrogates are only one case of all possible cases, that the identifier of an entity can be. (see my Simple Form). Such a broad theoretical approach does not exist in "Anchor Modeling", for their most important concept.
The theory of identification is introduced. In my data model I concentrated on identifiers of states and identifier of entities. Identifiers of entities can be: Surrogates, Locally-defined keys and Internationallydefined keys( as I explained in this thread in my analysis of the Simple Form). I am focused on the last two types (Locally and Internationally defined keys) and less on surrogates. The reason is that the surrogates are extremely small part of the business applications.
In simple form, the conditions under which surrogates may be, are given. These conditions are not given in "Anchor modeling", so the "Anchor Modeling" is not legal. Today in business applications that work with serious resources, for example, banks and airline booking systems, this approach is unacceptable, as is the approach of the authors of the anchor modeling.
Please note that the conditions for surrogates are not given, nor are given for Codd's surrogates - this means that Codd's theory of surrogates is poor, as well as "Anchor Modeling" theory. From the point of practical application, Codd's surrogates are "invisible". Obviously "invisible surrogates" do not fall within the domain of science.
Note that C. Date wrote for "anchor keys" the following: "Does this state of affairs remind you of the RM/T discipline..." (see C. Date, "Database design & Relational theory, Normal forms & All that jazz", page 211). This Date writing is not true. In RM/T, E. Code writes that his surrogate key is different from a user-controlled surrogate. We can notice that "anchor key" is a type of user-controlled surrogates, it is not the type of Codd's "invisible surrogates". However, we can notice also that Codd in RM / T writes about the weaknesses of usercontrolled surrogates. User-controlled keys are anchor keys. So, all that Codd wrote about the bad aspects of a user-controlled surrogates (that is anchor keys), should be added to my list of bad characteristics of surrogates. So this list of bad characteristics of "Anchor Modeling" becomes too great list.
As I wrote, the essential difference between the surrogate key and Locally
(Internationally) defined keys is as follows: The surrogate key enables the subject
to work with one memory while Locally (Internationally) defined keys allow work between two (or more) memories, including the transfer of thoughts and semantics between subjects that use these memories. Here we assume that sentences express thoughts. (see my paper "Semantic databases and semantic machines", section 3)
In my db design procedure, the first step is the application of Leibniz 'Law on construction of entities. The second step may be the application of the General Law
(I've already talked in this thread about the General Law). It can be applied to the
example below. In this example, we can see a major drawback in the application of surrogate keys.
It is important to understand the following two things:
(i) Here we apply db design in ERM. Database design in ERM has not so far been
presented in the form of Leibniz's and General Law.
(ii) We do not use here first-order predicate calculus. Leibniz's law is a secondorder
Example: Honda dealer received 200 new Honda Civic cars, which all have the same attributes. Imagine now that someone has wiped out all the VIN numbers from these Honda Civic. Then we get 200 cars that have all the attributes the same. If in this situation we apply surrogates, then we will get a disaster. If we keep the industry-standard identifiers, then we do not need surrogates. Note that this problem with a surrogate key, there is for all industrial products of this type.
Far as I know, no one has done the above mentioned eight points.
Vladimir Odrljin Received on Sun Apr 05 2015 - 02:27:47 CEST