T (j, k, l, m, n, o)

Primary Key: j, k

FD1: j, k  l, m, n, o

FD2: k  l, m

FD3: n  o

I) The Primary key: (j, k) 

k  (l, m)
It is a 2NF violation. PF dependency violates 2NF, so the given relation is 1NF
confirmed.

II) Remove the PF dependency to get 2NF. Close the dependency and form a new
relationship. Separate the primary key and other attributes in separate relation
k  l, m
kTk, l, m
T (j, k, l, m, n, o)

R1: (k, l, m) R2: (j, k, n, o)

R1: 3NF
k (l, m)

R2: not 3NF

j, k (n, o)
no

III) R2: (j, k, n, o)

j, k  n, o
n  o (not 3NF due to transitive dependency)

R2 (j, k, n, o)

R3: (n, o) R4: (j, k, n)

no j, k  n
 IV) R1: (k, l, m)
k  (l, m)
R3: (n, o)
no
R4: (j, k, n)
j, k  n

These relations check out in 3NF, and key  non-key

2)

1NF
All attributes are atomic and independent of composite primary-keys.
Crops (CropID, Owner, Street, City, State, ZipCode, FertID, Fertilizer, Amount)
Composite Primary Key: (CropID, FertID)

Functional dependencies:
CropID  Owner, Street, City, State, ZipCode
CropID  FertID  Amount
FertID  Fertilizer

2NF
It has no partial dependencies. It happens when some attributes are not fully functionally
dependent on the primary-key.
Partial:
CropID  Owner, Street, City, State, ZipCode
FertID  Fertilizer
3NF
There is no transitive dependency here. It occurs when some attributes rely on non-primary
keys.
Transitive:
City  ZipCode
(multi-valued)

TABLES
 Italicized = foreign-keys
 Underlined = primary-keys

2NF:
CROP (CropID, Owner, Street, City, State, ZipCode)
FERTILIZER (FertID, Fertilizer)
CROP_AMOUNT (CropID, FertID, Amount)

3NF:
CROP (CropID, Owner, Street, City, State)
FERTILIZER (FertID, Fertilizer)
CROP_AMOUNT (CropID, FertID, Amount)
ADDRESS (City, ZipCode)