Database Normalization

2. DATABASE NORMALIZATION
Presented by:
Group#01
Section:B

3. -::Scheme of Presentation::-
• Database Normalization (Intro)
• Data Anomalies and causes
• History/Overview
• Quick review to DBMS Keys
• All Forms of Normalization
• Conclusion
• References
• Q & A

4. -::Database Normalization::-
• The main goal of Database Normalization is to
restructure the logical data model of a
database to:
• Eliminate redundancy (Reduced memory
usage )
• Organize data efficiently
• Allows faster access (dependencies make sense)
• Reduce the potential for data anomalies.

5. -::Data Anomalies::-
• Data anomalies are inconsistencies in the data stored
in a database as a result of an operation such as
update, insertion, and/or deletion.
• Such inconsistencies may arise when have a
particular record stored in multiple locations and not
all of the copies are updated.
• We can prevent such anomalies by implementing 7
different level of normalization called Normal Forms
(NF)
• We’ll look at all of them briefly. 

6. -::Brief History/Overview::-
• Database Normalization was first proposed by Edgar F. Codd.
• In order to do normalization we must know what the
requirements are for each of the each Normal Forms that
we’ll go over.
• One of the key requirements to remember is that Normal
Forms are progressive. That is, in order to have 3rd NF we
must have 2nd NF and in order to have 2nd NF we must have 1st
NF.

7. -::(I) Super Key::-
• (I) Super Key – An attribute or a combination of attribute
that is used to identify the records uniquely is known as
Super Key. A table can have many Super Keys.
E.g. of Super Key
1 ID
2 ID, Name
3 ID, Address
4 ID, Department_ID
5 ID, Salary
6 Name, Address
7 Name, Address, Department_ID ………… So on as any
combination which can identify the records uniquely will be
a Super Key.

8. -::(II) Candidate Key::-
• (II) Candidate Key – It can be defined as
minimal Super Key or irreducible Super Key.
• E.g. of Candidate Key
1 Code
2 Name, Address

9. -::(III) Primary Key::-
• (III) Primary Key – A Candidate Key that is
used by the database designer for unique
identification of record Primary Key. A Primary
Key can consist of one attribute of a table.
E.g. of Primary Key - Database designer can
use one of the Candidate Key as a Primary Key.
In this case we have “Code” and “Name,
Address” as Candidate Key, we will consider
“Code” Key as a Primary Key.

10. -::(IV) Foreign Key::-
• (IV) Foreign Key – A foreign key is an attribute or
combination of attribute in one base table that
points to the candidate key (generally it is the
primary key) of another table. The purpose of the
foreign key is to ensure referential integrity of the
data i.e. only values that are supposed to appear
in the database are permitted.
E.g. of Foreign Key –
Such as if we have two tables one for employee
and 2nd for Manager, the key that relates each
other is called Foreign Key.

11. -::(V) Alternate Key::-
• (VI) Alternate Key – Alternate Key can be any
of the Candidate Keys except for the Primary
Key.
E.g. of Alternate Key is “Name, Address” as it
is the only other Candidate Key which is not a
Primary Key.

12. -::(VI) Secondary Key::-
• (VII) Secondary Key – Is used for
Identification of Rows but not usually Unique,
We can have multiple Secondary Key per
table.
E.g. of Secondary Key can be Name, Address,
Salary, Department_ID etc. as they can
identify the records but they might not be
unique.

13. -::1st Normal Form::-
-::The Requirements::-
• First normal form (INF) is now considered to be
part of the formal definition of a relation in the
basic (flat) relational model;12 historically, it was
defined to disallow multivalued attributes,
composite attributes, and their combinations. It
states that the domain of an attribute must
include only atomic (simple, indivisible) values
and that the value of any attribute in a tuple must
be a single value from the domain of that
attribute. Hence, INF disallows having a set of
values, a tuple of values, or a combination of
both as an attribute value for a single tuple.

15. • Remove the attribute DLOCATIONS that
violates 1NF and place it in a separate relation
DEPT_LOCATIONS along with the primary key
DNUMBER of DEPARTMENT. The primary key
of this relation is the combination {DNUMBER,
DLOCATION}, A distinct tuple in
DEPT_LOCATIONS exists for each location of a
department. This decomposes the non-1NF
relation into two 1NFrelations.

16. -::2nd Normal Form::-
-::The Requirements::-
• Second normal form (2NF) is based on the
concept of full functional dependency. A
functional dependency X -7 Y is a full functional
dependency if removal of any attribute A from X
means that the dependency does not hold any
more; that is, for any attribute A E X, (X - {A}) does
not functionally determine Y.A functional
dependency X -7 Y is a partial dependency if some
attribute A E X can be removed from X and the
dependency still holds; that is, for some A E X, (X -
{A}) -7 Y.

18. • Definition: A relation schema R is in second
normal form (2NF) if every nonprime attribute
A in R is not partially dependent on any key of
R.

19. -::3rd Normal Form::-
-::The Requirements::-
• Third normal form (3NF) is based on the
concept of transitive dependency. A functional
dependency X -> Y in a relation schema R is a
transitive dependency if there is a set of
attributes Z that is neither a candidate key nor
a subset of any key of R, and both X -> Z and
Z->Y hold.

20. Definition: A relation schema R is in third normal form (3NF) if, whenever a
nontrivial functional dependency X ->A holds in R, either
(a) X is a superkey of R, or
(b) A is a prime attribute of R.

22. -::Boyce-Codd Normal Form::-
Definition. A relation schema R is in BCNF if
whenever a nontrivial functionaldependency X-> A
holds in R, when X is a superkey of R.

24. -::Conclusion::-
• We have seen how Database Normalization
can decrease redundancy, increase efficiency
and reduce anomalies by implementing three
of seven different levels of normalization
called Normal Forms. The first three NF’s are
usually sufficient for most small to medium
size applications.

25. -::References::-
• Hillyer Mike, MySQL AB. An Introduction to Database Normalization,
http://dev.mysql.com/tech-resources/articles/intro-to-normalization.html,
accessed October 17, 2006.
• Microsoft. Description of the database normalization basics,
http://support.microsoft.com/kb/283878 , accessed October 17, 2006.
• Wikipedia. Database Normalization.
http://en.wikipedia.org/wiki/Database_normalization.html , accessed October 17,
2006.