The temporal history of an object is an order between the different versions of that object and reflects the order of the versions' creation time. In our model we allow several users to take out an object at the same logical time and to create a new versions of that object. In this case we say that logically all the new versions come after the latest common version, but there is no order between the new versions. Consequently the temporal history is a partial order between the versions of an object.
Two users take out an object at the same logical time if the object they access has the same state at both accesses, ie. there has been no change in the database involving that object between both accesses. Versions that cannot be ordered following creation time are said to be parallel.
By allowing this kind of parallelism in the temporal history, several users can work at the same time using and even updating the same piece of information in the shared database without disturbing each other. Although this results in the potential problem of parallel versions which at some time must be merged this may be preferable to locking, given the fact that transactions are relatively long. If desired, constraints can be placed at a higher level to enforce locking and a sequential history. This would be just a simplification of the temporal model which we take as a baseline.
The model also allows that several users connect with the same database, take a copy, and work further disconnected from that database. When the user reconnects with the database all new information in the workspace is integrated into the database.