Chapter Four

Functional Dependency and Normalization

content
Purpose of Normalization
Functional Dependency
Normalization

Prepared by Feven T. Chap 5 1

Purpose of Normalization
Normalization
Is technique for producing set of suitable relations that support
data of enterprise.
Is the process of decomposing unsatisfactory "bad"
relations by breaking up their attributes into smaller
relations.
Why do we need to normalize?
 To avoid redundancy (less storage space
needed, and data is consistent)
To avoid update/delete anomalies.
Organize data efficiently
Prepared by Feven T. Chap 5 2
Functional Dependencies
A functional dependency occurs when the value of one (a
set of) attribute(s) determines the value of a second (set
of) attribute(s) in the same table.
StudentID  StudentName
StudentID  (DormName, DormRoom, Fee)
The attribute on the left side of the functional dependency
is called the determinant.
Function dependencies are not equations!

Prepared by Feven T . Chap 5 3

Characteristics of Functional Dependencies
Diagrammatic representation

Determinant
Attribute or group of attributes on left-hand side of
arrow.

Prepared by Feven T. Chap 5 4

Composite determinant: A determinant of
a functional dependency that consists of more
than one attribute
(StudentName, ClassName) 
(Grade)
Functional Dependency Rules
If A  (B, C), then A  B and A C
If (A,B)  C, then neither A nor B determines
C by itself.

Prepared by Feven T. Chap 5 5

An Example Functional Dependency

Prepared by Feven T. Chap 5 6

Example Functional Dependency that holds
for all Time
EmpNum EmpEmail EmpFname EmpLname
123 [email protected] John Doe
456 [email protected] Peter Smith
555 [email protected] Alan Lee
633 [email protected] Peter Doe
787 [email protected] Alan Lee

If EmpNum is the PK then the

FDs:
EmpNum  EmpEmail
EmpNum  EmpFname
EmpNum  EmpLname
must exist.

Prepared by Feven T. Chap 5 7

Functional Dependencies
EmpNum  EmpEmail
EmpNum  EmpFname 3 different ways
EmpNum  EmpLname you might see FDs
depicted

EmpEmail
EmpNum EmpFname

EmpLname

EmpNum EmpEmail EmpFname

EmpLname

Prepared by Feven T. Chap 5 8

Transitive dependency
Transitive dependency

Consider attributes A, B, and C, and where

A  B and B  C.
Functional dependencies are transitive, which means that we also
have the functional dependency AC
We say that C is transitively dependent on A through B.

Prepared by Feven T. Chap 5 9

Transitive dependency
EmpNum  DeptNum
EmpNum EmpEmail DeptNum DeptNname

DeptNum  DeptName

EmpNum EmpEmail DeptNum DeptNname

DeptName is transitively dependent on EmpNum via DeptNum

EmpNum  DeptName

Prepared by Feven T. Chap 5 10

Partial dependency
A partial dependency exists when an attribute B is
functionally dependent on an attribute A, and A is a
component of a multipart candidate key.

InvNum LineNum Qty InvDate

Candidate keys: {InvNum, LineNum} InvDate is partially

dependent on {InvNum, LineNum} as InvNum is a
determinant of InvDate and InvNum is part of a
candidate key

Prepared by Feven T. Chap 5 11

Multivaled Dependencies
A multivaled dependency occurs when a determinant
determines a particular set of values:
Employee  Degree
Employee  Sibling
PartKit  Part

The determinant of a multivaled dependency can never be a

primary key

Prepared by Feven T. Chap 5 12

Characteristics of Functional
Dependencies
Determinants should have minimal number of
attributes necessary to maintain functional
dependency with attribute(s) on right hand-side
Called full functional dependency.
Full functional dependency indicates that if A and
B are attributes of relation, B is fully functionally
dependent on A, if B is functionally dependent on A,
but not on any proper subset of A.

Prepared by Feven T. Chap 5 13

Example Full Functional Dependency
Exists in the Staff relation

staffNo, sName → branchNo

Each value of (staffNo, sName) is associated with single

value of branchNo
branchNo also functionally dependent on subset of
(staffNo, sName)
(staffNo, sName) - partial dependency

Prepared by Feven T. Chap 5 14

Con’t....
Main characteristics of functional dependencies used in
normalization:
One-to-one relationship between attribute(s) on left-hand
side (determinant) and right-hand side of functional
dependency
Determinant has minimal number of attributes necessary to
maintain dependency with attribute(s) on right hand-side

Prepared by Feven T. Chap 5 15

Normalization
Normalization: The process of decomposing
unsatisfactory "bad" relations by breaking up
their attributes into smaller relations.
Normal form: Condition using keys and FDs
of a relation to certify whether a relation
schema is in a particular normal form

Prepared by Feven T. Chap 5 16

Normal Forms: Review
Unnormalized – There are multivalued
attributes or repeating groups
1 NF – No multivalued attributes or
repeating groups.
2 NF – 1 NF plus no partial dependencies
3 NF – 2 NF plus no transitive
dependencies

Prepared by Feven T. Chap 5 17

First Normal Form (1NF)
All attributes are atomic(no repeating groups).
Disallows composite attributes, multivalued
attributes, and nested relations; attributes whose values
for an individual tuple are non-atomic
Values must be simple.
Remove horizontal redundancies
No two columns hold the same information
No single column holds more than a single item

Prepared by Feven T. Chap 5 18

Con’t…
Each row must be unique
Use a primary key
Benefits
Easier to query/sort the data
More scalable
Each row can be identified for updating

Prepared by Feven T. Chap 5 19

First Normal Form
The following in not in 1NF

EmpNum EmpPhone EmpDegrees

123 233-9876
333 233-1231 BA, BSc, PhD
679 233-1231 BSc, MSc

EmpDegrees is a multi-valued field:

employee 679 has two degrees: BSc and MSc
employee 333 has three degrees: BA, BSc, PhD

To obtain 1NF relations without loss of information, replace the

above with two relations

Prepared by Feven T. Chap 5 20

First Normal Form
EmployeeDegree
Employee
EmpNum EmpDegree
EmpNum EmpPhone
333 BA
123 233-9876
333 BSc
333 233-1231
333 PhD
679 233-1231
679 BSc

679 MSc

An outer join between Employee and EmployeeDegree will

produce the information we saw before

Prepared by Feven T. Chap 5 21

Second Normal Form (2NF)
Table must be in First Normal Form
Remove vertical redundancy
The same value should not repeat
across rows
Composite keys
• All columns in a row must refer to
BOTH parts of the key
Benefits
• Increased storage efficiency
• Less data repetition
All non-key attributes are fully dependent on the
PK (“no partial dependencies”)
 A relation in 2NF will not have any partial
dependencies.
Prepared by Feven T. Chap 5 22
Second Normal Form (2NF)

This table has a composite primary key [Customer ID, Store ID].
The non-key attribute is [Purchase Location]. In this case,
[Purchase Location] only depends on [Store ID], which is only
part of the primary key. Therefore, this table does not satisfy
second normal form.

Prepared by Feven T. Chap 5 23

Second Normal Form (2NF)
To bring this table to second normal form, we break the table into two
tables, and now we have the following:

What we have done is to remove the partial functional dependency that we

initially had. Now, in the table [TABLE_STORE], the column [Purchase
Location] is fully dependent on the primary key of that table, which is [Store
ID].

Prepared by Feven T. Chap 5 24

Third Normal Form (3NF)

• A relation in 3NF will not have any transitive dependencies of

non-key attribute on a candidate key through another non-key
attribute.
Table must be in Second Normal Form
If your table is 2NF, there is a good chance it is 3NF
All columns must relate directly to the primary key
Benefits
No extraneous data

Prepared by Feven T. Chap 5 25

Third Normal Form
Consider this Employee relation
Candidate
keys are? …
EmpNum EmpName DeptNum DeptName

EmpName, DeptNum, and DeptName are non-key attributes.

DeptNum determines DeptName, a non-key attribute, and
DeptNum is not a candidate key.

Is the relation in 3NF? … no

Is the relation in 2NF? … yes

Prepared by Feven T. Chap 5 26

Third Normal Form

EmpNum EmpName DeptNum DeptName

We correct the situation by decomposing the original relation into

two 3NF relations. Note the decomposition is lossless.

EmpNum EmpName DeptNum DeptNum DeptName

Verify these two relations are in 3NF.

Prepared by Feven T. Chap 5 27

Reading Assignment
Boyce Code Normal Form

Prepared by Feven T. Chap 5 28