Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 

Change Management in Your Database

By Dinesh Asanka,

Database Change Management

Introduction

This is the most challenging job as far as software or database developments are concerned. In the field of software, customers and the project managers are always asking for changes in the delivered software system. If these changes are done in ad hoc manner you will end up with a mess. To overcome this challenging task you have to adopt some management experience. For most of the time we, developers encounter difficulties not in developments but in managing them.

Having in the field for just over ten years in the database management and developments field here are some of my practices. You also may have some different ways of achieving this. I would like to welcome you to participate with your comments on this discussion.

Phases of the Change

As far I am concerned, there are four phases in the "change".

  1. Change Request by developers.
  2. Change Analyze
  3. Implementation
  4. Record the Change

Change Request by Developers

First developers have to request the changes in a predefined format before implementing the changes. This format is depending on the type of customers you have. The following format  is the one which I adopted.

Request ID:

 

Request By:

 

Date:

 

Customer / Project:

 

System:

 

Database:

 

Item(s) need to be changed:

 

Type of Change:  
Description:

 

 
Components Need to be Changed:

 

 
Comments:

 

 

Let me briefly describe the above format. Request ID is a unique id to identify the "change". You can use some means to give better indication to this ID. for example you can include user code , system code or the database code to this ID so that it will be much easier to identify the change the from the ID itself. Customer / Project, System, and Database is much important when you are in the process of developing multiple software systems for more than one customer. Tables, Views, Stored procedures, Triggers that require change can be included in the space allowed for Item(s) need to be changed. The developer can enter whether it is a new item or deleting existing one or modifying the item. if it is modifying, developer has to specify what he is going to modify. Description is the comprehensive description of the "change". Here you have to specify why this change is needed. Components need to be changed is very much important parameter in changing the database. As always the case in databases, on change may lead to change in one or more components. At this place developer has to specify what the other components that needs to be changed. Comments column is the space which allows developer to enter additional comments of the change.

After filling this format, the developer has to pass this to the database owner who is responsible for the whole system.

Change Analysis

After getting the request, the database owner has to analyze the change. His first task would be to find out this change is one that is really needed. If this can be done by using the existing database he must reject this by indicating the ways which can be achieved.

His main task would be to find the other components which will be affected from the "change". Even though the developer has mentioned this, database owner has to study this carefully to identify the other components. His duty will be to inform his findings to the other components' owners and the project owner. Having informing the project owner he will not release the system until all the components have been changed.

Implementation

After accepting this database owner passes this to the developer and project manager. Then database owner can perform the necessary changes that were requested by the developer.

Recording the Change

This the most important stage. For future reviews this recording of the change is very important. You may use a simple table for this recording. This recording is very useful when it comes to the analyzing part for the next change.

Further Improvements

This process can be automated. A Simple tool can be developed so that it will be easy for all the members to view the changes requested and accepted. When a request is made it can be automatically email to the user and when the changes are accepted mails can be sent to all the components' owners for those components that need to be changed.

Conclusion

As I mentioned earlier, changes are the headaches which is part and parcel of software development. If we can adopt the systematic way, then we can meet the changes without any fear. I accept that this process would time consuming. But I think sacrificing this time would be better off rather than going into a mess.

Total article views: 7190 | Views in the last 30 days: 0
 
Related Articles
FORUM

Custom data flow component..

Developing ssis destination component

ARTICLE

Three Rules for Database Development

Today Steve Jones talks about a series of rules he found for database development.

FORUM

Development and Production Database

Insert Into Development and Production Database at the same time

BLOG

SQL Server 2005 Components

Ok! There is the SQL Server 2005 Components. There is the brief information about the components: D...

FORUM

Developing a report from two different databases

Developing a report from two different databases

 
Contribute

Join the most active online SQL Server Community

SQL knowledge, delivered daily, free:

Email address:  

You make SSC a better place

As a member of SQLServerCentral, you get free access to loads of fresh content: thousands of articles and SQL scripts, a library of free eBooks, a weekly database news roundup, a great Q & A platform… And it’s our huge, buzzing community of SQL Server Professionals that makes it such a success.

Join us!

Steve Jones
Editor, SQLServerCentral.com

Already a member? Jump in:

Email address:   Password:   Remember me: Forgotten your password?
Steve Jones