MySQL：从四个问题到数据库规范化理论

一、前言

在关系数据库的逻辑设计中，针对一个具体的问题，应该如何构造一个合适于它的关系模式，即应该构造几个关系，每个关系由哪些属性组成？

二、数据模式存在的问题

2.1 例子

我们设计的数据模式可能会出现什么问题？我们通过设计一个教务系统来了解一下

• 涉及的对象
  学号、所在系、系主任姓名、课程号和成绩
• 语义：
  1、一个系有若干个学生，但是一个学生只属于一个系
  2、一个系只有一个系主任
  3、一个学生可以选修多门课程，每门课程有若干学生选修
  4、每个学生所学的每门课程都有一个成绩

我们设计的关系模式：学生表(学号，所在系，系主任姓名，课程号，成绩)

学号	所在系	系主任姓名	课程号	成绩
S1	计算机系	张三	C1	90
S2	计算机系	张三	C1	95
S3	计算机系	张三	C2	90
S4	数学系	王五	C3	90
S5	数学系	王五	C4	90
S6	数学系	王五	C4	90
S7	物理系	李四	C7	90

2.2 问题

通过观察这个表我们可以发现，这个数据模式存在如下的四个问题：

数据冗余：数据冗余太大，浪费存储空间。通过观察我们发现系主任姓名重复出现。

更新异常：数据冗余，更新数据时，维护数据完整性代价大，如果某系更换系主任，系统必须修改与该系学生有关的每一个元组

插入异常：该插入的数据插不进去，如果新成立一个人工智能系，但是还没有招生，我们就无法把这个系及其系主任的信息插入表中

删除异常：不该删除的信息也被删除了，如果某个系的学生全部毕业了，我们在删除该系学生信息的时候也把该系和及其系主任的信息删除了

2.3 什么是好的数据模式

一个好的关系模式不会发生插入异常、删除异常、更新异常，同时数据冗余应尽可能少。如果设计好的关系模式呢？这就要用到数据库的规范化理论了。

三、数据库的规范化理论

3.1 关系模式

关系的描述称为关系模式（Relation Schema）它可以形式化地表示为：R（U，D，dom，F）

• R为关系名
• U为组成该关系的属性名集合
• D为属性组U中属性所来自的域
• dom为属性向域的映象集合
• F为属性间数据的依赖关系集合。

通常简记为：R(U) 或 R(A1，A2，…,An)
其中R为关系名，U为属性名集合，A1，A2，…,An为各属性名。
简单来说，表的关系模式就是对表的结构的描述。

3.2 函数依赖

• 函数依赖：
  设X,Y是关系R的两个属性集合，当任何时刻R中的任意两个元组中的X属性值相同时，则它们的Y属性值也相同，则称X函数决定Y，或Y函数依赖于X。

• 平凡函数依赖
  当关系中属性集合Y是属性集合X的子集时(Y⊆X)，存在函数依赖X→Y，即一组属性函数决定它的所有子集，这种函数依赖称为平凡函数依赖。

• 非平凡函数依赖
  当关系中属性集合Y不是属性集合X的子集时，存在函数依赖X→Y，则称这种函数依赖为非平凡函数依赖。

• 完全函数依赖
  设X,Y是关系R的两个属性集合，X’是X的真子集，存在X→Y，但对每一个X’都有X’!→Y，则称Y完全函数依赖于X。

• 部分函数依赖
  设X,Y是关系R的两个属性集合，存在X→Y，若X’是X的真子集，存在X’→Y，则称Y部分函数依赖于X。

• 传递函数依赖
  设X,Y,Z是关系R中互不相同的属性集合，存在X→Y(Y !→X),Y→Z，则称Z传递函数依赖于X。

3.3 候选码、超码、主码、主属性、非主属性、全码

设K为关系模式R<U,F>中的属性或属性组。

• 若U完全函数依赖于K，则K称为R的一个候选码（候选键）
• 若U部分函数依赖于K，则K称为R的一个超码
• 若关系模式R中有多个候选码，则选定其中的一个作为主码
• 包含在任何一个候选码中的属性，称为主属性
• 不包含在任何码中的属性称为非主属性或非码属性
• 整个属性组是候选码，称为全码

3.4 范式

1NF

如果一个关系模式R的所有属性都是不可分的基本数据项，则称其满足1NF。
在任何一个关系数据库中，第一范式是对关系模式的基本要求，不满足第一范式的数据库就不是关系数据库。

2NF

若R满足1NF，并且每个非主属性都完全函数依赖于R的候选码，则称R满足2NF。

3NF

若R满足1NF，并且每个非主属性既不部分依赖于R的候选码，也不传递依赖于候选码，则称R满足3NF

BCNF

若R满足1NF，并且每个属性（包括主属性和非主属性）既不部分依赖于R的候选码，也不传递依赖于候选码，则称R满足BCNF