Done at Last

   

Assembling the Database Documentation

Throughout the database-design process, you've generated a number of lists, specification sheets, and diagrams used to record various aspects of the database-design. You should now assemble them into a central repository, preferably in a set of binders. (Incidentally, you could generate and store these documents using a computer program.) The design repository should consist of the following sets of documents:

Final table list

Relationship diagrams

Field Specifications sheets

Business Rule Specifications sheets

Calculated-field list

View diagrams

Table structure diagrams

View Specifications sheets

Two additional sets of items you may consider keeping with this documentation are the notes you compiled during the design process and the samples you gathered during the analysis stage of the design process. You can keep each of these items in a separate appendix at the end of the documentation.

All of these items constitute the complete set of documentation for the logical design of the database. This documentation is vital for three reasons:

  1. It provides a complete record of the database structure. You can find every aspect of the logical structure of the database within the documentation. Additionally, you can answer almost any question concerning the database simply by referring to the documentation.

  2. It provides a complete set of specifications and instructions on how the database should be created during the implementation process. This documentation is similar to an architect's blueprints: It indicates how the database is to be constructed . It also identifies the integrity that needs to be established for the database. Because the database design is not directed to a particular RDBMS, the individuals implementing the database have full latitude concerning the manner in which they physically implement the database.

  3. Should it seem necessary to modify the database structure during the implementation process, the design documentation can be used to determine the effects and consequences of any modifications. Any modifications you make to the database structure should be the result of an informed decision. You can make certain that a proposed modification will not have an adverse effect on the database structure by referencing the documentation first.


   
Top


Database Design for Mere Mortals[c] A Hands-On Guide to Relational Database Design
Database Design for Mere Mortals: A Hands-On Guide to Relational Database Design
ISBN: 0201694719
EAN: 2147483647
Year: 2002
Pages: 203

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net