I need help finding the candidate keys from the given relation:
R (A,B,C,D,E) with FD:
A -> BE
B -> BE
B -> D
STEPS:
I know all the attributes can identify themselves so: A,B,C,D,E -> {ABCDE}
Now I know A -> BE, so i can cross out BE and get this: ACD -> {ABCDE}
The prime attributes are (A,C,D)
D would now be replaced by B giving me my other candidate key of (ABC)
I have the answer has ACD and ABC but apparently, it's AC. What am I doing wrong?
A simple reasoning is the follow.
A and C must be present in any candidate key, since they never appear in the right part of some FD.
So, let’s see if they are already a candidate key by computing their closure, AC*.
By applying the rules for computing the closure of a set of attributes, we can see easily that AC* is equal to ABCDE, so AC is a candidate key. The only other attribute that appears in the left side of a FD is B, so we should check that no other candidate key contains it. But noting that the attributes AC must be present in any key and already they form a candidate key, so adding any attribute to them produces only superkeys, we can conclude that this is the only candidate key.
Related
I was doing homework for DB class.
One of the questions bugs me out even though I got the answer(I think)..
Question was simple.
FOR GIVEN RELATION R(A,B,C,D,E) and Functional dependencies F(AB -> C, D->E, DE ->B)
1. IS R IN 2NF?
2. IS R IN 3NF?
3. IS R IN BCNF?
I thought since there's no A and D on right-hand side of all FDs in F, A and D must be part of Candidate keys.
So I checked the Closure of AD, and I got AD+ : {A,B,C,D,E}.
That means that AD is super key.
Also, since both A and D must be part of Candidate key and AD cannot be reduced(no closure of subset of AD is {A,B,C,D,E}), AD is a candidate key and only possible candidate key. (Am I doing this right?)
With candidate key AD, D->E is partial dependence on candidate key AD.
So it violates the condition of 2NF.
On DE -> B, is this FD is violating 2NF?
If that's true then..
Is it violating because we can get D->DE from D->E . so DE -> B is equivalent to D -> B. Is this D->B is violating 2NF ??
OR
DE->B itself violates the 2NF without any conversion because of D on left-hand side?
It really confuses me when XY -> Z X is part of Candidate key and Y,Z is non-prime key.
Because I can't say it is violating 2NF or not. I think it is violating 2NF but I can't say why clearly.
I've been looking for examples and explanations and clips for hours but I haven't got any satisfying answer.
It's okay if I don't care specific reason and just want credit . But I can't bare myself with that kind of attitude.
Also, since both A and D must be part of Candidate key and AD cannot be reduced(no closure of subset of AD is {A,B,C,D,E}), AD is a candidate key and only possible candidate key. (Am I doing this right?)
Yes
Is this D->B is violating 2NF ?
Yes, since B is a non prime attribute and D is part of a candidate key and the dependency holds, since it is implied by D -> E and DE -> B (in a relation in 2NF dependencies where the determinant is a proper subset of a candidate key and the determinant is a non-prime attribute cannot hold).
If I Have R(E, F, G, H), what would be the candidate keys from these functional dependencies?
FD1: EF -> G
FD2: EF -> H
FD3: G -> E
FD4: H -> F
My thought process was that EF would be considered a candidate key, since EF -> G and EF -> H, therefore EF+ = {E, F, G, H}. Could I say the same in saying that GH is also a candidate key, since G -> E, H -> F, therefore GH -> EF and GH+ = {E, F, G, H}? Would there be any other candidate keys?
The schema has four candidate keys: EF, EH, FG, GH. You can easily verify this fact by computing the closure of each pair of attributes, and noting that it contains all the attributes.
The question is naturally how to find them. The trivial method is simply to try the closure of all the subsets of attributes of the relation, but this is obviously inefficient, being an exponential process.
There are more efficient algorithms to find all the candidate keys, but they are quite complex. There are simple heuristics that can help in reducing the complexity of the solution, without using a formal algorithm.
First, you should start from a canonical cover, otherwise these heuristics cannot be applied (in your example you have already a canonical cover). The first step is that you can exclude any attribute that appears only in the right hand sides of the dependencies (not in this case), and consider that all the attributes appearing only in left hand sides must be always part of any key (also not in this case).
Then, you can start from the left hand sides of the dependencies, and compute their closures to see if those sets of attributes can determine all the others. If this is not the case, you can add the other attributes, one at time, and again compute the closure of the resulting set, stopping considering those attributes when you have found a key or the set includes a subset already considered.
For instance, from EF you have found that you can determine all the other attributes, so this is a candidate key. Then, considering G, you can add E, noting that EG+ = EG, so this is not a candidate key, then add H, noting that GH+ = EFGH, so this is a candidate key, and finally add F, finding that FG is a candidate key. Of course, when a set of attributes is a candidate key you do not add to it other attributes. Another set of tests starts with H, first HE (which produces a candidate key), then HF, which do not produce a candidate key. At this point we should check if adding an attribute to EG or to HF we obtain a candidate key, but we can safely stop here since we will obtain just a superset of a set already considered (like EGF, for instance, that contains GF).
I have a set of functional dependencies:
V = {ABCDEF} F = {AB → CD,ABDE → F,BC → A,C → DF}
Candidate keys are: {ABE, BCE}
Canonical cover is: {AB→ C, BC→ A, C→ DF} [This is what I think, might be wrong]
However, as you can see an attribute of candidate key, E, is not in my canonical cover and as far as I know candidate keys should be same in the canonical cover.
If you consider Augmentation rule from Armstrong calculus we can say it is correct but I am confused. Does attribute E have to be represented in the canonical cover?
You say:
as far as I know candidate keys should be same in the canonical cover
This is not true. On the contrary, if an attribute does not belong to any right part of the functional dependencies of a canonical cover, it must be present in any candidate key (this is because it cannot be derived from any other subset of attributes, so, since a candidate key must determines all the attributes, it should be present in any key). Your canonical cover and candidate keys are correct.
Note that if an attribute does not belong to any functional dependency (both in the left and right part), as E in your example, this is a special case of above (it does not belong the a right part side), and must be present in any candidate key.
Finally, note that this can be considered a “symptom” of something wrong in the relation and in fact the schema is not in 3NF or BCNF.
Well, when I try to do Bernnstein synthesis from this relation (ABCDEF) I have to use basis: {AB→C,BC→A,C→DF} I need to add candidate keys since no candidate key exist when we form a relation from functional dependencies : R1(ABC) and R2(CDF) and I was wondering if we need to add E here since our basis doesn't contain E and we consider basis when we do synthesis. That's why I was little confused. But, I think we need to add E since we are doing a synthesis from original R(ABCDEF) so it should be R1(ABC), R(CDF) and R3( ABCE). R3 contains all candidate keys.
Example:
Let R = (A, B, C, D)
Let F = {C -> AD, AB -> C}
Then how can I find the candidate keys?
The answer is {AB, BC}
Why?
Given a relation schema R with a set of attributes T and a non-empty set of non-trivial functional dependencies F describing a certain set of constraints that are assumed to hold in that schema:
Every attribute that does not appear in the right part of a FD in F must be present in any candidate key.
Every attribute that does not appear in the left part of a FD in F cannot be present in any candidate key.
To find all the candidate keys, for all the other attributes, you should try to add to the attributes of 1 above every possible combination of them, and see if the closure determines all the attributes of the relation (and such that you cannot remove any attribute from the combination without losing this property).
Note that, if the set F is empty, the only candidate key is constituted by all the attributes T.
In practice there are algorithms that can be relatively efficient (since the problem of finding all the keys is in the general case exponential).
A simple approach is to start from a canonical cover of the functional dependencies, in this case for instance from:
{ A B → C
C → A
C → D }
and after finding the attributes that must be present in any candidate key (in this case B), try to add to them the left hand side of the dependencies (in this case both AB, that is A, and C) (in any order, and possibly combining them) and compute the closure to see if they determine all the attributes. When you discover that some set of attributes determines all the relation attributes, you have found a candidate key (and it is not necessary to add other attributes to it). In your example:
(A B)+ = A B C D
(B C)+ = A B C D
So A B and B C are candidate keys (since you cannot remove any attribute to both of them without losing the property of determining all the other attributes). And since there are no other attributes (a part from D that cannot be present in a candidate key), you know that you have found all the candidate keys.
Consider relation R = (A, B, C, D, E, F) and a set of functional dependencies:
AB --> C
BC --> A
BC --> D
D --> E
CF --> B
What are all the candidate keys?
Please if anyone can give me the answer and explain how.
Let me explain how to find candidate keys in a simple manner:
Form a three columns,left,right and middle
In left column,add the attributes which appear only on left hand side of FD
In right column,add attributes which appear only on right hand side of FD
In middle column,add attributes which appear both on right and left hand side of FD
Explanation:
Attributes on left column indicates,every possible candidate keys must include these attributes
and
Attributes on right column indicates candidate keys should not include it
and
Attributes on middle may or may not be included in super keys
In the given example,F is placed in left column and A,B,C,D are placed in right column and E is placed in right column
Then,apply Closure property,
AF+->AF reflexivity rule
BF+->BF reflexivity rule
CF+->ABCDEF
because
CF->CF reflexivity rule
CF->B given
CB->A given
CB->D given
CB->A transitivity rule CB->D and D->A
Thus,CF->ABCDEF and CF is the candidate key
Hope,this helps!
I hope this will help you finding the candidate key for this answer .
As per my analysis candidate key for these functional dependencies are :
AB, BC, ABC, ABD, BCD, ABCD