Question

我想知道BCNF中的关系表是否

学生（StudentNum，NRIC，DateOfBirth，BookTitle）

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

根据我的分析，关系是2NF。在更改为BCNF后，它看起来像这样

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

我的查询;

改变之前2NF
改变后BCNF

我是对的。

Answer 1

规范化背后的想法是通过为那些似乎在表上造成任何冗余的列创建额外的表来尽可能地消除行的冗余。

例如，如果我们从下表开始：学生（StudentNum，NRIC，DateOfBirth，BookTitle）在这种情况下，唯一列是StudentNum和NRIC，其他2个字段不是因为其他学生可能具有相同的日期出生和其他人可能借用了同一本书。从那里我们看到需要规范化，以便我们不会陷入数据冗余，例如，如果同一个学生借了100本不同的书？

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

我建议您查看5个普通表格http://www.bkent.net/Doc/simple5.htm

的指南

更新：

我认为开始关系更好地被认为是第一范式，因为一切都在一个表中。我猜你的结果是2NF，因为如果不同的学生借了同一本书怎么办？这可能会导致学生表中的重复。

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

Answer 2

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

你从

开始

Student(StudentNum, NRIC, DateOfBirth, BookTitle)

和这些依赖关系。

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

当且仅当

时，关系为2NF

它在1NF，
每个非素数属性都依赖于每个候选键的整个，而不仅仅是任何候选键的一部分。

所以你的第一份工作是确定学生关系的候选键。 Student关系只有一个候选键，那就是{StudentNum，BookTitle}。

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

由于NRIC依赖于StudentNum，而StudentNum不是候选键（它只是候选键的 part ），因此Student不在2NF中。通过更改

来解决此问题

Student(StudentNum, NRIC, DateOfBirth, BookTitle)

通过消除对StudentNum。¹

的部分密钥依赖性

学生（ StudentNum ，NRIC，DateOfBirth）
学生用书（ StudentNum，BookTitle ）

StudentBooks根本没有非素数属性;它现在在6NF。学生在2NF，但尚未在3NF或BCNF。你知道为什么吗？

看来你确实知道原因。确实存在传递依赖：StudentNum-＆gt; NRIC，和 NRIC-＆GT; DATEOFBIRTH。像这样修复传递依赖。

学生（ StudentNum ，身份证）
NRIC（ NRIC ，DateOfBirth）
学生用书（ StudentNum，BookTitle ）

所有这三个关系都在6NF。

这种分解可能看起来有点奇怪。这是因为教科书示例通常不会对关系或属性使用有意义的名称。关系通常命名为R {ABCD}，R ₁ {ABC}，R ₂ {AD}等。上述分解涉及
- 投射新关系{ StudentNum ，NRIC，DateOfBirth}以消除部分密钥依赖关系，
- 观察名称“学生”不再识别由{ StudentNum，BookTitle }，
- 将名称“Student”从原始关系移动到新的预计关系
- 为原始关系提出一个新名称StudentBooks。

关系表规范化

2 个答案: