不,学生在 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 中。
这种分解可能看起来有点奇怪。这是因为教科书示例通常不会为关系或属性使用有意义的名称。关系通常命名为R{ABCD}、R 1 {ABC}、R 2 {AD}等。上面涉及到的分解
- 投影一个新的关系 { StudentNum , NRIC, DateOfBirth} 以消除部分键依赖,
- 观察到名称“Student”不再标识由 { StudentNum, BookTitle } 组成的关系,
- 将名称“学生”从原始关系移动到新的投影关系,以及
- 为原始关系想出一个新名称 StudentBooks。