Database Reference
In-Depth Information
phasize this point. As long as you guarantee that each of your tables represents a
single subject, you greatly reduce the risk of potential data integrity problems. This
element validates the work you've done during the analysis and interview stages of
the database design process, as well as the work you've just recently performed.
•
It has a primary key.
This is important for two reasons: A primary key uniquely
identifies each record within a table, and it plays a key role (no pun intended) in
establishing table relationships. Additionally, it has specific characteristics that
help to implement and enforce various levels of data integrity. If you fail to assign
a primary key to each table, you will eventually have data integrity problems.
•
It does not contain multipart or multivalued fields.
Theoretically, you should have
resolved these issues when you refined the field structures. Nevertheless, it's still a
good idea to review the fields one last time to ensure that you've completely re-
moved each and every one of them.
•
It does not contain calculated fields.
Although you might believe that your current
table structures are free of calculated fields, you may have accidentally overlooked
one or two calculated fields during the field refinement process. This is a good
time to review the table structures once more and make certain you remove those
calculated fields you may have missed.
•
It does not contain unnecessary duplicate fields.
(Note that this guideline does not
apply to fields used to relate a set of tables together, such as those used in the ex-
ample in
Figure 7.22
.) One of the hallmarks of a poorly designed table is the inclu-
sion of duplicate fields from other tables. You might feel compelled to add duplic-
ate fields to a table for one of two reasons: to provide reference information or to
indicate multiple occurrences of a particular type of value. Duplicate fields such as
these raise various difficulties when you work with the data or attempt to retrieve
information from the table.
•
It contains only an absolute minimum amount of redundant data.
Remember that a
relational database will never be completely free of redundant data. But you
can—and should—make certain that each table contains as little redundant data as
possible.
Resolving Unnecessary Duplicate Fields
Before you make final modifications to the table structures, you must first remove all un-
necessary duplicate fields from the database. You can then refine the tables so that they
comply with the Elements of the Ideal Table.
