Life cycle of a relational database

From Wikipedia, the free encyclopedia

To comply with Wikipedia's quality standards, this article may need to be rewritten.
Please help improve this article. The discussion page may contain suggestions.

The life cycle of a relational database is the cycle of development and changes that a database goes through during the course of its life. The cycle typically consists of several stages. There is possibility that the database designer/developer can go back to any of the previous stages. This represents an admission that a full understanding of a problem and its solution is likely to evolve as the various stages of design and implementation proceed. The typical eleven stages involved in the life cycle of a relational database are as follows:

BE AWARE THIS IS ONLY ONE VERSION, MULTIPLE DIFFERING VERSIONS EXIST

The designer must try to obtain as complete as possible an understanding of the real world problem that is going to be helped by the introduction of a database. This understanding of the nature of the problem and the constraints and outline feasible solutions is often performed using some systems analysis methodology.
The entity relationship diagram is drawn, and this diagram in its modified form serves as an essential part of the logical schema. Attributes of the entity types so produced are then added. Primary and foreign keys are specified.
Normalization is used to check the entity-relationship model. Some splitting and even recombination of entity types may result from normalization and the entity relationship model will have to be updated accordingly. The entity relationship model and the table definitions resulting from normalization should be consistent.
Set of Table(s) definition for the required schema is finalized.
The database tables are created. Primary, Foreign keys, database constraints and database integrity rules are specified at this stage.
At this stage, the file organization is performed. File organization is the way the database relations are to be stored on the storage medium. The file organization is decided on the basis of maximum speed of access, the type of access required and storage space considerations. There are two factors to consider; firstly how the records are to be physically mapped onto the storage medium, and secondly which indexes are to be used and if so, which fields (attributes, columns) are to be indexed. Indexes are designed to increase the speed of access to required records. Views can also be defined at this stage. Views are used to limit access to parts of database only, when used in conjunction with access privileges. Views also make programming simpler.
The designer will be able to design the required queries at this stage. The designer should have a good idea of the main types of query and reports the database will have to accommodate.
At this stage, application screens are designed. The application screens are used to capture the input information that will be kept in the database. Screen design is partially determined by the data items that must be input and output by particular applications and partially in human-computer interface terms. When designing screens, special consideration is given to the suggestions given by the application end users. There are published standards which can be exactly followed for screens design or organization can develop their own screen design standards as per their requirements.
Report design is another area where input from users is paramount. They will specify what they want to see on the reports and the format of the reports and in the case of regular reports, when they should be produced. Now-a-days most of the application design tools provide easy to use friendly tools for quick reports development. e.g. report builder in Oracle, Crystal Reports, R&R Report Writer etc.
Testing is performed at this stage. Application screens, various functions offered by the application screens, data validations through screens and reports are tested and it serves as the ultimate test of the correctness of the database schema and the viability of the system as a whole. It is recommended to create a test database separate of the production database. The test database will be useful for testing any schema changes and new and modified application before applying the changes to the production (live) database. Careful testing of the system before handover will minimize the expense of later modifications to the schema and major applications.
The final stage is Handover. This is the stage where the users receive the finished database and applications and begin data entry. In practice, it is likely that the core of the system will be handed over to users and later extensions to the system will be implemented.