Re: some information about anchor modeling
Date: Mon, 16 Sep 2013 09:31:48 -0700 (PDT)
Message-ID: <01afac45-89c2-42ee-8dd1-1f69c0849758_at_googlegroups.com>
Dana utorak, 10. rujna 2013. 14:54:07 UTC+2, korisnik vldm10 napisao je:
> Hi Derek,
> (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).
>
This simple key is theoretical basis for the identifier of an entity. Note that this simple key is also theoretical bases for the surrogate key. I have explained that the identifier of entity is the basis for all kind of simple keys. The simple key that is on the database level, do not corresponds always to one attribute of the corresponding entity from the real world. The design of a database depends on db designer. For example he can maintain history for just one entity – in this case he can use this simple key as the immutable identifier of the entity (from the some point in the time) and combine it with the identifier of a state in order to maintain a history, the general database approach, etc. Note that this is logical db design and therefore one can use only a technical solution that is in compliance with the logical database design. Note also that a design with the surrogate key has its limitation. For some of them see my post from April 1, 2013, where I explained using examples from 11 areas that surrogate keys can not even give a solution. Let me explain in more details the most important case. Within the last 20 years, there is a strong development of the use of keys that are the global industry standard. Today, almost there is no a serious business application without the use of these keys. As far as I know, this phenomenon is not sufficiently explained theoretically. In my paper from 2008, I introduced a clear division between the m-objects and real objects. M-objects are objects in the memory; they are abstract objects that can be recorded. What the authors of Anchor Modeling and RM / T did not realize, is that the surrogate keys exist just as m-attributes, and the industry-standard keys exist as m-attributes and also as real attributes. Therefore industry-standard keys are not surrogates.
I have explained in this thread, how complex objects are stored in memory, and how they are called from memory using a combination of identifiers of other objects. I also explained that the identifier of a complex object is built using a combination of identifiers of objects that make up the complex object. In my paper from 2008, I have defined identifiers recursively. First, I define attributes as identifiers by the formula (3.3.3) see my paper from 2008. The identifier of an m-entity is constructed using identifiers of the corresponding attributes. Then I apply formula (3.3.3) to the m-entity. Procedures for relations and states are similar. Note that the identifiers of complex objects are derived. However identifiers for attributes are not derived. They are given.
Note that industry-standard keys as well as the surrogate keys are the identifiers of the m-entities. In contrast to the industry-standard keys, note that the surrogate keys can not be the identifiers of the real entities.
There is one other thing about identifiers, and that is their use by people who have little knowledge about theory. Therefore, professionals have become irritated with the use of identifiers by the amateurs. Note that industry-standard keys are much better than the surrogate keys. If there is an industry standard key in the data structure, then there is no reason to use a surrogate key. If someone uses a surrogate key in addition to the existing industry-standard key, then it would be the same as if someone had killed a steer to make a steak for lunch, which is about half a pound. Note that in my db design, the identifier of an entity does not have to be constructed as a separated single column data structure. The identifier of an entity may have an associated knowledge. When we talk about the design of surrogate keys, then my solution is more general. For example in the case of the surrogate key I can join to it the date, when it was created, who (or which procedure) created it, etc. If you must have an identifier of an entity as a column, then do so. But put into each design strictly structure with one column is a serious error, because it is at the level of db design. Note that Anchor Modeling and RM / T have strictly the surrogate key as one column structure.
> (b) GENERAL DATABASES - databases that maintain history and other important things.
>
> Here I introduced identifiers. The identifier of a state is the main construct in my db design and theory. Here I will mention only two things that this identifier enables. The identifier of the states is powerful tool that determines the decomposition of the most complex data structures into the corresponding atomic structures. The identifier of states determines mapping between my model and ER model and RM and vice verse. The identifier of states determines mapping between ERM and RM and vice verse. The identifier of states in fact determines two kinds of the mappings, the schema mapping between data models and the mappings of the corresponding instances. This solution is of the general character.
>
Note that the identifier of a state is not an “anchor”, it is not the identifier of an entity.
> (iv) The identifiers of states
>
> 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).
>
> 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
>
The following Definition16 from the corrected version of Anchor Modeling is plagiarism:
Definition 16 (identifier). Let T be a (static, historized, knoted or knotted historized) tie. An identifier for T is a subset of T containing at least one anchor role. Furthermore, if T is historized or knotted historized tie, where t is the time type in T, every identifier for T must contain t.
The “ties” from Anchor modeling are a special case of structures from my papers. Note that the identifier defined in definition16 from the corrected paper of Anchor Modeling is the special case of my identifier of a state. Note that every time when something is changed in the data structure from the Definition16, then the identifier from the Definiti16 is also changed, therefore this is the identifier of states. Note that I introduced the identifier of a state in 2005th. Note that without the identifier of state there is no proof for decomposition on atomic structures and there is no mapping between data models. I mean, the first paper Anchor Modeling started from unproved structures and unproved mappings. They just put in the title of their first paper that they are using 6NF.
After my public explanations of these fundamental errors from the first paper of Anchor Modeling, which I presented to this user group, the Definition16 was published, in the corrected version of Anchor Modeling. As I previously wrote, I complained to the chief editor Peter Chen, but I never got an answer.
On September 25,2010, I received email from one of the authors, Lars Rönnbäck. Here is a part from the email: "... Some of the points you address are clarified in our upcoming paper. Unfortunately we have not read yours. Have you got a URL to where we might find it? Some of your critique is also based on misunderstandings. I am sorry if we were not precise enough in our presentation to not leave room for interpretation." I wrote about this email on the user group, and explained that I express my opinion about database theory only publicly on the corresponding user groups. I wrote about this email because this thread seems maybe unrealistic. However this topic and matter is extremely important for the database theory.
The corrected version of Anchor Modeling has title: "Anchor Modeling - Agile information modeling in evolving data environment." In section 6, page 12 the authors have explained the idea of "evolving" and wrote: "This is solved by adding an attribute PR_DUR_Program_Duration to the PR_Program anchor ...". This means Anchor Modeling has the type of entities that have a different number of attributes, but the same concept. It also raises the question: how corresponding "relvar" for this concept looks like?
Vladimir Odrljin Received on Mon Sep 16 2013 - 18:31:48 CEST