CS 3630 Database Design and Implementation

Slides:



Advertisements
Similar presentations
Unnormalized Form (UNF) student courses John CS363 CS334 CS323 Multi-Value attribute Common in reports 1.
Advertisements

Schema Refinement and Normal Forms Given a design, how do we know it is good or not? What is the best design? Can a bad design be transformed into a good.
1 Assignment 4 Map entities with relationships to relational schemas. Use DBDL to describe the table schemas.
Assignment Design Methodology A structured approach that uses procedures, techniques, tools, and documentation aids to support and facilitate the.
Boyce-Codd Normal Form (BCNF) Definition R in 1NF and Every determinant (the left side of a FD) is a candidate key. 1.
1 Database Systems: A Practical Approach to Design, Implementation and Management International Computer Science S. Carolyn Begg, Thomas Connolly Lecture.
Database Design Conceptual –identify important entities and relationships –determine attribute domains and candidate keys –draw the E-R diagram Logical.
1 Design Methodology A structured approach that uses procedures, techniques, tools, and documentation aids to support and facilitate the process of design.
CS 3630 Database Design and Implementation. First Normal Form (1NF) No multi-value attributes Done when mapping E-R model to relational schema DBDL 2.
1 CS 3630 Database Design and Implementation. 2 Final Exam 7:00 – 8:52 PM, Thursday, May 16 Section 1: Ull 009 Section 2: Ull Points –50 points.
Why Normalization? To Reduce Redundancy to 1.avoid modification, insertion, deletion anomolies 2.save space Goal: One Fact in One Place.
CSC271 Database Systems Lecture # 28.
1 CS 3630 Database Design and Implementation. 2 Sets Foundation of relational database. Basic Operations Power set Mapping.
Chapters 15 &16 Conceptual and Logical Database Design Methodology.
Chapter 13 Normalization Transparencies Last Updated: 08 th May 2011 By M. Arief
CS 3630 Database Design and Implementation. 2 Functions y = f(x) x1 = x2  f(x1) = f(x2) Same x value, then same function value. Yes, it’s a function!
CS 3630 Database Design and Implementation. 2 Design Methodology Three main phases 1.Conceptual database design Understanding client data E-R (EER) Model.
CS 3630 Database Design and Implementation. Unnormalized Form (UNF) student courses John CS363 CS334 CS323 Multi-Value attribute Common in reports 2.
Dr. Mohamed Osman Hegaz1 Logical data base design (2) Normalization.
Normalization. 2 u Main objective in developing a logical data model for relational database systems is to create an accurate representation of the data,
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.
Quiz Where to Store Attributes of Relationship Staff (1) Interviews (0..*) Client Attributes: date, time, comment Staff (StaffNo, …) PK: StaffNo.
1 CS 430 Database Theory Winter 2005 Lecture 8: Functional Dependencies Second, Third, and Boyce-Codd Normal Forms.
1 CS490 Database Management Systems. 2 CS490 Database Normalization.
Chapter 8 Relational Database Design Topic 1: Normalization Chuan Li 1 © Pearson Education Limited 1995, 2005.
CS 3630 Database Design and Implementation
COP 6726: New Directions in Database Systems
CS 3630 Database Design and Implementation
Functional Dependency and Normalization
Advanced Normalization
SEEM3430: Information Systems Analysis and Design
Normalization DBMS.
Normalization Dongsheng Lu Feb 21, 2003.
Chapter 15 Basics of Functional Dependencies and Normalization for Relational Databases.
Chapter 7 Normalization Chapter 14 & 15 in Textbook.
CS 3630 Database Design and Implementation
Advanced Normalization
Advanced Normalization
Normalization Lecture 7 May Aldoayan.
Assignment 4 Map entities with relationships to relational schemas.
Chapter 14 Normalization
Chapter 15 Basics of Functional Dependencies and Normalization for Relational Databases.
CS 3630 Database Design and Implementation
Normalization 2NF & 3NF Presented by: Dr. Samir Tartir
CS 3630 Database Design and Implementation
Normalization.
Normalization There is a sequence to normal forms:
Normalization Murali Mani.
CSCI 4333 Database Design and Implementation – Exercise (3)
CS 3630 Database Design and Implementation
Normalization Boyce-Codd Normal Form Presented by: Dr. Samir Tartir
Boyce-Codd Normal Form (BCNF)
Chapter 14 & Chapter 15 Normalization Pearson Education © 2009.
Normalization.
Normalization Dongsheng Lu Feb 21, 2003.
Chapter 7 Normalization Chapter 13 in Textbook.
Database solutions The process of normalization Marzena Nowakowska Faculty of Management and Computer Modelling Kielce University of Technology rooms:
Normalization Dale-Marie Wilson, Ph.D..
CS 3630 Database Design and Implementation
CS 3630 Database Design and Implementation
Normalization.
Normalization Edited by: Nada Alhirabi.
Chapter 15 Basics of Functional Dependencies and Normalization for Relational Databases.
國立臺北科技大學 課程:資料庫系統 2015 fall Chapter 14 Normalization.
Normalization of DB relations examples Fall 2015
Sampath Jayarathna Cal Poly Pomona
Chapter 7 Normalization Chapter 14 & 15 in Textbook.
Database Normalization.
Database Design Normalisation (2)
CSCI 6315 Applied Database Systems – Exercise (5)
Presentation transcript:

CS 3630 Database Design and Implementation

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) Owner (ONo, OName) ONo ---> Oname Renter (RNo, RName) RNo ---> RName Property (PNo, PAddress, ONo) PNo ---> PAddress, ONo PAddress ---> PNo, Ono Only 4 tables, not 5. Pno  Paddress Paddress  Pno Ono will not be in Lease. Pno ---> Ono 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) 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 (Ono not in Lease any more) Property (PNo, PAddress, Ono) PNo ---> PAddress, Ono PAddress ---> PNo, Ono Owner (Onp, Oname) Ono ---> Oname Ono is not in Lease any more!

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? R2 (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 A is Partial 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