Functional dependencies

• Definition: a -> b
• ‘a’ functionally determines ‘b’ Informally: ‘if you know ‘a’,
there is only one ‘b’ to match’
Functional Dependencies
• formally:

• if two tuples agree on the ‘X’ attribute, they *must* agree on the ‘Y’
attribute, too (eg., if ssn is the same, so should address)
Goal
• Design ‘good’ tables
• sub-goal#1: define what ‘good’ means
• sub-goal#2: fix ‘bad’ tables
• In short: “we want tables where the attributes depend on the primary
key, on the whole key, and nothing but the key”
• Let’s see why and how:
Solution: Decomposition
• split offending table in two (or more), eg.:
Decompositions
• There are ‘bad’ decompositions. Good ones are:
• lossless and MUST HAVE

• dependency preserving Nice to have

Decompositions - lossless
Decompositions – dependency preserving
 Today’s Agenda

1. 1NF

2. 2NF

3. 3NF

4. BCNF

5. How to decompose a table tconform to BCNF

Normal forms
• 1NF: attributes are atomic (ie., no set valued attr., a.k.a. ‘repeating
groups’)
Normal forms
• 2NF: 1NF and non-key attr. fully depend on the key
Normal forms
• 3NF: 2NF and no transitive dependencies
• counter-example:
R(A, B, C, D)
Normal forms
• STJ( Student, Teacher, subJect)
• Key: Student, subJect
• T-> J
• S,J -> T

informally, 3NF ‘forgives’ the red

arrow in the canonical cover
In 3NF, but not in BCNF
Normal forms – 3NF
• STJ( Student, Teacher, subJect) Formally, a rel. R with
• T-> J
FDs ‘F’ is in 3NF if: for
• S,J -> T
every a->b in F:
• it is trivial or
• a is a superkey or
b: part of a candidate
key
Question
• Question 1:
What maximum normal
form is the relation in?

Has set-valued attributes?

Question
• Question 1:
What maximum normal
form is the relation in?

Has set-valued attributes?

No => 1NF
Question
• Question 1:
What maximum normal
form is the relation in?

Has set-valued attributes?

No => 1NF
Are all non-key attributes
fully determined by the
key?
No => not 2NF
Question
• Question 1:
Is this 3NF?
It is not 2NF, so it is not
3NF

Another way to solve this

question?
Question
• Question 1:
Is this 3NF?
It is not 2NF, so it is not
3NF

Another way to solve this

question?
for every a->b in F:
• it is trivial or
• a is a superkey or
• b: part of a candidate key
Normal forms - BCNF
• Formally: for every FD a->b in F
• a->b is trivial (a superset of b) or
• a is a superkey
Sailors(SID, SName, Age, Rating, ZipCode)
Reserves(SID, BID, StartingDate, EndingDate)
Boats(BID, BName, Color, ZipCode)

Which function dependency will make above relations

violate the BCNF?

A. SID, BID -> StartingDate

B. SID -> Rating
C. BID -> ZipCode
D. BName -> BID
Normal forms - BCNF
• Theorem: given a schema R and a set of FD ‘F’, we can always
decompose it to schemas R1, … Rn, so that
• R1, … Rn are in BCNF and
• the decompositions are lossless.
• (but, some decompositions might lose dependencies)
Normal forms - BCNF
• How? algorithm in book: for a relation R
• for every FD X->A that violates BCNF, decompose to tables (X,A) and (R-A)
• repeat recursively
• eg. TAKES1(ssn, c-id, grade, name, address)
• ssn -> name, address
• ssn, c-id -> grade
Normal forms - BCNF
 Consider the relation:

Dept(DeptID, DeptName, Location, WorkerID,

WorkerName, Age, Salary)

Suppose the following dependencies exist:

DeptID → DeptName, Location

WorkerID → WorkerName, Age
DeptID, WorkerID → Salary

Question 1. Is this relation in 3NF?

Question 2. Which dependency violates 3NF and BCNF?
Question 3. How to decompose for BCNF?
Normal forms - 3NF vs BCNF
• If ‘R’ is in BCNF, it is always in 3NF (but not the reverse)
• In practice, aim for
• BCNF; lossless join; and dep. preservation
• if impossible, we accept
• 3NF; but insist on lossless join and dep. Preservation
• in practice, E-R diagrams usually lead to tables in BCNF