I am working on lossless-join decomposition on the relation R(A,B,C,D,E).
The relation has functional dependencies: {A->BC,B->D,CD->E,E->A}
(1) I think candidate keys are {A} and {E}
(2) And BCNF violations are {B->D} and {CD->E}, because {B} and {CD} are not candidate keys
(3) But I don't know how to decompose it and which dependencies are not preserved. I guess it would be like...
=> R1={A,B,C,E}, R2={B,D} and lose FDs: {CD->E}
But both {A} and {E} are candidate keys, so does it need to be separated like below?
=> R1{A,B,C}, R2{B,D}, R3{B,C,E} and lose FDs: {CD->E}
I want to ask which one is correct
(1) is wrong, since also BC and CD are candidate keys (for instance, since CD → E and E is a candidate key, it is easy to see that also CD must be a candidate key). Another way of checking this is computing CD+:
CD+ = CD
CD+ = CDE (by using CD -> E)
CD+ = CDEA (by using E -> A)
CD+ = CDEAB (by using A -> BC)
CD+ is equal to all the attributes of the relation and this means that it is a superkey. Moreover, since you cannot remove any attribute from with without losing the property of determining all the attributes of the relation, this means it is a candidate key.
So B → D is the only dependency that violates the BCNF, and for this reason you can decompose R in R1(BD) with candidate key B and R2(ABCE) with candidate keys A, BC, and E. Both relations are in BCNF, so no further decomposition is necessary.
Because of this decomposition, it is true that the dependency CD → E is lost.
Related
My doubt is for a given set of funtional dependencies F = { AE -> BCD, B -> E
}. Is this in BCNF or 3NF? It's a question from a test I have recently done and I would say that it is 3NF, but my teacher said it's neither 3NF nor BCNF. (I believe it is an error).
I have obtained as candidate keys AE and AB, and as in the first functional dependency the left side is a candidate key and in B -> E, E is contained in a candidate key, so it is in 3NF.
Is this in BCNF, 3NF or neither?
Assuming that all the attributes of the relations are A B C D and E, and that the only dependencies given are the two described (F), you are correct. Since the (only) candidate keys are correctly A E and A B, and since the functional dependency B → E has a determinant which is not a superkey, the relation is not in BCNF. Given one of the definitions of BNCF: “for all the non-trivial dependencies X → Y of F+, X is a superkey”, there is a theorem that shows that a necessary and sufficient condition for this is that the property of being a superkey holds for all the dependencies in F.
On the other hand, since E is a prime attribute, i.e. an attribute of a candidate key, the dependency B → E does not violate the 3NF, so that the relation is in 3NF. This, again, given one of the definitions of 3NF: “for all the non-trivial dependencies X → A in F+, then X is a superkey or A is a prime attribute”, is due to a theorem that says that this condition is equivalent to check, “for each functional dependency X → A1,...,An in F, and for each i in {1..n}, either Ai belongs to X, or X is a superkey or Ai is prime”. And this is satified by the two dependencies of F.
You need to use a definition of a NF when you claim/show that a relation is in it.
You don't actually say what all the attributes are. I'll assume the attributes are A through E. Otherwise, the CKs (candidate keys) are not what you say.
You are right in your argument against BCNF. You are using the definition that all determinants of FDs (functional dependencies) are out of superkeys. You found a counterexample FD B → E.
If it were an either-or question re BCNF vs 3NF you could stop there.
in the first functional dependency the left side is a candidate key and in B -> E, E is contained in a candidate key
You don't show that the table meets the conditions of either of the following definitions (from Wikipedia that happen to be correct) that a table is in 3NF if and only if:
both of the following conditions hold:
The relation is in 2NF
Every non-prime attribute is non-transitively dependent on every [candidate] key
for each of its functional dependencies X → A, at least one of the following conditions holds:
X contains A
X is a superkey
each attribute in A-X is prime
You seem to using definition 2 (but not saying so). You show bullet 2 holds for AE → BCD. Pointing out that E is prime in B → E seems to be part of showing that E-B is all prime. But you need to show every FD satisfies a bullet. Note that more FDs hold than the given ones. Armstrong's axioms tell you what all the FDs are.
In practice it can be easier to show a schema is in 3NF by applying a 3NF algorithm.
If we have functional dependencies ABC->DE and D->AB, one key is obviously ABC, but is CDE also a key?
If CDE is a key, then all 5 attributes are prime, and thus is the relation in 2NF and 3NF as well?
edit: there are only ABCDE in the relation
CDE is a superkey, a key is CD wich is enough to determine all the other elements:
CD+ = CD
= CDAB (since CD → AB)
= CDABE (since ABC → E)
So the prime attributes are ABCD, and the relation is in 3NF, since the dependency D → AB has only prime attributes on the right side, while it is not in BCNF (since D is not a (super)key).
Relation schema R (ABCD)
Functional Dependencies are :
AB -> D
CB -> D
A-> C
C -> A
Highest Normal Form ???
My understanding :
Candidate key = AB and BC
While creating table both AB and BC can not consider as Primary key. So let's take one by one.
For Key AB :
AB -> D ( Fully Functional Dependency , so no problem )
CB -> D ( ??? )
A -> C (partial Functional Dependency , as left side contains only part of key)
C -> A ( Functional Dependency , So no problem )
For Key BC
AB -> D ( ???? )
CB -> D ( Fully Functional Dependency , so no problem )
A -> C (Functional Dependency )
C -> A ( Partial Functional Dependency , as it's LHS is part of Key )
Now through both key's , relation contains Partial Functional Dependency.
Then it should not be in 2NF.
But answer is 3NF.
Please correct me.
While creating table both AB and BC can not consider as Primary key.
So let's take one by one.
No. You can take them one by one, but you have to consider every candidate key. The relational model offers no theoretical basis for labeling one candidate key "primary". There might be good practical reasons for that in a SQL database, but there's no theoretical justification for it solely within the relational model.
The notion of "partial functional dependency" applies to non-prime attributes. The only non-prime attribute is D. There's no partial dependency here.
When some FDs hold, others must hold, per Armstrong's axioms. But you are only looking at given FDs.
"Partial FD" is not defined in terms of CKs (candidate keys). 2NF is defined in terms of partial FDs and CKs. 2NF holds when there are no partial FDs of non-prime attributes on any CK. Not when there are no partial FDs.
PKs (primary keys) are irrelevant. A PK is just some CK you decided to call "the PK".
Y is partially functionally dependent on X when Y is functionally dependent on a smaller/proper subset S of X. But the partial dependency so identified is X -> Y, not S -> Y.
(See this answer.)
This is more of a concept check than anything, but suppose I have a relation R on attributes ABCD with the functional dependencies B -> ACD and C -> D. The solitary key for this relation is B, and a superkey for this relation is BC, correct?
The only candidate key in your example is indeed B. Any collection of attributes containing B will be a superkey, e.g., B itself, AB, BC or ABD.
candidate key is B.
As all the attributes can be derived from B, B becomes superkey..
I'm trying to produce a 3NF and BCNF decomposition of a schema. I have been looking at the algorithms but I am very confused at how to do this.
If I have my minimal cover say: F' = {A->F, A->G, CF->A, BG->C) and I have identified one candidate key for the relation, say it is A. Then what exactly do I do?
I have been looking at examples, one which has the following:
F = {A → AB,A → AC,A → B,A → C,B → BC}
Minimal cover: F′ = {A → B,B → C}
And the final result was: (AB,A → B), (BC,B → C). How did they get to this?
If I have my minimal cover say: F' = {A->F, A->G, CF->A, BG->C) and I
have identified one candidate key for the relation, say it is A. Then
what exactly do I do?
F' is not a minimal cover: you have to combine A->F and A->G to A->FG
Even worth A cannot be a candidate key given F' since B does not belong yo the closure of A. A possible candidate key would be AB.
For 3NF you start with creating tables for each one of the dependencies in F', i.e.,
R1(A,F,G) R2(A,C,F) R3(B,C,G)
Next you check whether one of the tables contains a candidate key. Since B appears only on the left side of the dependencies, B should always be a part of a candidate key. The only table with B is R3 and it does not contain candidate keys (check it!). Hence, we add a new table R4 with a candidate key as attributes
R4(A,B)
Finally, we check whether the set of attributes of one of the tables is contained in the set of attributes of another table. This is not the case for our running example.
Hence, our 3NF decomposition is
R1(A,F,G) R2(A,C,F) R3(B,C,G) R4(A,B)
For BCNF you start with R(A,B,C,F,G) and look for BCNF violations.
For instance A->FG is a violation of BCNF because this dependency is not trivial and A is not a superkey. Hence we split R into
R1(A,F,G) and R2(A,B,C)
None of the relations obtained contains BCNF violations, so the process stops here.