The #1 Easy, Commonsense Guide to Database Design! Michael J. Hernandez’s best-selling Database Design for Mere Mortals® has earned worldwide respect as the clearest, simplest way to learn relational database design. Now, he’s made this hands-on, software-independent tutorial even easier, while ensuring that his design methodology is still relevant to the latest databases, applications, and best practices. Step by step, Database Design for Mere Mortals ® , Third Edition, shows you how to design databases that are soundly structured, reliable, and flexible, even in modern web applications. Hernandez guides you through everything from database planning to defining tables, fields, keys, table relationships, business rules, and views. You’ll learn practical ways to improve data integrity, how to avoid common mistakes, and when to break the rules.
Understanding database types, models, and design terminology
Discovering what good database design can do for you—and why bad design can make your life miserable
Setting objectives for your database, and transforming those objectives into real designs
Analyzing a current database so you can identify ways to improve it
Establishing table structures and relationships, assigning primary keys, setting field specifications, and setting up views
Ensuring the appropriate level of data integrity for each application
Identifying and establishing business rules
Whatever relational database systems you use, Hernandez will help you design databases that are robust and trustworthy. Never designed a database before? Settling for inadequate generic designs? Running existing databases that need improvement? Start here.
About the Author
Michael J. Hernandez, a relational database developer with more than twenty years of experience, was a program manager and product manager for Microsoft’s Visual Studio group. He has been a premier instructor with organizations such as AppDev Training Co., Focal Point, Inc., and Deep Training, and was a top-rated speaker at technical conferences across the United States, Europe, and South America. With John L. Viescas, he coauthored SQL Queries for Mere Mortals®, Second Edition (Addison-Wesley, 2008).
Read an Excerpt
Chapter 11: Business Rule
Reviewing the Business Rule Specification Sheets
Once you've established the Business Rules you believe to be appropriate, review their specification sheets. Carefully examine the specification sheet and make certain that the rule has been properly established and that all the appropriate areas on the sheet are clearly marked. If you find an error, make the necessary modifications and review it once more. Repeat this process until you've reviewed every Business Rule.
Business Rules are an important component of the database. Along with contributing to overall data integrity, Business Rules impose integrity constraints that are specific to the organization. As you've seen, these rules help to ensure the validity and consistency of the data within the context of the manner in which the organization functions or conducts its business. Furthermore, these rules will affect the manner in which the database is implemented in an RDBMS and how it works with the application program used to work with the database.
It's important to understand that you will revisit these rules quite often. As you review the final structure, for example, you may determine that additional Business Rules are necessary. You may discover that several of the rules will not provide the results you had initially envisioned, and thus they need to be modified. It's also possible to determine that some of the rules aren't necessary after all. (In this instance, be absolutely sure to examine the rules carefully before you remove them.)
Keep in mind that the Business Rules you define now are bound to require modifications in the future; you will most likely need to add Business Rules in due course because of changes in the way the organization functions or conducts its business. The need to modify existing Business Rules or develop new ones comes up naturally-the organization inevitably grows and matures, and so does the manner in which it acts upon or reacts to external forces. These forces affect the manner in which the organization perceives and uses its data, which, in turn, changes the nature of the organization's requirements in terms of Business Rules.
The task of defining and establishing Business Rules is-as are so many other tasks within the database design process-ongoing. Don't be discouraged if you have to perform this task several times. Your efforts will pay great dividends in the long run.
Now it's time to establish Business Rules for Mike's database. You schedule a meeting with Mike and his staff to review the tables and relationships in their database. The first order of business is to define and establish field-specific Business Rules.
You begin the process by reviewing the PRODUCTS table. As you begin to examine each field, you try to determine whether any constraints are required. Upon reviewing the CATEGORY field, you remember that there was some question as to the values that could be entered into the field. (Refer to the Case Study in Chapter 9.) After some discussion with Mike and his staff, you compile a list of categories. Then Mike decides that the values for the CATEGORY field should be limited to those on this list to make certain that the staff does not arbitrarily invent new categories. Because Mike wants to limit the values that can be entered in the CATEGORY field, you define an appropriate Business Rule to properly establish the constraint. The new rule is stated as follows:
These are the settings you've made for the table relationship characteristics:
- There is a restrict deletion rule for the relationship.
- The type of participation for the CATEGORIES table is set to "Mandatory."
- The type of participation for the PRODUCTS table is set to "Optional."
- The degree of participation for CATEGORIES is set to "(1,1)."
- The degree of participation for PRODUCTS is set to "(O,N)."
Remember that by establishing this relationship, you've replaced the existing CATEGORY field in the PRODUCTS table with a copy of the CATEGORY ID field from the new CATEGORIES table. Because the CATEGORY ID field in the PRODUCTS table is a Foreign key, you now make certain that it conforms to the Elements of a Foreign key and make the appropriate modifications to its Field Specifications. Then you modify the Range of Values element to read "Any value within the CATEGORY ID field in the CATEGORIES table." Figure 11-19 shows the Logical Elements settings of the Field Specifications for the CATEGORY ID field in the PRODUCTS table.
Now you must decide when the rule should be tested. As you already know, you typically want to test a rule established with a validation table if the user attempts to insert a value into the field or update an existing value within the field.
Finally, you complete a Business Rule Specification sheet for this new Business Rule. This specification sheet will reflect the modifications you've made to the Field Specifications for the CATEGORY ID field as well as the characteristics of the relationship between the CATEGORIES and PRODUCTS tables...
Table of ContentsForeword xxi
Part I: Relational Database Design 1
Chapter 1: The Relational Database 3
Topics Covered in This Chapter 3
Types of Databases 4
Early Database Models 5
The Hierarchical Database Model 5
The Network Database Model 9
The Relational Database Model 12
Retrieving Data 15
Advantages of a Relational Database 16
Relational Database Management Systems 18
Beyond the Relational Model 19
What the Future Holds 21
A Final Note 22
Review Questions 24
Chapter 2: Design Objectives 25
Topics Covered in This Chapter 25
Why Should You Be Concerned with Database Design? 25
The Importance of Theory 27
The Advantage of Learning a Good Design Methodology 29
Objectives of Good Design 30
Benefits of Good Design 31
Database Design Methods 32
Traditional Design Methods 32
The Design Method Presented in This Book 34
Review Questions 39
Chapter 3: Terminology 41
Topics Covered in This Chapter 41
Why This Terminology Is Important 41
Value-Related Terms 43
The Value of Nulls 46
The Problem with Nulls 47
Structure-Related Terms 49
Relationship-Related Terms 59
Types of Relationships 60
Types of Participation 65
Degree of Participation 66
Integrity-Related Terms 67
Field Specification 67
Data Integrity 68
Review Questions 70
Part II: The Design Process 73
Chapter 4: Conceptual Overview 75
Topics Covered in This Chapter 75
The Importance of Completing the Design Process 76
Defining a Mission Statement and Mission Objectives 77
Analyzing the Current Database 78
Creating the Data Structures 80
Determining and Establishing Table Relationships 81
Determining and Defining Business Rules 81
Determining and Defining Views 83
Reviewing Data Integrity 83
Review Questions 86
Chapter 5: Starting the Process 89
Topics Covered in This Chapter 89
Conducting Interviews 89
Participant Guidelines 91
Interviewer Guidelines (These Are for You) 93
The Case Study: Mike’s Bikes 98
Defining the Mission Statement 100
The Well-Written Mission Statement 100
Composing a Mission Statement 102
Defining the Mission Objectives 105
Well-Written Mission Objectives 106
Composing Mission Objectives 108
Review Questions 113
Chapter 6: Analyzing the Current Database 115
Topics Covered in This Chapter 115
Getting to Know the Current Database 115
Paper-Based Databases 118
Legacy Databases 119
Conducting the Analysis 121
Looking at How Data Is Collected 121
Looking at How Information Is Presented 125
Conducting Interviews 129
Basic Interview Techniques 130
Before You Begin the Interview Process . . . 137
Interviewing Users 137
Reviewing Data Type and Usage 138
Reviewing the Samples 140
Reviewing Information Requirements 144
Interviewing Management 152
Reviewing Current Information Requirements 153
Reviewing Additional Information Requirements 154
Reviewing Future Information Requirements 155
Reviewing Overall Information Requirements 155
Compiling a Complete List of Fields 157
The Preliminary Field List 157
The Calculated Field List 164
Reviewing Both Lists with Users and Management 165
Case Study 166
Review Questions 172
Chapter 7: Establishing Table Structures 175
Topics Covered in This Chapter 175
Defining the Preliminary Table List 176
Identifying Implied Subjects 176
Using the List of Subjects 178
Using the Mission Objectives 182
Defining the Final Table List 184
Refining the Table Names 186
Indicating the Table Types 192
Composing the Table Descriptions 192
Associating Fields with Each Table 199
Refining the Fields 202
Improving the Field Names 202
Using an Ideal Field to Resolve Anomalies 206
Resolving Multipart Fields 210
Resolving Multivalued Fields 212
Refining the Table Structures 219
A Word about Redundant Data and Duplicate Fields 219
Using an Ideal Table to Refine Table Structures 220
Establishing Subset Tables 228
Case Study 233
Review Questions 242
Chapter 8: Keys 243
Topics Covered in This Chapter 243
Why Keys Are Important 244
Establishing Keys for Each Table 244
Candidate Keys 245
Primary Keys 253
Alternate Keys 260
Table-Level Integrity 261
Reviewing the Initial Table Structures 261
Case Study 263
Review Questions 270
Chapter 9: Field Specifications 273
Topics Covered in This Chapter 273
Why Field Specifications Are Important 274
Field-Level Integrity 275
Anatomy of a Field Specification 277
General Elements 277
Physical Elements 285
Logical Elements 292
Using Unique, Generic, and Replica Field Specifications 300
Defining Field Specifications for Each Field in the Database 306
Case Study 308
Review Questions 311
Chapter 10: Table Relationships 313
Topics Covered in This Chapter 313
Why Relationships Are Important 314
Types of Relationships 315
One-to-One Relationships 316
One-to-Many Relationships 319
Many-to-Many Relationships 321
Self-Referencing Relationships 329
Identifying Existing Relationships 333
Establishing Each Relationship 344
One-to-One and One-to-Many Relationships 345
The Many-to-Many Relationship 352
Self-Referencing Relationships 358
Reviewing the Structure of Each Table 364
Refining All Foreign Keys 365
Elements of a Foreign Key 365
Establishing Relationship Characteristics 372
Defining a Deletion Rule for Each Relationship 372
Identifying the Type of Participation for Each Table 377
Identifying the Degree of Participation for Each Table 380
Verifying Table Relationships with Users and Management 383
A Final Note 383
Relationship-Level Integrity 384
Case Study 384
Review Questions 391
Chapter 11: Business Rules 393
Topics Covered in This Chapter 393
What Are Business Rules? 393
Types of Business Rules 397
Categories of Business Rules 399
Field-Specific Business Rules 399
Relationship-Specific Business Rules 401
Defining and Establishing Business Rules 402
Working with Users and Management 402
Defining and Establishing Field-Specific Business Rules 403
Defining and Establishing Relationship-Specific Business Rules 412
Validation Tables 417
What Are Validation Tables? 419
Using Validation Tables to Support Business Rules 420
Reviewing the Business Rule Specifications Sheets 425
Case Study 426
Review Questions 434
Chapter 12: Views 435
Topics Covered in This Chapter 435
What Are Views? 435
Anatomy of a View 437
Data View 437
Aggregate View 442
Validation View 446
Determining and Defining Views 448
Working with Users and Management 449
Defining Views 450
Reviewing the Documentation for Each View 458
Case Study 460
Review Questions 466
Chapter 13: Reviewing Data Integrity 469
Topics Covered in This Chapter 469
Why You Should Review Data Integrity 470
Reviewing and Refining Data Integrity 470
Table-Level Integrity 471
Field-Level Integrity 471
Relationship-Level Integrity 472
Business Rules 472
Assembling the Database Documentation 473
Done at Last! 475
Case Study—Wrap-Up 475
Part III: Other Database Design Issues 477
Chapter 14: Bad Design—What Not to Do 479
Topics Covered in This Chapter 479
Flat-File Design 480
Spreadsheet Design 481
Dealing with the Spreadsheet View Mind-set 483
Database Design Based on the Database Software 485
A Final Thought 486
Chapter 15: Bending or Breaking the Rules 489
Topics Covered in This Chapter 489
When May You Bend or Break the Rules? 489
Designing an Analytical Database 489
Improving Processing Performance 490
Documenting Your Actions 493
In Closing 497
Part IV: Appendixes 499
Appendix A: Answers to Review Questions 501
Chapter 1 501
Chapter 2 502
Chapter 3 504
Chapter 4 505
Chapter 5 506
Chapter 6 508
Chapter 7 510
Chapter 8 513
Chapter 9 516
Chapter 10 518
Chapter 11 520
Chapter 12 521
Appendix B: Diagram of the Database Design Process 525
Appendix C: Design Guidelines 543
Defining and Establishing Field-Specific Business Rules 543
Defining and Establishing Relationship-Specific Business Rules 543
Elements of a Candidate Key 544
Elements of a Foreign Key 544
Elements of a Primary Key 545
Rules for Establishing a Primary Key 545
Elements of the Ideal Field 545
Elements of the Ideal Table 546
Field-Level Integrity 546
Guidelines for Composing a Field Description 547
Guidelines for Composing a Table Description 547
Guidelines for Creating Field Names 548
Guidelines for Creating Table Names 548
Identifying Relationships 549
Identifying View Requirements 549
Interview Guidelines 550
Participant Guidelines 550
Interviewer Guidelines 550
Mission Statements 551
Mission Objectives 551
Relationship-Level Integrity 551
Resolving a Multivalued Field 552
Table-Level Integrity 552
Appendix D: Documentation Forms 553
Appendix E: Database Design Diagram Symbols 557
Appendix F: Sample Designs 559
Appendix G: On Normalization 567
Please Note . . . 568
A Brief Recap 569
How Normalization Is Integrated into My Design Methodology 572
Logical Design versus Physical Design and Implementation 575
Appendix H: Recommended Reading 577
Plain cooking cannot be entrusted to plain cooks.
In the past, the process of designing a database has been a task performed by information technology (IT) personnel and professional database developers. These people usually had mathematical, computer science, or systems design backgrounds and typically worked with large mainframe databases. Many of them were experienced programmers and had coded a number of database application programs consisting of thousands of lines of code. (And these people were usually very overworked due to the nature and importance of their work!)
People designing database systems at that time needed to have a solid educational background because most of the systems they created were meant to be used company wide. Even when creating databases for single departments within a company or for small businesses, database designers still required extensive formal training because of the complexity of the programming languages and database application programs that they were using. As technology advanced, however, those educational requirements changed and evolved.
Since the mid-1980s, many software vendors have developed database software programs that run on desktop computers and can be more easily programmed to collect, store, and manage data than their mainframe counterparts. They have also produced software that allows groups of people to access and share centralized data within a variety of environments, such as client/server architectures on computers connected within local area networks (LANs), wide are networks (WANs), and even via the Internet. People within a company or organization are no longer strictly dependenton mainframe databases or having their information needs met by centralized IT departments. Over the years, vendors have added new features and enhanced the tool sets in their database software, enabling database developers to create more powerful and flexible database applications. They've also improved the ease with which the software can be used, inspiring many people to create their own database applications. Today's database software greatly simplifies the process of creating efficient database structures and intuitive user interfaces.
Most programs provide sample database structures that you can copy and alter to suit your specific needs. Although you might initially think that it could be quite advantageous for you to use these sample structures as the basis of a new database, you should stop and reconsider that move for a moment. Why? Because you could easily and unwittingly create an improper, inefficient, and incomplete design. Then, you would eventually encounter problems in what you believed to be a dependable database design. This, of course, begs the question, "What types of problems would I encounter?"
Most problems that surface in a database fall into two categories: application problems and data problems. Application problems include such things as problematic data entry/edit forms, confusing menus, confusing dialog boxes, and tedious task sequences. These problems typically arise when the database developer is inexperienced, is unfamiliar with a good application design methodology, or knows too little about the software he's using to implement the database. Problems of this nature are common and important to address, but they are beyond the scope of this work.
Note One good way to solve many of your application problems is to purchase and study third-party "developer" books that cover the software you're using. Such books discuss application design issues, advanced programming techniques, and various tips and tricks that you can use to improve and enhance an application. Armed with these new skills, you can revamp and fine-tune the database application so that it works correctly, smoothly, and efficiently.
Data problems, on the other hand, include such things as missing data, incorrect data, mismatched data, and inaccurate information. Poor database design is typically the root cause of these types of problems. A database will not fulfill an organization's information requirements if it is not structured properly. Although a poor design is typically generated by a database developer who lacks knowledge of good database design principles, it shouldn't necessarily reflect negatively on the developer. Many peopleincluding experienced programmers and database developershave had little or no instruction in any form of database design methodology. Many are unaware that design methodologies even exist. Data problems and poor design are the issues that will be addressed in this work.
What's New in the Second Edition
I revised this edition to improve readability, update or extend existing topics, add new content, and enhance its educational value. Here is a list of the changes you'll find in this edition.
- Much of the text has been rewritten to improve clarity and reader comprehension.
- Many of the figures and illustrations have been revised to improve clarity.
- New figures and illustration added as warranted by revisions of or additons to exisitng text.
- Discussions on Relational Database Management Systems and the Relational Model in Chapter One have both been expanded to include brief content on recent technological advances and general industry direction.
- The premise behind the design methodology presented in this book is explained in Chapter Two.
- Discussions on nulls and the many-to-many relationship in Chapter Three have both been expanded to provide greater detail on these subjects.
- Web page-based examples are now included as appropriate in Chapter Six.
- Discussions on multi-valued fields and the subset tables in Chapter Seven have both been expanded to provide greater detail on these subjects.
- The discussion on primary keys in Chapter Eight has been expanded to provide greater detail on this subject.
- The Field Specifications sheet has been updated and redesigned for improved flow and readability.
- The discussion on the Data Type field specification element in Chapter Nine has been expanded to include an introduction to SQL data types.
- Discussions on self-referencing relationships and the Deny, Nullify, and Use Default deletion rules have been added to Chapter Ten.
- Review questions have been added at the end of chapters one through twelve, and the answers to the questions appear in Appendix A.
- All of the various design guidelines have been compiled together in Appendix C.
- A flowchart of the design process has been provided for use as a quick-reference tool and is included in Appendix B.
- A Glossary has been added to provide throughout the book.
- The accompanying CD includes files in Adobe Acrobat PDF format that contain the material in appendices B through F.
Who Should Read This Book
No previous background in database design is necessary to read this book. The reason you have this book in your hands is to learn how to design a database properly. If you're just getting into database management and you're thinking about developing your own databases, this book will be very valuable to you. It's better that you learn how to create a database properly from the beginning than that you learn by trial and error. The latter method takes much longer, believe me.
If you fall into the category of those people who have been working with database programs for a while and are ready to begin developing new databases for your company or business, you should read this book. You probably have a good feel for what a good database structure should look like but aren't quite sure how database developers arrive at an effective design. Maybe you're a programmer who has created a number of databases following a few basic guidelines but you always ended up writing a lot of code to get the database to work properly. If this is the case, this book is also for you.
It would be a good idea for you to read this book even if you already have some background in database design. Perhaps you learned a design methodology back in college or attended a database class that discussed design, but your memory is vague about some details, or there were parts of the design process that you just did not completely understand. Those points with which you had difficulty will finally become clear once you learn and understand design process presented in this book.
This book is also appropriate for those of you who are experienced database developers and programmers. Although you may already know many of the aspects of the design process that are presented here, you'll probably find that there are some elements that you've never before encountered or considered. You may even come up with fresh ideas on how to design your databases by reviewing the material in this book because many of the design processes familiar to you are presented here from a different viewpoint. At the very least, this book can serve as a great refresher course in database design.
Note Those of you who have a burning desire to immerse yourself in depths of the database field (i.e., learn the intricacies of database theory & design, analysis, implementation, administration, application development, etc.) should make a point of reading most of the books on my "Recommended Reading" list. Although I do not cover any of the aforementioned topics, my book does serve as the beginning of your journey into the realm of the database professional.
The Purpose of This Book
In general terms, there are three phases to the overall database development process.
Logical Design The first phase involves determining and defining tables and their fields, establishing Primary and Foreign keys, establishing table relationships, and determining and establishing the various levels of data integrity.
Physical implementation The second phase entails creating the tables, establishing key fields and table relationships, and using the proper tools to implement the various levels of data integrity.
Application development The third phase involves creating an application that allows allows a single user or group of users to interact with the data stored in the database. The application development phase itself can be divided into separate processes, such as determining end-user tasks and their appropriate sequences, determining information requirements for report output, and creating a menu system for navigating the application.
You should always go through the logical design first and execute it as completely as possible. After you've created a sound structure, you can then implement it within any database software you choose. As you begin the implementation phase, you may find that you need to modify the database structure based on the pros and cons or strengths and weaknesses of the database software you've chosen. You may even decide to make structural modifications to enhance data processing performance. Performing the logical design first ensures that you make conscious, methodical, clear and informed decisions concerning the structure of your database. As a result, you help minimize the potential number of further structural modifications you might need to make during the physical implementation and application development phases.
This book deals with only the logical design phase of the overall development process, and the book's main purpose is to explain the process of relational database design without using the advanced, orthodox methodologies found in an overwhelming majority of database design books. I've taken care to avoid the complexities of these methodologies by presenting a relatively straightforward commonsense approach to the design process. I also use a simple and straightforward data modeling method as a supplement to this approach, and present the entire process as clearly as possible and with a minimum of technical jargon.
There are many database design books out on the market that include chapters on implementing the database within a specific database product, and some books even seem to meld the design and implementation phases together. (I've never particularly agreed with the idea of combining these phases together, and I've always maintained that a database developer should perform the logical design and implementation phases separately to ensure maximum focus, effectiveness, and efficiency.) The main drawback that I've encountered with these types of books is that it can be difficult for a reader to obtain any useful or relevant information from the implementation chapters if he or she doesn't work with the particular database software or programming language that the book incorporates. It is for this reason that I decided to write a book that strictly focuses on the logical design of the database.
Note I do not cover implementation issues, SQL, or application programming issues in this work, but there are various books that I do recommend on these topics. You can review my recommendations by accessing my website and clicking on "Book Selections."
This book should be easier to read than other books you may have encountered on the subject. Many of the database design books on the market are highly technical and can be difficult to assimilate. I think most of these books can be confusing and overwhelming if you are not a computer science major, database theorist, or experienced database developer. The design principles you'll learn within these pages is easy to understand and remember, and the examples are common and generic enough to be relevant to a wide variety of situations.
Most people I've met in my travels around the country have told me that they just want to learn how to create a sound database structure without having to learn about Normal Forms or advanced mathematical theories. Many people are not as worried about implementing a structure within a specific database software as they are about learning how to optimize their data structures and how to impose data integrity. In this book, you'll learn how to create efficient database structures, how to impose several levels of data integrity, as well as how to relate tables together to obtain information in an almost infinite number of ways. Don't worry; this isn't as difficult a task as you might think. You'll be able to accomplish all of this by understanding a few key terms and by learning and using a specific set of commonsense techniques and concepts.
You'll also learn how to analyze and leverage an existing database, determine information requirements, and determine and implement business rules. These are important topics because many of you will probably inherit old databases that you'll need to revamp using what you'll learn by reading this book. They'll also be just as important when you create a new database from scratch.
When you finish reading this book, you'll have the knowledge and tools necessary to be able to create a good relational database structure. I'm confident that this entire approach will work for a majority of developers and the databases they need to create.
How to Read This Book
I strongly recommend that you read this book in sequence from beginning to end, regardless of whether you are a novice or a professional. You'll keep everything in context this way and avoid the confusion that generally comes from being unable to see the "Big Picture" first. It's also a good idea to learn the process as a whole before you begin to focus on any one part.
If you are reading this book to refresh your design skills, you could read just those sections that are of interest to you. As much as possible, I've tried to write each chapter so that it could stand on its own; nonetheless, I would still recommend that you glance through each of the chapters to make sure that you're not missing any new ideas or points on design that you may not have considered up to now.
How This Book Is Organized
Here's a brief overview of what you'll find in each part and each chapter.
Part I: Relational Database Design
This section provides an introduction to databases, the idea of database design, and some of the terminology you'll need to be familiar with in order to learn and understand the design process presented in this book.
Chapter 1, What Is a Relational Database?, provides a brief discussion of the types of databases you'll encounter, common database models, and a brief history of the relational database.
Chapter 2, Design Objectives, explores why you should be concerned with design, points out the objectives and advantages of good design, and provides a brief introduction to Normalization and Normal Forms.
Chapter 3, Terminology, covers the terms you need to know in order to learn and understand the design methodology presented in this book.
Part II: The Design Process
Each aspect of the database design process is discussed in detail in Part Two, including establishing table structures, assigning primary keys, setting field specifications, establishing table relationships, setting up views, and establishing various levels of data integrity.
Chapter 4, Conceptual Overview, provides an overview of the design process, showing you how the different components of the process fit together.
Chapter 5, Starting the Process, covers how to define a mission statement and mission objectives for the database, both of which provide you with an initial focus for creating your database.
Chapter 6, Analyzing the Current Database, covers issues concerning the existing database. We look at reasons for analyzing the current database, how to look at current methods of collecting and presenting data, why and how to conduct interviews with users and management, and how to compile initial field lists.Chapter 7, Establishing Table Structures, covers topics such as determining and defining what subjects the database should track, associating fields with tables, and refining table structures.
Chapter 8, Keys, covers the concept of keys and their importance to the design process, as well as how to define candidate and primary keys for each table.
Chapter 9, Field Specifications, covers a topic that a number of database developers tend to minimize. Besides indicating how each field is created, field specifications determine the very nature of the values a field contains. Topics in this chapter include the importance of field specifications, types of specification characteristics, and how to define specifications for each field in the database.
Chapter 10, Table Relationships, explains the importance of table relationships, types of relationships, setting up relationships, and establishing relationship characteristics.
Chapter 11, Business Rules, covers types of business rules, determining and establishing business rules, and using validation tables. Business rules are very important in any database because they provide a distinct level of data integrity.
Chapter 12, Views, looks into the concept of views and why they are important, types of views, and how to determine and set up views.
Chapter 13, Reviewing Data Integrity, reviews each of the levels of integrity that have been defined and discussed in previous chapters. Here you learn that it's a good idea to review the final design of the database structure to ensure that you've imposed data integrity as completely as you can.
Part III: Other Database Design Issues
This section deals with topics such as avoiding bad design and bending the rules set forth in the design process.
Chapter 14, Bad DesignWhat Not To Do, covers the types of designs you should avoid, such as a flat file design and a spreadsheet design.
Chapter 15, Bending or Breaking the Rules, discusses those rare instances in which it may be necessary to stray from the techniques and concepts of the design process. This chapter tells you when you should consider bending the rules, as well as how it should be done.
IMPORTANT: READ THIS SECTION!
A Word About the Examples and Techniques in This Book
You'll notice that there are a wide variety of examples in this book. I've made sure that they are as generic and relevant as possible. However, you may have noticed that several of the examples are rather simplified, incomplete, or even on occasion incorrect. Believe it or not, I created them that way on purpose.
I've created some examples with errors so that I could illustrate specific concepts and techniques. Without these examples, you wouldn't see how the concepts or techniques are put to use, as well as the results you should expect from using them. Other examples are simple because, once again, the focus is on the technique or concept and not on the example itself. For instance, there are many ways that you can design an Order Tracking database. However, the structure of the sample Order Tracking database I use in this book is simple because the focus is specifically on the design process, not on creating an elaborate Order Tracking database system.
So what I'm really trying to emphasize here is this:
Focus on the concept or technique and its intended results, not on the example used to illustrate it.
A New Approach to Learning
Here's an approach to learning the design process (or pretty much anything else, for that matter) that I've found very useful in my database design classes.Think of all the techniques used in the design process as a set of tools; each tool (or technique) is used for a specific purpose. The idea here is that once you learn generically how a tool is used, you can then use that tool in any number of situations. The reason you can do this is because you use the tool the same way in each situation.
Take a Crescent wrench, for example. Generically speaking, you use a Crescent wrench to fasten and unfasten a nut to a bolt. You open or close the jaw of the wrench to fit a given bolt by using the adjusting screw located on the head of the wrench. Now that you have that clear, try it out on a few bolts. Try it on the legs of an outdoor chair, or the valve cover on an engine, or the side panel of an outdoor cooling unit, or the hinge plates of an iron gate. Do you notice that regardless of where you encounter a nut and bolt, you can always fasten and unfasten the nut by using the Crescent wrench in the same manner?
The tools used to design a database work in exactly the same way. Once you understand how a tool is used generically, it will work the same way regardless of the circumstances under which it is used. For instance, consider the tool (or technique) for decomposing a field value. Say you have a single ADDRESS field in a CUSTOMERS table that contains the street address, city, state, and zip code for a given customer. You'll find it difficult to use this field in your database because it contains more than one item of data; you'll certainly have a hard time retrieving information for a particular city or sorting the information by a specific zip code.
The solution to this apparent dilemma is to decompose the ADDRESS field into smaller fields. You do this by identifying the distinct items that make up the value of the field, and then treating each item as its own separate field. That's all there is to it! This process constitutes a "tool" that you can now use on any field containing a value composed of two or more distinct data items, such as these sample fields.
Note You'll learn more about decomposing field values in Chapter 7, "Establishing Table Structures."
You can use all of the techniques ("tools") that are part of the design process presented in this book in the same manner. You'll be able to design a database structure using these techniques regardless of the type of database you need to create. Just be sure to remember this:
Focus on the concept or technique being presented and its intended results, not on the example used to illustrate it.