Time-Versioned Behavior

When it comes to time versioning of objects in a dimension, VDM enforces the following two basic rules:

• Object identity (ID) is separate from version identifier (VID). A version or an object is identified by the combination {ID+VID}
• An object cannot have more than one effective version at a given point in time

There are three methods by which the versioning intervals are assigned:

Dense versioning

Each object of the dimensions has exactly one version effective for any point in time from the beginning-of-time to the end-of-time.

Semi-dense versioning

A variation of dense versioning, allows the beginning date of the first version to be set at the time the object became known or created, thus leaving a gap from beginning of time to the beginning of the first version, maintaining dense versions from that point to the end-of time.

Sparse versioning

Dimension objects have versions that span any number of non-overlapping intervals of time, allowing gaps. This method is appropriate for a variety of circumstances, including general non-dimensional situations.

Dense Versioning as it guarantees lossless recasting both forward and backward in time its more efficient maintenance for correcting or inserting versions in the middle of history, and the simpler integrity checks. Semi-dense versioning corresponding to a non-versioned environment where objects are added over time and never get deleted when they expire. At any given point in history, objects that were created before that time are visible, while those that were created after that time are hidden. Maintenance efficiency is similar to that of dense versioning. Semi-dense versioning does not guarantee lossless recasting backwards in time. Finally, sparse dimensions are best for situations geared to "as-posted" lookup policies, and where minimizing the cardinality of the dimension can be beneficial. Lossless recasting cannot be guaranteed for sparse dimensions. Notice that sparse versioning semantics can be implemented over a densely or semi-densely versioned dimension, where a “dummy” or “inactive” version takes the place of what otherwise would be a gap in a sparse dimension. The structural properties of versioned objects are {[VID,] EFF_BGN_DT, EFF_END_DT}. If an explicit VID (Version ID) for the object is not provided the EFF_BGN_DT can be used as the version ID of the object. The decision to use a token VID is driven by two concerns:

• Space considerations (driven by the need to include the version ID into the facts for as posted queries)
• Desirability of having the Version ID to be a unique identifier (e.g. ID = 12345, VID = 45678) as opposed to hierarchically dependent on the object ID (e.g. ID = 12345, VID = 1). Proponents of a unique VID are often misguided by the perceived performance advantage of using a single rather than a double key join to the dimension, a practice that almost guarantees disastrous performance implications in share-nothing partitioned databases.