1 / 30

CS 3630 Database Design and Implementation

CS 3630 Database Design and Implementation. Assignment 6-1. 1. staffNo  dentistName patNo  patName staffNo, Date  surgeryNo staffNo, Date, Time  All patNo, Date, Time  All surgeryNo, Date, Time  All 2. staffNo, Date, Time (any one of the three ALL FDs) 3.

cramey
Download Presentation

CS 3630 Database Design and Implementation

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. CS 3630 Database Design and Implementation

  2. Assignment 6-1 1. staffNo  dentistName patNo  patName staffNo, Date  surgeryNo staffNo, Date, Time  All patNo, Date, Time  All surgeryNo, Date, Time  All 2. staffNo, Date, Time (any one of the three ALL FDs) 3. patNo, Date, Time surgeryNo, Date, Time (the other two ALL FDs)

  3. Exercise Decompose R into 3NF Each table: DBDL FDs Table instance R (A, B, C, D, E, F) PK: A, B AK: None FK: None FDs: A, B  All C  D E  F Table Instance A B C D E F 1 x 10 100 se 400 1 y 20 200 cis 1000 2 x 30 100 cis 1000 2 y 10 100 ct 400

  4. R1 (C, D) PK: C AK: None FK: None FDs: C  D R (A, B, C, D, E, F) PK: A, B AK: None FK: None FDs: A, B  All C  D E  F R2 (E, F) PK: E AK: None FK: None FDs: E  F R (A, B, C, E) PK: A, B AK: None FK: C references R1 E references R2 FDs: A, B  All

  5. Table Instances R1 (C, D) PK: C AK: None FK: None FDs: C  D C D • 100 • 200 30 100 R2 (E, F) PK: E AK: None FK: None FDs: E  F E F se 400 cis 1000 ct 400 R (A, B, C, E) PK: A, B AK: None FK: None FDs: A, B  All A B C D 1 x 10 100 1 y 20 200 2 x 30 100 2 y 10 100 No Duplicates!

  6. First Normal Form (1NF) • No multi-value attributes • Done when mapping E-R model to relational schema • DBDL

  7. 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.

  8. Third Normal Form (3NF) 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.

  9. Boyce-Codd Normal Form (BCNF) Definition R in 1NF and The determinant of each FD is a candidate key. Review: 1NF determinant candidate key

  10. 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.

  11. 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.

  12. 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 PNo, Finish  All PAddress, Start  All PAddress, Finish  All 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?

  13. 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) PropertyPno (PNo, PAddress, Ono, Oname) PNo  PAddress, Ono, Oname PropertyAddress (PNo, PAddress, Ono, Oname) PAddress  PNo, Ono, Oname The Same Table!

  14. 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

  15. 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 BCNF? Lease (RNo, PNo, Start, Finish, Rent) PNo, Start  All PNo, Finish  All BCNF?

  16. 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 (Ono, Oname) Ono  Oname

  17. 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

  18. 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

  19. 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

  20. 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.

  21. Decomposing to BCNF R1 (A, B, D) PK: B, D AK: NONE FK: None FDs: B, D  A Does R1 have a FK? 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 (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?

  22. 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

  23. 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!

  24. 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 Why: remove redundant data • BCNF Stronger than 3NF Any candidate keys Why: better PK remove redundant data In most cases, BCNF is enough.

  25. 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

  26. 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

  27. De-Normalization • Normalized relations Minimal redundancy Need join operation to get results • How far should we go? • Where to stop?

  28. 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

  29. Schedule • Assignment_52 • Tuesday, March 5, by 11 PM • Assignment_62 • Friday, March 8, by 11 PM • Quiz 2 • Wednesday, March 6 • Test 1 • Wednesday, March 13

  30. Quiz 2 • Wednesday, March 6 • Lab 206 • Canvas • Must go to Lab 206 during your section to take the quiz • Need Access Code • Derive table schemas from E-R Model (Mapping E-R Model to Database Schema) • DBDL • Functional Dependency

More Related