举例说明 2NF 与 3NF

Question

我有第二范式 (2NF) 的问题，我无法使用 Google 解决它。这让我发疯，因为我是一名老师，我不想教我的学生错误的东西。

让我们有一个包含 5 个字段的表。

评分 = {学生姓名、学科代码、学科名称、#考试、成绩}

依赖是这样的：

学生姓名、学科代码、#考试 -> 成绩

主题代码 -> 主题名称

主题名称 -> 主题代码

因此，候选键 1 是{StudentName, SubjectCode, #Exam}，候选键 2 是{StudentName, SubjectName, #Exam}。

主要属性是{StudentName, SubjectCode, SubjectName, #Exam}，非主要属性是Grade

根据第二范式的定义，非主属性不能依赖于候选键的一部分。唯一的非主要属性 (Grade) 不依赖于候选键的一部分，因此该表似乎在 2NF 中。

问题是我认为有些不对劲（我可能是错的）。我认为科目应该有自己的桌子。

评分 = {学生姓名，学科代码，#考试，成绩}

主题 = {主题代码，主题名称}

但是 2NF 不会产生这个。3NF 是关于非主要属性之间的依赖关系，因此它也不会产生这种依赖关系。但在我看来，这是正确的结果，因为它没有冗余。

我猜如果非主要属性被定义为“不是候选键的属性”，2NF 会产生想要的结果。但是我一次又一次地检查了这一点，非主要属性被定义为“不属于候选键的属性”。

我究竟做错了什么？

Answer 1

您的关系是 3NF，（不仅是 2NF），因为正如您所说，唯一的非主要属性是Grade，它仅出现在您的 FD 的右侧。

该关系不在 BCNF 中，因为两个小 FD 的左侧不是超级键。

但是，您可以无损地分解与 ( SubjectCode , SubjectName ) 和 ( StudentName, SubjectCode, #Exam, Grade ) 或 ( StudentName, SubjectName, #Exam, Grade ) 的关系

这种分解为您提供了两个 BCNF 关系并保留了所有函数依赖关系。这并不总是可能的（您总是可以将关系分解为 3NF，但不一定与 BCNF）。

2NF

如果你想要一个 2NF（而不是 3NF）的例子，你的关系需要包含传递依赖。

例如，假设您有一个 Score 列。直觉上 Score->Grade 因为所有分数相同的考试都应该得到相同的成绩（否则会很不公平），但请注意我们不能说 Grade->Score 因为几个分数可以有相同的成绩（11% 和 12%例如，可能是“失败”）。

现在你的关系是：

评分（学生姓名、学科代码、学科名称、#考试、分数、成绩）

并且您有一种新形式的冗余，因为每次您输入与另一个评分记录相同分数的结果时，您还必须重复相应的评分。为了达到 3NF，你可以分解为

ScoreGrades( Score,Grade )

以Score为关键，以及

分数（学生姓名，学科代码，学科名称，#考试，分数）

Answer 2

你是对的，科目需要自己的表格。如果您选择一个候选键，则subject_code或subject_name成为非主候选键。然后，您从评分表中删除非主要科目字段。

您对具有两个唯一标识符的主题具有功能依赖性。subject_code和之间的传递依赖证明了这一点subject_name。这表明需要创建一个包含这两个字段的表，并从所有其他表中删除其中一个字段。该表很可能有其他依赖列，尽管我在本例中没有看到任何依赖列。在您选择的第三范式中。

成绩取决于新评分表中的其他三个字段（候选键）。如上所述，您需要为主题表选择候选字段之一。通常，如果可用的话，这将是一个代码值，因为它们往往更稳定。生成的模型采用 3nf 格式，因为所有非键字段完全依赖于主键中的字段。

对问题（要求）的进一步分析可能会产生一个应用标记的会话表。当前的模式不太可能涵盖学生重修课程。这将在后面的课程中介绍。

学生也可能成为一个单独的表，因为可能有多个学生同名。这可能可以通过添加合成主键（学号？）来解决。

subjects --->  sessions ---+--> grades
students  -----------------+