Database Reference
In-Depth Information
•
Unnecessary duplicate fields:
Each of the fields pertaining to a particular item is a
duplicate. For example, the I
TEM
1, I
TEM
2, and I
TEM
3 fields are unnecessary du-
plicate fields.
•
No true primary key:
There is no field or group of fields that can uniquely identify
a single record in this table. The O
RDER
N
UMBER
field is not a primary key in this
table; if a customer orders more than three items, you'll have to enter another re-
cord into the table using the
same
order number.
•
The table represents more than one subject.
This table represents three subjects:
customers, orders, and items. (Depending on your point of view, it also represents
sales reps.)
Now that you know the elements of good database design, you're sure to avoid a design
such as this.
Spreadsheet Design
A spreadsheet is certainly a good tool if you use it properly and for the purpose for which
it was designed. For example, it is quite suitable for work that involves complex mathem-
atical calculations and statistical analysis. Contrary to popular myth, however, a spread-
sheet
does not
make a good relational database. If your organization has a need to collect,
store, maintain, and manipulate various types of data, then use the proper tool for the job
by designing and implementing a real database. For example, consider the spreadsheet in
