Professional Documents
Culture Documents
NORMALISATION
● No repeating data.
● No chance of anomalies when updating, deleting or adding data
● No chance of data inconsistencies
You have to understand what each stage is and be able to normalise data.
Identify TWO examples of why attributes in this table that are not in FIRST NORMAL FORM
1.
Many values in dentist name
Part time and fulltime
2.
Question : Complete the tables to show what attributes (fields, columns) would go into
each table so that the data is now in 1st Normal Form.
Some attributes have already been added for you.
DENTIST
Attributes
Dentist ID
Dentist name
Appointments
APPOINTMENTS
Attributes
Appointment ID
Appointment Time
Appointment Date
Customer Name
Dentist ID
Question - Explain why Dentist ID has been added to the APPOINTMENTS table(relation)
as well as the DENTIST table(relation)
Here is a database used by an online retailer to record orders and customers. The
customer table isn’t displayed here but you can assume it stores all the information about
customers accessible by their Customer ID. For that reason the customer ID is a FOREIGN
KEY in this table.
There is no single attribute here that is UNIQUE i.e. different for each row(tuple) of the
table(relation) here. Therefore we have to use a COMPOSITE KEY made up of more than
one.
Question: What 3 attributes combined would be a unique combination for each row?
Customer ID
Product ID
Date purchased
Second normal form is only an issue for tables that have COMPOSITE KEYS.
Important: Tables with a single key attribute are already in 2nd normal form.
We need to look at all the attributes that are NOT part of the composite key in your
answer to the last question.
Which of these DEPEND (could be found) only when you know ALL THREE of the key
attributes or which are only PARTIALLY DEPENDENT on knowing one or two of the key
attributes.
Question : Mark all attributes with an ‘X’ in the last row that are only PARTIALLY
DEPENDENT on the composite key.
Partially dependent: X X
Now that you have identified the partial key dependencies we can divide this table into two.
Complete the attributes for the two tables below
ORDERS
Attributes
Customer ID
Product ID
Date Purchased
Quantity purchased
PRODUCTS
Attributes
Product ID
Product Price
Product desc
ALL attributes that are not part of the composite key depend on the whole key.
THIRD NORMAL FORM
What is Third Normal form? Watch this video first:
Here is a table that is in 2nd normal form used to store team details for a local league.
Question: There is a transitive functional dependence here - in other words there are
attributes that depend on other attributes which are not the key attribute. Can you spot it?
CLUE: Look for any non-key attributes that if you had to change them for whatever reason
then you would have to change another attribute as well.
x x
This would mean separating this table into two tables. Remember they will need to be
linked
TEAM
Attributes
Title
Homeground
Kit Colour
Manager name
MANAGER
Attributes
ALL attributes that are not part of the key only depend on the key and not on any other
non-key attributes.
Here is an unnormalized table used to store exam results in a college. Convert this
into a two or more normalised tables
1 Fred 3 IT IT1 44 50 A
Pye
3 Max 3 IT IT1 33 50 B
Jones
3 Max 3 IT IT2 34 70 D
Jones