Name – Yashraj Kunwar

Student number – 3125511

Course – ACS-3902-003

Assignment no 7
Exercise 7.1

Consider the following relations for an order-processing application database at ABC, Inc.

ORDER (O#, Odate, Cust#, Total_amount)

ORDER-ITEM (O#, I#, Qty_ordered, Total_price, Discount%)

Assume that each item has a different discount. The Total_price refers to one item, Odate is

the date on which the order was placed, and the Total_amount is the amount of the order. If

we apply a natural join on the relations Order-Item and Order in this database, what does the

resulting relation schema look like? What will be its key? Show the FDs in this resulting

relation. Is it in 2NF? Is it in 3NF? Why or why not? (State any assumptions you make.)

Ans: After applying a natural join on Order-Item and Order will look like:

ORDER_JOIN (O#, Odate, Cust#, Total_amount, I#, Qty_ordered, Total_price, Discount%)

The key of this resulting relation will be the combination of the O# and I# attributes.

The functional dependencies (FDs) in this resulting relation are:

O# -> Odate, Cust#, Total_amount

I# -> Qty_ordered, Total_price, Discount%

O#, I# -> Odate, Cust#, Total_amount, Qty_ordered, Total_price, Discount%

In the ORDER_JOIN relation, we can see that the order date, customer number, and total

amount are dependent only on the order number (O#), and not on the item number (I#). This

is called a partial dependency and means that the relation is not in second normal form (2NF).
To fix this, we can split the relation into two separate relations, one for ORDER and one for

ORDER-ITEM.

After splitting the relation, we find that both the ORDER and ORDER-ITEM relations are in

third normal form (3NF) because they do not have any transitive dependencies. This means

that the resulting schema is optimized for the order-processing application database at ABC,

Inc.

Exercise 7.2

Consider the following relation:

CAR_SALE(Car#, Date_sold, Salesman#, Commision%, Discount_amt)

Assume that a car may be sold by multiple salesmen and hence {CAR#, SALESMAN#} is the

primary key. Additional dependencies are:

Date_sold --> Discount_amt

and

Salesman# --> commission%

Based on the given primary key, is this relation in 1NF, 2NF, or 3NF? Why or why not? How

would you successively normalize it completely?

Ans: We have a table named CAR_SALE with information on car sales. The table contains

attributes like Car#, Date_sold, Salesman#, Commission%, and Discount_amt. The primary

key of this table is {CAR#, SALESMAN#}.

However, there is a problem with this table because some attributes depend on only one part

of the primary key. To fix this, we need to divide the table into two tables. The first table will
have {Car#, Salesman#, Commission%}, and the second table will have Date_sold, Car#, and

Discount_amt. Both of these tables will be in 2NF because there are no partial dependencies.

But the first table still has a transitive dependency, so we need to split it again into two tables.

The first table will have {Car#, Salesman#, Commission%}, and the second table will have

Salesman# and Salesman_name. This way, we can normalize the table to 3NF. In summary,

we fixed the issues with the initial table by dividing it into separate tables and removing

dependencies, resulting in a 3NF table structure.

Exercise 7.3

Consider the following relation:

R (Doctor#, Patient#, Date, Diagnosis, Treat_code, Charge)

In this relation, a tuple describes a visit of a patient to a doctor along with a treatment code

and daily charge. Assume that diagnosis is determined (uniquely) for each patient by a

doctor. Assume that each treatment code has a fixed charge (regardless of patient). Is this

relation in 2NF? Justify your answer and decompose if necessary. Then argue whether

further normalization to 3NF is necessary, and if so, perform it.

Ans: The given relation R describes the visits of patients to doctors along with the diagnosis,

treatment codes, and charges for each visit. We assume that a doctor determines a unique

diagnosis for each patient and that each treatment code has a fixed charge for all patients.

To check whether this relation is in second normal form (2NF), we need to check if there are

any partial dependencies. In other words, we need to see if any non-key attributes depend on

only part of the primary key. In this relation, the Diagnosis attribute depends only on the

Doctor# and Patient# attributes, which are part of the primary key. Therefore, the relation is

not in 2NF.To fix this issue, we can decompose the relation into two relations. The first
relation would have the primary key {Doctor#, Patient#} and the Diagnosis attribute, and the

second relation would have the primary key {Treat_code} and the Charge attribute. Eg :-

R1(Doctor#, Patient#, Date, Diagnosis, Treat_code) and R2(Treat_code, Charge)

The resulting relations are now in 2NF. However, there is still a transitive dependency

between Diagnosis and Doctor# in R1. To fix this, we need to split R1 into two different

relations again. The first one, called R3, will have attributes Doctor# and Diagnosis, and the

primary key will be {Doctor#}. The second one, called R4, will have attributes Doctor#,

Patient#, and Date, and the primary key will be {Doctor#, Patient#, Date}.

Now, all relations are in the third normal form (3NF), and there are no more dependencies.

Therefore, the final normalized schema is R2(Treat_code, Charge), R3(Doctor#, Diagnosis),

and R4(Doctor#, Patient#, Date).