-3
A - flight_date
B - plane ticket price
C - source_airport_country
D - ticket holder names
E - address 
F - source airport
G - Pilot_name
H - Pilot_grade
I - Plane_id

There is a functional dependency between the plane_id, the flight date and the pilot name (if I know the date of the flight and the plane used I can find the particular pilot that flew that flight). I.e.

AI --> G

What other functional dependencies exist amongst these attribute

answers should use letters to denote the attributes and so should look like: AI --> G

For the relation R(A,B,C,D,E,F,G,H,I), (i.e. the attributes above) and using the functional dependencies you found above find, using the key determination algorithm, those attributes that are: 1. Definitely part of the key for R, 2. Defintely not part of the key for R, and 3. Maybe in the key for R. Finally derive a key for R.

Strawberry
  • 33,750
  • 13
  • 40
  • 57
james dunne
  • 3
  • 2
  • Sorry, I can't figure what you are trying to achieve here, but realistically assigning attributes, F-source is unclear for a definition. What does source contain? Secondly, Pilot needs an id. Names and even dob's combined with names cannot be relied on. You need a unique identifier for pilot. – Mugé Aug 14 '15 at 20:49
  • oh sorry source if for source airport – james dunne Aug 14 '15 at 20:51
  • muge, this is just a task iv been set their are other tables, but in this particular question I have to find any functional dependancies between the given tables – james dunne Aug 14 '15 at 20:54
  • To give one example, you may set up a list of airports for a particular country and which planes land at a particular airport: I->CF, this can expand on dates and pilots. Still not sure if I am at the right track in what you want to achieve. Are you looking for a realistic dependency scenario? – Mugé Aug 14 '15 at 21:03
  • yes you are along the write lines, its just that im really bad at spotting these haha – james dunne Aug 14 '15 at 21:06
  • Just think of a realistic scenario. To give an example you can continue brainstorming from, 1-There are in-bound and out-bound airports serving in-flights or flights from other countries also depending on size of a plane some cannot land in smaller/inbound airports. 2- A pilot who flies to a country cannot be available for another flight from another country, so date/pilot/airport is another attribute to work on. 3- Ticket holders cannot fly from a country that is their destination, they need source country that matches with depart/return flights/dates. I hope these help :) good luck! – Mugé Aug 14 '15 at 21:13
  • 2
    This looks like a homework problem... – Unome Aug 14 '15 at 22:35
  • 1
    We have very different definitions of 'clarity' – Strawberry Aug 14 '15 at 22:36
  • 1
    So how have you been told to go about doing this? Where did you get stuck from some resource from googling '(find OR determine) (fds OR "functional dependencies")'? If you don't understand a reference then ask a question about the first thing you don't understand. And what are all FDs and non-FDs do you claim are present, and why? – philipxy Aug 16 '15 at 02:06

1 Answers1

0

From this answer:

Re Application relationships and situations:

Together the application relationships and situations determine both the rules and FDs (and other constraints)! They are just things that are true of every application situation or every database state (ie values of one or more base tables) (which are are a function of the criteria and the possible application situations.) Then we normalize to reduce redundancy.

Re FDs & CKs:

Given the criterion for putting rows into or leaving them out of a table and all possible situations that can arise, only some values (sets of rows) can ever be in that table.

For every subset of columns you need to decide which other columns can only have one value for a given subrow value for those columns. When it can only have one we say that the subset of columns functionally determines that column. But every superset of that subset will also functionally determine it, so that cuts down on cases. Conversely, if a given set does not determine a column then no subset of the set does. Also, you may think in terms of column sets being unique; then all other columns are functionally dependent on that set. Such a set is called a superkey.

Only after you have determined the FDs can you determine the candidate keys! A CK is a superkey that constains no smaller superkey. (The presence of CKs and superkeys are also constraints.) We can pick a CK as primary key.

See this answer and this one (and others of mine involving normalization).

Community
  • 1
  • 1
philipxy
  • 14,867
  • 6
  • 39
  • 83