【数据库-通用知识系列-01】数据库规范化设计之范式，让数据库表看起来更专业

我们在设计数据库时考虑的因素包括读取性能，数据一致性，数据冗余度，可扩展性等，好好学习数据库规范化的知识，设计的数据库表看起来才专业。

范式一览

“键”理解：

• 超键：在关系中能唯一标识元组的属性集称为关系模式的超键
• 候选键：不含有多余属性的超键称为候选键。也就是在候选键中，若再删除属性，就不是键了。
• 主键：用户选作元组标识的一个候选键称为主键。
• 外键：如果关系模式R中属性K是其它模式的主键，那么K在模式R中称为外键。

主键为候选键的子集，候选键为超键的子集，而外键的确定是相对于主键的！

0NF（Not Normal Form）

一个员工有多个电话，用“，”分割，我们常常这样设计，的确这样设计没毛病，干嘛再设计一个写的电话表，还要关联，浪费时间。的确，我们有些情况下确实这样设计。但是他不符合数据库的规范，为什么呢：

1. 首先看Phone，字段长度不明确，我们应该定义多长，长了浪费，短了业务不允许。
2. 统一每个人有多少电话，没法统计。
3. 可维护性差，我删除个电话，更换个电话不好弄。
4. 扩展性差，哪个是主，哪个是次，哪个是家庭，哪个是工作电话怎么搞。

所以就有了1NF，设计上还是不要有分割，保持原子性。

EmployeeId	Person	Phone
1	John Jones	27716602, 26153215,
2	Peter Janes	47716602, 36153215, 52321262
3	Michael Juines	17716602

1NF（First Normal Form）

定义：第一范式是指数据库的每一列都是不可分割的基本数据项，强调列的原子性。

我们改造一下上边的表结构，这样就符合了第一范式：

EmployeeId	Person	Phone
1	John Jones	27716602
1	John Jones	26153215
2	Peter Janes	47716602
2	Peter Janes	36153215
2	Peter Janes	52321262
3	Michael Juines	17716602

上边第一范式的设计好吗？不太优雅吧，我们有太多的冗余，如果现在Peter有3个电话占了三行，若有Peter有100个电话呢，是不是要有100行一样的EmployeeId和Person。可能你会说，也占用不了太多的空间呀，那我要问你Peter还有100多个属性呢，所以说，第一范式是没有考虑数据冗余的。我们要消灭数据冗余，就要考虑2NF。

2NF（Second Normal Form ）

定义：第二范式建立在第一范式的基础上，即满足第二范式一定满足第一范式，第二范式要求数据表每一个实例或者行必须被唯一标识。除满足第一范式外还有两个条件，一是表必须有一个主键；二是没有包含在主键中的列必须完全依赖于主键，而不能只依赖于主键的一部分。

上表的主键现在是什么，竟然是EmployeeId和Phone组成的联合主键，而Name只依赖于EmployeeId。这就不符合Employee的建表目的了，name只依赖于EmployeeId就好，Phone在这凑什么热闹，把Phone单独建张表吧：

EmployeeId	Name
1	John
2	Peter
3	Michael

PhoneId	Phone
1	27716602
2	26153215
3	47716602
4	36153215
5	52321262
6	17716602

EmployeeId	PhoneId
1	1
1	2
2	3
2	4
2	5
3	6

3NF（Third Normal Form）

定义： 若某一范式是第二范式，且每一个非主属性都不传递依赖于该范式的候选键，则称为第三范式，即不能存在：非主键列 A 依赖于非主键列 B，非主键列 B 依赖于主键的情况。

第三范式其实也和第二范式一个目的，减少数据冗余。为了说明第3范式，我们增加个邮编地址，如下表所示。

EmployeeId	Name	ZIP	City
1	John	8000	Aarhus C
2	Peter	8200	Aarhus N
3	Michael	8520	Lystrup

上表明显满足第二范式，但是是不是感觉City多余，明明非主属性ZIP知道了就知道非主属性EmployeeId在哪个城市了。好了，这里出来了一个传递依赖，消灭掉如下：

EmployeeId	Name	ZIP
1	John	8000
2	Peter	8200
3	Michael	8520

ZIP	City
8000	Aarhus C
8200	Aarhus N
8520	Lystrup

BCNF（Boyce and Codd Normal Form）

下表满足：

1. 1个学生可以选择多门课程，比如101选了java和C++。
2. 一个教授教一门课程，可以有多个教授教一门课程，比如Java对应三个教授。

studentId	subject	professor
101	Java	P.Java
101	C++	P.Cpp
102	Java	P.Java2
103	C#	P.Chash
104	Java	P.Java

该设计满足3NF，因为主键为studentId和subject，满足1NF，所有值都是原子；满足2NF，不存在部分依赖。满足3NF，不存在传递依赖。但是不是BCNF，原因如下：

professor->subject

subject是一个主属性，而professor为非主属性，所以不满足BCNF。修改如下：

Student Table

student_id	p_id
101	1
101	2

Professor Table

p_id	professor	subject
1	P.Java	Java
2	P.Cpp	C++

---

原文：[实践派]-数据库规范化