database normalisation feel free to copy :)

1. The theory of
Relational Database Design
Prepared by:
AUHAMMAD
MUZAFFAR

2. Table of Content
 Introduction
 Advantages and Disadvantages of
Normalization
 Update anomalies
 Sample anomalies
 Better design
 Boyce-Codd Normal Form
 Determinants
 Other Normal Forms
 END

3. Introduction
 Normalisation is a theory for designing
relational schema that “make sense” and
work well.
 Well-normalised tables avoid redundancy
and thereby reduce inconsistencies.
 Redundancy is unnecessary duplication.
 In well-normalised DBs semantic
dependencies are maintained by primary
key uniqueness.

4. Advantages and
Disadvantages of
Normalization
 Advantages:
 1. You won't have redundancy(same data stored many times in
same/different tables).
 2. You will be away from all the update anomalies and there by you
won't have any loss of data or inefficient data update process.
 3. You will have a well organized database where all the tables are
inter-related maintaining integrity and consistency of data.
 4. Your data all are stored efficiently since there is no redundency.
 5. The entire database system remains consistent over time as the
database grows with least redundancy and much durability.
 Disadvantages:
 1. Maintaining more tables is a bit messier.
 2. Nested queries over multiple tables gets tricky.

5. Update anomalies
 Undesirable side-effects that occur
when performaing insertion, modification
or deletion operations on badly designed
relational DBs.
SSN
987
654
333
321
678
467
Name
J Smith
M Burke
A Dolan
K Doyle
O O’Neill
R McKay
Dept
1
2
1
1
3
2
DeptMgr
321
467
321
321
678
467
Dept
Name
…
...
Representing
Department info
in the Employee
table causes
problems.

6. Sample anomalies
 Modification -
 when the manager of a dept changes we have to
change many values.
 If we are not careful the DB will contain
inconsistencies.
 There is no easy way to get the DB to ensure that a
department has only one manager and only one
name.
 Deletion -
 if O O’Neill leaves we delete his tuple and lose
○ the fact that there is a department 3
○ the name of dept 3
○ who is the manager of dept. 3
 Insertion
 how would we create a new department before any
employees are assigned to it ?

7. Better design
 Separate entities are represented in
separate tables.
SSN
987
654
333
321
678
467
Name
J Smith
M Burke
A Dolan
K Doyle
O O’Neill
R McKay
Dept
1
2
1
1
3
2
Dept
1
2
3
DeptMgr
321
467
678
Dept
Name
…
...
Note that mapping from an ER model
following the steps given will give a well-
normalised DB.

8. Boyce-Codd Normal Form
 After a lot of other approaches Boyce
and Codd noticed a simple rule for
ensuring tables are well-normalised.
Tables which obey the rule are in BCNF
(Boyce Codd Normal Form).
 BCNF rule:
 Every determinant in a table must be a
candidate key for that table.

9. Determinants
 A is a determinant of B if each value of
A has precisely one (possibly null)
associated value of B.
Said another way -
 A is a determinant of B if and only if
whenever two tuples agree on their A
value they agree on their B value.
A B

10. Determinants Continue…
 Note that determinancy depends on
semantics of data
 cannot be decided from individual table
occurences.
 Alternative terminology
 if A (functionally) determines B then
 B is (functionally) dependent on A

11. Example of Determinants
 SSN determines employee name
 SSN determines employee department
 Dept. No. determines Dept. Name
 Dept. Name determines Dept. No.
 assuming Dept. names are also unique
 Emp. Name does not determine Emp.
Dept
 two John Smiths could be in difft. Depts.
 Emp. Name does not determine SSN.

12. Other Normal Forms
 First NF - no multi-valued attributes
 all relational DBs are 1NF
 2NF - every non-key attribute is fully
dependent on the primary key
 3NF - eliminate functional dependencies
between non-key attributes
 all dependencies can then be enforced by
uniqueness of keys.
G H J
Table is in 2NF
but not 3NF

13. END