Normalization.ppt What is Normalizations

Copyright © 2009, Oracle. All rights reserved.
I - 1
Normalization
 After designing the database, it is important to ensure that the data in the
table is consistent and relevant.
 Normalization is a process of reducing duplicate data in a relational
database. The opposite of normalization is called as denormalization.

I - 2
What is data
redundancy?
Understanding Data Redundancy

I - 3
Redundancy means repetition
of data.
Understanding Data Redundancy (Contd.)

I - 4
 Redundancy:
 Increases the time involved in updating, adding, and deleting data.
 Increases the utilization of disk space and hence, disk I/O increases.
 Redundancy can, therefore, lead to:
 Insertion, modification, and deletion of data, which may cause
inconsistencies.
 Errors, which are more likely to occur when facts are repeated.
 Unnecessary utilization of extra disk space.

I - 5
 Consider the STUDENT table, as shown in the following diagram.
STUDENT
STUDENTID
STUDENTNAME
STUDENTBIRTHDATE
STUDENTADDRESS
STUDENTCITY
STUDENTZIP
STUDENTCLASS
STUDENTSEMESTER
STUDENTTEST1
STUDENTTEST2

I - 6
 The STUDENT table contains the values for each attribute, as shown in the
following diagram.
STUDENTID STUDENTNAME …… STUDENTSEMESTER STUDENTTEST1 STUDENTTEST2
001 Mary …… SEM-1 40 65
001 Mary …… SEM-2 56 48
002 Jake …… SEM-1 93 84
002 Jake …… SEM-2 85 90
The details of the students, such as STUDENTID and STUDENTNAME are
repeated while recording marks of different semesters. As a result, if you need to
modify the address of a student, it has to be modified in multiple row for that
student. If not done, it could lead o data inconsistency across rows.

I - 7
How can I
remove data
redundancy?
Definition of Normalization

I - 8
We can remove data redundancy
with the help of normalization. Let
us understand this concept.
Definition of Normalization (Contd.)

I - 9
 Normalization:
 Is a method of breaking down complex table structures into simple table
structures by using certain rules.
 Using this method, you can reduce redundancy in a table and eliminate the
problems of inconsistency and disk space usage. You can also ensure that
there is no loss of information.
 Has the following benefits:
 It helps in maintaining data integrity.
 It helps in simplifying the structure of tables, therefore, making a database
more compact.
 It helps in reducing the null values, which reduces the complexity of data
operations.

I - 10
 Some rules that should be followed to achieve a good database design are:
 Each table should have an identifier.
 Each table should store data for a single type of entity.
 Columns that accept NULLs should be avoided.
 The repetition of values or columns should be avoided.

I - 11
 Normalization results in the formation of tables that satisfy certain
normal forms.
 The normal forms are used to remove various types of abnormalities
and inconsistencies from the database.
 The most important and widely used normal forms are:
 First Normal Form (1NF)
 Second Normal Form (2NF)
 Third Normal Form (3NF)
 Boyce-Codd Normal Form (BCNF)

I - 12
The following diagram shows the different levels of normalization.
UNNORMALIZED RELATION
1NF
2NF
3NF
BCNF

I - 13
 First Normal Form (1NF):
A table is said to be in 1NF when each cell of the table contains precisely
one value.
 The guidelines for converting a table into 1NF are:
 Place the related data values in a table. Further, define similar data values
with the column name.
 There should be no repeating group in the table.
 Every table must have a unique primary key.

I - 14
 Consider the PROJECT table, as shown in the following diagram.
Primary key
PROJECT table is not in first normal form because cells
in PROJCODE and HOURS have more than one value.

I - 15
 By applying the 1NF definition to the PROJECT table, you arrive at the
table, as shown in the following diagram.

I - 16
 Consider the STUDENT table, as shown in the following diagram.
STUDENT table contains null values in PHONE
NUMBER2 column, and the number of telephone
numbers per student is restricted to two.
Primary key

I - 17
If a student has three telephone
numbers, you are constrained to
record only two and leave the third
unrecorded.

I - 18
 By applying the 1NF definition to the STUDENT table, you can arrive at the
tables, as shown in the following diagram.

I - 19
To convert the table to 2NF, you
must first understand the concept
of functional dependency.

I - 20
 Functional dependency:
 Attribute A is functionally dependent on B if and only if, for each value of
B, there is exactly one value of A.
 Attribute B is called the determinant.

I - 21
 Consider the REPORT table, as shown in the following diagram.
Primary key

I - 22
 In the REPORT table:
 For a particular value of ROLL_NUMBER+COURSE_CODE, there is
precisely one corresponding value for MARKS.
 Hence, MARKS is functionally dependent on
ROLL_NUMBER+COURSE_CODE.
 This can be symbolically represented as:
(ROLL_NUMBER, COURSE_CODE)MARKS.

I - 23
 The following diagram shows the functional dependency between
MARKS and ROLL_NUMBER+COURSE_CODE.
ROLL_NUMBER
COURSE_CODE
MARKS

I - 24
 The other functional dependencies in the REPORT table are:
 COURSE_CODECOURSE_NAME
 COURSE_CODET_NAME
(Assuming one course is taught by only one teacher.)
 T_NAMEROOM_NUMBER
(Assuming each teacher has his/her own, unshared room.)
 MARKSGRADE

I - 25
 COURSE_NAME, T_NAME, and ROOM_NUMBER attributes are partially
dependent on the whole key.
 This dependency is called partial dependency, as shown in the following
diagram.
ROLL_NUMBER
COURSE_CODE
COURSE_NAME
T_NAME
ROOM_NUMBER

I - 26
 ROOM_NUMBER is dependent on T_NAME, and T_NAME is dependent on
COURSE_CODE, as shown in the following diagram.

I - 27
This type of dependency is called
as transitive dependency.

I - 28
 The following diagram shows the transitive (indirect) dependency.
COURSE_CODE T_NAME ROOM_NUMBER

I - 29
 Second Normal Form (2NF):
A table is said to be in 2NF when:
 It is in the 1NF, and
 No partial dependency exists between non-key attributes and key
attributes.
 Find and remove attributes that are functionally dependent on only a
part of the key and not on the whole key. Place them in a different table.
 Group the remaining attributes.

I - 30
 The preceding table could lead to the following problems:
 Insertion
 Updation
 Deletion

I - 31
 Insertion
 Updation
 Deletion
The department of an employee cannot be recorded until the
employee is assigned a project.

I - 32
 Insertion
 Updation
 Deletion
For an employee, ECODE, DEPT, and DEPTHEAD are repeated.
Any change will have to be recorded in every row of the
EMPLOYEE table.

I - 33
 Insertion
 Updation
 Deletion
When the project finishes, the employee details are deleted. This
leads to loss in information about the department to which
employee belongs.

I - 34
Let us check if the PROJECT
table is in 2NF.

I - 35
Hours is functionally dependent on the
whole key, ECODE+PROJCODE.
Composite key

I - 36
Composite Key
Dept is functionally dependent on part of the
key, which is ECODE.

I - 37
Composite Key
DEPTHEAD is functionally dependent on
ECODE; however, it is not dependent on
the attribute, PROJCODE.

I - 38
To convert the PROJECT table into
2NF, you must remove the attributes
that are not functionally dependent
on the whole key.

I - 39
You should place the removed
attributes in a different table along
with the attribute they are
functionally dependent on.

I - 40
 The EMPLOYEEDEPT and PROJECT tables are in 2NF, as shown in the
following diagram.

I - 41
 Now, consider the following STUD_SUBJECT_DETAILS table
STUD_ID FIRST_NAME LAST_NAME SUB_CODE SUB_NAME DURATION MARKS
ST32 Mark Steven SC345 Java 4 75
ST34 Peter Hanks SC534 HTML 2 70
ST65 Joey Carol SC345 Java 4 65
ST44 Lee Jones SC564 JavaScript 3 80
ST34 Peter Hanks SC564 JavaScript 3 60
ST66 Tom Sean SC655 XML 1 72

I - 42
 Tables in 2NF
SUB_CODE SUB_NAME DURATION
SC345 Java 4
SC534 HTML 2
SC564 JavaScript 3
SC655 XML 1
STUD_ID FIRST_NAME LAST_NAME
ST32 Mark Steven
ST34 Peter Hanks
ST65 Joey Carol
ST44 Lee Jones
ST34 Peter Hanks
ST66 Tom Sean
STUD_ID SUB_COD
E
MARKS
ST32 SC345 75
ST34 SC534 70
ST65 SC345 65
ST44 SC564 80
ST34 SC564 60
ST66 SC655 72

I - 43
 Third Normal Form (3NF):
A relation is said to be in the 3NF if and only if:
 It is in 2NF, and
 No transitive (indirect) dependency exists between non-key
attributes and key attributes.
 Find and remove non-key attributes that are functionally dependent
on attributes that are not the primary key. Place them in a different
table.
 Group the remaining attributes.

I - 44
 Consider the EMPLOYEE table, as shown in the following diagram.
 Insertion
 Updation
 Deletion

I - 45
 Insertion
 Updation
 Deletion
The department head of a new department that does not have any
employees at present cannot be entered in the DEPTHEAD column.

I - 46
 Insertion
 Updation
 Deletion
For a department, DEPTHEAD is repeated. Any change will have to
be made consistently across the table.

I - 47
 Insertion
 Updation
 Deletion
If an employee record is deleted, the information about DEPTHEAD
will also be deleted. Hence there will be a loss of information

I - 48
Let us check if the EMPLOYEE
table is in 3NF.

I - 49
Primary key
DEPTHEAD is functionally dependent on DEPT,
which is not a primary key.

I - 50
 To convert the EMPLOYEE table into 3NF, you must remove the DEPTHEAD
column and place it in another table, as shown in the following diagram.

I - 51
 Consider another table, STUD_DETAILS, which stores the student
residential address.
STUD_DETAILS
ROLL_NO
NAME
DOB
STATE
CITY
STREET
ZIPCODE

I - 52
 The STUD_DETAILS table contains the values,
ROLL_NO NAME DOB STATE CITY STREET ZIPCODE
R10 Ryan 22-04-87 Maine Big City Long Lane 435564
R35 Lisa 04-09-88 Nevada Windy Main Lane 435576
R42 Sam 09-09-90 Ohio Ville Wind Road 435764
R58 Aaron 08-08-91 Texas Mega Main Street 435565
R62 Sharon 12-05-92 Nevada Windy Main Lane 435576
 In the preceding table, Street, City and State are associated with the ZipCode.
 For example, if you want to know the number of students residing at a
particular location, then a zip code is enough for this. There fore you can
move attributes, STATE, CITY, STREET, and ZIPCODE into another table,
ADDRESS

I - 53
 The following is the ADDRESS table
STATE CITY STREET ZIPCODE
Maine Big City Long Lane 435564
Nevada Windy Main Lane 435576
Ohio Ville Wind Road 435764
Texas Mega Main Street 435565
 Then, you can move the rest of the attributes to another table, which must
include ZIPCODE or matching the address details in the ADDRESS table.

I - 54
 The following is the STUD_DETAILS table
 Then, you can move the rest of the attributes to another table, which must
include ZIPCODE or matching the address details in the ADDRESS table.
ROLL_NO NAME DOB ZIPCODE
R10 Ryan 22-04-87 435564
R35 Lisa 04-09-88 435576
R42 Sam 09-09-90 435764
R58 Aaron 08-08-91 435565
R62 Sharon 12-05-92 435576

I - 55
 Boyce-Codd Normal Form (BCNF):
The original definition of 3NF was not sufficient in some situations. It was
not satisfactory for the tables:
 That had multiple candidate keys.
 Where the multiple candidate keys were composite.
 Where the multiple candidate keys overlapped (had at least one attribute in
common).
 In tables, where the preceding 3 conditions do not apply, you can stop at the
third normal form. In such cases, the third NF is the same as the BCNF.
 A relation is in BCNF if and only if every determinant is a candidate key.
 The guidelines for converting a table into BCNF are:
 Find and remove the overlapping candidate keys. Place the part of the
candidate key and the attribute it is functionally dependent on, in a different
table.
 Group the remaining items into a table.

I - 56
Primary Key
NAME+PROJCODE can also be chosen
as the primary key and hence, is a
candidate key.
PROJECT table is already in 3NF

I - 57
 The following points describe the functional dependencies in the
PROJECT table:
 HOURS is functionally dependent on ECODE+PROJCODE.
 HOURS is also functionally dependent on NAME+PROJCODE.
 NAME is functionally dependent on ECODE.
 ECODE is functionally dependent on NAME.
 You will notice that the PROJECT table has:
 Multiple candidate keys that are ECODE+PROJCODE and
NAME+PROJCODE.
 Composite candidate keys.
 Candidate keys that overlap since the PROJCODE attribute is
common between the two candidate keys.

I - 58
 The only non-key item is HOURS, which is dependent on the whole key,
ECODE+PROJCODE or NAME+PROJCODE.
 ECODE and NAME are determinants since they are functionally dependent
on each other.
 As per BCNF, the determinants have to be candidate keys.
 You can remove NAME and ECODE and place them in a different table.

I - 59
 You can remove NAME and ECODE and place them in a different table,
as shown in the following diagram.

I - 60
 Which of the following points helps in achieving a good
database design?
1. A table should store data for all the related entities together.
2. Each table should have an identifier.
3. Columns that contain NULL values should be created.
Solution:
2. Each table should have an identifier.
Just a minute

I - 61
 In which normal form, you need to remove non-key attributes
that are functionally dependent on non-primary key attributes?
Solution:
 Third normal form
Just a minute

Normalization.ppt What is Normalizations

More Related Content

Similar to Normalization.ppt What is Normalizations

Recently uploaded

Normalization.ppt What is Normalizations