The Database Life Cycle

 

The following common sense principles must be considered during the design and implementation of any database:

?         Determining the need for a system

?         Defining the goals for the system

?         Gathering business requirements

?         Converting business requirements to system requirements

?         Designing the database and application interface

?         Building, testing, and implementing the database and application

 

These principles are applied by most database design methodologies.

 

A methodology is a set of guidelines for designing a database.

 

The Barker method is one of the most common methodologies used for relational databases, and involves the following seven phases:

??????????? 1.???????? Strategy

??????????? 2.???????? Analysis

??????????? 3.???????? Design

??????????? 4.???????? Build

??????????? 5.???????? Documentation

??????????? 6.???????? Transition

??????????? 7.???????? Production

 

Strategy involves planning the design effort.

In the analysis phase, the development team interviews key employees to gather all the business requirements - which will be used as a model for the system.

During the design phase, a physical model is designed based on the logical model that was designed in the analysis phase.

After the design is complete, the database is built.

The use of documentation is extremely beneficial, both for system users and application users.

During the transition phase, data is prepared to be moved into the production environment. The end-user application is tested against the database with real data to ensure that all components of the application function properly and that the integrity of the data as stored in the database is consistent.

Finally, the database is ported into a production environment, where it is available to the end user for daily use.


The following figure outlines the 7 phases of the Barker method:

 

 

A design methodology may be adapted to meet an organization?s needs.

 

The Oracle Designer adapted design method is outlined in the following steps:

??????????? 1.???????? Strategy

??????????? 2.???????? Pre-analysis

??????????? 3.???????? Analysis

??????????? 4.???????? Pre-design

??????????? 5.???????? Design

??????????? 6.???????? Build

??????????? 7.???????? Test

??????????? 8.???????? Implementation

??????????? 9.???????? Maintenance


Maintenance?is a huge part of the life of most information systems.

After a system has been designed, tested, and implemented, it must be maintained for the remainder of its life.

Maintenance includes performance tuning and change management.

Two levels of system maintenance that must occur are as follows:

? 1.???????? Database maintenance?- Involves the maintenance of the back-end database, related mainly to how data is stored in the database and how it grows after a given period of time. When new data is created in the database and old data is deleted, fragmentation occurs. One of the main tasks during database maintenance is to monitor the usage and growth of the database, and keep fragmentation to a minimum. Also, it is important to tune the database after it has been implemented to attempt to improve overall performance for the end user. Changes that might occur to a database throughout its life include the addition or deletion of database tables, columns, or indexes. It might be necessary to change any piece of the database structure as business and user needs change. Change requests are usually provided by the end user or the development team if an application change is also being made. Changes are implemented by the development team and the database administrator. Database maintenance is performed by the database administrator.

? 2.???????? Application maintenance?- Involves the ongoing maintenance of an application after it has initially been made available to the end user. Performance tuning an application might be related to the way the application accesses objects in the database. One of the most common performance problems associated with an application involves the underlying SQL and programming code. There are many ways to write code to perform the same task. For example, if a window in the application that reads the database retrieves data slowly on a consistent basis, the SQL query behind the window should be examined and tuned if necessary. Change requests are usually provided by the end user. Application maintenance is performed by application developers, although changes to the application might sometimes be recommended by the database administrator.


Overview of the Database Life Cycle

The database life cycle starts with a requirement to have information available for the operation of a business.

The company begins to plan for this proposed database, and resources are allocated for its development.

There are several reasons that provoke the need for a database.

Likewise, the need for a particular database implementation might perish for additional reasons. Some of these reasons are:

?      The company changes the way it does business.

?      New technology renders the existing database obsolete.

?      An existing database needs to be re-engineered, but the costs would be far greater than designing a new database because of the volume of revisions involved.

The following database environments are associated with the life of a database:

?         Development

?         Test

?         Production

 

The following figure illustrates these environments:



Following is a development evaluation checklist?that might assist in determining if a database is ready to be tested:

?         Are all processes reflected in the application?

?         Are all business entities accounted for in the database?

?         Do all data elements and processes defined allow new records to be entered?

?         Do all data elements and processes defined allow existing records to be modified?

?         Do all data elements and processes defined allow existing records to be deleted?

?         Do all data elements and processes defined allow existing records to be queried?

?         Are all table relationships accurate?

?         Has referential integrity been applied?

?         Have obvious indexes been created?

?         Have views been created where needed?

?         Does the database need to be normalized?

?         Have all errors been accounted for and corrected during object creation?

The following test evaluation checklist?might help determine if a database and application has been properly tested and if it is time to make the transition to production:

?         How much time has been allocated to test the system?

?         When is the system expected in production?

?         Do any data relationships need to be modified?

?         Are business rules being followed?

?         How did the database application interface perform?

?         Was the system tested with real data?

?         Was the system tested with a realistic volume of data?

?         Was data integrity compromised during testing?

?         Were all changes tested thoroughly?

?         Was the database queried after changes were made to data using the application interface (using a combination of the application and manual transactions and queries to ensure that the application is working properly)?

?         Have all requirements for the system been double-checked for completeness?

The following production evaluation checklist?might assist in the evaluation of a recent implementation, as well as the decision to make modifications in attempt to improve the system:

?         Were there any errors during implementation?

?         Does the end user have any complaints?

?         How does the system seem to perform?

?         Was all live data loaded or converted successfully?

?         What is the average number of concurrent users?

?         Are any areas for immediate improvement in database functionality or performance recognized?

?         Are any areas for immediate improvement in application functionality or performance recognized?


The following figure illustrates possible problems if database changes are not properly tested between versions: