What is Data Model Versioning?

Data Model Versioning | Concepts | Advantages | Uses:

Data Model Versioning is the process of assigning either unique version names or unique version numbers to different stages of a data model. Data Modeling tools may have this versioning facility in their software itself and versions of data models may be stored in their repository.

The following information just gives an idea about how to do versioning manually.

Example:

a) <Project Name>_<mmddyyyy>; Banking_01012010

b) <Project Name>_<Version Number>; Banking_v1

During the development cycle of the data model, SME’s (Subject Matter Experts) or Business Analysts will request the data modeling team to create a new subject area for a new line of business or modify the existing subject area.

In the initial stages of development of a data model, whenever a new subject area is added to the data model or changes done to the data model, immediately, data model changes will be sent to the “project team” by email. Data Models are stored in a shared network where “project team” will have privileges to view the data model and “data modelers” will have privileges to update the data model.

Practical Example:

To start with, A bank may have “savings account” as their line of business. Later it may add a different line of business “Credit Card”. To start with, data model will have only only subject area “Savings Account”. When credit card is added to the bank’s business, SMEs or business analyst will analyze it and they will send a new requirement to the data modeling team to add different entities in the logical data model. They may also send few changes(add attribute/delete attribute) in existing “Savings Account” data model. In order to keep track of these changes, we need versioning of the data model.

Versioning Example:

Assume that this data model work will be completed within 6 months starting from Jan 2010 and ending in June 2010.

In the shared network allocated for the project team, create a folder called “Data Modeling”. Under data modeling, create sub folders like “Jan 2010”, “Feb 2010”, “Mar 2010”, “Apr 2010”, “May 2010” and “June 2010”. The logic behind this is data model updates done in that particular month are stored under that month folder.

For Data Models, Start with version V1 in January and update it to V2 in February. Whatever other changes you do within that particular month, suffix “V1” or “V2” by .1, .2 etc.

Date: 1st January 2010: A new requirement to create “Savings Account” data model was given by SMEs or business analysts. Assume that the project name is “Banking”. Create a data model by name “Banking_v1” and add necessary entities in the data model. Save it under “Jan 2010” folder.
Date: 25th January 2010: Few changes have been sent by SMEs for “Savings Account” subject area. Save the existing data model as “Banking_V1.1”, update the changes and store it under “Jan 2010” folder. Now you have two versions of the data model.
Date: 25th February 2010: A new requirement about “Credit Card” was sent by SMEs. Save the the latest model “Banking_v1.1” as “Banking_v2” and apply the changes. Now you have three versions of data model. Store it under “Feb 2010” folder.

Advantages:

Data Model Changes can be tracked. Weekly or monthly changes can be sent to the project team by email.
Data Model can be compared with the data base and data models can be brought in SYNC with data base.
Changes can be easily rolled back (Removing the changes). If SMEs or business analysts are not sure, very often these roll backs will happen.
Reports can be generated from the data model and sent to the “documentation team”.
Clarity within the project team.
Some times the project team may be interested in a particular version of the data model. Its easier to send that particular version of the data model.