请求处理中...
请求处理中...
很多人对于数据库设计实例大多都停留在大学教材上面那些枯燥的数值，那一大堆的数学公式谁也看不懂，当然也记不住，但是很多人设计数据库并不是根据那些公式和规范来设计的，设计范式对于我们来说太难懂也太难记了，所以今天小编就是要将设计范式给简单化了，通过一些例子来简单举例，让大家都能明白就是小编今天的目的。
数据库的设计范式是数据库设计所需要满足的规范，满足这些规范的数据库是简洁的、结构明晰的，同时，不会发生插入（insert）、删除（delete）和更新（update）操作异常。反之则是乱七八糟，不仅给数据库的编程人员制造麻烦，而且面目可憎，可能存储了大量不需要的冗余信息。
实质上，设计范式用很形象、很简洁的话语就能说清楚，道明白。本文将对范式进行通俗地说明，并以笔者曾经设计的一个简单论坛的数据库为例来讲解怎样将这些范式应用于实际工程。
范式说明
第一范式（1NF）：数据库表中的字段都是单一属性的，不可再分。这个单一属性由基本类型构成，包括整型、实数、字符型、逻辑型、日期型等。
很显然，在当前的任何关系数据库管理系统（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：1或1：N关系这种较特殊的情况下，合并导致的不符合范式要求反而是合理的。
看完上面小编给大家介绍的数据库设计实例范式设计说明不知道大家对于这个设计范式有没有记得更劳了，教材终归是教材，大家不能对教材上的东西死记硬背，这样到头来只会变成书呆子，只有将教材学或才能做到学以致用。当然了后面的事情就得靠大家自己了。
交易额: 110.67万元
无 |浙江省 |温州市 |瓯海区
交易额: 101.38万元
无 |广东省 |东莞市 |东莞市
交易额: 78.68万元
工作室 |山东省 |潍坊市 |奎文区
交易额: 47.41万元
公司 |广东省 |深圳市 |福田区
成为一品威客服务商，百万订单等您来有奖注册中
价格是多少？怎样找到合适的人才？
￥2800 已有76人投标
￥1000 已有4人投标
￥500 已有4人投标
￥100 已有3人投标
￥2000 已有0人投标
￥1000 已有6人投标
￥100 已有1人投标
￥600 已有42人投标
企业QQ
智能客服
