Database 部分功能依赖，仍在3NF中？

关系模式R（ABCD）
功能依赖项为：
AB->D
CB->D
A->C
C->A
最高范式

我的理解是：

候选键=AB和BC

AB -> D ( ???? )  
CB -> D ( Fully Functional Dependency , so no problem )  
A  -> C  (Functional Dependency )  
C  -> A  ( Partial Functional Dependency , as it's LHS is part of Key )   

创建表时，AB和BC都不能考虑主键。让我们一个接一个地看

对于AB键：

AB->D（完全功能依赖，所以没有问题）

CB->D（？）

A->C（部分功能依赖项，因为左侧仅包含部分键）

C->A（函数依赖，所以没问题）

用于关键BC

AB -> D ( ???? )  
CB -> D ( Fully Functional Dependency , so no problem )  
A  -> C  (Functional Dependency )  
C  -> A  ( Partial Functional Dependency , as it's LHS is part of Key )   

现在，通过这两个键，关系包含部分函数依赖项。
那么它不应该在2NF中。
但答案是3NF。
请纠正我

创建表时，AB和BC都不能考虑主键。 让我们一个接一个地看

不，你可以一个接一个，但你必须考虑每个候选人的关键。关系模型没有提供将一个候选键标记为“主”的理论基础。在SQL数据库中这样做可能有很好的实际原因，但仅仅在关系模型中没有理论依据

“部分函数依赖”的概念适用于非素数属性。唯一的非素数属性是D。这里没有部分依赖关系

根据阿姆斯特朗的公理，当一些FD成立时，其他FD必须成立。但是，您只查看给定的FD

“部分FD”未根据CKs（候选密钥）定义。2NF是根据部分FD和CKs定义的。当任何CK上没有非素数属性的部分FD时，2NF保持不变。当没有部分FD时，则不会

PK（主键）是不相关的。PK就是你决定称之为“PK”的某个CK

当Y在功能上依赖于X的较小/适当子集S时，Y在功能上部分依赖于X。但是这样确定的部分依赖是X->Y，而不是S->Y

---

（请参阅。）

“关系包含部分函数依赖项”不足以违反2NF。查找、引用和使用部分FD和CK的定义。当删除一个确定属性时，保持的FD是部分FD，则给出另一个保持的FD。这不涉及CKs或基本属性。每一个以CK的适当超集作为行列式的FD都是局部的；所以这里有部分FD，例如ABC->D。对2NF重要的部分FD是CKs确定非素数属性的FD。