DBS201 Lab 11 - More Normalization
In this lab, you will learn how to:
1. Produce the 3NF Relations from each user view into one set of 3NF Relations for the
application.
2. You will accomplish this by writing the UNF for each of 2 user views.
3. Normalize each set of relations to 3NF.
4. Merge attributes onto one relation where the PKs of two relations are identical.
5. Simplify Primary Keys. Ensure that the entire PK of multi-part PK’s is required. If not, remove
the part of the PK that is not required and add it to the non-key attribute list for that relation.
6. Merge all relations with the identical Primary Key.
7. Eliminate any new Transitive Dependancies.
8. Mark ALL Foreign Keys.
Produce a Final 3NF Solution based on the two user views given below:
07/03/2016
Page 1 of 8
DBS201 Lab 11 - More Normalization
Lab 11 Submission
NAME:
Produce the final merged 3NF relations for the following two user views:
User View #1
HEALTH HISTORY REPORT
PET ID
PET NAME
PET TYPE PET AGE OWNER
246
ROVER
DOG
12
VISIT DATE
SAM COOK JAN 13/2013
PROCEDURE
DOCTOR
01 – DOG RABIES VACCINATION
T.CANINE
07 - DE-WORMING
25 – DOG ANNUAL CHECKUP
341
342
MORRIS
SPOT
CAT
DOG
4
2
SAM COOK AUG 13/2012
02 – CAT RABIES VACCINATION
T.CANINE
JAN 13/2013
02 – CAT RABIES VACCINATION
J.KATZ
MAR 10/2013
10 - EXAMINE and TREAT WOUND
R.BYRD
05 – CAT HEART WORM TEST
J.KATZ
08 - TETANUS VACCINATION
R. BYRD
TERRY KIM JAN 21/2013
25 – DOG ANNUAL CHECKUP
MAR 10/2013
519
TWEEDY
BIRD
2
TERRY KIM FEB 26/2013
06 – DOG HEART WORM TEST
27 - ANNUAL CHECK UP
J.KATZ
12 - EYE WASH
Start with this UNF:
UNF: [ PetID, PetName, PetType, PetAge, Ownerid, Owner, ( Visit Date, (Proc#, Procedure, DocId, Doctor) ) ]
07/03/2016
Page 2 of 8
DBS201 Lab 11 - More Normalization
UNF: [ PetID, PetName, PetType, PetAge, Ownerid, Owner, ( Visit Date, (Proc#, Procedure, DocId, Doctor) ) ]
1NF: [PetID, Visit Date, Proc#, PetName, PetType, PetAge, Ownerid, Owner, Procedure, DocId, Doctor) )
With a 3-part PK, there are 7 possible tables:
There are 3 one-part PK tables and 3 two-part PK tables and 1 three-part PK table.
2NF: [PetID,
[Visit Date,
[Proc#,
[PetID, Visit Date,
[PetID, Proc#,
[Visit Date, Proc#,
[PetID, Visit Date, Proc#,
We will place all the non-key attributes on the appropriate table. We should attempt to put them on the
table with the minimal PK (the PK with the least number of parts).
2NF: (1)
[PetID, PetName, PetType, PetAge, Ownerid, Owner ]
(2)
[Visit Date ]
(3)
[Proc#, Procedure ]
(4)
[PetID, Visit Date ]
(5)
[PetID, Proc# ]
(6)
[Visit Date, Proc# ]
(7)
[PetID, Visit Date, Proc#, DocId, Doctor ]
We need to keep (1), (3), and (7). The other tables can be produced from relation (7).
2NF: (1)
[PetID, PetName, PetType, PetAge, Ownerid, Owner ]
(3)
[Proc#, Procedure ]
(7)
[PetID, Visit Date, Proc#, DocId, Doctor ]
07/03/2016
Page 3 of 8
DBS201 Lab 11 - More Normalization
3NF: Remove Transitives
(1A)
[ PetID, PetName, PetType, PetAge, Ownerid(FK), Owner ]
(8)
[ Ownerid, Owner ]
(7a)
[ PetID, Visit Date, Proc#, DocId(FK) ]
(9)
[ DocId, Doctor ]
The only relation that is a candidate for simplification is (7a) as it is a muti-part PK.
We cannot simplify (7a) because none of the part(s) of the PK determine any other part(s).
Final Answer User View 1:
(1A)
[ PetID, PetName, PetType, PetAge, Ownerid(FK), Owner ]
(8)
[ Ownerid, Owner ]
(7a)
[ PetID, Visit Date, Proc#, DocId(FK) ]
(9)
[ DocId, Doctor ]
07/03/2016
Page 4 of 8
DBS201 Lab 11 - More Normalization
User View 2
INVOICE
HILLTOP ANIMAL HOSPITAL
DATE: JAN 13/2013
INVOICE # 987
MR. RICHARD COOK
123 THIS STREET
MY CITY, ONTARIO
Z5Z 6G6
PET
DOCTOR#
ROVER
12
MORRIS
23
PROCEDURE
AMOUNT
DOG RABIES VACCINATION
30.00
DE-WORMING
59.00
DOG ANNUAL CHECKUP
45.00
CAT RABIES VACCINATION
24.00
TOTAL
TAX (13%)
AMOUNT OWING
158.00
20.54
178.54
UNF: [ Invoice#, InvDate, CustDetails, (PetId, PetName, Doctor#, Doctor, (Proc#, Procedure, A mount ) ) ]
1NF:
[Invoice#, PetId, Proc#, InvDate, CustDetails, PetName, Doctor#, Doctor, Procedure, A mount ]
07/03/2016
Page 5 of 8
DBS201 Lab 11 - More Normalization
In resolving Partial Dependencies, a 3-part PK results in 7 possible tables:
There are 3 one-part PK tables and 3 two-part PK tables and 1 three-part PK table.
2NF: [ Invoice#,
[ PetId,
[ Proc#,
[ Invoice#, PetID,
[ Invoice#, Proc#,
[ PetId, Proc#,
[ Invoice#, PetID, Proc#,
We will place all the non-key attributes on the appropriate table. We should attempt to put them on the
table with the minimal PK (the PK with the least number of parts).
2NF: (11)
[ Invoice#, InvDate, CustDetails ]
(12)
[ PetId, PetName ]
(13)
[ Proc#, Procedure]
(14)
[ Invoice#, PetID, Doctor#, Doctor]
(15)
[ Invoice#, Proc# ]
(16)
[ PetId, Proc# ]
(17)
[ Invoice#, PetID, Proc#, Amount ]
We need to keep (11), (12), (13), (14) and (17). The other tables can be produced from relation (7).
2NF: (11)
[ Invoice#, InvDate, CustDetails ]
(12)
[ PetId, PetName ]
(13)
[ Proc#, Procedure]
(14)
[ Invoice#, PetID, Doctor#, Doctor]
(17)
[ Invoice#, PetID, Proc#, Amount ]
07/03/2016
Page 6 of 8
DBS201 Lab 11 - More Normalization
3NF: Remove Transitive Depoendencies and explode Cust Details
(11a) [ Invoice#, InvDate, Cust#(FK) ]
(12)
[ PetId, PetName ]
(13)
[ Proc#, Procedure]
(14a) [ Invoice#, PetID, Doctor(FK)]
(17)
[ Invoice#, PetID, Proc#, Amount ]
(18)
[ Doctor#, Doctor ]
(19)
[ Cust#, Cname, Cstreet, Ccity, Cprov, CpostalCode ]
The only relations that are candidates for simplification are (14a) and (17) as they have a muti-part PK.
We cannot simplify (14a) because neither of the PK attributes determines the other PK attribute.
We cannot simplify (17) because none of the part(s) of the PK determine any other part(s).
Final Answer User View 2:
(11a)
(12)
(13)
(14a)
(17)
[ Invoice#, InvDate, Cust#(FK) ]
[ PetId, PetName ]
[ Proc#, Procedure]
[ Invoice#, PetID, Doctor(FK)]
[ Invoice#, PetID, Proc#, Amount ]
(18)
(19)
[ Doctor#, Doctor ]
[ Cust#, Cname, Cstreet, Ccity, Cprov, CpostalCode ]
Note: The Customer Number is the same as the OwnerId so we don’t need table (8)
Final Answer User View 1:
(1A) [ PetID, PetName, PetType, PetAge, Ownerid(FK), Owner ]
(8)
[ Ownerid, Owner ]
(7A) [ PetID, Visit Date, Proc#, DocId(FK) ]
(9)
[ DocId, Doctor ]
07/03/2016
Page 7 of 8
DBS201 Lab 11 - More Normalization
Now we can merge relations from User View 1 and User View 2 that have the identcal Primary Key.
Final Answer User View 2:
INVOICE (11a)
PET (12)+(1A)
PROCEDURE (13)
INVOICE-PET(14a)
[ Invoice#, InvDate, Cust#(FK) ]
[ PetID, PetName, PetType, PetAge, Cust#(FK) ]
[ Proc#, Procedure]
[ Invoice#, PetID, Doctor(FK)]
INVOICE-PET-PROCEDURE (17) [ Invoice#, PetID, Proc#, Amount ]
DOCTOR (9) + (18) [ Doctor#, Doctor ]
CUSTOMER(19)
[ Cust#, Cname, Cstreet, Ccity, Cprov, CpostalCode ]
Wecan eliminate (7A) because the information it gives us is obtainable from:
INVOICE-PET-PROCEDURE and INVOICE-PET
Final Answer User View 1:
(1A) [ PetID, PetName, PetType, PetAge, Cust#(FK) ]
(8)
[ Ownerid, Owner ]
(7a) [ PetID, Visit Date, Proc#, DocId(FK) ]
(9)
[ DocId, Doctor ]
There are no new transitive dependencies.
Complete Final Answer sorted by table name:
(30)
CUSTOMER
[ Cust#, Cname, Cstreet, Ccity, Cprov, CpostalCode ]
(31)
DOCTOR
(32)
INVOICE
(33)
(34)
(35)
(36)
INVOICE-PET
INV-PET-PROC
PET
PROCEDURE
[ DocId, Doctor ]
[ Invoice#, InvDate, Cust#(FK) ]
[ Invoice#, PetID, Doctor(FK)]
[ Invoice#, PetID, Proc#, Amount ]
[ PetID, PetName, PetType, PetAge, Cust#(FK) ]
[ Proc#, Procedure]
07/03/2016
Page 8 of 8