Chapter 4

Logical Database Design

Redundancy, Data Anomaly and Normalization

 Topics
Topics Subtopics
4. 4.3. Redundancy and Data Anomaly

Logical 4.3.1.Functional Dependency (FD)

4.3.2.Normalization
Database
4.3.3.Purpose of normalization
Design
4.4. Process of Normalization (1NF, 2NF, 3NF, BCNF)
4.4.1.Unnormalized Form
4.4.1.1. NF- First Normal Form
4.4.1.2. NF- Second Normal Form (2NF)
4.4.1.3. 3NF- Third Normal Form
4.4.1.4. Boyce–Codd Normal Form (BCNF)
4.4.1.5. Multivalued Dependency and Fourth Normal Form
4.4.1.6. Join Dependencies and Fifth Normal Form
4.5 Pitfalls of Normalization
4.6. Denormalization

2
Mekonnen K.
 What is Redundancy?
▪ Redundancy refers to the duplication of data within a database system. While some degree of
redundancy is inevitable and even necessary for efficient data retrieval, excessive redundancy can lead
to various issues, including
- increased storage requirements,
- data inconsistency, and
- decreased performance.
▪ Redundancy in a DBMS refers to the storage of the same piece of data in multiple places.
▪ It can arise due to various reasons, such as
- denormalized database design,
- a lack of proper data modeling, and
- the replication of data for backup or distribution purposes.
Mekonnen K. 3
Redundancy

▪ Row Level Redundancy:

▪ This occurs when entire rows (records) in a table are repeated or contain very similar information.

▪ If the SID is primary key to each row, you can

SID SName Age
use it to remove the duplicates as shown
1 Jojo 20 below:
2 Kit 25 SID SName Age

1 Jojo 20 1 Jojo 20
2 Kit 25

Mekonnen K.
4
Redundancy (Cont..)
▪ Column Level Redundancy:
▪ This happens when attributes (columns) store repetitive or derived information that can be
obtained from other columns or tables.
▪ Now Rows are same but in column level because of Sid is primary key but columns are same.
Redundant
Sid Sname Cid Cname Fid Fname Salary Column
Values
1 AA C1 DBMS F1 Jojo 30000

2 BB C2 JAVA F2 KK 50000

3 CC C1 DBMS F1 Jojo 30000

4 DD C1 DBMS F1 Jojo 30000

Mekonnen K. 5
What is an Anomaly?
▪ Problems that can occur in poorly planned, unnormalized databases where all the
data is stored in one table (a flat-file database).

▪ Types of Anomalies:

• Insert

• Delete

• Update

Mekonnen K. 6
Anomalies in DBMS

▪ Insert Anomaly : An Insert Anomaly occurs when certain attributes cannot be inserted into the
database without the presence of other attributes.

▪ Delete Anomaly: A Delete Anomaly exists when certain attributes are lost because of the deletion
of other attributes.

▪ Update Anomaly: An Update Anomaly exists when one or more instances of duplicated data is
updated, but not all.

Mekonnen K. 7
Anomaly Example
▪ Below table University consists of seven attributes: Sid, Sname, Cid, Cname, Fid,
Fname, and Salary. And the Sid acts as a key attribute or a primary key in the relation.

Mekonnen K. 8
Insertion Anomaly
▪ Suppose a new faculty joins the University, and the Database Administrator inserts the faculty data
into the above table. But he is not able to insert because Sid is a primary key, and can’t be NULL.
So, this type of anomaly is known as an insertion anomaly.

Mekonnen K. 9
Delete Anomaly
▪ When the Database Administrator wants to delete the student details of Sid=2 from the above table,
then it will delete the faculty and course information too which cannot be recovered further.
SQL:
DELETE FROM University WHERE Sid=2;

Mekonnen K. 10
Update Anomaly
▪ When the Database Administrator wants to change the salary of faculty F1 from 30000 to 40000 in
above table University, then the database will update salary in more than one row due to data
redundancy. So, this is an update anomaly in a table.
SQL:
UPDATE University
SET Salary= 40000
WHERE Fid=“F1”;

• To remove all these anomalies, we need to normalize the

data in the database.

Mekonnen K. 11
What is Functional Dependency?
▪ A functional dependency (FD) is a relationship between two attributes, typically between the primary
key and other non-key attributes within a table.

▪ A functional dependency denoted by X→Y , is an association between two sets of attribute X and Y.

Here, X is called the determinant, and Y is called the dependent.

▪ For example,

▪ SIN ———-> Name, Address, Birthdate

▪ Here, SIN determines Name, Address and Birthdate. So, SIN is the determinant and
Name, Address and Birthdate are the dependents.

Mekonnen K. 12
Functional Dependency
▪ Types of functional dependency

▪ The following are types functional dependency in DBMS:

1. Fully-Functional Dependency

2. Partial Dependency

3. Transitive Dependency

4. Trivial Dependency

5. Multivalued Dependency

Mekonnen K. 13
 Functional Dependency
1. Full functional Dependency
▪ A functional dependency X → Y is said to be a full functional dependency if Y is
functionally dependent on X, and not on any proper subset of X.
- If you remove any attribute A from X, the dependency no longer holds.
- This means Y depends on the entire set X, and not just a part of it.

▪ For example,

- {Emp_num, Proj_num} → Hour is a full functional dependency. Here, Hour is the

working time by an employee in a project.

Mekonnen K. 14
 Functional Dependency
2. Partial functional Dependency
▪ A partial functional dependency occurs when a non-prime attribute is functionally dependent on part
(but not all) of a candidate key.
- Let X → Y be a functional dependency.
- If X is a composite candidate key (i.e., consists of two or more attributes), and
- There exists a proper subset A of X such that A → Y also holds,
- Then X → Y is a partial dependency, because Y is not fully dependent on the whole of X, just a
part of it.
- For example,
- If {Emp_num,Proj_num} → Emp_name but also Emp_num → Emp_name then Emp_name is
partially functionally dependent on {Empl_num,Proj_num}.
Mekonnen K. 15
 Functional Dependency
2. Partial functional Dependency

Mekonnen K. 16
 Functional Dependency
3. 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.

Mekonnen K. 17
 Functional Dependency
3. Transitive Dependency
EmpNum → DeptNum

EmpNum EmpEmail DeptNum DeptNname

DeptNum → DeptName

EmpNum EmpEmail DeptNum DeptNname

DeptName is transitively dependent on EmpNum via DeptNum

EmpNum → DeptName
Mekonnen K. 18
 Functional Dependency
4. Trivial Dependency
▪ A functional dependency X → Y is said to be a trivial functional dependency if Y is a subset of X.

▪ For example,
▪ {Emp_num,Emp_name} → Emp_num is a trivial functional dependency since Emp_num is a subset of
{Emp_num,Emp_name}.

5. Multivalued Dependency

▪ Multivalued dependency occurs in the situation where there are multiple independent multivalued
attributes in a single table.

▪ A multivalued dependency is a complete constraint between two sets of attributes in a relation. It

requires that certain tuples be present in a relation.
Mekonnen K. 19
 Functional Dependency
▪ Example: Consider the following table

▪ The functional dependencies

▪ car_model -> manufr_year

▪ car_model-> colour are multivalued dependency since manufr_year and color both
are multivalued attribute.

Mekonnen K. 20
What is Normalization ?
▪ Normalization is the process of identifying the logical associations between data items and designing

a database that will represent such associations but without any type of anomalies.

▪ It is a database design technique that organizes tables in a manner that reduces redundancy and
dependency of data.

▪ Normalization is used to avoid redundancy and the problems arising out of redundancy.

▪ Normalization is the process of structuring and handling the relationship between data to minimize
redundancy in the relational table and avoid the unnecessary anomalies properties from the database like
insertion, update and delete.

▪ It helps to divide large database tables into smaller tables and make a relationship between them.

▪ It can remove the redundant data and ease to add, manipulate or delete table fields.

Mekonnen K. 21
What is Normalization ?

• Concept of normalization was introduced by Edgar.F. Codd

(known as the father of the relational data model) as the
basis for database design.

• He defined first, second and third normal forms depending

on the constraints each normalization form satisfies.

Mekonnen K.
22
Purpose of Normalization
▪ Normalization is the process of efficiently organizing data in a database.

▪ There are two goals of the normalization process:

1. Eliminating redundant data (for example, storing the same data in more than
one table)

2. Ensuring data dependencies make sense (only storing related data in a table)

▪ Both of these are worthy goals as they reduce the amount of space a database
consumes and ensure that data is logically stored.

Mekonnen K. 23
 Purpose of Normalization

▪ The benefits of using a database that has a suitable set of relations is that the
database will be:
1. Easier for the user to access and maintain the data;

2. Take up minimal storage space on the computer.

Mekonnen K. 24
Normal forms
▪ A normalization defines rules for the relational table as to whether it
satisfies the normal form.
▪ We have various levels or steps in normalization called Normal Forms.
▪ A normal form is a process that evaluates each relation against defined
criteria and removes the multivalued, joins, functional and trivial
dependency from a relation.
▪ The level of complexity, the strength of the rule, and decomposition
increase as we move from one lower-level Normal Form to the higher.
▪ A table in a relational database is said to be in a certain normal form if it
satisfies certain constraints.
▪ If any data is updated, deleted or inserted, it does not cause any problem
for database tables and help to improve the relational table' integrity and
efficiency.

Mekonnen K. 25
Normal forms

▪ The Theory of Data Normalization in SQL is still being developed further. For example, there are

discussions even on 6th Normal Form.

▪ However, in most practical applications, normalization achieves its best in 3rd Normal Form.

The evolution of Normalization theories is illustrated below-

Database Normalization

Mekonnen K. 26
First Normal Form (1NF)

• A relation is said to be in first normal form (INF) if and only if :

⚬ All underlying domains contain atomic values only (It does
not allow Composite attributes and multivalued attributes)
⚬ No repeating group or Attribute.
⚬ Create a Separate table for each set of data
⚬ Create a primary key for each set of data

Mekonnen K. 27
First Normal Form (1NF)

• Normalize the below Unnormalized Table (UNF):

Mekonnen K. 28
First Normal Form (1NF)

• Each cell must contain a single/atomic value.

⚬ Remove multiple values in any cell.

Mekonnen K. 29
1NF Example

▪ Example:

The following Course_Content relation is not in 1NF because the Content attribute contains
multiple values.

Mekonnen K. 30
1NF Example (Cont..)

▪ The below relation student is in 1NF:

Mekonnen K. 31
Second Normal Form (2NF)

• A table (relation) is in 2NF, if

⚬ It is in 1NF
⚬ No partial dependency

Mekonnen K. 32
Prime and Non Prime Attributes
Prime attributes: The attributes which are used to form a candidate key are called prime attributes.

Non-Prime attributes: The attributes which do not form a candidate key are called non-prime
attributes.

▪ Prime Attribute: Roll No., Course Code

▪ Non-Prime Attribute: First Name of Student, Last Name of Student

Mekonnen K. 33
Second Normal Form (2NF)
• Steps to achieve 2NF:
⚬ Ensure the table is in 1NF.
⚬ Remove partial dependencies (attributes must depend on the whole
primary key).

Mekonnen K. 34
Second Normal Form (2NF)

Mekonnen K. 35
Example 2NF

▪ The Course Name depends on only CourseID, a part of the primary key
not the whole primary {CourseID, SemesterID}.It’s called partial dependency.

▪ Solution:
▪ Remove CourseID and Course Name together to create a new table.
Mekonnen K. 36
 CourseID SemesterID Num Student
Example 2NF (Cont..) IT101 201301 25
IT101 201302 25
IT102 201301 30
IT102 201302 35
IT103 201401 20

Done? Oh no, it is still not in CourseID Course Name

1NF yet. IT101 Database
Remove the repeating IT102 Web Prog
groups too. IT103 Networking
Finally, connect the
relationship.
Mekonnen K. 37
Third Normal Form (3NF)

• A table (relation) is in 3NF, if

⚬ It is in 2NF
⚬ No transitive dependencies.

Mekonnen K. 38
Third Normal Form (3NF)

• Convert the table to 3NF

Mekonnen K. 39
Third Normal Form (3NF)

Mekonnen K. 40
 Example 3NF

Solution:
Remove Teacher Name and Teacher Tel together The Teacher Tel is a nonkey attribute, and
to create a new table. the Teacher Name is also a nonkey atttribute.
But Teacher Tel depends on Teacher Name.
It is called transitive dependency.

Mekonnen K. 41
 StudyID Course Name T.ID
Example 3NF 1 Database T1
2 Database T2
3 Web Prog T3
4 Web Prog T3
5 Networking T4
Done?
Oh no, it is still not
in 1NF yet.
Remove Repeating
row. ID Teacher Name Teacher Tel
Note about primary key:
T1 Sok Piseth 012 123 456
- In theory, you can choose
Teacher Name to be a primary key. T2 Sao Kanha 0977 322 111
- But in practice, you should add T3 Chan Veasna 012 412 333
Teacher ID as the primary key. T4 Pou Sambath 077 545 221

Mekonnen K. 42
 Boyce Codd Normal Form(BCNF)
▪ Boyce Codd normal form (BCNF) - is the advance version of 3NF. It is stricter than 3NF.

▪ A table is in BCNF if every functional dependency X → Y, X is the super key of the table.

▪ For BCNF, the table should be in 3NF, and for every FD, LHS is super key.

▪ Example: assume there is a company where employees work in more than one department.
EMPLOYEE table:

EMP_ID EMP_COUNTRY EMP_DEPT DEPT_TYPE EMP_DEPT_NO

264 India Designing D394 283

264 India Testing D394 300

364 UK Stores D283 232

364 UK Developing D283 549

Mekonnen K. 43
Boyce Codd Normal Form(BCNF)

▪ In the above table Functional dependencies are as follows:

▪ EMP_ID → EMP_COUNTRY

▪ EMP_DEPT → {DEPT_TYPE, EMP_DEPT_NO}

▪ Candidate key: {EMP-ID, EMP-DEPT}

▪ The table is not in BCNF because neither EMP_DEPT nor EMP_ID alone are keys.

Mekonnen K.
44
Boyce Codd Normal Form(BCNF)
▪ To convert the given table into BCNF, we decompose it into three tables:

EMP_COUNTRY table: EMP_DEPT table:

EMP_DEPT DEPT_TYPE EMP_DEPT_NO
EMP_ID EMP_COUNTRY
Designing D394 283
264 India Testing D394 300
264 India Stores D283 232
Developing D283 549
EMP_DEPT_MAPPING table:
EMP_ID EMP_DEPT
D394 283
D394 300
D283 232
D283 549
Mekonnen K. 45
Boyce Codd Normal Form(BCNF)
▪ Functional dependencies:

1. EMP_ID → EMP_COUNTRY

2. EMP_DEPT → {DEPT_TYPE, EMP_DEPT_NO}

▪ Candidate keys:

▪ For the first table: EMP_ID

▪ For the second table: EMP_DEPT

▪ For the third table: {EMP_ID, EMP_DEPT}

▪ Now, this is in BCNF because left side part of both the functional dependencies is a key.

Mekonnen K. 46
 Forth Normal Form (4NF)
▪ A relation will be in 4NF if it is in Boyce Codd normal form and has no multi-valued
dependency.

▪ For a dependency A → B, if for a single value of A, multiple values of B exists, then

the relation will be a multi-valued dependency.
• Example STUDENT
STU_ID COURSE HOBBY
21 Computer Dancing
21 Math Singing
34 Chemistry Dancing
74 Biology Cricket
59 Physics Hockey
Mekonnen K. 47
 Forth Normal Form (4NF)

▪ The given STUDENT table is in 3NF, but the COURSE and HOBBY are two independent entity.

Hence, there is no relationship between COURSE and HOBBY.

▪ In the STUDENT relation, a student with STU_ID, 21 contains two courses, Computer and Math

and two hobbies, Dancing and Singing. So, there is a Multi-valued dependency on STU_ID, which

leads to unnecessary repetition of data.

Mekonnen K. 48
Forth Normal Form (4NF)

▪ So, to make the above table into 4NF, we can decompose it into two tables:

STUDENT_COURSE STUDENT_HOBBY

STU_ID COURSE STU_ID HOBBY

21 Computer 21 Dancing
21 Math 21 Singing
34 Chemistry 34 Dancing
74 Biology 74 Cricket
59 Physics 59 Hockey

Mekonnen K. 49
 Denormalization

▪ Denormalization is a database optimization technique where we add redundant data

in the database to get rid of the complex join operations.

▪ This is done to speed up database access speed.

▪ Denormalization is done after normalization for improving the performance of the

database.

▪ The data from one table is included in another table to reduce the number of joins in
the query and hence helps in speeding up the performance.

Mekonnen K. 50
Denormalization
▪ A denormalized database should never be confused by a database that has never been
normalized.

▪ Example: Suppose after normalization we have two tables first, Student table and second, Branch
table. The student has the attributes as Roll_no , Student-name , Age , and Branch_id .

Mekonnen K. 51
 Denormalization
▪ The branch table is related to the Student table with Branch_id as the foreign key in the Student table.

► If we want the name of students along with the name of the branch name then we need to perform
a join operation. The problem here is that if the table is large, we need a lot of time to perform the
join operations. So, we can add the data of Branch_name from Branch table to the Student table
and this will help in reducing the time that would have been used in join operation and thus
optimize the database.
Mekonnen K. 52
Denormalization

▪ Advantages of Denormalization

▪ Query execution is fast since we have to join fewer tables.

▪ Disadvantages of Denormalization

1. As data redundancy is there, update and insert operations are more expensive and take more
time. Since we are not performing normalization, so this will result in redundant data.

2. Data Integrity is not maintained in denormalization. As there is redundancy so data can be

inconsistent.

Mekonnen K.
53
 Conclusion

• Generally, even though there are other four additional levels

of Normalization, a table is said to be normalized if it
reaches 3NF.
• A database with all tables in the 3NF is said to be a
Normalized Database.

Mekonnen K. 54
 Exercise

1. Normalize the table using 1NF, 2NF, and 3NF

Mekonnen K. 55
 Exercise
2. StudentID is the primary key. Is it 1NF? How can you make it 1NF?

Mekonnen K. 56
Mekonnen K. 57