Slide 11-1 Elmasri and Navathe, Fundamentals of Database Systems, Fourth Edition Revised by IB &...

Slide 11-1

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

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.

Slide 11-2


Exercise – Multiple Choices

Which of the following is known to be true from the functional dependency shown as (A, B) (C, D)?

a. A is the determinant of Cb. A and B together are determined by C and D togetherc. A and B together determine Dd. C and D together determine Ae. A determines B

Which of the following is not a requirement for 1NF?a. cells must contain single valuesb. all entries in a column must be of the same kindc. no two rows may be identicald. rows must be ordered by the value of the primary keye. the order of the columns is insignificant

Copyright © 2004 Pearson Education, Inc.

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)

Slide 11-4


Outline

BCNFMultivalued Dependencies and Fourth

Normal Form

Slide 11-5


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 BCNFThe goal is to have each relation in BCNF (or 3NF)

Slide 11-6


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.

Slide 11-7


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

Slide 11-8


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

Slide 11-9


Achieving the BCNF by Decomposition (2)

Three possible decompositions for relation TEACH1. {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).

Slide 11-10


1NF

2NF

3NF

BCNF

Eliminate the non-trivial functional

dependencies of non-key

attributes to key

Eliminate partial FDs of non-key attributes to key

Eliminate transitive FDs of non-key attributes to key

Eliminate partial and transitive FDs of key attributes to key

Poor Relational Schema DesignDeveloped as Stepping Stone

Most 3NF are in BCNF - BCNF Eliminates All Update Anomalies

Comparing the Normal Forms

Slide 11-11


Reflections on Normalization

NormalizationA 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 ProcessActually a Process of Concept SeparationConcept Separation is Result of Applying a Top-down

Methodology for Producing a Schema Via Subsequent Refinements and Decompositions

Slide 11-12


Relational DB Design Process

Normalization Process Focused on Decomposition

Raises Number of QuestionsHow 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?

Slide 11-13


S# DName DHeadR = ( U, F )

U = { S#, DName, DHead }

F = { S#DName,

DName DHead }

S1S2S3S4

D1D1D2D3

JohnJonhSmithBlack

Recall Transitive FD/Update Anomalies

S# Dhead” is a Transitive FDWhen S4 Graduates, Head Information of D3 LostSimilarly, If D5 has No Students Yet, then the Head

Information cannot be Stored in this DatabaseUpdate Head of Any Department Requires an Update

to Every Student Enrolled in the Dept.

Slide 11-14


What are Possible Decompositions?

S#

S1S2S3S4

D1D1D2D3

DHead

JohnJohnSmithBlack

DName

Information Based

R = ( U, F ) U = { S#, DName, DHead }

F = { S#DName, DName DHead }

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

is Neither Lossless nor FD-Preserving

Slide 11-15



S# DName

S1S2S3S4

D1D1D2D3

S# DHead

S1S2S3S4

JohnJohnSmithBlack

•Lossless Decomposition but not Dependency-Preserving•DNameDHead is lost in the decomposition



= { R1({S# ,DName}, {S#DName}),

R2({S#, DHead}, {S#DHead})}

is Lossless but not FD-Preserving

Slide 11-16



S# DName

S1S2S3S4

D1D1D2D3

DName DHead

JohnJohn

D1D1D2D3

Lossless & dependency-preserving decomposition



= { R1({S# ,DName}, {S# DName})

R3({DName, DHead}, {Dname DHead})}

is both Lossless and FD-Preserving

Slide 11-17


BCNF

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

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

Eliminate the Partial and Transitive Functional Dependencies of Prime (Key) Attributes to Key

Lossless Decomposition

but not Dependency Preserving

Lossless Decomposition

and Dependency Preserving2NF

3NF

1NF

Summary of Normalization

Slide 11-18


The Entire Normalization Picture1NF

2NF

3NF

BCNF

Eliminate Partial FDs of Non-prime Attributes to Key

Eliminate Transitive FDs of Non-prime Attributes to Key

Eliminate Partial and Transitive FDs of Prime Attributes to Key

4NF

Eliminate Non-trivial and Non-functional Multi-Valued Dependencies

5NF

Eliminate Join Dependencies that are Not Implied by Candidate Key

Slide 11-19


What are Multi-Valued Dependencies?

Focused on the Concept of Multi-Valued DependenciesA MVD X Y Indicates that a Value of X Corresponds

to Multiple Values of YConsider EMP with MVDs:

ENAME PNAME (E works on many Project)

ENAME DNAME (E has many Dependents)

Slide 11-20


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 Non-Trivial MVD X Y in F+, X is a Superkey for R

MVD X Y in R is called trivial ifY is subset of X, orX 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!

Slide 11-21


Notes on FD

A functional dependency is trivial if it is satisfied by all instances of a relationE.g.

customer-name, loan-number customer-name customer-name customer-name

In general, is trivial if

Slide 11-22


Decomposition into 4NF

ENAME PNAME is Trivial MVD: ENAME PNAME is

Equal to EMP_PROJECTS (same for ENAME DNAME)

Slide 11-23


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.

Slide 11-24


Other Normalizations

You can read by yourself

Slide 11-25


Concluding RemarksWhat have we Learned?

Guidelines for “Good” Relational DesignAvoiding Anomalies Functional Dependencies Augment SchemaNormalization “Improves” DesignLossless Joins and Dependency PreservationQuick Look at 4NF (Informally)

How is the Chapter Related to the Project?Phase I in the Project: submit on 31th March

Step 1: ER DiagramStep 2: ER to Relational MappingStep 3: Relational Normalization (1,2,3 NF) which Includes

Identification of FDs!

Slide 11-26


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.

Slide 11-27


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.

Slide 11-28


Answer 10.19To 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 GProof 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

Slide 11-29


Answer10.33

Given the relationBook(Book_title, Authorname, Book_type, Listprice,

Author_affil, Publisher)and the FDsBook_title . Publisher, Book_typeBook_type . ListpriceAuthorname .Author_affil (a)The key for this relation is Book_title,Authorname.

This relation is in 1NF and not in2NF as no attributes are FFD on the key. It is also not in

3NF.

Slide 11-30


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

Slide 11-31


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

Slide 11-32


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}

Slide 11-33


Date post:	27-Dec-2015
Category:	Documents
Upload:	howard-adams
View:	223 times
Download:	0 times

Slide 11-1 Elmasri and Navathe, Fundamentals of Database Systems, Fourth Edition Revised by IB &...

Documents