Scribd
Upload
6 views5 pages

Normalisation Tutorial Solutions

The document provides solutions to normalization exercises involving database relations, focusing on identifying primary keys, functional dependencies, and normal forms. It covers examples of relations such as PROJECT, JobNo, and student enrollment data, detailing steps to achieve 1NF, 2NF, and 3NF. The solutions include necessary decompositions to ensure compliance with normalization rules.

Uploaded by

Nandar Lwin
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
6 views5 pages

Normalisation Tutorial Solutions

The document provides solutions to normalization exercises involving database relations, focusing on identifying primary keys, functional dependencies, and normal forms. It covers examples of relations such as PROJECT, JobNo, and student enrollment data, detailing steps to achieve 1NF, 2NF, and 3NF. The solutions include necessary decompositions to ensure compliance with normalization rules.

Uploaded by

Nandar Lwin
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 5

Normalisation Tutorial 1 – SOLUTIONS

Question 1

Consider the following relation definition of PROJECT and sample data:

Project_id Emp_name Emp_salary


100A Brown £35,000
100A Hopper £30,000
100B Hopper £30,000
200A Brown £35,000
200B Brown £35,000
200C White £20,000
200C Hopper £30,000
200D White £20,000
200E Smith £30,000
200E Jones £30,000

PROJECT(Project_id, Emp_name, Emp_salary)

Where:
Project_id is the identifier of the project,
Emp_name is the name of an employee who works on the project, and
Emp_salary is the salary of the employee whose name is Emp_name.

Assuming that all of the functional dependencies and constraints are apparent in this
data, answer these questions:

a. What is the primary key of PROJECT?


Ans: (Project_id, Emp_name)

b. Are all non-key attributes (if any) fully dependent on the primary key?
Ans: No, non-key attribute Emp_salary is only dependent on Emp_name, not on
the primary key.

c. Is Project_id a determinant?
Ans: No

d. Is Emp_name a determinant?
Ans: Yes, Emp_name determines Emp_salary

e. Is (Project_id, Emp_name) a determinant?


Ans: Yes

f. Is Emp_salary a determinant?
Ans: No

which of the following statements is true?


g. Project_id → Emp_name F
h. Project_id → Emp_salary F
i. (Project_id, Emp_name) → Emp_salary T (because of the key)
j. Emp_name → Emp_salary T
k. Emp_salary → Project_id F
l. Emp_salary → (Project_id, Emp_name) F
Question 2

Exercise 1

Examine the following relation:

JobNo ProductNo JobReportDate ProductDescription FaultReported


137 F386 12-JUN-2006 Laptop P4 Faulty screen,
Cracked case
137 G52 12-JUN-2006 Laptop carry bag Split
138 F442 12-JUN-2006 Li-on Battery Blown cells
139 F442 15-JUN-2006 Li-on Battery Damaged case

a. What do you think is the primary key of this relation?


Ans: {Job#, Product#} is the likely primary key, as all attributes are
dependant on this. However, the students should realise that once 1NF is
applied then FaultReported also needs to be part of the primary key.

b. The table is not in 1NF, why? Convert the table to be in 1NF.


Ans: Fault reported is not atomic, the value for the first row contains a list of
values.
We need to convert the first row of the table above to be two rows:

JobNo ProductNo JobReportDate ProductDescription FaultReported


137 F386 12-JUN-2006 Laptop P4 Faulty screen
137 F386 12-JUN-2006 Laptop P4 Cracked case
137 G52 12-JUN-2006 Laptop carry bag Split
138 F442 12-JUN-2006 Li-on Battery Blown cells
139 F442 15-JUN-2006 Li-on Battery Damaged case

c. See part (a) above.

Exercise 2

Using the table given below:

JobNo ProductNo JobReportDate FaultReported


137 F386 12-JUN-2006 Faulty screen
137 G52 12-JUN-2006 Split
138 F442 12-JUN-2006 Blown cells
139 F442 15-JUN-2006 Damaged case

a. Suggest a suitable primary key


Ans: JobNo, ProductNo as a composite PK
b. Identify all of the functional dependencies in the relation
Ans:
JobNo -> JobReportDate
JobNo, ProductNo -> FaultReported

c. Identify whether the relation is in 2NF, and, if not, suggest a decomposition of


the relation which then conforms to 2NF.

Ans: The relation is NOT in 2NF, becauseJob ReportDate depends on a


subset of the PK. Split into 2 relations, one containing (JobNo,
JobReportDate) and one containing (JobNo, ProductNo, FaultReported).

Exercise 3

Examine the following table:

ProductNo ProductName ProductTypeCode ProductTypeDescription


F386 Laptop P4 LAP Laptop
X686 Laptop Athlon LAP Laptop
G52 Laptop carry bag ACC A Small Accessory
F442 Battery BATT Battery
G55 Laptop carry bag ACC B Large Accessory
X456 Battery BATT-D Battery

a. Identify all the functional dependencies in this relation


Ans: ProductNo -> ProductName
ProductNo -> ProductTypeCode
ProductTypeCode -> ProductTypeDescription
(also ProductNo -> ProductTypeDescription is a transitive
functional dependency – needs explained if the students identify it)

b. From this set of dependencies, state whether this relation is in 3NF, and if not
suggest a decomposition of the relation which then conforms to 3NF.
This relation is not in 3NF because of the FD ProductTypeCode ->
ProductTypeDescription, so we need to decompose into two relations, one
containing (ProductNo, ProductName, ProductTypeCode) and one
containing (ProductTypeCode, ProductTypeDescription)
Question 3

Consider the data that has to be stored in a typical University or College with regard
to Students, Courses, Modules, Lecturers, etc.

Essentially, a student is enrolled onto a programme and may take several modules as
part of this programme. Normalise this data to be in 3NF.

Once we ensure this table is in 1NF, then we can identify the composite primary
key as {StudentNo, ModuleNo}. These together are unique for each tuple in the
relation.

We therefore consider the FDs for each non-key attribute:

StudentNo -> Name


StudentNo -> Programme
StudentNo -> Duration (transitive dependency as we also have the FD below)
Programme -> Duration

ModuleNo -> ModuleName


ModuleNo -> Lecturer

Our relation is therefore clearly not in 2NF, because all the non-key attributes
are not fully dependent on the primary key. Our 2NF solution is therefore to
create three tables:

1. StudentNo*, ModuleNo*
2. StudentNo, Name, Programme, Duration
3. ModuleNo, ModuleName, Lecturer

We then need to consider 3NF. Both tables 1 and 3 are in 3NF, but table 2 is not
because of the transitive dependency. Our solution is therefore to decompose
this into two tables:

2a. StudentNo, Name, Programme*


2b. Programme, Duration

Underlined attributes indicate Primary Key, * indicates a foreign key.

You might also like