Database

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.