数据库设计范式
大部分业务开发都需要我们开发人员自己进行表结构的设计，设计关系数据库时，会要求我们遵从不同的规范要求，设计出合理的关系型数据库，只有设计出更加合理的数据库表结构，才能在业务处理和后期维护变得更加方便。这些不同的规范要求被称为不同的范式，各种范式呈递次规范，越高的范式数据库冗余越小。
关系数据库有六种范式(Normal form)：第一范式（1NF）、第二范式（2NF）、第三范式（3NF）、巴斯-科德范式（BCNF）、第四范式(4NF）和第五范式（5NF，又称完美范式）。
1、第一范式（1NF）
所谓第一范式（1NF）是指在关系模型中，对于添加的一个规范要求，所有的域都应该是原子性的，即数据库表的每一列都是不可分割的原子数据项，而不能是集合，数组，记录等非原子数据项。即实体中的某个属性有多个值时，必须拆分为不同的属性。在符合第一范式（1NF）表中的每个域值只能是实体的一个属性或一个属性的一部分。简而言之，第一范式就是无重复的域。
说明：在任何一个关系数据库中，第一范式（1NF）是对关系模式的设计基本要求，一般设计中都必须满足第一范式（1NF）。不过有些关系模型中突破了1NF的限制，这种称为非1NF的关系模型。换句话说，是否必须满足1NF的最低要求，主要依赖于所使用的关系模型。
举例：某个表中设计了用户地址（有且只有改地址字段），地址的字段就是：address，如果需要满足第一范式的设计，更加规范的地址应该设计为多个字段：省、市、区、街道地址等，这样在统计用户信息时，就可以满足更多业务或者报表的需求。
2、第二范式（2NF）
在1NF的基础上，所有属性必须完全依赖于主键（即：表中的每列都和主键相关，在1NF基础上消除非主属性对主码的部分函数依赖），这个就是2NF。
第二范式（2NF）是在第一范式（1NF）的基础上建立起来的，即满足第二范式（2NF）必须先满足第一范式（1NF）。第二范式（2NF）要求数据库表中的每个实例或记录必须可以被唯一地区分。选取一个能区分每个实体的属性或属性组，作为实体的唯一标识。例如在员工表中的身份证号码即可实现每个一员工的区分，该身份证号码即为候选键，任何一个候选键都可以被选作主键。在找不到候选键时，可额外增加属性以实现区分，如果在员工关系中，没有对其身份证号进行存储，而姓名可能会在数据库运行的某个时间重复，无法区分出实体时，设计辟如ID等不重复的编号以实现区分，被添加的编号或ID选作主键。（该主键的添加是在ER设计时添加，不是建库时随意添加）
所谓完全依赖是指不能存在仅依赖主关键字一部分的属性（如这样设计：用户同一个订单可以买不同商品，把订单信息和商品信息设计到一张表，如设计订单id和商品id为主键，那么这个里面订单地址，订单用户等只依赖订单id，订单商品名和商品价格只依赖商品id，所以这样设计就是不合理的，应该拆成多张表，订单信息表，商品信息表，和订单商品项目/数量关联表三张表）。如果存在，那么这个属性和主关键字的这一部分应该分离出来形成一个新的实体，新实体与原实体之间是一对多的关系。
假定选课关系表为SelectCourse(学号, 姓名, 年龄, 课程名称, 成绩, 学分)，关键字为组合关键字(学号, 课程名称)，因为存在如下决定关系：
(学号, 课程名称) → (姓名, 年龄, 成绩, 学分)
这个数据库表不满足第二范式，因为存在如下决定关系：
(课程名称) → (学分)
(学号) → (姓名, 年龄)
即存在组合关键字中的字段决定非关键字的情况。
由于不符合2NF，这个选课关系表会存在如下问题：
(1) 数据冗余：同一门课程由n个学生选修，"学分"就重复n-1次；同一个学生选修了m门课程，姓名和年龄就重复了m-1次。
(2) 更新异常：若调整了某门课程的学分，数据表中所有行的"学分"值都要更新，否则会出现同一门课程学分不同的情况。
(3) 插入异常：假设要开设一门新的课程，暂时还没有人选修。这样，由于还没有"学号"关键字，课程名称和学分也无法记录入数据库。
(4) 删除异常：假设一批学生已经完成课程的选修，这些选修记录就应该从数据库表中删除。但是，与此同时，课程名称和学分信息也被删除了。很显然，这也会导致插入异常。
把选课关系表SelectCourse改为如下三个表：
学生：Student(学号, 姓名, 年龄)；
课程：Course(课程名称, 学分)；
选课关系：SelectCourse(学号, 课程名称, 成绩)。
3、第三范式（3NF）
在2NF基础上，任何非主属性不依赖于其它非主属性（在2NF基础上消除传递依赖）
第三范式（3NF）是第二范式（2NF）的一个子集，即满足第三范式（3NF）必须满足第二范式（2NF）。简而言之，第三范式（3NF）要求一个关系中不包含已在其它关系已包含的非主关键字信息。例如，存在一个部门信息表，其中每个部门有部门编号（dept_id）、部门名称、部门简介等信息。那么在员工信息表中列出部门编号后就不能再将部门名称、部门简介等与部门有关的信息再加入员工信息表中。如果不存在部门信息表，则根据第三范式（3NF）也应该构建它，否则就会有大量的数据冗余。简而言之，第三范式就是属性不依赖于其它非主属性，也就是在满足2NF的基础上，任何非主属性不得传递依赖于主属性。
4、巴斯-科德范式Boyce-Codd Normal Form(BCNF)
在3NF基础上，任何非主属性不能依赖于主属性的子集（在3NF基础上消除对主码子集的依赖）
假设仓库管理关系表为StorehouseManage(仓库ID, 存储物品ID, 管理员ID, 数量)，且有一个管理员只在一个仓库工作；一个仓库可以存储多种物品。这个数据库表中存在如下决定关系：
(仓库ID, 存储物品ID) →(管理员ID, 数量)
(管理员ID, 存储物品ID) → (仓库ID, 数量)
所以，(仓库ID, 存储物品ID)和(管理员ID, 存储物品ID)都是StorehouseManage的候选关键字，表中的唯一非关键字段为数量，它是符合第三范式的。但是，由于存在如下决定关系：
(仓库ID) → (管理员ID)
(管理员ID) → (仓库ID)
即存在关键字段决定关键字段的情况，所以其不符合BCNF范式。它会出现如下异常情况：
(1) 删除异常：当仓库被清空后，所有"存储物品ID"和"数量"信息被删除的同时，"仓库ID"和"管理员ID"信息也被删除了。
(2) 插入异常：当仓库没有存储任何物品时，无法给仓库分配管理员。
(3) 更新异常：如果仓库换了管理员，则表中所有行的管理员ID都要修改。
把仓库管理关系表分解为二个关系表：
仓库管理：StorehouseManage(仓库ID, 管理员ID)；
仓库：Storehouse(仓库ID, 存储物品ID, 数量)。
这样的数据库表是符合BCNF范式的，消除了删除异常、插入异常和更新异常。
5、第四范式（4NF）
对于第四范式，从理论层面来讲是，关系模式R∈1NF,如果对于R的每个非平凡多值依赖X→Y(Y不属于X)，X都含有候选码，则R∈4NF。4NF就是限制关系模式的属性之间不允许有非平凡且非函数依赖的多值依赖。显然一个关系模式是4NF，则必为BCNF。也就是说，当一个表中的非主属性互相独立时（3NF），这些非主属性不应该有多值。若有多值就违反了第四范式。
有这样一个用户联系方式表TELEPHONE(CUSTOMERID,PHONE,CELL)。CUSTOMERID为用户ID,PHONE为用户的固定电话,CELL为用户的移动电话。本来，这是一个非常简单的第3范式表。主键为CUSTOMERID，不存在传递依赖。但在某些情况下，这样的表还是不合理的。比如说，用户有两个固定电话，两个移动电话。这时，表的具体表示如下：
CUSTOMERID PHONE CELL
1000 8828-1234 149088888888
1000 8838-1234 149099999999
由于PHONE和CELL是互相独立的，而有些用户又有两个和多个值。这时此表就违反第四范式。
在这种情况下，此表的设计就会带来很多维护上的麻烦。例如，如果用户放弃第一行的固定电话和第二行的移动电话，那么这两行会合并吗？解决问题的方法为，设计一个新表NEW_PHONE(CUSTOMERID,NUMBER,TYPE)。这样就可以对每个用户处理不同类型的多个电话号码，而不会违反第四范式。
显然，第四范式的应用范围比较小，因为只有在某些特殊情况下，要考虑将表规范到第四范式。所以在实际应用中，一般不要求表满足第四范式。
6、第五范式（5NF）
第五范式（5NF）：是最终范式。消除了4NF中的连接依赖。
第五范式有以下要求：
（1）必须满足第四范式
（2）表必须可以分解为较小的表，除非那些表在逻辑上拥有与原始表相同的主键。
第五范式是在第四范式的基础上做的进一步规范化。第四范式处理的是相互独立的多值情况，而第五范式则处理相互依赖的多值情况。
有一个销售信息表SALES（SALEPERSON，VENDOR，PRODUCT）。SALEPERSON代表销售人员，VENDOR代表供和商，PRODUCT则代表产品。在某些情况下，这个表中会产生一些冗余。可以将表分解为PERSON_VENDOR表（SALEPERSON，VENDOR）；PERSON_PRODUCT表（SALEPERSON，PRODUCT）；VENDOR_PRODICT表（VENDOR，PRODUCT）
总结：
1、第一范式主要针对具体某一列；第二范式主要针对某一列与复合主键的一部分有关；第三范式针对某一列与主键无关，但是与某一非主键列有关；巴斯-科德范式针对某一列与复合主键中的某一列有关，而与其他主键无关；
2、前三范式为主要约束，后面的三个范式根据需要使用也可以不使用。
