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).
Related
I have the following relation and I need to normalize it to 4NF.
Relation
First I've tried to find all the FD's and MVD's that hold.
AB ->> C (MVD)
C -> D (FD)
D -> E (FD)
ABC -> F (FD)
Next, using these dependencies I've managed to find the candidate key: ABC.
Let me know if what I've done so far is right. Also, is it ok to have a multivalued dependency in 4NF? Like AB ->> C and ABC -> F?
Thanks.
In general dependencies describe important constraints on the data, for instance a functional dependency X → A means that a certain value of X determines uniquely a certain value of A (that is, each time we find in a tuple a certain value of X, we always find the same value of A). Such kinds of constraints cannot be inferred by (few) rows of a table, in which is unknown the meaning of the data.
At the best, we can infer a set of possible functional dependencies holding in that particular instance of the table, hoping (but without any particular reason) that those functional dependencies will hold on every instance of the table, which is the only condition for which we can “normalize” the relation (and not simply find a non-redundant way of storing a particular instance of that table).
In your case, for instance, since the table has very few rows, many functional dependencies could be seen as holding in it, for instance at least the following:
F → AB
E → AD
D → AE
C → ADE
B → A
EF → ABCD
DF → ABCE
CF → ABDE
CB → ADEF
(while ABC → F can be derived from CB → ADEF, and AB →→ C does not hold).
And if we should apply a normalization algorithm to that instance (for instance the synthesis algorithm for 3NF), we will decompose the relation in an exaggerate number of subschemas:
R1(AB), R2(BCF), R3(CD), R4(ADE), R5(CEF),
five relations for a table with six attributes!
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 was doing some textbook questions which contain this following one.
Which of the following relations is in Third normal form (3NF)?
a) R(ABCD) FD's: ABD → C ; CD → A ; AC → B ; AC → D
b) R(ABCD) FD's: ABD → C ; A → B ; AB → C ; B → A
c) R(ABCD) FD's: AB → C ; ABD → C ; ABC → D ; AC → D
d) R(ABCD) FD's: AD → C ; D → A ; A → C ; ABC → D
I feel that all four choices are wrong but I do not have the answer to it. Could anybody help me with it? R represents relationship, FD is short term for functional dependency.
(Disclaimer: this is not from test/homework which gives any credit, I just want to make sure that I understand the concept correctly)
The way to prove something is in a certain NF form is by trying to break it. It is hard to describe why something is rather than is not in 3NF. That being said, could you tell me why you think each one does not satisfy 3NF so we can work from there?
This is what I've figured out:
b) Breaks 2NF since candidate key ABD can be broken down into AB which determines non-prime C.
c) Only candidate key is AB. AB -> C. D is determined through a transitive relationship ABC -> D. Breaks 3NF.
d) Candidate key BA determines C. But A -> C, therefore this breaks 2NF.
I could not find anything wrong with a, so that would be my guess to the right answer.
Let me explain it in simple words:
Condition for 3NF:
The non-prime attributes should be dependent only on super key
For option A,
By closure property,
AC+=ABCD
Thus A,C are prime attributes and B,D are non-prime attributes
Since all non-prime attributes are dependent on super key AC
The option A is in 3NF
For option B,
By closure property,
ABD+=ABCD
Thus,A,B,D are prime attributes and C is non-prime attributes
Since C, a non-prime attribute depends on AC which is not a super key,
option B is not in 3NF
For option C,
By closure property,
AB+=ABCD
Thus,A,B are prime attributes and C,D are non-prime attributes
Since D a non-prime attribute depends on AC which is not a super key
option C is not in 3NF
For option D,
By closure property,
AB+=ABCD
Thus,A,B are prime attributes and C,D are non-prime attribute
Since C, a non-prime attribute depends on AD which is not a super key,
option D is not in 3NF
Hope,it helps!!
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..