I'm trying to understand decomposition to BCNF. I have read many examples, yet I still do not understand few things. I followed this answer to try and solve following problem:
Attributes are customer name(A), address(B), phone(C), id(D) and accounts have a number(E), type(F) and balance(G).
What functional dependencies hold if customers have one and only one id, name, address and phone number and accounts have one number, type and balance and are owned by one and only one customer? Give a BCNF decomposition using these dependencies of R(ABCDEFG)
What I have come to so far:
To first obtain the FDs specified in the question:
D -> ABC // If we agree on same customer ID, then we agree on the name, address and phone #
E -> DFG // If we agree Account number, then we agree on customer ID, account balance and account type
The only candidate key we have is: {E} as all attributes can be obtained with this attribute.
Since there are no extraneous left-hand side attributes and no redundant FD, I have come to following relational tables:
R1={D, A, B, C}
R2={E, D, F, G}
Where the keys in these two relations are marked in bold
Now to check for BCNF we check if any of these relations (R1,R2) violate the conditions of BCNF (i.e. for every functional dependency X->Y the left hand side (X) has to be a superkey) .
Now we can see that E -> DFG has a left hand side that is a super key. However D -> ABC does not have a left hand side that is a super key. So that FD violates BCNF. But I don't know how to proceed into decomposing into BCNF.
When you check for satisfaction of the BNCF of the decomposed relations, you must check the functional dependencies separately for each relation.
So, in R1={D, A, B, C} the only (candidate) key is D (as you have noted), with all the non-trivial dependencies that have only D as left part; in R2={E, D, F, G} the only (candidate) key is E with all the non-trivial dependencies that have only E as left part. So in both relations there is no (non-trivial) dependency that violates the BCNF, and so the decomposition is correct and nothing else must be done.
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).
I have a relation R(a,b,c,d) where (a,b) is a primary key so I have the determinant a,b -> c,d.
In addition to that I have the following determinants: a,c -> b,d and a,d -> b.
Let's be ok that this relation is in 3NF.
I'm wondering if it's in BCNF or not. I was using a definition for the BCNF that recognize:
a relation is in BCNF if it's in 3NF and there's no determinant X -> Y such as X is non-key attributes and Y is a part (or the totality) of the key
which is not applicable in my case for the determinant a,d -> b for example. Another definition is that
A relation, R, is in BCNF iff for every nontrivial FD (X->A) satisfied
by R the following condition is true:
(a) X is a superkey for R
which left me undecided insofar as in a,d->b it's clear that (a,d) is not a superkey (nor a key), but we have (a,d) clearly a key to the relation R!
So, my question is:
Is the relation R in BCNF or not, and why?
And what's the right process to determine whether a relation is or isn't in BCNF?
About terminology
You say:
I have the determinant a,b -> c,d
This is wrong therminology. a,b -> c,d is a functional dependency (sometimes abbreviated with FD), which has a determinant a,b (sometimes called left hand side (LHS) of the FD) and a determinate c,d (sometimes called right hand side, RHS, of the FD). This terminology is used since the values of the attributes a,b uniquely determinate the values of the attributes c,d.
About the key
The information that:
(a,b) is a primary key
can be irrelevant when normalizing a relation when you have enough information about the functional dependencies. From those dependencies you can calcolate which are the candidate keys: set of attributes that uniquely determines all the attributes of the relation and such that you cannot remove any attribute from them maintaining this property (in other words, minimal sets of attributes that uniquely determines all the attributes of the relation). The information about the primary key can be relevant when you have only partial information about the functional dependencies that hold in a relation, but in your case the information about all the (candidate) keys can be derived from the functional dependencies.
In your example, for instance, there are three candidate keys:
1. a, b
2. a, c
3. a, d
You can verify this fact by computing the closure of the attributes of a candidate key to see if it contains all the attributes. For instance, let's try to calculate the closure of a,d (called a,d *):
1. a,d * = a,d
2. a,d * = a,d,b (since a, d -> b)
3. a,d * = a,d,b,c (since a, b -> c, d)
So a,d is a candidate key (which is also a superkey, i.e. a set of attributes that determines all the attributes of the relation).
About the BCNF
There are different definitions of BCNF. Using for instance the second one that you cited, all the three dependencies have a determinant which is a candidate key (and so a superkey), and so the relation is in BCNF.
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.
I am studying for my databases exam and I've realized my professor did not teach a section of the normalization lecture notes, but glossed over them so I've been self studying and there is this example without solutions in the notes and I was wondering if I have been doing it right:
Given Relation R = {A,B,C,D,E,F,G,H,I,J}
And functional dependencies:
A,B -> C
A -> D,E
B -> F
F -> G,H
D -> I,J
Determine the primary key
Decompose R so it is in 2NF then show it in 3NF.
So, I got the primary key to be (A, B, D, F)
And then I tried to convert it to 2NF and I got relations:
(ABC), (DIJ), (ADE), (BF), (FGH)
And I honestly have no idea if this is right or how to then put it in 3NF... or if I've just skipped 2NF and already put it in 3NF. Any help?
It appears to me that you have skipped the NF2 and normalised the relation straight into the 3NF :)
The primary key for the original relation should be (A,B) as by inference rules (transitivity, such as A->D,E and D->I,J therefore A->I,J) it determines all other attributes. From this point onwards we have that:
FD1: A,B -> C
FD2: A -> D,E (Partial)
FD3: B -> F (Partial)
FD4: F -> G,H
FD5: D -> I,J
2NF (No partial dependencies allowed)
Now we can decompose the relation in three relations moving partial FDs to separate relations but preserving other FDs which might depend on those partial FDs, such as FD2 and FD5. This would give us the following results:
R1(A,D,E,I,J) -- FD2, FD5 (transitive)
R2(B,F,G,H) -- FD3 FD4 (transitive)
R3(A,B,C) -- FD1
Next, to achieve 3NF, transitive dependencies would have to be removed into separate relations in the same manner as NF2. Which, in turn, would result in the set of relations which you have already derived.
Good luck with your exams!
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.