Re: The original version
Date: Mon, 29 Nov 2010 04:54:55 -0800 (PST)
Message-ID: <131d9c06-014c-46d3-9e70-7f8d3d61b426_at_k11g2000vbf.googlegroups.com>
At the beginning of this thread, I wrote that the paper Anchor Model
was just a special case of my paper. In Anchor Modeling ( abbreviated
AM ), the only significant idea - that of the historized attribute –
is my own procedure, which I described at the beginning of this thread
(message from May 26) and labeled (a).
I had published this idea on my website http://www.dbdesign10.com and
in this user group in September 2005. The Anchor Modeling paper was
published in November of 2009.
The authors of AM have tried to correct the things that I have shown
are wrong (also in this thread). They wrote a new version of this
paper with corrections based on:
(i) my critiques in this thread.
(ii) ideas from my paper, which was written in a broader context and
submitted for publication on August 21st, 2008.
The new paper has been accepted for publication in a journal Data & Knowledge Engineering. I used a preprint of the article at: http://api.ning.com/files/O03Gglrgkj7tPERDEbcWXEmDI1VDNzZx9EZc6pikGGG0uewENqy-l-xLFL62LHnpw0WkU7afbudzj2ftuc5AIQ__/AnchorModelingDKEpreprint.pdf
This surprised me because I have in many places indicated that there are various mistakes in AM and that they are so serious and wrong in essence that they make this paper theoretically and practically unacceptable.
In this thread I explained why I put the procedure (a) as a special case. It is because we use Leibniz’s Law when we model distinguished entities. In contrast, I model states of entities and relationships. So it turns out that authors of AM do not model appropriate objects. In my papers from 2005 and 2008 I wrote in detail about states and about “history of states of entities/relationships”. Now, in this new version of their paper, after my critique of Anchor Modeling in this thread, the authors introduce states.
In my paper from 2008 I wrote, defined and connected concepts, extensions, abstract and real world objects, states of entitles/ relationships as well as their identification. As far as papers are concerned, to the best of my knowledge, my paper is the first that presents this combination of the mentioned objects. In the new version of their paper the authors introduce extensions. Extensions and states are fundamental objects but in the new version of AM neither are defined.
My model works intensively with identifiers – there is a whole section
on identification in my paper.
Now in their new version the authors introduce an identifier in a
structure that represents the history of relationships. This
identifier and its theoretical foundation were included in my paper
long ago.
In the thread I showed that 6NF can’t be applied as the authors of AM explain. In the new version they don’t use 6NF. 6NF was a word in the title of the previous version of their paper and now it has been retracted from the title. They haven’t explained how AM now (without RM) works. How does one map/inversely map between ER and RM, including schema mapping.
The authors changed all basic structures. The first version of AM was awarded as the best paper at ER congress, so it is not clear which one users should use: the first version or this new version. Maybe we can combine both versions??? This question refers to situations to which both can be applied.
For example: The two most important structure in AM:
Old Version:
Def 2 (Anchor). An anchor A(C) is a table with one column. The domain
of C
is ID. The primary key for A is C.
Def 5 (Historized Attribute). A historized attribute Hatt(C, D, T) for
an anchor
A(C) is a table with three columns. The domain of C is ID, of D a non-
null
data type, and of T a non-null time type. Hatt.C is a non-null foreign
key with
respect to A.C. (Hatt.C,Hatt.T ) is a primary key for Satt.
New version:
Definition 4 (Anchor). An anchor A is a string. An extension of an
anchor is a subset of I.
Definition 7 (Historized Attribute). A historized attribute BH is a string. A historized attribute BH has an anchor A for domain, a data type D for range, and a time type T as time range. An extension of a historized attribute BH is a relation over I x D x T.
The following example shows that this model cannot solve the most
important of the cases for which it is intended. This is an example of
wrongly-entered data (erroneous or wrong data). The question arises:
why hasn’t this been fixed in the new version? Rather, it has been
explained unclearly. The answer is that AM cannot solve this most
important part.
Let me explain this with the following example: Let “Historized
Attribute” be given (for entity Car).
Car ( id, color, start-date-for-color)
22 Blue 16 August 2002
22 Red 16 August 2002
In the first row the data entry person made a mistake and entered the
wrong color “blue”, then the manager fixed the mistake and entered
“red”, which is the actual color of the car. This cannot be done in AM
because we get a double key, key = (id, date). For this reason wrong
data in AM must be deleted. Of course, there is no history.
This implies many other things. For instance, AM can’t be used to
design online applications, as well as to solve other serious
problems.
This example clearly indicates that the authors of AM are incompetent and fail to understand the nature of databases and the problems of changes and history.
Vladimir Odrljin Received on Mon Nov 29 2010 - 13:54:55 CET