Scribd
Upload
3 views

Lab 14

Uploaded by

josh
Copyright
© © All Rights Reserved
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
3 views

Lab 14

Uploaded by

josh
Copyright
© © All Rights Reserved
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 18

Today’s Schedule

Review of Lecture: 20 minutes


Exercises: 55 minutes
Lecture Review
Function Dependency and Database Normalization
Functional Dependency
 In a state r of relation R, whenever two tuples agree on
their X-value, they also agree on their Y-value, that is:
If t1[X] = t2[X] then t1[Y] = t2[Y]
 A functional dependency (FD) is denoted by

XY

 It is a generalization of the key concept


 Each key value uniquely determines values of all other
attributes in a relation
(e.g., ssn  name, address, phone#)
Trivial Dependency vs Non-trivial Dependency

 If X  Y then X  Y
 This is trivial dependency
 E.g., SSN  SSN
 E.g., {Vehicle VIN, Reg}  {Vehicle VIN, Reg}
 E.g., {Vehicle VIN, Reg}  Reg

 Other dependencies are non-trivial dependency


 E.g., SSN  Name
 E.g., {Vehicle VIN, Reg}  {Manufacturer, Vehicle type}
First Normal Form (1NF)
 A relation is in 1NF if all its attribute values are atomic (i.e., simple).

 This means that a relation with multi-valued (or set-valued) attributes is not
in 1NF.
1NF Example
Name Age Children Years Company Title
name(s)
J Smith 40 Alice 75-80 Abc Chem Engineer
H. 50 Ben,Donna 70-79 Xerox Accountant
Nicholas
 Solution:

Name Age Children Years Company Title


name

J Smith 40 Alice 75-80 Abc Chem Engineer

H. 50 Ben 70-79 Xerox Accountant


Nicholas
H. 50 Donna 70-79 Xerox Accountant
Nicholas
Second Normal Form (2NF)
 A relation R is in 2NF if it is in 1NF and every nonprime attribute is fully
functionally dependent on each composite key.

 nonprime attribute: An attribute that is not part of any candidate key.

 e.g.,
 Relation: Sales (Dept, Item , Price)

 FD: Item  price

 key: {Dept, Item}

 Price is NOT fully functionally dependent on the key. Therefor, 2NF is

violated.
How to Achieve 2NF
 To convert a relation into 2NF, dept item price
separate the non-key attribute D1 I1 p1
that violates 2NF into a new
D1 I2 p2
relation together with its
partially dependent key D2 I2 p2
attribute. The partially
dependent key attribute will
be the primary key of the new
dept item item price
relation.
D1 I1 I1 p1
D1 I2 I2 p2
D2 I2
3NF (Third Normal Form)
 Transitive dependency:
 If A  B and B  C, then A  C

☞ A relation R is in 3NF if R is in 2NF and no non-key


attribute of R is transitively dependent on the key.
3NF Employee Example
 EMP_DEPT
EName SSN Bdate ADD DNUM DNAME DMGRSSN

 Key: SSN
 DF:
 SSN{Ename, Bdate, ADD, DNUM}
 DNUM{DNAME, DMGRSSN}
 Then we have transitive dependencies:
 SSN{DNAME, DMGRSSN}
 Therefore, this relation violates 3NF
How to Achieve 3NF
 Separate the non-key attributes that violate 3NF into a new relation
together with their directly dependent attribute. The directly dependent
attribute will be the key in the new relation.

EName SSN Bdate ADD DNUM DNAME DMGRSSN

DNUM DNAME DMGRSSN

EName SSN Bdate ADD DNUM


Boyce-Codd Normal Form (BCNF)
 BCNF : A relation schema R is in BCNF if whenever a nontrivial functional
dependency X  A holds in R, then X is a super key of R.

 In a nontrivial FD, the left hand side must be a super key of the
relation.
BCNF Grades Example 1
 Relation: Grades(StudId, SSN, Course, Grades)
I S C G
 Keys: {I, C}; {S, C}
 FD: {I, C}  G; {S, C}  G; IS; SI
 In 1NF, 2NF, and 3NF


But S I (a FD) violates BCNF definition

 Solution: Decompose into two relations:


 Students(StudId, SSN)
 Grades(StudId, Course, Grades)
BCNF Address Example 2
 A city is allocated with
several zip codes; a zip code
is only used in one city
 R( city, zipcode, StreetAdd )
C Z S

FD: {C, S}  Z; Z  C; {Z, S}  C
 Candidate Keys: {C, S}; {Z, S}
 In 1NF, 2NF, 3NF
 Z  C (Is this FD non-trivial? Yes)
 Z is not a super key.
 Hence R is not in BCNF
To Achieve BCNF (not achievable)
 R( city, zipcode, StreetAdd )
C Z S
 Decomposition into any relation schema {{CS}, {CZ}};
{{CS}, {SZ}}; {{CZ},{SZ}};… that does not have {C,S,Z} in one
relation, the dependency {CS}  Z is lost in the new
schema
 Example:
street city city zip
110 Yates St Chicago Arlington 76010
110 Yates St Dallas Arlington 76019
120 Main St Dallas
Although no FDs were violated in the decomposed relations,
FD CS  Z is not preserved by the schema as a whole.
BCNF
 The first example shows a non-BCNF relation that can be decomposed into
relations that satisfy BCNF and preserve the dependencies that held in the
original table.
 The second example shows a non-BCNF relation that cannot be
decomposed into relations that satisfy BCNF and preserve the dependencies
that held in the original table.

 Therefore, BNCF is not always achievable.


Lab Assignment
Submission
 Decomposed tables. Each table should have
 Table name
 Colum headers (attributes)
 Specified PK (underlined)
 FK if applicable and a reference (arrow pointing) to PK
in another table
 Data (rows) from the original table

You might also like