SOLUTION TO 14.31
------------------
Applying a natural join to the two tables gives us a new table with
the following schema

Order_OrderItem( O#, Odate, Cust#,Total_amount, I#, Oty_ordered,Total_price,
Discount%)

The combination of {O#,I#} is the key

The following FDs exists

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

The first relation we started with: ORDER was in 3NF.
It had no dependencies other than those defined directly from the
primary key O#.

The second relation ORDER-ITEM in fact has a dependency
I# -> Discount% that violates 2NF.

When we join a 3NF relation with a 2NF we carry over the dependencies
from both relations into the result and the result is likely
to have the lower of the normal form status of the component relations.

We can see that the newly formed relation is not in 2NF because we all
the attributes are not fully functonally dependent on the keys.
(This is due to the I# -> Discount% functional dependency).
Because it is not in 2NF, it is not in 3NF either.

=================
SOLUTION TO 14.32

Given the relation,

CAR_SALE( car#, Date_sold, Salesman #, commission%, Discount_amt)

(with primary key Car#,Salesman#)

F1: Date_sold -> Discount_amt
F2: Salesman# -> Commission%

First, is this relation in 1NF?
Looking at all the attributes, are they atomic? Yes.
So this relation is in 1NF.

2NF: By simple observation, we can see that this relation is not in 2NF. Why?
Because by definition of 2NF, every non-prime attribute is not fully
functionally dependent on the primary key.  F2 for example violates this
rule. So we decompose to make it conform.

CAR_SALE( car#, Date_sold, Salesman #, commission%, Discount_amt)
                                           ||
                                           ||
                                          \  /
CAR_SALE1( Car#, Salesman#, Date_Sold, Discount_amt)
CAR_SALE2( Salesman #, Commission%)
                         ----------
We analyze both relations for 3NF.
Since CAR_SALE2 has only one non-key attribute , it needs no further
testing.

CAR_SALE1 has the dependecy:
F1: Date_sold -> Discount_amt

This is a transitive dependeny:
Car# -> Date_sold -> Discount_amt where Discount_amt is transitively
dependent on the key Car# of this relation. So we further decompose it
into:

CAR_SALE11(Date_Sold, Discount_amt)
CAR_SALE12( Car#, Salesman#, Date_sold)
CAR_SALE2( Salesman #, commission%)
Everything is now in 3NF.
(Convince yourself that everything is in BCNF as well. The only relation
where you would apply the BCNF test is the middle one where Car#, Salesman#
is the key. Since it has no other dependency of the type Date_sold -> Car#,
there is no problem with BCNF.).
==============