Solving Normalisation Problems

Plan Report
Client_id
Client_name
W237651 Williams
W237651
B849821
S154987

Williams
Baker
Smith

J234159

Jacobs

Street
12 Pemberton
St
256 Walsh St
68 Havannah St
96
Rosemary Lane
42 Morgan St

Town
Albury

Land_Size
1000

Plan_id
RGA2768

Plan_name
Sheds

Designer_name
French

Designer_Loc
B160

Albury
Bathurst
Orange

600
750
2200

RGA3987
RGB1256
RGO3456

Fountain
Vegetables
Front

Todd
French
Miller

B104
B160
A210

Wagga

1200

RGW3765

Cottage

Bennet

W112

1. Start by identifying what looks to be a possible primary key. In our table here, Client_Id is
underlined, so it has been identified as the PK.
2. Now what attributes relate directly to a client_id?
a. Client_name, street and town look to be related to a client, so they are distinct
possibilities;
b. What about land_size? Is that related to a client? Does the client_id determine what
land size we have to work with? Could be, so at this stage we will include land_size
with client;
c. What about plan_id and plan_name? Well, they are related to a client, because the
client wants something done to their land, but they are not attributes of a client. So
they would be a different table. But to check, would a plan_id determnine what plan
we would look at? The answer is probably yes, so that looks good;
d. Now, what about designer_name and designer_loc? Are they part of the attributes
of a client? Probably not. Are they attributes of a plan? Possibly, but they might be
able to break down further. So lets look at it: Does a plan_id determine a designer
name? Probably, so that looks ok. But what about designer_loc? Is that determined
by the plan_id or the designer_name? It looks like the designer_name determines
where the designer is located, so that looks like another table.
3. Now lets look at where we stand after going through all this:
a. Lets start with the original dependency diagram
{client_id} -> {client_name, street, town, land_size, plan_id, plan_name, designer_name,
designer_loc}
b. But we know that Client_id determines only the client related attributes, so that
gives us:
{client_id} -> {client_name, street, town, land_size}
c. Then we know that plan_id gives us another table
{plan_id} -> {plan_name, designer_name, designer_loc}
d. But we also know that designer_name has its own dependent attribute:
{designer_name} -> {designer_loc}

4. So our new position is this:

Dependency diagram Client
{client_id} -> {client_name, street, town, land_size}
Dependency diagram Plan
{plan_id} -> {plan_name}
Dependency diagram Designer
{designer_name} -> {designer_loc}
5. Now, we need to check that the tables are in at least 3NF:
a. 1NF requires a PK and no repeating columns:
i. All tables have a PK and no repeating columns; so this looks OK, they are all
at least 1NF.
b. 2NF requires 1NF and no partial dependencies:
i. All tables have a single attribute PK, so they cant have any partial
dependencies; this looks good, so they are all at least in 2NF.
c. 3NF requires 2NF and no transitive dependencies:
i. In Client, does land_size depend on the combination of street and town?
This is quite likely, so we now have identified a transitive dependency in this
table. To remove this dependency, we split this Transitive dependency out
of the table and create a new table: Land.
ii. Land now has to have a dependency diagram created, so it would look
something like this:
{street, town} -> {land_size}
6. Our final tables would therefore look like this (Note that the tables include any foreign keys
that are required!):
Table Client( client_id, client_name, plan_id, street, town)
Primary Key (client_id)
Foreign Key (plan_id) References Table Plan
Foreign key (street, town) References Table Land;
Table Land (street, town, land_size)
Primary Key (street, town);
Table Plan( plan_id, plan_name, designer_name)
Primary Key (plan_id)

Foreign Key Designer_Name References Table Designer;

Table Designer(Designer_name, designer_loc)
Primary Key (designer_name);
7. Note: For these normalisation exercises, you do not normally add attributes, even to add a
surrogate key, for example in either Table Land or Table Designer.