在数据库的建立过程中需要考虑很多规则&＃xff0c;一个良好的数据库设计不但要节省数据的存储空间&＃xff0c;方便进行数据库应用程序的开发&＃xff0c;而且能够保证数据的完整性。定义一个良好的数据库需要这么多的规则&＃xff0c;那我们设计时岂不更让人头疼。所以为了能够建立一个好的数据库在开发时就必须保证数据库的规范化——三大范式。
数据库三范式 为了建立冗余较小&＃xff0c;结构合理的数据库&＃xff0c;在设计时必须遵循一定的规则。在关系数据库中这些规则简称为数据库的范式。Dr E.F.codd 最初定义了规范化的是三个级别&＃xff0c;这些范式是&＃xff1a;
第一范式&＃xff08;1st NF&＃xff09;
第二范式&＃xff08;2nd NF&＃xff09;
第三范式&＃xff08;3rd NF)
三范式间是层层递进的关系&＃xff0c;高层的范式要在符合底层范式的基础上设计。在进行数据库设计时应该根据三层范式层层递进&＃xff0c;一个好的数据库一定遵守三范式&＃xff0c;但由三范式设计出的数据库不一定是最好的&＃xff0c;但范式是具有最小冗余的表结构。
第一范式&＃xff1a;
最基本的范式&＃xff0c;确保每列都是不可再分的最小单元。在设计时比较简单。
第一范式的设计需要根据系统的设计需求来定。如&＃xff1a;在某些数据库系统中需要用到“时间”这个属性&＃xff0c;本来直接将“时间”这个属性设计成一个数据库表的字段就行&＃xff0c;但是如果系统经常会访问“时间”属性中的“年”部分&＃xff0c;那么就要将“时间”这个属性重新拆分为年、月、日、时等多个部分进行存储&＃xff0c;这样在对地址中某一部分操作的时候将非常。
| 学号
| 课程名称
| 姓名 | 年龄 | 成绩 | 学分 |
| 1 | 数学 | 韩某 | 23 | 77 | 4 |
| 2 | 英语 | 张某 | 22 | 70 | 3 |
第二范式&＃xff1a;
首先要满足第一范式。数据库表中不存在非关键字段对任意候选关键字段的部分依赖&＃xff08;主要针对联合主键而言&＃xff09;&＃xff0c;需要确保数据库表中的每一列都和主键相关。
如&＃xff1a;假定下表为选课关系表&＃xff0c;其中学号和课程名称为组合关键字。
上面的表虽然看起来很整齐&＃xff0c;但是却不满足第二范式&＃xff0c;因为存在如下的部分依赖关系&＃xff1a;
&＃xff08;课程名称&＃xff09;-->&＃xff08;学分&＃xff09;
&＃xff08;学号&＃xff09;-->&＃xff08;姓名&＃xff0c;年龄&＃xff09;
即存在非关键字段对其中某一关键字段的部分依赖关系。
由于不符合2NF&＃xff0c;这个选课关系表在使用时会导致数据冗余、更新异常等情况。
在设计时我们应尽量避免使用组合关键字&＃xff0c;因为&＃xff0c;所有但关键字的数据库表都符合第二范式&＃xff0c;因为不可能存在组合关键字。
第三范式&＃xff1a;
首先要符合第二范式&＃xff0c;数据表中不存在非关键字段对任意候选关键字段的传递函数依赖。即不存在"A → B → C"的决定关系。每一列数据都和主键直接相关&＃xff0c;而不能间接相关。
假定学生关系表为(学号, 姓名, 年龄, 所在学院, 学院地点, 学院电话)&＃xff0c;关键字为单一关键字"学号"&＃xff0c;因为存在如下决定关系&＃xff1a;
(学号) → (姓名, 年龄, 所在学院, 学院地点, 学院电话)
这个数据库是符合2NF的&＃xff0c;但是不符合3NF&＃xff0c;因为存在如下决定关系&＃xff1a;
(学号) → (所在学院) → (学院地点, 学院电话)
即存在非关键字段"学院地点"、"学院电话"对关键字段"学号"的传递函数依赖。
这时应把学生关系表分为如下两表&＃xff1a;
学生&＃xff1a;(学号, 姓名, 年龄, 所在学院)&＃xff1b;
学院&＃xff1a;(学院, 地点, 电话)。
BCNF&＃xff08;鲍依斯-科得范式&＃xff09;
在第三范式的基础上&＃xff0c;数据库表中如果不存在任何字段对任一候选关键字段的传递函数依赖则符合BC范式。它较多考虑的是在组合主键中&＃xff0c;两个主键之间的关系。因为经过第三范式设计后&＃xff0c;已经基本上没有了非主属性对候选关键字的传递依赖。但第三范式并没有考虑候选关键字之间的关系。
假设仓库管理关系表为(仓库ID, 存储物品ID, 管理员ID, 数量)&＃xff0c;且有一个管理员只在一个仓库工作&＃xff1b;一个仓库可以存储多种物品。这个数据库表中存在如下决定关系&＃xff1a;
(仓库ID, 存储物品ID) →(管理员ID, 数量)
(管理员ID, 存储物品ID) → (仓库ID, 数量)
所以&＃xff0c;(仓库ID, 存储物品ID)和(管理员ID, 存储物品ID)都是仓库管理关系表的候选关键字&＃xff0c;表中的唯一非关键字段为数量&＃xff0c;它是符合第三范式的。但是&＃xff0c;由于存在如下决定关系&＃xff1a;
(仓库ID) → (管理员ID)
(管理员ID) → (仓库ID)
即存在关键字段决定关键字段的情况&＃xff0c;所以其不符合BCNF范式。
它会出现如下异常情况&＃xff1a;
(1) 删除异常&＃xff1a;
当仓库被清空后&＃xff0c;所有"存储物品ID"和"数量"信息被删除的同时&＃xff0c;"仓库ID"和"管理员ID"信息也被删除了。
(2) 插入异常&＃xff1a;
当仓库没有存储任何物品时&＃xff0c;无法给仓库分配管理员。
(3) 更新异常&＃xff1a;
如果仓库换了管理员&＃xff0c;则表中所有行的管理员ID都要修改。
把仓库管理关系表分解为二个关系表&＃xff1a;
仓库管理&＃xff1a;StorehouseManage(仓库ID, 管理员ID)&＃xff1b;
仓库&＃xff1a;Storehouse(仓库ID, 存储物品ID, 数量)。
这样的数据库表是符合BCNF范式的&＃xff0c;消除了删除异常、插入异常和更新异常。
三范式是最初的数据库设计规则&＃xff0c;它是为了避免数据的冗余&＃xff0c;但是越较多应用范式那么分出的表就越多&＃xff0c;这无形中就又会造成数据的冗余&＃xff0c;所以范式只是规定了一个标准&＃xff0c;但并不是最准确的。在使用范式时要看情况&＃xff0c;有些冗余也是需要的。
总结&＃xff1a;
其实简单的说三范式是数据库设计中最基础的规则&＃xff0c;第一范式不需要我们考虑太多&＃xff0c;因为关系数据库已经帮我们控制好了&＃xff1b;第二范式&＃xff0c;就是要有主键&＃xff0c;其他属性都要依赖于这个主键&＃xff0c;再设计时尽量避免组合的主键&＃xff0c;组合主键常常违背第二范式&＃xff1b;第三范式&＃xff0c;就是不能有冗余&＃xff0c;一张表&＃xff0c;只能有主键&＃xff0c;依赖主键的属性&＃xff0c;外键&＃xff0c;不能包含外键表的非主键属性。
京公网安备 11010802041100号 | 京ICP备19059560号-4 | PHP1.CN 第一PHP社区 版权所有