DATABASE SYSTEM CONCEPTS (6th Edition)-Abraham Silberschatz

Chapter 8: Relational Database Design

Farhana Akter Sunny
Sr. Lecturer
Dept. of Computer Science and Engineering
Normalization of Database
Database Normalization is a technique of organizing the data in the
database.
Normalization is a systematic approach of decomposing tables to
eliminate data redundancy and data integrity like Insertion, Update and
Deletion Anomalies.
It is a multi-step process that puts data into tabular form by removing
duplicated data from the relation tables.

Normalization is used for mainly two purpose,

Eliminating redundant(useless) data.
Ensuring data dependencies make sense i.e data is logically stored.
Normalization of Database
 Normalization is a process that “improves” a database
design by generating relations that are of higher normal
forms.

 The objective of normalization:

“to create relations where every dependency is on the key,

the whole key, and nothing but the key”.
Updating Anomaly : To update address of a student who occurs twice or more
than twice in a table, we will have to update S_Address column in all the rows,
else data will become inconsistent.

Insertion Anomaly : Suppose for a new admission, we have a Student id(S_id),

name and address of a student but if student has not opted for any subjects yet
then we have to insert NULL there, leading to Insertion Anomaly.

Deletion Anomaly : If (S_id) 401 has only one subject and temporarily he drops
it, when we delete that row, entire student record will be deleted along with it.
Normalization
There is a sequence to normal forms:
1NF is considered the weakest,
2NF is stronger than 1NF,
3NF is stronger than 2NF, and
BCNF is considered the strongest

Also,
any relation that is in BCNF, is in 3NF;
any relation in 3NF is in 2NF; and
any relation in 2NF is in 1NF.
Normalization
1NF a relation in BCNF, is also
in 3NF
2NF a relation in 3NF is also in
2NF
3NF
a relation in 2NF is also in
1NF
BCNF
Normalization of Database
 We consider a relation in BCNF to be fully normalized.
 The benefit of higher normal forms is that update
semantics for the affected data are simplified.
 This means that applications required to maintain the
database are simpler.
 A design that has a lower normal form than another
design has more redundancy. Uncontrolled redundancy
can lead to data integrity problems.

First we introduce the concept of functional dependency

Functional Dependencies
We say an attribute, B, has a functional dependency on another
attribute, A, if for any two records, which have the same value
for A, then the values for B in these two records must be the
same. We illustrate this as:
AB
Example: Suppose we keep track of employee email
addresses, and we only track one email address for each
employee. Suppose each employee is identified by their
unique employee number. We say there is a functional
dependency of email address on employee number:

employee number  email address

 Functional Dependencies
EmpNum EmpEmail EmpFname EmpLname
123 [email protected] John Doe
456 [email protected] Peter Smith
555 [email protected] Alan Lee
633 [email protected] Peter Doe
787 [email protected] Alan Lee

If EmpNum is the PK then the FDs:

EmpNum  EmpEmail
EmpNum  EmpFname
EmpNum  EmpLname
must exist.
Functional Dependencies
EmpNum  EmpEmail 3 different ways
EmpNum  EmpFname you might see FDs
EmpNum  EmpLname depicted
EmpEmail
EmpNum EmpFname
EmpLname

EmpNum EmpEmail EmpFname EmpLname

Determinant
Functional Dependency

EmpNum  EmpEmail

Attribute on the LHS is known as the determinant

• EmpNum is a determinant of EmpEmail
Transitive dependency
Consider attributes A, B, and C, and where
A  B and B  C.
Functional dependencies are transitive, which means
that we also have the functional dependency AC
We say that C is transitively dependent on A through
B.
Transitive dependency
EmpNum  DeptNum

EmpNum EmpEmail DeptNum DeptNname

DeptNum  DeptName

EmpNum EmpEmail DeptNum DeptNname

DeptName is transitively dependent on EmpNum via DeptNum

EmpNum  DeptName
 Partial dependency
A partial dependency exists when an attribute B is functionally
dependent on an attribute A, and A is a component of a multipart
candidate key.

InvNum LineNum Qty InvDate

Candidate keys: {InvNum, LineNum} InvDate is partially

dependent on {InvNum, LineNum} as InvNum is a determinant
of InvDate and InvNum is part of a candidate key
First Normal Form
First Normal Form
We say a relation is in 1NF if all values stored in the
relation are single-valued and atomic.

1NF places restrictions on the structure of relations.

Values must be simple.
First Normal Form
The following in not in 1NF
EmpNum EmpPhone EmpDegrees
123 233-9876
333 233-1231 BA, BSc, PhD
679 233-1231 BSc, MSc

EmpDegrees is a multi-valued field:

employee 679 has two degrees: BSc and MSc
employee 333 has three degrees: BA, BSc, PhD
First Normal Form
EmpNum EmpPhone EmpDegrees
123 233-9876
333 233-1231 BA, BSc, PhD
679 233-1231 BSc, MSc

To obtain 1NF relations we must, without loss of

information, replace the above with two relations -
see next slide
 First Normal Form
Employee EmployeeDegree
EmpNum EmpPhone EmpNum EmpDegree
123 233-9876 333 BA
333 233-1231 333 BSc
679 233-1231 333 PhD
679 BSc
679 MSc
An outer join between Employee and EmployeeDegree will
produce the information we saw before
Second Normal Form
A relation is in 2NF if it is in 1NF, and every non-key
attribute is fully dependent on each candidate key. (That is, we
don’t have any partial functional dependency.)

• 2NF (and 3NF) both involve the concepts of key and

non-key attributes.
• A key attribute is any attribute that is part of a key;
any attribute that is not a key attribute, is a non-key attribute.
• Relations that are not in BCNF have data redundancies
• A relation in 2NF will not have any partial dependencies
 Second Normal Form
Consider this InvLine table (in 1NF):
InvNum LineNum ProdNum Qty InvDate
InvNum, LineNum ProdNum, Qty
There are two
candidate keys.
Qty is the only non-
key attribute, and it is
InvNum InvDate
dependent on InvNum
Since there is a determinant that is not a
candidate key, InvLine is not BCNF
InvLine is
InvLine is not 2NF since there is a partial only in 1NF
dependency of InvDate on InvNum
 Second Normal Form
InvLine
InvNum LineNum ProdNum Qty InvDate
The above relation has redundancies: the invoice date is
repeated on each invoice line.
We can improve the database by decomposing the relation
into two relations:
InvNum LineNum ProdNum Qty

InvNum InvDate

Question: What is the highest normal form for these

relations? 2NF? 3NF? BCNF?
Is the following relation in 2NF?

inv_no line_no prod_no prod_desc qty

2NF, but not in 3NF, nor in BCNF:

EmployeeDept
ename ssn bdate address dnumber dname

since dnumber is not a candidate key and we have:

dnumber  dname.
 Third Normal Form
• A relation is in 3NF if the relation is in 1NF and all determinants of non-key
attributes are candidate keys
That is, for any functional dependency: X  Y, where Y is a non-key
attribute (or a set of non-key attributes), X is a candidate key.

• This definition of 3NF differs from BCNF only in the specification of non-
key attributes - 3NF is weaker than BCNF. (BCNF requires all determinants
to be candidate keys.)

• A relation in 3NF will not have any transitive dependencies

of non-key attribute on a candidate key through another non-key attribute.
 Third Normal Form
Consider this Employee relation Candidate keys
are? …

EmpNum EmpName DeptNum DeptName

EmpName, DeptNum, and DeptName are non-key attributes.

DeptNum determines DeptName, a non-key attribute, and
DeptNum is not a candidate key.

Is the relation in 3NF? … no Is the relation in BCNF? … no

Is the relation in 2NF? … yes
 Third Normal Form
EmpNum EmpName DeptNum DeptName

We correct the situation by decomposing the original relation

into two 3NF relations. Note the decomposition is lossless.

EmpNum EmpName DeptNum DeptNum DeptName

Verify these two relations are in 3NF.

 In 3NF, but not in BCNF:

Instructor teaches one

course only.
student_no course_no instr_no
Student takes a course
and has one instructor.

{student_no, course_no}  instr_no

instr_no  course_no

since we have instr_no  course-no, but instr_no is not a

Candidate key.
 student_no course_no instr_no

BC
NF

student_no instr_no

course_no instr_no

{student_no, instr_no}  student_no

{student_no, instr_no}  instr_no
instr_no  course_no
Normalization Rule
Normalization rule are divided into following normal form.
First Normal Form
Second Normal Form
Third Normal Form
BCNF
As per First Normal Form, no two Rows of data must contain repeating group
of information i.e each set of column must have a unique value, such that
multiple columns cannot be used to fetch the same row. Each table should be
organized into rows, and each row should have a primary key that
distinguishes it as unique.

The Primary key is usually a single column, but sometimes more than one
column can be combined to create a single primary key. For example consider
a table which is not in First normal form
Second Normal Form (2NF)
As per the Second Normal Form there must not be any partial dependency
of any column on primary key. It means that for a table that has
concatenated primary key, each column in the table that is not part of the
primary key must depend upon the entire concatenated key for its
existence. If any column depends only on one part of the concatenated key,
then the table fails Second normal form.

In example of First Normal Form there are two rows for Adam, to include
multiple subjects that he has opted for. While this is searchable, and follows
First normal form, it is an inefficient use of space. Also in the above Table in
First Normal Form, while the candidate key is {Student, Subject}, Age of
Student only depends on Student column, which is incorrect as per Second
Normal Form. To achieve second normal form, it would be helpful to split
out the subjects into an independent table, and match them up using the
student names as foreign keys.
Third Normal Form (3NF)
Third Normal form applies that every non-prime attribute of table must
be dependent on primary key, or we can say that, there should not be
the case that a non-prime attribute is determined by another non-
prime attribute. So this transitive functional dependency should be
removed from the table and also the table must be in Second Normal
form. For example, consider a table with following fields.

The advantage of removing transitive dependency is,

Amount of data duplication is reduced.
Data integrity achieved.
Boyce and Codd Normal Form (BCNF)
Boyce and Codd Normal Form is a higher version of the Third Normal
form. This form deals with certain type of anamoly that is not handled
by 3NF. A 3NF table which does not have multiple overlapping
candidate keys is said to be in BCNF. For a table to be in BCNF, following
conditions must be satisfied:

R must be in 3rd Normal Form

and, for each functional dependency ( X -> Y ), X should be a super Key.
Relation without Normalization
1NF
2NF
Non prime/non key attribute, cloud not depend on subset
of candidate key
Candidate key {studentid, name}
Subset studentid
2NF
3NF
3NF
 References

http://www.studytonight.com/dbms/database-normalization.php
http://beginnersbook.com/2015/05/normalization-in-dbms/

In Bengali..
http://subeen.com/%E0%A6%A8%E0%A6%B0%E0%A6%AE%E0%A6%BE%E0%A6%B2%E0%A6%BE%E0%A6%87%E0%A6%9C%E0%A7%8
7%E0%A6%B6%E0%A6%A8
%E0%A6%A1%E0%A6%BE%E0%A6%9F%E0%A6%BE%E0%A6%AC%E0%A7%87%E0%A6%9C/
 What you have learn from this
lecture?

Discuss with your Learning

Partner.

48