0% found this document useful (0 votes)
9 views3 pages

Chapter 5

Chapter 5 discusses the process of normalization, which simplifies complex data structures to eliminate redundancies, detailing various normal forms including First, Second, and Third Normal Forms. It provides examples of how to transform relations into these normal forms, emphasizing functional dependencies and the importance of foreign keys for maintaining referential integrity. The chapter concludes with practical examples illustrating the application of these concepts in database design.

Uploaded by

yalewastatikie3
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
9 views3 pages

Chapter 5

Chapter 5 discusses the process of normalization, which simplifies complex data structures to eliminate redundancies, detailing various normal forms including First, Second, and Third Normal Forms. It provides examples of how to transform relations into these normal forms, emphasizing functional dependencies and the importance of foreign keys for maintaining referential integrity. The chapter concludes with practical examples illustrating the application of these concepts in database design.

Uploaded by

yalewastatikie3
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 3

Chapter 5

Normalization
 Is a process used to convert complex data structures into simple, stable data structures that do not have data
redundancies?
Different types of normalization forms:
 First normal form
 Second normal form
 Third normal form
 Up to Nth normal form

1.1 First Normal Form (1NF)


Example: the EMPLOYEE relation –employees complete training Courses.
A relation named EMPLOYEE looks like.
EMPLOYEE
Name Department Salary
Emp_ID Courses
100 A Information Technology 100000
Course Date_Completed
C++ 30/11/2003
Report Writing 15/10/2003
101 B Administration 100000
Course Date_Completed
Report Writing 20/6/2003

102 C Finance 90000


Course Date_Completed
Report Writing 20/6/2003
Investments 15/7/2003

Figure 1 – EMPLOYEE relation - not in any normal form


--To make the relation into a first normal form relation,
 Make each value in each column a simple value. Which means:
 For each relation row in the non-simple column, make a row in a new relation.
This relation is in first normal form.
EMPLOYEE1
Name Department Salary Date_Completed
Emp_ID Course
10 A Information Technology 10000 C++ 30/11/2003
10 A Information Technology 10000 Report Writing 15/10/2003
11 B Administration 10000 Report Writing 20/6/2003
12 C Finance 9000 Report Writing 20/6/2003
12 C Finance 9000 Investments 15/7/2003
Figure 2 – EMPLOYEE1 relation with sample data – in first normal form
-- Emp_ID, Department and Salary values appear in more than one row
-- So there is still redundant data in this relation.
 There is redundant data in this relation because: it contains data about two different entities –
-----Employee and Course.
 The principles of normalization can be used to divide the relation into two relations –
----- EMPLOYEE and EMP COURSE.
 In the EMP_COURSE relation, the primary key is a composite of the Emp_ID and the Course.
Chapter 5

EMP COURSE
Course Date_Completed
Emp_ID
10 C++ 30/11/2003
10 Report Writing 15/10/2003
11 Report Writing 20/6/2003
12 Report Writing 20/6/2003
12 Investments 15/7/2003
Figure 3 – EMP_COURSE relation,
Functional Dependence
A functional dependency: is a particular relationship between two attributes.
 If a value of one attribute (A) in a relation uniquely determines the value of another attribute (B) in the same
relation, then there is a functional dependency between attributes A and B.
 if we know the value of A, we can determine the value for B. In this case, B is functionally dependent on A.
 i.e. as A  B. Or, A determines B.
 An attribute can be functionally dependent on two or more attributes.
In the EMP_COURSE relation
 the value of the Date_Completed attribute cannot be determined by the Emp_ID alone or the Course value alone
 Because the Date_Completed is a characteristic of an Employee taking a Course.
o The Date_Completed depends on the combination of the Emp_ID and Course values.
1.2 Second Normal Form (2NF)
A relation is in second normal form (2NF)
 If every non-primary-key attribute is functionally dependent on the whole primary key.
o Figure 2, is in 1NF. the primary key consists of Emp_ID and Course.
o EMPLOYEE1 (Emp_ID,Name,Department,Salary,Course,Date_Completed)
o The functional dependencies here are:
Emp_IDName,Department,Salary
Emp_ID,CourseDate_Completed
We can say that second normal form is satisfied if:
1. The primary key consists of only one attribute
2. No non-primary-key attributes exist in the relation.
3. Every non-primary-key attribute is functionally dependent on the full set of primary key attributes.

o To convert a relation to second normal form:


 Remove the functional dependencies that violate the rules.
 The relation needs to be decomposed into new relations.
 The new relations are based on the determinants
– The determinants are the primary keys of the new relations.
 if we take the functional dependencies, the new relations will be:
Emp_IDName,Department,Salary
Emp_ID,CourseDate_Completed
o And make a new relation from its attributes - EMPLOYEE (Emp_ID, Name, Department, Salary)
o Second new relation EMP_COURSE (Emp_ID, Course, Date_Completed)
Now all non-primary-key attributes are functionally dependent on the whole primary key: 2 nd normal form.

1.3 Third Normal Form (3NF)


 A relation is in third normal form (3NF) if :
 it is in second normal form and
 There are not functional dependencies between two (or more) non-primary-key attributes.
A functional dependency between non-primary-key attributes is also called a transitive dependency.
o The EMPLOYEE and EMP_COURSE relations are in 3NF because there are no functional dependencies
between the non-primary-key attributes.
Chapter 5

E.g., a relation named VEHICLE, VEHICLE (Registration_No, Owner, Model, Manufacturer, Engine_Size)

This relation is in 2NF because the Registration_No uniquely determines the value of the Owner, Model,
Manufacturer and Engine_Size.
Owner Model Manufacturer Engine_Size
Registration_No
10234 TDA Land Cruiser I Toyota 2.5
10545 REST Land Cruiser II Toyota 2.9
45454 TDA Jeep Nissan 2.5
46765 REST Land Cruiser I Toyota 2.5
54098 Mekelle University Jeep Nissan 2.5
Figure 4 – VEHICLE relation – in 2NF
 There are functional dependences between some of the non-primary-key attributes.
 The model determines the manufacturer and engine_size. Model manufacturer, engine_size.
Because of this functional dependency, the VEHICLE relation is not in 3NF.
To convert the relation to 3NF,
 Remove the functional dependency. by creating a new relation using the attributes in the dependency, with
the determinant attribute(s) being the primary key of the new relation:
VEHICLE1 (Model, Manufacturer, Engine_Size)
REGISTRATION (Registration_No, Owner, Model)
Now Both the VEHICLE1 and REGISTRATION relations are in 3NF because
 they are in 2NF (every non-primay-key attribute is functionally dependent on the whole primary key)
 There are no dependencies between non-primary-key attributes.

1.4 Foreign Keys & Referential Integrity


A foreign key:
 Is an attribute that appears as a non-primary-key attribute in one relation and as a primary key
attribute in another relation.
 is indicated with a dashed underline:
E.g. in the VEHICLE1 relation above, Model is the primary key. Model is also an attribute in the
REGISTRATION relation – this makes it a foreign key.
REGISTRATION (Registration_No, Owner, Model)
 when we say a foreign key must satisfy referential integrity:
– It means that the values of an attribute in one relation depend on the values of the same attribute in
another relation.
E.g. the values of Model in the REGISTRATION relation must be a value that exists in the Model attribute in the
VEHICLE1 relation.

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy