0

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

学生（学生编号、身份证、出生日期、书名）

• 学生编号 (StudentNum) 唯一标识国民登记身份证 (NRIC) 和学生的出生日期 (DateOfBirth)。• NRIC 确定学生的出生日期 (DateOfBirth)。

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

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

我的查询；

  1. 变更前 2NF
  2. 更改后的 BCNF

我对么。

4

2 回答 2

0

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

你从

Student(StudentNum, NRIC, DateOfBirth, BookTitle)

以及这些依赖项。

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

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

  • 它在 1NF 中，并且
  • 每个非主属性都依赖于每个候选键的整体，而不仅仅是任何候选键的一部分。

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

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

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

Student(StudentNum, NRIC, DateOfBirth, BookTitle)

为此，通过消除对 StudentNum 的部分密钥依赖。1

  • 学生（StudentNum、NRIC、DateOfBirth）
  • StudentBooks ( StudentNum, BookTitle )

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

看来你确实知道为什么。确实存在传递依赖：StudentNum->NRIC 和 NRIC->DateOfBirth。像这样修复传递依赖。

  • 学生 ( StudentNum , NRIC)
  • 身份证（身份证，出生日期）
  • StudentBooks ( StudentNum, BookTitle )

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

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

    • 投影一个新的关系 { StudentNum , NRIC, DateOfBirth} 以消除部分键依赖，
    • 观察到名称“Student”不再标识由 { StudentNum, BookTitle } 组成的关系，
    • 将名称“学生”从原始关系移动到新的投影关系，以及
    • 为原始关系想出一个新名称 StudentBooks。
于 2012-11-24T12:18:39.070 回答
0

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

例如，如果我们从下表开始： Student(StudentNum, NRIC, DateOfBirth, BookTitle) 在这种情况下唯一的列是 StudentNum 和 NRIC，其他 2 个字段不是因为其他学生可能有相同的出生日期和其他可能是借了同名的书。从那里我们看到了标准化的必要性，这样我们就不会陷入数据冗余中，例如，如果同一个学生借了 100 本不同的书怎么办？

如果一切都在一个表中，我们最终可能会得到大量冗余（重复）数据。

我建议您查看 5 种范式http://www.bkent.net/Doc/simple5.htm的本指南

更新：

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

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

于 2012-11-24T08:22:55.657 回答