---

1NF 需要保证表中每个属性都保持原子性；
2NF 需要保证表中的非主属性与候选键完全依赖；
3NF 需要保证表中的非主属性与候选键不存在传递依赖。

---

BC范式：https://baike.baidu.com/item/BC%E8%8C%83%E5%BC%8F/3193909?fr=aladdin
第四范式：https://baike.baidu.com/item/%E7%AC%AC%E5%9B%9B%E8%8C%83%E5%BC%8F/3193985
第五范式：https://baike.baidu.com/item/%E7%AC%AC%E4%BA%94%E8%8C%83%E5%BC%8F

1、数据库的设计范式

范式是数据表设计的基本原则。
范式：需要对关系内部各个属性之间联系的合理化程序进行定义，就有了不同等级的规范要求，这些规范要求就是范式(NF)

关系型数据库有6种范式，按照范式级别，从低到高分别是：1NF(第一范式)、2NF(第二范式)、3NF(第三范式)、BCNF(巴斯-科德范式)、4NF(第四范式)、5NF(第五范式，又叫做完美范式)。
反规范化：破坏范式规则。

image.png

数据表设计的范式，数据表设计的三大范式：第一范式、第二范式、第三范式。

• 第一范式（1NF）
  所有的字段都是基本数据字段，不可进一步拆分。数据库表中的任何属性都是原子性的，不可再分。比如字段X，不可拆分字段为X-1和字段X-2。
  1、表中的同一列的类型相同
  2、一个列名只能对应到一列
  3、并且每一列都不可分
  4、行的上下关系互不影响

• 第二范式(2NF)
  满足第一范式的前提，满足数据表里的每一条数据记录，都是可唯一标识的，而且所有字段，都必须完全依赖主键，不能只依赖主键的一部分。
  数据表里的非主属性都要和这个数据表的候选键有完全依赖关系。

即1NF 告诉我们字段属性需要是原子性的，而 2NF 告诉我们一张表就是一个独立的对象，也就是说一张表只表达一个意思。

举例：
学生基本信息表（学号，身份证号，姓名）中，学号属性是唯一的。而（学号，身份证号） ->姓名，
（身份证号） ->姓名，
（学号） ->姓名，
所以姓名部分函数依赖于（学号，身份证号）。

• 第三范式(3NF)
  满足第二范式的前提，不能包含那些可以由非主键字段派生出来的字段，或者说，不能存在依赖于非主键字段的字段。
  对任何非主属性都不传递依赖于候选键。也就是说不能存在非主属性A依赖于非主属性性B，非主属性B依赖于候选键的情况。

  
  image.png

• 巴斯范式（BCNF）
  巴斯范式（BCNF），也叫巴斯-科德范式，在3NF的基础上消除了主属性对候选键的部分依赖或者传递依赖关系。

image.png

业务优先的原则：一切以业务需求为主，技术服务于业务。

2、数据表中的那些键

范式的定义会使用到主键和候选键（主键和候选键可以唯一标识元组），数据库中的键（Key）由一个或者多个属性组成。我总结了下数据表中常用的集中键和属性的定义：

• 超键：能唯一标识元组的属性集叫做超键；
• 候选键：如果超键不包括多余的属性，最小的超键，那么这个超键就是候选键；也称之为码。
• 主键：用户可以从候选键中选择一个作为主键；即主码。
• 外键：如果数据表R1中的某属性集不是R1的主键，而是另一个数据表R2的 主键，那么这个属性集就是数据表R1的外键；
• 主属性：包含在任一候选键中的属性成为主属性；
• 非主属性：与主属性相对，指的是不包含在任何一个候选键中的属性；

实例：
NBA 的球员表（player）和球队表（team）。
球员表：定义为包含球员编号、姓名、身份证号、年龄和球队编号；
球队表：包含球队编号、主教练和球队所在地。
对于球员表来说，
1、超键：包括球员编号或者身份证号的任意组合，比如（球员编号）、（球员编号，姓名）、（身份证号，年龄）等。
2、候选键：最小的超键，对于球员表来说，候选键就是（球员编号）或者（身份证号）。
3、主键：我们自己选定，也就是从候选键中选择一个，比如（球员编号）。
4、外键：球员表中的球队编号。
在 player 表中，
1、主属性：（球员编号）、（身份证号）
2、非主属性：其他的属性：（姓名）、（年龄）、（球队编号）都是非主属性。