Copyright © 2007 Ramez Elmasri and Shamkant B.

Navathe
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe
Chapter
Functional Dependencies and
Normalization for Relational
Databases
1.2 Redundant Information in Tuples and
Update Anomalies

◼ Information is stored redundantly

◼ Wastes storage
◼ Causes problems with update anomalies
◼ Insertion anomalies
◼ Deletion anomalies
◼ Modification anomalies

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

EXAMPLE OF AN UPDATE ANOMALY

◼ Consider the relation:

◼ EMP_PROJ(Emp#, Proj#, Ename, Pname,
No_hours)
◼ Update Anomaly:
◼ Changing the name of project number P1 from
“Billing” to “Customer-Accounting” may cause this
update to be made for all 100 employees working
on project P1.

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

EXAMPLE OF AN INSERT ANOMALY

◼ Consider the relation:

◼ EMP_PROJ(Emp#, Proj#, Ename, Pname,
No_hours)
◼ Insert Anomaly:
◼ Cannot insert a project unless an employee is
assigned to it.
◼ Conversely
◼ Cannot insert an employee unless an he/she is
assigned to a project.

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

EXAMPLE OF AN DELETE ANOMALY

◼ Consider the relation:

◼ EMP_PROJ(Emp#, Proj#, Ename, Pname,
No_hours)
◼ Delete Anomaly:
◼ When a project is deleted, it will result in deleting
all the employees who work on that project.
◼ Alternately, if an employee is the sole employee on
a project, deleting that employee would result in
deleting the corresponding project.

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

Figure 10.3 Two relation schemas
suffering from update anomalies

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

Figure 10.4 Example States for
EMP_DEPT and EMP_PROJ

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

3.1 Normalization of Relations (1)
◼ Normalization:
◼ The process of decomposing unsatisfactory "bad"
relations by breaking up their attributes into
smaller relations

◼ Normal form:
◼ Condition using keys and FDs of a relation to
certify whether a relation schema is in a particular
normal form

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

Functional Dependencies (2)
◼ X -> Y holds if whenever two tuples have the same value
for X, they must have the same value for Y
◼ For any two tuples t1 and t2 in any relation instance r(R): If
t1[X]=t2[X], then t1[Y]=t2[Y]
◼ X -> Y in R specifies a constraint on all relation instances
r(R)
◼ Written as X -> Y; can be displayed graphically on a
relation schema as in Figures. ( denoted by the arrow: ).
◼ FDs are derived from the real-world constraints on the
attributes

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

Examples of FD constraints (1)
◼ Social security number determines employee
name
◼ SSN -> ENAME
◼ Project number determines project name and
location
◼ PNUMBER -> {PNAME, PLOCATION}
◼ Employee ssn and project number determines
the hours per week that the employee works on
the project
◼ {SSN, PNUMBER} -> HOURS

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe
3.2 First Normal Form
◼ Disallows
◼ composite attributes
◼ multivalued attributes
◼ nested relations; attributes whose values for an
individual tuple are non-atomic

◼ Considered to be part of the definition of relation

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

Figure 10.8 Normalization into 1NF

Dnumber Dlocation
Dname Dnumber Dmgr_ssn 1 Houston
Research 5 333445555 4 Stafford
Administrat 4 987654321 5 Bellaire
ion
5 Sugarland
Headquart 1 888665555
ers 5 Houston

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

Figure 10.9 Normalization nested
relations into 1NF

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe
Second Normal Form (1)
◼ Uses the concepts of FDs, primary key
◼ Definitions
◼ Prime attribute: An attribute that is member of the primary key K
◼ Full functional dependency: a FD Y -> Z where removal of any attribute from
Y means the FD does not hold any more
◼ Examples:
◼ {SSN, PNUMBER} -> HOURS is a full FD since neither SSN -> HOURS nor
PNUMBER -> HOURS hold
◼ {SSN, PNUMBER} -> ENAME is not a full FD (it is called a partial dependency )
since SSN -> ENAME also holds

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 10- 26

Second Normal Form (2)
◼ A relation schema R is in second normal form
(2NF) if every non-prime attribute A in R is fully
functionally dependent on the primary key

◼ R can be decomposed into 2NF relations via the

process of 2NF normalization

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 10- 27

Figure 10.10 Normalizing into 2NF and 3NF

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 10- 28

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe
Figure 10.11 Normalization into 2NF and 3NF

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 10- 31

3.4 Third Normal Form (1)
◼ Definition:
◼ Transitive functional dependency: a FD X -> Z
that can be derived from two FDs X -> Y and Y ->
Z
◼ Examples:
◼ SSN -> DMGRSSN is a transitive FD
◼ Since SSN -> DNUMBER and DNUMBER ->
DMGRSSN hold
◼ SSN -> ENAME is non-transitive
◼ Since there is no set of attributes X where SSN -> X
and X -> ENAME

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 10- 32

Third Normal Form (2)
◼ A relation schema R is in third normal form (3NF) if it is in 2NF and no non-
prime attribute A in R is transitively dependent on the primary key
◼ R can be decomposed into 3NF relations via the process of 3NF
normalization
◼ NOTE:
◼ In X -> Y and Y -> Z, with X as the primary key, we consider this a problem only
if Y is not a candidate key.
◼ When Y is a candidate key, there is no problem with the transitive dependency .
◼ E.g., Consider EMP (SSN, Emp#, Salary ).
◼ Here, SSN -> Emp# -> Salary and Emp# is a
candidate key.

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 10- 33

Normal Forms Defined Informally
◼ 1st normal form
◼ All attributes depend on the key
◼ 2nd normal form
◼ All attributes depend on the whole key
◼ 3rd normal form
◼ All attributes depend on nothing but the key

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 10- 34

4 General Normal Form Definitions (For Multiple Keys)
(1)

◼ The above definitions consider the primary key

only
◼ The following more general definitions take into
account relations with multiple candidate keys
◼ A relation schema R is in second normal form
(2NF) if every non-prime attribute A in R is fully
functionally dependent on every key of R

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 10- 35