数据库设计三大范式应用实例剖析.pdf

数据库设计三大范式应用实例剖析引言数据库的设计范式是数据库设计所需要满足的标准，满足这些标准的数据库是简洁的、结构明晰的，同时，不会发生插入insert 、删除delete和更新update操作异常。反之则是乱七八糟，不仅给数据库的编程人员制造麻烦， 而且面目可憎，可能存储了大量不需要的冗余信息。设计范式是不是很难懂呢？非也， 大学教材上给我们一堆数学公式我们当然看不懂， 也记不住。所以我们很多人就根本不按照范式来设计数据库。实质上，设计范式用很形象、很简洁的话语就能说清楚， 道明白。本文将对范式进行通俗地说明， 并以笔者曾经设计的一个简单论坛的数据库为例来讲解怎样将这些范式应用于实际工程。范式说明第一范式1NF ：数据库表中的字段都是单一属性的，不可再分。这个单一属性由基本类型构成，包括整型、实数、字符型、逻辑型、日期型等。例如，如下的数据库表是符合第一范式的：字段 1字段 2字段 3字段 4而这样的数据库表是不符合第一范式的：字段 1字段 2字段 3字段 3.2字段 4很显然，在当前的任何关系数据库管理系统 DBMS中，傻瓜也不可能做出不符合第一范式的数据库，因为这些 DBMS 不允许你把数据库表的一列再分成二列或多列。因此，你想在现有的 DBMS 中设计出不符合第一范式的数据库都是不可能的。第二范式2NF ：数据库表中不存在非关键字段对任一候选关键字段的部分函数依赖部分函数依赖指的是存在组合关键字中的某些字段决定非关键字段的情况 ，也即所有非关键字段都完全依赖于任意一组候选关键字。假定选课关系表为 SelectCourse(学号, , 年龄, 课程名称, 成绩, 学分)，关键字为组合关键字(学号, 课程名称)，因为存在如下决定关系：(学号, 课程名称) (, 年龄, 成绩, 学分)这个数据库表不满足第二范式，因为存在如下决定关系：(课程名称) (学分)(学号) (, 年龄)即存在组合关键字中的字段决定非关键字的情况。由于不符合 2NF，这个选课关系表会存在如下问题：(1) 数据冗余：同一门课程由 n 个学生选修，学分就重复 n-1 次；同一个学生选修了 m 门课程，和年龄就重复了 m-1 次。(2) 更新异常：假设调整了某门课程的学分， 数据表中所有行的学分值都要更新，否则会出现同一门课程学分不同的情况。(3) 插入异常：假设要开设一门新的课程，暂时还没有人选修。这样，由于还没有 学号关键字，课程名称和学分也无法记录入数据库。(4) 删除异常：假设一批学生已经完成课程的选修， 这些选修记录就应该从数据库表中删除。 但是，与此同时，课程名称和学分信息也被删除了。很显然，这也会导致插入异常。把选课关系表 SelectCourse 改为如下三个表：学生：Student(学号, , 年龄)；课程：Course(课程名称, 学分)；选课关系：SelectCourse(学号, 课程名称, 成绩)。这样的数据库表是符合第二范式的， 消除了数据冗余、 更新异常、 插入异常和删除异常。另外，所有单关键字的数据库表都符合第二范式，因为不可能存在组合关键字。第三范式3NF ：在第二范式的基础上，数据表中如果不存在非关键字段对任一候选关键字段的传递函数依赖则符合第三范式。 所谓传递函数依赖， 指的是如果存在A B C的决定关系，则 C 传递函数依赖于 A。因此，满足第三范式的数据库表应该不存在如下依赖关系：关键字段 非关键字段 x 非关键字段 y假定学生关系表为 Student(学号, , 年龄, 所在学院, 学院地点, 学院)， 关键字为单一关键字学号，因为存在如下决定关系：(学号) (, 年龄, 所在学院, 学院地点, 学院)这个数据库是符合 2NF 的，但是不符合 3NF，因为存在如下决定关系：(学号) (所在学院) (学院地点, 学院)即存在非关键字段学院地点、学院对关键字段学号的传递函数依赖。它也会存在数据冗余、更新异常、插入异常和删除异常的情况，读者可自行分析得知。把学生关系表分为如下两个表：学生：(学号, , 年龄, 所在学院)；学院：(学院, 地点,)。这样的数据库表是符合第三范式的， 消除了数据冗余、 更新异常、 插入异常和删除异常。鲍依斯-科得范式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 发贴：用户名，发帖 ID5 回复：发帖 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 关系这种较特殊的情况下，合并导致的不符合范式要求反而是合理的。在我们设计数据库的时候，一定要时刻考虑范式的要求。