CAS CS 460/660

Introduction to Database Systems

Functional Dependencies
and
Normal Forms

1.1
 Review: Database Design
 Requirements Analysis
 user needs; what must database do?
 Conceptual Design
 high level descr (often done w/ER model)
 Logical Design
 translate ER into DBMS data model
 Schema Refinement
 consistency,normalization
 Physical Design - indexes, disk layout
 Security Design - who accesses what
1.2
 Keys (review)

 A key is a set of attributes that uniquely

identifies each tuple in a relation.
 A candidate key is a key that is minimal.
If AB is a candidate key, then neither A nor B is
a key on its own.

 A superkey is a key that is not necessarily

minimal (although it could be)
If AB is a candidate key then ABC, ABD, and
even AB are superkeys.
1.3
 (Review) Projection
sname rating
yuppy 9
lubber 8
guppy 5
sid sname rating age rusty 10
28 yuppy 9 35.0
31 lubber 8 55.5  sname,rating(S 2)
44 guppy 5 35.0
58 rusty 10 35.0 age
S2 35.0
55.5
 age(S2)
1.4
 Functional Dependencies (FDs)
 A functional dependency X  Y holds over relation
schema R if, for every allowable instance r of R:
t1  r, t2  r, pX (t1) = pX (t2)
implies pY (t1) = pY (t2)
(where t1 and t2 are tuples;X and Y are sets of attributes)

 In other words: X  Y means

Given any two tuples in r, if the X values are the
same, then the Y values must also be the same.
(but not vice versa)
 Can read “” as “determines”

1.5
 FD’s Continued

 An FD is a statement about all allowable relations.

• Identified based on application semantics

• Given some instance r1 of R, we can check if r1

violates some FD f, but we cannot determine if f
holds over R.
 How related to keys?
• if “K  all attributes of R” then
K is a superkey for R
(does not require K to be minimal.)

• FDs are a generalization of keys.

1.6
 Example: Constraints on Entity Set

 Consider relation obtained from Hourly_Emps:

Hourly_Emps (ssn, name, lot, rating, wage_per_hr, hrs_per_wk)
 We sometimes denote a relation schema by listing the attributes:
e.g., SNLRWH
 This is really the set of attributes {S,N,L,R,W,H}.
 Sometimes, we refer to the set of all attributes of a relation by using
the relation name. e.g., “Hourly_Emps” for SNLRWH
 What are some FDs on Hourly_Emps (Given)?

ssn is the key: S  SNLRWH

rating determines wage_per_hr: R  W
lot determines lot: L  L (“trivial” dependnency)

1.7
 Redundancy Problems Due to R  W

Hourly_Emps

 Update anomaly: Can we modify W in only the 1st tuple of SNLRWH?

 Insertion anomaly: What if we want to insert an employee and don’t
know the hourly wage for his or her rating? (or we get it wrong?)
 Deletion anomaly: If we delete all employees with rating 5, we lose the
information about the wage for rating 5!

1.8
 Decomposing a Relation
 Redundancy can be removed by “chopping” the relation into
pieces.
 FD’s are used to drive this process.
R  W is causing the problems, so decompose SNLRWH into what
relations?

Wages
Hourly_Emps2

1.11
 Reasoning About FDs
 Given some FDs, we can usually infer additional FDs:
title  studio, star implies title  studio and title  star
title  studio and title  star implies title  studio, star
title  studio, studio  star implies title  star
But,
title, star  studio does NOT necessarily imply that title 
studio or that star  studio

 An FD f is implied by a set of FDs F if f holds whenever all FDs in F

hold.

 F+ = closure of F is the set of all FDs that are implied by F. (includes

“trivial dependencies”)

1.12
 Rules of Inference

 Armstrong’s Axioms (X, Y, Z are sets of attributes):

 Reflexivity: If Y  X, then X  Y
 Augmentation: If X  Y, then XZ  YZ for any Z
 Transitivity: If X  Y and Y  Z, then X  Z

 These are sound and complete inference rules for FDs!

 i.e., using AA you can compute all the FDs in F+ and only these FDs.

 Some additional rules (that follow from AA):

 Union: If X  Y and X  Z, then X  YZ
 Decomposition: If X  YZ, then X  Y and X  Z

1.13
 Example
 Contracts(cid,sid,jid,did,pid,qty,value), and:
 C is the key: C  CSJDPQV
 Job purchases each part using single contract: JP  C
 Dept purchases at most 1 part from a supplier: SD  P
 Problem: Prove that SDJ is a key for Contracts
• JP  C, C  CSJDPQV imply JP  CSJDPQV
(by transitivity) (shows that JP is a key)
• SD  P implies SDJ  JP (by augmentation)
• SDJ  JP, JP  CSJDPQV imply SDJ  CSJDPQV
• (by transitivity) thus SDJ is a key.

Q: can you now infer that SD  CSDPQV (i.e., drop J on

both sides)?
No! FD inference is not like arithmetic multiplication.
1.14
 Attribute Closure
 Size of F+ is exponential in # attributes in R;
 Computing it can be expensive.
 If we just want to check if a given FD X Y is in F+, then:
1) Compute the attribute closure of X (denoted X+) wrt F
• X+ = Set of all attributes A such that X  A is in F+
 initialize X+ := X
 Repeat until no change:
if U  V in F such that U is in X+, then add V to X+
2) Check if Y is in X+

 Can also be used to find the keys of a relation.

 If all attributes of R are in X+ then X is a superkey for R.

 Q: How to check if X is a “candidate key”?

1.15
 Attribute Closure (example)

 R = {A, B, C, D, E}
 F = { B CD, D  E, B  A, E  C, AD B }
 Is B  E in F+ ? • Is AD a key for R?
B =B
+ AD +
= AD
B+ = BCD AD+ = ABD and B is a key, so
B+ = BCDA Yes!
B+ = BCDAE … Yes! B is a key for R too! • Is AD a candidate key
 Is D a key for R? for R?
D+ = D A+ = A
D+ = DE
A not a key, nor is D so Yes!
D = DEC
+

• Is ADE a candidate key

… Nope!
for R?
No! AD is a key, so ADE is a
superkey, but not a cand. key
1.16
 Normal Forms

 Question: is any refinement needed??!

 If a relation is in a normal form (BCNF, 3NF etc.):
 we know that certain problems are avoided/minimized.
 helps decide whether decomposing a relation is useful.
 NFs are syntactic rules (don’t need to understand app)
 Role of FDs in detecting redundancy:
 Consider a relation R with 3 attributes, ABC.
 No (non-trivial) FDs hold: There is no redundancy here.
 Given A  B: If A is not a key, then several tuples could have the same A
value, and if so, they’ll all have the same B value!

 1st Normal Form – all attributes are atomic (i.e., “flat tables”)
 1st 2nd (of historical interest)  3rd  Boyce-Codd  …

1.17
Normal Forms

1.18
 Boyce-Codd Normal Form (BCNF)
 Reln R with FDs F is in BCNF if, for all X  A in F+
 A  X (called a trivial FD), or
 X is a superkey for R.
 In other words: “R is in BCNF if the only non-trivial FDs over R are key
constraints.”
 If R in BCNF, then every field of every tuple records information that cannot
be inferred using FDs alone.
 Say we are told that FD X  A holds for this example relation:

• Can you guess the value of the

missing attribute?

• Yes, so relation is not in BCNF

1.19
 Boyce-Codd Normal Form -
Alternative Formulation

“The key, the whole key, and

nothing but the key”

1.20
 Decomposition of a Relation Scheme
 If a relation is not in a desired normal form, it can be decomposed into
multiple relations that each are in that normal form.

 Suppose that relation R contains attributes A1 ... An. A decomposition

of R consists of replacing R by two or more relations such that:
 Each new relation scheme contains a subset of the attributes of R, and
 Every attribute of R appears as an attribute of at least one of the new
relations.

1.21
 Example

Hourly_Emps

 SNLRWH has FDs S  SNLRWH and R  W

 Q: Is this relation in BCNF?

No, The second FD causes a violation;

W values repeatedly associated with R values.
1.22
 Decomposing a Relation
 Easiest fix is to create a relation RW to store these associations,
and to remove W from the main schema:

Wages
Hourly_Emps2
• Q: Are both of these relations now in BCNF?
• Decompositions should be used only when needed.
– Q: potential problems of decomposition?
1.23
 Refining an ER Diagram
 1st diagram becomes: Before:
Workers(S,N,L,D,Si) since
name dname
Departments(D,M,B)
ssn lot did budget
 Lots associated with
workers. Works_In
Employees Departments
 Suppose all workers in
a dept are assigned the same
lot: DL
 Redundancy; fixed by: After:
Workers2(S,N,D,Si) budget
since
Dept_Lots(D,L) name dname
Departments(D,M,B) ssn did lot
 Can fine-tune this:
Workers2(S,N,D,Si) Employees Works_In Departments
Departments(D,M,B,L)
1.24
 Decomposing a Relation
 Easiest fix is to create a relation RW to store these associations,
and to remove W from the main schema:

Wages
Hourly_Emps2
• Q: Are both of these relations now in BCNF?
• Decompositions should be used only when needed.
– Q: potential problems of decomposition?
1.25
 Problems with Decompositions
 There are three potential problems to consider:
1) May be impossible to reconstruct the original relation! (Lossiness)
 Fortunately, not in the SNLRWH example.
2) Dependency checking may require joins.
 Fortunately, not in the SNLRWH example.
3) Some queries become more expensive.
 e.g., How much does Guldu earn?

Lossiness (#1) cannot be allowed

#2 and #3 are design tradeoffs: Must consider these
issues vs. redundancy.

1.26
Lossless Decomposition (example)

=
1.29
 Lossy Decomposition (example)

A  B; C  B

=
1.30
 Lossless Decomposition
 Decomposition of R into X and Y is lossless-join w.r.t. a set of FDs F if,
for every instance r that satisfies F:
(r) (r) = r
 The decomposition of R into X and Y is lossless with
respect to F if and only if F+ contains:
X  Y  X, or
XYY
in previous example: decomposing ABC into AB and BC is lossy, because
intersection (i.e., “B”) is not a key of either resulting relation.

 Useful result: If W  Z holds over R and W  Z is

empty, then decomposition of R into R-Z and WZ is
lossless.

1.31
 Lossless Decomposition (example)

A  B; C  B

=
But, now we can’t check A  B without doing a join!
1.32
 Dependency Preserving
Decomposition
 Dependency preserving decomposition (Intuitive):

 If R is decomposed into X, Y and Z, and we

enforce the FDs that hold individually on X, on Y
and on Z, then all FDs that were given to hold
on R must also hold. (Avoids Problem #2 on
our list.)

 The projection of F on attribute set X (denoted FX ) is the set of FDs

U  V in F+ (closure of F , not just F ) such that all of the attributes on
both sides of the f.d. are in X.
 That is: U and V are subsets of X

1.33
 Dependency Preserving Decompositions
(Contd.)

 Decomposition of R into X and Y is dependency preserving if

(FX  FY ) +
= F+
 i.e., if we consider only dependencies in the closure F + that can be checked in X
without considering Y, and in Y without considering X, these imply all
dependencies in F +.
 Important to consider F + in this definition:
 ABC, A  B, B  C, C  A, decomposed into AB and BC.
 Is this dependency preserving? Is C  A preserved?????
 note: F + contains F  {A  C, B  A, C  B}, so…

 FAB contains A B and B  A; FBC contains B  C and C  B

 So, (F  F )+ contains C  A
AB BC

1.34
 Decomposition into BCNF
 Consider relation R with FDs F.
If X  Y violates BCNF, decompose R into R - Y and XY
(guaranteed to be lossless).
 Repeated application of this idea will give us a collection of relations that are in
BCNF; lossless join decomposition, and guaranteed to terminate.
 e.g., CSJDPQV, key C, JP  C, SD  P, J  S
 {contractid, supplierid, projectid,deptid,partid, qty, value}
 To deal with SD  P, decompose into SDP, CSJDQV.
 To deal with J  S, decompose CSJDQV into JS and CJDQV
 So we end up with: SDP, JS, and CJDQV

 Note: several dependencies may cause violation of BCNF. The order in

which we fix them could lead to very different sets of relations!

1.35
 BCNF and Dependency Preservation

 In general, there may not be a dependency preserving decomposition into

BCNF.
 e.g., CSZ, CS  Z, Z  C
 Can’t decompose while preserving 1st FD; not in BCNF.
 Similarly, decomposition of CSJDPQV into SDP, JS and CJDQV is not
dependency preserving (w.r.t. the FDs JP  C, SD  P and J  S).
 {contractid, supplierid, projectid,deptid,partid, qty, value}
 However, it is a lossless join decomposition.
 In this case, adding JPC to the collection of relations gives us a dependency
preserving decomposition.
 but JPC tuples are stored only for checking the f.d. (Redundancy!)

1.36
 Third Normal Form (3NF)
 Reln R with FDs F is in 3NF if, for all X  A in F+
A  X (called a trivial FD), or
X is a superkey of R, or
A is part of some candidate key (not superkey!) for R. (sometimes stated as “A
is prime”)
 Minimality of a key is crucial in third condition above!
 If R is in BCNF, obviously in 3NF.
 If R is in 3NF, some redundancy is possible. It is a compromise, used when
BCNF not achievable (e.g., no ``good’’ decomp, or performance
considerations).
 Lossless-join, dependency-preserving decomposition of R into a collection of
3NF relations always possible.

1.37
 Decomposition into 3NF

 Obviously, the algorithm for lossless join decomp into BCNF can be used to
obtain a lossless join decomp into 3NF (typically, can stop earlier) but does
not ensure dependency preservation.
 To ensure dependency preservation, one idea:
 If X  Y is not preserved, add relation XY.
Problem is that XY may violate 3NF! e.g., consider the addition of CJP to
`preserve’ JP  C. What if we also have J  C ?
 Refinement: Instead of the given set of FDs F, use a minimal cover for F.

1.38
 Minimal Cover for a Set of FDs

 Minimal cover G for a set of FDs F:

 Closure of F = closure of G.
 Right hand side of each FD in G is a single attribute.
 If we modify G by deleting an FD or by deleting attributes from an FD in G, the
closure changes.
 Intuitively, every FD in G is needed, and ``as small as possible’’ in order to
get the same closure as F.
 e.g., A  B, ABCD  E, EF  GH, ACDF  EG has the following
minimal cover:
 A  B, ACD  E, EF  G and EF  H
 M.C. implies 3NF, Lossless-Join, Dep. Pres. Decomp!!!
 (more in book)

1.39
 Assertions

 How to test if and FD is satisfied?

 ASSERTIONS:

CREATE ASSERTION assertion_name CHECK predicate

Example:

CREATE ASSERTION SmallClub

CHECK ((SELECT COUNT(S.sid) FROM Sailors S) +
(SELECT COUNT(B.bid) FROM Boats B) < 100)

1.40
 Assertions

Constraint: A customer with a loan should have an account with at

least 1000 dollars.

create assertion balance_constraint check

(not exists (select * from loan L
where not exists (select *
from borrower B, depositor D, account A
where L.loan_no = B.loan_no
and B.cname = D.cname
and D.account_no = A.account_no
and A.balance >= 1000 ))

1.41
 Another example

customer(customer_name, customer_street, customer_city)

Constraint: Customer city is always not null.

Can enforce it with an assertion:

Create Assertion CityCheck Check

( NOT EXISTS (
Select *
From customer
Where customer_city is null));

1.42