Database

Flat file DB

This will cause data

repetition or redundancy.
 Database

• This will cause data repetition or redundancy.

• If one application changed this data, this
change will not appear to other applications
which makes the data inconsistent.
• Fields are also in different order, staff Number
is the fifth field in payroll program while it is
the second in the Sales program.
• Retrieving data depend on it’s structure, data
is not independent in this case. It depends on
the program that uses it.

These two files can be combined into one file to

avoid redundancy.
Database
If we combine them:
• data of each field will be stored once.
• Any change to data will be visible by all
programs.
• Save storage area.
• Data independent and can be accessed by any
program in any order.
Database
Database
Many tables connected together instead of one
table that has all data.
Database
Many tables connected together instead of one
table that has all data.
Database
Referential integrity has to be maintained.
It means that if a field is deleted or updated in one
table, this should be seen in other tables.
Database

In the exam look at the name of entity that

comes first.
Class to student then it is one to many.
Student to class then it is many to one.
It is the same relationship, but the order is
different.
Design ERD

The exam concentrates on one to one, many

to many and one to many.
Database
All exams have normalization questions.

This table needs normalization because

it has data about many different things.
Student
Class
Teacher
• If Mr.Khan leave the school, we have
to delete all records (classes and
student) that he teaches.
• If one teacher changed his address,
then we need to update many
records.
Database
Normalization is the solution for all
problems of data being inconsistent.

Don’t have more than one field for same attribute,

such as, STUD-PHONE 1 and STUD-PHONE 2
 Database
1NF
First Normal Form (1NF): Example-1:
If a relation contains a composite or multi-valued Relation STUDENT in table 1 is not in 1NF because of multi-valued
attribute, it violates the first normal form, or the attribute STUD_PHONE. Its decomposition into 1NF has been
relation is in first normal form if it does not contain shown in table 2.
any composite or multi-valued attribute. A relation is
in first normal form if every attribute in that relation is
singled valued attribute.

A table is in 1 NF if:

• There are only Single Valued Attributes.

• Attribute Domain does not change.
• There is a unique name for every
Attribute/Column.
• The order in which data is stored does not matter.
Don’t solve the problem by adding new field called STUD_PHONE2
Consider the examples given below. This violate condition three that table should have one name for
each attribute.
 Normalisation
1NF

More rows, relations, better than more

columns course 1, course 2, ….

1NF does not eliminate redundancy, but rather, it’s that it eliminates repeating groups.
Instead of having multiple columns of the same kind of data in a record, (0NF or
Unnormalized form) you remove the repeated information into a separate relation and
represent them as rows. This is what constitutes 1NF.
 Normalisation
2NF
What is wrong in this table? Many courses have the same fees.

COURSE_FEE cannot alone decide the value of COURSE_NO or

STUD_NO (can 1000 tell which student or which course?)

COURSE_FEE together with STUD_NO cannot decide the value

of COURSE_NO (1000 and 4, can you tell which course?)

COURSE_FEE together with COURSE_NO cannot decide the

value of STUD_NO (1000 and C1, can you tell which student?)

(STUD_NO with COURSE_No) is my composite PK.

COURSE_FEE depends only on part of this key, this is called
partial dependency.
and so this relation is not in 2NF.
 Normalisation
2NF
To convert the above relation to 2NF, we need to split the table into two tables such as :
Table 1: STUD_NO, COURSE_NO Table 2: COURSE_NO, COURSE_FEE

Note – 2NF tries to reduce the redundant data getting stored in memory. For instance, if there
are 100 students taking C1 course, we don't need to store its Fee as 1000 for all the 100 records,
instead once we can store it in the second table as the course fee for C1 is 1000.
Normalisation

Many repetition in one column Subject Name

so not in 1NF.
To avoid this, we need a separate table for
Subject.
 Normalisation

PK

FK

PK as Composite key
Normalisation
 Normalisation

All keys and every key in any table should only depend on PK.
Normalisation
SUMMARY
Recap
Normalizing an example table

What is wrong here?

Class# isn't functionally dependent on Student#

(primary key), o this relationship isn't in second
normal form.
Recap
Recap
Recap
Recap
Recap
Recap