Académique Documents
Professionnel Documents
Culture Documents
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}