The original version
vldm10
November, 2009. (The name of paper is: Anchor Modeling, see
http://api.ning.com/files/R0UON79E5Kh7ell4QTUVt0Aty-EEblPNcpyaTWiHnLMBXgte-CCu7smzUYIvHtcQwtab90phqS2vOLETydOEHIfEId88ND9q/AnchorModeling09.pdf
) As I read the paper, it became clear to me that it was merely a
special case of my paper. Here are my explanations:
(a)
The main part of solving “temporal”, “historical” and other complex
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. This user group translates into many major
world languages (English, French, Russian, Chinese, German, Italian,
etc.), and even some less-used languages (Macedonian). So, these ideas
were essentially broadcasted in a global auditorium, possibly the
biggest one for database design. Here is a link to the
comp.databases.theory user group, where I presented my ideas in 2005:
http://groups.google.com/group/comp.databases.theory/browse_frm/thread/c79f846beb00cc56#
(there are also many other links where the ideas in (a) were clearly
presented)
Later, I put these ideas in a paper, which was written in a broader
context, and submitted it on 21 August 2008. I posted this paper on my
website http://www.dbdesign11.com on 7 March 2009. If someone wants
to see a version of this paper that has additional explanations and
clarifications, he can do so on this webpage.
Therefore, as I stated, the main, most significant part of the paper
was the one cited under part (a). Without this component, nothing in
the paper could have been solved. I believe that the reason complex
databases and databases of a general character have not been solved
until now is because no one came up with that in part (a).
Also, an even more important factor in being able to solve general
databases is the good understanding of part (a). So, an anchor and a
surrogate key without the schema given in part (a) does not help at
all.
The mentioned solution is important also for others fields, for
example for philosophy, logic and semantics. (see for example: Ship of
Theseus ). People have always held that a name denotes a certain
entity, although this entity has been changed many times. But the
following problem has always existed: How an entity which has changed
to another entity is, in fact, the same entity. This problem is solved
in my paper. In my paper I gave the corresponding procedures,
constructions and semantics for solving this problem.
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.
2. Connecting all changes of one entity to the identifier of this
entity.
Vladimir Odrljin
vldm10
<snip>
In my paper at (4.2.6.1), the schema of a state of an entity is
represented by schemas of the following binary concepts:
(4.2.6.1) Schemas of K-concepts;
Ck1 (P,A1, K11,…,K1k,D11,…,D1m);
…
Ckn (P, An, Kn1,…,Knr, Dn1,…,Dns);
(b) Schema of the E-concept
Ce (P, E, Kp1,…,Kej, Dp1,…,Dps)■
(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)
If I put in (4.2.6.1) that P = E (This means entities have only one
state), then (4.2.6.1) becomes “Anchor Model”.
In fact “Anchor Model” is a worse model; Instead of Kij and Dmn ,
“Anchor Model” has only T . It seems that authors of “Anchor Modeling”
don’t understand what T is in their “model”.
I can get “Anchor Modeling” as consequence of my paper (as I have
shown it, in above text). Why then, I have not taken the "Modeling
anchor" for my model? Because, it is not a bad idea to know what we
do. Now I will show why “Anchor Modeling” is very bad modeling.
For example, in “Anchor Modeling”, all the changes are associated to
the same entity. This means that all these different (changed)
entities are, in fact, the same entity. And this is in contradiction
with Leibniz’s Law. By using this kind of “modeling”, Relational Model
and Entity Relationship Model would be unusable. This is nonsense.
Here is a citation from my paper, the paper is at www.dbdesign11.com
(see 7.1.iii) and here is shown the way that changes should be solved:
<<Quote
We have divided all databases into Simple and General databases. We
apply General databases when we model states of entities or
relationships. We apply Simple databases when we model entities and
relationships. In other words we distinguish modeling of entities and
relationships from modeling of their states. Thus, these objects are
different types and have their corresponding operations. General
databases do not have delete and update operations. According to
(3.1), General database modeling supports an insertion only of a new
primitive information.
Quote>>
Note that my procedure described as schema (a), from my message on
26May2010 in this thread, is a fundamental construct for changes of
states.
Vladimir Odrljin
vldm10
I would like to emphasize that changes of states are associated with a
lot of important things :
In my paper the concept of a state is constructed using new ideas
about concepts. This concept is not defined only by means of
attributes. Aside from attributes, it involves constructs which are
related to knowledge, identification and semantics of states of
entities.
Regarding states of entities, I use abstract objects which are
interpretations and abstractions of the real objects. An abstract
object satisfies the corresponding concept. This means that real
objects do not satisfy (directly) concepts, rather the corresponding
abstract objects satisfy the concepts.
The objects from database represent the abstract objects. I introduce
a state of an entity as knowledge about the entity. An identifier of a
state of an entity is determined with knowledge about the entity. This
identifier identifies the corresponding state of the entity. This
state (in the database) represents the corresponding abstract object,
i.e. represents knowledge about the entity. (see 4.2.4)
If I need, I can construct a real identifier of the state of the real
entity which corresponds to the identifier of the state from the
database. See 6.5.(ii), (page 15) for this construction.
An identifier of a state of an entity allows decomposition of the
concept of the state to binary concepts. The same hold true for
relations.
The identifier of the state of an entity provides straightforward
mapping between the binary schemas as well as inverse mapping.
The meaning of an entity is determined by the semantic properties of
its states.
(In my paper I use term m-entity and m-states)
There is one interesting example in philosophy which is related to
states:
Entities e1 and e2 have the same attributes. There are 100 states: s1,
s2,…,s100. Entity e1 changes its states starting from state s1 to
state s100. Entity e2 changes its state from state s100 to s1. At one
moment in time both entities will be in state s50. If each entity can
somehow jump into position of another entity then both entities will
continue their travel to their past.
Vladimir Odrljin
vldm10
importance the paper Anchor Modeling tries to place upon it. In my
opinion, the question here is not about data warehouse approach, but
about much bigger ambitions. Here, we are dealing with the most
significant developments in database theory. These include the
construction of binary relations and concepts, the solving of
“history” and of the most important parts of “temporary database”,
online and data-centric databases, solving important problems in the
fields of philosophy, logic and semantics.
I would like to illustrate with a few real-life examples how Anchor
Modeling cannot solve complex problems.
(i) Anchor Modeling cannot maintain incorrect data. We know that every
serious company has much wrongly-entered data, and that there are
often whole departments which correct this data.
Example 1. In Anchor Modeling, the history of attributes is maintained
in the structure “Historized Attribute”, which had the schema
Hatt(C,D,T), where C represents ID, D represents an attribute, T
represents time, and (C,T) is the primary key.
If the value D is wrong, then it is impossible to enter a correct
value, because it will generate a double key. So this structure can’t
maintain history in this important case. If a company has taken legal
action on the basis of wrongly entered data (for instance, if a
company sues a client based on wrong data) then the company must save
the history, that is, it must save the incorrect and the later
corrected incorrect data.
Example 2.
If incorrect data is entered in T, then the situation is even worse
because then two rows are wrong. If we were to enter corrected data,
then we would have to have four rows for one attribute change. In this
example, things can get even more complicated, ( involved
relationships, recurring mistakes upon repairing, etc.)
(ii) The authors have mentioned some complex problems, but they don’t
give or show any solutions for them. This is really very bad. For
instance, they mentioned “metadata”, but they do not say what this is,
or how they will solve “metadata”. I mean, there are many different
definitions of data and metadata.
The schema Hatt (C,D,T) cannot solve anything complex and this is the
reason why the authors don’t show a solution. Let me give two small
examples:
Example 3.
A database solution needs the following: valid time, two transaction
times (there are transfers of data in two different databases) and
system time. (banks, online shopping).
Example4.
In example3 DateFrom for valid time is 15 May, but the person
responsible for reporting the data from the outside world did not
report this to the IT department until June 10th . What would be the
value for T in this case?
(iii) The rule that applies to Hatt(C,D,T) is that EndDate is for one
value of an attribute is the same as the Start Date for a new value of
the attribute.
In real business applications, this doesn’t have to be the case. We
sometimes have the need to enter a change only every other time it
occurs, or maybe once a week. So, this role is absurd.
(iv) In today’s databases, 99% of business applications have
identifiers. When we apply Anchor Modeling, we then get two
identifiers per entity, which is also absurd.
Aside from everything else we have to take care that during all this
time, these two identifiers identify the same object. An average
hacker could make serious problems here.
If you wish to see a solution for the above problems, you can find it
at http://www.dbdesign11.com
Vladimir Odrljin
vldm10
given in Anchor Modeling. In fact it is not clear what a relationship
is.
In Section 3 of the paper the authors write: “Furthermore, the
relationships between the anchors are captured through ties”. But in
section 2 there is Def2 which says: “Def2. An anchor A(C) is table
with one column”.
Now it turns out that the relationships between tables with one column
are captured through ties? Of course this is nonsense.
In my paper I defined relationships using keys and attributes. So in
my solution a relationship can have attributes. As far as I know other
authors define relationships without attributes. In Anchor Modeling
relationships are defined without attributes.
But suddenly historized ties have the attribute T. T is time. This is
contradiction.
The representation of relationships through ties is naive. Let me give
the following simple example of m-n relationship between Person and
Address (where m, n 1)
Here, we can’t apply Anchor Modeling, because Address is not an
entity. (Anchor Modeling section 2.4: “A tie represents association
between two or more entities.)
We can note that each state has M zip codes, every zip code has K
cities, every city has L streets, every street has X buildings, every
building has Y apartments.
Anchor Modeling is represented as Data Warehousing approach but at the
end of the paper this model is suggested as superior to existing data
models.
Considering my criticism of the entity solutions (see my post - 14jun
in this thread), then the relationships between entities have serious
problems (in Anchor Modeling).
Vladimir Odrljin
Bob Badour
> In this post I would like to reflect on solutions for relationships,
> given in Anchor Modeling. In fact it is not clear what a relationship
> is.
>
> In Section 3 of the paper the authors write: “Furthermore, the
> relationships between the anchors are captured through ties”. But in
> section 2 there is Def2 which says: “Def2. An anchor A(C) is table
> with one column”.
> Now it turns out that the relationships between tables with one column
> are captured through ties? Of course this is nonsense.
So why bother mentioning it here?
vldm10
> The representation of relationships through ties is naive. Let me give
> the following simple example of m-n relationship between Person and
> Address (where m, n 1)
my mistake - it should be: (where m, n > or = 1)
vldm10
designed. T is the time when the value of a property is no longer
valid and also the time that a new value of the property becomes
valid. However, this is incorrect. For instance, let us consider the
property: the color of a car. A car can be sent to the mechanic to be
fixed. The old color can be removed right away and the company can
enter this into a database. After a serious of repair jobs, the new
color can be painted on 10 days after the previous color was removed.
This data may be entered into the database 12 days after the car has
been in the shop. Therefore, one of the design foundations in Anchor
Modeling is flawed.
A much more important question here is what is time? Is time even an
attribute of an entity? In my paper time is defined as knowledge about
an attribute or knowledge about a a fact. In my paper an entity has
only intrinsic properties. My approach to time differs significantly
from others’. In section 3.1 of my paper changes in the real world are
defined on the level of two types of information: information about an
event when something begins and information about an event when
something ends. All changes are defined by these two events. Because a
database is part of the real world, changes in the values of
attributes in the database are defined by these two events.
This gives companies many options in defining their technology. In the
above example, when the old car color is done being removed, then
using the ClosingConstructor (see 6.3) we can enter into the DB: who
did this, when this was done, when was this entered into the database,
how much it cost, how long it took to do, etc. Thus, the distinct
closing event is a key database design element and of a general
character. Note that the ClosingConstructor is not the only possible
solution – there are many others, but they are on a technical level
(not theoretical).
In Anchor Modeling, when dealing with time, a particular case is taken
as a general one – this is wrong.
The authors write: “A historized attribute is used when changes of the
attribute values need to be recorded”. This is when values in the db
are changed. However, this doesn’t work because these values can be
entered into the db 40 days later than they actually happened in the
real world.
Today we often use two or more db. For example, data can be recorded
(or transferred) in OO db and then in relational db. System times can
be also very important, for example for banking transactions or for
online buying or real time db applications. The history of these of
changes does not exist in Anchor Modeling.
Concerning entity changes, the following from my paper is
significant:
1. there are only two kinds of events related to changes
2. there are two abstract objects – states and change of states
Another important question related to these events is theoretical. If
we measure the two above events with the help of another system of
events – for instance with events that create seconds – then the
system with seconds must have faster creating and closing second-
events, otherwise measuring by seconds is incorrect.
Vladimir Odrlin
vldm10
Sixth Normal Form. However, 6NF cannot secure binary structures. Let
us consider a relation with five attributes that are mutually
independent. This relation is in 6NF , thus it cannot be further
decomposed. If we wish to get the history for each of its attributes,
things become very complicated.
My solution marked by (a) in this thread and posted on May 26th,
solves this relation and gives a decomposition into binary structures.
Of course, many other things need to be considered too.
My solution (a) uses Anchor Modeling, but in Anchor Modeling the
identifier is named the “ technicalyly generated surrogate key" or
sometimes “surrogate key”. The terms “anchor” and “surrogate key” are
incorrect and are a results of a poor understanding of the process of
identifying and the nature of the identifier.
In database design we can roughly observe three situations related to
identifiers:
1. We use identifiers in db objects, but we do not use the same
identifier for corresponding objects from the real world. Some call
this identifier the “surrogate key”, they think that all things are
“unique acts of nature”. However, the majority of entities that
databases use are made by people, not nature.
2. We have an identifier which is used both for real objects and for
corresponding objects in the database. This is used in standards that
are often defined on an international level, for instance VIN numbers.
3. We have an identifier which is used for objects from the real
world, but is not used in the database. This is used when we identify
real entities by identifiers rather than by attributes or something
else.
Aside from these three ways of identifying, it is common to identify
an entity through attributes. An identifier is something by which we
are able to identify something that can be an entity, a relationship,
database objects, a state of an entity, an element of a set or
something else.
In my paper, Section 5 is devoted to identification. This process is
partially explained in other sections of the paper also;
identification with the help of concepts, identification of an
attribute (determined in (3.3.3)), identification of abstract objects,
etc.
Therefore, this has to do with identifications, not with surrogates.
The authors state that Anchor Modeling models mostly binary tables.
But Hatt (A,C,T) has three attributes because the authors defined A,
C, T as attributes. The authors claim they use older techniques in
Anchor Modeling. They state that they successfully use and join
techniques that have been in existence for some time – like 6NF and
“surrogate key”.
I will briefly observe such techniques that have to do with binary
structures. For binary relations we need a relation in the form (K,A),
where K is the key and A is an attribute. E. Codd tried to solve this
problem using a “surrogate key” He "anticipated" that any future
solution must include a key that is simple. If the key were to be
composite, it would make no sense to have a solution with one
attribute A and a key with many attributes.
6NF has the opposite approach – there is only one attribute A, but the
key K is composite. As far as I know, the authors of 6NF haven’t given
any solutions that explain how to reach 6NF.
( See “technique” for 6NF in http://www.anchormodeling.com/tiedostot/6nf.pdf
)
Both approaches are unsuccessful regarding the decomposition into
binary relations.
Now, the authors of Anchor Modeling use my solution (a) to “bridge”
the two (6NF and Codd's) “approaches” !
I must say immediately that my solution (a) does not depend on E.
Codd’s approach nor that of 6NF. My solution is much broader and is
done with concepts. Through the application of knowledge this solution
uses a completely new model and new semantics. I introduce a new
normal form which enables well constructed database objects from the
beginning. In contrast, Anchor Modeling (and the current realational
db theory) allows the construction of badly designed relations that
must be later fixed using up to seven normal forms.
Vladimir Odrljin
Bob Badour
> The authors of Anchor Modeling state that their model is based on the
> Sixth Normal Form. However, 6NF cannot secure binary structures. Let
> us consider a relation with five attributes that are mutually
> independent. This relation is in 6NF , thus it cannot be further
> decomposed. If we wish to get the history for each of its attributes,
> things become very complicated.
Huh? Do you know what 6NF is?
vldm10
There are a few reasons. One of them is my paper, which was earlier
mentioned in this tread. The other reason is that there really is a
lot of nonsense in Anchor Modeling. Here, for instance, is another
more drastic one from Section 5.4: “Delete statements are allowed only
when applied to remove erroneous data.” On the other hand, the authors
claim their model keeps the entire (complete) history of data. We can
imagine what happens at court when a judge asks for evidence which was
grounds for suing and a company representative says, “we erased that
data.” Or we can imagine how convenient erasing data is for crime in
the case of online database applications. There are many more such
errors in this paper, but I do not intend to address them.
It can be said that Stockholm University (where the paper Anchor
Modeling originated) is well-known and involved in well-known
scientific events. Science in the developed countries of Europe and
the United States is on the highest global level. In underdeveloped
countries, the position of people in the field of science is much
worse.
With the internet, professionals from informational technology are
able to express their knowledge as independent individuals.
I am sure this process will continue to develop in the future.
This thread is unusual and probably boring to many, but I am sure that
it is about problems which are among the most important in db theory.
The importance of these problems is another reason why I am writing
about the nonsense in Anchor Modeling.
Vladimir Odrljin
vldm10
> A much more important question here is what is time? Is time even an
> attribute of an entity? In my paper time is defined as knowledge about
> an attribute or knowledge about a a fact. In my paper an entity has
> only intrinsic properties. My approach to time differs significantly
> from others’. In section 3.1 of my paper changes in the real world are
> defined on the level of two types of information: information about an
> event when something begins and information about an event when
> something ends. All changes are defined by these two events. Because a
> database is part of the real world, changes in the values of
> attributes in the database are defined by these two events.
My mistake - it should be:
In my paper time is defined as knowledge about an attribute or
knowledge about data.
vldm10
I guess I know?
Do you know what 6NF is?
6NF is defined by the authors of the “Anchor Modeling” as follows:
A table is in 6NF iff it satisfies no nontrivial join dependencies at
all.
( http://www.anchormodeling.com/tiedostot/6nf.pdf )
Maybe you can explain your thinking by using this definition?
Vladimir Odrljin
Bob Badour
How does a relation with 5 mutually independent attributes meet the
definition of 6NF?
vldm10
>
> - Show quoted text -
When I speak about an entity then in my db design I have the following
constructions:
1. the concept of the entity with ( for example) 5 “mutually
independent attributes”
2. the corresponding binary concepts (they are the entity attributes)
3. the corresponding unary concepts (they are the kind of)
That is all what we need.
I don’t need a decomposition of the entity on 3+2 attributes, for
example. I don’t know what these components represent. I don’t need
6NF. I need binary structures and they are reason why I mentioned
“mutually independent attributes”.
So your note is OK, it is possible that the relation with 5 mutually
independent attributes be nonloss-decomposed as non-trivial join. But
it is a random, it is not a rule. With mutually independent attribute
the probability for decomposition is really small. On the other hand
relation can have 10 or more mutually independent attributes.
There is one other thing here, which is more important, which is badly
done in the "Anchor Modeling. This is about how to do the transition
from E / R model in the relational model and vice versa. I think it is
necessary to define the mapping from E / R to RM, then the inverse
mapping for the given mapping and in the end it is necessary to define
the composition mapping. In my model I have at the outset, the binary
concepts. Each binary structure has its own unique identifier of the
state. Therefore, each tuple or a binary concept is uniquely defined.
In "Anchor Modeling" They start from the E / R and go in the RM, so do
6NF, and return to the E / R. But it was not discussed in the paper,
so it's not clear how to do it. For example the definition of 6NF is
interesting:
(A table is in 6NF iff it satisfies no nontrivial join dependencies at
all.)
We can note that mapping of schemas between two db models can be
complex, for examples it can include constrains.
Vladimir Odrljin
vldm10
> A much more important question here is what is time? Is time even an
> attribute of an entity? In my paper time is defined as knowledge about
> an attribute or knowledge about a a fact. In my paper an entity has
> only intrinsic properties. My approach to time differs significantly
> from others’. In section 3.1 of my paper changes in the real world are
> defined on the level of two types of information: information about an
> event when something begins and information about an event when
> something ends. All changes are defined by these two events. Because a
> database is part of the real world, changes in the values of
> attributes in the database are defined by these two events.
In fact in the above text is not about a time, it is about the two
mentioned events. Only these events change a state. This implies that
each data in my solution corresponds exactly to one of the two
mentioned events from the real world. Binary structures enable us to
associate one attribute and many combinations of these two events. For
example, we can associate events in the real world and corresponding
events associated to the attribute in the corresponding database. Or
we can associate events in the real world and events in a processor
(or any hardware) where this attribute was processed (Note that
processors are part of the real world).
In my paper (see Section 6.3) I suggest that these two events and the
corresponding data should be processed using Constructor and
ClosingConstructor. This means that we need a language which has a
declarative part and a procedural part, sql + procedural language. The
declarative part should work with derived and existing data (see
“Derived data” section 6.1 in my paper), while the procedural part
should work with New Data (see “New data” section 6.2). I have only
roughly presented this language.
(snip)
> Another important question related to these events is theoretical. If
> we measure the two above events with the help of another system of
> events – for instance with events that create seconds – then the
> system with seconds must have faster creating and closing second-
> events, otherwise measuring by seconds is incorrect.
Here with a simplified example we show a new approach to time. Here we
measure one pair of events with the help of another pair of events. In
other words, I measure the state of an attribute with a state I take
as a unit of measure. Therefore, if I chose the “second event” as the
unit of measure, then the “second event” must happen quicker than the
one that I wish to measure with seconds ( here, the term second
refers to the unit of time, 60seconds = 1 minute).
Note that I defined these two events in my paper from 2005 at
http://www.dbdesign10.com and also in my paper from 2008, section 3.1
at http://www.dbdesign11.com .
Vladimir Odrljin
vldm10
relation to this thread. With this message I would like to say that I
do not wish to engage in a private correspondence about this thread.
If someone wishes to express his/her opinion related to the thread,
let them do so in this user group.
It seems that certain things in this thread are not clear, and so I
wish to briefly clarify.
1. In my paper, I do not use 6NF.
I do not see a theoretical significance in 6NF. The authors of 6NF
have not given a procedure or solution that puts a relvar into 6NF.
If someone wishes to put a relvar into irreducibility form, he must do
so completely on his own with the careful analysis of all possible
cases, neither less nor more.
I do not see a reason why the authors of Anchor Modeling are thrilled
by 6NF. Again, I argue 6NF does not give a solution for putting a
relvar into 6NF. The authors only define what they call 6NF.
On the other hand, the main problems in Anchor Modeling are solved by
my procedure named (a), which I presented in this thread on May 26th
(the first message in the thread).
2. My response to Bob was determined by a small impreciseness
expressed in the following sentence: “Let us consider a relation with
five attributes that are mutually independent”. 6NF is about JDs, not
about FDs.
I have forgotten to say that in this case we have an all-relation key
and that because of that 6NF does not make sense in this case, because
(for example) the key can be composed of 20 attributes. Actually, I
intended to say this when I said that attributes are mutually
independent.
> There is one other thing here, which is more important, which is badly
> done in the "Anchor Modeling. This is about how to do the transition
> from E / R model in the relational model and vice versa. I think it is
> necessary to define the mapping from E / R to RM, then the inverse
> mapping for the given mapping and in the end it is necessary to define
> the composition mapping. In my model I have at the outset, the binary
> concepts. Each binary structure has its own unique identifier of the
> state. Therefore, each tuple or a binary concept is uniquely defined.
> In "Anchor Modeling" They start from the E / R and go in the RM, so do
> 6NF, and return to the E / R. But it was not discussed in the paper,
> so it's not clear how to do it. For example the definition of 6NF is
> interesting:
> (A table is in 6NF iff it satisfies no nontrivial join dependencies at
> all.)
> We can note that mapping of schemas between two db models can be
> complex, for examples it can include constrains.
3. Recently in this user group problems related to a design using two
data models were discussed. Vadim posted some text about this problem.
In anchor modeling the authors use the following two data models, ER
and RM. In the paper they often use the term table. However, in their
paper they do not explain how the two data models are worked with,
which is a crucial question. In ER, FDs and JDs are not the same way
as they are in RM, so we cannot work in ER (six) normal forms. In RM
there is no entity or relationship at all.
There are many papers by R. Fagin about schema mappings. Microsoft has
also published papers about this topic (see Phil Bernstein, Melnik,
Alagic).
The conceptual schema is an especially serious problem because it has
components which are at a very high level of abstraction (a concept
for example). I have tried to solve the schema (inverse) mapping here
by introducing a definition of concepts, abstract objects (m-objects
in my paper) and other terms.
Vladimir Odrljin
vldm10
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).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
vldm10
an anchor A(C) is a table with three columns. The domain of C is ID,
non-null foreign key with respect to A.C. (HattC,Hatt.T ) is a primary
key for Satt.
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.
Here there are two different definitions of Historized Attribute, the
first one from the first version (from 2009) and the second one from
the second version (from 2010). This paper is about the most important
things in db theory and Historized Attribute is the most important
thing of the paper.
These corrections in the second version of Anchor Modeling were made
after my public critique on this user group of the first version of
the paper.
The following text is my critique of this new version of Anchor
Modeling.
(i)
In my paper, a binary concept is precisely defined and under which
conditions these binary concepts form an entity (see 4.2.2 and 4.2.6
in my paper). Also, I defined when a given relation can be decomposed
into binary relations (see 4.2.8, 4.2.9, 6.4, and 6.5)
http://www.dbdesign11.com
I also published these results on my website http://www.dbdesign10.com
on May 15, 2006 and on the mentioned user group.
Therefore, my paper shows how and under which conditions binary
concepts, binary relations, and binary files can be constructed.
(We can note that before we construct a structure which maintains the
history of an entity, we should define the entity.)
Many people have worked on this and the entire theory of normal forms
was headed toward binary relations. Binary structures were also sought
after in logic and semantics. Now, all of a sudden, the authors of
Anchor Modeling introduce binary structures, and only by definition!
(see above Definition 7)
(ii)
It is well known in Mathematics that extensions of properties cannot
always be introduced through definitions. Russell’s paradox is a well-
known example. This matter with properties can be complex – here are
just a few examples: Hilary Putnam, the renowned mathematician and
philosopher says: A Lemon is a lemon even if its (attribute) color is
green. The French philosopher Merleau-Ponty writes: when at night we
walk past a cherry tree and we see black fruits, we know that they are
actually red and that they are cherries. Thus, this “brief”
introduction of attributes, in fact, historized attributes, is
unusual. In my paper from 2008, in (3.3.3) the following construction
is introduced:
S (the m-attribute, the concept of the property) = T iff
the m-attribute matches the entity’s attribute. ……..…
(3.3.3)
In this construction a concept of an entity’s property is not enough.
Rather, identification of the corresponding attribute is also
necessary (see section 3.3).
If we only have a concept, then we could also make concepts of
imaginary entities, like the horse Pegasus, which has wings and isn’t
real. (3.3.3) also indicates that a subject can identify only those
attributes for which it has the ability. In other words, the subject’s
ability determines the domain of a property in a general case, and
even in the case of an “evolving data environment”. The construction
(3.3.3) in my paper has a broader meaning.
In my paper, an attribute is always determined by a corresponding
concept of a property, not with a relation (see Section 3.3 in my
paper).
(iii)
An extension is not defined in the definition of historized
attributes. If it is an extension of a concept, then this is solved
better in my paper. This means again that Anchor Modeling is a paper
with results that I already had published in my paper from 2008. This
part of my paper is precisely defined: an extension is defined in
4.2.1, and in Section 2, a concept is defined. In Anchor Modeling
these terms are left undefined.
My definition of a concept is oriented toward the construction and
identification of abstract objects. The identification of abstract
objects using concepts has been solved in my paper. For example,
identification of m-n relationships that change their states is a
complex and serious problem. I use the identifier of a relationship to
identify these relationships. I devoted one section of my paper to the
identification. Now, in the new version of their paper, the authors of
Anchor Modeling also introduce the identifier of a relationship in
definition 16. In this way, they have introduced two key objects from
my paper into theirs, which fundamentally change it (extension and
identifier of relationship).
So I decided to complain to journal DKE.
Vladimir Odrljin
vldm10
“When a transaction has some property, like PEDAT-PerformanceDate in
Fig. 4, it should be modeled as an anchor. It can be modeled as a tie
only if the transaction has no properties.” (see Anchor Modeling,
section 4.1 Modeling Core Entities and Transactions)
However no scientific explanation for the above statement is given. In
contrast to Anchor Modeling, many university lectures include
definitions of relationships by their attributes - often giving
examples for relationships with attributes. Wikipedia also defines
relationships through attributes.
In fact, Anchor Modeling cannot solve a relationship that has an
attribute.
Explanation: In this case the Historized Tie would have the following
form: Htie (C1, C2, ..., Cn, A, T) where A is an attribute. Here it is
not clear what T is - is T time that is related to a set of anchors or
is T time related to A?
Vladimir Odrljin
vldm10
example that confirms this.
Historized Tie in Anchor Modeling has the form: Htie(C1, C2, …, Cn,
T). Then it is possible the following sequence of instances:
(C1, C2, …, Cn, T1)
(C1, C2, …, Cn, T2)
….
(C1, C2, …, Cn, Tk)
Now we can construct the algorithm which has the following rule: If i
at Ti is an odd number, then the above relationship is “on”. Otherwise
the relationship is “off”.
Now if a data entry person enters the following wrong instance: (C1,
C2, … ,Cn, Ti) where T1<Ti<T2, then all the above instances which
correspond to T2, T3, … , Tk become wrong.
There are many combinations in this simple example that show that
Anchor Modeling is naive modeling. Just to mention that in the case of
a crime, we can have an insider or we can have an insider and an
outsider.
We can combine the above example with deleting of wrong data and as I
have already shown - Anchor Modeling can not maintain “history” for
deleted data.
For example, I remember the outages that happened in NYC, I think in
summer of 2006. Many electrical lines were “off” many times and there
are a lot of important companies, critical customers and government
online agencies in NYC (the outages were “off” and “on” for about 10
days).
Vladimir Odrljin
vldm10
When we talk about modeling relationships in Anchor Modeling, then the
following question arises: what do the authors of Anchor Modeling
model?
If we have a relationship between two entities, then we should notice
that both entities change over time. Each entity can have for instance
10 attributes and each attribute changes independent of time. Also,
the relationship itself can change with time. In my paper I do not
model relationships between entities, but relationships between the
corresponding states of two entities (or relationships).
In their basic version from 2009 Anchor Modeling defines relationships
in the following way:
Def 9 (Historized Tie). A historized tie Htie(C1,…,Cn, T) relating a
set of
anchors {A1(C1),…,Am(Cm)} is a table with n + 1 columns satisfying n
>= m
and n >= 2, where for every i in [1, n], Htie.Ci is a non-null foreign
key to some
Aj.Cj for j in [1,m], and the domain of the last column T is a non-
null time
type. The primary key for Htie is a subset of (C1,…,Cn, T) containing
T.
(ii)
According to Leibniz’s Law, every entity becomes another entity when
its value changes.
Does Anchor Modeling work on an audit file level or on a database
level?
(iii)
It is possible for two men to possess different values for a certain
property, for the same period of time. Similarly, this can happen for
a relationship. A manager wishes to record both of these values. He
wants to maintain statistic of bad workers. He also wants online db.
The following case is for instance possible in court:
One side claims the car in an accident was blue, the other claims it
was red, while the police claims the car was black. The court requests
that all of these three colors be recorded in the database. Obviously,
Anchor Modeling cannot solve this.
Vladimir Odrljin
vldm10
> (iii)
> It is possible for two men to possess different values for a certain
> property, for the same period of time. Similarly, this can happen for
> a relationship. A manager wishes to record both of these values. He
> wants to maintain statistic of bad workers. He also wants online db.
This kind of design enables a history of incorrect data. It also
enables the one who entered the incorrect data to fix it. This design
enables online db, it does not need any additional projects for
“logical control “ or any other “auxiliary db, project or procedure”.
Vladimir Odrljin
vldm10
“metadata”. In the first version of Anchor Modeling (section 2) they
mention that “Although important, metadata is not discussed further
since its use does not differ from that of other modeling techniques.”
This is a very important theoretical part. There is no example,
definition or schema of “metadata”. Because of this, nobody can say
whether this good or bad. I think that Anchor Modeling cannot solve
these structures, but it would be absurd to analyze these kinds of
“solutions”. I also think that this kind of science is not
acceptable.
Vladimir Odrljin
vldm10
> (iii)
> It is possible for two men to possess different values for a certain
> property, for the same period of time. Similarly, this can happen for
> a relationship.
Let us note that my db design can include knowledge about (real world)
attributes. So it is possible that two people have different knowledge
about one state of an entity. And my db solution can record both of
these in db.
Knowledge about an attribute of an entity depends on different
conditions. For example a shape of an entity depends of an angle of
watching.
Of course my db design can support a constraint that forces unique
entity’s attributes for one state.
Vladimir Odrljin
vldm10
based on DateFrom for the new attribute’s value. There is no DateTo.
Regarding history of databases this is logical nonsense. It is not
possible that a new value of an attribute begins to exist before the
current value ceases to exist. There are numerous examples of business
applications where entities’ attributes don’t work in this way. We can
note that time can be continuous or discrete.
My solution is based on events rather then on time.
Vladimir Odrljin
vldm10
intrinsic properties, I mean properties which an entity (or
relationship) has itself; intrinsic properties are independent of
other concepts. This means that if we have the two concepts C1(id, A1)
and C2(id, A2) then there is one concept C(id, A1, A2). The common
identifier says this.
So an entity is constructed by the intrinsic properties and the
identifier. This entity corresponds to a relation that has an
identifier and corresponding mutually independent attributes. This
relation satisfies all normal forms and can be decomposed into binary
relations (see 6.4 and 6.5 in my paper at http://www.dbdesign11.com ).
In contrast, Anchor Modeling just constructs an entity without any
control of the attributes, and then maps the entity to RM. If this
entity is in fact constructed from two other entities, then there is
the question of what the identifier of the mapped entity identifies?
Now, the authors of Anchor Modeling apply Sixth Normal Form. As I
already explained, 6NF does not make sense when we have a relation
with mutually independent attributes. 6NF also does not have a
technique that shows how to put a relation into 6NF - this problem is
left up to the users to solve.
Therefore, in order to do the history of an entity, we must first
construct the entity well. I first showed that a different db design
is necessary for databases which maintain changes than for databases
that do not maintain changes. Also, I showed that the creating of
binary structures differs in the two mentioned database types.
In my paper from 2008, I showed how a mapping is done between
different database models (ER into RM and vice versa):
1. A mapping is done between the db schemas.
2. Every entity from ER must have the corresponding tuple in RM (and
vice versa).
(This is a second mapping, which is between instances from the
corresponding data models)
3. The semantics must be the same in both models. This means that
instances from both data models denote the same real world objects.
4. A mapping must be done on the level of binary structures. The
mapping of binary structures from ER into RM and the corresponding
inverse mapping are both completely defined with the identifier of
state of an entity. For databases that do not record history, this
mapping is determined by the identifier of an entity (section6.4 and
6.5 in my paper). This is done for relationships in a similar way.
The authors of Anchor Modeling have only done the first step, and have
failed to understand the others. They included this in their paper
only after my critiques (explanations) on this user group, because
this hadn’t been done at all in their first version of Anchor
Modeling. This movement from Anchor Modeling into RM ( and probably
the inverse?) was mystified by 6NF. I will again mention that I solved
schema mapping in 2008. My intention in defining schema mapping was
for it to be coordinated with Model Theory.
I would like to conclude this message with the following:
1. In Anchor Modeling there is no criteria for the construction of an
entity’s attributes. One can just add an attribute to the entity
during db design or during “evolving data warehouse” without any
criteria. In contrast, in my db design and db model there are criteria
for the introduction of attributes, as I explained in this message and
in my message from 13 December in this thread.
2. In Anchor modeling there is no guarantee or explanation that
knots, attributes and anchors form an entity or a whole in a given
point in time. To be more precise, what is the theoretical basis for
creating this type of entity? When I say entity, I mean in terms of
entity/ relationship theory. In Anchor Modeling, this part is not at
all explained.
vldm10
definition of an anchor:
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.
In my paper from 2008 I paid special attention to defining a concept,
an extension, an abstract object, the interpretation of real objects
and their identification and connection to knowledge. As far as I
know, my paper is the first instance in which these ideas are put
together in such a way. My definition of a concept describes the
construction of a plurality. The problem of identification is
addressed in Section 5, but is also analyzed throughout the entire
paper.
Among other terms, I defined a concept of an identifier. Two years
after my paper from 2008 and after my public critique of the
definition of the anchor as a table, the authors of Anchor Modeling
published a new definition of the anchor in the second version of
their paper (from October 2010). It is the following:
An anchor represents a set of entities, such as a set of actors or
events.
Definition 4 (Anchor). An anchor A is a string. An extension of an
anchor is a subset of I.
An example of an anchor is AC_Actor with an example extension {#4711,
#4712, #4713}.
So, the above definition of an anchor is written in 2010. My
definition of the concept of an identifier is written in 2008.
In this definition of an anchor there is some obvious misunderstanding
of basic things. An anchor cannot represent a set, as the authors
stated. A Venn diagram, for example, can represent a set. In the above
definition, an anchor is defined as a name. Names denote (not
represent) something and names have other significant roles in
semantics.
Also, we cannot say “a set of actors” because sets don’t contain
physical objects, rather abstract objects belong to a set. A set has
members and these members can denote actors.
It is bad design when one just puts numbers into a database and uses
these numbers as identifiers or as “surrogate keys”. This technique is
especially bad for databases that maintain history, because the
following two cases are possible:
1. one identifier can identify two distinct entities;
2. two distinct identifiers can identify one entity;
In my paper, I described how the process of identification should be
done. In Anchor Modeling this part is not done at all.
As I have already written in this thread, the structures, which are
named “Attributes” in Anchor Modeling, are special cases of binary
structures from my paper. I explained this in my message from May 31,
2010 in this thread. I also wrote that these special cases are not
always correct.
Vladimir Odrljin
vldm10
As far as I can see, Anchor Modeling cannot maintain the history of a
database regarding any kind of deleting of data. For example, there is
an option “logical delete” in many old software, that can maintain the
history of a database. Note that there are only three operands –
delete, insert and update - which are related to changes of data.
(ii)
The question is how to construct basic structures in Anchor Modeling?
How to construct "Historized Attributes"?
First one has to construct an entity, which entity may not be actually
composed of two other entities. The entity must comply with the
conditions that are consistent with "normal forms". None of this is
solved in Anchor Modeling, but it is in my paper.
Secondly, if an entity is constructed, then we can apply anchors and
get “Historized Attributes”. So, I have the entity E, and from it I
get "Historized Attributes" HA1,...,HAn. An important thing is how to
get the entity E from HA1,...,HAn. I solved this using relationships,
i.e., using only the ER model (see Example 6 in my paper). Anchor
Modeling cannot solve this problem using the ER model.(see my message
from 24 December in this thread, where I explained that Anchor Model
cannot solve historized relationships).
Also it is necessary to explain how to decompose a relation into
binary relations (also solved in my paper - see sections 4.2.6 –
4.2.9, 6.4 and 6.5). Only after these constructions of binary
concepts and binary relations is it possible to do a mapping between
them.
6NF cannot do this as the authors explained in first version of Anchor
Modeling. Anyone who is interested, can find a critique in this thread
related to this argumentation of the authors of Anchor Modeling.
Now, in the second version of Anchor Modeling 6NF is omitted from the
title of the paper. In this new version, I can not find reference
[19], which was about NFs.
In the second version of their paper, the authors change the
definition of “Historized Attribute”.
They introduce by definition all what I did regarding binary
structures. And I really don’t have time for this kind of “theory”.
Vladimir Odrljin
vldm10
> [19], which was about NFs.
Here I made a mistake. Above sentence should be written as follows:
Now, In the first version of the paper "Anchor Modeling" which was
written in 2009, I can not find reference [19], which was about normal
forms.
Vladimir Odrljin
vldm10
> It is bad design when one just puts numbers into a database and uses
> these numbers as identifiers or as “surrogate keys”. This technique is
> especially bad for databases that maintain history, because the
> following two cases are possible:
> 1. one identifier can identify two distinct entities;
> 2. two distinct identifiers can identify one entity;
Example: Let E1 and E2 be two entities of the same type. Suppose they
change the value of their properties. It is quite clear that this can
happen at the same time and that E1 and E2 can have all of the exact
same attributes. That which is very bad for Anchor Modeling here is
that the identities of these two entities are different, even though
these two entities are exactly the same in the database, and in the
real world.
In this example, a variety of combinations and variations can occur,
especially since the authors of Anchor Modeling allow the deletion of
erroneous data.
Vladimir Odrljin
vldm10
post new entries on the thread. Because work is beginning again, I
will limit my entries to a minimum. With this post I would like to
summarize what I have written so far:
1. This thread began because the authors of Anchor Modeling used a
procedure which I described on this thread in a post from May 26,
2010. I labeled this procedure "(a)" and I published this procedure in
2005. Procedure (a) and the basic idea of my work I stated in 2005 on
this user group, and Anchor modeling was released on November 2009.
Without procedure (a), Anchor Modeling is essentially worthless.
To conclude, the ideas of my paper were described and analyzed in
detail through specific examples to a broad group of readers.
2. I showed that though procedure (a) is important, it could not be
solution for databases.
3 I argued that Anchor Modeling can not even solve some major areas
related to "history" of the database. ( Erroneous data, relationships,
the deleting of data, non-sequential states, anomalies with "surrogate
key")
Unfortunately defending my work, I lost all my free time to work on
perfecting my paper.
In the end, I apologize to those who find this thread foreign, unusual
and monotonous.
Vladimir Odrljin
vldm10
authors on August 25, 2010.
Among other things he explained to me that he and the other authors
have not read my paper. (“Unfortunately we have not read yours. Have
you got a URL to where we might find it?”)
Previously, I had posted the website addresses that contained my
papers from 2005 and 2008, but I suppose Mr. Ronnback wanted to know
the “URL” of a journal in which my paper was published. This leads to
the conclusion that:
1) Mr. Ronnback of Anchor modeling maybe thinks that papers from web
sites and user groups do not have any rights.
2) That things are not as I present them.
So I decided to post this text, though I had not intended to.
I submitted my paper on August 21, 2008 in Journal of Computing and
Information Technology (from Croatia). Croatia is a country of my
origin.
Almost a year went by after the paper was submitted without any
information about whether the paper had been accepted or rejected. I
realized that the paper could not be published even after a year, I
contacted the Editor-in-Chief S. Lonacaric and informed him I would
publish the paper on my website, and in the case that it was accepted,
I would give all the rights to his journal. I quickly received a
message from D. Mladenic (from Slovenia ), the Associate Editor, that
my paper was rejected. I inquired about the reviewers and got the
answer that I could not get reviewers names nor contact them. So if
one is interested in my paper, she/he can contact above mentioned
editors.
The only comment D. Mladenic made that was targeted at a specific part
of my paper was absurd. Here, the reviewer questions my employing the
same example twice, though these are actually two different examples;
see in the reviewer comment: “…instead of using practically the same
example more than once (see subsections 3.7 and 3.8)…”
I complained because in my opinion this paper was rejected without any
scientific arguments. My complaint was refused.
Then suddenly, quite by accident, I came upon the paper Anchor
Modeling. I wrote to the chief editor, S. Loncaric and stated that
Anchor Modeling was only a special case of my paper. I wrote that it
had received an award for the best paper of 2009 at ER Congress. I
also wrote that Anchor Modelling employs my ideas from my paper
published in 2005.
S. Loncaric has never responded to my note. As I mentioned S. Loncaric
is Editor-in-Chief in this journal.
I have since given up on publishing this paper in a journal, and have
published the submitted version online.
As far as I know, the aforementioned editors are not experts in
databases. According to their CV's, research by D. Mladenic is
connected to "Machine Learning, Text meaning", and the research by S.
Loncaric is connected to "Imaging".
All my life I work with databases, I was project leader on several
very complex projects.
At that point I began this thread. In my opinion the results of my
paper are important.
So, I put the main idea from the paper on web and on this user group
on September, 2005. I submitted my paper on August 21, 2008;
published the submitted version on my web site on March 7, 2009.
Anchor Modeling got award as the best paper on November, 2009.
I think this thread provides some experience for those who express
their ideas on the user groups and on their websites. It seems that
there are people who think that scientific texts, posted on a website
(user group), are not relevant scientific texts. I mean on a text
which is obviously the original scientific text.
Vladimir Odrljin
=====================
Regarding the rejection of my paper D. Mladenic sent me the following:
“Reviewer nr.1 comment:
Major remarks:
In general, the idea of the research is not clearly represented and
the paper is not well-structured.
Introduction section of the paper should contain more concrete
description of the research problem (significance, motivation and
possibly the list of contributions).
It would be necessary to add a Conclusion section which would
summarize the main achievements and key results of the research.
In addition, it would be useful to include in the paper a Related work
section with an overview of existing methodologies and various
approaches applicable for a given research topic. Besides it, the
comparison with other relevant methodologies could be made and the
list of references (literature cited) could be augmented. It would
help to explicitly state the originality of the performed research.
Minor remarks:
Clarity of the article should be improved. All examples, tables and
formulas should be enumerated and the text of the article itself
should be formatted in a more suitable way for reading.
As well, it would be helpful to give examples along with definitions.
At the same time, instead of using practically the same example more
than once (see subsections 3.7 and 3.8), the references on the used
example should be made.
Furthermore, several references to cited literature are missing (see
subsection 4.2.1).
In addition, references to new concepts, new terms and formulas
introduced in the paper should be done in a coherent way. In
particular, for the reader who is
reading the subsection 3.3 it might be inconvenient to refer to the
definitions in the subsections 4.2.1 and 4.2.2.
Finally, several English phrases should be reformulated and spelling
mistakes should be corrected:
- "According to G. Frege, two concepts are coextensive if every thing
that satisfies either satisfies the other" (see subsection 4.2.1);
- "We assume that the m-entity matches an entity if all it's the m-
attributes match the corresponding entity's attributes carried by
information" (see subsection 4.2.2);
- "5 Determining Plurality - Identifying And Istinguishing
Entities" (see section 5). “
=====================
vldm10
> Example: Let E1 and E2 be two entities of the same type. Suppose they
> change the value of their properties. It is quite clear that this can
> happen at the same time and that E1 and E2 can have all of the exact
> same attributes. That which is very bad for Anchor Modeling here is
> that the identities of these two entities are different, even though
> these two entities are exactly the same in the database, and in the
> real world.
>
> In this example, a variety of combinations and variations can occur,
> especially since the authors of Anchor Modeling allow the deletion of
> erroneous data.
>
> Vladimir Odrljin
In my message 25, from Jan 9 2011, I wrote that in the first version
of the paper "Anchor Modeling" which was written in 2009, I could not
find reference [19] on the given web address. I have now found it, but
it seems the reference was moved to the new version of Anchor Modeling
from 2010 and new web address. The corresponding reference is [25].
In [25] the authors write that they use the surrogate key. See page
2 : “Hatt(C,D,T) contains, as indicated above an anchor surrogate
key”.
(i) “Anchor Modeling” is based on the 6NF, which is evident from the
title: “Anchor Modeling an agile modeling technique using sixth normal
form for structurally and temporally evolving data”.
In this thread in my message from Oct 5, 2010, I presented the case of
a relation that has mutually independent attributes. In this example
the whole relation is in 6NF. So here “Anchor Modeling” would not
work. This means that Anchor Modelling is not based on 6NF and that,
in fact, its basis is unknown.
"Anchor Modeling" starts at the conceptual level with structures.
However, the authors have not proven that we can get (for example) the
concept of the corresponding entity from these structures. So we can
pose the question, why should anyone believe “Anchor Modeling”?
In “Anchor Modeling” the authors extensively use the transition from
one data model to another data model. But they neither explain nor
define this transition.
In my message in the thread from Oct 5, 2010 I wrote that this problem
was solved in my paper from 2008. I used binary structures and the
following two mappings: the first mapping is a schema mapping, and
the second mapping is between instances of the data models.
In this situation both models have the same semantics. I believe that
this is an important result. (see also my message 16, from August 6,
2010)
(ii) Let E1 be the entity in the "Anchor Model" whose anchor key = 234
and which has three attributes that in time t1 have the values v1, v2,
v3 respectively. One can insert another entity whose anchor key = 567
and whose three attributes at the same time t1 have again the values
v1, v2, v3 respectively.
So we get two entities which have the same attribute values in the
database. This implies that we have two entities in the real world,
which have the same attributes in the time t1. These two entities have
different surrogate keys. We know that this is nonsense in the ER
model and Relational model. But we also see that "Anchor Model"
supports this nonsense. So anybody can enter the same entities with
different suroggates.
In this example, a variety of combinations and variations can occur,
especially since the authors of Anchor Modeling allow the deletion of
erroneous data.
(iii) Today the vast majority of keys use the industry standard,
probably more than 90% of databases use this type of keys. For
example, VIN, Bank account, SSN, etc. In this case too "Anchor
Modeling" does not make sense.
(iv) The authors of "Anchor Model" did not show "meta data" in their
solutions. In fact "Anchor Model" cannot solve structures with "meta
data".
Vladimir Odrljin
vldm10
> (ii) Let E1 be the entity in the "Anchor Model" whose anchor key = 234
> and which has three attributes that in time t1 have the values v1, v2,
> v3 respectively. One can insert another entity whose anchor key = 567
> and whose three attributes at the same time t1 have again the values
> v1, v2, v3 respectively.
> So we get two entities which have the same attribute values in the
> database. This implies that we have two entities in the real world,
> which have the same attributes in the time t1. These two entities have
> different surrogate keys. We know that this is nonsense in the ER
> model and Relational model. But we also see that "Anchor Model"
> supports this nonsense. So anybody can enter the same entities with
> different suroggates.
> In this example, a variety of combinations and variations can occur,
> especially since the authors of Anchor Modeling allow the deletion of
> erroneous data.
1.
Sometimes we need additional techniques in order for a database
solution to work. We need additional techniques because the solution
does not work on its own. In this case “Anchor Modeling” needs some
additional technique.
2.
Here is another example:
Let E1 be an entity from the real world with three attributes that
have values v1,v2, v3 respectively at time t1.
In “Anchor Modeling” the following situation is possible: one who
wants to contest the “Anchor Modeling”, can enter the following:
First step: (12, v1, t1), (12, v2, t1), third attribute is null.
12 is the surrogate key, in parenthesis are the corresponding
“historized attributes”, all of which belong to the entity E1.
Note that a person can enter any number of instances of the entity E1
when one or more attributes have null value.
Second step: Later, the data entry person can enter (for example) the
following: (12,v4,t1) - which is intentionally a wrong value (v4) for
the third attribute of entity E1. The company sues client E1.
Third step: Then, the data entry person deletes (12,v4,t1) as wrong
data - since the authors of “Anchor Modeling” allow the deletion of
erroneous data - and enters (12,v3,t1), which is correct.
The company loses the case because it no longer possesses evidence.
In this example, a variety of combinations and variations can occur,
especially since the authors of “Anchor Modeling” allow the deletion
of erroneous data and that one or more attributes can have null
values.
> (iii) Today the vast majority of keys use the industry standard,
> probably more than 90% of databases use this type of keys. For
> example, VIN, Bank account, SSN, etc. In this case too "Anchor
> Modeling" does not make sense.
3.
A surrogate key cannot solve fundamental problems in database design
theory.
To clearly portray this statement, I will use the following example:
A Honda dealer receives 200 Honda Civics to sell. All these Hondas
have the same attributes.
If we were to use a surrogate key here, we would get 200 Hondas with
the same attributes but different surrogate keys. Of course, this is
nonsense. The VIN (vehicle identification number) , which is not a
surrogate key, was introduced.
From this example, we can clearly see the following:
- “Anchor Modeling” (Surrogate Key) cannot solve a large number of
problems of this type
- I am not sure that the authors of “Anchor Modeling” understand
important theoretical issues related to this example.
- In my paper, this topic has been theoretically explained and
resolved. In my paper at http://www.dbdesign10.com (from December
2007) I introduced “distinguishing” which can be applied for the
identification of entities. We can note that “distinguishing” implies
that in this case Leibniz's law doesn’t hold true. (see also my paper
at http://www.dbdesign11.com from 2008, section 5)
4.
Here are a few well-known weaknesses of the surrogate keys:
(i) ) It is impossible to externally verify a surrogate key, while
industry-standard keys are externally verifiable. For example a bar
code or passport id are externally verifiable.
(ii)
Different companies can assign different surrogate keys, defined on
distinct domains that denote the same entities.
On this user group, there were detailed discussions about the
surrogate key related to my paper from 2005. Here is the link to my
thread from September 23, 2005 on this user group:
Database design, Keys and some other things
Here you can see some interesting posts, for example, posts 27, 25 and
62 from Anith Sen, Joe Celko and James Goulding.
5.
I introduced the idea of an identifier of an entity and of an
identifier of a relationship in my paper from 2005 at http://www.dbdesign10.com
. In Section 1.1 of this paper, I wrote “…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.
”
Note that in this definition I wrote “… or can provide identification
of the entity”.
This refers to anything that can provide identification of an entity
(including a surrogate key if it can provide identification of the
entity). The surrogate key is a special sub case of the mentioned
definition. The surrogate key is a very limited solution. My papers
are more general, they are about identifications rather then about
keys.
Without my procedure (a) surrogate keys are worthless (I described
procedure (a) in this thread in my post from 26 May) . Procedure (a)
is important for databases, but by itself, it cannot be a solution for
databases. There are others things which must be implemented.
Procedure (a) is also important for semantics and for identification,
see for example Ship of Theseus. It the first time solves these
problems.
Vladimir Odrljin
vldm10
In this thread I showed that:
1.
"Anchor Modeling" cannot solve some major areas related to "history"
of databases.
2.
A surrogate key is only a special sub case of my solution (see my
messages 12 and 34 from this thread). See also at http://www.dbdesign10.com
Section 6.3 .
As I mentioned in the above point 1, the surrogate key is a very
limited solution.
3.
Some important theoretical solutions are incorrect.
The authors of ''Anchor Modeling'' wrote corrections and published a
new version of ''Anchor Modeling'' in December 2010. In the new
version of ''Anchor Modeling'' these authors introduced new and very
important ideas: states, extensions, binary structures, mappings
between data models and identifiers of relationships.
I introduced states and identifiers of relationships in my papers from
2005. I introduced decomposition into the binary structures in 2005
and 2006, and extensions and mappings between data models from 2008.
In this post I will concentrate on the following two:
(a) A New Definition of ''historized attribute'':
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.
This definition degrades the ER and Semantic model. The relation I x D
x T is what E.Code unsuccessfully attempted to have in his paper RM/T.
He wrote ''In any RM/T databases there is a unary relation (called an
E-relation) for each entity type.'' Note that the ''Anchor'' in fact
is the ''E-relation''.
Note that the extension from Definition7 enables the following:
- the decomposition of data structures into binary structures
- spanning a data model over two data models (Conceptual Model and
Relational
Model). It also enables a transition (mapping) from the Conceptual
Model to the Relational Model.
Note that the authors of ''Anchor Modeling'' try to solve the
mentioned fundamental semantic and structural problems, only by
definition7.
In ''Anchor Modeling'' there is no guarantee that (binary structures)
”historized attributes” form an entity or a whole at a given point in
time. To be more precise, what is the theoretical basis for creating
these binary structures? In RM there are no entities.
On May 15, 2006, I presented a solution which explains how to
decompose a relation into binary relations. (see Section 4 at
http://www.dbdesign10.com ) .
In my paper from 2008 at http://www.dbdesign11.com I presented how to
decompose a concept of an entity, a concept of relationship and a
concept of a state of an entity or relationship into Binary Concepts.
All of this was done on the conceptual level. The binary concept is
precisely defined, as well as the conditions under which binary
concepts form an entity (see 4.2.2 and 4.2.6 in my paper). In the
paper from 2008 I defined mapping from the Conceptual Data Model to
the Relational Data Model. This data model mapping is determined by
the following two mappings: the schema mapping and data mapping.
The authors of “Anchor Modeling” give no theoretical explanation for
surrogate keys. We know that functional dependency is determined by
the real state in the Universe of Discourse. However, in this paper
there is not a single word about the surrogate keys and the real
world.
Note that every ''historized atribute'' has the attribute T. Thus, if
an entity has 10
''historized atribute'', then the entity (and the corressponding
relation) has 10 of the same attributes T. In my data model, time T is
not an attribute.
(b) The Identifiers of Relationships
In this new version from December 2010, the authors of the ''Anchor
Modeling'' introduce the identifier of a relationship (see Definition
16).
This definition is a sub case of the identifier of the state of a
relationship from my data model (see 4.2.4.1, 4.2.4.2, 4.2.5, 4.2.6,
4.2.7, 4.2.8 and 4.2.9 in my paper from 2008). Note that I presented
the main ideas about the identifier of a state of an entity or
relationship in my paper from 2005, five years prior to 2010.
Identifiers of states are very important and fundamental.
(i) In my papers I defined a state of an entity or relationship as the
total knowledge about the entity or relationship
(ii) In my paper from 2008 under 3.9 I defined knowledge about an
entity or relationship
(iii) I defined a state as a concept
(iv) The concept of a state of an entity or relationship is a definite
departure from the idea that a concept is determined only by
conjunction of properties. This is the first time that one precisely
shows the construction of this kind of concepts.
(v) In my papers, states are at the subject level, not at the object
level.
(vi) I distinguish between three realms: the real world i.e. the realm
of reference; the realm of mental; and the realm of semantics. For
instance, everyone can grasp a state of an entity in the same way,
which means that semantics (meaning and grasping of the mental) is
real and objective.
(vii) In my papers knowledge is based on facts. I determined two
important properties of facts: the facts are recorded i.e. they are
permanent and the corresponding subjects are aware of the facts. (see
3.4)
(viii) The concepts in my paper work with abstract objects (not with
physical object). In my data model the abstract objects are recorded
(written) in the memory, which is the reason why I put the prefix m in
front of their names. The abstract objects that satisfy the concept of
the states are complex because they are constructed from the other
abstract objects. This means that depending on their structure, there
are two kinds of abstract objects.
(ix) Concerning entity (relationship) changes, the following from my
paper is
significant: there are only two kinds of events related to changes. An
event which causes new information and an event which causes existing
information to be invalid after this event (this event closes existing
information). A very important consequence of my event approach is
that any change of a state corresponds to one of these two events in
the real world. This approach implies a new definition of and a new
approach to time.
(xi) I introduced the identification of a state. Every state has an
identifier. My paper is the first instance in which the identifiers of
a state of an entity or relationship were introduced. Note that the
states are abstract objects.
(xii) The identifier of a state is determined by the corresponding
concept.
(xiii) The entities involved in relationships must be in the
corresponding states.
(xiv) I introduced a procedure (a), which together with other
constructs resolves
the problem of "history", the semantics of states and changes, and
other problems. I described my procedure (a) on this thread in a post
from May 26.
(xv) My definition of the concept of a relationship determines the
keys of the relationship.
(xvi) My paper, for the first time, shows how to solve the "history"
of states of an entity or relationship.
(xvii) My paper gives for the first time an effective solution, which
decomposes any data structure of the state into appropriate binary
structure. This has been shown for the Conceptual Data Model,
Relational Model and File Model.
(xviii) My solution is of a general character; it is at the level of
databases design and concepts. Note that surrogate keys and object
identities from OOP have some elements that are on a technical level.
The main ideas for these solutions were presented in 2005 in my
papers.
None of the above listed eighteen points is included in the first
version of "Anchor Modeling".
In this thread, on 12 June 2010, I criticized the definition of a
relationship from the first version of ''anchor modeling" I wrote:
”But in section 2 there is Def2 which says: “Def2. An anchor A(C) is
table with one column”. Now it turns out that the relationships
between tables with one column
are captured through ties? Of course this is nonsense.”
I believe that the paper, which intends to resolve such fundamental
issues in database theory, cannot define them this way.
In definition13 (relationship) in the new version of ’’Anchor
Modeling”, the authors introduce “roles”. Note that Peter Chen defined
roles, a long time ago. Note that my definition of a relationship from
2008 also uses also the keys of the relationship (the keys caver
roles, see also (xv) in this post).
In this new version from December 2010, the authors of ‘‘Anchor
Modeling'' introduce an identifier of a relationship (only by
Definition 16).
Note that the identifier of state is a vital part of the following:
1. the solution for ”history”
2. the decomposition the data structures into binary structures
3. It completely defines the mapping between data models
4. It identifies the states
5. It identifies abstract complex objects,
and much more.
Vladimir Odrljin
vldm10
> In this post I will concentrate on the following two:
>
> (a) A New Definition of ''historized attribute'':
> 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.
It seems to me that the authors of "Anchor Modeling" in this
definition do not understand some of the corresponding theoretical
requirements.
Vladimir Odrljin
vldm10
> In this new version from December 2010, the authors of the ''Anchor
> Modeling'' introduce the identifier of a relationship (see Definition
> 16).
>
> This definition is a sub case of the identifier of the state of a
> relationship from my data model (see 4.2.4.1, 4.2.4.2, 4.2.5, 4.2.6,
> 4.2.7, 4.2.8 and 4.2.9 in my paper from 2008). Note that I presented
> the main ideas about the identifier of a state of an entity or
> relationship in my paper from 2005, five years prior to 2010.
It seems that the authors of "Anchor Modeling" tried to introduce the
states of relationships with this identifier.
The states of the relationships are defined in my paper 5 years ago.
Note that the identifiers of the states of relationships enable work
with the relationship between two relationships and with the
corresponding history of this relationship.
Note that the "Anchor Modeling" is only defines relationship between
the entities.
Vladimir Odrljin
vldm10
Given the significance of the results of my paper, published
four(five) years before "Anchor Modeling" on this user group, I have
decided to submit complaints to Springer and Data & Knowledge
Engineering publishers - the publishers of the first and second
versions of "Anchor Modeling". When I find out the results of these
complaints I will post them on this user group.
Vladimir Odrljin
vldm10
> vldm10 wrote:
>
> > On Aug 5, 2:41 am, Bob Badour <bbad...@pei.sympatico.ca> wrote:
> >
> >>vldm10 wrote:
> >>
> >>>The authors of Anchor Modeling state that their model is based on the
> >>>decomposed. If we wish to get the history for each of its attributes,
> >>>things become very complicated.
> >>
> >>Huh? Do you know what 6NF is?
> >
> > I guess I know?
> > Do you know what 6NF is?
> >
> > all.
> > Maybe you can explain your thinking by using this definition?
>
> How does a relation with 5 mutually independent attributes meet the
> definition of 6NF?
issue and it spins at user groups in the past ten years I would like to say
that 6NF can not solve anything. I think so because the authors of 6NF do
not provide any solution or procedure by which we can put a relvar in 6NF.
But let's start from the beginning. Your question, "Huh? Do you know what is
6NF? "Is related to your next question question:
„How does a relation with 5 mutually independent attributes meet the
definition of 6NF?“
Your note is OK. Your intention was as folows:
(i) JD * {A,B,...,Z} is trivial iff at least one of A,B,...,Z is equal to
entire heading of pertinent relvar R.
(ii) Relvar R is in 6NF iff it satisfies no nontrivial JDs at all.
(iii) So your question „How does a relation with 5 mutually independent
attributes meet the definition of 6NF?“ is OK.
Let me explain what I want to say „with 5 mutually independent attributes“.
My Simple Form is not based on FD. It is based on quite different grounds,
that enables the decomposition of data structures in atomic (binary) data
structure.
For example, I can work with binary files. Of course, the intention of the
Simple form is to work with binary entities and binary relations.
In contrast to 6NF, my Simple Form gives the conditions under which we can
get binary (atomic) data structures and "simple key" in these structures.
This refers to the databases that maintain the current state. The main
requirement is that these data structures have attributes which are mutually
independent.
In my General theory of databases I use other tools. Thus decomposition into
atomic data structures in my approach is divided into two different
theories. Several times I presented it on this user group. In short, this
other theory I named General db theory which has its General Form.
Here are a few additional remarks. I do not use non-defined terms such as
"metadata". But the question is how here goes predicate calculus for relvar
R with "metadata". Note metadata are not attributes of objects. So, how to
explain the semantics, that is the relationship between the (formal)
language and objects from the real world that the language denotes. In other
words, how to explain the connection between our (logical) model and the
corresponding fragment of the real world, which is modeled. Here I want to
emphasize the distinction between semantics and logic.
-----------------------------------------------------------
Now, let's take the example from Anchor modeling:
(AnchorKey, attribute1, metadata1, ..., metadataN), key is K = (AnchorrKey,
metadata1).
Note that here some "metadata" can be a kind of "interval-type". Here, it is
necessary to do the following analysis:
When the above "relvar" is in 5NF? When is in 6NF?
Note that in main paper of Anchor Modeling, mentioned relvar is presented
only in the very reduced form: (AnchorKey, Attribute1, T) and key K =
(AnchorKey, T). Of course, this kind of presentation does not look like a
serious analysis.
=========================
As for plagiarism, which is done in Anchor Modeling, which is related to
6NF, I can say the following:
1. Anchor Key je plagijat ključa iz moje Simple Form. Note that the key from
Simple Form is simple. Note that Anchor key is slightly different from
Codd's surrogates.
2. Authors of Anchor modeling inserted "Historized" data structures in 6NF.
But these "Historized" structures I presented on this the user group in
2005, and the Anchor modeling was presented in 2009. It is important to
understand that here 6NF can help. "Historized" data structures that the
authors of Anchor modeling put in 6NF, solve this problem.
3. Anchor Modeling works with the entities, but suddenly the authors of
Anchor modeling work in relational model and here they prove that their
"Historized" structures are in 6NF.
Since the mapping between data models is made only in my data model, I
explained on this thread that the authors of Anchor modeling did not do a
mapping between these two aforementioned data models. In addition to other
posts, I wrote about this serious error, in my posts to you, in this thread.
After my comments, authors of Anchor modeling published entirely new paper
in 2010, where they plagiarized my theory of states, which is the basis of
my theory and my data model.
================
With this post, I'll end up writing about my papers. Of course, if someone
wants to write something or ask a question, let put it on this user group, I
will respond to him.
(more details that are relating to this post you can find in my thread:
The anatomy of plagiarism that was made by the authors of "Anchor Modeling")
Vladimir Odrljin
vldm10
> 1. Anchor Key je plagijat ključa iz moje Simple Form. Note that the key from
> Simple Form is simple. Note that Anchor key is slightly different from
> Codd's surrogates.
> 2. Authors of Anchor modeling inserted "Historized" data structures in 6NF.
> But these "Historized" structures I presented on this the user group in
> 2005, and the Anchor modeling was presented in 2009. It is important to
> understand that here 6NF can help. "Historized" data structures that the
> authors of Anchor modeling put in 6NF, solve this problem.
1. Anchor Key is a plagiarism of the key from my Simple Form. Note that the
from Codd's surrogates.
2. Authors of Anchor modeling inserted "Historized" data structures in 6NF.
But these "Historized" structures I presented on this the user group in
2005, and the Anchor modeling was presented in 2009. It is important to