---

一、数据库范式是什么

数据库规范化，又称正规化、标准化，是数据库设计的一系列原理和技术，以减少数据库中数据冗余，增进数据的一致性。关系模型的发明者埃德加·科德最早提出这一概念，并于1970年代初定义了第一范式、第二范式和第三范式的概念，还与Raymond F. Boyce于1974年共同定义了第三范式的改进范式——BC范式。

除外还包括针对多值依赖的第四范式，连接依赖的第五范式、DK范式和第六范式。

现在数据库设计最多满足3NF，普遍认为范式过高，虽然具有对数据关系更好的约束性，但也导致数据关系表增加而令数据库IO更易繁忙，原来交由数据库处理的关系约束现更多在数据库使用程序中完成。

一般来说，数据库只需满足第三范式(3NF）就行了。

Normal Form 范式

• UNF: 非标准化形式
• 1NF: 第一范式
• 2NF: 第二范式
• 3NF: 第三范式
• EKNF: 主键范式
• BCNF: Boyce–Codd 范式（巴斯-科德范式）
• 4NF: 第四范式
• ETNF: 关键元组范式
• 5NF: 第五范式
• DKNF: 域键范式
• 6NF: 第六范式

二、主要范式内容

2.0、UNF: 非标准化形式

2.1、 1NF: 第一范式

第一范式意味着：表中没有重复的行、重复的列；不存在行序、列序。

第一范式（1NF）是数据库正规化所使用的正规形式。第一范式是为了要排除重复组的出现，要求数据库的每一列的论域都是由不可分割的原子值组成；每个字段的值都只能是单一值。1971年埃德加·科德提出了第一范式。

重复群（repeating group）是指含有多值的一个列。原子性（atomicity）的操作语义可以说如果关系数据库管理系统的类型系统允许的值，例如date类型、VARCHAR(20)类型。严格意义上，NULL违背了第一范式；通常把NULL理解为标记（marker），而不是值（value），用专门的函数、运算符去处理NULL。

如果设置了主键的话，理论上不可能会有任何关系数据库的资料表会违反第一范式的原则。
不过就算是在这种情况下，还是可以设计出在骨子里违反第一范式的资料表。最简单的方法就是把多个有意义的值编码过后存进一个字段里，然后在资料表中用很多字段来表达同一个事实。

2.1.1、不符合情况

1. 重复群，数量这个不定个数的值就不符合第一范式
   
   修改可用的
   
2. 没有唯一标识符，就是缺少类似主键的标识符 ，下面两个数据就无法去区分记录，标识符可以是一个字段，也可以是一组字段，可以保证在这个资料中的唯一标识符不会重复出现，
   
   改正
   
3. 用很多字段来表达同一个事实，也是违法的
   

就算我们能确定每个人不喜欢吃的食物最多不会超过三样，这还是一个很糟的设计。举例来说，我们想要知道所有不喜欢同一种食物的人的组合的话，这就不是件容易的事，因为食物有可能出现在任何一个字段，也就是说每一次的查询都要去检查
9 (3 x 3) 组不同的字段组合。

2.2、2NF: 第二范式

第二范式（2NF）是数据库正规化所使用的正规形式。
规则是要求资料表里的所有资料都要和该资料表的键（主键与候选键）有完全依赖关系：每个非键属性必须独立于任意一个候选键的任意一部分属性。如果有哪些资料只和一个键的一部分有关的话，就得把它们独立出来变成另一个资料表。如果一个资料表的键只有单个字段的话，它就一定符合第二范式。

一个资料表符合第二范式当且仅当

• 它符合第一范式
• 所有非键字段都不能是候选键非全体字段的函数

就是当他符合第二范式的时候他一定是符合“所有非键字段都不能是候选键非全体字段的函数and第一范式”，如果他符合“所有非键字段都不能是候选键非全体字段的函数and第一范式”，那他就一定符合第二范式。

2.2.1、问题情况

这里符合了第一范式，每个值都是单一值。

• 因为同一个组件有可能由不同的供应商提供，所以得把组件 ID 和供应商 ID 合在一起组成一个主键。

• 组件（关键词）和价格之间的关系很正确：同一个组件在不同供应商有可能会有不同的报价，所以价格确实和主键完全相关（完全依赖）。

• 另一方面，供应商的名称和住址就只和供应商 ID 有关（部分依赖），这不符合第二范式的原则。

• 仔细看就会发现 “Stylized Parts” 这个名称和 “VA” 这个住址重复出现了两次；要是它改名了或是被其他公司并购了怎么办？这时候最好把这些资料存到第二个资料表中：

• 这么一来，原本的 “组件来源” 资料表就得要做相对应的改动：

检查资料表里的每个字段，确认它们是不是都和关键词完全相关， 这样才能知道这个资料表是不是符合第二范式；

如果不是的话，就把那些不完全相关的字段移到独立的资料表里。

2.3、3NF: 第三范式

第三范式（3NF）是数据库正规化所使用的正规形式。
要求所有非主键属性都只和候选键有相关性，也就是说非主键属性之间应该是独立无关的。

如果再对第三范式做进一步加强就成了BC正规化，强调的重点在于“资料间的关系是奠基在主键上、以整个主键为考量、而且除了主键之外不考虑其他因素”。

R表一个关系；
F 表维持 R 所需的一组函数依赖；
X 表 R 属性的子集合；
A 表 R 的一个属性

• 最早由埃德加·科德在1971年给出的第三范式定义为
  1- 关系R(表)满足第二范式 (2NF)；
  2- R的每个非键属性是R的每个候选键的非传递依赖。
• Carlo Zaniolo于1982年给出的一个等价定义为：
  如果对于X——》A这种形式的函数依赖而言，满足一下任意一个条件，R就可以说是满足第三范式：
  • A∈（属于） X；也就是说 A 是明显函数依赖
  • X是超键
  • A 是R 的候选键的一部分

2.3.1、示例

示例 1、

• 表中的制造商地址应该是和制造商直接关联的，而不是和组件关联的，应该吧制造商地址独立出来一个表
  

示例 2、
对于这个表的所有非主键字段都依赖于主键编号， 通过主键可以导出唯一非主键字段值，符合第二范式的要求记录有惟 一标识，但第三范式要求所有非主键属性之间没有相关联的，应该是独立无关的，小计这个值需要根据 UnitPrice 和Quantity 的值来获得，所以不符合第三范式

修改符合3NF需要把小记拿掉
但在查询时就需要麻烦了： SELECT UnitPrice * Quantity FROM Order

2.4、EKNF: 主键范式

2.5、BCNF: Boyce–Codd 范式（巴斯-科德范式）

Boyce-Codd范式（英语：Boyce-Codd normal form，缩写BCNF），是数据库规范化的一种正规形式。是在第三范式的基础上加上稍微更严格约束，每个BCNF关系都满足第三范式。 BCNF去除了属性间的不必要的函数依赖。

BCNF的定义是：

如果对于关系模式R中存在的任意一个非平凡函数依赖X->A，都满足X是R的一个超键，那么关系模式R就属于BCNF。
对上述定义，可以理解为：平凡函数依赖关系是指，如果属性集合X包含了属性集合A，那么就一定有X->A；超键是指能够唯一确定表中各行的属性集合，因此一个超键的最小化就是一个候选键；BCNF是说，如果一个属性集合X能“不平凡”地推导出另一个属性集合A，而且X还不能唯一区分表的各行，那么这个表中一定包含了一些冗余信息。

BCNF与第三范式的不同之处在于：第三范式中不允许非主属性被另一个非主属性决定，但第三范式允许主属性被非主属性决定；而在BCNF中， 任何属性（包括非主属性和主属性）都不能被非主属性所决定。

就是第三范式只规定了非主键之间不能相关，但主属性（举例，学生id）可以被其他非主属性（“姓名”、“年龄”、“性别”、“班级”）影响，而在bcnf中任何属性都不能被非主属性影响

任何一个BCNF必然满足：

• 所有非主属性都完全函数依赖于每个候选键
• 所有主属性都完全函数依赖于每个不包含它的候选键
• 没有任何属性完全函数依赖于非候选键的 任何一组属性

2.5.1、示例

此时 Area 和County_name 依赖关系 ，但Area右不是主键，County_name这个非主键收到不是主键的影响就打破了BCNF规则

修改

2.6、4NF: 第四范式

第四正规化（4NF，中国大陆译作“第四范式”、台湾及香港译作“第四正规化”）是数据库正规化中所使用的一种正规形式，是BC范式之后的另一层次的规范化。第二范式、第三范式、BC范式关注于属性集合之间的函数依赖；而第四范式关注更一般形式称作多值依赖。

Ronald Fagin于1977年提出。 数据库的一个表遵从第四范式，当且仅当对于任意一个非平凡的多值依赖X ——> > Y,
X是一个超键。

2.7、ETNF: 关键元组范式

• List item

2.8、5NF: 第五范式

• List item

2.9、DKNF: 域键范式

• List item

2.10、6NF: 第六范式

• List item

参考文章

个人笔记，不同意见，望有交流
直接可以点击跳转连接

主要参考作者 维基百科