Re: The original version

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 Received on Mon Jun 14 2010 - 11:27:05 CEST