Test Data and Conclusion

In Chapters 2, 3, and this chapter, you learned some of the principles of database design. The purpose was to teach you basic relational database principles and give you an overall sense of database design. But please remember that, in my attempt to make a coherent presentation of reasonable length, I've left out important steps in creating a real-world database.

For example, I've mentioned nothing about testing your database. You will want to use test data to be sure your database can generate the required queries, forms, and reports that meet your mission objectives. You will want to use both "good" test data and "bad" test data. Good test datadata that is accurate and meets data integrity standardswill show you whether you can enter the data you need and output it in the form of reports. Bad test data is data that violates the rules. You will want to make sure you cannot enter bad data into your database.

Testing your data makes little sense until you designate field specifications, another topic I have barely mentioned. For each field you create, you will determine various characteristics. Do you want the field to be requiredthat is, must you enter a value in every record? Do you want to include a default value for the field, for easy data entry? Do you want to limit the field to a certain sizesay, two characters for a State field in a table of contact info? Should there be a validation rule that implements business rulessay, a limit on the number of units you can keep in stock of any item?

These questions can be answered only with a knowledge of field properties, the most important topic in the next chapter on table creation.

Note that ClassicTVChap4End.mdb shows the ClassicTVChap4.mdb database as of the end of the chapter. ClassicTVChap4All Relationships.mdb has the database with all relationships created, as shown in Figure 4.1. These databases can be downloaded from the companion website.