数据库设计篇：范式设计思想

 

范式
Normal Format

设计关系数据库时，遵从不同的规范要求，设计出合理的关系型数据库，这些不同的规范要求被称为不同的范式，各种范式呈递次规范，越高的范式数据库冗余越小。目
前关系数据库有六种范式：第一范式（1NF）、第二范式（2NF）、第三范式（3NF）、巴斯-科德范式（BCNF）、第四范式(4NF）和第五范式
（5NF，又称完美范式）。在第一范式的基础上进一步满足更多规范要求的称为第二范式（2NF），其余范式以次类推。一般说来，数据库只需满足第三范式
(3NF）就行了。终极目标是为了解决数据的冗余。

1NF

所谓第一范式（1NF）是指在关系模型中，对域添加的一个规范要求，所有的域都应该是原子性的，即数据库表的每一列都是不可分割的原子数据项，而不能是集合，数组，记录等非原子数据项。即实体中的某个属性有多个值时，必须拆分为不同的属性。在符合第一范式（1NF）表中的每个域值只能是实体的一个属性或一个属性的一部分。简而言之，第一范式就是无重复的域。

由于很多人设计表的时候，往往会把很多信息以“，”隔开来存入一个字段，再根据需要使用的时候再拿出来进行循环切割，实际这种设计思想已经不满足1NF了，应该修改成如下图：

比如某些数据库系统中需要用到“地址”这个属性，本来直接将“地址”属性设计成一个数据库表的字段就行。但是如果系统经常会访问“地址”属性中的“城市” 部分，那么就非要将“地址”这个属性重新拆分为省份、城市、详细地址等多个部分进行存储，这样在对地址中某一部分操作的时候将非常方便。这样设计才算满足 了数据库的第一范式，如下表所示。

2NF
基于满足1NF上，在数据表设计的过程中，如果有复合主键(多字段)，且表中有字段并不是由整个主键来确定，而是依赖主键中的某个字段(主键部分)，存在字段依赖主键部分的问题，称为部分依赖，第二范式就是要解决表设计不允许出现部分依赖。

讲师代课表：



以上表中，因为讲师没有办法作为独立主键，需要结合班级才作为主键(讲师，班级)代课时间都与代课主键(讲师和班级)对应，但是性别不依赖与班级，教师不依赖于讲师，性别只依赖讲师，教室只依赖班级，出现性别和教室依赖主键的一部分，部分依赖不符合2NF。

解决方案1：可以将性别与讲师单独成表，班级与教室也单独成表

解决方案2：取消复合主键，使用逻辑主键

3NF
一张表中的所有字段直接依赖主键(逻辑主键：代表的是业务逻辑主键)，如果表设计中在一个字段，并不直接依赖主键，而是通过某个非主键字段，最终实现依赖主键，把这种不依赖主键而是依赖非主键字段的依赖关系称之为传递依赖。第三范式就是要解决传递依赖的问题。(不能出现传递依赖)

讲师代课表：



在讲师代课表中，性别依赖于讲师字段，教室依赖于班级字段，出现传递依赖，应该设计成如图3个表来记录：

(ps:其中的ID均为逻辑主键，也许会有疑问，讲师表和班级表中也同样存在传递关系，实际上是没有的，因为逻辑主键ID是代表业务字段“讲师"的)