In other words, only one value is associated with each attributes and the value is not
a set of values or a list of values.
More simply, a relation is in first normal form if it does not have any repeating groups.
For example, we have the database of employees having multiple addresses for a single
employee shown in Fig. 7.1
Ename
Designation
Address
Scott
Manager
Boston
New York
Washington
John
Accountant
Boston
Zurich
Abraham
Clerk
New York
Glasgow
Fig. 7.1
This table is obviously a complex object being three-dimensional. It is
more complex
both from the point of view of representation, whether on paper or in a computer and, more
importantly from the point of view of the relational model, because it will require much
more complex operators to access data within it. Thus in order to simplify the operators

Data Base Management systems
53
Notes
Amity Directorate of Distance & Online Education
of the relational model and to simplify the model in general, repeating columns are not
allowed in its table.
To convert this relation into 1NF, repeating groups will have to be eliminated a shown
in Fig. 7.2.
Ename
Designation
Address
Scott
Manager
Boston
Scott
Manager
New York
Scott
Manager
Washington
John
Accountant
Boston
John
Accountant
Zurich
Abraham
Clerk
New York
Abraham
Clerk
Glasgow
Fig. 7.2
However, it will lead to the redundancy of the data, for example, Scott’s designation
is ‘Manager’ is repeated several times. This will lead to update difficulties when Scott’s
designation changes, since many occurrences of his designation will have to be found
and updated when it does. Secondly the Ename attribute can no longer server the primary
key, since the same value for it can now occur many times in different rows of the table.
To obtain a key for the table, Ename and Address attributes must be concatenated and
this is clearly not a very good design.
Functional Dependencies
The only purpose of 1NF is to simplify the relational model. It is fundamental property
of relational model. The second normal form is based on the concept of fully functional
dependency, which provides a means for defining additional constraints on a relational
scheme. Formally a functional dependency is defined as follow:
Let X and Y be two nonempty set of attributes in a relational scheme R. If r is an
instance of R then r satisfies the functional dependency X
→
Y, if for any tow tuples t1 and
t2 of r, t1[X] = t2[X] implies t1[Y] = t2[Y].
More simply, Functional dependency can also be defined as:
“An attribute in a relational model table is said to be functionally dependent on another
attribute in the table if it can take only one value for a given value of the attribute upon
which it is functionally dependent.”
In order to verify if a given FD X
→
Y is satisfied by a relation R, we find any tow tuples
with the same X value; if the FD X
→
Y is satisfied in R, then the Y value in these tuples
must be the same. This procedure is repeated until all the pairs having same value in X
have been examined.
This can be clarified by an example. Consider the Employee database having the
data shown in Fig. 7.3
EMPNO
Ename
Sal
Dept_Name
Dept_Loc
1001
Scott
5000
Chemistry
Loc-A
1002
John
7500
Computer
Loc-B
1003
Abraham
5000
Physics
Loc-C
1004
Smith
4500
Physics
Loc-C
1005
Brown
2900
Computer
Loc-B
Fig. 7.3
