是否所有具有部分依赖关系的关系模式都不在3NF中？

Question

来自数据库管理系统，由Raghu Ramakrishnan，Johannes Gehrk撰写

让R成为一个关系模式，F是用于保持R的函数依赖（FD）的集合，X是R的属性的子集，而A是R的属性。如果对于R中的每个FD X -> A，F处于第三范式，则以下陈述之一为真：

• A \in X;也就是说，它是一个微不足道的FD，或者
• X是一个超级钥匙，或
• A是R的一些关键的一部分。

假设依赖性X -> A导致违反3NF。有两种情况：

• X是一些关键的K的适当子集。这种依赖性称为部分依赖性。
• X不是任何密钥的适当子集。这种依赖性称为传递依赖，因为它意味着我们有一系列依赖关系K->X-> A。

1. 我是否正确“图19.7案例1”和“图19.8案例1”不是3NF，而“图19.8案例2”是3NF？
2. 为什么没有“图19.7案例2：A在KEY中”或“图19.7案例2：在KEY1中的A”，其中“KEY1”与“KEY”不同？那种情况存在吗？ 我纠正了吗 如果那种情况可以存在，那将是3NF。 如果不存在这种情况，那么所有具有部分依赖关系的关系模式都不在3NF中？

谢谢。

Answer 1

在回答任何问题之前，我先写下必要的定义：

Third Normal Form：如果满足以下条件，则关系R处于第三范式：

1.关系R是第二范式。

2.R的每个非素数属性都是非传递性地依赖于R的每个键。

Second Normal Form：如果以下条件成立，则关系R处于第二范式：

1.关系R是第一范式。

2.No-prime属性不依赖于任何候选键的适当子集。

现在，回答你的问题：

我是否正确“图19.7案例1”和“图19.8案例1”不是3NF，而“图19.8案例2”是3NF？

是的，你是正确的：“图19.7案例1”违反了3NF定义的条件1，“图19.8案例1”违反了3NF定义的条件2，“图19.8案例2”没有违反。

为什么“KEY1”与“KEY”不同，“KEY 2：A in KEY”或“Case 2：A in KEY1”中没有？如果那种情况可以存在，是否会是3NF？

好吧，如果你想知道为什么“图19.7”没有“案例2”，那是因为它不会违反3NF定义的任何条件。并且作者不打算使用不同的密钥KEY1，因为条件必须适用于所有密钥，并且如果任何密钥发生违规，则该关系不能在3NF中。

是否所有具有部分依赖关系的关系模式都不在3NF中？

是的，你是对的。他们不会因为违反3NF定义的第一个条件而不在3NF的原因。