The Process of Normalisation

Normalisation is a data analysis technique to design a database system. It allows the database designer to understand the current data structures in an organisation. Furthermore, it aids any future changes and enhancements to the system. Normalisation is a technique for producing relational schema with the following properties: No Information Redundancy No Update Anomalies he end result of normalisation is a set of entities, which remo!es unnecessary redundancy "ie duplication of data# and a!oids the anomalies which will be discussed ne$t.

Anomalies
Anomalies are incon!enient or error%prone situation arising when we process the tables. here are three types of anomalies: Update Anomalies &elete Anomalies Insert Anomalies

Update Anomalies
An Update Anomaly e$ists when one or more instances of duplicated data is updated, but not all. For e$ample, consider 'ones mo!ing address % you need to update all instances of 'ones(s address.

StudentNum S21 S21 S24 S 0 S 0 &elete Anomalies

CourseNum 9201 9267 9267 9201 9 22

Student Name Jones Jones Smith !ichards !ichards

Address Edinburgh Edinburgh Glasgow "anchester "anchester

Course Accounts Accounts physics #omputing "aths

A Delete Anomaly e$ists when certain attributes are lost because of the deletion of other attributes. For e$ample, consider what happens if )tudent )*+ is the last student to lea!e the course % All information about the course is lost.

StudentNum S21 S21 S24 S 0

CourseNum 9201 9267 9267 9201

Student Name Jones Jones Smith !ichards

Address Edinburgh Edinburgh Glasgow "anchester

Course Accounts Accounts physics #omputing

S 0

9 22

!ichards

"anchester

"aths

Insert Anomalies
An Insert Anomaly occurs when certain attributes cannot be inserted into the database without the presence of other attributes. For e$ample this is the con!erse of delete anomaly % we can(t add a new course unless we ha!e at least one student enrolled on the course.

StudentNum S21 S21 S24 S 0 S 0

CourseNum 9201 9267 9267 9201 9 22

Student Name Jones Jones Smith !ichards !ichards

Address Edinburgh Edinburgh Glasgow "anchester "anchester

Course Accounts Accounts physics #omputing "aths

Normalisation Stages
,rocess in!ol!es applying a series of tests on a relation to determine whether it satisfies or !iolates the requirements of a gi!en normal form. -hen a test fails, the relation is decomposed into simpler relations that indi!idually meet the normalisation tests. he higher the normal form the less !ulnerable to update anomalies the relations become. hree Normal forms: .NF, /NF and *NF were initially proposed by 0odd. All these normal forms are based on the functional dependencies among the attributes of a relation. Normalisation follows a staged process that obeys a set of rules. he steps of normalisation are: Step 1: )elect the data source and con!ert into an unnormalised table "UNF# Step 2: ransform the unnormalised data into first normal form ".NF# Step 3: ransform data in first normal form ".NF# into second normal form "/NF# Step 4: ransform data in second normal form "/NF# into third normal form "*NF# 1ccasionally, the data may still be sub2ect to anomalies in third normal form. In this case, we may ha!e to perform further transformations. ransform third normal form to 3oyce%0odd normal form "30NF# ransform 3oyce%0odd normal form to fourth normal form "4NF# ransform fourth normal form to fifth normal form "5NF#

Normalisation E ample
-e will demonstrate the process of normalisation "to *NF# by use of an e$ample. Normalisation is a bottom%up technique for database design, normally based on an e$isting system "which may be paper%based#. -e start by analysing the documentation, eg reports, screen layouts from that system. -e will begin with the ,ro2ect 6anagement Report, which describes pro2ects being wor7ed upon by employees. his report is to be (normalised(. 8ach of the first four normalisation steps is e$plained.

$$ )tep .
)elect the data source "ie the report from the pre!ious page# and con!ert into an unnormalised table "UNF#. he process is as follows: 0reate column headings for the table for each data item on the report "ignoring any calc!lated fields#. A calculated field is one that can be deri!ed from other information on the form. In this case total staff and a"erage ho!rly rate. 8nter sample data into table. " his data is not simply the data on the report but a representati!e sample. In this e$ample it shows se!eral employees wor7ing on se!eral pro2ects. In this company the same employee can wor7 on different pro2ects and at a different hourly rate.# Identify a #ey for the table "and underline it#. Remo!e duplicate data. "In this e$ample, for the chosen 7ey of ,ro2ect 0ode, the !alues for ,ro2ect 0ode, ,ro2ect itle, ,ro2ect 6anager and ,ro2ect 3udget are duplicated if there are two or more employees wor7ing on the same pro2ect. Pro$ect %ode chosen for the 7ey and duplicate data, associated with each pro2ect code, is remo!ed. &o not confuse duplicate data with repeating attributes which is descibed in the ne$t step.

$
UN&' !nnormalised ta(le

)tep /
ransform a table of unnormalised data into first normal form ".NF#. any repeating attributes to a new table. A repeating attribute is a data field within the UNF relation that may occur with multiple !alues for a single !alue of the 7ey. he process is as follows: Identify repeating attributes. Remo!e these repeating attributes to a new table together with a copy of the 7ey from the UNF table. Assign a 7ey to the new table "and underline it#. he 7ey from the original unnormalised table al)ays becomes part of the 7ey of the new table. Acompo!nd #ey is created. he !alue for this 7ey must be unique for each entity occurrence. Notes' After remo!ing the duplicate data the repeating attributes are easily identified. In the pre!ious table the 8mployee No, 8mployee Name, &epartment No, &epartment Name and 9ourly Rate attributes are repeating. hat is, there is potential for more than one occurrence of these attributes for each pro2ect code. hese are the repeating attributes and ha!e been to a new table together with a copy of the original 7ey "ie: ,ro2ect 0ode#. A 7ey of ,ro2ect 0ode and 8mployee No has been defined for this new table. his combination is unique for each row in the table.

.NF ables: Repeating Attributes Remo!ed Project Code %#010 %#04& %#064 Project Title %ensions$System Salaries$System '!$System Project Manager "$%hillips '$"artin ($)ewis Project Budget 24&00 17400 122&0

Project Code Employee No. Employee Name Department No. %#010 %#010 %#010 %#04& %#04& %#04& %#04& %#064 %#064 %#064 S10001 S100 0 S21010 S10010 S10001 S 1002 S1 210 S 1002 S21010 S100 4 A$Smith )$Jones %$)ewis .$Jones A$Smith +$Gilbert 0$!ichards +$Gilbert %$)ewis .$James )004 )02 )004 )004 )004 )02)00)02)004 )009

Department Name *+ %ensions *+ *+ *+ /atabase Salary /atabase *+ '!

Hourly Rate 22,00 1-,&0 21,00 21,7& 1-,00 2&,&0 17,00 2 ,2& 17,&0 16,&0

Step 3
ransform .NF data into second normal form "/NF#. Remo!e any %7ey attributes "partial &ependencies# that only depend on part of the table 7ey to a new table. -hat has to be determined :is field A dependent upon field 3 or !ice !ersa;: his means: :<i!en a !alue for A, do we then ha!e only one possible !alue for 3, and !ice !ersa;: If the answer is yes, A and 3 should be put into a new relation with A becoming the primary 7ey. A should be left in the original relation and mar7ed as a foreign 7ey. Ignore tables with "a# a simple 7ey or "b# with no non%7ey attributes "these go straight to /NF with no con!ersion#. he process is as follows: a7e each non%7ey attribute in turn and as7 the question: is this attribute dependent on one part of the 7ey; If yes, remo!e the attribute to a new table with a copy of the part of the 7ey it is dependent upon. he 7ey it is dependent upon becomes the 7ey in the new table. Underline the 7ey in this new table. If no, chec7 against other part of the 7ey and repeat abo!e process If still no, ie: not dependent on either part of the 7ey, 7eep attribute in current table. Notes' he first table went straight to /NF as it has a simple 7ey ",ro2ect 0ode#. 8mployee name, &epartment No and &epartment Name are dependent upon 8mployee No only. herefore, they were mo!ed to a new table with 8mployee No being the 7ey. 9owe!er, 9ourly Rate is dependent upon both ,ro2ect 0ode and 8mployee No as an employee may ha!e a different hourly rate depending upon which pro2ect they are wor7ing on. herefore it remained in the original table.

2N& Ta(les' Partial *ey Dependencies +emo"ed

Project Code %#010 %#04& %#064 Project Title %ensions$System Salaries$System '!$System Hourly Rate 22,00 1-,&0 21,00 21,7& 1-,00 2&,&0 17,00 2 ,2& 17,&0 16,&0 Project Manager "$%hillips '$"artin ($)ewis Employee No. S10001 S100 0 S21010 S10010 S 1002 S1 210 S100 4 Project Budget 24&00 17400 122&0 Employee Name A$Smith )$Jones %$)ewis .$Jones +$Gilbert 0$!ichards .$James Department No. )004 )02 )004 )004 )02)00)009 Department Name *+ %ensions *+ *+ /atabase Salary '!

Project Employee Code No. %#010 %#010 %#010 %#04& %#04& %#04& %#04& %#064 %#064 %#064 S10001 S100 0 S21010 S10010 S10001 S 1002 S1 210 S 1002 S21010 S100 4

)tep 4
data in second normal form "/NF# into third normal form "*NF#. Remo!e to a new table any non%7ey attributes that are more dependent on other non%7ey attributes than the table 7ey. -hat has to be determined is :is field A dependent upon field 3 or !ice !ersa;: his means: :<i!en a !alue for A, do we then ha!e only one possible !alue for 3, and !ice !ersa;: If the answer is yes, then A and 3 should be put into a new relation, with A becoming the primary 7ey. A should be left in the original relation and mar7ed as a foreign 7ey. Ignore tables with =ero or only one non%7ey attribute "these go straight to *NF with no con!ersion#. he process is as follows: If a non%7ey attribute is more dependent on another non%7ey attribute than the table 7ey: 6o!e the dependent attribute, together with a copy of the non%7ey attribute upon which it is dependent, to a new table. 6a7e the non%7ey attribute, upon which it is dependent, the 7ey in the new table. Underline the 7ey in this new table. ,ea"e the non%7ey attribute, upon which it is dependent, in the original table and mar7 it a foreign #ey ">#. Notes'

 he pro2ect team table went straight from /NF to *NF as it only has one non%7ey attribute. &epartment Name is more dependent upon &epartment No than 8mployee No and therefore was mo!ed to a new table. &epartment No is the 7ey in this new table and a foreign 7ey in the 8mployee table.

3N& Ta(les' Non-*ey Dependencies +emo"ed

Project Code %#010 %#04& %#064 Project Code %#010 %#010 %#010 %#04& %#04& %#04& %#04& 064 %#064 %#064 Employee No. S10001 S100 0 S21010 S10010 S 1002 S1 210 S100 4 Department No. )004 )02 )02)00Project Title %ensions$System Salaries$System '!$System Employee No. S10001 S100 0 S21010 S10010 S10001 S 1002 S1 210 S 1002 S21010 S100 4 Employee Name A$Smith )$Jones %$)ewis .$Jones +$Gilbert 0$!ichards .$James Department Name *+ %ensions /atabase Salary Project Manager "$%hillips '$"artin ($)ewis Hourly Rate 22,00 1-,&0 21,00 21,7& 1-,00 2&,&0 17,00 2 ,2& 17,&0 16,&0 Department No. )004 )02 )004 )004 )02 )00)0009 Project Budget 24&00 17400 122&0

)009

'!

S!mmary of Normalisation +!les

hat is the complete process. 9a!ing started off with an unnormalised table we finished with four normalised tables in *NF. ?ou will notice that duplication has been remo!ed "apart from the 7eys needed to establish the lin7s between those tables#. he process may loo7 complicated. 9owe!er, if you follow the rules completely, and donot miss out any steps, then you should arri!e at the correct solution. If you omit a rule there is a high probability that you will end up with too few tables or incorrect 7eys. he following normal forms were discussed in this section: ..&irst normal form' A table is in the first normal form if it contains no repeating columns. /.Second normal form' A table is in the second normal form if it is in the first normal form and contains only columns that are dependent on the whole "primary# 7ey. *.Third normal form' A table is in the third normal form if it is in the second normal form and all the non%7ey columns are dependent only on the primary 7ey. If the !alue of a non%7ey column is dependent on the !alue of another non%7ey column we ha!e a situation 7nown as transiti!e dependency. his can be resol!ed by remo!ing the columns dependent on non%7ey items to another table.

SA. 1
A college maintains details of its lecturers( sub2ect area s7ills. hese details comprise: @ecturer Number @ecturer Name @ecturer <rade &epartment 0ode &epartment Name )ub2ect 0ode )ub2ect Name )ub2ect @e!el Assume that each lecturer may teach many sub2ects but may not belong to more than one department. )ub2ect 0ode, )ub2ect Name and )ub2ect @e!el are repeating fields. Normalise this data to hird Normal Form.

Answer
UN& @ecturer Number ,@ecturer Name, @ecturer <rade, &epartment 0ode,&epartment Name, )ub2ect 0ode, )ub2ect Name, )ub2ect @e!el 1N& @ecturer Number, @ecturer Name, @ecturer <rade, &epartment 0ode, &epartment Name

@ecturer Number , )ub2ect 0ode, )ub2ect Name,)ub2ect @e!el 2N& @ecturer Number, @ecturer Name, @ecturer <rade, &epartment 0ode, &epartment Name @ecturer Number, )ub2ect 0ode )ub2ect 0ode, )ub2ect Name, )ub2ect @e!el 3N& @ecturer Number,@ecturer Name,@ecturer <rade >&epartment 0ode &epartment 0ode, &epartment Name @ecturer Number, )ub2ect 0ode )ub2ect 0ode,)ub2ect Name,)ub2ect @e!el

SA. 2
A software contract and consultancy firm maintains details of all the !arious pro2ects in which its employees are currently in!ol!ed. hese details comprise: 8mployee Number 8mployee Name &ate of 3irth &epartment 0ode &epartment Name ,ro2ect 0ode ,ro2ect &escription ,ro2ect )uper!isor Assume the following: 8ach employee number is unique. 8ach department has a single department code. 8ach pro2ect has a single code and super!isor. 8ach employee may wor7 on one or more pro2ects. 8mployee names need not necessarily be unique. ,ro2ect 0ode, ,ro2ect &escription and ,ro2ect )uper!isor are repeating fields. Normalise this data to hird Normal Form.

Answer
UN& 8mployee Number, 8mployee Name,&ate of 3irth, &epartment 0ode, &epartment Name, ,ro2ect 0ode, ,ro2ect &escription, ,ro2ect )uper!isor 1N& 8mployee Number, 8mployee Name, &ate of 3irth &epartment 0ode, &epartment Name 8mployee Number, ,ro2ect 0ode, ,ro2ect &escription, ,ro2ect )uper!isor 2N&

8mployee Number, 8mployee Name, &ate of 3irth, &epartment 0ode, &epartment Name 8mployee Number,,ro2ect 0ode, ,ro2ect 0ode, ,ro2ect &escription,,ro2ect )uper!isor 3N& 8mployee Number, 8mployee Name, &ate of 3irth, >&epartment 0ode &epartment 0ode, &epartment Name 8mployee Number, ,ro2ect 0ode ,ro2ect 0ode, ,ro2ect &escription, ,ro2ect )uper!isor