When designing a relational database, it is normally a good thing to
"normalize" the database. There are different degrees of normalization, but
in general, relational databases should be normalized to the "third normal
form". Simply put, this means that the attributes in each table should
"depend on the key, the whole key and nothing but the key".
An example of a de-normalized database table is provided below. The
database designer has assumed that there will never be a need to have more
than two order items in any one order:
By moving repeating groups of attributes to a separate database table,
the database design becomes more flexible. A single order can now support
any number of order items; not just just two. The primary key (PK) of the
Order Item table is the "Order Nbr" (represented by the relationship) plus
the "Order Item Nbr":
The "Order Item Description" field is dependent on the "Order Item Code";
not the unique identifier of the Order Item Table (i.e. "Order Nbr" + "Order
Item Nbr"). By creating a classification table, the database become even
more flexible. New codes can easily be added. The "Order Item Description"
for a given code can easily be altered should the need ever arise (e.g.
"blue widget" => "light blue widget"):
A RDBMS alone will not solve all data management issues. A good data
analyst and/or database analyst is needed to design a flexible and efficient
relational database.
| 
