消除传递函数依赖条件
（粗体主键。）消除传递函数依赖条件
在我的一次演讲中，我们采取了以下模式
R（A，B，Ç，d，E）
甲 - >乙
ë - >乙
C，d - >一个
C，d - >乙
C，d - >电子
并把它带到2NF如下：
R1（Ç，d，A，E）
C，d - > a和e
R2（A，E ，b）（不在2NF）
甲 - >乙
ë - >乙
当然，如果我想利用我的模式，以3NF这会导致一个问题，因为b不能被部分遏制由a和e开采。我想要做的就是简单地创建单独的关系如下：
R3（ê，B）
é - >乙
和
R4（一个，B）
a - > b
在这种情况下，b完全依赖于主键，这使得我得到了2NF，对于关系3和4来说，转换的依赖关系被取消，whi ch在3NF。然而，我认为可以认为，这种解决方案并不令人满意，因为b的价值可能会因为每个关系而不同，并且当它不可避免地被用作外键时可能会出现异常。对此有何想法？
我们寻求分解“保留”FD和（通常没有明确说明）不引入其他约束。 FD在某个组件中存放时会被保留。我们的想法是，我们可以通过检查它在组件中的存在来检查FD是否存在重构，而不是必须加入然后检查。我们也更喜欢FD和它的属性只在一个组件中，或者我们需要添加一个约束，在行列式值同意相关值同意的地方。总是有一个3NF模式保留所有FD而不引入其他约束。当一个FD不能保存到BCNF时，就会引入一个“等式依赖”，因为两个组件必须在FD属性上具有相同的投影。
我们没有通过移动较低的NF来标准化给定的NF。这可能会导致更高的NF设计出现。我们对给定的NF使用一种算法。
当某些FD（功能依赖性）成立时，其他人根据阿姆斯特朗的公理来做。我们必须在之间查找所有 FD的NF违规者和FD以保存，而不仅仅是某些形成封面的给定者。算法也考虑到了这一点。
PS PK（主键）并不重要，CK（候选键）也可以。可以有多个，它们可以是复合的。 PK只是你决定叫PK的一些CK。所以突出PK的属性通常是不够的。只需列出CK。
PPS一个（更新）异常是一个特定的事情，这不是你使用“异常”的东西。
你是什么意思，“把它拿到2NF”？当我们将一个模式“分解”为一个NF时，我们正在滥用语言来表示“NF中的一堆其他模式”。原始模式已经消失。 （所以我编辑了“R（...）”到“R1（...）”）。但是由于你的第一个分解仍然有一个组件不在2NF中，所以你*没有“把它带到2NF”。你似乎认为R1仍然是R，而R1是在2NF，或者R1被命名为R，因为有理由认为“取R到2NF”，但这没有意义。 – philipxy