All Bcnf Is In 3nf, But All 3nf Is Not

  • Uploaded by: Sabrina Hossain Tonny
  • 0
  • 0
  • June 2020
  • PDF

This document was uploaded by user and they confirmed that they have the permission to share it. If you are author or own the copyright of this book, please report to us by using this DMCA report form. Report DMCA


Overview

Download & View All Bcnf Is In 3nf, But All 3nf Is Not as PDF for free.

More details

  • Words: 704
  • Pages: 5
All BCNF is in 3NF, but all 3NF is not in BCNF Relations that are in 3NF are also in BCNF. But, a 3NF relation is not in BCNF. A schema R is in BCNF with respect to a set F of functional dependencies, if for all functional dependencies in F+ of the form α → β , where α ⊆ R and β ⊆ R, at least one of the following holds: α → β is trivial (i.e., β ⊆ α ). α is a superkey for R. A relational schema R is in 3NF if for every functional dependency α ->β (where α is a subset of the attributes and β is a single attribute) either α ->β is trivial (i.e., β ⊆ α ) α is a superkey β is part of some key for R. Thus the definition of 3NF permits a few additional functional dependencies involving key attributes that are prohibited by BCNF. O, we can say that All BCNF is in 3NF, but all 3NF is not in BCNF. A 3NF relation may be in BCNF only if (a) the candidate keys in the relation are composite keys (that is, they are not single attributes), (b) there is more than one candidate key in the relation, and (c) the keys are not disjoint, that is, some attributes in the keys are common. Example Patient No

Patient Name Appointment Id

1

John

0

2

Kerr

0

3

Adam

1

4

Robert

0

5

Zane

1

Tim e 09:0 0 09:0 0 10:0 0 13:0 0 14:0 0

Docto r Zorro Killer Zorro Killer Zorro

Lets consider the database extract shown above. From this scenario we can extract the following determinants:

DB(Patno,PatName,appNo,time,doctor)

and Patno -> PatName Patno,appNo -> Time,doctor Time -> appNo

Now we have to decide what the primary key of DB is going to be. From the information we have, we could chose: DB(Patno,PatName,appNo,time,doctor) DB(Patno,PatName,appNo,time,doctor) a) 1NF Eliminate repeating groups. None: so just as before b) 2NF Eliminate partial key dependencies DB(Patno,appNo,time,doctor) R1(Patno,PatName) c) 3NF Eliminate transitive dependencies None: so just as 2NF d) BCNF: Every determinant is a candidate key DB(Patno,appNo,time,doctor) R1(Patno,PatName) BCNF: rewrite to DB(Patno,time,doctor) R1(Patno,PatName) R2(time,appNo) This example has demonstrated three things: • • • •

BCNF is stronger than 3NF, relations that are in 3NF are not necessarily in BCNF BCNF is needed in certain situations to obtain full understanding of the data model there are several routes to take to arrive at the same set of relations in BCNF. Unfortunately there are no rules as to which route will be the easiest one to take.

Information repetition 3NF- YES BCNF- NO

We have seen BCNF and 3NF. - It is always possible to obtain a 3NF design without sacri cing lossless-join or dependency preservation. - If we do not eliminate all transitive dependencies, we may need to use null values to represent some of the meaningful relationships. - Repetition of information occurs in 3NF. Example These problems can be illustrated with the following example Grade_report(StudNo,StudName,(Major,Adviser, (CourseNo,Ctitle,InstrucName,InstructLocn,Grade))) •

Functional dependencies

StudNo -> StudName CourseNo -> Ctitle,InstrucName InstrucName -> InstrucLocn StudNo,CourseNo,Major -> Grade StudNo,Major -> Advisor Advisor -> Major •

Unnormalised

Grade_report(StudNo,StudName,(Major,Advisor, (CourseNo,Ctitle,InstrucName,InstructLocn,Grade))) •

1NF Remove repeating groups

Student(StudNo,StudName) StudMajor(StudNo,Major,Advisor) StudCourse(StudNo,Major,CourseNo, Ctitle,InstrucName,InstructLocn,Grade) •

2NF Remove partial key dependencies

Student(StudNo,StudName) StudMajor(StudNo,Major,Advisor) StudCourse(StudNo,Major,CourseNo,Grade) Course(CourseNo,Ctitle,InstrucName,InstructLocn) •

3NF Remove transitive dependencies

Student(StudNo,StudName)

StudMajor(StudNo,Major,Advisor) StudCourse(StudNo,Major,CourseNo,Grade) Course(CourseNo,Ctitle,InstrucName) Instructor(InstructName,InstructLocn)



BCNF: Every determinant is a candidate key

Only StudNo,Major is a candidate key. •

BCNF

Student(StudNo,StudName) StudCourse(StudNo,Major,CourseNo,Grade) Course(CourseNo,Ctitle,InstrucName) Instructor(InstructName,InstructLocn) StudMajor(StudNo,Advisor) Adviser(Adviser,Major) Problems BCNF overcomes ADVISO R PHYSIC EINSTEI S N MOZAR MUSIC T BIOLOG DARWI Y N PHYSIC BOHR S PHYSIC EINSTEI S N

STUDENT MAJOR 123 123 456 789 999 • •

If the record for student 456 is deleted we lose not only information on student 456 but also the fact that DARWIN advises in BIOLOGY we cannot record the fact that WATSON can advise on COMPUTING until we have a student majoring in COMPUTING to whom we can assign WATSON as an advisor.

In BCNF we have two tables: STUDENT

ADVISO R

123 123 456 789 999

EINSTEI N MOZAR T DARWI N BOHR EINSTEI N

ADVISOR MAJOR EINSTEIN PHYSIC S MOZART MUSIC DARWIN BIOLOG Y BOHR PHYSIC S

Related Documents


More Documents from ""

Unix
May 2020 5
Ujian Dms.doc
June 2020 30
Visite Theatralisee
November 2019 43
Ntc Gp 1000
October 2019 43