I have a relation A,B,C,D,E with functional dependencies
1) A->BC
2) CD->E
3) B->D
4) E->A
Using 1 gives A,D,E and then using 4 will make it D,E
Using 2 gives A,B,C,D and then using 3 gives A,B,C and using 1 gives A
Using 2 gives A,B,C,D and using 1 gives A,D
Using 4 gives B,C,D,E and using 2 gives B,C,D and using 3 gives B,C
Using 3 gives A,B,C,E and using 1 gives A,E and using 4 gives E
So I would have 5 super keys? (A, E, AD, BC, DE). And from my super keys I would pick the unique ones.
Since I can get A from E, I can remove A and AD(since DE is the same) and since I can get BC from A I can remove that so I am left with
E, DE
Would that be my super key? Or would it just be E?
By definition, a candidate key K of a relation is a set of attributes that determines all the others and such that we cannot remove any attribute from it without losing this property.
To find all the keys of the relation, if you do not follow a formal algorithm, then you could start by checking from each determinant of the FDs and see if this is a (super or candidate) key, by calculating its closure. For instance, starting from A, you can find:
A+ = A
= ABC (by using 1)
= ABCD (by using 3)
= ABCDE (by using 2)
So, A determines all the attributes and for this reason is a candidate key (and not a strict superkey, since you cannot remove any attribute from it!)
Calculating the closures of the other determinants, you can find that:
CD+ = ABCDE (candidate key, since C+ and D+ do not contain all the attributes)
B+ = BD (not a key)
E+ = ABCDE (candidate key)
Now you have three candidate keys, A, E, and CD. And since B determines only D, we could try to add something to it to see if it can be part of a key. We do not add A, or E, since they are already keys, and we do not add D since it is already determinated by B (so that having it will produce surely a superkey). So we try C:
BC+ = ABCDE (candidate key, since B+ and C+ do not contain all the attributes)
So, finally, we can say that the relation has four (and only four) candidate keys:
A
BC
CD
E
Related
Here I did 2 questions about functional relations and normal forms and i have some follow-up questions, things I couldn't find answers for.
1. On the relation scheme R(A, B, C, D, E, F) on which following
functional dependencies are being applied:
F = {ABC →D, CE→B, E→C, BF→AC, E→F, F→E}.
• Find (AB)+, (CD)+,(EF)+
• Find all candidate keys.
• Find all function dependencies which cause this relation not to be at BCNF.
(AB)+=AB | (CD)+=CD | (EF)+=EFCBAD
Find all candidate keys
(AB)+=AB | (BF)+=BFECAD
(AC)+=AC | (CE)+=CEBFAD
(AE)+=AECFBD | (CF)+=CFEBAD
(AF)+=AFECBD | (EF)+=EFCBAD
(BC)+=BC | **(E)+=EFCBAD**
(BE)+=BECFAD | **(F)+=FECBAD**
Candidate keys are: E and F
Prime attributes are: E and F
Non-prime attributes are: A, B, C, D
Other Keys that functionally determines relation scheme R are not
candidate keys because they don’t fulfill "minimality" rule!
2nd
2. On the relation scheme R = (A, B, C, D, E, F G, H) on which following
functional dependencies are being applied:
F= {A →E, GH → C, DB → H, BG → A, C → D, G → H, H → B, AE → G}
• Find (A)+ and (DBG)+
• Does G →B applies from fd F
• Find all candidate keys.
• In which normal form is following relations scheme?
(AB)+=AB| (CD)+=CD | (EF)+=EFCBAD
Find all candidate keys:
**(A)+=AEGHBCD** | (B)+=B | (C)+=CD | (D)+=D | (E)+=E | (F)+=F | **(G)+=GHBCDAE** |
(H)+=HB
Candidate keys are: A and G
Other Keys that functionally determines relation scheme R are not
candidate keys because they don’t fulfil minimality rule!
Prime elements are: A and G
Non prime elements are: B, C, D, E, H
1NF – yes
2NF – yes, because there are no partial key dependencies
3NF – no, because ABC ->D (functional dependency between 2 non-prime elements).
BCNF – no, because it is not in 3NF
QUESTIONS:
1) Am I right with all of these that I wrote?
2) At 1st question, there are a lot of keys that are made by 2 elements, but they are not candidate keys, because the "minimal" rule is not applying on them. Am I right with this?
3) What if the part of the key is non-prime and part is prime element and that key functionally determines some other non-prime element. Is that relation at 3rd Normal form?
4) What if candidate part of the key (prime element) functionally determines another prime element, is that relation at 2nd Normal form?
5) In case there are a lot of keys that has "minimization" characteristics and they are candidate keys, do they all apply as candidate keys (for example 10 candidate keys)?
6) At 2nd question here, the F element is not being used in any functional dependency, but it is part of relation scheme. Do I left element F out, or element F must be part of the candidate key (also prime attribute/element)?
I'm studying for my database exam and I'm not sure about one question which goes as follow:
Given the relation R={A, B, C, D, E, F, G, H, I} and the set of functional dependencies
F = { AB -> C,
A -> DE,
C -> AB,
B -> FGH,
D -> IJ,
D -> CBE
}
Under what (normal) form is this relation?
First, I know I have to find all candidate keys. Looking at the right, I see that every attribute of R appears on the right hand-side, so it is not trivial that any single attribute of R is a candidate key. So looking at the left hand-size, only A, B, C, D appear, so one or some of these attributes must appear in the candidate keys.
So using A, C and D works (details skipped), but using B alone doesn't. Considering using two-attribute ket is useless since any key that does not contain A, C or D won't "bring us back" to R. Exemple, BE allows us to find B, E, F, G, H, but then we can't proceed further, so not all attributes of R are found.
Also, using any combination with A, C, or D in it is useless since it contains a subset (a single attribute) which is part of a candidate key (a single attribute). Example, AB can be reduced to A, and then all attributes of R can be found.
What bugs me is AB -> C and C -> AB, which is a circular dependency. I thought of two possibilities:
C is the primary key and we can use it to find A and B (C -> AB);
AB can be reduced to A (as said above) and with it we can find C.
But it is very easy to see that AB must be unique and C must also be unique.
Let's only use AB -> C. We can have the following associations:
11 -> 1 (A = 1, B = 1, C = 1)
12 -> 1
But then, if we reinsert the rule C -> AB, we find:
1 -> 11
1 -> 12
which can't hold.
So C has to be unique.
Same thing if we only consider C -> AB, and then reinsert the rule AB -> C.
I'm starting to think that this is a trick and that the real primary key of this relation is ABC to ensure uniqueness of the combinations of AB and C. We would then have the following rules:
F'={
ABC -> DEFGH
D -> IJ
D -> CBE
}
Is this right? What about the other circular dependency, i.e. C -> D (first rule), D -> C (third rule), and C -> D (going back to first rule)? Do I simply not care about it?
If I don't care about it (and assuming the primary key is ABC), then it seems obvious that this table is not in 3NF since ABC determines D (which is a non prime attribute here), and D determines IJ, two non prime attributes. But it seems to be in 2NF because no non prime attribute (D, E, F, G, H, I, J) can be obtain using a subset of attributes of the candidate keys (ABC here).
Of course, I could consider the primary key to be A, C or D and split AB -> C and C -> AB in two separate relations, but I don't think joining those two tables will always respect the rules AB -> C and C -> AB. For example, if someone inserts a new row in one of the table, then the join could introduce an invalid row.
I am thinking too much? Am I going in the wrong direction?
Thanks for your help :)
AB -> C
A -> DE
C -> AB
B -> FGH
D -> IJ
D -> CBE
I will assume that the FDs in your relation are known to be exactly those in the the transitive closure of F. (What were you actually told about F vis a vis your relation?)
{} only determines trivially.
{A} determines DE, which determines IJCB, which determines FGH. CK.
{B} determines FGH. Not CK.
{C} determines AB. CK.
{D} determines IJCBE. CK.
Other singleton sets just determine trivially.
Proper supersets of A, C and D are not CKs.
Other proper supersets are of B,E,F,G,H,I,J, which cannot determine A, C or D. Not CKs.
That accounts for all subsets of attributes.
So the CKs are {A},{B} and {D}.
What bugs me is AB -> C and C -> AB, which is a circular dependency.
Why should this bug you? Just follow the rules you were given. Review the definition of CK and how to determine the CKs from FDs. Eschew non-technical terms.
the real primary key of this relation
"Primary key" is not a useful notion in normalization. (I can't make much sense of what follows.)
this table is not in 3NF since
I don't see any definition of 3NF being used in your reasoning. You seem to use a definition of BCNF, but not properly.
assuming the primary key is ABC
the candidate keys (ABC here)
Make up your mind. Is there one candidate key {A,B,C} or three candidate keys {A}, {B} and {C}? This is two different situations.
it seems to be in 2NF because no non prime attribute [...] can be obtain using a subset of attributes of the candidate keys
You mean no non-prime attribute is functionally dependent on a proper subset of attributes of any candidate key. You misquoted, then misused what you quoted as if it meant what you should have quoted.
Review the definitions of the normal forms and the definitions they depend on.
I have been trying to understand the process of decomposing a relation but with no succes. I have no idea how it works and I can't figure it out. I have an example here if someone could explain me step by step how it works.
Consider schema R(A;B;C;D;E) with FDs
F = {AB -> CDE; AC -> BDE; B -> C; C -> B; C -> D; B -> E}.
1. Find all keys of R.
F = {AB -> CDE; AC -> BDE; B -> C; C -> B; C -> D; B -> E}
A+ = A
B+ = BCED
- it is not possible to deduce A from the other attributes -> A belongs to key
AB+ = ABCDE - a candidate key
AC+ = ACBDE - a candidate key
AD+ = AD,
AE+ = AE
ADE+ = ADE
I also don't understand what A+ signifies
What you've posted isn't decomposing a relation. It's finding the candidate keys. The candidate keys here are {AB, AC}.
Finding the keys is the second step in decomposing a relation. The first step is identifying all the dependencies. You're given all the functional dependencies, so you don't have to do that part here.
A+ means "the closure of the set of attributes A with respect to the set of functional dependencies F"--the set of attributes of F that can be determined by A.
This statement
it is not possible to deduce A from the other attributes -> A belongs
to key
should be
it is not possible to deduce A from the other attributes -> A belongs
to every candidate key
I am trying to comprehend BCNF databasing and I can't quite wrap my head around it.
Consider the following relation:
R (A, B, C, D, E, F, G)
The following functional dependences hold:
A -> E, F
A -> G
A, B -> D
B -> C
E, F -> G
A -> D
How would I make it BCNF?
Speaking informally, in homework problems, you get to BCNF by
assuming you're in at least 1NF,
removing partial key dependencies to get to 2NF (at least),
removing transitive dependencies to get to 3NF (at least), and finally
removing remaining functional dependencies in which the left-hand side isn't a candidate key to get to BCNF (at least).
An example of a partial key dependency is the pair
AB->D
A->D
Since A alone determines D, the functional dependency AB->D has a partial key dependency.
An example of a transitive dependency is the pair
A->EF
EF->G
There's no guarantee that you can normalize a given relation to, say, BCNF and no higher. (This seems to cause a lot of confusion among university students on SO.) Removing partial-key dependencies to get to 2NF might leave all the relations in 5NF.
）We can use the Armstrong Axioms to get the F+
A -> D,E,F,G
B -> C (A,B -> D is ignored because A -> D)
E,F -> G
We can get the primary key(A,B).
According to the definition of BCNF, we have to separate A-> (E,F), B->C, A -> D and (E,F) -> G from the original schema.
(A,B) Primary key(A,B)
(B,C) Primary Key(B)
(A,D) Primary Key(A)
(A,E,F) Primary Key(A)
(E,F,G) Primary Key(E,F)
That's BCNF decomposition.
You can try this:
Table 1: A, B, D, E, F with composite primary keys (A, B) and foreign key( B) refer to table 2(B)
Table 2: B, C with B is primary key
Table 3: A, E, F, G with composite primary keys(A, E, F)
I am trying to decompose the following relationships in to 3NF:
A -> BCD
BC -> DE
C -> D
D -> A
So I eliminated the redundancy to get the canonical cover:
A -> BC
B -> E
C -> D
D -> A
And now I am trying to decompose this into 3NF.
Should I decompose into r1(A, B, C) r2(B, D), r3(C, D). Then what do I do with D -> A?
The fact that A -> B -> D -> A is throwing me off.
Given
A -> BCD
BC -> DE
C -> D
D -> A
to obtain a canonical cover we first remove D from BC->DE:
A -> BC
BC -> E
C -> D
D -> A
Next, we observe that C->D, D->A, A->BC and if we know B->E, then we also know C->E. Hence,
A -> BC
B -> E
C -> D
D -> A
3NF decomposition works as follows:
1) Create tables for each dependency in the canonical cover
R1(A,B,C) R2(B,E) R3(C,D) R4(A,D)
2) Determine candidate keys of R. If no candidate keys are contained in the tables of step 1, add a new table containing only attributes of a candidate key.
Here A is a candidate key and it is contained in R1 (and R4), so no new tables should be added.
3) If there is a table such that its attributes are a subset of attributes of another table, remove the "contained" table.
This is not applicable, so the 3NF decomposition remains unchanged.
As you see, circular dependencies are not problematic.