The document discusses database normalization and its goals. Normalization is the process of structuring data into tables to reduce redundancy and dependency. It explains 1st, 2nd, and 3rd normal form. 1st NF requires each field contain a single value. 2nd NF eliminates redundant data where non-key fields depend on whole primary key. 3rd NF removes fields that depend on other non-prime fields, rather than just the primary key. Examples show how to normalize tables by splitting into multiple tables to conform with these forms.

1. Functional Dependencies and
Normalization for Relational
Databases
Dr.Sanu Kumar Basak
Banaras Hindu University

2. What is Normalization?
Unnormalized data exists in flat files
Normalization is the process of moving
data into related tables
This is usually done by running action
queries (Make Table and Append
queries)….unless you’re starting from
scratch – then do it right the first time!

3. Why Normalize Tables?
 Save typing of repetitive data
 Increase flexibility to query, sort, summarize,
and group data (Simpler to manipulate data!)
 Avoid frequent restructuring of tables and
other objects to accommodate new data
 Reduce disk space

4. A Typical Spreadsheet File
Emp No Employee Name Time Card No Time Card Date Dept No Dept Name
10 Thomas Arquette 106 11/02/2002 20 Marketing
10 Thomas Arquette 106 11/02/2002 20 Marketing
10 Thomas Arquette 106 11/02/2002 20 Marketing
10 Thomas Arquette 115 11/09/2002 20 Marketing
99 Janice Smitty 10 Accounting
500 Alan Cook 107 11/02/2002 50 Shipping
500 Alan Cook 107 11/02/2002 50 Shipping
700 Ernest Gold 108 11/02/2002 50 Shipping
700 Ernest Gold 116 11/09/2002 50 Shipping
700 Ernest Gold 116 11/09/2002 50 Shipping

5. Employee, Department, and Time Card Data
in Three Tables
EmpNo EmpFirstName EmpLastName DeptNo
10 Thomas Arquette 20
500 Alan Cook 50
700 Ernest Gold 50
99 Janice Smitty 10
TimeCardNo EmpNo TimeCardDate
106 10 11/02/2002
107 500 11/02/2002
108 700 11/02/2002
115 10 11/09/2002
116 700 11/09/2002
Table: Employees
Table: Time Card Data
DeptNo DeptName
10 Accounting
20 Marketing
50 Shipping
Table: Departments
Primary Key

6. Semantics of the Relation
Attributes
 Each tuple in a relation should represent one entity
or relationship instance
 Only foreign keys should be used to refer to other
entities
 Entity and relationship attributes should be kept apart as
much as possible
 Design a schema that can be explained easily relation by
relation. The semantics of attributes should be easy to
interpret.

9. Redundant Information in
Tuples and Update
Anomalies
 Mixing attributes of multiple entities may
cause problems
 Information is stored redundantly wasting
storage
 Problems with update anomalies:
 Insertion anomalies
 Deletion anomalies
 Modification anomalies

12. EXAMPLE OF AN UPDATE
ANOMALY
Consider the relation:
EMP_PROJ ( Emp#, Proj#, Ename, Pname, No_hours)
 Update Anomaly
 Changing the name of project number P1 from “Billing” to
“Customer-Accounting” may cause this update to be made for all
100 employees working on project P1
 Insert Anomaly
 Cannot insert a project unless an employee is assigned to .
 Inversely- Cannot insert an employee unless he/she is assigned to
a project.

13. EXAMPLE OF AN UPDATE
ANOMALY (2)
 Delete Anomaly
 When a project is deleted, it will result in deleting all the
employees who work on that project. Alternately, if an employee
is the sole employee on a project, deleting that employee would
result in deleting the corresponding project.
 Design a schema that does not suffer from the
insertion, deletion and update anomalies. If there
are any present, then note them so that applications
can be made to take them into account

14. Null Values in Tuples
 Relations should be designed such that their tuples
will have as few NULL values as possible
 Attributes that are NULL frequently could be placed in
separate relations (with the primary key)
 Reasons for nulls:
 a. attribute not applicable or invalid
 b. attribute value unkown (may exist)
 c. value known to exist, but unavailable

15. Spurious Tuples
 Bad designs for a relational database may result in
erroneous results for certain JOIN operations
 The "lossless join" property is used to guarantee
meaningful results for join operations
 The relations should be designed to satisfy the
lossless join condition. No spurious tuples should
be generated by doing a natural-join of any
relations

16. Functional Dependencies
 Functional dependencies (FDs) are used to
specify formal measures of the "goodness"
of relational designs
 FDs and keys are used to define normal
forms for relations
 FDs are constraints that are derived from
the meaning and interrelationships of the
data attributes

17. Functional Dependencies (2)
 A set of attributes X functionally determines a set of
attributes Y if the value of X determines a unique value for
Y
 X Y holds if whenever two tuples have the same value for
X, they must have the same value for Y
If t1[X]=t2[X], then t1[Y]=t2[Y] in any relation instance r(R)
 X  Y in R specifies a constraint on all relation instances
r(R)
 FDs are derived from the real-world constraints on the
attributes

18. Examples of FD constraints
 Social Security Number determines employee name
SSN  ENAME
 Project Number determines project name and
location
PNUMBER  {PNAME, PLOCATION}
 Employee SSN and project number determines the
hours per week that the employee works on the
project
{SSN, PNUMBER}  HOURS

19. Functional Dependencies (3)
 An FD is a property of the attributes in the
schema R
 The constraint must hold on every relation
instance r(R)
 If K is a key of R, then K functionally
determines all attributes in R (since we never
have two distinct tuples with t1[K]=t2[K])

20. Inference Rules for FDs
 Given a set of FDs F, we can infer additional FDs
that hold whenever the FDs in F hold
 Armstrong's inference rules
A1. (Reflexive) If Y subset-of X, then X  Y
A2. (Augmentation) If X  Y, then XZ  YZ
(Notation: XZ stands for X U Z)
A3. (Transitive) If X  Y and Y  Z, then X  Z
 A1, A2, A3 form a sound and complete set of
inference rules

21. Additional Useful Inference
Rules
 Decomposition
 If X  YZ, then X  Y and X  Z
 Union
 If X  Y and X  Z, then X  YZ
 Psuedotransitivity
 If X  Y and WY  Z, then WX  Z
 Closure of a set F of FDs is the set F+ of all FDs
that can be inferred from F

22. Introduction to
Normalization
 Normalization: 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
 2NF, 3NF, BCNF based on keys and FDs of a relation
schema
 4NF based on keys, multi-valued dependencies

23. First Normal Form
 Disallows composite attributes, multivalued
attributes, and nested relations; attributes
whose values for an individual tuple are
non-atomic
 Considered to be part of the definition of
relation

24. First Normal Form
 Each field contains the smallest meaningful
value
 The table does not contain repeating groups of
fields or repeating data within the same field
 Create a separate field/table for each set of related data.

Identify each set of related data with a primary key

25. Tables Violating First Normal Form
PART (Primary Key) WAREHOUSE
P0010 Warehouse A, Warehouse B, Warehouse C
P0020 Warehouse B, Warehouse D
PART
(Primary Key)
WAREHOUSE A WAREHOUSE B WAREHOUSE C
P0010 Yes No Yes
P0020 No Yes Yes
Really Bad Set-up!
Better, but still flawed!

26. Table Conforming to First Normal Form
PART
(Primary Key)
WAREHOUSE
(Primary Key) QUANTITY
P0010 Warehouse A 400
P0010 Warehouse B 543
P0010 Warehouse C 329
P0020 Warehouse B 200
P0020 Warehouse D 278

29. Second Normal Form
 Uses the concepts of FDs, primary key
 Definitions:
 Prime attribute - attribute that is member of the
primary key K
 Full functional dependency - a FD Y  Z
where removal of any attribute from Y means the
FD does not hold any more

30. Examples
Second Normal Form
 {SSN, PNUMBER}  HOURS is a full FD since neither
SSN  HOURS nor PNUMBER  HOURS hold
 {SSN, PNUMBER}  ENAME is not a full FD (it is
called a partial dependency ) since SSN  ENAME also
holds
 A relation schema R is in second normal form (2NF) if
every non-prime attribute A in R is fully functionally
dependent on the primary key
 R can be decomposed into 2NF relations via the process
of 2NF normalization

31. Second Normal Form
 usually used in tables with a multiple-field
primary key (composite key)
 each non-key field relates to the entire primary
key
 any field that does not relate to the primary key
is placed in a separate table
 MAIN POINT –
 eliminate redundant data in a table
 Create separate tables for sets of values that apply to
multiple records

32. Table Violating Second Normal
Form
PART
(Primary Key)
WAREHOUSE
(Primary Key) QUANTITY
WAREHOUSE
ADDRESS
P0010 Warehouse A 400 1608 New Field Road
P0010 Warehouse B 543 4141 Greenway Drive
P0010 Warehouse C 329 171 Pine Lane
P0020 Warehouse B 200 4141 Greenway Drive
P0020 Warehouse D 278 800 Massey Street

33. Tables Conforming to Second
Normal Form
PART_STOCK TABLE
PART (Primary Key) WAREHOUSE (Primary Key) QUANTITY
P0010 Warehouse A 400
P0010 Warehouse B 543
P0010 Warehouse C 329
P0020 Warehouse B 200
P0020 Warehouse D 278
WAREHOUSE TABLE
WAREHOUSE (Primary Key) WAREHOUSE_ADDRESS
Warehouse A 1608 New Field Road
Warehouse B 4141 Greenway Drive
Warehouse C 171 Pine Lane
Warehouse D 800 Massey Street
1
∞

35. Third Normal Form
 Definition
 Transitive functional dependency – if there a set of
atribute Z that are neither a primary or candidate key and
both X  Z and Y  Z holds.
 Examples:
 SSN  DMGRSSN is a transitive FD since
SSN  DNUMBER and DNUMBER  DMGRSSN hold
 SSN  ENAME is non-transitive since there is no set
of
attributes X where SSN  X and X  ENAME

36. 3rd
Normal Form
A relation schema R is in third normal form
(3NF) if it is in 2NF and no non-prime
attribute A in R is transitively dependent on
the primary key

37. Table Violating Third Normal
Form
MPLOYEE_DEPARTMENT TABLE
EMPNO
(Primary Key)
FIRSTNAME LASTNAME WORKDEPT DEPTNAME
000290 John Parker E11 Operations
000320 Ramlal Mehta E21 Software Support
000310 Maude Setright E11 Operations

38. Tables Conforming to Third
Normal Form
EMPLOYEE TABLE
EMPNO (Primary Key) FIRSTNAME LASTNAME WORKDEPT
000290 John Parker E11
000320 Ramlal Mehta E21
000310 Maude Setright E11
DEPARTMENT TABLE
DEPTNO (Primary Key) DEPTNAME
E11 Operations
E21 Software Support
1
∞

39. Example 1
 Un-normalized Table:
Student# Advisor# Advisor Adv-Room Class1 Class2 Class3
1022 10 Susan Jones 412 101-07 143-01 159-02
4123 12 Anne Smith 216 101-07 159-02 214-01

40.  Table in First Normal Form
 No Repeating Fields
 Data in Smallest Parts
Student# Advisor# AdvisorFName AdvisorLName
Adv-
Room
Class#
1022 10 Susan Jones 412 101-07
1022 10 Susan Jones 412 143-01
1022 10 Susan Jones 412 159-02
4123 12 Anne Smith 216 101-07
4123 12 Anne Smith 216 159-02
4123 12 Anne Smith 216 214-01

41.  Tables in Second Normal Form
 Redundant Data Eliminated
Student# Advisor# AdvFirstName AdvLastName
Adv-
Room
1022 10 Susan Jones 412
4123 12 Anne Smith 216
Table: Students
Student# Class#
1022 101-07
1022 143-01
1022 159-02
4123 201-01
4123 211-02
4123 214-01
Table: Registration

42.  Tables in Third Normal Form
 Data Not Dependent On Key is Eliminated
Student# Advisor# StudentFName StudentLName
1022 10 Jane Mayo
4123 12 Mark Baker
Table: Students
Student# Class#
1022 101-07
1022 143-01
1022 159-02
4123 201-01
4123 211-02
4123 214-01
Table: RegistrationAdvisor# AdvFirstName AdvLastName
Adv-
Room
10 Susan Jones 412
12 Anne Smith 216
Table: Advisors

43. Example 2
 Un-normalized Table:
EmpID Name Dept
Code
Dept Name Proj 1 Time
Proj 1
Proj 2 Time
Proj 2
Proj 3 Time
Proj 3
EN1-26 Sean Breen TW Technical Writing 30-T3 25% 30-TC 40% 31-T3 30%
EN1-33 Amy Guya TW Technical Writing 30-T3 50% 30-TC 35% 31-T3 60%
EN1-36 Liz Roslyn AC Accounting 35-TC 90%

44. Table in First Normal Form
EmpID Project
Number
Time on
Project
Last
Name
First
Name
Dept
Code
Dept Name
EN1-26 30-T3 25% Breen Sean TW Technical Writing
EN1-26 30-TC 40% Breen Sean TW Technical Writing
EN1-26 31-T3 30% Breen Sean TW Technical Writing
EN1-33 30-T3 50% Guya Amy TW Technical Writing
EN1-33 30-TC 35% Guya Amy TW Technical Writing
EN1-33 31-T3 60% Guya Amy TW Technical Writing
EN1-36 35-TC 90% Roslyn Liz AC Accounting

45. Tables in Second Normal Form
EmpID Project
Number
Time on
Project
EN1-26 30-T3 25%
EN1-26 30-T3 40%
EN1-26 31-T3 30%
EN1-33 30-T3 50%
EN1-33 30-TC 35%
EN1-33 31-T3 60%
EN1-36 35-TC 90%
Table: Employees and
Projects EmpID Last
Name
First
Name
Dept
Code
Dept Name
EN1-26 Breen Sean TW Technical Writing
EN1-33 Guya Amy TW Technical Writing
EN1-36 Roslyn Liz AC Accounting
Table: Employees

46. Tables in Third Normal Form
Dept Code Dept Name
TW Technical Writing
AC Accounting
EmpID Project
Number
Time on
Project
EN1-26 30-T3 25%
EN1-26 30-T3 40%
EN1-26 31-T3 30%
EN1-33 30-T3 50%
EN1-33 30-TC 35%
EN1-33 31-T3 60%
EN1-36 35-TC 90%
Table:
Employees_and_Projects EmpID Last
Name
First
Name
Dept
Code
EN1-26 Breen Sean TW
EN1-33 Guya Amy TW
EN1-36 Roslyn Liz AC
Table: Departments
Table: Employees

47. Example 3
EmpID Name Manager Dept Sector Spouse/Children
285 Carl
Carlson
Smithers Engineering 6G
365 Lenny Smithers Marketing 8G
458 Homer
Simpson
Mr. Burns Safety 7G Marge, Bart, Lisa, Maggie
• Un-normalized Table:

48. Table in First Normal Form
Fields contain smallest meaningful values
EmpID FName LName Manager Dept Sector Spouse Child1 Child2 Child3
285 Carl Carlson Smithers Eng. 6G
365 Lenny Smithers Marketing 8G
458 Homer Simpson Mr. Burns Safety 7G Marge Bart Lisa Maggie

49. Table in First Normal Form
No more repeated fields
EmpID FName LName Manager Department Sector Dependent
285 Carl Carlson Smithers Engineering 6G
365 Lenny Smithers Marketing 8G
458 Homer Simpson Mr. Burns Safety 7G Marge
458 Homer Simpson Mr. Burns Safety 7G Bart
458 Homer Simpson Mr. Burns Safety 7G Lisa
458 Homer Simpson Mr. Burns Safety 7G Maggie

50. Second/Third Normal Form
Remove Repeated Data From Table Step 1
EmpID FName LName Manager Department Sector
285 Carl Carlson Smithers Engineering 6G
365 Lenny Smithers Marketing 8G
458 Homer Simpson Mr. Burns Safety 7G
EmpID Dependent
458 Marge
458 Bart
458 Lisa
458 Maggie

51. Tables in Second Normal Form
EmpID FName LName ManagerID Dept Sector
285 Carl Carlson 2 Engineering 6G
365 Lenny 2 Marketing 8G
458 Homer Simpson 1 Safety 7G
EmpID Dependent
458 Marge
458 Bart
458 Lisa
458 Maggie
ManagerID Manager
1 Mr. Burns
2 Smithers
Removed Repeated Data From Table
Step 2

52. Tables in Third Normal Form
EmpID FName LName DeptCode
285 Carl Carlson EN
365 Lenny MK
458 Homer Simpson SF
EmpID Dependent
458 Marge
458 Bart
458 Lisa
458 Maggie
ManagerID Manager
1 Mr. Burns
2 Smithers
DeptCode Department Sector ManagerID
EN Engineering 6G 2
MK Marketing 8G 2
SF Safety 7G 1
Employees Table
Dependents Table
Department Table
Manager Table

53. BCNF (Boyce-Codd Normal
Form)
 A relation schema R is in Boyce-Codd Normal
Form (BCNF) if whenever an FD X  A holds in
R, then X is a superkey of R
 Each normal form is strictly stronger than the previous
one:
 Every 2NF relation is in 1NF
 Every 3NF relation is in 2NF
 Every BCNF relation is in 3NF
 There exist relations that are in 3NF but not in BCNF
 The goal is to have each relation in BCNF (or 3NF)

55. BCNF
 {Student,course}  Instructor
 Instructor  Course
 Decomposing into 2 schemas
 {Student,Instructor} {Student,Course}
 {Course,Instructor} {Student,Course}
 {Course,Instructor} {Instructor,Student}

56. BCNF vs 3NF
 BCNF: For every functional dependency X->Y in a set
F of functional dependencies over relation R, either:
 Y is a subset of X or,
 X is a superkey of R
 3NF: For every functional dependency X->Y in a set F
of functional dependencies over relation R, either:
 Y is a subset of X or,
 X is a superkey of R, or
 Y is a subset of K for some key K of R

57. 3NF Schema
Account Client Office
A Joe 1
B Mary 1
A John 1
C Joe 2
For every functional
dependency X->Y in a set F
of functional dependencies
over relation R, either:
– Y is a subset of X or,
– X is a superkey of R, or
– Y is a subset of K for
some key K of R Client, Office -> Client, Office, Account
Account -> Office

58. 3NF Schema
Account Client Office
A Joe 1
B Mary 1
A John 1
C Joe 2
For every functional
dependency X->Y in a set F
of functional dependencies
over relation R, either:
– Y is a subset of X or,
– X is a superkey of R, or
– Y is a subset of K for
some key K of R
Client, Office -> Client, Office, Account
Account -> Office

59. BCNF vs 3NFFor every functional
dependency X->Y in a set F
of functional dependencies
over relation R, either:
 Y is a subset of X or,
 X is a superkey of R
 Y is a subset of K for
some key K of R
3NF has some redundancy
BCNF does not. Unfortunately, BCNF is
not dependency preserving, but 3NF is
Client, Office -> Client, Office, Account
Account -> Office
Account Client Office
A Joe 1
B Mary 1
A John 1
C Joe 2
Account Office
A 1
B 1
C 2
Account Client
A Joe
B Mary
A John
C Joe
Account -> Office
No non-trivial FDs
Lossless
decomposition