PHP and MySQL Web Development 4th Ed-tqw-_darksiderg

Designing Your Web Database
213
OrderID
Amount
Date
CustomerID
Name
Address
City
12
199.50
25-Apr-2007
1
Julie Smith
25 Oak Street
Airport West
13
43.00
29-Apr-2007
1
Julie Smith
25 Oak Street
Airport West
14
15.99
30-Apr-2007
1
Julie Smith
25 Oak Street
Airport West
15
23.75
01-May-2007
1
Julie Smith
25 Oak Street
Airport West
Figure 8.4
A database design that stores redundant data takes up extra space
and can cause anomalies in the data.
Such a design creates two basic problems:
n It’s a waste of space.Why store Julie’s details three times if you need to store them
only once?
n It can lead to update anomalies—that is, situations in which you change the database
and end up with inconsistent data.The integrity of the data is violated, and you no
longer know which data is correct and which is incorrect.This scenario generally
leads to losing information.
Three kinds of update anomalies need to be avoided: modification, insertion, and deletion
anomalies.
If Julie moves to a new house while she has pending orders, you will need to update
her address in three places instead of one, doing three times as much work.You might
easily overlook this fact and change her address in only one place, leading to inconsistent
data in the database (a very bad thing).These problems are called modification anomalies
because they occur when you are trying to modify the database.
With this design, you need to insert Julie’s details every time you take an order, so
each time you must make sure that her details are consistent with the existing rows in
the table. If you don’t check, you might end up with two rows of conflicting information
about Julie. For example, one row might indicate that Julie lives in Airport West, and
another might indicate she lives in Airport.This scenario is called an insertion anomaly
because it occurs when data is being inserted.
The third kind of anomaly is called a deletion anomaly because it occurs (surprise, surprise)
when you are deleting rows from the database. For example, imagine that after an
order has been shipped, you delete it from the database. After all Julie’s current orders
have been filled, they are all deleted from the Orders table.This means that you no
longer have a record of Julie’s address.You can’t send her any special offers, and the next
time she wants to order something from Book-O-Rama, you have to get her details all
over again.
Generally, you should design your database so that none of these anomalies occur.