数据库表3NF规范化咨询：两种拆分方案的正确性辨析

原始表结构与字段含义 #

原始数据库表结构：

| MatrikelNr [PK] | Stud.-Name | Klausur | Raum |

字段说明：

• Matrikelnr：学号
• Stud.-Name：学生姓名
• Klausur：考试名称
• Raum：考场

我们的目标是将该表转化为符合**第三范式（3NF）**的结构，要求以带下划线标注主键的关系形式呈现。

两种拆分方案 #

方案1 #

Student (_Matrikelnr_, Stud.-Name)
Klausur (_Matrikelnr_, Klausur, Raum)

方案2 #

Student (_Matrikelnr_, Stud.-Name, Klausur)
Klausur (_Klausur_, Raum)

方案辨析 #

判断是否符合3NF，核心要满足两个要求：首先满足第二范式（2NF，非主属性完全依赖主键），其次非主属性不存在对主键的传递依赖——也就是所有非主属性都直接依赖于主键，不能通过其他非主属性间接依赖。

先看原始表的问题：主键是MatrikelNr，但Raum（考场）并不依赖学号，而是依赖Klausur（考试名称），存在传递依赖链：MatrikelNr → Klausur → Raum，这明显违反3NF。

• 方案1的问题：
  Klausur表的主键是Matrikelnr，但Raum依赖的是Klausur而非主键，依然存在传递依赖Matrikelnr → Klausur → Raum，不符合3NF。同时这种设计会造成数据冗余：比如多个学生参加同一门考试，Klausur和Raum的对应关系会重复存储，还可能出现同一考试对应不同考场的矛盾数据，维护性差。

• 方案2的合理性：

  • Student表：主键Matrikelnr，Stud.-Name和Klausur都直接依赖学号（学生姓名属于学生属性，考试名称是该学生参加的考试），满足2NF。
  • Klausur表：主键Klausur，Raum直接依赖考试名称（一门考试对应固定考场），不存在传递依赖。
    整个结构消除了传递依赖，也避免了数据冗余，完全符合第三范式的要求。

内容的提问来源于stack exchange，提问作者Begems