Faculty of Science, Engineering and Technology

Fundamentals of Data Management

Credit Tasks 4.2.1: Functional Dependencies and Normalisation
Overview
In this tutorial, you’ll practise identifying functional dependencies and ensuring a
relational database is in third normal form.

Purpose
Learn to identify problems with database schemas and how to solve them using
normalisation.
Task
Solve the functional dependency and relational design problems outlined below.
Time
This task should be completed in your fourth lab class and submitted for feedback in the
fourth lab.
Resources
• Elmasri & Navathe, Fundamentals of Database Systems, Chapter 15
• Connolly & Begg, Database Systems, Chapter 14
• Online resources, e.g.
o https://www.youtube.com/watch?v=oGObN5TKY9E
o http://www.cs.nott.ac.uk/~nza/G51DBS/dbs11.pdf
• You can use a specialised tool or simply use tables in your lab report.
Feedback
Discuss your solutions with the tutorial instructor.
Next
Get started on week5.

Credit Tasks 4.2.1 — Submission Details and Assessment Criteria

Document your solutions to the tasks in document using a word processor or other
suitable software. Upload a pdf to Doubtfire. The tutors will discuss them with you in the
lab.
Subtask 4.2.1
Suppose all information you have to determine functional dependencies is a table of
data. Depending on unique mappings available a column or a set of columns may qualify
as foreign key. Note that given we don’t know the actual purpose of the table, any new
row may contradict our findings.
Identify the possible functional dependencies in a table that has the following entries:
A B C D
a1 b1 c1 d3
a1 b2 c3 d2
a2 b2 c3 d4
a3 b3 c5 d4

A, B, C and D are the attribute names. Decide which attributes could possibly be
dependent on another attribute or pair of attributes. The way to decide is by exclusion; if
a value of A is in the same row with a two different values of C, C cannot be functionally
dependent on A (but the reverse may be the case).
For example, both a1 and a2 are in the same row with a value of b2. So based on A, we
can’t be sure what the value of B should be.
This is the same question as asking what is a potential primary key for this table.
Present your findings in the following table (you can copy it into your report):
Dependency Possible (Yes/No) Why/why not?
A -> B No the same A value have different B values

A -> C No the same A value has different C values

A -> D No the same A value has different D values

B -> A No the same B value has the same A values

B -> C Yes every B value has a unique C value

B -> D No the same B value has different D values

C -> A No the same C value has different A values

C -> B Yes every C value has a unique B value

C -> D No the same C value has different D values

 {A, B} -> C Yes every combination of A and B has different
C value

{A, B} -> D Yes every combination of A and B has

different D value

{B, C} -> A No a combination of B and C has 2 different

A values

{B, C} -> D No a combination of B and C has 2 different D

values

{C, D} -> A Yes every combination of C and D has

different A value

{C, D} -> B Yes every combination of C and D has

different B value

{A, C} -> B Yes every combination of A and C has

different B value

{A, C} -> D Yes every combination of A and C has

different D value

(Don’t worry about the rest of the possible combinations.)

What do you conclude? Do we need a composite key or does one attribute suffice as a
key?
Document your findings and upload.
Each primary key need to have a unique non-primary key. One attribute is not sufficient enough
to be a primary key. We need to find a composite primary key.
From the table above, the combination of {A, D} and {B, D} were not tested. From these 2
combination, we get the following dependencies:
{A, D} -> B
{A, D} -> C
{B, D} -> A
{B, D} -> C
These dependencies are all possible as every combination has a unique dependent value.

From here we can conclude that any of the 2 combination except B and C can create a primary
key.