当前位置：首页 > news >正文

数据库范式（Normalization）

news 2025/9/15 15:52:56

一个设计混乱的数据库就像一个杂乱的房间，用起来非常不方便：东西到处乱放（数据冗余），找件东西要翻遍所有角落（查询困难），扔掉一把旧椅子时，可能会把搭在上面的唯一一件外套也一起扔了（删除异常）。

数据库范式（Normalization） 就是一套“房间整理法则”，指导我们如何合理地组织数据表，以消除冗余、避免上述问题。2NF和3NF是其中最核心、最重要的两条法则。

假设我们要设计一个系统来记录学生的选课成绩。最直接的想法可能是把所有信息都塞进一张大表里。这张表符合第一范式（1NF），因为每个单元格都只有一个值，并且没有完全重复的行。但你会发现，它问题重重。

选课成绩表 (符合1NF)

学号	课程号	学生姓名	课程名称	授课老师	成绩
101	CS101	张三	计算机导论	王老师	92
101	MTH202	张三	高等数学	李老师	85
102	CS101	李四	计算机导论	王老师	88
103	PHY301	王五	量子力学	赵老师	95

我们先来分析这张表的“身份”信息：

主码 (Primary Key): 要唯一确定一行数据，需要同时知道“哪个学生”和“哪门课”。因为一个学生可以选多门课，一门课也可以被多个学生选。所以，主码是 (学号, 课程号) 这样一个组合。
主属性: 学号, 课程号。
非主属性: 学生姓名, 课程名称, 授课老师, 成绩。

这张表虽然能用，但有严重的“副作用”（我们称之为“异常”）：

更新异常 (Update Anomaly): 如果学生“张三”改名叫“张大三”，你必须修改所有他出现的行。一旦漏掉一行，数据就不一致了。
插入异常 (Insertion Anomaly): 你无法添加一个新生（比如学号104的“赵六”），除非他至少选了一门课。因为主码 (学号, 课程号) 要求 课程号 不能为空。
删除异常 (Deletion Anomaly): 如果“王五”退掉了他唯一选的课（量子力学），那么他所在的整行数据都会被删除。我们不仅丢失了他的选课记录，连“王五”这个学生本身的信息也从数据库里消失了！

如何解决这些问题？答案就是遵循范式法则进行整理。

一个表在符合1NF的基础上，如果所有非主属性都“完全函数依赖”于主码，那么它就符合2NF。

我们的主码是 (学号, 课程号)。我们来检查一下每个非主属性：

成绩: 由什么决定？必须同时知道 学号 和 课程号 才能确定一个唯一的成绩。所以，成绩 依赖于整个主码。这很好，符合2NF。
学生姓名: 由什么决定？只需要 学号 就能确定。学生的姓名和他选了什么课没关系。所以，学生姓名 只依赖于主码的一部分 (学号)。这很糟糕，违反了2NF。
课程名称 和 授课老师: 由什么决定？只需要 课程号 就能确定。这和哪个学生来选课也没关系。所以，这两个属性也只依赖于主码的一部分 (课程号)。这也很糟糕，违反了2NF。

解决办法就是“分家”。把那些只依赖于部分主码的信息，拆分出去成立自己的独立小家庭（新表）。

学生表 (Students)

课程表 (Courses)

选课表 (Enrollment)

现在，我们所有的表都符合2NF了，之前提到的那些异常问题也随之解决！张三改名，只需改 学生表 一处。新生赵六可以直接添加到 学生表，不用非得选课。

我们离完美还差一步。仔细看刚刚创建的 课程表，它里面还隐藏着一个问题。

一个表在符合2NF的基础上，如果不存在“传递函数依赖”，那么它就符合3NF。

“传递函数依赖”：指的是一个非主属性，不直接依赖于主码，而是通过另一个非主属性间接地依赖于主码。形成了一个依赖链条：主码 -> 非主属性A -> 非主属性B。
通俗版法则：任何一个非主属性，都不能依赖于其他非主属性。

为了让问题更明显，我们在 课程表 里加一列“老师所在院系”。

课程表 (符合2NF，但不符合3NF)

课程号 (主码)	课程名称	授课老师	老师所在院系
CS101	计算机导论	王老师	计算机系
MTH202	高等数学	李老师	数学系
CS205	数据结构	王老师	计算机系

我们来检查主码 课程号 和非主属性之间的依赖关系：

课程名称 直接依赖于 课程号。很好。
授课老师 直接依赖于 课程号（为简化，假设一门课只有一个老师）。很好。
老师所在院系: 老师的院系是由 课程号 决定的吗？不是！ 它是由授课老师决定的。这样就形成了一个依赖链条：
课程号 -> 授课老师 -> 老师所在院系
这就是传递依赖，它违反了3NF。