Table Relationships - Database Design for Mere Mortals - page 269

are problems that arise from such modifications when you load the revised STUDENTS
table with sample data.
Figure 10.19 clearly illustrates the problems you'll encounter using this method.
• The table contains unnecessary duplicate fields. You learned all about unnecessary
duplicate fields and the problems they pose back in Chapter 7 , so you know that
using them here is not a good idea. Besides, it is very likely that the C LASS N AME
and I NSTRUCTOR ID fields are not appropriate in the STUDENTS table—the C LASS
ID field identifies the class sufficiently, and it is really all you need to identify the
classes a student is taking.
• There is a large amount of redundant data. Even if you remove the C LASS N AME
and I NSTRUCTOR ID fields from the STUDENTS table, the C LASS ID field will still
produce a lot of redundant data.
• It is difficult to insert a new record. If you enter a record in the STUDENTS table
for a new class (instead of entering it in the CLASSES table) without also entering
student data, the fields pertaining to the student will be null—including the
primary key of the STUDENTS table (S TUDENT ID). This will automatically trig-
ger a violation of the Elements of a Primary Key because the primary key cannot
be null; therefore, you cannot insert the record into the table until you can provide
a proper primary key value.
• It is difficult to delete a record. This is especially true if the only data about a new
class has been recorded in the particular student record you want to delete. Note
the record for Diana Barlet, for example. If Diana decides not to attend any classes
this year and you delete her record, you will lose the data for the “Introduction to
Database Design” class. That might not create a serious problem—unless someone
neglected to enter the data about this class into the CLASSES table as well. Once
you delete Diana's record, you'll have to reenter all of the data for the class in the
CLASSES table.