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.

Slides:



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

Copyright © 2011 Pearson Education, Inc. Publishing as Pearson Addison-Wesley Chapter 16 Relational Database Design Algorithms and Further Dependencies.
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.
Normalization Dr. Mario Guimaraes. Data Normalization Primarily a tool to validate and improve a logical design so that it satisfies certain constraints.
Ch 10, Functional Dependencies and Normal forms
Functional Dependencies and Normalization for Relational Databases.
The Relational Model System Development Life Cycle Normalisation
Boyce-Codd Normal Form (BCNF) Definition R in 1NF and Every determinant (the left side of a FD) is a candidate key. 1.
Copyright © 2011 Pearson Education, Inc. Publishing as Pearson Addison-Wesley Chapter 15 Basics of Functional Dependencies and Normalization for Relational.
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.
Normal Form Design addendum by C. Zaniolo. ©Silberschatz, Korth and Sudarshan7.2Database System Concepts Normal Form Design Compute the canonical cover.
Normalization of Database Tables
1 Design Methodology A structured approach that uses procedures, techniques, tools, and documentation aids to support and facilitate the process of design.
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.
Databases 6: Normalization
Why Normalization? To Reduce Redundancy to 1.avoid modification, insertion, deletion anomolies 2.save space Goal: One Fact in One Place.
Department of Computer Science and Engineering, HKUST Slide 1 7. Relational Database Design.
Chapter 8 Normalization for Relational Databases Copyright © 2004 Pearson Education, Inc.
Chapter 14 & 15 Conceptual & Logical Database Design Methodology
Chapter 10 Functional Dependencies and Normalization for Relational Databases.
Lecture 12 Inst: Haya Sammaneh
Normalization. Learners Support Publications 2 Objectives u The purpose of normalization. u The problems associated with redundant data.
Copyright © 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley Normalization for Relational Databases.
Lecture 6 Normalization: Advanced forms. Objectives How inference rules can identify a set of all functional dependencies for a relation. How Inference.
Database Design (Normalizations) DCO11310 Database Systems and Design By Rose Chang.
CSC 411/511: DBMS Design Dr. Nan Wang 1 Schema Refinement and Normal Forms Chapter 19.
CSCI 4333 Database Design and Implementation – Exercise (3) Xiang Lian The University of Texas – Pan American Edinburg, TX
CSC271 Database Systems Lecture # 28.
Normalization Fundamentals of Database Systems. Lilac Safadi Normalization 2 Database Design Steps in building a database for an application: Real-world.
1 CS 3630 Database Design and Implementation. 2 Sets Foundation of relational database. Basic Operations Power set Mapping.
Functional Dependencies and Normalization for Relational Databases.
Chapter 13 Normalization Transparencies. 2 Chapter 13 - Objectives u Purpose of normalization. u Problems associated with redundant data. u Identification.
Chapters 15 &16 Conceptual and Logical Database Design Methodology.
By Abdul Rashid Ahmad. E.F. Codd proposed three normal forms: The first, second, and third normal forms 1NF, 2NF and 3NF are based on the functional dependencies.
CSE314 Database Systems Basics of Functional Dependencies and Normalization for Relational Databases Doç. Dr. Mehmet Göktürk src: Elmasri & Navanthe 6E.
Lecture No 14 Functional Dependencies & Normalization ( III ) Mar 04 th 2011 Database Systems.
1 Functional Dependencies and Normalization Chapter 15.
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.
1 CSE 480: Database Systems Lecture 18: Normal Forms and Normalization.
Design Process - Where are we?
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,
Normalization.
Chapter 15 & 16 Conceptual and Logical Database Design Methodology Thomas Connolly, Carolyn Begg, Database System, A Practical Approach to Design Implementation.
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.
CS 3630 Database Design and Implementation. Null Value The value of an attribute could be NULL NOT known at the moment or NOT Applicable Example Cell.
1 CS 430 Database Theory Winter 2005 Lecture 8: Functional Dependencies Second, Third, and Boyce-Codd Normal Forms.
Copyright © Curt Hill Schema Refinement II 2 nd NF to 3 rd NF to BCNF.
Chapter 7 Normalization Chapter 14 & 15 in Textbook.
Relational Data Model, Review Relation Tuple Attribute Domains Candidate key, primary key Key attribute, non-key attribute.
Chapter 14 Functional Dependencies and Normalization Informal Design Guidelines for Relational Databases –Semantics of the Relation Attributes –Redundant.
1 CS490 Database Management Systems. 2 CS490 Database Normalization.
Chapter 9 Normalization Chapter 14 & 15 in Textbook.
CS 3630 Database Design and Implementation
CS 3630 Database Design and Implementation
SEEM3430: Information Systems Analysis and Design
CS 3630 Database Design and Implementation
CS 3630 Database Design and Implementation
Assignment 4 Map entities with relationships to relational schemas.
CS 3630 Database Design and Implementation
CS 3630 Database Design and Implementation
CS 3630 Database Design and Implementation
Boyce-Codd Normal Form (BCNF)
CS 3630 Database Design and Implementation
CS 3630 Database Design and Implementation
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 2

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

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

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

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

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 candidate key but a determinant (B ---> C ) So, R is not in BCNF. 7

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? 8

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 Lease (RNo, PNo, Start, Finish, Rent) PNo, Start ---> All PNo, Finish ---> All Property (PNo, PAddress, ONo) PNo ---> PAddress, ONo PAddress ---> PNo, Ono 9 Only 4 tables, not 5. Pno  Paddress Paddress  Pno Ono will not be in Lease. Pno ---> Ono

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 10

Table Instance A B C D E F 2 10 x u ct y v cis z u se x v cs4 FDs: A, B, C  All B, C, D  All B, D  A 11

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

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

Table Instance A B C D E F 2 10 x u ct y v cis z u se x v cs 4 FDs: A, B, C  All B, C, D  All B, D  A 14 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

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 15 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!

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

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 17

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 18 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? 19

20 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 1.Conceptual database design Understanding client data E-R (EER) Model Contract between clients and designers 2.Logical database design Mapping E-R Model to (relational) database schema (Derive relational schema from E-R Model) DBDL Normalization 3.Physical database design

Schedule Monday, March 2 Assignment6-1 Friday, March 6 Quiz2 Wednesday, March 11 Test1 21

Assignment 5-2 Due Today (before class) 22

Assignment