数据库设计范式是数据库设计必须满足的规范，满足这些规范的数据库简洁、结构清晰，同时不会出现插入(insert )、删除(delete )、更新(update )操作异常。 相反，它却是乱来的，不仅会给数据库的程序员带来麻烦，还会给他们一张难看的脸，可能会存储大量不必要的冗馀信息。
范式说明
1.1 第一范式（1NF）无重复的列
正则表达式(1NF )是数据库表中的每一列都是不可分割的基本数据项，同一列不能有多个值。 这意味着实体中的一个属性不能有多个值，也不能有重复的属性。 如果出现重复属性，则必须定义由重复属性组成的新实体。 新实体和原始实体之间存在一对多的关系。 在第一范式(1NF )中，表格的每一行只包含一个实例的信息。 简而言之，第一范式是一个没有重复的列。
说明：在所有关系数据库中，第一范式(1NF )是关系模型的基本要求，不满足第一范式(1NF )的数据库不是关系数据库。
例如，以下数据库表符合第一个范例：
字段1
字段2
字段3
字段4
这种数据库表不符合最初的范式。
字段1
字段2
字段3
字段4
字段3.1
字段3.2
数据库表格中的所有字段都是单个属性，不能再分开。 该单属性由基本类型构成，有整数型、实数型、字符型、逻辑型、日期型等。 很明显，在当前的关系数据库管理系统(DBMS )中，傻瓜也不能创建不符合第一范式的数据库。 因为这些DBMS不能将数据库表中的一列进一步分为两列或更多列。 因此，用现有的DBMS设计不符合第一范式的数据库是不可能的。
1.2 第二范式（2NF）属性完全依赖于主键 [ 消除部分子函数依赖 ]
如果关系模型r是第一范式，而r中的所有非主属性完全函数依赖于具有r的候选键，则将其称为第二范式模型。
第二范式(2NF )基于第一范式) 1NF )构建，即满足第二范式(2NF )必须首先满足第一范式(1NF )。 第二范式(2NF )必须能够唯一区分数据库表中的每个实例或行。 为了实现区分，通常需要向表中添加列，以存储每个实例的唯一标识符。 此唯一的属性列称为主键或主键，主代码。
例如，员工编号(emp_id )列已添加到“员工信息”表中。 每个员工的员工编号是唯一的，因此可以唯一区分每个员工。
简而言之，第二范式(2NF )是非主属性完全依赖于主关键字。
完全依赖是指不能存在只依赖于部分主关键字的属性。 (设置函数依赖WA，如果XW存在，XA成立，则称为WA局部依赖，否则WA称为完全函数依赖。 如果存在，这个属性和主关键字的这个部分必须分离形成新的实体，新实体和原实体之间是一对多的关系。
之所以将选择关系表作为SelectCourse (学校编号、名字、年龄、课程名称、成绩、单位)，将关键字作为组合关键字(学校编号、课程名称)，是因为存在以下决定关系。
(学校编号、课程名称)(姓名、年龄、成绩、学分) )。
此数据库表不满足第二个范例，因为它具有以下决策关系：
(课程名称()单位) ) ) ) )。
(学号(姓名、年龄) )。
也就是说，组合关键字中的字段有时决定非关键字。
由于不符合2NF标准，该选择关系表存在以下问题。
(1)数据冗馀：
同一课程由n名学生选择后，“学分”重复n-1次； 同一学生修m门课时，姓名和年龄会重复m-1次。
)2)更新异常：
如果调整了某个课程的单位，数据表中所有行的“单位”值都会更新。 否则，同一课程的学分可能不同。
)3)插入异常：
如果要开设新课程的话，还没有人选择。 因此，由于没有“学校编号”关键字，课程名称和学分也无法记录在数据库中。
)4)异常删除：
/p>
假设一批学生已经完成课程的选修，这些选修记录就应该从数据库表中删除。但是，与此同时，课程名称和学分信息也被删除了。很显然，这也会导致插入异常。
把选课关系表SelectCourse改为如下三个表：
学生：Student(学号, 姓名, 年龄)；
课程：Course(课程名称, 学分)；
选课关系：SelectCourse(学号, 课程名称, 成绩)。
这样的数据库表是符合第二范式的， 消除了数据冗余、更新异常、插入异常和删除异常。
另外，所有单关键字的数据库表都符合第二范式，因为不可能存在组合关键字。
1.3 第三范式（3NF）属性不依赖于其它非主属性 [ 消除传递依赖 ]
如果关系模式R是第二范式，且每个非主属性都不传递依赖于R的候选键，则称R为第三范式模式。
满足第三范式（3NF）必须先满足第二范式（2NF）。第三范式（3NF）要求一个数据库表中不包含已在其它表中已包含的非主关键字信息。
例如，存在一个部门信息表，其中每个部门有部门编号（dept_id）、部门名称、部门简介等信息。那么在的员工信息表中列出部门编号后就不能再将部门名称、部门简介等与部门有关的信息再加入员工信息表中。如果不存在部门信息表，则根据第三范式（3NF）也应该构建它，否则就会有大量的数据冗余。
第三范式（3NF）：在第二范式的基础上，数据表中如果不存在非关键字段对任一候选关键字段的传递函数依赖则符合第三范式。简而言之，第三范式就是属性不依赖于其它非主属性。
所谓传递函数依赖，指的是如果存在"A → B → C"的决定关系，则C传递函数依赖于A。
因此，满足第三范式的数据库表应该不存在如下依赖关系：
关键字段 → 非关键字段x → 非关键字段y
假定学生关系表为Student(学号, 姓名, 年龄, 所在学院, 学院地点, 学院电话)，关键字为单一关键字"学号"，因为存在如下决定关系：
(学号) → (姓名, 年龄, 所在学院, 学院地点, 学院电话)
这个数据库是符合2NF的，但是不符合3NF，因为存在如下决定关系：
(学号) → (所在学院) → (学院地点, 学院电话)
即存在非关键字段"学院地点"、"学院电话"对关键字段"学号"的传递函数依赖。
它也会存在数据冗余、更新异常、插入异常和删除异常的情况，读者可自行分析得知。
把学生关系表分为如下两个表：
学生：(学号, 姓名, 年龄, 所在学院)；
学院：(学院, 地点, 电话)。
这样的数据库表是符合第三范式的，消除了数据冗余、更新异常、插入异常和删除异常。
1.4 高兴的糖豆得范式（BCNF是3NF的改进形式）
若关系模式R是第一范式，且每个属性都不传递依赖于R的候选键。这种关系模式就是BCNF模式。即在第三范式的基础上，数据库表中如果不存在任何字段对任一候选关键字段的传递函数依赖则符合高兴的糖豆得范式。
假设仓库管理关系表为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范式的，消除了删除异常、插入异常和更新异常。
四种范式之间存在如下关系：
范式应用
我们来逐步搞定一个论坛的数据库，有如下信息：
（1）用户：用户名，email，主页，电话，联系地址
（2）帖子：发帖标题，发帖内容，回复标题，回复内容
第一次我们将数据库设计为仅仅存在表：
用户名 email 主页电话 联系地址 发帖标题 发帖内容回复标题 回复内容
这个数据库表符合第一范式，但是没有任何一组候选关键字能决定数据库表的整行，唯一的关键字段用户名也不能完全决定整个元组。我们需要增加"发帖ID"、"回复ID"字段，即将表修改为：
用户名 email 主页电话 联系地址 发帖ID 发帖标题 发帖内容 回复ID 回复标题 回复内容
这样数据表中的关键字(用户名，发帖ID，回复ID)能决定整行：
(用户名,发帖ID,回复ID) → (email,主页,电话,联系地址,发帖标题,发帖内容,回复标题,回复内容)
但是，这样的设计不符合第二范式，因为存在如下决定关系：
(用户名) → (email,主页,电话,联系地址)
(发帖ID) → (发帖标题,发帖内容)
(回复ID) → (回复标题,回复内容)
即非关键字段部分函数依赖于候选关键字段，很明显，这个设计会导致大量的数据冗余和操作异常。
我们将数据库表分解为（带下划线的为关键字）：
（1）用户信息：用户名，email，主页，电话，联系地址
（2）帖子信息：发帖ID，标题，内容
（3）回复信息：回复ID，标题，内容
（4）发贴：用户名，发帖ID
（5）回复：发帖ID，回复ID
这样的设计是满足第1、2、3范式和BCNF范式要求的，但是这样的设计是不是最好的呢？
不一定。
观察可知，第4项"发帖"中的"用户名"和"发帖ID"之间是1：N的关系，因此我们可以把"发帖"合并到第2项的"帖子信息"中；第5项"回复"中的"发帖ID"和"回复ID"之间也是1：N的关系，因此我们可以把"回复"合并到第3项的"回复信息"中。这样可以一定量地减少数据冗余，新的设计为：
（1）用户信息：用户名，email，主页，电话，联系地址
（2）帖子信息：用户名，发帖ID，标题，内容
（3）回复信息：发帖ID，回复ID，标题，内容
数据库表1显然满足所有范式的要求；
数据库表2中存在非关键字段"标题"、"内容"对关键字段"发帖ID"的部分函数依赖，即不满足第二范式的要求，但是这一设计并不会导致数据冗余和操作异常；
数据库表3中也存在非关键字段"标题"、"内容"对关键字段"回复ID"的部分函数依赖，也不满足第二范式的要求，但是与数据库表2相似，这一设计也不会导致数据冗余和操作异常。
由此可以看出，并不一定要强行满足范式的要求，对于1：N关系，当1的一边合并到N的那边后，N的那边就不再满足第二范式了，但是这种设计反而比较好！
对于M：N的关系，不能将M一边或N一边合并到另一边去，这样会导致不符合范式要求，同时导致操作异常和数据冗余。
对于1：1的关系，我们可以将左边的1或者右边的1合并到另一边去，设计导致不符合范式要求，但是并不会导致操作异常和数据冗余。
结论
满足范式要求的数据库设计是结构清晰的，同时可避免数据冗余和操作异常。这并意味着不符合范式要求的设计一定是错误的，在数据库表中存在1：1或1：N关系这种较特殊的情况下，合并导致的不符合范式要求反而是合理的。
在我们设计数据库的时候，一定要时刻考虑范式的要求。