CS 3630 Database Design and Implementation
Assignment 6-1 2. staffNo dentistName patNo patName staffNo, Date, Time All patNo, Date, Time All surgeryNo, Date, Time All staffNo, Date surgeryNo 3. staffNo, Date, Time (any one of the three ALL FDs) 4. patNo, Date, Time surgeryNo, Date, Time
First Normal Form (1NF) No multi-value attributes Done when mapping E-R model to relational schema DBDL
Second Normal Form (2NF) A relation R is in 1NF, and every non-primary-key attribute is fully functionally dependent on the primary key Then R is in 2NF No Partial FDs on the PK.
Third Normal Form (3NF) No Transitive FDs on PK. Relation R in 2NF, and No non-Primary-Key attribute is transitively functionally dependent on the primary key Then R is in 3NF. No Transitive FDs on PK.
Boyce-Codd Normal Form (BCNF) Definition R in 1NF and The determinant of each FD is a candidate key. Review: 1NF determinant candidate key
BCNF is stronger than 3NF BCNF and 3NF BCNF is stronger than 3NF If R in BCNF, then R in 3NF. If R not in 3NF, then R not in BCNF.
Proof If R not in 3NF, then PK B, and B C, (PK C) NO cycle for transitive FD B PK : False B is not a candidate key but a determinant (B C ) So, R is not in BCNF.
Example Lease (RNo, RName, PNo, PAddress, Start, Finish, Rent, ONo, OName) Primary Key: PNo, Start Alternate Key: PNo, Finish PAddress, Start PAddress, Finish FDs: PNo, Start All other attributes PNo, Finish All other attributes PAddress, Start All other attributes PAddress, Finish All other attributes PNo PAddress, ONo, OName (Pno not a candidate key) PAddress PNo, ONo, Oname (Paddress not a candidate key) RNo Rname (Rno not a candidate key) ONo OName (Ono not a candidate key) Not in BCNF. How many tables in order to make it BCNF?
Decompose Lease into BCNF Lease (RNo, RName, PNo, PAddress, Start, Finish, Rent, ONo, OName) PNo PAddress, ONo, OName (Pno not a candidate key) PAddress PNo, ONo, Oname (Paddress not a candidate key) RNo Rname (Rno not a candidate key) ONo OName (Ono not a candidate key) Property (PNo, PAddress, Ono, Oname) PNo PAddress, Ono, Oname PAddress PNo, Ono, Oname The Same Table!
Decompose Lease into BCNF Lease (RNo, RName, PNo, PAddress, Start, Finish, Rent, ONo, OName) PNo PAddress, ONo, OName (Pno not a candidate key) (PAddress PNo, ONo, Oname (Paddress not a candidate key) ) RNo Rname (Rno not a candidate key) ONo OName (Ono not a candidate key) Property (PNo, PAddress, Ono, Oname) PNo PAddress, Ono, Oname PAddress PNo, ONo, Oname (Ono Oname) Renter (Rno, Rname) Rno Rname Lease (RNo, PNo, Start, Finish, Rent) PNo, Start All PNo, Finish All
Decompose Lease into BCNF Lease (RNo, RName, PNo, PAddress, Start, Finish, Rent, ONo, OName) Property (PNo, PAddress, Ono, Oname) PNo PAddress, Ono, Oname Ono Oname BCNF? Renter (Rno, Rname) Rno Rname Lease (RNo, PNo, Start, Finish, Rent) PNo, Start All PNo, Finish All
Decompose Lease into BCNF Lease (RNo, RName, PNo, PAddress, Start, Finish, Rent, ONo, OName) Property (PNo, PAddress, Ono, Oname) PNo PAddress, Ono, Oname PAddress PNo, Ono, Oname Ono Oname (determinant is not a candidate key) Property (PNo, PAddress, Ono) PNo PAddress, Ono PAddress PNo, Ono Owner (Onp, Oname) Ono Oname
Decompose Lease into BCNF Lease (RNo, RName, PNo, PAddress, Start, Finish, Rent, ONo, OName) PNo PAddress, ONo, OName (Pno not a candidate key) PAddress PNo, ONo, Oname (Paddress not a candidate key) RNo Rname (Rno not a candidate key) ONo OName (Ono not a candidate key) Property (PNo, PAddress, ONo) PNo PAddress, ONo PAddress PNo, Ono Renter (RNo, RName) RNo RName Owner (ONo, OName) ONo Oname Only 4 tables, not 5. Ono will not be in Lease. Pno Ono Lease (RNo, PNo, Start, Finish, Rent) PNo, Start All PNo, Finish All
Example R (A, B, C, D, E, F) PK: A, B, C AK: B, C, D FK: None FDs: A, B, C All B, C, D All B, D A A: staffNo B, C: Date, Time D: surgeryNo
Table Instance A B C D E F 2 10 x u ct 1 1 20 y v cis 2 2 10 z u se 3 1 20 x v cs 4 FDs: A, B, C All B, C, D All B, D A A: staffNo B, C: Date, Time D: surgeryNo
Decomposing to BCNF R (A, B, C, D, E, F) PK: A, B, C AK: B, C, D FK: None FDs: A, B, C All B, C, D All B, D A B, D and A should be in a new table with (B, D) as PK B and D should remain in the original table as FK A should not remain in the original table PK of the original table must be changed to B, C, D. A: staffNo B, C: Date, Time D: surgeryNo
Decomposing to BCNF R (A, B, C, D, E, F) PK: A, B, C AK: B, C, D FK: None FDs: A, B, C All B, C, D All B, D A R1 (A, B, D) PK: B, D AK: NONE FK: None FDs: B, D A Does R1 have a FK? R (B, C, D, E, F) PK: B, C, D AK: NONE FK: B, D References R1 FDs: B, C, D All Does R2 have a FK? A: staffNo B, C: Date, Time D: surgeryNo
Table Instance A B C D E F 2 10 x u ct 1 1 20 y v cis 2 2 10 z u se 3 1 20 x v cs 4 FDs: A, B, C All B, C, D All B, D A A B D 2 10 u 1 20 v B C D E F 10 x u ct 1 20 y v cis 2 10 z u se 3 20 x v cs 4 A: staffNo B, C: Date, Time D: surgeryNo
Selecting B, C, D as PK at the Beginning R (A, B, C, D, E, F) PK: A, B, C AK: B, C, D FK: None FDs: A, B, C All B, C, D All B, D A R (A, B, C, D, E, F) PK: B, C, D AK: A, B, C FK: None FDs: A, B, C All B, C, D All B, D A Partial FD on PK! A: staffNo B, C: Date, Time D: surgeryNo
Review: Normalization 1NF Remove multi-value attributes Why: each element can not be a set (first order logic) 2NF Remove partial FDs on PK Why: remove redundant data 3NF Remove transitive FDs on PK BCNF Stronger than 3NF Any candidate keys Why: better PK remove redundant data In most cases, BCNF is enough.
Lossless Decomposition After a relation is normalized into two or more relations, the original relations could be obtained by joining new relations Primary Key and Foreign Key
Decompose Lease into BCNF Lease (RNo, RName, PNo, PAddress, Start, Finish, Rent, ONo, OName) Owner (ONo, OName) ONo ---> OName Renter (RNo, RName) RNo ---> RName Property (PNo, PAddress, ONo) PNo ---> PAddress, ONo PAddress ---> PNo, Ono Lease (RNo, PNo, Start, Finish, Rent) PNo, Start ---> All other attributes PNo, Finish ---> All other attributes How to get Property data for a lease? Lease Property How to get Renter data for a lease? Lease Renter How to get Owner data for a lease? Lease Property Owner
De-Normalization Normalized relations Minimal redundancy Need join operation to get results How far should we go? Where to stop?
Review: Database Design A structured approach that uses procedures, techniques, tools, and documentation aids to support and facilitate the process of design. Three main phases Conceptual database design Understanding client data E-R (EER) Model Contract between clients and designers Logical database design Mapping E-R Model to (relational) database schema (Derive relational schema from E-R Model) DBDL Normalization Physical database design
Schedule Assignment_52 Assignment_62 Quiz 2 Test 1 Monday, March 5, by 5 PM Assignment_62 Friday, March 9, by 5 PM Quiz 2 Wednesday, March 7 Test 1 Wednesday, March 14
Quiz 2 Wednesday, March 7 Lab 206 D2L Must go to Lab 206 during your section to take the quiz Derive table schemas from E-R Model (Mapping E-R Model to Database Schema) DBDL Functional Dependency Note11 – Note14 Assignment 4, 5-1 and 6-1