Microsoft Office Tutorials and References
In Depth Information
Storing this data on multiple records is an example of redundancy, which causes
several problems, including:
1. Wasted storage space. The name of Recruiter 24 (Camden Reeves), for example,
should be stored only once. Storing this fact several times is wasteful.
2. More difﬁ cult database updates. If, for example, Camden Reeves’s name is spelled
wrong and needs to be changed in the database, his name would need to be
changed in several different places.
3. A possibility of inconsistent data. There is nothing to prohibit the recruiter’s
last name from being Reeves on client BH72’s record and Reed on client BL12’s
record. The data would be inconsistent. In both cases, the recruiter number is 24,
but the last names are different.
The solution to the problem is to place the redundant data in a separate table, one in
which the data no longer will be redundant. If, for example, you place the data for recruiters
in a separate table (Figure 1–4), the data for each recruiter will appear only once.
Ca m den
appears only once
Notice that you need to have the recruiter number in both tables. Without it, there
would be no way to tell which recruiter is associated with which client. The remaining
recruiter data, however, was removed from the Client table and placed in
the Recruiter table. This new arrangement corrects the problems of redundancy in the
1. Because the data for each recruiter is stored only once, space is not wasted.
2. Changing the name of a recruiter is easy. You have only to change one row in the
3. Because the data for a recruiter is stored only once, inconsistent data cannot
occur. Designing to omit redundancy will help you to produce good and valid
You should always examine your design to see if it contains redundancy. If it does, you
should decide whether you need to remove the redundancy by creating a separate table.