8/6/2019 Normalization Forms - Intro to Db
1/24
8/6/2019 Normalization Forms - Intro to Db
2/24
Tanvir Ahmed 2
Well-Structured Relations A relation that contains minimal data redundancy
and allows users to insert, delete, and update rowswithout causing data inconsistencies
Goal is to avoid anomalies
Insertion Anomaly adding new rows forces user tocreate duplicate data
Deletion Anomaly deleting rows may cause a loss ofdata that would be needed for other future rows
Modification Anomaly changing data in a row forceschanges to other rows because of duplication
General rule of thumb: a table should not pertain to
more than one entity type
8/6/2019 Normalization Forms - Intro to Db
3/24
Tanvir Ahmed 3
Example Figure 5.2b
Question Is this a relation? Answer Yes: unique rows and no multivaluedattributes
Question Whats the primary key? Answer Composite: Emp_ID,Course_Title
8/6/2019 Normalization Forms - Intro to Db
4/24
Tanvir Ahmed 4
Anomalies in this Table
Insertion cant enter a new employee without
having the employee take a class
Deletion if we remove employee 140, we lose
information about the existence of a Tax Acc class
Modification giving a salary increase to
employee 100 forces us to update multiple records
Why do these anomalies exist?
Because weve combined two themes (entity types)
into one relation. This results in duplication, and an
unnecessary dependency between the entities
8/6/2019 Normalization Forms - Intro to Db
5/24
Tanvir Ahmed 5
8/6/2019 Normalization Forms - Intro to Db
6/24
Tanvir Ahmed 6
8/6/2019 Normalization Forms - Intro to Db
7/24
Tanvir Ahmed 7
8/6/2019 Normalization Forms - Intro to Db
8/24
Tanvir Ahmed 8
8/6/2019 Normalization Forms - Intro to Db
9/24
Tanvir Ahmed 9
8/6/2019 Normalization Forms - Intro to Db
10/24
Tanvir Ahmed 10
8/6/2019 Normalization Forms - Intro to Db
11/24
Tanvir Ahmed 11
8/6/2019 Normalization Forms - Intro to Db
12/24
Tanvir Ahmed 12
8/6/2019 Normalization Forms - Intro to Db
13/24
Tanvir Ahmed 13
Functional Dependencies and Keys
Functional Dependency: The value of oneattribute (the determinant) determines thevalue of another attribute
Candidate Key: A unique identifier. One of the candidate keys
will become the primary key
E.g. perhaps there is both credit card number andSS# in a tablein this case both are candidate keys
Each non-key field is functionally dependent onevery candidate key
8/6/2019 Normalization Forms - Intro to Db
14/24
Tanvir Ahmed 14
5.22 -Steps in
normalization
8/6/2019 Normalization Forms - Intro to Db
15/24
Tanvir Ahmed 15
First Normal Form
No multivalued attributes
Every attribute value is atomic
Fig. 5-2a is notin 1st
Normal Form(multivalued attributes) it is not arelation
Fig. 5-2b is in 1st
Normal form All relations are in 1st Normal Form
8/6/2019 Normalization Forms - Intro to Db
16/24
Tanvir Ahmed 16
Second Normal Form
1NFplus every non-key attribute is fullyfunctionally dependent on the ENTIREprimary key
Every non-key attribute must be defined by theentire key, not by only part of the key
No partial functional dependencies
Fig. 5-2b is NOT in 2nd
Normal Form (seefig 5-23b)
8/6/2019 Normalization Forms - Intro to Db
17/24
Tanvir Ahmed 17
Fig 5.23(b) Functional Dependencies
in EMPLOYEE2
EmpID CourseTitle DateCompletedSalaryDeptNameName
Dependency on entire primary key
Dependency on only partof the key
EmpID, CourseTitle DateCompletedEmpID Name, DeptName, Salary
Therefore, NOT in 2nd Normal Form!!
8/6/2019 Normalization Forms - Intro to Db
18/24
Tanvir Ahmed 18
Getting it into 2ndNormal Form
See p193 decomposed into two separaterelations
EmpID SalaryDeptNameName
CourseTitle DateCompletedEmpID
Both are fullfunctional
dependencies
8/6/2019 Normalization Forms - Intro to Db
19/24
Tanvir Ahmed 19
Third Normal Form 2NF PLUS no transitive dependencies
(one attribute functionally determines a
second, which functionally determines a
third)
Fig. 5-24, 5-25
8/6/2019 Normalization Forms - Intro to Db
20/24
8/6/2019 Normalization Forms - Intro to Db
21/24
Tanvir Ahmed 21
Figure 5-24(b) Relation with transitive dependency
CustID Name
CustID SalespersonCustID Region
All this is OK
(2nd NF)
BUTCustID Salesperson Region
Transitive dependency
(not 3rdNF)
8/6/2019 Normalization Forms - Intro to Db
22/24
Tanvir Ahmed 22
Figure 5.25 -- Removing a transitive dependency
(a) Decomposing the SALES relation
8/6/2019 Normalization Forms - Intro to Db
23/24
Tanvir Ahmed 23
Figure 5.25(b) Relations in 3NF
Now, there are no transitive dependencies
Both relations are in 3rd NF
CustID Name
CustID
Salesperson
Salesperson Region
8/6/2019 Normalization Forms - Intro to Db
24/24
Tanvir Ahmed 24
Other Normal Forms
(from Appendix B) Boyce-Codd NF
All determinants are candidate keysthere is no determinantthat is not a unique identifier
4thNF No multivalued dependencies
5thNF
No lossless joins
Domain-key NF The ultimate NFperfect elimination of all possible
anomalies