Database Reference
In-Depth Information
What about the other columns? It turns out that if we know the value of SKU, we also
know the values of all of the other columns. In other words:
SKU S SKU_Description
because a given value of SKU will have just one value of SKU_Description. Next,
SKU S Department
because a given value of SKU will have just one value of Department. And, finally,
SKU S Buyer
because a given value of SKU will have just one value of Buyer.
We can combine these three statements as:
SKU S (SKU_Description, Department, Buyer)
For the same reasons, SKU_Description determines all of the other columns, and we can write:
SKU_Description S (SKU, Department, Buyer)
In summary, the functional dependencies in the SKU_DATA table are:
SKU S (SKU_Description, Department, Buyer)
SKU_Description S (SKU, Department, Buyer)
Buyer S Department
By The WAy You cannot always determine functional dependencies from sample data.
You may not have any sample data, or you may have just a few rows that
are not representative of all of the data conditions. In such cases, you must ask the users
who are experts in the application that creates the data. For the SKU_DATA table, you
would ask questions such as, “Is a Buyer always associated with the same Department?”
and “Can a Department have more than one Buyer?” In most cases, answers to such
questions are more reliable than sample data. When in doubt, trust the users.
Functional Dependencies in the ORDeR_ITeM Table
Now consider the ORDER_ITEM table in Figure 3-1. For convenience, here is a copy of the data
in that table:
What are the functional dependencies in this table? Start on the left. Does OrderNumber
determine another column? It does not determine SKU because several SKUs are
 
 
Search WWH ::




Custom Search