Re: some information about anchor modeling
Date: Sat, 15 Jun 2013 12:00:29 -0700 (PDT)
Message-ID: <99699318-23cd-4a93-be9f-7736b27bd607_at_googlegroups.com>
Dana ponedjeljak, 13. svibnja 2013. 13:58:56 UTC+2, korisnik vldm10 napisao je: Hi Derek,
> > Plagiarism
>
> >
>
> > -------------
>
> >
>
> >
>
> >
>
> > Yes, I understand, from painful experience. So let me start out by saying I am generally on your side, I agree and empathise.
>
> >
>
> >
>
> >
>
> > But I think you need to understand that although there are laws against it, etc, it is sadly very common in the west. Especially in the last ten years, where universities are no longer centres of learning; they are centres of programming humans to be herd animals, and to compete without resolution. I am not saying "deal with it", I am saying, protect yourself.
>
> > -----------
> ===============================
>
> ProcedureA
>
> (a)
>
> The main part of solving “historical” and General databases consists of two sub-steps:
>
> 1. Constructing an identifier of an entity or relationship.
>
> 2. Connecting all changes of states of one entity (or relationship) to the identifier of this entity (or relationship).
>
>
>
> I had published this idea on my website http://www.dbdesign10.com and in this user group in 2005 (see section 1. and 2.)
>
>
>
> (b)
>
> “We determine the Conceptual Model so that every entity and every relationship has only one attribute, all of whose values are distinct. So this attribute doesn’t have two of the same values. We will call this attribute the Identifier of the state of an entity or relationship. We will denote this attribute by the symbol Ack. All other attributes can have values which are the same for some different members of an entity set or a relationship set. Besides Ack, 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.” (See section 1.1)
>
> ===============================
>
> Anchor modeling uses the schema which is given in part (a); it uses both of the following sub-steps:
>
> 1. Constructing an identifier of an entity.(This is about the construction of the simple key)
>
> 2. Connecting all changes of one entity to the identifier of this entity.
>
>
>
> This is plagiarism.
>
>
>
> The identifier is a more general solution than a surrogate key. The idea of the identifier allows presenting key as simple key instead of a complex key.
In the above written text, it was shown that ProcedureA is crucial for "History of Events". Proceduree also shown that Anchor Modeling use it for most important part of which I called “History”.
Now in this post I will prove that the Identifier of an entity which I defined is much more general and better solution than the surrogate key used by the authors of Anchor Modeling.
My main structure, roughly speaking, has the following schema:
IdentifierOfEntity, IdentifierOfState, Knowledge “Knowledge” is total knowledge about an entity, which has one or more subjects. The key is IdentifierOfState. The key is man’s abstraction; the key does not exist in the real entity and the key is one wholeness. Note also that IdentifierOfEntity is not the key of my main structure.
I usually have three groups of knowledge: knowledge about an entity, knowledge about attributes and knowledge about data. However, in my papers I wrote that design of Knowledge depends on the real world situation. For one application I can have one kind of total knowledge and for another application I can have another total knowledge with maybe 5 groups of knowledge, etc. My solution enables variable Knowledge structures design. Anchor modeling has fixed number: knots, anchors .... This db design is nonsense because business applications are very different and I am surprised that the the editors of Springer and the editors of Data & Knowledge Engineering – Journal can accept this limitation on the fundamentals of db design.
(1)
Note that the authors of Anchor Modeling define the anchor key as the surrogate key, see their paper “Analysis of normal form for anchor models”, which is reference to both of their papers; “Anchor Modeling” from 2009 and repair of their first paper, from 2010.
By definition, the surrogate key is internally generated by system and never visible to the user or application. See Codd, RM/T paper.
(2)
Let me cite the following part of the above mentioned ProcedureA: “Besides Ack, every entity has an attribute which is the identifier of the entity or can provide identification of the entity.” This sentence means that the following two cases are possible:
CaseA: The identifier of an entity is a part of entity and it is also a part of m-entity. As I wrote, in RM a tuple is m-entity. So, the identifier of entity is embedded in both entity; in the real entity and in m-entity.
CaseB: The identifier of an entity belongs only to the corresponding m-entity. ===========================================In CaseA, I solved problems which are related to "industry standard" keys, using the identifier of an entity. In this case Anchor Modeling is heavy nonsense. See my explanation in my post from April 1, 2013 in this thread, see cases 6,7,8,9,10. We already discussed in details about the industry-standard-keys.
CaseB is the case in which the authors of Anchor Modeling apply the anchor keys. In fact, this case is applicable to the small number of the database applications. Say 2% of all the databases.
In CaseB, the anchor key is partly plagiarism of the key from my IdentifierOfEntity.
(i) It is simple key. (ii) It does not belong to real world entity. (iii) It uses the mentioned two steps defined in ProcedureA, see case (a). (iv) The anchor key is not the same as my key because it is not visible.
However the authors of AM didn't understand the following: (i) My key belongs to an abstract object, that is, it belongs to the m-entity. (ii) My key is the identifier of the abstract object. This means that the key “enables” the identification of real object bat that the key is part of the abstract object. The user can always identify the real world entity using information from the corresponding abstract object, that is, from the m-entity. That is why in this case the ProcedureA was written "or can provide identification of the entity". As I wrote in my ProcedureA, the identifier of an entity in this case "can" provide the identification of the entity. This means it does not identify the entity directly; rather the identifier can do it indirectly. (iii) The authors of AM do not understand that there is no need for surrogate key here. I have no need to hide the key for the following reason:
- The identifier of a state of an entity can “join” all binary relations that are related to a state of an entity. My solution is based on the states, so I know what it is modeled in my database. In contrast, it seems to me that the authors of "Anchor Modeling" trace the changes, what is a kind of a programming rather than a database.
b Codd has used a surrogate key, so that he can do some things "behind the scenes". In my opinion, these are the things, for which Codd was been aware, that are not entirely clear for him.
Codd introduced invisible key because he did not know to solve all the problems related to the decomposition of data structures in the corresponding binary structure.
As for my paper, I have solved the problems that are related to General Databases. Therefore I don't have needs to hide the keys. So my conclusion is that the authors of Anchor Modeling didn't understand that Codd defined the key invisible because he didn't know to solve the problems but databases which can solve “History”, don’t need a surrogate key.
That is my answer on your question: What is the difference between the surrogate key and identifier? An identifier is well known (visible) part of (abstract) object. So, my design uses “visible” objects, in contrast to the surrogate key. For example, I can use identifiers in SQL, but nobody can do it by using a surrogate key. More importantly, the identifier is not an "identity." The authors of Anchor Modeling define the anchor key as a symbol, which is used as identity! Let me give you one naïve example. Let me give you one naïve example. Complete molecular biology (genetics) works by using receptors (these are small parts of molecules). The receptors are a kind of identifiers, and the receptors work by using identification. The receptors are stupid for philosophical concept, as it is the identity. A virus just need to catch a receptor. After that it can couse very bad things to a person
Conclusion
CaseA. The surrogate key is nonsense for this case.
CaseB. The surrogate key is nonsense for this case, because it is invisible. However, If the authors of the anchor modeling try to cheat, if they say that they do not use invisible surrogate key in their paper, then their key (for this CaseB) is brutal plagiarism of my identifier of an entity.
Please note that I defined concepts for identifiers. I wrote a whole chapter on the identification and much more which is related to identifiers.
Finally, once again, let me repeat, that I think Codd's contribution to the theory of databases, as one of the most important. However, his paper RM / T is not good. About this paper I did not have intention to write. (I think that editors and journal where the RM / T was released, they are obliged to explain some things.)
I write about RM / T because they occurred some very bad frauds that are related to my work and RM / T.
In my last two posts from this thread I showed two things. 1. History in Anchor Modeling is plagiarism if my paper(see ProcedureA). 2. My Identifiers Of Entity is much more general and better solution than any surrogate
key.
This my paper was presented in this user group four years before the publication of Anchor Modeling. My solution was not accepted at all of the people on the many years of discussions. I say this in order to understand how it was contrary to the then-image about databases. I'm also constantly had doubts that I made a mistake somewhere, despite the fact that I did a very complex database "history project". The project has worked and what bothered me was the fact that in the implementation phase, the project has not needs for programmers and maintenance at all. When one works with a database, my project took from him all the information, without his knowledge: his id, id of computer, time etc and all this for each data. Therefore, it was clear who or which procedure is responsible for each data. When it came to the Internet, I had some new problems. My solution is roughly the following: database distinguishes two types of online users. The first type, the registered user who can work with data and another type of visitors who only look at the data. Users from the another type, if I need them, then I take their data, for example if you want to bore them with advertisements. Data entry person can work at home, at office or in a cafe.
Johan Sjöström, MSc, MCAD, Stockolm (Sweden) posted the problem about history and databases on this user group on September 1, 2006. The name of the thread is “Order details table reference live data”. In this thread you can find one example with my ad hoc solution.
Vladimir Odrljin Received on Sat Jun 15 2013 - 21:00:29 CEST