规范化至第三范式例题

在数据库设计中，规范化是一种重要的技术，其目的是减少数据存储的冗余度，优化数据库的性能和数据的完整性。规范化至第三范式是一种常见的规范化形式，本文将以一个例题为例，从多个角度讲解规范化至第三范式的技巧和方法。

例题：

假设有一个学校管理系统，需要记录每个学院的信息和每个学院下面的专业信息。每个学院包括学院编号、学院名称、学院简介；每个专业包括专业编号、专业名称、专业简介和所属学院编号。现在需要将这个系统进行规范化至第三范式，请问应该如何设计数据库？

第一步：设计初始关系模式

根据上述问题，初始关系模式可以设计为两个表：

学院表（colleges）：学院编号、学院名称、学院简介

专业表（majors）：专业编号、专业名称、专业简介、所属学院编号

第二步：规范化至第一范式

在第一步中，我们按照最原始的方式设计出了关系模式，但是这个关系模式存在冗余数据。比如，学院名称和学院简介在专业表中是重复出现的，这个问题可以通过规范化至第一范式来解决，即每个表中的属性都是原子性的，不能再拆分为更小的部分。

学院表（colleges）：学院编号、学院名称、学院简介

专业表（majors）：专业编号、专业名称、专业简介、所属学院编号

第三步：规范化至第二范式

虽然在第二步中已经将每个表中的属性都拆分成了最小单位，但是还存在某些属性与其他属性存在函数依赖的情况。例如，在专业表中，所属学院编号决定了学院名称和学院简介，即所属学院编号 -> 学院名称、学院简介，这个问题可以通过规范化至第二范式来解决，即在满足第一范式的前提下，将表中的非主属性与主属性分开来，形成新的关系表。

学院表（colleges）：学院编号、学院名称、学院简介

专业表（majors）：专业编号、专业名称、专业简介、所属学院编号

学院信息表（college_info）：所属学院编号、学院名称、学院简介

第四步：规范化至第三范式

在第三步中，我们已经将每个表都拆分成了满足第一范式和第二范式的关系表，但是还可能存在某些非主属性之间存在传递依赖的情况。例如，在学院信息表中，学院名称只依赖于所属学院编号，并不依赖于学院简介，所以可以将这两个属性拆分成两个关系表，以便满足第三范式。

学院表（colleges）：学院编号

学院信息表（college_info）：所属学院编号、学院名称

学院简介表（college_desc）：所属学院编号、学院简介

专业表（majors）：专业编号、专业名称、专业简介、所属学院编号