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.
Related
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).
Consider a database relation of student records as follows:
Student (I,G,P,M,S,Y,E,L,R,C)
(a) Show how to derive two candidate keys for Student, or justify why you cannot do so.
(b) What normal form is Student in? Show working that justifies your answer.
(c) If F contained MSY→LRCE instead of PMSY→LRCE, what would this imply about paper
names? (i.e., the values of M)
(d) Find a minimal cover (i.e, an irreducible set of functional dependencies) for Student.
(e) Find a decomposition of Student into third normal form (3NF).
I stuck on the first question about the candidate key. I know that the candidate keys must be a subset of (I,P,M,S,Y,L,R) since these appear on the left hand side of the Functional dependancies above and determine all of the remaining attributes. We can remove M which is determined by P, but then I was kinda confused about how to make these attributes to be the minimal, especially from complexed functional dependencies such as PMSY→LRCE. Thx for any solution and suggestions.
I won't do your homework but as a hint on (a);
F:IGPMSYELRC->IGPMSYELRC
always holds. By virtue of F:P->M you can remove M and get
F:IGPSYELRC->IGPMSYELRC
now apply F:R->C to get
F:IGPSYELR->IGPMSYELRC .
Repeat this until you cannot remove any attributes from the left-hand side.
Then you got a candidate key.
With different permutations of F this may yield other 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.
I have a problem about the 2nd normal form. The rule says : “A relation is in second formal form when it is in 1NF and there is no such non-key
attribute that depends on part of the candidate key, but on the entire candidate key.” (Neeraj Sharma, 2010) My problem is about the candidate key. It is only the primary key of a relation or all possible candidate keys.
Thank you for your help
It counts for any candidate key. If it counted only for the primary key, simply adding a surrogate id would be enough to put any table into 3NF. However, that wouldn't help to ensure that each fact is recorded once only and independent of other facts.
Trying to clear your doubt by an example:
According to 2NF "Partial Dependencies are not allowed in a relation."
Assume this relation: R(A,B,C,D)
lets suppose there are 3 CK's related to this relation (Assume CK's: AB,AC,B).
Then first write all the attributes that are present in any of CK's,these are called Prime attributes.Other than that are called non prime attributes.
Here:
Prime Attributes (3)= {A,B,C}
Non Prime Attributes (1)={D}
Now According to 2 NF, any FD should not be in this form:
This kind of FD's aren Not allowed in 2NF:
"Part of any candidate key(Partial Dependency) ---> Non Prime attribute"
Means:
Here : C---> D(Not allowed in 2 NF because C is a part of CK "AC" and D is non prime attribute)
Hope this helps. For more detail, you can also refer : Detailed explanation of Normal forms
needing desperate help with understanding boyce codd and finding the candidate keys.
i found a link here http://djitz.com/neu-mscs/how-to-find-candidate-keys/ which i have understood for most part but i get stuck
e.g
(A B C D E F)
A B → C D E
B C D → A
B C E → A D
B D → E
right as far as i understand from the link i know you find the common sets from the left which is only B, and common sets from the right which are none
now where do i go from here? i know all candidate sets will have B in them but i need guidance on finding candidate sets after that. someone explain in simple language
The linked article isn't written particularly well. (That's an observation, not a criticism. The author's first language isn't English.) I'll try to rewrite the algorithm. This isn't me telling you how to do this. It's my interpretation of how the original author is telling you to do this.
Identify the attributes that are on neither the left side nor right side of any FD.
Identify the attributes that are only on the right side of any FD.
Identify the attributes that are only on the left side of any FD.
Combine the attributes from steps 1 and 3.
Compute the closure of the attributes from step 4. If the closure comprises all the attributes, then the attributes from step 4 make up the only candidate key. (No matter how many candidate keys there are, every one of them must contain these attributes.)
Identify the attributes not included in step 4 and step 2.
Compute the closure of the attributes from step 4 plus every possible combination of attributes from step 6.
So for the FDs you posted, you'd end up with this.
{F}
{}
{B}
{BF}
The closure of {BF} is {BF}. That's not all the attributes. (But every candidate key must contain {BF}.)
{ACDE}
Compute the closure of these sets of attributes.
{ABF}
{CBF}
{DBF}
{EBF}
{ACBF}
{ADBF}
{AEBF}
{CDBF}
{CEBF}
{DEBF}
{ACDBF}
{ADEBF}
{CDEBF}
If I got those combinations right, every candidate key will be found among the possibilities in step 7. In your example, there are 3 candidate keys.
http://www.sroede.nl/projects/fdhelper.aspx
this would help'just put in ur relation and FD's
click generate at the bottom