Versioning

Database dimensions define the components necessary for identifying a data item within the database [UDT]. Many database systems are two dimensional in the sense, that a data item is identified by an object instance identification (e.g. identity or primary key) and a property name. In fact, object property values not only depend on object and property, but also on time. Databases supporting time dimension, at least have to store different versions for object instances in order to track changes of an object instance over time.

The version concept describes the way, how to maintain several versions for an object instance in order to reflect states for an instance over time. This also includes version support for relationships and collections, which means in general storing versions for database entries. Usually (but not necessarily), a version is associated with a time point or interval, i.e. it reflects the state of an instance or collection at a certain time (interval). Version support enables a system to represent previous (historical) states of an object instance or a collection.

One way of managing versions is kind of differential update, i.e. versions are considered as a set of slides, where each slide contains the updates for the earlier ones. Putting all slides above each other provides the current database state. Removing slides from top makes older states visible.

A critical point is consistency in history (consistent versioning). A simple way to achieve consistent versioning is creating a new version for an object instance instance version at any time point, when instance state changes (copy on write). Since this type of complete versioning may cause enormous amount of data, different versioning strategies have been developed for ODABA in order to reduce the amount of data and improve performance accessing historical instance states. ODABA allows choosing between different versioning strategies (versioning modes) for a database.

Considering time as a simple linear dimension, which is a good estimation in many cases, versioning strategies have to fulfill two important requirements in order to guarantee data consistency:

• Data versions form a sequence and do not branch
• Historical data states cannot be changed

The first limitation seems to be a restriction, but within the limited universe that we are considering, time does not create branches and what is considered as version branch in some versioning systems in fact are variants rather than versions. Variants of object instances may be supported by application specific data models and are not subject of ODABA versioning strategies.

The second requirement becomes obvious, when thinking about consistency along the time dimension. State changes are not simple changes of instance states in a database system but depend on many system and application specific rules and conditions, which have to be fulfilled when instances are changing its state. When trying to change a historical instance state, changes made to later instance versions might become invalid because of the changed history. Theoretically, one could implement kind of complete upgrade for historical changes, but probably, nobody will understand the final result. Hence, for the moment it is a better solution never changing the past (as in every day life) - or accepting inconsistency in history.

Regardless on this theoretical approach, ODABA supports updates for older versions when versioning modes have been chosen, which are less consistent by definition (e.g. instance or owner scope versioning mode).