Hi

Can someone please give me some guidance?

From the attached spreadsheet below i've determined that the following are the FD's:

> Title --- Description
> Media ID --- Description, Title, Format
> Returned By --- Name, House, Address, City, County, Post Code, Phone
> Status ID --- Status Description
> Status Description --- Status ID
> City --- County
> County --- City
> Phone --- Returned By

And from the FD's i've determined that the attributes on the left hand side of the relationship are the attributes that make up the composite PK.

If you need any clarification on the question or if there is any confusion with the attachment, please let me know

Thanks for your help

Whitebear

wha?

there was no question in your post

Sure there was a question:-PatP

My apologies for not being clear.

Have I identified the correct FD's, and if so is the composite PK correct too?

From looking at my results though, there seems to be too many FD's?

Hope that clears things up

Whitebear

A candidate key must be both unique and irreducible. Is that the case for your proposed composite key?

I don't see the point of this exercise if the dependencies are to be based solely on the small sample of data you are given. For all practical purposes dependencies are defined by the semantics of the data across all valid values. So for example the dependency County->City holds for the tiny sample you've been given but we know it will not hold as a general rule so it is not likely to be useful to enforce it.

Are you saying that the composite key is the same as the candidate key then? I can find many definitions of a candidate key, but none for a composite key.

The purpose of the exercise is to teach us Normalisation, we're meant to take the data provided to 3rd NF, but the issue you've identified has caused me confusion, and then I start to over think the data and get my self in a mess.

I think the FD's I'm going to go for are:

> Title --- Description
> Media ID --- Description, Title, Format
> Returned By --- Name, House, Address, City, County, Post Code, Phone
> Status ID --- Status Description
> Status Description --- Status ID

Looking at the possible data entries for the attributes I think the rule will hold.

A composite key (also called a compound key) is a candidate key with more than one attribute.

I suggest you ask your tutor if you need more help with the exercise.

<ot>I only learned this recently, but compound key and composite key are not interchangeable terms</ot>

In what way? Do you have a reference for that?

I'll confess I don't have an online source that I can hold up as authoritative, however there are several references around e.g.
Compound Key
Composite Key

The difference is subtle and I admit I use them interchangeably, but it is the kind of detail I suspect you would be interested in.

What does FD stand for?

Thanks. I think this is based on the ER modelling idea of distinguishing between identifying and non-identifying relationships: the compound key (in ER modelling terms) being the key on the end of an identifying relationship, which means its attributes include a key from another table. In relational model terms there is no difference between one candidate key and another and therefore composite and compound can safely be used interchangeably I would have thought.

Functional Dependency

what does the <ot> stand for?

PS I wonder if we were all as keen to do our own coursework, when we were at college, as we appear to be now to do other peoples

<ot>ot = off topic</ot>