关于第三范式的问题
下表：
EmpId State Zip
1 FL 342008
2 CA 342001
不符合第三范式，因为 状态取决于主要 key(EmpId) 传递。
所以，如果我像这样打破它： (EmpId,State) (State,PIN)
位于 3NF 中。
我也可以像这样打破它： （员工 ID、状态）（员工 ID、PIN） 它将再次出现在 3NF 中。
但在第二种情况下， 存在信息冗余，对于 例如，
1 FL
2 FL
1 342008
2 342008
第二次分解违反了哪个属性？
The following table :
EmpId State Zip
1 FL 342008
2 CA 342001
is not in 3rd normal form because
State is dependent on the primary
key(EmpId) transitively.
So, if I break it like this :
(EmpId,State) (State,PIN)
it's in 3NF.
I could also break it like :
(EmpId,State) (EmpId,PIN)
and it will again be in 3NF.
But in the second case,
there is redundancy of information, for
e.g.
1 FL
2 FL
1 342008
2 342008
Which property does the second decomposition violate?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
正如已经说过的，存在冗余，因为可以通过邮政编码推断出州，因此，您应该以这种方式设置表格：
始终考虑什么取决于什么。 当然，已经有一个基于集合论进行标准化的标准流程。 这也可以帮助您。
As already said, there is redundancy because the State can be inferred by the ZIP Code, hence, you should have your tables in this way:
Always think on what depends on what. Of course, there is already an standard process to normalize based on set theory. This could help you too.
这并没有直接解决您的问题，但是严格来说，州列是多余的，因为它可以从邮政编码派生（尽管您显示的是六位邮政编码，这在美国不是标准的）。 ）您可以按 EmpID 和 ZIP 分解该表，将 State 本身保留在查找表中。
This doesn't directly address your question, but, strictly speaking, the state column is redundant, because it can be derived from the ZIP code (although you're showing six-digit ZIP codes, which aren't standard in the USA.) You could break the table down by EmpID and ZIP, leaving State by itself in a lookup table.
为了直接解决所提出的问题，被侵犯的属性是 FFD（对密钥的完全功能依赖）。
To directly address the question asked, the violated property is FFD (full functional dependency on the key).