Hey there! Let's break down this confusion step by step—this is a super common pitfall when learning normal forms, so you're not alone here.

Core Issue: Identifying Candidate Keys is Critical #

First, we need to correctly pin down the candidate keys of R(A,B,C,D,E) because every normal form rule hinges on this. Using your function dependency set {A → B, B → A, B → E, AC → D}, let's calculate attribute closures:

• For AC: A determines B, B determines E, and AC directly determines D. This means (AC)+ = {A,B,C,D,E}—so AC is a valid candidate key.
• For BC: B determines A, BC can derive AC (thanks to B→A), which then determines D, plus B determines E. So (BC)+ = {A,B,C,D,E}—making BC another candidate key.

Why It Fails 2NF (and Only Qualifies for 1NF) #

Recall the definition of 2NF: A relation is in 2NF if it’s in 1NF, and no non-prime attribute has a partial functional dependency on any candidate key.

Let’s clarify key terms first:

• Prime attributes: Attributes that are part of any candidate key. Here, that’s A, B, C.
• Non-prime attributes: Attributes not included in any candidate key. Here, that’s D, E.

Now look at the dependency B → E:

• E is a non-prime attribute.
• B is a proper subset of the candidate key BC (since BC includes both B and C, but B alone is a smaller subset).
• This means E is partially dependent on the candidate key BC—it doesn’t require the full BC key to be determined, just B.

Since 2NF mandates eliminating all such partial dependencies, this relation fails to meet 2NF requirements. And if it doesn’t satisfy 2NF, it can’t possibly be in 3NF either.

Where You Might Have Missed the Mark #

I’m guessing you might have only considered AC as the candidate key and overlooked BC. If you only analyze against AC, B isn’t part of that key, so B→E wouldn’t look like a partial dependency. But normal form rules require checking against all candidate keys—once you account for BC, the partial dependency becomes clear.

内容的提问来源于stack exchange，提问作者Api