Data Model Versioning

DataModel 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 (Smart Management 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.

Interview Question:

How do you implement data model versioning?