范式

范式（NF）可以理解为，一张数据表的设计结构需要满足的某种设计标准的级别。

数据库的范式设计越高阶，冗余度就越低，同时高阶的范式一定符合低阶范式的要求。

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

各种键的举例：NBA 的球员表（player）和球队表（team）。这里我可以把球员表包含：球员编号、姓名、身份证号、年龄和球队编号；球队表包含：球队编号、主教练和球队所在地。

对于球员表来说
超键就是包括球员编号或者身份证号的任意组合，比如（球员编号）（球员编号，姓名）（身份证号，年龄）等。
候选键就是最小的超键，对于球员表来说，候选键：（球员编号）或者（身份证号）。
主键：球员编号
外键：球队编号
主属性：（球员编号）（身份证号），其他的属性（姓名）（年龄）（球队编号）都是非主属性。

范式：

1NF 指的是数据库表中的任何属性都是原子性的，不可再分
2NF数据表里的非主属性都要和这个数据表的候选键有完全依赖关系，如果有部分依赖，会产生问题

• 数据冗余：如果一个球员可以参加 m 场比赛，那么球员的姓名和年龄就重复了 m-1 次。
• 插入异常：添加一场新的比赛，但是这时还没有确定参加的球员都有谁，那么就没法插入。
• 删除异常：删除某个球员编号，如果没有单独保存比赛表的话，就会同时把比赛信息删除掉。
• 更新异常：调整了某个比赛的时间，那么数据表中所有这个比赛的时间都需要进行调整。
  避免这样的问题可以设计三张表：
  球员 player 表包含球员编号、姓名和年龄等属性；
  比赛 game 表包含比赛编号、比赛时间和比赛场地等属性；
  球员比赛关系 player_game 表包含球员编号、比赛编号和得分等属性。

**3NF 在满足 2NF 的同时，对任何非主属性都不传递依赖于候选键。**也就是说不能存在非主属性 A 依赖于非主属性 B，非主属性 B 依赖于候选键的情况。