Normalization

We have noted that relations that form the database must satisfy some properties,
for example, relations have no duplicate tuples, tuples have no ordering associated
with them, and each element in the relation is atomic. Relations that satisfy these
basic requirements may still have some undesirable properties, for example, data
redundancy and update anomalies. We illustrate these properties and study how
relations may be transformed or decomposed (or normalised) to eliminate them.
Most such undesirable properties do not arise if the database modelling has been
carried out very carefully using some technique like the Entity-Relationship Model
that we have discussed but it is still important to understand the techniques in this
chapter to check the model that has been obtained and ensure that no mistakes
have been made in modelling.

The central concept in these discussions is the notion of functional dependency

which depends on understanding the semantics of the data and which deals with
what information in a relation is dependent on what other information in the
relation. We will define the concept of functional dependency and discuss how to
reason with the dependencies. We will then show how to use the dependencies
information to decompose relations whenever necessary to obtain relations that
have the desirable properties that we want without loosing any of the information
in the original relations.

Let us consider the following relation student.

sno sname address cno cname instructor office

85001 Smith 1, Main CP302 Database Gupta 102
85001 Smith 1, Main CP303 Communication Wilson 102
85001 Smith 1, Main CP304 Software Engg. Williams 1024
85005 Jones 12, 7th CP302 Database Gupta 102

The above table satisfies the properties of a relation and is said to be in first
normal form (or 1NF). Conceptually it is convenient to have all the information in
one relation since it is then likely to be easier to query the database. But the above
relation has the following undesirable features:

1. Repetition of information --- A lot of information is being repeated. Student name, address,
course name, instructor name and office number are being repeated often. Every time we wish to
insert a student enrolment, say, in CP302 we must insert the name of the course CP302 as well as
the name and office number of its instructor. Also every time we insert a new enrolment for, say
Smith, we must repeat his name and address. Repetition of information results in wastage of
storage as well as other problems.
2. Update Anomalies --- Redundant information not only wastes storage but makes updates more
difficult since, for example, changing the name of the instructor of CP302 would require that all
tuples containing CP302 enrolment information be updated. If for some reason, all tuples are not

Normalization Page # 1/26

 updated, we might have a database that gives two names of instructor for subject CP302. This
difficulty is called the update anomaly.
3. Insertional Anomalies -- Inability to represent certain information --- Let the primary key of the
above relation be (sno, cno). Any new tuple to be inserted in the relation must have a value for
the primary key since existential integrity requires that a key may not be totally or partially
NULL. However, if one wanted to insert the number and name of a new course in the database, it
would not be possible until a student enrols in the course and we are able to insert values of sno
and cno. Similarly information about a new student cannot be inserted in the database until the
student enrols in a subject. These difficulties are called insertion anomalies.
4. Deletion Anomalies -- Loss of Useful Information --- In some instances, useful information may
be lost when a tuple is deleted. For example, if we delete the tuple corresponding to student
85001 doing CP304, we will loose relevant information about course CP304 (viz. course name,
instructor, office number) if the student 85001 was the only student enrolled in that course.
Similarly deletion of course CP302 from the database may remove all information about the
student named Jones. This is called deletion anomalies.

The above problems arise primarily because the relation student has information
about students as well as subjects. One solution to deal with the problems is to
decompose the relation into two or more smaller relations.
Decomposition may provide further benefits, for example, in a distributed database
different relations may be stored at different sites if necessary. Of course,
decomposition does increase the cost of query processing since the decomposed
relations will need to be joined, sometime frequently.
The above relation may be easily decomposed into three relations to remove most
of the above undesirable properties:
S (sno, sname, address)
C (cno, cname, instructor, office)
SC (sno, cno)
Such decomposition is called normalization and is essential if we wish to overcome
undesirable anomalies. As noted earlier, normalization often has an adverse effect
on performance. Data which could have been retrieved from one relation before
normalization may require several relations to be joined after normalization.
Normalization does however lead to more efficient updates since an update that
may have required several tuples to be updated before normalization could well
need only one tuple to be updated after normalization.
Although in the above case we are able to look at the original relation and propose
a suitable decomposition that eliminates the anomalies that we have discussed, in
general this approach is not possible. A relation may have one hundred or more
attributes and it is then almost impossible for a person to conceptualise all the
information and suggest a suitable decomposition to overcome the problems. We
therefore need an algorithmic approach to finding if there are problems in a
proposed database design and how to eliminate them if they exist.
There are several stages of the normalization process. These are called the first
normal form (1NF), the second normal form (2NF), the third normal form (3NF),
Boyce-Codd normal form (BCNF), the fourth normal form (4NF) and the fifth normal
form (5NF). For all practical purposes, 3NF or the BCNF are quite adequate since
they remove the anomalies discussed above for most common situations. It should
be clearly understood that there is no obligation to normalise relations to the

Normalization Page # 2/26

highest possible level. Performance should be taken into account and this may
result in a decision not to normalise, say, beyond second normal form.
Intuitively, the second and third normal forms are designed to result in relations
such that each relation contains information about only one thing (either an entity
or a relationship). That is, non-key attributes in each relation must provide a fact
about the entity or relationship that is being identified by the key. Again, a sound
E-R model of the database would ensure that all relations either provide facts
about an entity or about a relationship resulting in the relations that are obtained
being in 3NF.
It should be noted that decomposition of relations has to be always based on
principles that ensure that the original relation may be reconstructed from the
decomposed relations if and when necessary. If we are able to reduce redundancy
and not loose any information, it implies that all that redundant information can be
derived given the other information in the database. Therefore information that
has been removed must be related or dependent on other information that still
exists in the database. That is why the concept of redundancy is important.
Careless decomposition of a relation can result in loss of information. We will
discuss this in detail later.

Role of Normalization
In an earlier chapter, we have discussed data modeling using the entity-
relationship model. In the E-R model, a conceptual schema using an entity-
relationship diagram is built and then mapped to a set of relations. This technique
ensures that each entity has information about only one thing and once the
conceptual schema is mapped into a set of relations, each relation would have
information about only one thing. The relations thus obtained would normally not
suffer from any of the anomalies that have been discussed in the last section. It
can be shown that if the entity-relationship is built using the guidelines that were
presented in Chapter 2, the resulting relations are in BCNF. (How??? Check?)

Of course, mistakes can often be made in database modeling specially when the
database is large and complex or one may, for some reasons, carry out database
schema design using techniques other than a modelling technique like the entity-
relationship model. For example, one could collect all the information that an
enterprise possesses and build one giant relation (often called the universal
relation) to hold it. This bottom-up approach is likely to lead to a relation that is
likely to suffer from all the problems that we have discussed in the last section. For
example, the relation is highly likely to have redundant information and update,
deletion and insertion anomalies. Normalization of such large relation will then be
essential to avoid (or at least minimise) these problems.

To summarise, normalization plays only a limited role in database schema design if

a top-down modelling approach like the entity- relationship approach is used.
Normalization however plays a major role when the bottom-up approach is being

Normalization Page # 3/26

used. Normalization is then essential to build appropriate relations to hold the
information of the enterprise.

Now to define the normal forms more formally, we first need to define the concept
of functional dependence.

Single-Valued Dependencies
Initially Codd (1972) presented three normal forms (1NF, 2NF and 3NF) all based
on functional dependencies among the attributes of a relation. Later Boyce and
Codd proposed another normal form called the Boyce-Codd normal form (BCNF).
The fourth and fifth normal forms are based on multivalue and join dependencies
and were proposed later.

Functional Dependency
Consider a relation R that has two attributes A and B. The attribute B of the
relation is functionally dependent on the attribute A if and only if for each value of
A no more than one value of B is associated. In other words, the value of attribute
A uniquely determines the value of B and if there were several tuples that had the
same value of A then all these tuples will have an identical value of attribute B.
That is, if t1 and t2 are two tuples in the relation R and
t1(A) = t2(A) then we must have t1(B) = t2(B).

A and B need not be single attributes. They could be any subsets of the attributes
of a relation R (possibly single attributes). We may then write

R.A -> R.B

if B is functionally dependent on A (or A functionally determines B). Note that

functional dependency does not imply a one-to-one relationship between A and B
although a one-to-one relationship may exist between A and B.

A simple example of the above functional dependency is when A is a primary key

of an entity (e.g. student number) and A is some single-valued property or
attribute of the entity (e.g. date of birth). A -> B then must always hold. (why?)

Normalization Page # 4/26

Functional dependencies also arise in relationships. Let C be the primary key of an
entity and D be the primary key of another entity. Let the two entities have a
relationship. If the relationship is one-to-one, we must have C -> D and D -> C. If
the relationship is many-to-one, we would have C -> D but not D -> C. For many-
to-many relationships, no functional dependencies hold. For example, if C is
student number and D is subject number, there is no functional dependency
between them. If however, we were storing marks and grades in the database as
well, we would have

(student_number, subject_number) -> marks

and we might have

marks -> grades

The second functional dependency above assumes that the grades are dependent
only on the marks. This may sometime not be true since the instructor may decide
to take other considerations into account in assigning grades, for example, the
class average mark.

For example, in the student database that we have discussed earlier, we have the
following functional dependencies:

sno -> sname

sno -> address
cno -> cname
cno -> instructor
instructor -> office

These functional dependencies imply that there can be only one name for each
sno, only one address for each student and only one subject name for each cno. It
is of course possible that several students may have the same name and several
students may live at the same address. If we consider cno -> instructor, the
dependency implies that no subject can have more than one instructor (perhaps
this is not a very realistic assumption). Functional dependencies therefore place
constraints on what information the database may store. In the above example,
one may be wondering if the following FDs hold

sname -> sno

cname -> cno

Certainly there is nothing in the instance of the example database presented

above that contradicts the above functional dependencies. However, whether
above FDs hold or not would depend on whether the university or college whose
database we are considering allows duplicate student names and subject names. If
it was the enterprise policy to have unique subject names than cname -> cno
holds. If duplicate student names are possible, and one would think there always is

Normalization Page # 5/26

the possibility of two students having exactly the same name, then sname -> sno
does not hold.

Functional dependencies arise from the nature of the real world that the database
models. Often A and B are facts about an entity where A might be some identifier
for the entity and B some characteristic. Functional dependencies cannot be
automatically determined by studying one or more instances of a database. They
can be determined only by a careful study of the real world and a clear
understanding of what each attribute means.

We have noted above that the definition of functional dependency does not require
that A and B be single attributes. In fact, A and B may be collections of attributes.
For example

(sno, cno) -> (mark, date)

When dealing with a collection of attributes, the concept of full functional

dependence is an important one. Let A and B be distinct collections of attributes
from a relation R end let R.A -> R.B. B is then fully functionally dependent on A if
B is not functionally dependent on any subset of A. The above example of students
and subjects would show full functional dependence if mark and date are not
functionally dependent on either student number ( sno) or subject number ( cno)
alone. The implies that we are assuming that a student may have more than one
subjects and a subject would be taken by many different students. Furthermore, it
has been assumed that there is at most one enrolment of each student in the
same subject.

The above example illustrates full functional dependence. However the following
dependence

(sno, cno) -> instructor

is not full functional dependence because cno -> instructor

holds.

As noted earlier, the concept of functional dependency is related to the concept of

candidate key of a relation since a candidate key of a relation is an identifier which
uniquely identifies a tuple and therefore determines the values of all other
attributes in the relation. Therefore any subset X of the attributes of a relation R
that satisfies the property that all remaining attributes of the relation are
functionally dependent on it (that is, on X), then X is candidate key as long as no
attribute can be removed from X and still satisfy the property of functional
dependence. In the example above, the attributes (sno, cno) form a candidate key
(and the only one) since they functionally determine all the remaining attributes.

Functional dependence is an important concept and a large body of formal theory

has been developed about it. We discuss the concept of closure that helps us
derive all functional dependencies that are implied by a given set of dependencies.

Normalization Page # 6/26

Once a complete set of functional dependencies has been obtained, we will study
how these may be used to build normalised relations.

Closure
Let a relation R have some functional dependencies F specified. The closure of F
(usually written as F+) is the set of all functional dependencies that may be
logically derived from F. Often F is the set of most obvious and important
functional dependencies and F+, the closure, is the set of all the functional
dependencies including F and those that can be deduced from F. The closure is
important and may, for example, be needed in finding one or more candidate keys
of the relation.

For example, the student relation has the following functional dependencies

sno -> sname cno -> cname sno -> address cno -> instructor instructor ->
office

Let these dependencies be denoted by F. The closure of F, denoted by F+, includes

F and all functional dependencies that are implied by F.

To determine F+, we need rules for deriving all functional dependencies that are
implied by F. A set of rules that may be used to infer additional dependencies was
proposed by Armstrong in 1974. These rules (or axioms) are a complete set of
rules in that all possible functional dependencies may be derived from them. The
rules are:

1. Reflexivity Rule --- If X is a set of attributes and Y is a subset of X, then X -> Y holds.

The reflexivity rule is the most simple (almost trivial) rule. It states that each
subset of X is functionally dependent on X.

2. Augmentation Rule --- If X -> Y holds and W is a set of attributes, then WX -> WY holds.

The augmentation rule is also quite simple. It states that if Y is determined

by X then a set of attributes W and Y together will be determined by W and X
together. Note that we use the notation WX to mean the collection of all
attributes in W and X and write WX rather than the more conventional (W, X)
for convenience.

3. Transitivity Rule --- If X -> Y and Y -> Z hold, then X -> Z holds.

The transitivity rule is perhaps the most important one. It states that if X
functionally determines Y and Y functionally determines Z then X functionally
determines Z.

Normalization Page # 7/26

These rules are called Armstrong's Axioms.
Further axioms may be derived from the above although the above three axioms
are sound and complete in that they do not generate any incorrect functional
dependencies (soundness) and they do generate all possible functional
dependencies that can be inferred from F (completeness). For proof of soundness
and completeness of Armstrong's Axioms, the reader is referred to Ullman (Vol 1,
page 387). The most important additional axioms are:

1. Union Rule --- If X -> Y and X -> Z hold, then X -> YZ holds.
2. Decomposition Rule --- If X -> YZ holds, then so do X -> Y and X -> Z.
3. Pseudotransitivity Rule --- If X -> Y and WY -> Z hold then so does WX -> Z.

Based on the above axioms and the functional dependencies specified for relation
student, we may write a large number of functional dependencies. Some of these
are:
(sno, cno) -> sno (Rule 1)
(sno, cno) -> cno (Rule 1)
(sno, cno) -> (sname, cname) (Rule 2)
cno -> office (Rule 3)
sno -> (sname, address) (Union Rule)
etc.
Often a very large list of dependencies can be derived from a given set F since
Rule 1 itself will lead to a large number of dependencies. Since we have seven
attributes (sno, sname, address, cno, cname, instructor, office), there are 128 (that
is, 2^7) subsets of these attributes. These 128 subsets could form 128 values of X
in functional dependencies of the type X -> Y. Of course, each value of X will then
be associated with a number of values for Y ( Y being a subset of X) leading to
several thousand dependencies. These large number of dependencies are not
particularly helpful in achieving our aim of normalizing relations.
Although we could follow the present procedure and compute the closure of F to
find all the functional dependencies, the computation requires exponential time
and the list of dependencies is often very large and therefore not very useful.
There are two possible approaches that can be taken to avoid dealing with the
large number of dependencies in the closure. One is to deal with one attribute or a
set of attributes at a time and find its closure (i.e. all functional dependencies
relating to them). The aim of this exercise is to find what attributes depend on a
given set of attributes and therefore ought to be together. The other approach is to
find the minimal covers. We will discuss both approaches briefly.
As noted earlier, we need not deal with the large number of dependencies that
might arise in a closure since often one is only interested in determining closure of
a set of attributes given a set of functional dependencies. Closure of a set of
attributes X is all the attributes that are functionally dependent on X given some
functional dependencies F while the closure of F was all functional dependencies
that are implied by F. Computing the closure of a set of attributes is a much
simpler task if we are dealing with a small number of attributes. We will denote the
closure of a set of attributes X given F by X+.
An algorithm to determine the closure:

Normalization Page # 8/26

Step 1 Let X^c <- X
Step 2 Let the next dependency be A -> B. If A is in X^c and B is not, X^c <- X^c
+ B.
Step 3 Continue step 2 until no new attributes can be added to X^c.
The result of the algorithm is X^c that is equal to X+.
The above algorithm may also be used to remove redundant dependencies. For
example, to check if X -> A is redundant, we find closure of X without using X ->
A. If A is in X^c, we can eliminate X -> A as redundant.
Consider the following relation
student(sno, sname, cno, cname).
We wish to determine the closure of (sno, cno). We have the following functional
dependencies.
sno -> sname
cno -> cname
We apply the above algorithm using X^c as the place holder for all the attributes
that have been found to be dependent on X so far.
Step 1 --- X^c <- X, that is, X^c <- (sno, cno)
Step 2 --- Consider sno -> sname, since sno is in X^c and sname is not, we have
X^c <- (sno, cno) + sname
Step 3 --- Consider cno -> cname, since cno is in X^c and cname is not, we have
X^c <- (sno, cno, sname) + cname
Step 4 --- Again, consider sno -> sname but this does not change X^c.
Step 5 --- Again, consider cno -> cname but this does not change X^c.
Therefore X+ = X^c = (sno, cno, sname, cname).
This shows that all the attributes in the relation student (sno, cno, sname, cname)
are dependent on (sno, cno) and therefore (sno, cno) is a candidate key of the
present relation. In this case, it is the only candidate key.
Similarly we may wish to investigate the closure of (sname, cname). We will find
that the closure of (sname, cname) is only (sname, cname). Therefore these two
attributes together cannot form the key of the above relation.
We define some further concepts about functional dependencies

Equivalent Functional Dependencies

Let F1 and F2 be two sets of FDs. The two FDs are called equivalent if F+1 = F
+2 . Of course, it is not always easy to test that the two sets are equivalent since
each of them may consist of hundreds of FDs. One way to carry out the checking
would be to take each dependency X -> Y in turn from F+1 and check if it is in
F+2. Sometime the term F1 covers F2 and F2 covers F1 is used to denote
equivalence.

Normalization Page # 9/26

 Minimal Functional Dependencies
In discussing the concept of equivalent FDs, it is useful to define the concept of
minimal functional dependencies or minimal cover which is useful in eliminating
unnecessary functional dependencies so that only the minimal number of
dependencies need to be enforced by the system. The concept of minimal cover of
F is sometimes called Irreducibe Set of F. To find the minimal cover of a set of
functional dependencies F, we transform F such that each FD in it that has more
than one attribute in the right hand side is reduced to a set of FDs that have only
one attribute on the right hand side. This can be done easily using the
decomposition rule that we have already discussed. The minimal cover of F is then
a set of FDs such that:

(a) every right hand side of each dependency is a single attribute;

(b) for no X -> A in F is the set F - {X -> A} equivalent to F;
(c) for no X -> A in F and proper subset Z of X is F - {X -> A} U {Z -> A}
equivalent to F.

Requirements (a), as already noted, can be met easily given any set of
dependencies F. Requirement (b) guarantees that we cannot remove any
dependencies from F and still have a set of dependencies equivalent to F or no
attribute on the left hand side of a dependency is redundant. Requirement (c)
makes sure that no dependencies may be replaced by a dependency that involves
a subset of the left hand side.

The concept of minimal set of dependencies is useful in normalization as we shall

discuss later. The minimal set may be considered a standard or canonical form of
FDs with no redundancies that is equivalent to F. Unfortunately however the
minimal cover is not unique. Now that we have the necessary background, we may
define the three normal forms.

Single-Valued Dependencies
Initially Codd (1972) presented three normal forms (1NF, 2NF and 3NF) all based
on functional dependencies among the attributes of a relation. Later Boyce and
Codd proposed another normal form called the Boyce-Codd normal form (BCNF).
The fourth and fifth normal forms are based on multivalue and join dependencies
and were proposed later.

First Normal Form (1NF)

Normalization Page # 10/26

A table satisfying the properties of a relation is said to be in first normal form. As
discussed in an earlier chapter, a relation cannot have multivalued or composite
attributes. This is what the 1NF requires.

A relation is in 1NF if and only if all underlying domains contain atomic values only.

The first normal form deals only with the basic structure of the relation and does
not resolve the problems of redundant information or the anomalies discussed
earlier. All relations discussed in these notes are in 1NF.

For example consider the following example relation:

student (sno, sname, dob)

Add some other attributes so it has anomalies and is not in 2NF

The attribute dob is the date of birth and the primary key of the relation is sno with
the functional dependencies sno -> sname and sno -> dob. The relation is in
1NF as long as dob is considered an atomic value and not consisting of three
components (day, month, year). The above relation of course suffers from all the
anomalies that we have discussed earlier and needs to be normalized. (add
example with date of birth)

Second Normal Form (2NF)

The second normal form attempts to deal with the problems that are identified with
the relation above that is in 1NF. The aim of second normal form is to ensure that
all information in one relation is only about one thing.

A relation is in 2NF if it is in 1NF and every non-key attribute is fully dependent on

each candidate key of the relation.

To understand the above definition of 2NF we need to define the concept of key
attributes. Each attribute of a relation that participates in at least one candidate
key of is a key attribute of the relation. All other attributes are called non-key.

The concept of 2NF requires that all attributes that are not part of a candidate key
be fully dependent on each candidate key. If we consider the relation

student (sno, sname, cno, cname)

and the functional dependencies

sno -> cname

cno -> cname

and assume that (sno, cno) is the only candidate key (and therefore the primary
key), the relation is not in 2NF since sname and cname are not fully dependent on

Normalization Page # 11/26

the key. The above relation suffers from the same anomalies and repetition of
information as discussed above since sname and cname will be repeated. To
resolve these difficulties we could remove those attributes from the relation that
are not fully dependent on the candidate keys of the relations. Therefore we
decompose the relation into the following projections of the original relation:

S1 (sno, sname)
S2 (cno, cname)
SC (sno, cno)

Use an example that leaves one relation in 2NF but not in 3NF.

We may recover the original relation by taking the natural join of the three
relations.

If however we assume that sname and cname are unique and therefore we have
the following candidate keys

(sno, cno)
(sno, cname)
(sname, cno)
(sname, cname)

The above relation is now in 2NF since the relation has no non-key attributes. The
relation still has the same problems as before but it then does satisfy the
requirements of 2NF. Higher level normalization is needed to resolve such problems
with relations that are in 2NF and further normalization will result in decomposition
of such relations.

Third Normal Form (3NF)

Although transforming a relation that is not in 2NF into a number of relations that
are in 2NF removes many of the anomalies that appear in the relation that was not
in 2NF, not all anomalies are removed and further normalization is sometime
needed to ensure further removal of anomalies. These anomalies arise because a
2NF relation may have attributes that are not directly related to the thing that is
being described by the candidate keys of the relation. Let us first define the 3NF.

A relation R is in third normal form if it is in 2NF and every non-key attribute of R is

non-transitively dependent on each candidate key of R.

To understand the third normal form, we need to define transitive dependence

which is based on one of Armstrong's axioms. Let A, B and C be three attributes of
a relation R such that A -> B and B -> C. From these FDs, we may derive A -> C.
As noted earlier, this dependence A -> C is transitive.

Normalization Page # 12/26

The 3NF differs from the 2NF in that all non-key attributes in 3NF are required to be
directly dependent on each candidate key of the relation. The 3NF therefore insists,
in the words of Kent (1983) that all facts in the relation are about the key (or the
thing that the key identifies), the whole key and nothing but the key. If some
attributes are dependent on the keys transitively then that is an indication that
those attributes provide information not about the key but about a kno-key
attribute. So the information is not directly about the key, although it obviously is
related to the key.

Consider the following relation

subject (cno, cname, instructor, office)

Assume that cname is not unique and therefore cno is the only candidate key. The
following functional dependencies exist

cno -> cname

cno -> instructor
instructor -> office

We can derive cno -> office from the above functional dependencies and
therefore the above relation is in 2NF. The relation is however not in 3NF since
office is not directly dependent on cno. This transitive dependence is an indication
that the relation has information about more than one thing (viz. course and
instructor) and should therefore be decomposed. The primary difficulty with the
above relation is that an instructor might be responsible for several subjects and
therefore his office address may need to be repeated many times. This leads to all
the problems that we identified at the beginning of this chapter. To overcome these
difficulties we need to decompose the above relation in the following two relations:

s (cno, cname, instructor)

ins (instructor, office)

s is now in 3NF and so is ins.

An alternate decomposition of the relation subject is possible:

s(cno, cname)
inst(instructor, office)
si(cno, instructor)

The decomposition into three relations is not necessary since the original relation
is based on the assumption of one instructor for each course.

The 3NF is usually quite adequate for most relational database designs. There are
however some situations, for example the relation student(sno, sname, cno,
cname) discussed in 2NF above, where 3NF may not eliminate all the redundancies
and inconsistencies. The problem with the relation student(sno, sname, cno,

Normalization Page # 13/26

cname) is because of the redundant information in the candidate keys. These are
resolved by further normalization using the BCNF.

Boyce-Codd Normal Form (BCNF)

The relation student(sno, sname, cno, cname) has all attributes participating in
candidate keys since all the attributes are assumed to be unique. We therefore had
the following candidate keys:

(sno, cno)
(sno, cname)
(sname, cno)
(sname, cname)

Since the relation has no non-key attributes, the relation is in 2NF and also in 3NF,
in spite of the relation suffering the problems that we discussed at the beginning of
this chapter.

The difficulty in this relation is being caused by dependence within the candidate
keys. The second and third normal forms assume that all attributes not part of the
candidate keys depend on the candidate keys but does not deal with dependencies
within the keys. BCNF deals with such dependencies.

A relation R is said to be in BCNF if whenever X -> A holds in R, and A is not in X,

then X is a candidate key for R.

It should be noted that most relations that are in 3NF are also in BCNF.
Infrequently, a 3NF relation is not in BCNF and this happens only if

(a) the candidate keys in the relation are composite keys (that is, they are not
single attributes),
(b) there is more than one candidate key in the relation, and
(c) the keys are not disjoint, that is, some attributes in the keys are common.

The BCNF differs from the 3NF only when there are more than one candidate keys
and the keys are composite and overlapping. Consider for example, the
relationship

enrol (sno, sname, cno, cname, date-enrolled)

Let us assume that the relation has the following candidate keys:

(sno, cno)
(sno, cname)
(sname, cno)
(sname, cname)

Normalization Page # 14/26

(we have assumed sname and cname are unique identifiers). The relation is in 3NF
but not in BCNF because there are dependencies

sno -> sname

cno -> cname

where attributes that are part of a candidate key are dependent on part of another
candidate key. Such dependencies indicate that although the relation is about
some entity or association that is identified by the candidate keys e.g. (sno, cno),
there are attributes that are not about the whole thing that the keys identify. For
example, the above relation is about an association (enrolment) between students
and subjects and therefore the relation needs to include only one identifier to
identify students and one identifier to identify subjects. Providing two identifiers
about students (sno, sname) and two keys about subjects (cno, cname) means that
some information about students and subjects that is not needed is being
provided. This provision of information will result in repetition of information and
the anomalies that we discussed at the beginning of this chapter. If we wish to
include further information about students and courses in the database, it should
not be done by putting the information in the present relation but by creating new
relations that represent information about entities student and subject.

These difficulties may be overcome by decomposing the above relation in the

following three relations:

(sno, sname)
(cno, cname)
(sno, cno, date-of-enrolment)

We now have a relation that only has information about students, another only
about subjects and the third only about enrolments. All the anomalies and
repetition of information have been removed.

Desirable Properties of Decomposition

Normalization Page # 15/26

So far our approach has consisted of looking at individual relations and checking if
they belong to 2NF, 3NF or BCNF. If a relation was not in the normal form that was
being checked for and we wished the relation to be normalised to that normal form
so that some of the anomalies can be eliminated, it was necessary to decompose
the relation in two or more relations. The process of decomposition of a relation R
into a set of relations R1 , R2 , ..., Rn was based on identifying different components
and using that as a basis of decomposition. The decomposed relations R1 , R2 , ...,
Rn are projections of R and are of course not disjoint otherwise the glue holding the
information together would be lost. Decomposing relations in this way based on a
recognise and split method is not a particularly sound approach since we do not
even have a basis to determine that the original relation can be constructed if
necessary from the decomposed relations. We now discuss desirable properties of
good decomposition and identify difficulties that may arise if the decomposition is
done without adequate care. The next section will discuss how such decomposition
may be derived given the FDs.

Desirable properties of a decomposition are:

1. Attribute preservation
2. Lossless-join decomposition
3. Dependency preservation
4. Lack of redundancy

Attribute Preservation
This is a simple and an obvious requirement that involves preserving all the
attributes that were there in the relation that is being decomposed.

Lossless-Join Decomposition
In these notes so far we have normalised a number of relations by decomposing
them. We decomposed a relation intuitively. We need a better basis for deciding
decompositions since intuition may not always be correct. We illustrate how a
careless decomposition may lead to problems including loss of information.

Consider the following relation

Normalization Page # 16/26

enrol (sno, cno, date-enrolled, room-No., instructor)

Suppose we decompose the above relation into two relations enrol1 and enrol2 as
follows

enrol1 (sno, cno, date-enrolled)

enrol2 (date-enrolled, room-No., instructor)

There are problems with this decomposition but we wish to focus on one aspect at
the moment. Let an instance of the relation enrol be

sno cno date-enrolled room-No. instructor

830057 CP302 1FEB1984 MP006 Gupta
830057 CP303 1FEB1984 MP006 Jones
820159 CP302 10JAN1984 MP006 Gupta
825678 CP304 1FEB1984 CE122 Wilson
826789 CP305 15JAN1984 EA123 Smith

and let the decomposed relations enrol1 and enrol2 be:

sno cno date-enrolled

830057 CP302 1FEB1984
830057 CP303 1FEB1984
820159 CP302 10JAN1984
825678 CP304 1FEB1984
826789 CP305 15JAN1984

date-enrolled room-No. instructor

1FEB1984 MP006 Gupta
1FEB1984 MP006 Jones
10JAN1984 MP006 Gupta
1FEB1984 CE122 Wilson
15JAN1984 EA123 Smith

All the information that was in the relation enrol appears to be still available in
enrol1 and enrol2 but this is not so. Suppose, we wanted to retrieve the student
numbers of all students taking a course from Wilson, we would need to join enrol1
and enrol2. The join would have 11 tuples as follows:

sno cno date-enrolled room-No. instructor

830057 CP302 1FEB1984 MP006 Gupta
830057 CP302 1FEB1984 MP006 Jones
830057 CP303 1FEB1984 MP006 Gupta
830057 CP303 1FEB1984 MP006 Jones
830057 CP302 1FEB1984 CE122 Wilson

Normalization Page # 17/26

830057 CP303 1FEB1984 CE122 Wilson

(add further tuples ...)

The join contains a number of spurious tuples that were not in the original relation
Enrol. Because of these additional tuples, we have lost the information about which
students take courses from WILSON. (Yes, we have more tuples but less
information because we are unable to say with certainty who is taking courses
from WILSON). Such decompositions are called lossy decompositions. A nonloss or
lossless decomposition is that which guarantees that the join will result in exactly
the same relation as was decomposed. One might think that there might be other
ways of recovering the original relation from the decomposed relations but, sadly,
no other operators can recover the original relation if the join does not (why?).

We need to analyse why some decompositions are lossy. The common attribute in
above decompositions was Date-enrolled. The common attribute is the glue that
gives us the ability to find the relationships between different relations by joining
the relations together. If the common attribute is not unique, the relationship
information is not preserved. If each tuple had a unique value of Date-enrolled, the
problem of losing information would not have existed. The problem arises because
several enrolments may take place on the same date.

A decomposition of a relation R into relations R1, R2 , ..., Rn is called a lossless-join

decomposition (with respect to FDs F) if the relation R is always the natural join of
the relations R1, R2 , ..., Rn. It should be noted that natural join is the only way to
recover the relation from the decomposed relations. There is no other set of
operators that can recover the relation if the join cannot. Furthermore, it should be
noted when the decomposed relations R1, R2 , ..., Rn are obtained by projecting on
the relation R, for example R1 by projection pi1 (R), the relation R1 may not always
be precisely equal to the projection since the relation R1 might have additional
tuples called the dangling tuples. Explain ...

It is not difficult to test whether a given decomposition is lossless-join given a set

of functional dependencies F. We consider the simple case of a relation R being
decomposed into R1 and R2. If the decomposition is lossless-join, then one of the
following two conditions must hold

(R1 intersection R2) -> (R1 - R2)

(R1 intersection R2) -> (R2 - R1)

That is, the common attributes in R1 and R2 must include a candidate key of either
R1 or R2. How do you know, you have a loss-less join decomposition?

Dependency Preservation

Normalization Page # 18/26

It is clear that a decomposition must be lossless so that we do not lose any
information from the relation that is decomposed. Dependency preservation is
another important requirement since a dependency is a constraint on the database
and if X -> Y holds than we know that the two (sets) attributes are closely related
and it would be useful if both attributes appeared in the same relation so that the
dependency can be checked easily.

Let us consider a relation R(A, B, C, D) that has the dependencies F that include
the following:

A -> B
A -> B
etc

If we decompose the above relation into R1(A, B) and R2(B, C, D) the dependency
A -> C cannot be checked (or preserved) by looking at only one relation. It is
desirable that decompositions be such that each dependency in F may be checked
by looking at only one relation and that no joins need be computed for checking
dependencies. In some cases, it may not be possible to preserve each and every
dependency in F but as long as the dependencies that are preserved are
equivalent to F, it should be sufficient.

Let F be the dependencies on a relation R which is decomposed in relations R1, R2,

..., Rn.

We can partition the dependencies given by F such that F1, F2, ..., Fn. Fn are
dependencies that only involve attributes from relations R1, R2, ..., Rn respectively.
If the union of dependencies Fi imply all the dependencies in F, then we say that
the decomposition has preserved dependencies, otherwise not.

If the decomposition does not preserve the dependencies F, then the decomposed
relations may contain relations that do not satisfy F or the updates to the
decomposed relations may require a join to check that the constraints implied by
the dependencies still hold.

(Need an example) (Need to discuss testing for dependency preservation with an

example... Ullman page 400)

Consider the following relation

sub(sno, instructor, office)

We may wish to decompose the above relation to remove the transitive

dependency of office on sno. A possible decomposition is

S1(sno, instructor)
S2(sno, office)

Normalization Page # 19/26

The relations are now in 3NF but the dependency instructor -> office cannot be
verified by looking at one relation; a join of S1 and S2 is needed. In the above
decomposition, it is quite possible to have more than one office number for one
instructor although the functional dependency instructor -> office does not allow it.

Lack of Redundancy
We have discussed the problems of repetition of information in a database. Such
repetition should be avoided as much as possible.

Lossless-join, dependency preservation and lack of redundancy not always possible

with BCNF.

Lossless-join, dependency preservation and lack of redundancy is always possible

with 3NF.

Deriving BCNF
Should we also include deriving 3NF? page 409-411 Ullman.

Given a set of dependencies F, we may decompose a given relation into a set of

relations that are in BCNF using the following algorithm: (page 238 Ullman or
Korth)

So far we have considered the "recognise and split" method of normalization. We

now discuss Bernstein's algorithm. The algorithm consists of

(1) Find out the facts about the real world.

(2) Reduce the list of functional relationships.
(3) Find the keys.
(4) Combine related facts.

Once we have obtained relations by using the above approach we need to check
that they are indeed in BCNF. If there is any relation R that has a dependency A ->
Band A is not a key, the relation violates the conditions of BCNF and may be
decomposed in AB and R - A. The relation AB is now in BCNF and we can now check
if R - A is also in BCNF. If not, we can apply the above procedure again until all the
relations are in fact in BCNF

Multivalued Dependencies
Normalization Page # 20/26
Recall that when we discussed database modelling using the E-R Modelling
technique, we noted difficulties that can arise when an entity has multivalue
attributes. It was because in the relational model, if all of the information about
such entity is to be represented in one relation, it will be necessary to repeat all
the information other than the multivalue attribute value to represent all the
information that we wish to represent. This results in many tuples about the same
instance of the entity in the relation and the relation having a composite key (the
entity id and the mutlivalued attribute). Of course the other option suggested was
to represent this multivalue information in a separate relation. The situation of
course becomes much worse if an entity has more than one multivalued attributes
and these values are represented in one relation by a number of tuples for each
entity instance such that every value of one the multivalued attributes appears
with every value of the second multivalued attribute to maintain consistency. The
multivalued dependency relates to this problem when more than one multivalued
attributes exist. Consider the following relation that represents an entity employee
that has one mutlivalued attribute proj:

emp (e#, dept, salary, proj)

We have so far considered normalization based on functional dependencies;

dependencies that apply only to single-valued facts. For example, e# -> dept
implies only one dept value for each value of e#. Not all information in a database
is single-valued, for example, proj in an employee relation may be the list of all
projects that the employee is currently working on. Although e# determines the list
of all projects that an employee is working on, e# -> proj is not a functional
dependency.

So far we have dealt with multivalued facts about an entity by having a separate
relation for that multivalue attribute and then inserting a tuple for each value of
that fact. This resulted in composite keys since the multivalued fact must form part
of the key. In none of our examples so far have we dealt with an entity having more
than one multivalued attribute in one relation. We do so now.

The fourth and fifth normal forms deal with multivalued dependencies. Before
discussing the 4NF and 5NF we discuss the following example to illustrate the
concept of multivalued dependency.

programmer (emp_name, qualifications, languages)

The above relation includes two multivalued attributes of entity programmer;

qualifications and languages. There are no functional dependencies.

The attributes qualifications and languages are assumed independent of each

other. If we were to consider qualifications and languages separate entities, we
would have two relationships (one between employees and qualifications and the
other between employees and programming languages). Both the above
relationships are many-to-many i.e. one programmer could have several

Normalization Page # 21/26

qualifications and may know several programming languages. Also one
qualification may be obtained by several programmers and one programming
language may be known to many programmers.

The above relation is therefore in 3NF (even in BCNF) but it still has some
disadvantages. Suppose a programmer has several qualifications (B.Sc, Dip. Comp.
Sc, etc) and is proficient in several programming languages; how should this
information be represented? There are several possibilities.

emp_name qualifications Languages

SMITH B.Sc FORTRAN
SMITH B.Sc COBOL
SMITH B.Sc PASCAL
SMITH Dip.CS FORTRAN
SMITH Dip.CS COBOL
SMITH Dip.CS PASCAL
emp_name qualifications Languages
SMITH B.Sc NULL
SMITH Dip.CS NULL
SMITH NULL FORTRAN
SMITH NULL COBOL
SMITH NULL PASCAL
emp_name qualifications Languages
SMITH B.Sc FORTRAN
SMITH Dip.CS COBOL
SMITH NULL PASCAL

Other variations are possible (we remind the reader that there is no relationship
between qualifications and programming languages). All these variations have
some disadvantages. If the information is repeated we face the same problems of
repeated information and anomalies as we did when second or third normal form
conditions are violated. If there is no repetition, there are still some difficulties with
search, insertions and deletions. For example, the role of NULL values in the above
relations is confusing. Also the candidate key in the above relations is (emp name,
qualifications, language) and existential integrity requires that no NULLs be
specified. These problems may be overcome by decomposing a relation like the
one above as follows:

emp_name qualifications
SMITH B.Sc
SMITH Dip.CS

emp_name languages
SMITH FORTRAN

Normalization Page # 22/26

SMITH COBOL
SMITH PASCAL

The basis of the above decomposition is the concept of multivalued dependency

(MVD). Functional dependency A -> B relates one value of A to one value of B while
multivalued dependency A ->> B defines a relationship in which a set of values of
attribute B are determined by a single value of A.

The concept of multivalued dependencies was developed to provide a basis for

decomposition of relations like the one above. Therefore if a relation like
enrolment(sno, subject#) has a relationship between sno and subject# in which
sno uniquely determines the values of subject#, the dependence of subject# on
sno is called a trivial MVD since the relation enrolment cannot be decomposed any
further. More formally, a MVD X ->> Y is called trivial MVD if either Y is a subset of
X or X and Y together form the relation R. The MVD is trivial since it results in no
constraints being placed on the relation. Therefore a relation having non-trivial
MVDs must have at least three attributes; two of them multivalued. Non-trivial
MVDs result in the relation having some constraints on it since all possible
combinations of the multivalue attributes are then required to be in the relation.

Let us now define the concept of multivalued dependency. The multivalued

dependency X ->> Y is said to hold for a relation R(X, Y, Z) if for a given set of
value (set of values if X is more than one attribute) for attributes X, there is a set
of (zero or more) associated values for the set of attributes Y and the Y values
depend only on X values and have no dependence on the set of attributes Z.

In the example above, if there was some dependence between the attributes
qualifications and language, for example perhaps, the language was related to the
qualifications (perhaps the qualification was a training certificate in a particular
language), then the relation would not have MVD and could not be decomposed
into two relations as abve. In the above situation whenever X ->> Y holds, so does
X ->> Z since the role of the attributes Y and Z is symmetrical.

Consider two different situations.

(a) Z is a single valued attribute. In this situation, we deal with R(X, Y, Z) as before
by entering several tuples about each entity.
(b) Z is multivalued.

Now, more formally, X ->> Y is said to hold for R(X, Y, Z) if t1 and t2 are two tuples
in R that have the same values for attributes X and therefore with t1[x] = t2[x]
then R also contains tuples t3 and t4 (not necessarily distinct) such that

t1[x] = t2[x] = t3[x] = t4[x]

t3[Y] = t1[Y] and t3[Z] = t2[Z]
t4[Y] = t2[Y] and t4[Z] = t1[Z]

Normalization Page # 23/26

In other words if t1 and t2 are given by

t1 = [X, Y1, Z1], and

t2 = [X, Y2, Z2]

then there must be tuples t3 and t4 such that

t3 = [X, Y1, Z2], and

t4 = [X, Y2, Z1]

We are therefore insisting that every value of Y appears with every value of Z to
keep the relation instances consistent. In other words, the above conditions insist
that Y and Z are determined by X alone and there is no relationship between Y and
Z since Y and Z appear in every possible pair and hence these pairings present no
information and are of no significance. Only if some of these pairings were not
present, there would be some significance in the pairings.

Give example (instructor, quals, subjects) --- explain if subject was single valued;
otherwise all combinations must occur. Discuss duplication of info in that case.

(Note: If Z is single-valued and functionally dependent on X then Z1 = Z2. If Z is

multivalue dependent on X then Z1 <> Z2).

The theory of multivalued dependencies in very similar to that for functional

dependencies. Given D a set of MVDs, we may find D+, the

Multivalued Normalisation -
Fourth Normal Form
We have considered an example of Programmer(Emp name, qualification,
languages) and discussed the problems that may arise if the relation is not
normalised further. We also saw how the relation could be decomposed into
P1(Emp name, qualifications) and P2(Emp name, languages) to overcome these
problems. The decomposed relations are in fourth normal form (4NF) which we
shall now define.

Normalization Page # 24/26

We are now ready to define 4NF. A relation R is in 4NF if, whenever a multivalued
dependency
X -> Y holds then either

(a) the dependency is trivial, or

(b) X is a candidate key for R.

As noted earlier, the dependency X ->> ø or X ->> Y in a relation R (X, Y) is trivial

since they must hold for all R (X, Y). Similarly (X, Y) -> Z must hold for all relations
R (X, Y, Z) with only three attributes.

In fourth normal form, we have a relation that has information about only one
entity. If a relation has more than one multivalue attribute, we should decompose it
to remove difficulties with multivalued facts.

Intuitively R is in 4NF if all dependencies are a result of keys. When multivalued

dependencies exist, a relation should not contain two or more independent
multivalued attributes. The decomposition of a relation to achieve 4NF would
normally result in not only reduction of redundancies but also avoidance of
anomalies.

Fifth Normal Form (5NF)

The normal forms discussed so far required that the given relation R if not in the
given normal form be decomposed in two relations to meet the requirements of the
normal form. In some rare cases, a relation can have problems like redundant
information and update anomalies because of it but cannot be decomposed in two
relations to remove the problems. In such cases it may be possible to decompose
the relation in three or more relations using the 5NF.

The fifth normal form deals with join-dependencies which is a generalisation of the
MVD. The aim of fifth normal form is to have relations that cannot be decomposed
further. A relation in 5NF cannot be constructed from several smaller relations.

A relation R satisfies join dependency (R1, R2, ..., Rn) if and only if R is equal to the
join of
R1, R2, ..., Rn where Ri are subsets of the set of attributes of R.

A relation R is in 5NF (or project-join normal form, PJNF) if for all join dependencies
at least one of the following holds.

Normalization Page # 25/26

(a) (R1, R2, ..., Rn) is a trivial join-dependency (that is, one of Ri is R)
(b) Every Ri is a candidate key for R.

An example of 5NF can be provided by the example below that deals with
departments, subjects and students.

dept subject student

Comp. Sc. CP1000 John Smith
Mathematics MA1000 John Smith
Comp. Sc. CP2000 Arun Kumar
Comp. Sc. CP3000 Reena Rani
Physics PH1000 Raymond Chew
Chemistry CH2000 Albert Garcia

The above relation says that Comp. Sc. offers subjects CP1000, CP2000 and
CP3000 which are taken by a variety of students. No student takes all the subjects
and no subject has all students enrolled in it and therefore all three fields are
needed to represent the information.

The above relation does not show MVDs since the attributes subject and student
are not independent; they are related to each other and the pairings have
significant information in them. The relation can therefore not be decomposed in
two relations

(dept, subject), and

(dept, student)

without loosing some important information. The relation can however be

decomposed in the following three relations

(dept, subject), and

(dept, student)
(subject, student)

and now it can be shown that this decomposition is lossless.

Normalization Page # 26/26