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..
Related
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.
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.
This is a pretty basic question from early on in the semester, which I got wrong. I am asking this for a better and more accurate answer from others in preparation for the final exam.
Normalizing a table with 5 attributes A, B, C, D, and E. Where A and B is a composite key. With no other prime attributes.
a. If you have a partial dependency B to C, what would you do to normalize the relation?
b. If you have a dependency D to E, what would you do to normalize the relation?
Normalization is something that can be done only trough Functional Dependencies. So let's reformulate you question using them.
Normalizing a table with 5 attributes A, B, C, D, and E. Where A and B is a composite key. With no other prime attributes.
This means that we have a relation schema
R(A, B, C, D, E)
with the only non-trivial functional dependency:
A B → C D E
This relation is in Boyce-Codd Normal Form (BCNF) as well as in Third Normal Form (3NF).
If you have a partial dependency B to C, what would you do to normalize the relation?
Now we add the dependency B → C, which violates both the BCNF (that require that each determinant be a superkey) and the 3NF (that tolerates non-superkyes determinant if the determinate is a prime attribute, that is an attribute which belongs to any key, and C is not a prime attribute since the only key is A B).
In this case the normalization is simple, we decompose the original relation R in two relations, the first, R1(B, C), that represent the information that ties B and C, so that we can know for each value of B which is the only corresponding value of C, the second R2(A, B, D, E) that represents the fact the the values of D and E are uniquely determined by a couple of values A and B. The two relations R1 and R2 are both in BCNF and in 3NF, since the key of R1 is B, while the key or R2 is A B.
It is worth mentioning the fact that this decomposition is loss-less and dependency preserving.
If you have a dependency D to E, what would you do to normalize the relation?
Also in this case the strategy is to decompose R in two relations, this time in R1(A, B, C, D) and R2(D, E). Again, we can note that both relations are in BCNF and in 3NF, and that data and dependencies are preserved.
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.