Re: The original version

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 secondevents,  otherwise measuring by seconds is incorrect.

Vladimir Odrlin Received on Wed Aug 04 2010 - 23:46:55 CEST