Boyce-Codd Normal Form (BCNF)

Slides:

Advertisements

Similar presentations

5 5 Normalization of Database Tables Database Systems: Design, Implementation, and Management 4th Edition Peter Rob & Carlos Coronel.

Advertisements

Normalisation 2 Chapter 4.2 V3.0 Napier University Dr Gordon Russell.

Normalisation to 3NF Database Systems Lecture 11 Natasha Alechina.

Boyce-Codd NF Takahiko Saito Spring 2005 CS 157A.

Boyce-Codd normal form (BCNF) Kai Zhu CS157B Professor: Dr. Lee.

Kingdom of Saudi Arabia Ministry of Higher Education Al-Imam Muhammad Ibn Saud Islamic University College of Computer and Information Sciences Normalization.

Assignment 6-1 Schedule(staffNo, dentistName, patNo, patName, surgeryNo, Date, Time) Make assumptions: surgeryNo is the surgery room number. staffNo, patNo,

Ms. Hatoon Al-Sagri CCIS – IS Department Normalization.

Boyce-Codd Normal Form (BCNF) Definition R in 1NF and Every determinant (the left side of a FD) is a candidate key. 1.

Relation A B C D E F 1NF? 2NF? 3NF? Relation1 A B Relation2 A* C D E* Help me Codd!! Relation3 E F Normalisation Reading: Connolly and Begg 13 & 14 (4th.

Need for Normalization

Database Design Conceptual –identify important entities and relationships –determine attribute domains and candidate keys –draw the E-R diagram Logical.

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.

Why Normalization? To Reduce Redundancy to 1.avoid modification, insertion, deletion anomolies 2.save space Goal: One Fact in One Place.

1 Minggu 10, Pertemuan 19 Normalization (cont.) Matakuliah: T0206-Sistem Basisdata Tahun: 2005 Versi: 1.0/0.0.

Assignment 5-1 Functional Dependencies Attributes within one table True for all table instances Part of table schema (Assumptions) Cannot get FDs just.

Lecture 12 Inst: Haya Sammaneh

Data Normalization Normal is not something to aspire to, it's something to get away from. ~ Jodie Foster ~

Project – Phase II Derive Database Schema from E-R Model DBDL.

1 CS 3630 Database Design and Implementation. 2 Sets Foundation of relational database. Basic Operations Power set Mapping.

Normal Forms through BCNF CPSC 356 Database Ellen Walker Hiram College (Includes figures from Database Systems by Connolly & Begg, © Addison Wesley 2002)

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.

Database Design – Lecture 9 Normalization Continued.

Chapter 13 Normalization Transparencies. 2 Chapter 13 - Objectives u How to undertake process of normalization. u How to identify most commonly used normal.

Chapter 7 Normalization Chapter 14 & 15 in Textbook.

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.

Assignment 5–2 For each new relation, Use DBDL to specify the relation scheme Give the functional dependencies Give the corresponding relation instance.

Database Architecture Normalization. Purpose of Normalization A technique for producing a set of relations with desirable properties, given the data requirements.

Chapter 8 Relational Database Design Topic 1: Normalization Chuan Li 1 © Pearson Education Limited 1995, 2005.

CS 3630 Database Design and Implementation

Normalization (Chapter 2)

CS 3630 Database Design and Implementation

Normalization DBMS.

Normalization Dongsheng Lu Feb 21, 2003.

Payroll Management System

Advanced Normalization

Advanced Normalization

Normalization Lecture 7 May Aldoayan.

Assignment 4 Map entities with relationships to relational schemas.

CS 3630 Database Design and Implementation

Assignment 5–2 For each table, Give a meaningful name

CS 3630 Database Design and Implementation

Normalization of Database Tables PRESENTED BY TANVEERA AKHTER FOR BCA 2ND YEAR dated:15/09/2015 DEPT. OF COMPUTER SCIENCE.

Normalization There is a sequence to normal forms:

Database Normalization

CSCI 2141 – Intro to Database Systems Database Normalization

CS 3630 Database Design and Implementation

Chapter 14 & Chapter 15 Normalization Pearson Education © 2009.

Normalization and FD.

Normalization Dongsheng Lu Feb 21, 2003.

Table Normal Forms.

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

Normalization Normalization

CS 3630 Database Design and Implementation

Normalization Edited by: Nada Alhirabi.

Boyce-Codd Normal Form (BCNF)

Normalisation to 3NF.

Chapter 14 Normalization.

Normalization of DB relations examples Fall 2015

Sampath Jayarathna Cal Poly Pomona

Lecture 04 Normalization.

Database Normalization.

Database Normalization.

Database Design Normalisation (2)

Presentation transcript:

Boyce-Codd Normal Form (BCNF) Definition R in 1NF and Every determinant (the left side) of any FD is a candidate key.

Not in BCNF SurgeryRoomSchedule (staffNo, dentistName, patNo, patName, surgeryNo, date, time) PK: surgeryNo, Date, Time AK: staffNo, Date, Time patNo, Date, Time FK: None FDs: surgeryNo, Date, Time ===> staffNo, patNo (All) staffNo, Date, Time ===> surgeryNo, patNo (All) patNo, Date, Time ===> staffNo, surgeryNo (All) (The determinants are NOT candidate keys) staffNo ===> dentistName (transitive on PK) patNo ===> patName (transitive on PK) staffNo, Date ===> surgeryNo (surgeryNo is a PK attribute!)

Different PK SurgeryRoomSchedule (staffNo, dentistName, patNo, patName, surgeryNo, date, time) PK: staffNo, date, time AK: surgeryNo, date, time patNo, date, time FK: None staffNo, Date, Time ===> patNo, surgeryNo (All) surgeryNo, Date, Time ===> staffNo, patNo (All) patNo, Date, Time ===> staffNo, surgeryNo (All) staffNo ===> dentistName (partial on PK) patNo ===> patName (transitive on PK) staffNo, Date ===> surgeryNo (partial on PK!)

SurgeryRoomSchedule (staffNo, dentistName, patNo, patName, surgeryNo, date, time) PK: surgeryNo, Date, Time FDs: surgeryNo, Date, Time ===> staffNo, patNo (All) staffNo, Date, Time ===> surgeryNo, patNo (All) patNo, Date, Time ===> staffNo, surgeryNo (All) staffNo ===> dentistName (determinant is NOT candidate key) patNo ===> patName (determinant is NOT candidate key) staffNo, Date ===> surgeryNo (determinant is NOT candidate key) New Tables in BCNF Staff (staffNo, dentistName) Patient (patNo, patName) RoomAllocation (staffNo, Date, surgeryNo) Schedule (staffNo, patNo, date, time) PK & FK!

Staff (staffNo, dentistName) PK: staffNo AK: None FK: None FDs: staffNo ===> dentistName SurgeryRoomSchedule (staffNo, patNo, date, time) PK: staffNo, date, time AK: patNo, date, time FK: staffNo references Staff patNo references Patient staffNo, Date references Room FDs: staffNo, Date, Time ===> patNo patNo, Date, Time ===> staffNo PK and AK can be switched. Patient (patNo, patName) PK: patNo AK: None FK: None FDs: patNo ===> patName RoomAllocation (staffNo, Date, surgeryNo) PK: staffNo, Date AK: None FK: staffNo references Staff staffNo, Date ===> surgeryNo

Staff (staffNo, dentistName) PK: staffNo AK: None FK: None FDs: staffNo ===> dentistName staffNo dentistName ------------- -------------------- S1011 Tony Smith S1024 Helen Pearson S1032 Robin Plevin S1035 Tony Smith dentistName will be removed from the original table, But staffNo remains in the original table.

Patient (patNo, patName) PK: patNo AK: None FK: None FDs: patNo ===> patName patNo patName ------------ ------------------- P100 Gillian White P105 Jill Bell P108 Ian MacKay P110 John Walker patName will be removed from the original table, But patNo remains in the original table.

RoomAllocation (staffNo, Date, surgeryNo) PK: staffNo, Date AK: None FK: staffNo references Staff FDs: staffNo, Date ===> surgeryNo staffNo Date surgeryNo ---------- ------------ -------------- S1011 12-Sep-04 S15 S1024 12-Sep-04 S15 S1024 14-Sep-04 S10 S1032 14-Sep-04 S13 S1035 12-Sep-04 S15 surgeryNo will be removed from the original table, But staffNo and Date remains in the original table.

SurgeryRoomSchedule (staffNo, patNo, date, time) PK: patNo, date, time AK: staffNo, date, time FK: staffNo references Staff patNo references Patient staffNo, Date references RoomAllocation FDs: staffNo, Date, Time ===> patNo patNo, Date, Time ===> staffNo staffNo patNo date time ---------- ---------- ------------- ---------- S1011 P100 12-Sep-04 10:00 S1011 P105 12-Sep-04 12:00 S1024 P108 12-Sep-04 11:00 S1024 P108 14-Sep-04 14:00 S1032 P105 14-Sep-04 16:30 S1032 P110 14-Sep-04 18:00 S1035 P110 12-Sep-04 14:00

SurgeryRoomSchedule (staffNo, patNo, date, time, surgeryNo) PK: patNo, date, time AK: staffNo, date, time FK: staffNo references Staff patNo references Patient staffNo, Date references RoomAllocation FDs: staffNo, Date, Time ===> patNo patNo, Date, Time ===> staffNo staffNo, Date ===> surgeryNo

Schedule (staffNo, patNo, date, time) PK: patNo, date, time AK: staffNo, date, time FK: staffNo references Staff patNo references Patient staffNo, Date references RoomAllocation FDs: staffNo, Date, Time ===> patNo patNo, Date, Time ===> staffNo staffNo patNo date time ---------- ---------- ------------- ---------- S1011 P100 12-Sep-04 10:00 S1011 P105 12-Sep-04 12:00 S1024 P108 12-Sep-04 11:00 S1024 P108 14-Sep-04 14:00 S1032 P105 14-Sep-04 16:30 S1032 P110 14-Sep-04 18:00 S1035 P110 12-Sep-04 14:00