References

1. http://www.ifis.cs.tu-bs.de/teaching/ss-09/classics
http://databases.about.com/od/specificproducts/a/normalization.htm
Database normalization is the process of organizing the fields and tables of a relational database to minimize
redundancy and dependency. Normalization usually involves dividing large tables into smaller (and less redundant)
tables and defining relationships between them. The objective is to isolate data so that additions, deletions, and
modifications of a field can be made in just one table and then propagated through the rest of the database via the
defined relationships.
Edgar . !odd, the inventor of the relational model, introduced the concept of normalization and what we now "now as
the irst Normal orm (#N) in #$%&.
'#(
!odd went on to define the )econd Normal orm (*N) and Third Normal orm
(+N) in #$%#,
'*(
and !odd and ,aymond . -oyce defined the -oyce.!odd Normal orm (-!N) in #$%/.
'+(
0igher
normal forms were defined by other theorists in subse1uent years, the most recent being the )i2th Normal orm (3N)
introduced by !hris 4ate, 0ugh 4arwen, and Ni"os 5orentzos in *&&*.
'/(
Normalization is the process of efciently organizing data in a database. There are two goals
of the normalization process: eliminating redundant data (for example, storing the same data
in more than one table) and ensuring data dependencies mae sense (only storing related
data in a table). !oth of these are worthy goals as they reduce the amount of space a
database consumes and ensure that data is logically stored.
The Normal Forms
The database community has de"eloped a series of guidelines for ensuring that databases are
normalized. These are referred to as normal forms and are numbered from one (the lowest
form of normalization, referred to as #rst normal form or $N%) through #"e (#fth normal form
or &N%). 'n practical applications, you(ll often see $N%, )N%, and *N% along with the occasional
+N%
Objectives of Normalization
A basic objective of the first normal form defined by Codd in 1970 as to permit data to be
!ueried and manipulated using a 6universal data sub.language6 grounded in first.order logic.
'7(
()85 is an e2ample of such a data sub.language, albeit one that !odd regarded as seriously
flawed.)
'$(
The objectives of normalization beyond #N (irst Normal orm) were stated as follows by !odd9
"he objectives of normalization process are#:
#. To free the collection of relations from undesirable insertion, update and deletion dependencies:
*. To reduce the need for restructuring the collection of relations, as new types of data are introduced, and thus increase the
life span of application programs:
+. To ma"e the relational model more informative to users:
/. To ma"e the collection of relations neutral to the 1uery statistics, where these statistics are liable to change as time goes by.
The Process of Normalization
"he process is based on the analysis of relations$ their schemes$ their primary %eys and their
functional dependencies.
&henever a relation does not meet a normal form test$ the relation must be decomposed or bro%en
don into some other relations that individually meet the criteria of the normal form test .
Free the database of modification anomalies
;hen an attempt is made to modify (update, insert into, or delete from) a table, undesired side.effects may
follow. Not all tables can suffer from these side.effects: rather, the side.effects can only arise in tables that
have not been sufficiently normalized. <n insufficiently normalized table might have one or more of the
following characteristics9
The same information can be e2pressed on
multiple rows: therefore updates to the table may
result in logical inconsistencies. or e2ample, each
record in an 6Employees= )"ills6 table might contain
an Employee >4, Employee <ddress, and )"ill: thus
a change of address for a particular employee will
potentially need to be applied to multiple records
(one for each of his s"ills). >f the update is not
carried through successfully?if, that is, the employee=s address is updated on some records but not
others?then the table is left in an inconsistent
state. )pecifically, the table provides conflicting
answers to the 1uestion of what this particular
employee=s address is. This phenomenon is
"nown as an update anomaly.
There are circumstances in which certain facts
cannot be recorded at all. or e2ample, each
record in a 6aculty and Their !ourses6 table
might contain a aculty >4, aculty Name,
aculty 0ire 4ate, and !ourse !ode?thus we
can record the details of any faculty member
who teaches at least one course, but we cannot
record the details of a newly.hired faculty
member who has not yet been assigned to
<n update anomaly. Employee @#$ is shown as
having different addresses on different records.
< deletion anomaly. <ll information about 4r. Aiddens
is lost when he temporarily ceases to be assigned to
any courses.
<n insertion anomaly. Bntil the new faculty
member, 4r. Newsome, is assigned to teach at least
one course, his details cannot be recorded.
teach any courses e2cept by setting the !ourse !ode to null. This phenomenon is "nown as
an insertion anomaly.
There are circumstances in which the deletion of data representing certain facts necessitates the
deletion of data representing completely different facts. The 6aculty and Their !ourses6 table described
in the previous e2ample suffers from this type of anomaly, for if a faculty member temporarily ceases to
be assigned to any courses, we must delete the last of the records on which that faculty member
appears, effectively also deleting the faculty member. This phenomenon is "nown as a deletion
anomaly.
Background to normalization: definitions
Functional dependency
>n a given table, an attribute Y is said to have a functional dependency on a set of attributes X (written X C Y)
if and only if each X value is associated with precisely one Y value. or e2ample, in an 6Employee6 table that
includes the attributes 6Employee >46 and 6Employee 4ate of -irth6, the functional dependency DEmployee >4E
C DEmployee 4ate of -irthE would hold. >t follows from the previous two sentences that each DEmployee >4E is
associated with precisely one DEmployee 4ate of -irthE.
Trivial functional dependency
< trivial functional dependency is a functional dependency of an attribute on a superset of itself. DEmployee >4,
Employee <ddressE C DEmployee <ddressE is trivial, as is DEmployee <ddressE C DEmployee <ddressE.
Full functional dependency
<n attribute is fully functionally dependent on a set of attributes F if it is9
functionally dependent on '$ and
not functionally dependent on any proper subset of '. ()mployee Address* has a functional
dependency on ()mployee +,$ -%ill*$ but not a full functional dependency$ because it is also
dependent on ()mployee +,*.
Transitive dependency
< transitive dependency is an indirect functional dependency, one in which XCZ only by virtue
of XCY and YCZ.
Multivalued dependency
< multivalued dependency is a constraint according to which the presence of certain rows in a table implies the
presence of certain other rows.
Join dependency
< table T is subject to a join dependency if T can always be recreated by joining multiple tables each having a
subset of the attributes of T.
Superkey
< super"ey is a combination of attributes that can be used to uni1uely identify a database record. < table might
have many super"eys.
Candidate key
< candidate "ey is a special subset of super"eys that do not have any e2traneous information in them9 it is a
minimal super"ey.
E2amples9 >magine a table with the fields GNameH, G<geH, G))NH and GIhone E2tensionH. This table has many
possible super"eys. Three of these are G))NH, GIhone E2tension, NameH and G))N, NameH. Jf those listed, only
G))NH is a candidate "ey, as the others contain information not necessary to uni1uely identify records (=))N= here
refers to )ocial )ecurity Number, which is uni1ue to each person).
Non-prime attribute
< non.prime attribute is an attribute that does not occur in any candidate "ey. Employee <ddress would be a
non.prime attribute in the 6Employees= )"ills6 table.
rime attribute
< prime attribute, conversely, is an attribute that does occur in some candidate "ey.
rimary key
Kost 4-K)s re1uire a table to be defined as having a single uni1ue "ey, rather than a number of possible
uni1ue "eys. < primary "ey is a "ey which the database designer has designated for this purpose.
The main normal forms are summarized below.
Normal form Defined by Brief definition
irst normal
form .1/01
"o versions: ).0. Codd
.19701$ C.2. ,ate .30041
'##(
"able faithfully represents a relation and has no repeating
groups
)econd normal
form .3/01
).0. Codd .19711
'*(
/o non5prime attribute in the table is functionally
dependent on a proper subset of any candidate "ey
Third normal
form .4/01
).0. Codd .197116
'*(
see 7also
Carlo 8aniolo9s e!uivalent but
differently5e:pressed
definition .19;31
'#*(
)very non5prime attribute is non5transitively dependent
on every candidate "ey in the table
Elementary Ley
Normal
orm .)</01
C.8aniolo .19;316
'#+(
)very non5trivial functional dependency in the table is
either the dependency of an elementary %ey attribute or a
dependency on a super%ey
-oyceM!odd normal
form.=C/01
>aymond 0. =oyce and ).0.
Codd .197?1
'#/(
)very non5trivial functional dependency in the table is a
dependency on a super"ey
ourth normal
form .?/01
,onald agin .19771
'#@(
)very non5trivial multivalued dependency in the table is a
dependency on a super%ey
ifth normal
form .@/01
,onald agin .19791
'#3(
)very non5trivial join dependency in the table is implied
by the super%eys of the table
4omainN"ey normal
form.,</01
,onald agin .19;11
'#%(
)very constraint on the table is a logical conse1uence of
the table9s domain constraints and %ey constraints
)i2th normal
form .A/01
!.O. 4ate$ 0ugh 4arwen$
and Ni"os 5orentzos .30031
'/(
"able features no non5trivial join dependencies at all
.ith reference to Beneralized join operator1
First Normal Form
A table is said to be in First Normal Form
(1NF) if and only if every entry of the table .the intersection of ro and column1 has at most a sinBle value.
Cbjective: to remove a table9s repeatinB Broups and ensure that all entries of the resultinB table have at most a sinBle
value.
Eliminate duplicate data!
Definitions of the Normal Forms
1st Normal Form (1NF)
,liminate duplicati"e columns from the same table.
-reate separate tables for each group of related data and identify each row with a uni.ue
column or set of columns (the primary ey).
2nd Normal Form (2NF)
A table is in 2NF if it is in 1NF and if all non-key attributes are dependent on all of the key.
Since a partial dependency occurs when a non-key attribute is dependent on only a part of the composite
key, the definition of 2NF is sometimes phrased as, A table is in 2NF if it is in 1NF and if it has no partial
dependencies.
/eet all the re.uirements of the #rst normal form.
0emo"e subsets of data that apply to multiple rows of a table and place them in separate
tables.
-reate relationships between these new tables and their predecessors through the use
of foreign eys.
3rd Normal Form (3NF)
A table is in NF if it is in 2NF and if it has no transiti!e dependencies.
/eet all the re.uirements of the second normal form.
0emo"e columns that are not dependent upon the primary ey
Boyce-Codd Normal Form (BCNF)
A table is in "#NF if it is in NF and if e!ery determinant is a candidate key
Database Anomaly: Insert , Update Delete
Insert!on Anomaly
$t is a failure to place information about a new database entry into all the places in the database where
information about the new entry needs to be stored. $n a properly normali%ed database, information
about a new entry needs to be inserted into only one place in the database, in an inade&uatly normali%ed
database, information about a new entry may need to be inserted into more than one place, and human
fallibility bein' what it is, some of the needed additional insertions may be missed.
Delet!on Anomaly
$t is a failure to remo!e information about an e(istin' database entry when it is time to remo!e that
entry. $n a properly normali%ed database, information about an old, to-be-'otten-rid-of entry needs to be
deleted from only one place in the database, in an inade&uatly normali%ed database, information about
that old entry may need to be deleted from more than one place.
Update Anomaly
An update of a database in!ol!es modifications that may be additions, deletions, or both. )hus update
anomalies* can be either of the kinds discussed abo!e.
All three kinds of anomalies are hi'hly undesirable, since thier occurence constitutes corruption of the
database. +roperly normali%ed database are much less susceptible to corruption than are un-normali%ed
databases.
"1. #hoose a key and write the dependencies for the followin' ,rades-
relation-
,.A/0S1Student2$/, #ourse3, Semester3, ,rade4
Ans#er:
5ey is -
Student2$/, #ourse3, Semester3,
/ependency is-
Student2$/, #ourse3, Semester3 -6 ,rade
"2. #hoose a key and write the dependencies for the 7$N02$)08S relation-
7$N02$)08S 1+92Number, $temNum, +artNum, /escription, +rice, :ty4
Ans#er:
5ey can be- +92Number, $temNum
/ependencies are-
+92Number, $temNum -6 +artNum, /escription, +rice, :ty
+artNum -6 /escription, +rice
"3. ;hat normal form is the abo!e 7$N02$)08S relation in<
Ans#er-
First off, 7$N02$)08S could not be in BCNF because-
not all determinants are keys.
ne(t- it could not be in 3NF because there is a transiti!e dependency-
+92Number, $temNum -6 +artNum
and
+artNum -6 /escription
)herefore, it must be in 2NF, we can check this is true because-
the key of +92Number, $temNum determines all of the non-key attributes howe!er, +92Number by itself and
$temNum by itself can not determine any other attributes.
"$- ;hat normal form is the followin' relation in<
S)9.02$)081 S5=, +romotion$/, >endor, Style, +rice 4
SKU, PromotionID -> Vendor, Style, Price
SKU -> Vendor, Style
Ans#er-
S)9.02$)08 is in 1NF 1non-key attribute 1!endor4 is dependent on only part of the key.
"%- Normali%e the abo!e 1:?4 relation into the ne(t hi'her normal form.
Ans#er-
S)9.02$)08 1S5=, +romotion$/, +rice4
>0N/9. $)08 1S5=, >endor, Style4
"&- #hoose a key and write the dependencies for the followin' S9F);A.0 relation 1assume all of the !endor@s
products ha!e the same warranty4.
S9F);A.0 1Software>endor, +roduct, .elease, System.e&, +rice, ;arranty4
SoftwareVendor, Product, Release -> SystemReq, Price, Warranty
Ans#er-
key is- Software>endor, +roduct, .elease
SoftwareVendor, Product, Release -> SystemReq, Price, Warranty
SoftwareVendor -> Warranty
.-. S9F);A.0 is in 1NF
"'est!on(- Normali%e the abo!e Software relation into ?NF.
Ans#er-
S9F);A.0 1Software>endor, +roduct, .elease, System.e&, +rice4
;A..AN)A 1Software>endor, ;arranty4
"'est!on)- ;hat normal form is the followin' relation in<
only B,$ can act as the key.
S)=FF 1B, $, C, 5, 7, 8, N, 94
B, $ -6 C, 5, 7
C -6 8
5 -6 N
7 -6 9
Ans#er-
2NF 1)ransiti!e dependencies e(ist4
"'est!on*- ;hat normal form the followin' relation in<
S)=FF2 1/, 9, N, ), #, ., A4
/, 9 -6 N, ), #, ., A
#, . -6 /
/ -6 N
Ans#er-
1NF 1+artial 5ey /ependency e(ist4
In+o!ce relat!on
$s this relation in 1NF< 2NF< NF<
#on!ert the relation to NF.
$n!3 date cust$/ Name +art3 /esc +rice 3=sed 0(t
+rice
)a(
rate
)a( )otal
1? 12DE ?2 7ee AF Nut G.2 1G .2G G.1G 1.22 1.?2
1? 12DE ?2 7ee A?G Saw ?.HG 2 I.GG G.1G 1.22 1.?2
1H 1DE? ?? +at AF Nut G.2 2G E.?G G.1G GE? J.G?
Tale not in !"# ecause
- it contains deri!ed !alues
0K) +.$#01L+rice K 3 used4
.2 L G.2 K 1G
- )a( 1Lsum of 0(t price of same $n!3 K )a( rate4
1.22 L 1.2 M I.GG4 K G.1G
- )otal 1Lsum of 0(t price M )a(4
1.?2 L 1.2G M I.GG4 M 1.22
)o 'et 1NF, identify +5 and remo!e deri!ed attributes
In+, date cust$/ Name -art, /esc +rice 3=sed )a( rate
1? 12DE ?2 7ee AF Nut G.2 1G G.1G
1? 12DE ?2 7ee A?G Saw ?.HG 2 G.1G
1H 1DE? ?? +at AF Nut 2 2G G.1G
)o 'et 2NF
- .emo!e partial dependencies
- +artial F/s with key attributes.
- $n!3 -6 /ate, #ust$/, Name, )a( .ate
- +art3 -6 /esc, +rice
.emo+e -art!al FDs
NO51-NNPPPPPPPO/1PPPPPPPPPPPNNP52PNNPP-/2PPPN
In+, date cust$/ Name )a( rate -art, /esc +rice 3=sed
1? 12DE ?2 7ee G.1G AF Nut G.2 1G
1? 12DE ?2 7ee G.1G A?G Saw ?.HG 2
1H 1DE? ?? +at G.1G AF Nut 2 2G
L
In+, date cust$/ Name )a(
rate
1? 12DE ?2 7ee G.1G
1? 12DE ?2 7ee G.1G
1H 1DE? ?? +at G.1G

In+, -art, 3=sed
1? AF 1G
1? A?G 2
1H AF 2G

-art, /esc +rice
AF Nut G.2
A?G Saw ?.HG
AF Nut 2
.emo+e trans!t!+e FD
$n!31+54 -6 #ust$/ -6 Name
In+, date cust$/ Name )a( rate
1? 12DE ?2 7ee G.1G
1H 1DE? ?? +at G.1G
=
In+, date cust$/ )a( rate
1? 12DE ?2 G.1G
1H 1DE? ?? G.1G
+
c'stID Name
?2 7ee
?? +at
All relations in 3NF
In+, -art, 3=sed
1? AF 1G
1? A?G 2
1H AF 2G

-art, /esc +rice
AF Nut G.2
A?G Saw ?.HG

In+, date cust$/ )a( rate
1? 12DE ?2 G.1G
1H 1DE? ?? G.1G

c'stID Name
?2 7ee
?2 +at
$n this pa'e you will see a basic database normali%ation e(ample, transformin' "#NF table into a ?NF one1s4.
)he ne(t table is in the "#NF form, con!ert it to the ?th normal form.
language
skill Emloyee
0rench electrical 2ones
Derman electrical 2ones
0rench mechanical 2ones
Derman mechanical 2ones
-panish
plumbinB
-mith
)he abo!e table does not comply with the ?th normal form, because it has repetitions like this-
A ' 2ones
= E 2ones
So this data may be already in the table, which means that it@s repeated.
' = 2ones
E A 2ones
)o transform this into the ?th normal form 1?NF4 we must separate the ori'inal table into two tables like this-
skill emloyee
electrical 2ones
mechanical 2ones
plumbinB -mith
And
language emloyee
0rench 2ones
Derman 2ones
-panish -mith