Recently, I came upon a paper that was awarded first place in 11
November, 2009. (The name of paper is: Anchor Modeling, see
http://api.ning.com/files/R0UON79E5K...Modeling09.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....f846beb00cc56#
(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

On May 26, 10:59Â*pm, vldm10 <vld... (AT) yahoo (DOT) com> wrote:

<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

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

The reason I have focused on this topic for so long is because of the
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

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.

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

vldm10 wrote:

So why bother mentioning it here?

my mistake - it should be: (where m, n > or = 1)

In historized Attributes Hatt(C,D,T), the attribute T is wrongly
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

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.

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

vldm10 wrote:

Huh? Do you know what 6NF is?