Relational database 关系表规范化

我想知道BCNF中的关系表

学生（学生人数，NRIC，出生日期，书名）

•学生编号（StudentNum）唯一标识国家注册身份证（NRIC）和学生出生日期（出生日期）。 •NRIC确定学生的出生日期（出生日期）

根据我的分析，这种关系是2NF。换成BCNF后，看起来是这样的

Student(StudentNum, NRIC, BookTitle)
StudentDetails(NRIC, DateOfBirth)

我的疑问

变更前2NF

改变BCNF后

---

我说得对。

规范化背后的思想是通过为那些可能会对表造成任何冗余的列创建额外的表，尽可能消除行的冗余

例如，如果我们从下表开始：Student（StudentNum，NRIC，DateOfBirth，BookTitle）在这种情况下，唯一的列是StudentNum和NRIC，其他两个字段不是，因为其他学生可能有相同的出生日期，其他人可能借用了相同标题的书。从这里，我们看到了规范化的必要性，这样我们就不会陷入数据冗余的境地，例如，如果同一个学生借了100本不同的书怎么办

如果所有内容都在一个表中，我们可能会得到大量冗余（重复）数据

我建议你看看这本指南的5个正常形式

更新：

我认为最好将起始关系视为第一范式，因为所有内容都在一个表中。我猜你的结果关系是2NF，因为如果不同的学生借了同一本书呢？这可能会导致学生表中出现重复

---

我认为你必须提供更多关于构成你们关系的场景的信息，以便我们能够更好地分析这一点。这在很大程度上取决于商业规则。

不。学生在1NF，而不是2NF

你从

Student(StudentNum, NRIC, DateOfBirth, BookTitle)

以及这些依赖关系

StudentNum->NRIC
StudentNum->DateOfBirth
NRIC->DateOfBirth

一个关系在2NF中当且仅当

• 它在1NF，并且
• 每个非素数属性都依赖于每个候选密钥的整体，而不仅仅依赖于任何候选密钥的一部分

因此，您的第一项工作是确定学生关系的候选键。Student关系只有一个候选键，即{StudentNum，BookTitle}

您的教科书应该至少有一个算法来确定关系的所有候选键

由于NRIC依赖于StudentNum，并且StudentNum不是候选键（它只是候选键的一部分），因此关系Student不在2NF中。通过改变来解决这个问题

Student(StudentNum, NRIC, DateOfBirth, BookTitle)

为此，通过消除StudentNum.1上的部分键依赖关系

• 学生（StudentNum，NRIC，出生日期）
• 学生用书（StudentNum，书名）

学生用书根本没有非主要属性；现在是6NF。学生在2NF，但尚未在3NF或BCNF。你知道为什么吗

看来你知道为什么了。确实存在一个可传递的依赖项：StudentNum->NRIC，和 NRIC->出生日期。像这样修复可传递依赖项

• 学生（StudentNum，NRIC）
• NRIC（NRIC，出生日期）
• 学生用书（StudentNum，书名）

所有这三种关系都在6NF中

---

这种分解可能看起来有点奇怪。这是因为教科书上的示例通常不会对关系或属性使用有意义的名称。关系通常被命名为R{ABCD}、R1{ABC}、R2{AD}，等等。上面的分解涉及到

• 投影新关系{StudentNum，NRIC，DateOfBirth}以消除部分键依赖
• 注意到名称“Student”不再识别由{StudentNum、BookTitle}组成的关系
• 将名称“Student”从原始关系移动到新的投影关系，以及
• 为原来的关系起了一个新名字，StudentBooks

---

书名与所有这些有什么关系？你是否保存了一份学生拥有的书籍清单（例如）？@parker.sikand是的，这是正确的，除了两点我没有任何其他信息。使用此信息，我需要将关系更改为BCNF形式的关系/sb，但学生的主要关系具有传递依赖性。这意味着它在2NF中。仅当关系具有比1NF中的部分依赖关系时。我说的对吗？我认为英语不是你的第一语言，尽管你的英语很好。你基本上是对的，但我会换一种说法。“Student”有一个传递依赖项，所以它不在3NF中。（严格地说，它可以在1NF或2NF中）如果一个关系有部分键依赖，它就不在2NF中。（要么在1NF中，要么根本不是关系。“根本不是关系”实际上发生在现实世界中。）