1. Relational and Online Database Management Systems Normalisation
Module 5.3.4
Relational and Online Database Management Systems
Normalisation

2. First Normal Form (1NF)
A table is in first normal form if all the data values are atomic values
In English, this means that there can only be one value per attribute
The following table records managers of shoe shops. One manager can be a manager of more than one shop
This is not in 1NF because each attribute does not contain a single value. For example, Shaw is manager of Gloucester and Bristol. To be in 1NF these values need to be separated
Manager
Shop
Shaw
Gloucester, Bristol
Jones
Trafalgar
Smith
Ashford, Canterbury
Greg
Brighton, Hove

3. First Normal Form (Cont.)
This is not in 1NF because the values are not atomic
Manager
Shop
Shaw
Gloucester, Bristol
Jones
Trafalgar
Smith
Ashford, Canterbury
Greg
Brighton, Hove
Manager
Shop
Shaw
Gloucester
Bristol
Jones
Trafalgar
Smith
Canterbury
Ashford
Greg
Brighton
Hove
This is in 1NF because each cell has only 1 value

4. First Normal Form - Difficulties
Terminology differences:
Atomic
Indivisible
Scalar
These all refer to a single value per attribute
Attributes to be careful of include:
Address – e.g 24 The Grange, Oxford. OX4 6JP is not scalar
Telephone – e.g is not scalar (code and number)
Atomic does not only refer to the data, but to the use of data. Just because you can split data does not means that you should. Telephone should only be split if you need to sort by code for example
Official Definition:
At the end of 1NF you end up with a table. In order to be a table it must have a primary key. This is officially correct and it may be necessary to add a field to give a primary key

5. Terminology: Primary Key
A primary key is a unique value which allows each record to be identified
CustomerID
FirstName
LastName 1
Brian
Smith 2
Harry
Adams 3
Joe
Jones 4
FirstName or LastName cannot be primary keys as they contain duplicate data. CustomerID uniquely identifies a row and is therefore suitable

6. Terminology: Primary Key (Cont.)
Sometimes there is no single field appropriate as a primary key. In these circumstances, it is possible to select two fields which, when taken together create a unique value:
OrderNo
ItemNo
EmployeeNo
CustomerNo
ItemName
Quantity
121 3 4
1024
Nut
Bolt
122 8 9
176
Washer 6
123
154 5
There are no unique fields, so the Primary Key is best suited by OrderNo and ItemNo taken together

7. Terminology: Functional Dependence
Functional Dependency
If you know the length, height and width of a room, you can calculate its volume:
Volume = width x height x length
Volume is functionally dependent on the length, height and width
Consider the following database, which holds orders. Each order is entered by a specific employee (only one employee is allowed to enter an order)

8. Terminology: Functional Dependency
OrderNo
ItemNo
EmployeeNo
CustomerID
ItemName
Quantity
121 3 4
1024
Nut
Bolt
122 8 9
176
Washer 6
123
154 5
EmployeeNo is functionally dependent on OrderNo
OrderNo functionally determines EmployeeNo
OrderNo is the determinant
The relationship is only one way

9. Terminology: Functional Dependency
Functional Dependency – More examples
A table containing PupilName and PupilID
PupilName is functionally dependent on PupilID
PupilID
PupilName 34
Smith 65
Sams 87
Hodd
654
If you know the PupilID you can find any PupilName, but if you only have the name, it is not always possible to find the PupilID

10. Second Normal Form (2NF)
To be in 2NF a table must:
Be in 1NF (obviously)
Have all non key fields fully functionally dependant on the primary key
In English:
A non key field is one that is not part of the primary key
It means that you need to use the primary key to determine the value of the other fields in the table
If you can find the value of other fields without using the primary key, you should remove that field from the table and place it in a separate table

11. Second Normal Form This table is not in 2NF
OrderNo*
ItemNo*
EmployeeNo
CustomerID
ItemName
Quantity
121 3 4
1024
Bolt
Washer
122 8 7
176
Nut 5
This table is not in 2NF
The primary key is OrderNo and ItemNo (combined)
The quantity is functionally dependant on the Primary Key
The ItemName is functionally dependant on the ItemNo not the primary key
The CustomerID is functionally dependant on the OrderNo, not the Primary Key
The EmployeeNo is functionally dependant on the OrderNo, not the primary key

12. Second Normal Form (Cont.)
OrderNo*
ItemNo*
EmployeeNo
CustomerID
ItemName
Quantity
121 3 4
1024
Bolt
Washer
122 8 7
176
Nut 5
We need to remove ItemName, CustomerID and EmployeeNo from the table – this involves setting up new tables

13. Second Normal Form (Cont.)
EmployeeNo and CustomerNo are functionally dependant on the OrderNo, therefore they are suited for a new table:
Orders
OrderNo*
EmployeeNo
CustomerNo
The Quantity is functionally dependant on both the OrderNo and the ItemNo, therefore they have a new table:
OrderSpec
OrderNo*
ItemNo*
Quantity
We are left with the ItemName. This is functionally dependent on the item number only, therefore a new table is required:
Stock
ItemNo*
ItemName

14. Second Normal Form (Cont.)
Do not be afraid to create new tables as appropriate but make sure that you are not breaking tables down for the sake of doing so. It should be appropriate and have advantages
Make sure that each table you create is in both 1NF and 2NF as appropriate
Ensure the original table can be rebuilt from the data contained in the new table

15. Second Normal Form A slightly different approach:
Each relation should only contain information about a single entity. If it contains information about more than one entity, then the table needs to be broken down
For example:
HOUSE(HouseName, Street, Town, City, Postcode, CityPopulation)
The CityPopulation is a separate entity to the house details, so it needs to be removed to a separate table
To create a separate table, remove the attribute and a copy of the attribute on which it is dependent. The copy becomes the link between the two tables
HOUSE(HouseName, Street, Town, City, Postcode)
CITY(City,CityPopulation)

16. Third Normal Form (3NF) To be in 3NF a table must: In English:
Be in second (and therefore also first) normal form
Have all non key fields non transitively dependent on the primary key
In English:
Fields which do not form part of the primary key must always be solely dependent on the primary key and not on anything else, such as another non key field
Aside: it is usually difficult to create a table which is not in 3NF – usually you will jump straight from 1NF to 3NF!

17. Third Normal Form (Cont.)
In the following example, the company keeps data on its employees. Each employee is allocated a city where they work and each city is given a CityID. Their salary is dependent on the type of job they do. Initially check the table below to ensure it is in 2NF before continuing
EmployeeNo
LastName
FirstName
City
CityID
Type
Salary 1
Taylor
Sarah
Canterbury CB
Manager
£22,000 2
Jones
Sam
London LN
Sales Person
£15,000 3
Smith
Sally
Birmingham BM
Admin Assistant
£13,500

18. Third Normal Form (Cont.)
EmployeeNo
LastName
FirstName
City
CityID
Type
Salary 1
Taylor
Sarah
Canterbury CB
Manager
£22,000 2
Jones
Sam
London LN
Sales Person
£15,000 3
Smith
Sally
Birmingham BM
Admin Assistant
£13,500
CityID is dependent on City
Salary is dependent on Type
Therefore this table is not in 3NF

19. Third Normal Form (Cont.)
Remove City from the table and create a new cities table
Remove Salary from the table and create a job type table
Staff
EmployeeID*
LastName
FirstName
CityID
Type
Cities
CityID*
City
JobTypes
TypeID*
Salary

20. Advantages of Normalisation
More efficient database structure
Better understanding of your data
Easier to see how the data fits together
More flexible database structure
Allows the data to be used for a variety of purposes
Data is independent of interface and use
Easier to maintain database structure
Changing, adding and removing data structures is easier with a relational model than any other model
Avoids redundant fields
And redundant records which reduced storage space and cost of hard disk drives