Chapter Five

Fundamental of Database System

CHAPTER FIVE
DATABASE DESIGN with NORMALIZATION

Zerihun E.

1
 Chapter Five

Logical Database Design

• Converting ER Diagram to Relational Tables (Three basic rules)

• 1. For a relationship with One-to-One Cardinality: All the attributes are merged into a
single table. one can post the primary key or candidate key of one of the relations to the
other as a foreign key.
• 2. For a relationship with One-to-Many Cardinality: Post the primary key or cardinality
key from the "one" side as a foreign key attribute to the "many" side.
• 3. For a relationship with Many-to-Many Cardinality: Create a new table and post the
primary key or cardinality key from each entity as attributes in the new table along with
some additional attributes.

2
 Chapter Five

Cont…

• After converting the ER diagram into table forms. the next phase is implementing the
process of normalization.

3
 Chapter Five

Cont.

• Normalization: is essentially the process of taking a wide table with lots of columns but
few rows and redesigning it as several narrow tables with fewer columns but more rows.
• Normalization is a process of organizing the data in database to avoid data redundancy,
insertion anomaly, update anomaly & deletion anomaly
• A properly normalized design allows you to use:-
• Eliminate redundant data
• Reduce or eliminate inconsistent data and
• Ease the data maintenance burden.
4
 Chapter Five

Normalization

• A properly normalized design allows you to use storage space efficiently, eliminate
redundant data and ease the data maintenance burden.

Problems with unnormalized structure

• Insertion Anomalies
• Deletion Anomalies
• Updating Anomalies

5
 Chapter Five

Cont.

• Insertion Anomalies
• Example: StudentID , StudentName, dept, depthead, deptphone
studId Stud_name dept Dept_head dept_phone

11 Yohannes CS Melaku +2511110365

12 Abebe CS Melaku +2511110365
33 Tewodros CS Melaku 2511110365
44 Nati CS Melaku 2511110365

• To insert new data in every row there is insertion anomalies

6
 Chapter Five

Cont.

• Deletion Anomalies
• Example: StudentID , StudentName, dept, depthead, deptphone
studId Stud_name dept Dept_head dept_phone

11 Yohannes CS Melaku +2511110365

12 Abebe CS Melaku +2511110365
33 Tewodros CS Melaku 2511110365
44 Nati CS Melaku 2511110365

• When we delete student information department information also deleted.

• This is Deletion anomalies
7
 Chapter Five

Cont.

• Updation Anomalies
• Example: StudentID , StudentName, dept, depthead, deptphone
studId Stud_name dept Dept_head dept_phone

11 Yohannes CS Melaku +2511110365

12 Abebe CS Melaku +2511110365
33 Tewodros CS Melaku 2511110365
44 Nati CS Melaku 2511110365

• When we delete Dept head and one single row missed there will have updation anomalies.

8
 Chapter Five

Functional Dependency (FD)

• The logical associations between data items and one item is functional dependent to
another item called functional dependency.

• Two data items A and B are said to be in a determinant or dependent relationship if

certain values of data item B always appears with certain values of data item A.

• The notation is: A->B which is read as; B is functionally dependent on A.

• A functional dependency is a relationship among attributes In relational database, and
one id depends with the other.

9
 Chapter Five

Functional Dependency (FD)

• Example:

1
0
 Chapter Five

Functional Dependency (FD)

Example:

• Dinner->Wine: Since the type of Wine served depends on the type of Dinner, we say
Wine is functionally dependent on Dinner.

• Both Wine type and Fork type are determined by the Dinner.
• Dinner->Wine
• Dinner-Fork

1
1
 Chapter Five

Forms of Normalization

• Relational database theorists have divided normalization into several rules called
Normal forms.

• First Normal Form : No repeating groups.

• Second Normal Form : No non-key attributes depend on a portion of the primary
key.

• Third Normal Form : No attributes depend on other non-key attributes.

1
2
 Chapter Five

Forms of Normalization

• First Normal Form

• There are no repeating groups
• All the key attributes are defined
• All attributes are dependent on the primary key

1
3
 Chapter Five

Forms of Normalization

Example: what's a repeating group?:

• StudentName
• AdvisorName
• CourseID1
• CourseDescription1
• CourseInstructorName1
• CourseID2
• CourseDescription2
• CourseInstructorName2

1
4
 Chapter Five

Forms of Normalization

• The primary keys are shown in italics.

• The repeating group of columns in the original table is eliminated

• There is student table and Course table
15
 Chapter Five

Forms of Normalization

• Second Normal Form

• It's in 1st normal form
• It includes no partial dependencies:where an attribute is dependent on only a part
of a primary key

• No non-key attributes depend on a portion of the primary key.

16
 Chapter Five

Forms of Normalization

• Second Normal Form

• Example: In the StudentCourses table, the primary key is the combination of
SCStudentID and SCCourseID

17
 Chapter Five

Forms of Normalization

• Third Normal Form

• It's in 2nd normal form
• It contains no transitive dependencies (where a non-key attribute is dependent on
another non-key attribute).

• No attributes depend on other non key attributes.

18
 Chapter Five

Forms of Normalization

• Third Normal Form

• Example: all the columns in the table contain data about the entity that is defined by the
primary key.
• The columns in the table must contain data about only one thing.
• To complete the normalization, we need to look for columns that are not dependent on the
primary key of the table.
• In the Students table, we have two data items about the student's advisor:
• The same logic applies to the instructor information in the Courses table.
• The data for the instructor is not dependent on the primary key CourseID.
19
 Chapter Five

Forms of Normalization

• Third Normal Form

20
 Chapter Five

• Pitfalls(Problems) of Normalization
• Requires data to see the problems
• May reduce performance of the system
• Is time consuming,
• Difficult to design and apply
Don't go overboard with Third Normal Form or you'll result in destruction on
performance.

21
 Chapter Five

Denormalization

• Denormalization is a technique to move from higher to lower normal forms of

database modeling in order to speed up database access.
• Considered the following before Denormalizing.
• can the system achieve acceptable performance without denormalizing?
• will the performance of the system after denormalizing still be unacceptable?
• will the system be less reliable due to denormalization? If Yes, avoid
denormalization

22
 Chapter Five

Denormalization

• Only one valid reason exists for denormalizing a relational design - to enhance
performance.

• Many calculations need to be applied to one or many columns.

• Tables need to be accessed in different ways by different users during the same
timeframe.

• Many large primary keys exist.

• Certain columns are queried a large percentage of the time

23