《数据库设计范式》由会员分享，可在线阅读，更多相关《数据库设计范式（6页珍藏版）》请在金锄头文库上搜索。
1、 数据库设计三大范式引言数据库的设计范式是数据库设计所需要满足的规范，满足这些规范的数据库是简洁的、构造明晰的，同步，不会发生插入（insert）、删除（delete）和更新（update）操作异常。反之则是乱七八糟，不仅给数据库的编程人员制造麻烦，并且面目可憎，也许存储了大量不需要的冗余信息。范式阐明第一范式（1NF）：数据库表中的字段都是单一属性的，不可再分。这个单一属性由基本类型构成，涉及整型、实数、字符型、逻辑型、日期型等。例如，如下的数据库表是符合第一范式的： 而这样的数据库表是不符合第一范式的：很显然，在目前的任何关系数据库管理系统（DBMS）中，傻瓜也不也许做出不符合第一范式的数
2、据库，由于这些DBMS不容许你把数据库表的一列再提成二列或多列。因此，你想在既有的DBMS中设计出不符合第一范式的数据库都是不也许的。第二范式（2NF）：数据库表中不存在非核心字段对任一候选核心字段的部分函数依赖（部分函数依赖指的是存在组合核心字中的某些字段决定非核心字段的状况），也即所有非核心字段都完全依赖于任意一组候选核心字。假定选课关系表为SelectCourse(学号, 姓名, 年龄, 课程名称, 成绩, 学分)，核心字为组合核心字(学号, 课程名称)，由于存在如下决定关系：(学号, 课程名称) (姓名, 年龄, 成绩, 学分)这个数据库表不满足第二范式，由于存在如下决定关系：(课程名
3、称) (学分)(学号) (姓名, 年龄)即存在组合核心字中的字段决定非核心字的状况。由于不符合2NF，这个选课关系表会存在如下问题：(1) 数据冗余：同一门课程由n个学生选修，学分就反复n-1次；同一种学生选修了m门课程，姓名和年龄就反复了m-1次。(2) 更新异常：若调节了某门课程的学分，数据表中所有行的学分值都要更新，否则会浮现同一门课程学分不同的状况。(3) 插入异常：假设要开设一门新的课程，临时还没有人选修。这样，由于还没有学号核心字，课程名称和学分也无法记录入数据库。(4) 删除异常：假设一批学生已经完毕课程的选修，这些选修记录就应当从数据库表中删除。但是，与此同步，课程名称和学分信
4、息也被删除了。很显然，这也会导致插入异常。 把选课关系表SelectCourse改为如下三个表：学生：Student(学号, 姓名, 年龄)；课程：Course(课程名称, 学分)；选课关系：SelectCourse(学号, 课程名称, 成绩)。这样的数据库表是符合第二范式的，消除了数据冗余、更新异常、插入异常和删除异常。此外，所有单核心字的数据库表都符合第二范式，由于不也许存在组合核心字。第三范式（3NF）：在第二范式的基本上，数据表中如果不存在非核心字段对任一候选核心字段的传递函数依赖则符合第三范式。所谓传递函数依赖，指的是如果存在A B C的决定关系，则C传递函数依赖于A。因此，满足第三
5、范式的数据库表应当不存在如下依赖关系：核心字段 非核心字段x 非核心字段y假定学生关系表为Student(学号, 姓名, 年龄, 所在学院, 学院地点, 学院电话)，核心字为单一核心字学号，由于存在如下决定关系：(学号) (姓名, 年龄, 所在学院, 学院地点, 学院电话) 这个数据库是符合2NF的，但是不符合3NF，由于存在如下决定关系：(学号) (所在学院) (学院地点, 学院电话)即存在非核心字段学院地点、学院电话对核心字段学号的传递函数依赖。它也会存在数据冗余、更新异常、插入异常(增长新的学院)和删除异常的状况，读者可自行分析得知。把学生关系表分为如下两个表：学生：(学号, 姓名, 年
6、龄, 所在学院)；学院：(学院, 地点, 电话)。这样的数据库表是符合第三范式的，消除了数据冗余、更新异常、插入异常和删除异常。范式应用我们来逐渐搞定一种论坛的数据库，有如下信息：（1） 顾客：顾客名，email，主页，电话，联系地址（2） 帖子：发帖标题，发帖内容，答复标题，答复内容 第一次我们将数据库设计为仅仅存在表： 顾客名 email 主页 电话 联系地址 发帖标题 发帖内容 答复标题 答复内容 这个数据库表符合第一范式，但是没有任何一组候选核心字能决定数据库表的整行，唯一的核心字段顾客名也不能完全决定整个元组。我们需要增长发帖ID、答复ID字段，即将表修改为：顾客名 email 主页
7、 电话 联系地址 发帖ID 发帖标题 发帖内容 答复ID 答复标题 答复内容 这样数据表中的核心字(顾客名，发帖ID，答复ID)能决定整行：(顾客名,发帖ID,答复ID) (email,主页,电话,联系地址,发帖标题,发帖内容,答复标题,答复内容)但是，这样的设计不符合第二范式，由于存在如下决定关系：(顾客名) (email,主页,电话,联系地址)(发帖ID) (发帖标题,发帖内容)(答复ID) (答复标题,答复内容)即非核心字段部分函数依赖于候选核心字段，很明显，这个设计会导致大量的数据冗余和操作异常。我们将数据库表分解（1） 顾客信息：顾客名，email，主页，电话，联系地址（2） 帖子信
8、息：发帖ID，标题，内容（3） 答复信息：答复ID，标题，内容（4） 发贴：顾客名，发帖ID（5） 答复：发帖ID，答复ID这样的设计是满足第1、2、3范式规定的，但是这样的设计是不是最佳的呢？不一定。观测可知，第4项发帖中的顾客名和发帖ID之间是1：N的关系，因此我们可以把发帖合并到第2项的帖子信息中；第5项答复中的发帖ID和答复ID之间也是1：N的关系，因此我们可以把答复合并到第3项的答复信息中。这样可以一定量地减少数据冗余，新的设计为： （1） 顾客信息：顾客名，email，主页，电话，联系地址（2） 帖子信息：顾客名，发帖ID，标题，内容（3） 答复信息：发帖ID，答复ID，标题，内容
9、数据库表1显然满足所有范式的规定；数据库表2中存在非核心字段标题、内容对核心字段发帖ID的部分函数依赖，即不满足第二范式的规定，但是这一设计并不会导致数据冗余和操作异常；数据库表3中也存在非核心字段标题、内容对核心字段答复ID的部分函数依赖，也不满足第二范式的规定，但是与数据库表2相似，这一设计也不会导致数据冗余和操作异常。由此可以看出，并不一定要强行满足范式的规定，对于1：N关系，当1的一边合并到N的那边后，N的那边就不再满足第二范式了，但是这种设计反而比较好！结论满足范式规定的数据库设计是构造清晰的，同步可避免数据冗余和操作异常。这并意味着不符合范式规定的设计一定是错误的，在数据库表中存在1：N关系这种较特殊的状况下，合并导致的不符合范式规定反而是合理的。在我们设计数据库的时候，一定要时刻考虑范式的规定。
