Music Store Database – Normalization
1. Employee table: The first table in our database is the Employee table. The attributes for the
table are EmpId, EmpName, EmpPay, and Position. Example values for those attributes are
111222333, John Richards, 7.50, and Manager respectively. The key is EmpId.
ICS:
1. Any manager must make more than employees with positions that aren’t manager.
2. All pay rates for employees must exceed or equal the minimum wage of 7.50.
3. EmpId cannot be null.
4. There cannot exceed two managers on staff at a time.
5. All employees in the same position receive the same pay.
Normalization:
We can deduce that the table must be in the 1st Normal Form as it is a RDB. It is also in
the second normal form as the functional dependencies do not contain subsets of key in
the left side of the implications.
FDS
{EmpId}  {EmpName, EmpPay, Position}
{Position}  {EmpPay}
It is not in BCNF because the 2nd FD does not contain a superkey on the left.
Correction: To right this wrong we removed the EmpPay attribute from the table and
created a new table PayRate with Position and EmpPay attributes. Position is a foreign
reference to Employee.Position. The decomposition was lossless and the tables
normalized. Using the decomp method in class it can be seen that we needed two
decomposed tables:
S = {EmpId, EmpName, EmpPay, Position}
S1 = {Position, EmpPay}
{Position}  {EmpPay}
S2 = {EmpId, EmpName, Position}
{EmpId }  {EmpName, Position}
-Nothing was added and the decomposition was lossless.
Tables:
+-----------+-----------------+--------------+
| EmpId
| EmpName
| Position
|
+-----------+-----------------+--------------+
| 111222333 | Jacob Ryder
| Cashier
|
| 222333666 | Malcom Smith | Manager
|
| 111444777 | Harry Larson | Head Cashier |
| 111333555 | Coleman Frasier | Cashier
|
| 111444333 | Mary Emerson | Clerk
|
| 111333888 | Brain Masterson | Clerk
|
| 222111999 | Cole Reid
| Clerk
|
| 222333111 | Mariah McDonald | Cashier
|
| 111999553 | Melissa Oconner | Reciever
|
+-----------+-----------------+--------------+
+--------------+--------+
| Position
| EmpPay |
+--------------+--------+
| Manager
| Cashier
| Clerk
| 12.50 |
| 7.50 |
| 8.00 |
| Head Cashier | 8.50 |
| Reciever
| 8.00 |
+--------------+--------+
2. Inventory: The 2nd table in our database is Inventory. It contains ProductId, ProductName, Price,
Quantity, Genre, and Artist attributes. The key is ProductId.
ICS:
1. Quantity for any product must be >= 0.
2. ProductId cannot be null.
Normalization: The table is in the 1st Normal Form and the 2nd Normal Form because the left
sides of the FDs are not subsets of the key. It is also in
FDs
{ProductId}  {ProductName, Price, Quantity, Genre, Artist}
{Artist}  {Genre} --This is accidental and does not satisfy any IC. It is not a real FD.
Corrections: It is in BCNF because Product Id is a superkey. There are a bunch of attributes for
this one table and some might not seem related. It is possible that I could create a table for
album where Inventory references that table and only contains ProductId and Quantity but it is
not necessary.
3. Customer Table: The 3rd table in our database is the customer table. It contains CustId,
CustName, and Phone attributes. The key is CustId.
ICS:
1. CustId not null;
Normalization: The table is in the 1st and 2nd Normal Forms because it is an RDB and the left
sides of the FDS do not contain subsets of the key.
FDs
{CustId}  {CustName, Phone}
Corrections: The table is in BCNF because CustId is a superkey. No changes necessary.
4. Sales Table: The 4th table in our database is the Sales table which contains the CustId,
ProductId, Quantity, and Date attributes. The key is {CustId, ProductId, Date}.
ICS:
1.CustId, ProductId, and Date cannot be null.
2. CustId references CustId in the Customer table. (must exist in that table.)
3.ProductId references ProductId in the Inventory table. (must be in that table.)
4. The quantity purchased <= the quantity available in inventory.
Normalization: The table is in the 1st and 2nd Normal Forms because it is an RDB and the left
side of the FD implication is not a subset of the key.
FDs
{CustId, ProductId, Date}  {CustId, ProductId, Date, Quantity}.
Corrections: It would seem that this satisfies the BCNF because the left side is a superkey
but we made an error in creating the key for the table. If a situation occurred where a
customer bought a cd one day and then returned the same day and bought another copy of
the same cd, then there would be duplicate entries in the table. Changing the key to include
Quantity would not fix the problem. To fix the problem we had to add an attribute OrderId
so that each purchase would receive it’s own unique value. Then that value becomes the
key. The table is then normalized.
The new FD is : {OrderId}  {CustId, ProductId, Date, Quantity}.
+--------+-----------+----------+------------+---------+
| CustId | ProductId | Quantity | Date
| OrderId |
+--------+-----------+----------+------------+---------+
| 111111 | 111222333 |
1 | 10/25/2011 | 111111 |
| 211111 | 111222333 |
1 | 10/29/2011 | 111112 |
| 211111 | 222333555 |
2 | 10/29/2011 | 111113 |
| 211111 | 444333777 |
1 | 10/29/2011 | 111114 |
| 333111 | 111111666 |
1 | 10/18/2011 | 111115 |
| 333111 | 111111888 |
1 | 10/18/2011 | 111116 |
| 333666 | 111111555 |
1 | 10/22/2011 | 111117 |
| 222999 | 111111555 |
1 | 10/31/2011 | 111118 |
| 222999 | 666777999 |
1 | 10/31/2011 | 111119 |
| 222222 | 333666888 |
1 | 10/27/2011 | 111120 |
| 333555 | 111111777 |
1 | 10/27/2011 | 111121 |
| 333555 | 111111999 |
1 | 10/26/2011 | 111122 |
+--------+-----------+----------+------------+---------+
5. Returns Table: The 5th table in our database is the returns table. It contains CustId,
ProductId, and Date attributes. The key is the entire set of attributes.
ICS:
1. CustomerId, ProductId, and Date are not null.
2. CustId references the Sales table. (It must exist in sales table)
3. ProductId references the Sales table. (It must exist in the sales table)
Normalization: The table is in 1st and 2nd Normal Forms.
FDs
{CustomerId, ProductId, Date}  {CustomerId, ProductId, Date}
Corrections: The table has the same issue that the sales table did. To fix this issue we added
the OrderId attribute to reference the one in Sales. OrderId becomes the key. Then it is in
BCNF because OrderId is a superkey.
So {OrderId}  {CustId, ProductId, Date}.
+--------+-----------+-----------+---------+
| CustId | ProductId | Date | OrderId |
+--------+-----------+-----------+---------+
| 211111 | 111222333 | 11/2/2011 | 111112 |
| 333111 | 111111888 | 11/1/2011 | 111116 |
| 333555 | 111111999 | 11/3/2011 | 111122 |
| 222999 | 666777999 | 11/5/2011 | 111119 |
+--------+-----------+-----------+---------+