Re: some information about anchor modeling
Date: Tue, 10 Sep 2013 05:54:07 -0700 (PDT)
Message-ID: <ca16e4d8-9dd1-426e-b8f3-5612ec8927a3_at_googlegroups.com>
Hi Derek,
1.
In my last post (posted on Jul 25, 2013), I showed that my solution is a general solution, and that the surrogate key from Anchor Modeling is just a special case of my solution. In addition, the surrogate key is a technical solution; it is not on the theoretical solution.
It was also shown that the surrogate key is irrelevant, since it can be applied in a small number of business applications. Say 2% of the real world business applications.
2.
In my papers, the construction of the simple key is precisely determined on the theoretical level. There are the following two important cases:
(a) SIMPLE DATABASES – these are databases which maintain only the current state.
In 2006 I presented “Simple Form”, see section 4 at http://www.dbdesign10.com . The simple key is defined in the Simple Form. The simple key was realized as the identifier of an entity (or as the identifier of a relationship).
Introducing the Simple Form enables the following important constructions:
(i) It separates the construction of an entity, from the construction of the entity’s constraints. The current theory does not separate the construction of the entity’s constraints from the construction of the corresponding entity.
(ii) It enables construction of an entity by using the simple identifiers and intrinsic attributes.
(iii) It enables a construction of the simple key.
(iv) The Simple Form enables the construction of the atomic concepts, predicates and propositions.
(v) It enables the construction of constraints on the level of the atomic structures.
(vi) The simple key is also important in the process of the identification of a plurality and the individuals that belong to this plurality.
In 2005 I presented on this user group this solution that enables decomposition of the general data structures into the corresponding atomic data structures. I call it General Form. In 2008, I added the concepts on my solution and because of it I named it “Schema of the Concept of a State”, see section 4.2.5 and 4.2.6 in my paper from 2008 at http://www.dbdesign11.com . The General Form, i.e. the schema of the concept of a state of an entity takes the following form:
(Left side)
ConceptStateName (P, E, A1… An, Kp1… Knr, Dp1,…,Dns)
(Right side)
where P is the concept of the identifier of a state of the entity (or relationship); E is the concept of the identifier of the entity; A1,…,An are concepts of the properties of an entity (or relationship); Each property, including E and P, can have different sets of knowledge K associated to them and defined in 3.6 – 3.9. Thus:
P has knowledge Kp1, Kp2… Kpi; E has knowledge Ke1, Ke2… Kej; A1 has knowledge K11, K12…K1k;
….
An has knowledge Kn1, Kn2… Knr.
Knowledge Dp1,…,Dns is defined in 3.8.
Here is (Left) = (Right). The symbol "=" denotes that schemas (Left) and (Right) determine and represent the same states. Note that the identifier of a state, that is P, uniquely determines each component of the ConceptStateName. I will point out again the formula (3.3.3) from my paper:
S (the m-attribute, the concept of the property) = T iff the m-attribute matches
the entity’s attribute. … (3.3.3)
Given that P, E, A1, A2... An are identifiers, and considering on (3.3.3), then we can construct the schemas of the following relationships: (P, E), (P, A1), ..., (P, An).
So (Left) = (Right) is the general solution. I named this solution General Form. I will mention few notes for this occasion:
(i) This General Form is based on concepts of states, extensions, structured knowledge and (3.3.3). The General Form is not a schema of an entity or relation. General Form is not about a predicate, although we can construct the predicate that corresponds to this schema. The General Form is the set of the semantic constructs and procedures.
We can not say that states and concepts are the real world entities. So my model is strong extension of ER model. The identifier of a state is an identifier of subject’s subjective knowledge about the state of an entity.
(ii) The above mentioned knowledge is divided on ‘primitive knowledge about an entity’, knowledge about attributes and knowledge about data. (See sections 3.6 – 3.9 in my paper from 2008)
Primitive knowledge about the entity is related to the construction of concepts, i.e. it is related to the left side of (3.3.3).
Knowledge about attributes is related to the right side of (3.3.3).
I presented on this user group the example which belongs to Hilary Putnam: “Lemon is a lemon, even when it is green”. French philosopher Maurice Merleau-Ponty has another interesting example: When we look at a cherry tree at night, we can conclude, cherries are black; however we know they are red. I solve these two examples by applying the right side of (3.3.3). So, in order to identify an entity’s attribute, we use our knowledge about the entity’s attribute. Knowledge about data is knowledge about how data are stored.
(iii) I wrote in my paper that knowledge is not limited only to above mentioned knowledge. We can expand or restrict knowledge; depends on the real world application.
So my solution is not limited on non-proven and pre-limited set of ties, knots and anchors. My solution is flexible, i.e. my solution is of general character.
(iv) Note that I do not use the undefined term "metadata." I use the aforementioned knowledge, which is precisely defined.
In both cases (a) and (b), the construction of the simple key is defined. Note that both, the Simple Form and the General Form are determined on the level of concepts.
So my general solution has a precisely defined structure of the simple key. If we have a construction for the simple key on the theoretical level, then we can easily assign the surrogate key into the simple key (the same holds for all technical solutions which maintain keys on db level see also my definition of the identifier of an entity at http://www.dbdesign10.com section 1.1). In my previous post I explained that my definition of the key covers technical cases, including the surrogate key.
In this section I explained what the difference between theoretical and technical solution is. I also explained what the difference between general and special solution is. These are the basic things. The surrogate key does not belong to the fundamentals of database theory. Very roughly speaking, the technique of my model consists of the following two steps: I construct the entities using Simple Form and I also use the "General Form" for the construction of atomic structures to model "General Databases".
3.
In my last post the main attention is paid to the fundamental problem, which is the decomposition of a data structure into the atomic structures. Please note that these are fundamental problems that were not solved in the database theory. In accordance with this notice the following major errors in the paper Anchor Modeling:
(a) Decomposition of the data structures at the level of Anchor model was done without evidence.
(b) Decomposition of the data structures at the level of ERM, was done without evidence.
(c) Decomposition of the data structures at the level of RM, was done without evidence.
(d) Mapping data structures from the ERM in the RM, made without evidence.
(e) Mapping data structures from AM in the ERM and RM, made without evidence.
(f) The authors of Anchor Modeling, refer to 6NF. Moreover, they put 6NF in the title of their work. However, nowhere in this paper, there is not one word about 6NF. Note that 6NF has no any significance for the theory because it does not provide any procedure and nothing effectively. Name 6NF is an unofficial abbreviation for the following text "Relvar R is in sixth normal form, 6nf, if and only if it can't be nonloss decomposed at all."
The paper Anchor Modeling has many inaccuracies and even nonsense, I wrote about the many, and on some I did not write. The title of this article contains the amazing claims. The title: "Anchor Modeling An agile modeling technique using the sixth normal form for structurally and temporally evolving data" has the following part "technique for structurally evolving data". This part has misunderstanding of basic things, because "structurally evolving data" can not be solved in Anchor Modeling.
Conclusion: Paper Anchor Modeling won the first prize at "Conceptual Modeling - ER 2009, 28th International Conference on Conceptual Modeling, Gramado, Brazil, November 9-12, 2009" Scandalous proceedings in connection with this work, I described on this user group in my thread "The original version". Please note that this first work on Anchor Modeling besides the above-mentioned cases from (a) to (f) also has other glitches that I wrote in this thread and in my thread "The original version".
4.
I have explained in details many of the errors from the Anchor Modeling, in my thread "The original version". In May 2010 I have started the thread “The original version” and the authors of "Anchor Modeling" have submitted their second paper in September. In the second paper, they corrected some major theoretical errors from their first paper, which I presented in detail in the thread "original version". For the errors in the first paper I thoroughly and publicly explained how it should be done, the authors of "Anchor Modeling" corrected it, in their new paper. Corrected version of Anchor Modeling was published in Data & Knowledge Engineering.
Here are some examples of these corrections done in the corrected version of Anchor Modeling, which are of fundamental character:
(i) Identifier
The authors of "Anchor Modeling" use term "key" and the term "identity." In my model, I have introduced a chapter on the identification and concept of identifiers which I explained in this thread. I have defined the identification, as another mind - the real world link. The RM theory exclusively uses the idea of "natural key" instead of identifiers. I also explained that the term "identity" in db theory is nonsense. This term is not defined even in philosophy. In this thread I wrote that attributes are identifiers - this is based on (3.3.3). I also wrote that identification of complex objects is based on the combination of the corresponding identifiers.
In the paper Anchor Modeling I run command "find" for the term "identifier". I got no response. Word identifier has not once mentioned in this paper.
However in the second corrected paper of "Anchor Modeling" term identifier is introduced. Note that the identifier is one of the very important things in my model, and I explained it in my threads on this group. Note that, I am using the concept of an identifier in the both Simple Form and General Form. Both forms are mentioned in this post as the general solution. Note that these authors used concept of the visible surrogate key in the original version of Anchor Modeling.
(ii) Events
In my critique of Anchor Modeling, I wrote that my model is not temporal database but is event-oriented. Moreover I think I've given a new precise definition of the time, using only two events (see my paper at http://www.dbdesign10.com , section 1). Authors of Anchor Modeling claim that their model is temporal db. In the paper Anchor Modeling, I run command "find" for the term "event". I got no response. The word event has not once mentioned in this paper, in the sense that their model is event-oriented.
However, in the second corrected paper, these authors of Anchor Modeling introduced events. In my opinion the events are defined very badly in Anchor Modeling.
(iii) Concepts
My model is based on concepts. In the paper Anchor Modeling, there is no definition of the concept at all. Keep in mind that their model is defined as a conceptual and presented at the congress, which was named "28th International Conference on Conceptual Modeling." However, the main things here are not consistent. For example, on page 2 say "A anchor model is a relational database schema." Immediately following this sentence also on page 2 say "An anchor is a set of entities." Further on page 3 says:
def 2. An Anchor A (C) is a table with one column. The domain of C is ID. The primary key is C.
This means that this is ER model, i.e. this is the conceptual model.
In the corrected work of Anchor Modeling, the authors introduce some new terms. These terms are very poorly done and obviously the authors do not understand the important things. First of all, here I think on semantics of a given data model.
My model has a clear semantics. Unlike EntityRelationship model, my model has concepts and these concepts have meaning in the real world. The meaning in my model is precisely defined. Note that although the ER model claims that have a stronger semantics than RM, it is not true. ER model has entities but has not the semantics. The RM has a primitive semantics, which is implemented through the corresponding generated spoken language.
(iv) The identifiers of states
On this user group I explained that without the states and without the identifiers of states, can not be done the most important things. For example, it can not be done decomposition of relationship on the atomic structures. The mapping between two data models also can not be done. Without the identifier of the state, many other things are not possible.
In the last five years, I wrote in detail on this user group about the identifier of a state. The identifier of a state I introduced in 2005, and the authors of Anchor Modeling were plagiarized this identifier in 2010th
(v) Decompositions and mappings
In my critique of paper Anchor Modeling, I wrote that their technique is actually a log of changes; it is more like programming and less like a database. I mean, I have a model that models something. My solution models the states of entities and relationships.
In the new, corrected version of the Anchor Modeling, the authors introduce the identifier of a state. As I have written in this post, the identifier of a state contains the main ideas of my model. It is new and one of the main ideas of my work which contains a number of other important ideas. These authors have plagiarized most complex case for the identifier of states; it is the case for the states of relationships (ties).
In this post I wrote that the authors of Anchor Modeling is widely used mappings between data models, and also they use the decomposition of the data structure, all this without of any proof. See section 3 of this post. Please note that many eminent scientists working on these issues. In the corrected version of Ancor Modeling, the authors are trying unsuccessfully to resolve this problem.
I have solved this problem completely. As far as I know, no one else has solved this problem. In connection with the mapping between the data models, I distinguish the following two mappings:
(i) Schema mapping
(ii) The mapping between instances of these schemas
Note that, both of these mappings are completely determined by identifiers of states.
There is one more important issue here, which is related to the meaning. The question is whether the sentence from one model means the same as the sentence from another (mapped) model. This problem is not even noticed by the Anchor Modeling. I have solved this problem in the broader context, See my paper "Semantic databases and semantic machines" sections 1, 2, 3 at http://www.dbdesign11.com .
As I already wrote in this thread, I complained to Peter Chen, who is editor in chief of the journal Data & Knowledge Engineering. In this journal was published the corrected version of Anchor Modeling. He never replied to my complaint.
In addition to these aforementioned theoretical failures, "Anchor Model" can not solve many of the specific problems for what is intended to solve. See my post from April 1, 2013 in this thread. There I showed the real problems of the 11 areas that Anchor Modeling can not resolve.
Vladimir Odrljin Received on Tue Sep 10 2013 - 14:54:07 CEST