2NF和3NF标准化

Question

I seem to have a strange problem when doing normalization problems. When I'm giving relations with actual names I can figure these out easily but when I'm given letters it seems to be a lot harder.

For the following problem I don't know why it's not 3NF and why it is 2NF.

Given R (A, B, C, D, E, F)

FDs = {AB->C, DBE->A, BC->D, BE->F, F->D}

So for 2NF all the right hand side attributes must be fully functionally dependent on the left hand side attributes. For 3NF either all the left hand side attributes must be superkeys or the right hand attributes must be prime attributes.

I tried drawing this out, but I can't even find a candidate key. Can anyone help me determine why this is not 3NF? Also, what is the candidate key here? Since I don't see any attribute that has a closure equal to the original relation.

Answer 1

I seem to have a strange problem when doing normalization problems. When I'm giving relations with actual names I can figure these out easily but when I'm given letters it seems to be a lot harder.

Yes, its less intuitive with letters. I will tell you a neat method which you can follow to determine the candidate keys in such situations :

Make three columns left( L ), middle( M ) and right( R ) where left columns consists of all the attributes that appear only on the left side in all the given functional dependencies. In our case such attributes will be B and E since they are always on the left side of any FD given (or you can say they are never on the right side in any of the given FD.). Similarly middle column contains attribute that appear on both left and right side of the given FD's. So we have A , C , D and F in the middle column. The right column contains attributes which only occur on the right hand side of FD's (never on the LHS of any given FD's). So we have :

L  |   M   |R
B,E|A,C,D,F|-

Now that you have this table remember the following rules: ( these are very intuitive )

• Attributes in the left( L ) column are always part of the candidate keys
• Attributes in the right( R ) column are never part of the candidate keys
• Attributes in the middle( M ) column may or may not be a part of the candidate keys.

So in our case we start with checking if BE is a candidate key. We find BE-closure consists of all the attributes of the relation R so it is the candidate key. (Note: If BE would not have been the candidate key then we would have taken attributes from middle(M) column one-by-one and combine it with BE and check its closure eg. BEA , BEC , BED ...)

So now we have only 1 candidate key BE . So our prime attributes are {B,E} and non-prime attributes are {A,C,D,F} .

We know that 3NF is violated if RHS is a non-prime attribute and LHS is not a candidate key . Given FD's are:

1. AB->C
2. DBE->A
3. BC->D
4. BE->F
5. F->D

We note that in all these FD's RHS is a non-prime attribute. So in all of these LHS should be a key for it to be in 3NF. We see that (1),(3) and (5) violate this so it is not in 3NF . ( Note: In (2) we can see that D on the LHS is an extraneous attribute so its BE->A and hence (2) does not violate 3NF rule )