Database Design for Mere Mortals®

Michael J. Hernandez is a program manager for the Visual Studio .NET group at Microsoft, and is a veteran relational database developer with more than fourteen years of experience. He has been a premiere instructor with training organizations such as AppDev Training Co., Focal Point, Inc., and Deep Training, and was one of the first two hundred Microsoft-authorized .NET instructors. He speaks regularly at conferences. 0201694719AB02032003

Foreword.


Preface and Acknowledgments.
I. RELATIONAL DATABASE DESIGN.

1. What Is a Relational Database?


Types of Databases.



Early Database Models.



The Hierarchical Database Model.



The Network Database Model.



The Relational Database Model: A Brief History.



Relational Database Management Systems.

2. Design Objectives.


Why Should You Be Concerned with Database Design?



The Importance of Theory.



The Advantage of Learning Good Design Methodology.



The Importance of Understanding Database Design.



Objectives of Good Design.



Advantages of Good Design.



Database Design Methods.



Traditional Design Methods.



The Design Method Presented in This Book.

3. Terminology.


Why This Terminology Is Important.



Value-related Terms.



Data.



Information.



Null.



Structure-related Terms.



Table.



Field.



Record.



View.



Keys.



Index.



Relationship-related Terms.



Relationships.



Types of Relationships.



Types of Participation.



Degree of Participation.



Integrity-related Terms.



Field Specification.



Data Integrity.

II. THE DESIGN PROCESS.

4. Conceptual Overview.


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 Establishing Views.



Reviewing Data Integrity.

5. Starting the Process.


Conducting Interviews.



The Case Study: Mike's Bikes.



Defining the Mission Statement.



The Well-written Mission Statement.



Composing a Mission Statement.



Case Study.



Defining the Mission Objectives.



Well-written Mission Objectives.



Composing Mission Objectives.



Case Study.

6. Analyzing the Current Database.


Getting to Know the Current Database.



Paper-based Databases.



Legacy Databases.



Conducting the Analysis.



Looking at How Data Is Collected.



Looking at How Information Is Presented.



Conducting Interviews.



Conducting User Interviews.



Reviewing Data Type and Usage.



Reviewing the Samples.



Reviewing Information Requirements.



Conducting Management Interviews.



Reviewing Current Information Requirements.



Reviewing Additional Information Requirements.



Reviewing Future Information Requirements.



Reviewing Overall Information Requirements.



Compiling a Complete List of Fields.



The Preliminary Field List.



The Calculated Field List.



Reviewing Both Lists with Users and Management.



Case Study.

7. Establishing Table Structures.


Defining the Preliminary Table List.



Determining Implied Subjects.



Using the List of Subjects.



Using the Mission Objectives.



Defining the Final Table List.



Refining the Table Names.



Indicating the Table Types.



Composing the Table Descriptions.



Associating Fields with Each Table.



Refining the Fields.



Improving the Field Names.



Using the Ideal Field to Resolve Anomalies.



Refining the Table Structures.



A Word about Redundant Data and Duplicate Fields.



Using the Ideal Table to Refine Table Structures.



Establishing Subset Tables.



Case Study.

8. Keys.


Why Keys Are Important.



Establishing Keys for Each Table.



Candidate Keys.



Primary Keys.



Non-keys.



Table-Level Integrity.



Reviewing the Initial Table Structures.



Case Study.

9. Field Specifications.


Why Field Specifications Are Important.



Field-Level Integrity.



Anatomy of a Field Specification.



General Elements.



Physical Elements.



Logical Elements.



Specification Information.



Defining Field Specifications for Each Field in the Database.



Case Study.

10. Table Relationships.


Types of Relationships.



One-to-One Relationships.



One-to-Many Relationships.



Many-to-Many Relationships.



Identifying Existing Relationships.



Establishing Each Relationship.



One-to-One and One-to-Many Relationships.



Many-to-Many Relationships.



Reviewing the Structure of Each Table.



Refining All Foreign Keys.



Establishing Relationship Characteristics.



Establishing a Deletion Rule for Each Relationship.



Identifying the Type of Participation for Each Table.



Identifying the Degree of Participation for Each Table.



Verifying Table Relationships with Users and Management.



Relationship-Level Integrity.



Case Study.

11. Business Rules.


What Are Business Rules?



Types of Business Rules.



Categories of Business Rules.



Defining and Establishing Business Rules.



Working with Users and Management.



Defining and Establishing Field-Specific Business Rules.



Defining and Establishing Relationship-Specific Business Rules.



Validation Tables.



What Are Validation Tables?



Using Validation Tables to Support Business Rules.



Reviewing the Business Rule Specification Sheets.



Case Study.

12. Views.


What Are Views?



Anatomy of a View.



Data Views.



Aggregate Views.



Validation Views.



Determining and Establishing Views.



Working with Users and Management.



Establishing Views.



Reviewing the Documentation for Each View.



Case Study.

13. Reviewing Data Integrity.


Why You Should Review Data Integrity.



Reviewing and Refining Data Integrity.



At the Table Level.



At the Field Level.



At the Relationship Level.



At the Level of Business Rules.



At the Level of Views.



Assembling the Database Documentation.



Done at Last!



Case StudyÐWrap Up.

III. DATABASE DESIGN ISSUES.

14. Bad Design - What Not To Do.


Flat-File Design.



Spreadsheet Design.



Dealing with the Spreadsheet View Mind-set.



Database Design Based on Database Software.



A Final Thought.

15. Bending or Breaking the Rules.


When May You Bend or Break the Rules?



Designing an Analytical Database.



Improving Processing Performance.



Documenting Your Actions.



In Closing.

Appendix A. Recommended Reading.
Appendix B. Sample Designs.
Appendix C. Diagram Symbols.
Appendix D. Documentation Forms.
References.
Index. 0201694719T04062001