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
XY
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; IS; SI
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
