（主键以粗体显示。）
在我的一个讲座中，我们采用了以下架构
R（a，b， c ， d ，e）
a - ＆gt; b
e - ＆gt; b
c，d - ＆gt;一个
c，d - ＆gt; b
c，d - ＆gt; e
并按如下方式将其带到2NF：
R1（ c ， d ，a，e）
c，d - ＆gt; a和e
R2（ a，e ，b）（不在2NF中）
a - ＆gt; b
e - ＆gt; b
当然，如果我想将我的模式带到3NF，这会导致问题，因为b不能由a和e部分决定。我想要做的只是创建如下的单独关系：
R3（ e ，b）
e - ＆gt; b
和
R4（ a ，b）
a - ＆gt; b
在这种情况下，b在功能上完全依赖于主键，这使我达到2NF，并且对于3NF中的关系3和4，转换了依赖性。但是我认为可以认为这个解决方案并不令人满意，因为b的值可能对每个关系都有所不同，并且当它不可避免地被用作一个外键时可能会出现异常。有什么想法吗？
答案 0 :(得分：1)
我们寻求分解“保留”FD并且（通常没有明确说明）不引入其他约束。 FD保存在某个组件中时会被保留。我们的想法是，我们可以通过检查它在组件中保存而不是必须加入然后检查来检查FD在重构中是否成立。我们也更喜欢FD及其属性只在一个组件中，或者我们需要添加一个约束，即在行列式值与从属值一致的情况下一致。总是有一个3NF模式保留所有FD而不引入其他约束。当无法保留FD以进入BCNF时，引入了“相等依赖性”，即两个组件必须在FD属性上具有相同的投影。
我们不会通过降低NF来规范化给定的NF。这可能会妨碍出现更高的NF设计。我们对给定的NF使用算法。
根据阿姆斯特朗的公理，当一些FD（功能依赖）持有时，其他人就会这样做。我们必须在所有 FD中寻找NF违规者和FD来保存，而不仅仅是一些给定的覆盖范围。算法也考虑到了这一点。
PS PKs（主键）没关系，CK（候选键）可以。可以有多个，它们可以是复合的。 PK只是你决定叫PK的CK。因此，突出PK的属性通常是不充分的。只需列出CK。PPS（更新）异常是某种事情，而不是你正在使用的“异常”。