WO1998041935A2

WO1998041935A2 - Method and device for management of time-related information in a database

Info

Publication number: WO1998041935A2
Application number: PCT/SE1998/000482
Authority: WO
Inventors: Terttu Orci
Original assignee: Terttu Orci
Priority date: 1997-03-18
Filing date: 1998-03-17
Publication date: 1998-09-24
Also published as: AU6431798A; SE9700991D0; WO1998041935A3; SE9700991L

Abstract

The present invention relates to a method, a device, and a data storage medium for managing data records. Instead of overwriting existing data element values in the data record when these are to be changed, the system creates a new instance of the data record, which makes it possible on a later occasion to use the existing information for providing information about the earlier contents of the data record. At the same time, an instance is created in a transaction table related to the data record, which stores information about the changes which have been carried out with respect to the data record. Thus, both the data record and the transaction table related to the data record can be optionally utilised in connection with answering time-related questions with respect to the contents and/or updating of the data record.

Description

METHOD FOR UPDATING DATA RECORDS IN A DATABASE

Field of the Invention

The present invention relates to a method and a device for managing a data record, preferably in a database, comprising one or several data element values which are digitally stored in a memory area, as well as a computer-readable data medium for storing software which implements said method and device. More specifically, the present invention relates to a method and a device for managing time-related information in data- bases.

Background of the Invention

It is presently known to store information packets which in various ways are related to one another in data- bases. Usually, information about e.g. a product is stored in a so-called data record comprising one or several data element types, or attributes, as well as a number of data element values, or attribute values, associated with the data element types. "Price" (for a product) or "article number" (for the same product) are examples of data element types, and "100" (the price of the product in currency units) and "125" (the article number) are examples of associated data element values.

An example of a data structure in a conventional database will be described in more detail in connection with the description of preferred embodiments.

When e.g. a product range is to be supplemented with a new product, one simply creates a new data record with data element types and data element values, which are consequently added to the database.

When a record is to be updated in various ways, for example because the price of a product is to be changed, the data element value for the attribute "price" is changed by overwriting the old data element value with a new data element value.

In other words, a system is created which is always up-to-date (provided the database is updated) by the fact that data which is no longer current is replaced by new data. This is a common and, to the person skilled in the art, well known method which need not be described in more detail in this context.

US 5 600 832 describes another example of prior art, in which a variant of an entity called "processor" which is to be updated/changed is stored in a newly created version. The old version remains, containing the out-of- date variant. In addition, for each variant, time data is stored indicating the time intervals during which the respective version was relevant.

It is also known to do a back-up of the contents of a database, i.e. to make a back-up copy of the contents of the database so that it can be recreated if the memory unit in which the database is stored were to be damaged or lose its memory content for any other reason.

Object of the Invention

One object of the invention is to create a data storage system which provides a safe and efficient method for answering various types of time-related questions.

Another object of the invention is to provide the possibility for easy retrieval and study of the contents of a data storage system that that system had at a certain moment in time. A further object of the invention is to provide a system which has a dynamic relationship to old information in the system and not a static one, as is the case in connection with traditional back-up methods.

Yet another object is to provide a data storage sys- tern which makes it possible for the user easily to derive data about changes which have been made to the contents stored. Summary of the Invention

The above-mentioned objects of the present invention are achieved by a method defined in the independent claim 1, a device defined in the independent claim 13, and a medium defined in the independent claim 23. Preferred embodiments of the present invention are defined in the dependent claims 2-12 and 14-22.

According to one aspect of the present invention a method is thus provided for managing a data record, preferably in a database, comprising one or several data element values which are digitally stored in a memory area, which method comprises the steps of: digitally storing, in said data record, information relating to the valid time of the data element values and to the points in time when the data element values have been changed; storing, in a transaction table related to the data record, information relating to the valid time of the data element values and to the points in time when the data element values have been changed; creating a new instance of the data record when an existing data element value of an existing instance of the data record is to be changed to a new data element value, said existing data element value becoming an older data element value and said existing instance of the data record becoming an older instance of the data record; storing the new data element value in the new instance of the data record and saving at least the older data element value in the older instance of the data record; and creating a new instance in the transaction table each time a data element value is changed in the data record, wherein both the data record and the transaction table related to the data record may be used arbitrary in connection with answering time-related questions with respect to the contents and/or updating of the data record.

Thus, according to the invention, a transaction table related to the data record is provided, whose con- tents provide information about the changes which have taken place in the data record itself. For the sake of simplicity, the data record itself and its instances can be said to provide a picture of the contents of the information over time, i.e. a picture of the current information seen over time, while the transaction table provides a picture of the changes to the data record over time. Accordingly, the invention affords a freedom of choice in connection with answering time-related questions, i.e. depending on the nature of the question, the question is directed either to the data record or to the transaction table (or both) . For some types of questions, for example relating to the contents of the data record at a certain point in time, the question is suitably directed to the data record itself, while for other types of questions, e.g. relating to whether a change was retroactive or proactive, the question is suitably directed to the transaction table. The choice of whereto direct a certain question is, of course, also based on criteria such as what is quickest, what is least time-consuming, what requires the least amount of resources, or the like. Thus, there are time-related questions which could be answered with the aid of the data record as well as the transaction table, but which for reasons of expediency are preferably directed to one of the two. For example, the question "which was the first value assigned to the data element" could be answered with the aid of both the data record and the transaction table, but the answer is generally easier to obtain from the transaction table.

In this connection, it will be appreciated that parts of the instances of the data record can be recreated on the basis of the transaction table, and that, similarly, parts of the transaction table can be recreated on the basis of the data record. Accordingly, if the former is lost, the latter can be used as a back-up for recreat- ing large parts of the former and vice versa, thus reducing the need for extra back-up sources.

In connection with the change of a data element value, information relating to the valid time of one or several instances is stored in both the data record and the transaction table. One reason for this is to make it possible for the system to determine which instance of the data record is current at the moment, for example to enable the system to answer questions such as "what is the price of product A at time B?".

In addition, information is stored which relates to when the data element value itself has been changed (when a new instance of the data record has been created) . One reason for this is to enable the system to answer questions such as "during what time period did the database 'believe' that price A was to be valid until further notice?"

In one embodiment, the information related to the valid time of a data element value is stored in the form of a time interval with a start time and an end time, the end time optionally being capable of assuming an indefinite value to enable the database to handle valid times of the type "valid until further notice". When the end time of the valid time is indefinite, it can be given a definite value once the data element value has been changed, if the data element value which was valid until further notice has now been given a definite end time.

In one embodiment of the present invention, the information relating to when a data element value was changed is stored in the form of a time interval with a start time and an end time, the end time optionally being capable of assuming an indefinite value. If, for example, at a time 1, a new data record is created which is to comprise the data element types "article number" and "price" as well as a definite article number (e.g. 100) and a definite price (e.g. 1500) as data element values, and these data element values (100, 1500) are to be valid until further notice, the start time for the interval relating to when data element values have been changed is given the value 1 and the end time assumes an indefinite value. Now, supposing that, at a subsequent time 5, the valid time for the price data element value 100 is given the end time 6 for the current price to be replaced by another price at the time 6. Then the end time for the interval relating to when data element values have been changed will assume the value 5, since the database "was told" at the time 5 that the price was no longer valid until further notice but only until the time 6.

In one embodiment of the present invention, more than one instance of a data record is created when data element values in the data record are changed, for example a new instance for storing information about the new valid time of the old data element value and a new instance for storing information about the new valid time for the new data element value. An example of such an embodiment will be described in detail below.

In a further embodiment of the present invention, the information relating to when data element values have been changed is stored in the form of points in time and not in the form of intervals in the above-mentioned transaction table. One reason for this is that, preferably, a single instance in a transaction table only needs to provide information about the actual change which the instance relates to and not about the amount of time that went by before new changes were made. In one embodiment of the present invention, information about the types of changes which said changes relate to is stored in the transaction table, preferably in the form of the commands or instructions used for ordering said changes. One advantage of this is that it is possible to establish, after the fact, the types of data processing which have been carried out in the database . According to an embodiment of the present invention, an identification code is saved in the transaction table, which code identifies who ordered a certain transaction in the database. This may be very important in terms of system security.

According to yet another embodiment of the present invention, an event time is stored in the transaction table, i.e. the time when a certain event reflected in the database happened in reality, for example when the actual decision was taken about a certain change which was later implemented in the data record. This feature makes it possible, for example, to check the length of the delay between when something happens in reality and when the event is reflected in the database. In addition, it is easy to obtain an answer to whether a certain decision was retroactive or proactive, i.e. to compare the event time with the valid time.

It will be appreciated that the embodiments of the invention discussed above is advantageously combined as desired depending on the application to provide a system with the desired functionality.

Even though the invention is discussed and described herein using examples with respect to data elements types in the form of articles and prices, it will be appre- ciated that the invention is applicable in many other contexts. Examples of such contexts include medical information systems (e.g. patient data and patient treatment, medication, taking of specimens, and other events) follow-up and analysis of research results, financial applications (e.g. changes to exchange rates and stock exchange listings) , systems for decision-making support and decision evaluation, (what decisions were taken, what was the result?) , project documentation, etc.

The present invention will be explained in more detail below by means of exemplifying embodiments with reference to the accompanying drawings. Brief Description of the Drawings

Figs la-Id are tables illustrating the contents of a data record and of a transaction table related to the data record, which implement the present invention. Figs 2a-2d are tables illustrating the contents of a data record in a conventional database at times corresponding to those for the record in Figs la-Id.

Fig. 3 shows a device according to the present invention. Fig. 4 is a flow chart illustrating a method of operation according to the present invention.

Description of Preferred Embodiments

Fig. la shows a data record comprising five data element types: the article number for a product

(ART.NO.); the article name (ART .NAME) ; the price of the product (PRICE) ; the valid time (VT) and the transaction time (TT) , as well as a transaction table related to the data record comprising seven data element types: the article number of the product (ART.NO'); the article name (ART.NAME'); the price of the product (PRICE'); the valid time (VT' ) ; operation performed (OP' ) ; event time (ET' ) and transaction time (TT' ) .

The term "valid time" (VT, VT' ) refers to the time when the information about the product in the respective instance of the data record, is, was, or will be valid or "true". In this example, the valid time is indicated in the form of a time interval. For the sake of simplicity, this example illustrates an implementation of the inven- tion in a context where the data element value of only one data element type changes, viz. the price, but the invention is equally applicable in a context where several data element values change.

The term "transaction time" (TT, TT' ) refers to the time when the information in the respective instance of the record was or is the most current. In this example, the transaction time is indicated as time intervals in the data record and as points in time in the transaction table .

The term "event time" (ET' ) refers to the time when an event reflected in the database happened in reality, preferably the time when the actual decision was taken about the change which is reflected in the respective instance of the data record/transaction table.

The term "operation" (OP' ) refers to the operation carried out on the data record to change the same, for example whether the change related to the creation of a new data record, the up-dating of an existing data record, or the like.

Supposing that at the time 1, we decide to enter a new article with the article number "100", the article name "nail", and the price "1000", and at this time we do not know how long we will keep the price unchanged. In this case, the data record relating to the article nail and the transaction table relating thereto will have the contents shown in Fig. la, provided that the change was not implemented in the database until the time 2. The data record shows, from left to right, the article number (100) of the product, the article name ("nail"), the price of the product (1000), the valid time for the price (1,∞), which is to be understood to signify that the price is valid from the time 1 until further notice, and the transaction time for the price (2,∞), which signifies that the price is to be considered to be the most current from the time 2 until further notice.

The transaction table in Fig. la shows, from left to right, the article number (100) of the product, the article name ("nail"), the price (1000), the valid time for the price (1, ∞) , the operation carried out on the data record ("INSERT"), the time (1) when the decision was taken to carry out the operation and the actual transaction time (2) , which signifies that the decision was implemented in the database at the time 2. Fig. lb shows the contents of the data record and the transaction table if subsequently, at the time 10, we were to take the decision to raise the price to 1500 and that this is to be valid retroactively from the time 8 onwards, and if the corresponding transaction is implemented in the database at the time 12. As the Figure shows, the old contents of the data record are saved unchanged in the old instance of the data record, with the exception that the transaction time TT for the old instance has been changed to [2, 12) , which signifies that, until the time 12, the database itself "believed" that the price 1000 was to be valid from the time 1 until further notice. In addition, a first new instance of the data record is created and stored, which with respect to article number, article name, and price is identical to the old instance but which in the data element value for valid time VT instead contains [1,8), which signifies that the database now (from the time 12 onwards), after the fact, "knows" that the price 1000 is valid for the time interval from the time 1 to the time 8, and which in the data element value for transaction time TT has stored [12, ∞) , which signifies that the database "knows about" this price situation (the price 1000 between the times 1 and 8) from the time 12 onwards. Last but not least, a second new instance of the data record is stored with the article number 100, the article name "nail", the price 1500, the valid time [8, ∞) , which signifies that the price 1500 is valid from the time 8 onwards, and the transaction time [12, ∞) , which signifies that the data- base "knows about" this price situation from the time 12 and will continue to "believe" this unless "informed" otherwise. The above-mentioned first and second new instances of the data record are automatically created by the system as a direct result of the user initiating a change. In other words, the user is not required to take any specific action to create the new instances of the data record. Accordingly, the fact that new instances of the data record are created according to the invention does not mean any additional work for the user.

With respect to the transaction table in Fig. lb, the existing first row (Fig. la) remains unchanged, but a new row or instance (Fig. lb) with the following contents is inserted: the article number 100, the article name "nail", the price 1500, the valid time [8, ∞) , which signifies that the price 1500 is valid from the time 8 onwards, the operation "UPDATE", which means that the operation of updating the price has been carried out, the event time 10, which means that the decision to change the price was taken at the time 10, and the transaction time 12, which means that the transaction was carried out (the database was "informed" of the change) at the time 12.

Fig. lc shows the respective contents of the data record and the transaction table after a decision was taken at the time 20 about a temporary price reduction to the price 1200, which is to be valid from the time 25 to the time 31, after which the price will again be 1500, and after the change has been implemented in the database at the time 21.

In the data record in Fig. lc, the two top instances (rows) remain completely unchanged. The third instance also remains unchanged with the exception that the transaction time for the third instance is changed to [12, 21) , which as above is to be understood to signify that, between the times 12 and 21, the database "believed" that the price 1500 was to be valid from the time 8 onwards. In addition, three new instances of the data record have been created: a first new instance with the price 1500, the valid time [8, 25) , which signifies that the price 1500 is valid from the time 8 until the time 25, and the trans- action time [21, ∞) which signifies that from the time 21 onwards, the database "knows" that the price 1500 is valid between the times 8 and 25; a second new instance with the price 1200, the valid time [25, 31) , which signifies that the price 1200 is to be valid from the time 25 until the time 31, and the transaction time [21, ∞) which signifies that the data- base "knows" that the price 1200 is to be valid during the above valid time from the time 21 onwards; and a third instance with the price 1500, the valid time [31, ∞) , which signifies that the price 1500 is to be valid from the time 31 onwards, and the transaction time [21, ∞) , which signifies that the database "knows" that the price 1500 is to be valid during the above valid time from the time 21 onwards (until further information is provided) .

It should also be noted that the database already "knows", with reference to the still current second instance of the data record (which still has the valid time [12, ∞) ) , that the price 1000 is still true for the time interval 1 to 8.

In the transaction table in Fig. lc, the two top instances or rows remain unchanged, but two new rows are added. The first of the new rows contains, in addition to the article number and the article name, the price 1200 with the valid time [25, 31) , which means that the price 1200 is valid between the times 25 and 31, the operation "UPDATE", which means that the change involved an updating of the price, the event time 20, which means that the decision about the price change was taken at the time 20, and the transaction time 21, which means that the change to the database was carried out at the time 21. Fig. Id shows the respective contents of the data record and the transaction table if, after the action mentioned above, one decides, at the time 35, to eliminate the article 100 from the product range, and if one carries out the corresponding transaction in the database at the time 36.

In the data record in Fig. Id, the top five rows remain unchanged, and in the sixth row only the trans- action time is changed to [21, 36) , which, by analogy with what has been describe above, signifies that the database until the time 36 "believed" that the price 1500 was to be valid until further notice. Moreover, a new row is added containing the price 1500 with the valid time

[31, 35) and the transaction time [36, ∞) , i.e. the database "knows" from the time 36 onwards that the price 1500 is to be valid between the times 31 and 35.

In the transaction table in Fig. Id, the four top rows remain unchanged. A further row is added containing the article number, three empty fields (article name, price, and valid time), the operation "DELETE", which means that the article is eliminated from the product range, the event time 35, which means that the decision to eliminate the article was taken at the time 35, and, finally, the transaction time 36 indicating that the transaction of eliminating the article was carried out at the time 36.

The following are some simple examples of how various types of questions can be answered by utilising either the data record or the transaction table in Fig. Id.

Question: What was the price of the article 100 at the time 8 as far as the database knew at the time 10? Answer: Fetch all instances of the data record in which 10 is part of the transaction time TT (i.e. rows one and three). From these instances, select the instance in which 8 is part of the valid time VT (i.e. row one) . This gives the price 100. Question: What was the price of the article 100 at the time 8 as far as the database knew at the time 12? Answer: Fetch all instances of the data record in which 12 is part of the transaction time TT (i.e. rows two and three) . From these instances, select the instance in which 8 is part of the valid time VT (i.e. row three) . The answer is the price 1500. Question: What was the price of the article 100 at the time 25 as far as the database knew at the time 22? Answer: Fetch all instances of the data record in which 22 is part of the transaction time TT (i.e. rows four, five, and six) . From these instances, select the instance in which 25 is part of the valid time VT (i.e. row four) . The answer is the price 1200.

Question: When the price was changed to 1200, was this a retroactive or proactive change? Answer: Fetch the instance in the transaction table in which PRICE=1200 (i.e. row three) . If the start of the valid time (25) is less than the transaction time (21) , the change was retroactive. Since this is not the case, the change was proactive . Question: How long did it take from when the decision was taken to change the price to 1200 until it was implemented in the database? Answer: Fetch the instance in the transaction table in which PRICE=1200 (i.e. row three) . Compare the transaction time with the event time, which gives a difference of 1 time unit.

Figs 2a-d show the contents of a conventional data record in a database when the same price and product range modifications are carried out which were carried out with the database according to the present invention. The conventional database does not comprise a transaction table and, in addition, no new memory area is allocated to the data record when a change takes place in it, instead one simply overwrites the old contents. The data records contain three data element types: article number, article name, and the price of the article. Fig. la shows the contents of the three data element types after the time 2, i.e. article number = 100, article name = nail, and price = 1000. Fig. lb shows the contents of the data record after the time 12, the first two data element values remain unchanged but the price is changed to 1500. Fig. 2c shows the contents of the data record after the time 21, here, too, the price is the only value that has changed, but this time to 1200. Fig. 2d shows the contents after the time 35 when the price is again 1500. It should be noted that, in this case, one must order the operation externally at the time 35, i.e. bring the price back to 1500, which, as described above, is not the case in connection with the database according to the present invention where the database itself "remembers" to change the price. After the time 36 (the deletion of the article) we no longer have any information about the article with the number 100, in other words, we have lost the entire history of the deleted article.

Fig. 3 shows a computer system 10 which can be used for implementing the present invention. The computer system 10 comprises a central processing unit 16 with which a user can work by the intermediary of a user interface in the form of a monitor 12 and a keyboard 14. In turn, the central processing unit 16 communicates with a database 20 which stores data records with instances thereof according to the invention, and with a storage means 18 which stores transaction tables related to the respective data record, of which a data record with an associated transaction table could, for example, be the ones described with reference to Figs la-Id. In connection with the implementation of changes in the database, which are based on data entered by a user by the intermediary of the keyboard 14, the central processing unit effects changes to the database and the transaction table in the desired manner according to the above description. When a user asks a question of the database/transaction table, the central processing unit 16 directs the question to the suitable unit, i.e. to the data record or to the related transaction table, and delivers the answer to the user by the intermediary of the monitor 12.

Fig. 4 shows a flow chart in connection with the answering of a database-related question according to an embodiment of the invention. In this example, the flow chart in Fig. 4 is carried out by the central processing unit 16 in Fig. 3. In a first step S10, the central processing unit receives a question from a user. If the question is time-related and relates to a data record, the central processing unit determines in step S12 whether the question relates to the actual contents of the data record at a given time or to a change in the contents of the data record. If the question relates to a change, the question is directed, in step S16, to the transaction table related to the data record in the stor- age means 18, after which the answer is returned in step S18 to the user by the intermediary of the monitor 12. However, if the question relates to the state of the data record at a given time, the question is directed, in step S14, to the data record itself in the database 20, after which the answer is returned, in step S18, to the user by the intermediary of the monitor 12. Subsequently, the central processing unit 16 returns to the step S10 to receive the next question.

The above embodiments of the present invention have been described by way of example only and should not be considered to restrict the scope of the invention, which is defined by the appended claims.

Accordingly, modifications and changes to the embodiment described above can be effected within the scope of the invention. With respect to the valid time and the transaction time, which in the embodiment described are stored in the form of data element values in the data record, it is also envisaged that these could be stored in some other location and have pointers to the record instance or instances to which they apply. In different embodiments, valid time and transaction time may refer to data records as well as separate data element values. The system in which the present invention is implemented is preferably provided with means adapted to auto- matically create one or several new instances of existing data records when a user takes action to change one or several data element values in such an existing data record, and/or to change information relating to the valid time or the change time of the data element values.

It will be appreciated that several different types of interfaces can be employed to facilitate the communi- cation between the system and the user, but these are not per se part of the present invention and, consequently, will not be described in more detail in this application. However, according to one embodiment, it is preferred to utilise a query system based on time lines displayed on a computer screen to enable the user easily to visualise his questions and the answers obtained to time-related questions. The interface could, of course, also be designed in many other ways.

Claims

1. A method for managing a data record, preferably in a database, comprising one or more data element values which are digitally stored in a memory area, which method comprises the steps of: digitally storing, in said data record, information relating to the valid time of the data element values and to the timings when the data element values have changed; storing, in a transaction table related to the data record, information relating to the valid time of the data element values and to the timings when the data element values have changed; creating a new instance of the data record when an existing data element value of an existing instance of the data record is to be changed to a new data element value, said existing data element value becoming an older data element value and said existing instance of the data record becoming an older instance of the data record; storing the new data element value in the new instance of the data record and saving at least the older data element value in the older instance of the data record; and creating a new instance in the transaction table each time a data element value is changed in the data record, wherein both the data record and the transaction table related to the data record are usable arbitrary in connection with answering time-related questions with respect to the contents and/or updating of the data record.

2. A method according to claim 1, wherein the infor- mation relating to the valid time of the data element values is stored in the form of a time interval, whose end may assume an indefinite value so that the end of the valid time need not be determined in advance.

3. A method according to claim 1 or 2, wherein the information relating to when data element values have changed is stored in the form of a time interval, whose end may assume an indefinite value.

4. A method according to claim 2 or 3, wherein the end time for the information relating to when a data element value has changed is given a definite value when the valid time for said data element value is changed.

5. A method according to any one of the preceding claims, wherein at least two new instances of the data record are created every time a data element value is changed: one new instance for storing information relating to the new valid time of the old data element value and another new instance for storing information relating to the new valid time of the new data element value.

6. A method according to any one of the preceding claims, wherein the information relating to the valid time of said data element values is stored in the form of data element values in the data record.

7. A method according to any one of the preceding claims, wherein the information relating to when said data element values have changed is stored in the form of data element values in the data record.

8. A method according to any one of the preceding claims, wherein information about the types of changes that said changes relate to is stored in the transaction table, preferably in the form of the instructions used to order said changes.

9. A method according to any one of the preceding claims, wherein the information relating to when data element values have changed is stored in the transaction table in the form of the timing when said change took place.

10. A method according to any one of the preceding claims, wherein information relating to who initiated a certain change of a data element value is stored in the transaction table.

11. A method according to any one of the preceding claims, wherein information about the timing when the event causing the change in the data record took place in reality is stored in the transaction table.

12. A method according to any one of the preceding claims, comprising the step of choosing which of the data record and the transaction table related to the data record is to be utilised in connection with answering time-related questions with respect to the contents and/ or updating of the data record depending upon which information is requested by the time-related question.

13. A device for managing a data record, preferably in a database, which comprises one or more data element values, comprising: first memory means for digital storage of said data record which comprises one or more data element values, of information relating to the valid time of the data element values, and of information relating to when data element values have been changed, said first memory means, when an existing data element value is to be changed to a new data element value, being arranged to store the new data element value in a new instance of the data record and to store at least said existing value of the data element value in the old instance of the data record; and second memory means for digital storage of a transaction table related to the data record, which contains information relating to the valid time of the data element values in the related data record and information relating to when changes of said data element values have taken place, said second memory means being arranged to create a new instance in the transaction table each time a data element value is changed, wherein both the data record and the transaction table related to the data record are arbitrary usable in connection with answering time-related questions with respect to the contents and/or updating of the data record.

14. A device according to claim 13, wherein said first and/or second memory means are adapted to store the information relating to the valid time of the data element values in the form of a time interval, wherein the end time of the interval may assume an indefinite value .

15. A device according to claim 13 or 14, wherein said first memory means are adapted to store the information relating to when data element values have been changed in the form of a time interval, wherein the end time of the interval may assume an indefinite value.

16. A device according to claim 14 or 15, wherein said first memory means are adapted to give said end time a definite value when the information relating to the valid time of said data element value is changed.

17. A device according to any one of claims 13 to

15, wherein said first memory means are adapted to create at least two new instances of the data record each time a data element value is changed: one new instance for storing information about the new valid time of the old data element value and another new instance for storing information about the new valid time for the new data element value.

18. A device according to any one of claims 13 to

17, wherein said second memory means are adapted to store information relating to the types of change which said changes relate to, preferably in the form of the instructions used to initiate said changes.

19. A device according to any one of claims 13 to

18, wherein said second memory means are adapted to store the information relating to when a data element value has changed in the form of a point in time.

20. A device according to any one of claims 13 to

19, wherein said second memory means are adapted to store information relating to who has initiated a change of a data element value.

21. A device according to any one of claims 13 to

20, wherein said second memory means are adapted to store information relating to when the event causing the change of the data record took place in reality.

22. A device according to any one of claims 13 to

21, comprising means for selecting which of the data record and the transaction table related to the data record that should be used in connection with answering time-related questions with respect to the contents and/or updating of the data record depending upon which information is requested by the time-related question.

23. A computer-readable medium for storing software implementing a method according to any one of claims 1-12 or a device according to any one of claims 13-22.