Statement - "If a table contains only one candidate key, the 3NF and the BCNF are equivalent."In the below image, relation is 3nf but not bcnf. But it has only one candidate key ie AB, so according to above statement it should be either both (3nf, bcnf) or nothing. Can somebody explain what i am missing here ?
"If a table contains only one candidate key, the 3NF and the BCNF are equivalent."
The second half, "the 3NF and the BCNF are equivalent", doesn't mean anything. What do you think it means? The normal forms are different things. BCNF requires a more restrictive condition than 3NF. So when a relation is in BCNF it has to also be in 3NF. So a relation can be in both normal forms at the same time.
Presumably the quote is trying to say that, "if a table contains only one candidate key", then if it is in 3NF then it is also in BCNF. And this is correct, because a table that is in 3NF but not in BCNF has to have overlapping CKs (candidate keys). Here the CKs, ie sets of attributes that determine all attrbutes that don't contain a smaller such set, are AB & AC. Which overlap. This table is in 3NF, but it's not in BCNF.
(Note that the FDs that hold are not just ones you are explicitly told hold but all the ones that must hold when they do per Armstrong's axioms.)
In,simple words the given words can be written as
AB->C
AB->D
C->B
In above relations,A,B,C are prime attributes and D is non-prime attributes
Here,AB and AC are minimal Super keys
Condition for 3NF and BCNF
X->Y
For BCNF,X should be Super key whether Y is prime or non-prime attribute
For 3NF,X should be Super key only when Y is non-prime,otherwise it is a optional one
BCNF and 3NF are equivalent when there are no **non-prime** attributes
Hope,it helps.
Related
What's the main point of Normalization?
I mean if a normal form is not in 2NF, it is because of partial dependency i.e. a non key attribute is dependent on a part of a candidate key.
So, let's say, for a relation R(A,B,C) with FDs:
AB->C, B->C
Clearly, AB is the candidate key and B->C is the partial dependency.
Solution: Decompose the relation such that (B,C) forms a new relation with B as the key.
Now, if a relation is not in 3NF, it is because a non key attribute is dependent on another non key attribute i.e. to say
if FDs for a relation R(A,B,C) are:
A->B,B->C
Clearly, A is the key and B->C shows transitive dependency, so not in 3NF.
Solution: Decompose the relation such that (B,C) forms a new relation with B as the key.
So, what's the exact difference?
I mean, why such a marked distinction? Essentially in both of the cases the action is same.
Decompose the relation using the dependency where the determinant (B here) is either PART of a key or not.
Why have separate terms like partial dependency or transitive dependency?
Why not just see, if there exists a dependency wherein a non prime attribute is determined by a something which is NOT a candidate key( no matter whether it is a partial key or another non prime attribute )
Why can't we implement a method like this:
1 NF -- having all elements in the atomic form
X NF -- if there's any
dependency of the form non_key -> non_prime_attribute(s) ,
decompose the relation with one of the new relation having this
particular "non_key" as the key with those non_prime_attributes.
BCNF
: Where for all the dependencies of the form X->Y, X is a superkey?
Can we have such NF condition format? Does it combine all the conditions?
So, what's the exact difference?
2NF is not 3NF & definitions of 2NF are not definitions of 3NF. There isn't any particular semantic or syntactic structural similarity that would leave some kind of "difference" other than that a 2NF relation can have the sort of problem FD (functional dependency) that violates 3NF that a 3NF relation doesn't have. You can find definitions all over the place. You almost give them correctly here yourself. But a NF (normal form) is a condition, not a process. What do you mean "actions are the same"? Being in 3NF implies being in 2NF, so naturally decomposing to 3NF also gives 2NF. But there are relations that are in 2NF but not in 3NF, and there may be decompositions for a relation to 2NF that don't get to 3NF. Those decompositions will involve in a removal of all problem partial FDs that does not result in the removal of all problem transitive FDs.
(Because 3NF is always achievable and there are no other disadvantages compared to 2NF, 2NF isn't even useful. It's just a condition that was discovered first that is not as strong as 3NF.)
(3NF is frequently defined in terms of 2NF plus no transitive dependencies of non-prime attributes on CKs, but actually no such FDs implies no partial FDs of non-prime attributes on CKs, hence 2NF, so the first condition is redundant.)
Why not just see, if there exists a dependency wherein a non prime attribute is determined by a something which is NOT a candidate key
Why should that condition be helpful? It is not a description of just getting rid of the problem FDs of 2NF & 3NF--that's what putting into 3NF does.
Getting rid of non-trivial FDs that are not determined by superkeys happens to give BCNF. It implies 2NF & 3NF. But it is different from both of them. A BCNF relation exhibits no FD-based update anomalies. It is always achievable. However 3NF is alway achievable while "preserving FDs", whereas BCNF is not. There are cases where in order for a FD that held in the original to be enforced in a view/query that gives it via constraints on its components we need an EQD (equality dependency) constraint. That says two column sets have the same set of subrow values, which is more expensive to enforce than a FD. Either you have BCNF & an EQD & fewer update anomalies or you have 3NF/EKNF & a FD & certain update anomalies.
The NF that really matters is 5NF, which implies BCNF, with no update anomalies & with other benefits. (We might then decide to denormalize for performance reasons.)
PS Normalization to a given NF does not necessarily involve normalization to lower NFs.
It almost sounds as though you want to know why they called these two normal forms by different names instead of inventing just one form that covers both cases. If that's not the case, please ignore this answer.
Part of the answer is that the forms weren't discovered at the same time. And part of the answer is that the problem with 1NF that gave rise to 2NF is not the same as the problem with 2NF that gave rise to 3NF, even though they both exhibit harmful redundancy.
What might satisfy you a little more is BCNF. BCNF was actually discovered later than 4NF, so that name was already in use. But BCNF has to be placed between 3NF and 4NF, because it is more restrictive than 3NF but less restrictive than 4NF. So it was discovered "out of sequence", so to speak.
In BCNF, every (non trivial) determinant is a candidate key. That seems to be what you are looking for. I conjecture that any relation that is in 1NF and where every determinant is a candidate key, could be shown to be in 2NF and 3NF. But the proof is beyond me.
2NF and 3NF are essentially historical concepts and your question is a reasonable one. There is no real reason to apply them in practical database design because better tools exist today.
When it comes to teaching there is possibly some justification for mentioning 2NF and 3NF. Doing so allows students to explore the concepts involved (as you have done) while also teaching them a bit about the origins and rationale of design theory. In school maths lessons I was taught long division and differentiation from first principles. No one uses those techniques in practice, they are just teaching aids.
Before checking for 2NF the relation should be in 1NF. In simple words 2NF have only full dependencies only, no partial dependencies in relation. Full dependency means if x gives y, then by removal of any element in x, then y is not having any relation. If by removal of x, you are having relation with y then it is partial dependency. For 3NF we have to check for the 2NF, in 3NF we should not have any transitive relations like if x gives z, then there is no relation like x gives y and y gives z.
Solution for 2NF create a table for the partial dependcies and add foreign key in new relation which is primary key on the previous relation.
Solution for 3NF create a relation for both x gives y and y gives z. Add keys to relations.
R1(A, B, C, D) is a relation. It is specified that every attribute has only atomic values, and there is a set of dependencies (BD->C, C->A). It's clear to me that the relation is in the 1NF, but is it in the 2NF? I mean, BD is obviously a primary key, and we can conclude that BD->A, so all the attributes depend on the key. It isn't in the 3NF, for sure, because the 3NF doesn't accept transitive dependencies, but this shouldn't be a problem for the 2NF. I'm having doubts because some people told me that this couldn't be in 2NF. Is my reasoning correct? Is it in 2NF or not?
A relation schema is in 2NF if any non-prime (i.e. not belonging to a candidate key) attribute is fully functionally dependent on a candidate key.
This definition implies that, if a dependency X → A can be derived in which A is not a prime attribute and X is a proper subset of a candidate key, then such dependency violates the 2NF.
Since the (only) candidate key of this relation is BD, the attributes A and C are non-primes.
Since BD → C, is given, and BD → A can be derived, while neither B → A or D → A can be derived, then the relation is in 2NF.
Note that the 2NF has only historical interest, and the normalization process is discussed in many books (and formal algorithms are presented) only for BCNF, 3NF and higher normal forms.
A movie has one and only one genre.
A genre can be assigned to many movies.
Movies(MovieName, Genre)
MovieName is the only key
MovieName->Genre is the only determinant
If MovieName is the key, and the only dependence (not the only determinant!) is:
MovieName → Genre
then the relation is in First, Second, and Third Normal Form, as well as in Boyce-Codd Normal Form, and also in higher level forms (for instance Fourth Normal Form).
This is because in the (unique) dependency the determinant (MovieName) is the key, so all the definition of normal forms are respected.
You don't really mean "What level of normalization is this relation [in]". A relation variable or value can be in lots of normal forms at once. When it's in one, it's in all the lower ones, and it could be in higher ones. So presumably what you mean is "What is the highest level of normalization this relation must be in".
MovieName->Genre is not a determinant. It is a FD (functional dependency). Its determinant is {MovieName}. That is the only determinant of a CK (candidate key). The non-trivial FDs are
{MovieName}->{Genre}
{MovieName}->{MovieName,Genre}
Since every determinant of a non-trivial FD is a superkey, this is in BCNF. Since it's in BCNF, it's in every lower normal form.
There are two theorems by Date & Fagin relevant here:
if a relation is in 3NF (or BCNF) and every CK is simple, then it is in 5NF
if a relation is in BCNF and some CK is simple, then it is in 4NF
Since your relation is in BCNF it is 3NF and since every CK is simple it is in 5NF.
PS What if we didn't know these theorems?
If the only constraints on this value/variable were the ones implied by what you gave then it is in 5NF. Because by definition it's in 5NF when it doesn't satisfy any JDs (join dependencies) other than those that are implied by its having that set of candidate keys.
But if all we knew about the value/variable is what you gave then how could we show that it still must be in 5NF?
If the JD *{{MovieName},{Genre}} also held then it wouldn't be in 4NF (or higher). Ie if it were also equal to the join of its projections on {MovieName} & {Genre}. In the join/original every input MovieName value would be in a tuple with every Genre value. The CK says there is only one such pair per MovieName. So there would only be one Genre value in the input. Then FK {} -> {Genre} would hold. BCNF implies 2NF, which says there are no partial dependencies on CKs, so FK {} -> {Genre} doesn't hold. So we have a contradiction re it holding. So the JD doesn't hold. So the relation is in 4NF because there are no other non-trivial binary JDs that could hold to violate 4NF. It is also in 5NF because there are no JDs with more than two elements that could hold.
Accoring to Boyce-Codd Normal Form Definition,
Reln R with FDs F is in BCNF if, for all X -> A in F+
-A is subset of X (called a trivial FD), or
-X is a superkey for R.
“R is in BCNF if the only non-trivial FDs over R are key constraints.”
If R in BCNF, then every field of every tuple records information that
cannot be inferred using FDs alone.
What I dont understand is the above two statements about normal form,
Can someone give me an example?
Thanks!
Some Pre-requisite terms before I try to Explain:
• Non-key attribute: An attribute that is not part of any candidate key is known as non-key /non-prime attribute.
• Superkey: A set of attributes within a table whose values can be used to uniquely identify a tuple. A candidate key is a minimal set of attributes necessary to identify a tuple; this is also called a minimal superkey.
Now, BCNF is the advance version of 3NF, stricter than 3NF.
A table is in BCNF if every functional dependency X → Y, X is the super key of the table.
Consider a relation : R(A,B,C,D)
The dependencies are:
A->BCD
BC->AD
D->B
So, Candidate keys(or minimal super keys) are A and BC.
But in dependency: D->B, D is not a superkey.
Hence it violates BCNF form.
We can break this relation into R1 and R2 as:
R1(A,D,C) and R2(D,B) to get BCNF.
Is the relation R(ABCDE) with set of FD's {AB->CD, AC->BED, D->A} in 3NF? I doubt it but the notes i am reading say so. Could someone please explain how is this correct? My understanding is that assuming we take AB as key then the attributes B,E & D are dependent on only a part of the key (i.e. A) thereby violating 2NF property.
Yes, This Relation is in 3NF
Because,
For the given FD set there are total 4 candidate keys which are AB,AC,DB,DC.
And let us suppose we have key AB, then for the given relation, there is no Partial FD and Transitive FD. So the given relation is in 3NF but is is not in BCNF because of D-->A violates the BCNF rule.