TAL Distributors Chapter 5

The following exercises are based on the TAL Distributors database shown in Figure 5-1.

1. Using your knowledge of TAL Distributors, determine the functional dependencies that exist
in the following table. After determining the functional dependencies, convert this table to an
equivalent collection of tables that are in third normal form.
Item (ItemNum, Description, OnHand, Category, Price, (OrderNum,
OrderDate, CustomerNum, CustomerName, RepNum, LastName,
FirstName, NumOrdered, QuotedPrice))

Step-1: Breaking the group of Columns to create 1st normalization form.

Item (ItemNum , Description, OnHand, Category, Price, OrderNum, OrderDate, CustomerNum,
CustomerName, RepNum, LastName, FirstName, NumOrdered, QuotedPrice)

Step-2: Converting into the 2nd normalization form.

Identifying the primary keys for each subset;
(ItemNum,
(OrderNum,
(CustomerNum,
(RepNum,
Regrouping the Columns as per dependencies;
(ItemNum , Description, Category, OnHand, Price)
(OrderNum , OrderDate, CustomerNum, CustomerName, RepNum, NumOrdered, QuotedPrice)
(CustomerNum , CustomerName)
(RepNum , LastName, FirstName)
Assigning the names for the newly assigned tables;
Item (ItemNum , Description, Category, OnHand, Price)
Orders (OrderNum , OrderDate, CustomerNum, CustomerName, RepNum, NumOrdered,
QuotedPrice)
Customer (CustomerNum, CustomerName)
Rep (RepNum , LastName, FirstName)

Step3: Converting to the 3rd normalization form and creating a new table called Orderline with
the dependent rows: (OrderNum , ItemNum , NumOrdered, QuotedPrice). So the final content
would be;
Orderline (OrderNum , ItemNum , NumOrdered, QuotedPrice)
Step 4: Naming these tables and put the entire collection together, giving the following: Item
(ItemNum , Description, Category, OnHand, Price)
Orders (OrderNum QuotedPrice)
Customer (CustomerNum , CustomerName) Rep (RepNum , LastName, FirstName)

2. List the functional dependencies in the following table that concern invoicing (an application
TAL Distributors is considering adding to its database), subject to the specified conditions. For a
given invoice (identified by the Invoice-Num), there will be a single customer. The customer’s
number, name, and complete address appear on the invoice,
as does the date. Also, there may be several different items appearing on the invoice. For each
item that appears, display the item number, description, price, and number shipped. Each
customer that orders a particular item pays the same price. Convert this table to an equivalent
collection of tables that are in third normal form.
Invoice (InvoiceNum, CustomerNum, LastName, FirstName, Street, City,
State, PostalCode, Date, (ItemNum, Description, Price, NumShipped))

Invoice
InvoiceNum – CustomerNum, Date
CustomerNum- LastName, FirstName, street, city, state, postalcode
ItemNum- descripTon, Price
InvoiceNum, ItemNum – NumShipped
Invoice (InvoiceNum , CustomerNum, Date)
FK- CustomerNum customers
Customers (CustomerNum , LastName, FirstName, street, city, state, postalcode)
FK- none
Items (ItemNum , descripTon, Price)
FK- none
Shipped (InvoiceNum , ItemNum , NumShipped)
FK- InvoiceNum Invoice , ItemNum Items
3. The requirements for TAL Distributors have changed. A number and a name now identify
each storehouse. Units of each item may be stored in multiple storehouses, and it is important to
know precisely how many items are stored in each storehouse. In addition, TAL Distributors
now wants to manage information about the suppliers from which it purchases items. For each
item, TAL Distributors needs to know the number and name of each supplier as well as the
expected lead time for delivering each item. (Lead time is the amount of time a supplier is
expected to take to deliver the item after TAL Distributors has ordered it.) Each item can have
many suppliers, and each supplier can supply many items. Using this information, convert the
following unnormalized relation to fourth normal form:
Item (ItemNum, Description, Category, Price, (StorehouseNum, StorehouseName,
OnHand), (SupplierNum, SupplierName, LeadTime))

Fourth Normal Form:

Item (ItemNum, Description, Category, Price)
StoreHouse (StoreHouse, StoreHouse Name, OnHand)
Supplier (SupplierName, Lead Time)

4. What changes would you need to make to the normalized tables in Exercise 3 to support the
following additional requirements:

1. Item (ItemNum, Description, Category Price)

2. StoreHouse (StoreHouse Num, StoreHouseName, ItemNum, OnHand)
3. Supplier (SupplierNum, SupplierName, LeadTime)
4. Supplieritem (SupplierNum, ItemNum)

a. TAL needs to keep track of the price a supplier charges for an item. Different suppliers can
charge different prices for the same item.

A supplier can charge different price for an item and keeps track of its charged price. To fulfill
this criteria, there would be a charge in the relation SupplierItem like this:
SupplierItem (SupplierItem, ItemNum, Price)

b. Each storehouse has a manager who is identified by a manager number, a manager last name,
and a manager first name.

There is a manager for each store house and also the number, last name and first name of the
managers are to be kept. The New relation for the StoreHouse would be:
StoreHouse (StoreHouseNum, StoreHouseName, ItemNum, OnHand, ManagerNum, LastName,
FirstName)

The above relation show that there is a composite key or group of two attributes. The composite
key are StoreHouseNum and ManagerNum.
5. TAL Distributors is considering changing its business model so that many sales reps can
represent one customer and one sales rep can represent many customers. Using this information,
convert the following unnormalized relation to fourth normal form.
Customer (CustomerNum, CustomerName, Street, City, State, PostalCode,
Balance, CreditLimit, (RepNum, LastName, FirstName, Street, City,
State, PostalCode, Commission, Rate))

Consider the given table. There exists following dependencies in the table:
1. CustomerNum – CustomerName, Street, City, State, PostalCode, Balance, CreditLimit
2. RepNum – LastName, FirstName, Street, City, State, PostalCode, Commission, Rate

The table is said to be in fourth normal form, it is in first, second and third normal form and the
table must not have any multivalued dependencies. So that the table should be decomposed into
various tables and all the tables must be related in the right manner.

Step 1:
The table must not have group values in any attribute for one value of the primary key. So the
candidate key must be defined as the primary key. The primary key is now the group of the
keys: CustomerNum and RepNum.

Step2:
The relation which is the first normal form can still have a problem of update anomaly that is
there could be repeating values, which waste space and causes problems at the time of updating.
So the relation must have all non-key attributes dependent only on key attribute(s). Therefore,
divide a relation into two relations named Customer and Rep to be in Second Normal form.

This would be the structure:

1. Customer (CustomerNum, CustonerName, Street, City, State, PostalCode, Balance,
CreditLimit, RepNum, Commission, Rate)
2. Rep (RepNum, LastName, FirstName, Street, City, State, Postalcode)

Step 3:
The relation which is in second normal form can still have a problem of repetition of values due
to combinational primary key. It is possible for the relation Customer to have many of the same
values of RepNum, Commission, Rate.

The tables after decomposition which show the relations as well are as follows:
1. Customer (CustomerNum, CustomerName, Street, City, State, PostalCode, Balance,
CreditLimit)
2. Rep (RepNum, LastName, FirstName, Street, City, State, PostalCode, Commission, Rate)

Now there are not functional dependencies that each non-key attribute of the table is dependent
on only the key attribute. So each table is in third normal form.
Requirements:
1. A sales representative can represent many customers and many sales representatives can
represent one customer so if the relation would be designed as follows:

A. Customer (CustomerNum, CustomerName, Street, City State, PostalCode, Commission, Rate,

CreditLimit, RepNum)
B. Rep (RepNum, LastName, FirsttName, Street, City, State, PostalCode, Commission, Rate,
CustomerNum)

Step 4:
There would be multivalued dependencies because for a CustomerNum, there would be various
RepNum and for a RepNum, there would be various CustomerNum.

So there must be another relation such as:

CustomerRep (CustomerNum, RepNum)

Step 5:
Now the structure of the relations, which is in fourth normal form, would be:
1. Customer (CustomerNum, CustomerName, Street, City, State, PostalCode, Balance,
CreditLimit, RepNum)
2. CustomerRep (CustomrNum, RepNum)

6. Convert the following unnormalized relation to fourth normal form using the same
requirements as in Question 5 (many sales reps can represent one customer and one sales rep can
represent many customers).
Rep (RepNum, LastName, FirstName, Street, City, State, PostalCode,
Commission, Rate, (CustomerNum, CustomerName, Street, City,
State, PostalCode, Balance, CreditLimit))

Consider the given table. There exists following dependencies in the table:
1. CustomerNum – CustomerName, Street, City, State, PostalCode, Balance, CreditLimit
2. RepNum – LastName, FirstName, Street, City, State, PostalCode, Commission, Rate

The table is said to be in fourth normal form, it is in first, second and third normal form and the
table must not have any multivalued dependencies. So that the table should be decomposed into
various tables and all the tables must be related in the right manner.

Step 1:
The table must not have group values in any attribute for one value of the primary key. So the
candidate key must be defined as the primary key. The primary key is now the group of the
keys: CustomerNum and RepNum.

Step2:
The relation which is the first normal form can still have a problem of update anomaly that is
there could be repeating values, which waste space and causes problems at the time of updating.
So the relation must have all non-key attributes dependent only on key attribute(s). Therefore,
divide a relation into two relations named Customer and Rep to be in Second Normal form.

This would be the structure:

1. Rep (RepNum, LastName, FirstName, Street, City, State, Postalcode)
2. Customer (CustomerNum, CustonerName, Street, City, State, PostalCode, Balance,
CreditLimit, RepNum, Commission, Rate)
Step 3:
The relation which is in second normal form can still have a problem of repetition of values due
to combinational primary key. It is possible for the relation Customer to have many of the same
values of RepNum, Commission, Rate.

The tables after decomposition which show the relations as well are as follows:
1. Rep (RepNum, LastName, FirstName, Street, City, State, PostalCode, Commission, Rate)
2. Customer (CustomerNum, CustomerName, Street, City, State, PostalCode, Balance,
CreditLimit)
Now there are not functional dependencies that each non-key attribute of the table is dependent
on only the key attribute. So each table is in third normal form.

Requirements:
1. A sales representative can represent many customers and many sales representatives can
represent one customer so if the relation would be designed as follows:

A. Rep (RepNum, LastName, FirsttName, Street, City, State, PostalCode, Commission, Rate,
CustomerNum)
B. Customer (CustomerNum, CustomerName, Street, City State, PostalCode, Commission, Rate,
CreditLimit, RepNum)

Step 4:
There would be multivalued dependencies because for a CustomerNum, there would be various
RepNum and for a RepNum, there would be various CustomerNum.

So there must be another relation such as:

CustomerRep (CustomerNum, RepNum)

Step 5:
Now the structure of the relations, which is in fourth normal form, would be:
1. Customer (CustomerNum, CustomerName, Street, City, State, PostalCode, Balance,
CreditLimit, RepNum)
2. CustomerRep (CustomrNum, RepNum)
7. Is there any difference between the tables you created in Questions 5 and 6? Why or why not?

There is not difference between the tables which are created in question 5 and 6.

Here are the reasons why:

Reason 1:
In the first situation, there would have been various different representative details for a single
customer. Therefore, the multivalued dependency would be there.

Reason 2:
In the second situation, there would have been various different customer details for a single
representative hence again the multivalued dependency would be there.

When there is “many to many” relationship between two entities then the solution is one that is
creating another relation which would contain primary keys of both the relation as foreign keys.

So, in both of the above cases, the solution would be one:

 First decompose the relation in two different relations for keeping a single attribute as
determinant in each table.
 Then create another relation for storing only foreign keys for keeping the relationship
records customer and representatives hence there would not be any multivalued
dependency in any relation.