数据库设计三大范式应用实例剖析2
来源:百度文库 编辑:神马文学网 时间:2024/04/28 11:27:42
假设仓库管理关系表为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) 帖子:发帖标题,发帖内容,回复标题,回复内容 第一次我们将数据库设计为仅仅存在表:
这样数据表中的关键字(用户名,发帖ID,回复ID)能决定整行: (用户名,发帖ID,回复ID) → (email,主页,电话,联系地址,发帖标题,发帖内容,回复标题,回复内容) 但是,这样的设计不符合第二范式,因为存在如下决定关系: (用户名) → (email,主页,电话,联系地址) (发帖ID) → (发帖标题,发帖内容) (回复ID) → (回复标题,回复内容) 即非关键字段部分函数依赖于候选关键字段,很明显,这个设计会导致大量的数据冗余和操作异常。 我们将数据库表分解为(带下划线的为关键字): (1) 用户信息:用户名,email,主页,电话,联系地址 (2) 帖子信息:发帖ID,标题,内容 (3) 回复信息:回复ID,标题,内容 (4) 发贴:用户名,发帖ID (5) 回复:发帖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关系这种较特殊的情况下,合并导致的不符合范式要求反而是合理的。
本篇文章来源于:开发学院 http://edu.codepub.com 原文链接:http://edu.codepub.com/2009/1215/18752_2.php
这样数据表中的关键字(用户名,发帖ID,回复ID)能决定整行: (用户名,发帖ID,回复ID) → (email,主页,电话,联系地址,发帖标题,发帖内容,回复标题,回复内容) 但是,这样的设计不符合第二范式,因为存在如下决定关系: (用户名) → (email,主页,电话,联系地址) (发帖ID) → (发帖标题,发帖内容) (回复ID) → (回复标题,回复内容) 即非关键字段部分函数依赖于候选关键字段,很明显,这个设计会导致大量的数据冗余和操作异常。 我们将数据库表分解为(带下划线的为关键字): (1) 用户信息:用户名,email,主页,电话,联系地址 (2) 帖子信息:发帖ID,标题,内容 (3) 回复信息:回复ID,标题,内容 (4) 发贴:用户名,发帖ID (5) 回复:发帖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关系这种较特殊的情况下,合并导致的不符合范式要求反而是合理的。
本篇文章来源于:开发学院 http://edu.codepub.com 原文链接:http://edu.codepub.com/2009/1215/18752_2.php
数据库设计三大范式应用实例剖析2
数据库设计三大范式应用实例剖析
数据库设计三大范式应用实例剖析1
数据库设计范式应用实例剖析
数据库设计范式深入浅出
数据库范式
数据库设计之“有时不得不违背的第三范式”
关系型数据库设计范式 - 舞步者 - 博客园
我对关系型数据库设计范式的理解
数据库设计指南(三)
数据库关系范式
数据库关系范式
数据库范式 相关复习
数据库设计之“有时不得不违背的第三范式” - 听棠.NET - 博客园
关系型数据库(范式) - - BlogJava
数据库设计
数据库设计
SVG入门,SVG实例,SVG教程与设计,SVG应用
JS连接数据库“实例”
实例应用
Sawin软件研发之窗:数据库设计经验谈(三)
Sawin软件研发之窗:数据库设计经验谈(三)
Sawin软件研发之窗:数据库设计经验谈(三)
尚主席新闻发布会三大看点剖析