# Determine Secrets from Functional Dependencies

I am going for a database theory course, and it is not obvious in my experience after doing the reading through the way i can infer secrets, given some functional dependencies.

I've a good example problem:

Find all secrets from the relation R(ABCDEFG) with functional dependencies

``````AB → C
CD → E
EF → G
FG → E
DE → C
BC → A
``````

Demonstrate your understanding by determining which of this is a vital.

``````a. BCDEF
c. BDFG
d. BCDE
``````

Can someone walk me through the way i should decompose the running dependencies to summarize that some mixture of characteristics is really a key? I expect I'll face several of these kinds of problems and I have to learn how to approach it.

Take an FD, e.g. AB->C

Augment until all characteristics are pointed out, e.g. ABDEFG -> CDEFG (observe that this is the same as ABDEFG -> ABCDEFG since it is trivially correct that A->A and B->B).

This informs you that ABDEFG is really a superkey.

Look into the other FDs where the LHS is really a subset of the superkey, which on its RHS consists of another attribute of the superkey.

You will find two. EF->G and FG->E. Take away the characteristics from the RHS of those out of your superkey. Doing this provides you with two secrets, which are certainly superkeys, although not always irreducible ones: ABDEF and ABDFG.

However, from AB->C and Compact disc->E we are able to also derive that ABD->E. Hence we are able to also take away the E from your ABDEF key. The nasty factor here's that after I stated "Look into the other FDs", that apparently means that you ought to also check any FD that seems within the closure of the group of FDs (i.e. any FD that's derivable out of your given group of FDs)... And that is a little not practical to complete manually ...

http://www.koffeinhaltig.com/fds/ueberdeckung.php

You need to now have the ability to determine that option c is really a key.

Since you are inside a db theory course, I am likely to assume you've SQL experience and check out and relate the idea towards the implementation context.

Essentially, a relation is what you will describe as a table in implementation along with a secret is ANY group of characteristics (read posts) which may be used to identify a distinctive row (in db theory this is a tuple). The easiest example here's that the secret is most of your key, in addition to every other possible group of posts will identify just one tuple inside your relation (row inside your table). So, listed here are the fundamental steps for carrying this out (I'll walk-through example A, and you can try the relaxation):

1. List all the characteristics which aren't inside your suggested key (so BCDEF doesn't incorporate a and G).
2. For every attribute you are missing, feel the listing of functional dependencies and find out in case your suggested key is capable of doing inferring the attribute you are missing.

``````             a. So for A, you have BC -> A.  Since both B and C are in the proposed
key BCDEF, you can infer that BCDEF -> A.  Your set now becomes
BCDEFA.
b. For G, again going through your FDs you find EF -> G.  Since both
E and F are in BCDEFA, you can infer BCDEFA -> G.
``````

Since you could infer both A and G from BCDEF, option a is really a key from the relation ABCDEFG. I understand there's an formula with this, which is most likely inside your course text somewhere. There's also most likely a good example. You need to step through it by hand before the pattern is intuitive.

EDIT: The main reason I'd return with the text to search for this formula is the fact that odds are your exam will probably be written instead of multiple choice as it is a db theory course. If this sounds like true you would then have more partial credit if you're able to systematically follow notation shown inside your course text/notes.

The primary goal would be to turn the important thing in to the relation, that ought to prove the suggested key is actually a vital.