Database Design Based on the Database Software

An RDBMS does not provide a basis or procedure or even a reason for designing a database in a particular fashionit only provides the tools that you need to implement a design. In contrast, a formal database-design method provides both the principles and rationale necessary to define a database properly and effectively.

Many people unwittingly fall into the trap of designing a database based solely on the RDBMS software they will use for its implementation. In many cases, they do so because they are already somewhat familiar and skilled with a particular RDBMS. This is an unwise approach that you should avoid for several reasons:

• You're likely to make design decisions based on your perceptions of what your RDBMS can or can't do. For example, you may decide not to impose a degree of participation for a given relationship because you believe the RDBMS does not provide you with the means to do so.

• You'll inadvertently let the RDBMS dictate the design of the database as opposed to driving the design strictly from the organization's information requirements. This usually occurs when you discover that your RDBMS provides only limited support for certain aspects of the database, such as field specifications and relationship characteristics.

• Your design will be constrained by your knowledge of the RDBMS. For example, you may decide not to implement relationship characteristics simply because you don't know how to do so.

• Your design will be constrained by how skilled you are with your RDBMS. Your skill level affects how efficiently and effectively you can implement various aspects of the database, such as field specifications and business rules.

• Using this approach to design a database commonly results in improper structural design, insufficient data integrity, and problems with inconsistent data and inaccurate information. Defining a database within an RDBMS can be deceptively easy. You may create a database that works, but you're very likely to have a poor design without knowing it.

• In the end, the RDBMS that you know and love so well may not be suitable for your organization's database requirements.

You should always design the logical structure of your database without regard to any RDBMS. By doing so, you're more likely to design a sound structure because you'll be focused on the organization's information requirements. Once your design is complete, you can then clearly determine how you should implement the database (single-user application, client/server, Web-based, and so on) and which RDBMS you should use to facilitate the implementation.

Top Part I: Relational Database Design Chapter 1. The Relational Database Topics Covered in This Chapter Types of Databases Early Database Models The Relational Database Model Relational Database Management Systems Beyond the Relational Model What the Future Holds Summary Review Questions Chapter 2. Design Objectives Topics Covered in This Chapter Why Should You Be Concerned with Database Design? The Importance of Theory The Advantage of Learning a Good Design Methodology Objectives of Good Design Benefits of Good Design Database-Design Methods Summary Review Questions Chapter 3. Terminology Topics Covered in This Chapter Why This Terminology Is Important Value-Related Terms Structure-Related Terms Relationship-Related Terms Integrity-Related Terms Summary Review Questions Part II: The Design Process Chapter 4. Conceptual Overview Topics Covered in This Chapter The Importance of Completing the Design Process Defining a Mission Statement and Mission Objectives Analyzing the Current Database Creating the Data Structures Determining and Establishing Table Relationships Determining and Defining Business Rules Determining and Defining Views Reviewing Data Integrity Summary Review Questions Chapter 5. Starting the Process Topics Covered in This Chapter Conducting Interviews The Case Study: Mike's Bikes Defining the Mission Statement Defining the Mission Objectives Summary Review Questions Chapter 6. Analyzing the Current Database Topics Covered in This Chapter Getting to Know the Current Database Conducting the Analysis Looking at How Data Is Collected Looking at How Information Is Presented Conducting Interviews Interviewing Users Interviewing Management Compiling a Complete List of Fields Summary Review Questions Chapter 7. Establishing Table Structures Topics Covered in This Chapter Defining the Preliminary Table List Defining the Final Table List Associating Fields with Each Table Refining the Fields Refining the Table Structures Summary Review Questions Chapter 8. Keys Topics Covered in This Chapter Why Keys Are Important Establishing Keys for Each Table Table-Level Integrity Reviewing the Initial Table Structures Summary Review Questions Chapter 9. Field Specifications Topics Covered in This Chapter Why Field Specifications Are Important Field-Level Integrity Anatomy of a Field Specification Using Unique, Generic, and Replica Field Specifications Defining Field Specifications for Each Field in the Database Summary Review Questions Chapter 10. Table Relationships Topics Covered in This Chapter Why Relationships Are Important Types of Relationships Identifying Existing Relationships Establishing Each Relationship Refining All Foreign Keys Establishing Relationship Characteristics Relationship-Level Integrity Summary Review Questions Chapter 11. Business Rules Topics Covered in This Chapter What Are Business Rules? Categories of Business Rules Defining and Establishing Business Rules Validation Tables Reviewing the Business Rule Specifications Sheets Summary Review Questions Chapter 12. Views Topics Covered in This Chapter What Are Views? Anatomy of a View Determining and Defining Views Summary Review Questions Chapter 13. Reviewing Data Integrity Topics Covered in This Chapter Why You Should Review Data Integrity Reviewing and Refining Data Integrity Assembling the Database Documentation Done at Last! Summary Part III: Other Database-Design Issues Chapter 14. Bad Design-What Not to Do Topics Covered in This Chapter Flat-File Design Spreadsheet Design Database Design Based on the Database Software A Final Thought Summary Chapter 15. Bending or Breaking the Rules Topics Covered in This Chapter When May You Bend or Break the Rules? Documenting Your Actions Summary In Closing Part IV: Appendixes Appendix A. Answers to Review Questions Chapter 1 Chapter 2 Chapter 3 Chapter 4 Chapter 5 Chapter 6 Chapter 7 Chapter 8 Chapter 9 Chapter 10 Chapter 11 Chapter 12 Appendix B. Diagram of the Database-Design Process Appendix C. Design Guidelines Defining and Establishing Field Specific Business Rules Defining and Establishing Relationship Specific Business Rules Elements of a Candidate Key Elements of a Foreign Key Elements of a Primary Key Elements of the Ideal Field Elements of the Ideal Table Field-Level Integrity Guidelines for Composing a Field Description Guidelines for Composing a Table Description Guidelines for Creating Field Names Guidelines for Creating Table Names Identifying Relationships Identifying View Requirements Interview Guidelines Mission Statements Mission Objectives Relationship-Level Integrity Resolving a Multivalued Field Table-Level Integrity Appendix D. Documentation Forms Appendix E. Database-Design Diagram Symbols Appendix F. Sample Designs Appendix G. Recommended Reading Remember the name: eTutorials.org Copyright eTutorials.org 2008-2023. All rights reserved.