范式简介
在关系型数据库中，关于数据表设计的基本原则、规则就成为范式。范式的应为时 Normal Form 简称 NF，范式是关系型数据库理论的基础，也是我们在设计数据库过程中索要遵循的规则和指导方法。
目前关系型数据库有六种常见范式，按照范式级别，从低到高分别是：
- 第一范式(1NF)：第一范式主要是确保数据表中每个字段的值必须有原子性，也就是说数据表中的每个字段的值是
不可再次拆分的最小数据单元。 - 第二范式(2NF)：在满足第一范式的基础上，还要
满足数据表里的每一条记录都是可唯一标识的，且所有非主键字段，都必须完全依赖主键，不能只依赖主键的一部分。如果存在不完全依赖，那么这个属性和主关键字的这一部分应该分离出来形成一个新的实体，新实体与元实体是一对多的关系。 - 第三范式(3NF)：在第二范式的基础上，确保数据表中的每一个非主键字段都和主键字段直接相关，也就是说，
要求数据表中的所有非主键字段不能依赖于其他非主键字段(即所有非主键属性之间不能有依赖关系，必须相互独立)。 - 巴斯-科德范式(BCNF)：简称巴斯范式，若一个关系达到了第三范式，并且它只有一个候选键，或者它的每个候选键都是单属性，则该关系自然达到巴斯范式。
该范式被认为没有新的设计规范加入，只是在 3NF 的基础上设计规范要求更强，使得数据库冗余度更小。所以也被称为修正的第三范式或扩充的第三范式。
- 第四范式(4NF)：在满足 BCNF 的基础之上，消除非平凡且非函数以来的多值依赖(即把同一表内的多对多关系删除)。
- 多值依赖：即属性之间的一对多关系
- 函数依赖：事实上时单值依赖，所以不能表达属性之间的一对多关系
- 平凡的多值依赖：全集U=K+A，一个 K 可以对应多个A，此时整个表就是一组一对多关系。
- 非平凡的多值依赖：全集U=K+A+B，一个 K 可以对应多个 A，也可以对应多个 B，A 与 B 相互独立，整个表有多组一对多关系，且有“一”部分时相同的属性集合，“多”部分时相互独立的属性集合
- 第五范式(5NF,又称完美范式)：在满足 4NF 的基础之上，消除不是由候选键所蕴含的连接依赖。如果关系模式 R 中的每一个连接依赖均由 R 的候选键所隐含，则称此关系模式符合第五范式。第五范式处理的是无损连接的问题，这个范式基本没有实际意义，因为无损连接很少出现且难以察觉。
1NF 确保每列保持原子性；2NF 确保每列都和主键完全依赖；3NF 确保每列都和主键列完全相关，而不是间接相关；
数据库的范式设计越高阶，冗余度就越低，同时高阶的范式一定符合低阶范式的要求，要满足最低要求的范式是第一范式。
一般来说，在关系型数据库设计中，最高也就遵循到 BCNF，普遍还是 3NF。但也不绝对，有些特殊情况为了提高某些查询性能，我们还需要破坏范式规则，也就是反规范化。
范式的优点：数据的标准化有助于消除数据库中的数据冗余，3NF 通常被认为在性能、扩展性和数据完整性方面达到了最好的平衡。
范式的缺点：范式的使用，可能降低查询效率。因为范式等级越高，设计出来的数据就越多、越精细，数据的冗余度就越低，进行数据查询的时候可能需要关联多张表，不但成本较高也可能使一些索引策略无效。
键和相关属性的概念
范式的定义会使用到主键和候选键，数据库中的键(Key)由一个或多个属性组成。
数据表中常用的几种键和属性的定义：
- 超键：能唯一标识元组的属性集叫超键
- 候选键：如果超键不包括多余的属性，那么这个超键就是候选键
- 主键：用户可以从候选键中选择一个作为主键
- 外键：如果数据表 R1 中的某属性集不是 R1 的主键，而是另一个数据表 R2 的主键，那么这个属性集就是数据表 R1 的外键
- 主属性：包含在任一候选键中的属性成为主属性
- 非主属性：与主属性相对，指的是不包含任何一个候选键中的属性。
反范式化
有时候不能简单地按照规范要求设计数据表，因为有的数据看似冗余，其实对业务来说十分重要。这个时候，我们就要遵循业务优先的原则，首先满足业务需求，再尽量减少冗余。
但冗余信息有价值或者能大幅提高查询效率的时候，我们才会采取反范式的优化。反范式可以通过空间换时间，提升查询的效率，但也会带来一些问题：
- 存储空间变大了
- 一个表中字段做了修改，另一个表中冗余的字段也需要做同步修改，否则数据不一致
- 若采用存储过程来支持数据的更新、删除等额外操作，如果更新频繁会非常消耗系统资源
- 在数据量小的情况下，反范式不能体现性能的优势，可能还会让数据库的设计更加复杂。