Exercise – T/F

The columns of a relation are sometimes called “tuples.” Keys are always unique. A relation is in first normal form if all of its non-key attributes are dependent on part of the key. The functional dependency noted as A  B, means that the value of A can be determined from the value of B.
Elmasri and Navathe, Fundamentals of Database Systems, Fourth Edition Revised by IB & SAM, Fasilkom UI, 2005

Slide 11-1

Exercise – Multiple Choices
 Which of the following is known to be true from the functional dependency shown as (A, B)  (C, D)?
a. b. c. d. e. A is the determinant of C A and B together are determined by C and D together A and B together determine D C and D together determine A A determines B cells must contain single values all entries in a column must be of the same kind no two rows may be identical rows must be ordered by the value of the primary key the order of the columns is insignificant
Elmasri and Navathe, Fundamentals of Database Systems, Fourth Edition Revised by IB & SAM, Fasilkom UI, 2005

Which of the following is not a requirement for 1NF?
a. b. c. d. e.

Slide 11-2

Further Normalization
The main reference of this presentation is the textbook and PPT from : Elmasri & Navathe, Fundamental of Database Systems, 4th edition, 2004, Chapter 11 Additional resources: presentation prepared by Prof Steven A. Demurjian, Sr (http://www.engr.uconn.edu/~steve/courses.html)

Copyright © 2004 Pearson Education, Inc.

Outline
BCNF Multivalued Dependencies and Fourth Normal Form

Elmasri and Navathe, Fundamentals of Database Systems, Fourth Edition Revised by IB & SAM, Fasilkom UI, 2005

Slide 11-4

BCNF (Boyce-Codd Normal Form)
A relation schema R is in Boyce-Codd Normal Form (BCNF) if whenever an FD X -> A holds in R, then X is a superkey of R
 Each normal form is strictly stronger than the previous one
 Every 2NF relation is in 1NF  Every 3NF relation is in 2NF  Every BCNF relation is in 3NF

 There exist relations that are in 3NF but not in BCNF  The goal is to have each relation in BCNF (or 3NF)

Elmasri and Navathe, Fundamentals of Database Systems, Fourth Edition Revised by IB & SAM, Fasilkom UI, 2005

Slide 11-5

Figure 10.12 Boyce-Codd normal form
(a) BCNF normalization of LOTS1A with the functional dependency FD2 being lost in the decomposition. (b) A schematic relation with FDs; it is in 3NF, but not in BCNF.

Elmasri and Navathe, Fundamentals of Database Systems, Fourth Edition Revised by IB & SAM, Fasilkom UI, 2005

Slide 11-6

Figure 10.13 a relation TEACH that is in 3NF but not in BCNF

Elmasri and Navathe, Fundamentals of Database Systems, Fourth Edition Revised by IB & SAM, Fasilkom UI, 2005

Slide 11-7

Achieving the BCNF by Decomposition (1)
Two FDs exist in the relation TEACH: fd1: { student, course} -> instructor fd2: instructor -> course {student, course} is a candidate key for this relation and that the dependencies shown follow the pattern in Figure 10.12 (b). So this relation is in 3NF but not in BCNF

Elmasri and Navathe, Fundamentals of Database Systems, Fourth Edition Revised by IB & SAM, Fasilkom UI, 2005

Slide 11-8

Achieving the BCNF by Decomposition (2)
Three possible decompositions for relation TEACH 1. {student, instructor} and {student, course} 2. {course, instructor } and {course, student} 3. {instructor, course } and {instructor, student}  All three decompositions will lose fd1. We have to settle for sacrificing the functional dependency preservation. But we cannot sacrifice the non-additivity property after decomposition.  Out of the above three, only the 3rd decomposition will not generate spurious tuples after join.(and hence has the non-additivity property). 

Elmasri and Navathe, Fundamentals of Database Systems, Fourth Edition Revised by IB & SAM, Fasilkom UI, 2005

Slide 11-9

Comparing the Normal Forms
Poor Relational Schema Design Developed as Stepping Stone 1NF Eliminate partial FDs of non-key attributes to key 2NF Eliminate transitive FDs of non-key attributes to key 3NF Eliminate partial and transitive FDs of key attributes to key BCNF Most 3NF are in BCNF - BCNF Eliminates All Update Anomalies
Slide 11-10

Eliminate the non-trivial functional dependencies of non-key attributes to key

Elmasri and Navathe, Fundamentals of Database Systems, Fourth Edition Revised by IB & SAM, Fasilkom UI, 2005

Reflections on Normalization
Normalization
A Tool for Validating the Quality of the Schema, Rather than Merely as a Method for Designing a Relational Schema  Promotes Each Concept of the Application Domain Mapping to Exactly One Concept of the Schema

 Normalization Process
Actually a Process of Concept Separation Concept Separation is Result of Applying a Top-down Methodology for Producing a Schema Via Subsequent Refinements and Decompositions
Elmasri and Navathe, Fundamentals of Database Systems, Fourth Edition Revised by IB & SAM, Fasilkom UI, 2005

Slide 11-11

Relational DB Design Process
Normalization Process Focused on Decomposition Raises Number of Questions
How do we Decompose a Schema into a Desirable Normal Form? What Criteria Should the Decomposed Schemas Follow in order to Preserve the Semantics of the Original Schema? Can we Guarantee the Decomposition’s Quality? Can we Prevent the “Loss” of Information? Are Dependencies Maintained in Decomposition?
Elmasri and Navathe, Fundamentals of Database Systems, Fourth Edition Revised by IB & SAM, Fasilkom UI, 2005

Slide 11-12

Recall Transitive FD/Update Anomalies
R = ( U, F ) U = { S#, DName, DHead } F = { S#→DName, DName →DHead } S#
S1 S2 S3 S4

DName DHead
D1 D1 D2 D3 John Jonh Smith Black

S# → Dhead” is a Transitive FD
When S4 Graduates, Head Information of D3 Lost Similarly, If D5 has No Students Yet, then the Head Information cannot be Stored in this Database Update Head of Any Department Requires an Update to Every Student Enrolled in the Dept.

Elmasri and Navathe, Fundamentals of Database Systems, Fourth Edition Revised by IB & SAM, Fasilkom UI, 2005

Slide 11-13

What are Possible Decompositions?
R = ( U, F ) U = { S#, DName, DHead } F = { S#→DName, DName →DHead }
S# S1 S2 S3 S4 DName D1 D1 D2 D3 DHead John John Smith Black

δ

1

Information Based

δ δ

1 1

= { R1(S#, ∅), R2(DName, ∅) , R3(DHead, ∅)} is Neither Lossless nor FD-Preserving

Elmasri and Navathe, Fundamentals of Database Systems, Fourth Edition Revised by IB & SAM, Fasilkom UI, 2005

Slide 11-14

What are Possible Decompositions?
R = ( U, F ) U = { S#, DName, DHead } F = { S#→DName, DName →DHead }
S# DName S1 D1 S2 D1 S3 D2 S4 D3

S# S1 S2 S3 S4

DHead John John Smith Black

δ

•Lossless Decomposition but not Dependency-Preserving 2 •DName→DHead is lost in the decomposition

δ

2

= { R1({S# ,DName}, {S#→DName}), R2({S#, DHead}, {S#→DHead})}

δ

2

is Lossless but not FD-Preserving
Elmasri and Navathe, Fundamentals of Database Systems, Fourth Edition Revised by IB & SAM, Fasilkom UI, 2005

Slide 11-15

What are Possible Decompositions?
R = ( U, F ) U = { S#, DName, DHead } F = { S#→DName, DName →DHead }
S# DName S1 D1 S2 D1 S3 D2 S4 D3

DName DHead D1 D1 D2 D3 John John

δ

Lossless & dependency3 preserving decomposition

δ

3

= { R1({S# ,DName}, {S# → DName}) R3({DName, DHead}, {Dname → DHead})}

δ

3

is both Lossless and FD-Preserving
Elmasri and Navathe, Fundamentals of Database Systems, Fourth Edition Revised by IB & SAM, Fasilkom UI, 2005

Slide 11-16

Summary of Normalization
1NF
Lossless Decomposition and Dependency Preserving Eliminate the Partial Functional Dependencies of Non-prime Attributes to Key Attributes

2NF

Eliminate the Transitive Functional Dependencies of Non-prime Attributes to Key Attributes

3NF Lossless Decomposition but not Dependency Preserving BCNF
Eliminate the Partial and Transitive Functional Dependencies of Prime (Key) Attributes to Key
Slide 11-17

Elmasri and Navathe, Fundamentals of Database Systems, Fourth Edition Revised by IB & SAM, Fasilkom UI, 2005

The Entire Normalization Picture
1NF 2NF 3NF BCNF 4NF 5NF
Eliminate Partial FDs of Non-prime Attributes to Key Eliminate Transitive FDs of Nonprime Attributes to Key Eliminate Partial and Transitive FDs of Prime Attributes to Key Eliminate Non-trivial and Nonfunctional Multi-Valued Dependencies Eliminate Join Dependencies that are Not Implied by Candidate Key
Slide 11-18

Elmasri and Navathe, Fundamentals of Database Systems, Fourth Edition Revised by IB & SAM, Fasilkom UI, 2005

What are Multi-Valued Dependencies?
 Focused on the Concept of Multi-Valued Dependencies  A MVD X →→ Y Indicates that a Value of X Corresponds to Multiple Values of Y  Consider EMP with MVDs:
 ENAME →→ PNAME (E works on many Project)  ENAME →→ DNAME (E has many Dependents)

Elmasri and Navathe, Fundamentals of Database Systems, Fourth Edition Revised by IB & SAM, Fasilkom UI, 2005

Slide 11-19

What is Fourth Normal Form (4NF)?
 A Relation Schema R is in Fourth Normal Form (4NF) w.r.t Dependencies F (FD and MVD) if for every NonTrivial MVD X →→ Y in F+, X is a Superkey for R  MVD X →→ Y in R is called trivial if Y is subset of X, or X U Y = R  Reconsider EMP with MVDs: ENAME →→ PNAME (E works on many P) ENAME →→ DNAME (E has many Dependents)  ENAME is Not a Superkey of R since Need Triple of ENAME, PNAME, and DNAME to Distinguish  We need to Decompose EMP!
Elmasri and Navathe, Fundamentals of Database Systems, Fourth Edition Revised by IB & SAM, Fasilkom UI, 2005

Slide 11-20

Notes on FD
A functional dependency is trivial if it is satisfied by all instances of a relation
E.g.
 customer-name, loan-number → customer-name  customer-name → customer-name

In general, α → β is trivial if β ⊆ α

Elmasri and Navathe, Fundamentals of Database Systems, Fourth Edition Revised by IB & SAM, Fasilkom UI, 2005

Slide 11-21

Decomposition into 4NF

ENAME →→ PNAME is Trivial MVD: ENAME ∪ PNAME is Equal to EMP_PROJECTS (same for ENAME →→ DNAME)
Elmasri and Navathe, Fundamentals of Database Systems, Fourth Edition Revised by IB & SAM, Fasilkom UI, 2005

Slide 11-22

Multivalued Dependencies and 4NF
Decomposing a relation state of EMP that is not in 4NF. (a) EMP relation with additional tuples. (b) Two corresponding 4NF relations EMP_PROJECTS and EMP_DEPENDENTS.

Elmasri and Navathe, Fundamentals of Database Systems, Fourth Edition Revised by IB & SAM, Fasilkom UI, 2005

Slide 11-23

Other Normalizations
You can read by yourself

Elmasri and Navathe, Fundamentals of Database Systems, Fourth Edition Revised by IB & SAM, Fasilkom UI, 2005

Slide 11-24

Concluding Remarks
What have we Learned?
Guidelines for “Good” Relational Design Avoiding Anomalies Functional Dependencies Augment Schema Normalization “Improves” Design Lossless Joins and Dependency Preservation Quick Look at 4NF (Informally)

How is the Chapter Related to the Project?
Phase I in the Project: submit on 31th March
Step 1: ER Diagram Step 2: ER to Relational Mapping Step 3: Relational Normalization (1,2,3 NF) which Includes Identification of FDs!
Elmasri and Navathe, Fundamentals of Database Systems, Fourth Edition Revised by IB & SAM, Fasilkom UI, 2005

Slide 11-25

Exercise 10.19
 Consider the following two sets of functional dependencies F= {A ->C, AC ->D, E ->AD, E ->H} and G = {A ->CD, E ->AH}. Check whether or not they are equivalent.

Elmasri and Navathe, Fundamentals of Database Systems, Fourth Edition Revised by IB & SAM, Fasilkom UI, 2005

Slide 11-26

Exercise 10.33
 Consider the following relation for published books:
 BOOK (Book_title, Authorname, Book_type, Listprice, Author_affil, Publisher)  Author_affil referes to the affiliation of the author. Suppose the following dependencies exist:  Book_title -> Publisher, Book_type  Book_type -> Listprice  Author_name -> Author-affil

 (a) What normal form is the relation in? Explain your answer.  (b) Apply normalization until you cannot decompose the relations further. State the reasons behind each decomposition.

Elmasri and Navathe, Fundamentals of Database Systems, Fourth Edition Revised by IB & SAM, Fasilkom UI, 2005

Slide 11-27

Answer 10.19
To show equivalence, we prove that G is covered by F & F is covered by G. Proof that G is covered by F:  {A} + = {A, C, D} (with respect to F), which covers A ->CD in G  {E} + = {E, A, D, H, C} (with respect to F), which covers E ->AH in G Proof that F is covered by G:  {A} + = {A, C, D} (with respect to G), which covers A ->C in F  {A, C} + = {A, C, D} (with respect to G), which covers AC ->D in F  {E} + = {E, A, H, C, D} (with respect to G), which covers E ->AD and E ->H in F

Elmasri and Navathe, Fundamentals of Database Systems, Fourth Edition Revised by IB & SAM, Fasilkom UI, 2005

Slide 11-28

Answer10.33
 Given the relation  Book(Book_title, Authorname, Book_type, Listprice, Author_affil, Publisher)  and the FDs  Book_title . Publisher, Book_type  Book_type . Listprice  Authorname .Author_affil  (a)The key for this relation is Book_title,Authorname. This relation is in 1NF and not in  2NF as no attributes are FFD on the key. It is also not in 3NF.
Elmasri and Navathe, Fundamentals of Database Systems, Fourth Edition Revised by IB & SAM, Fasilkom UI, 2005

Slide 11-29

Answer10.33 (cont)
(b) 2NF decomposition:  Book0(Book_title, Authorname)  Book1(Book_title, Publisher, Book_type, Listprice)  Book2(Authorname, Author_affil) This decomposition eliminates the partial dependencies. 3NF decomposition:  Book0(Book_title, Authorname)  Book1-1(Book_title, Publisher, Book_type)  Book1-2(Book_type, Listprice)  Book2(Authorname, Author_affil)  This decomposition eliminates the transitive dependency of Listprice
Elmasri and Navathe, Fundamentals of Database Systems, Fourth Edition Revised by IB & SAM, Fasilkom UI, 2005

Slide 11-30

Exercise 10.7. Suppose we have the following requirements for a university

database that isused to keep track of students transcripts: (a) The university keeps track of each student's name (SNAME), student number (SNUM), social security number (SSSN), current address (SCADDR) and phone (SCPHONE), permanent address (SPADDR) and phone (SPPHONE), birthdate (BDATE), sex (SEX), class (CLASS) (freshman, sophomore, ..., graduate), major department (MAJORDEPTCODE), minor department (MINORDEPTCODE) (if any), and degree program (PROG) (B.A., B.S., ..., Ph.D.). Both ssn and student number have unique values for each student. (b) Each department is described by a name (DEPTNAME), department code (DEPTCODE), office number (DEPTOFFICE), office phone (DEPTPHONE), and college (DEPTCOLLEGE). Both name and code have unique values for each department. (c) Each course has a course name (CNAME), description (CDESC), code number (CNUM), number of semester hours (CREDIT), level (LEVEL), and offering department (CDEPT). The value of code number is unique for each course. (d) Each section has an instructor (INSTUCTORNAME), semester (SEMESTER), year (YEAR), course (SECCOURSE), and section number (SECNUM). Section numbers distinguish different sections of the same course that are taught during the same semester/year; its values are 1, 2, 3, ...; up to the number of sections taught during each semester. (e) A transcript refers to a student (SSSN), refers to a particular section, and grade (GRADE).

Design DB Schema, show FD, & normalize into 3NF or BCNF

Elmasri and Navathe, Fundamentals of Database Systems, Fourth Edition Revised by IB & SAM, Fasilkom UI, 2005

Slide 11-31

Answer:

From the above description, we can presume that the following functional dependencies hold on the attributes:

 FD1: {SSSN} -> {SNAME, SNUM, SCADDR, SCPHONE, SPADDR, SPPHONE, BDATE, SEX, CLASS,MAJOR, MINOR, PROG}  FD2: {SNUM} -> {SNAME, SSSN, SCADDR, SCPHONE, SPADDR, SPPHONE, BDATE, SEX, CLASS,MAJOR, MINOR, PROG}  FD3: {DEPTNAME} -> {DEPTCODE, DEPTOFFICE, DEPTPHONE, DEPTCOLLEGE}  FD4: {DEPTCODE} -> {DEPTNAME, DEPTOFFICE, DEPTPHONE, DEPTCOLLEGE}  FD5: {CNUM} -> {CNAME, CDESC, CREDIT, LEVEL, CDEPT}  FD6: {SECCOURSE, SEMESTER, YEAR, SECNUM} -> {INSTRUCTORNAME}  FD7: {SECCOURSE, SEMESTER, YEAR, SECNUM, SSSN} –> {GRADE}

Elmasri and Navathe, Fundamentals of Database Systems, Fourth Edition Revised by IB & SAM, Fasilkom UI, 2005

Slide 11-32

Elmasri and Navathe, Fundamentals of Database Systems, Fourth Edition Revised by IB & SAM, Fasilkom UI, 2005

Slide 11-33

Sign up to vote on this title
UsefulNot useful