BCNF Decomposition - database

I am trying to figure out the correct steps in performing a BCNF decomposition. I found this example, but I do not understand how to perform the correct steps.
Schema = (A,B,C,D,E,F,G,H)
FD's + {A -> CGH, AD->C, DE->F, G->G}
Could someone show the correct steps?

Determine a minimal cover using your FD's:
{A -> C, A -> G, A -> H,
B -> nothing,
C -> nothing,
D -> nothing,
E -> nothing,
F -> nothing
G -> nothing
H -> nothing
DE -> F}
Note AD -> C drops out because A alone determines C which implies D is redundant in the FD (see Armstrong's Axioms - Augmentation).
3NF and BCNF definitions relate to dependencies about compund keys. The only compound key
you have here is DE. Neither D or E participate in any other non-null FD's
so eliminating transitive dependencies and ensuring that dependent attributes rely on the
'key, the whole key, and nothing but the key' is not an issue here.
Break into relations so that the FD left hand side is the key and the right hand sides
are the non-key dependent attributes of that key:
[Key(A), C, G, H]
[Key(D, E), F]
Now eliminate these attributes from the cover, whatever is left are standalone relations.
[Key(B)]
This should be in 3NF/BCNF

Related

Is this in BCNF, 3NF or neither?

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.

Candidate Keys on Functional Dependencies?

The relation R=(A,B,C,D,E) and functional dependencies F are given as follows:
F={A->BC, CD->E, B->D, E->A}
E, BC and CD can be a candidate keys, but B cannot.
Anyone could point me how this fact is calculated? I google it but couldn't understand more as what I known before.
You can find all the dependent attributes of a given set of attributes by computing the closure of its functional dependencies. Let me demonstrate:
A -> ABC -> ABCD -> ABCDE
A determines BC (given) as well as itself (trivially) therefore A -> ABC. Add the fact that B -> D to get ABC -> ABCD. Finally, add CD -> E to get ABCD -> ABCDE. We stop here because we've determined the whole relation, therefore A is a candidate key.
You should verify that, starting from E, BC and CD, you can indeed determine the whole relation.
Starting from B, we get:
B -> BD
and that's it. The rest of the relation can't be determined from BD, so it's not a candidate key.
A more visual way of doing it is to sketch the functional dependencies:
Starting from any set of attributes, try finding a path to every other attribute by following the arrows. You can only get to E if you start at E or visited both C and D.
From B, you can reach D, but without C, you're not allowed to go to E, which also excludes A. So B can't be a candidate key.

Understanding candidate key

Consider R(A,B,C,D,E)
F = {BC->AE, A->D, D->C, ABD->E}.
I need to find all candidate key of the schema.
I know that BA,BC,BD are the keys, but i want to know how do discover them.
I saw some answers in candidate keys from functional dependencies = but i didn't fully understand them.
form what they suggest, I got L={B}, M={A,C,D}, R={E}
Now i need to add from M one at a time to L.
I start with A, i get BA. So BA->A, BA->B (trivial) and because A->D so BA->D and because D->C we get BA->C.
But, how we get E?
adapting the answer from https://stackoverflow.com/a/14595217/3591273
Since we have the functional dependencies: BC->AE, A->D, D->C, ABD->E, we have the following superkeys:
ABCDE (All attributes is always a super key)
ABCD (We can get attribute E through ABD -> E)
ABC (Just add D through A -> D)
ABD (Just add C through D -> C)
AB (We can get D through A -> D, and then we can get C through D -> C)
BC (We can get E through BC -> E, and then we can get C through D -> C)
BD (We can get C through D -> C, and then we can get AE through BC -> AE)
(One trick here to realize, is that since B never appears on the right side of a functional dependency, every key must include B, ie key B is independent and cannot be derived from other keys)
Now that we have all our super keys, we can see that only the last
three are candidate keys. Since the first four can all be trimmed
down. But we cannot take any attributes away from the last three
superkeys and still have them remain a superkey.
so the minimal keys are AB, BC, BD
update
this was a reduction approach, i.e succesively reduce the trivial superkey by use of functional dependencies, but one can take the opposite road and use an augment approach, i.e start with single trivial keys and augment them with other keys wrt dependency relations untill keys become superflous

Finding the Primary Key and Normalising a Relation with Functional Dependencies

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!

Database candidate keys from functional dependencies - specific technicality

I am working with a relational database's set of attributes and set of functional dependencies and have a specific question about which keys would be considered candidate keys of this schema.
The set of attributes I am working with is:
R = (A, B, C, D, E, F, G, H)
And the set of functional dependencies are:
F = { AC -> B, AB -> C, AD -> E, C -> D, BC -> A, E -> G, ABE -> D, FG -> E}
So here's what I am trying to figure out: Would this set of attributes have any candidate keys since H is not determined/mentioned at all in the set of functional dependencies?
By definition, candidate keys determine everything else, correct? If H is not determined by anything but itself, would there still be any candidate keys in this set?
Any insight is appreciated. Thanks!
Recall (Wikipedia) that
In the relational model of databases, a candidate key of a relation is
a minimal superkey for that relation; that is, a set of attributes
such that the relation does not have two distinct tuples (i.e. rows or
records in common database language) with the same values for these
attributes (which means that the set of attributes is a superkey)
there is no proper subset of these attributes for which (1) holds
(which means that the set is minimal).
Hence,
So here's what I am trying to figure out: Would this set of attributes have any candidate keys since H is not determined/mentioned at all in the set of functional dependencies?
This simply means that H will be contained in every candidate key R might have. For instance, ACFH is a candidate key. You can infer B because of AC->B, D because of C->D, E because of AD->E, and G because of E->G. On the other hand, you cannot infer F from ACH, H from ACF, C from AFH and A from CFH.

Resources