数据库范式1NF 2NF 3NF BCNF(实例)

计划范式(范式, 数据库计划范式,数据库的计划范式)是切合某一种级别的相干模式的聚拢。布局数据库必需服从 肯定 的正直。在相干数据库中,这种正直就是范式。相干数据库中 的相干必需满意肯定 的哀求 ,即满意差别 的范式。如今相干数据库有六种范式:第一范式(1NF)、第二范式(2NF)、第三范式(3NF)、第四范式 (4NF)、第五范式(5NF)和第六范式(6NF)。满意最低哀求 的范式是第一范式(1NF)。在第一范式的根本 上进一步满意更多哀求 的称为第二范式 (2NF),别的范式以次类推。一样平常说来,数据库只需满意第三范式(3NF)就行了。下面我们举例先容第一范式(1NF)、第二范式(2NF)和第三范式 (3NF)。 在创建 一个数据库的过程中,范化是将其转化为一些表的过程,这种行动 可以使从数据库得到的结果越发明了。如许也许使数据库发生频频数据,从而导致创建 过剩的表。范化是在识别数据库中的数据元素、相干,以及界说所需的表和各表中的项目这些初始事变 之后的一个细化的过程。 下面是范化的一个例子 Customer Item purchased Purchase price Thomas Shirt $40 Maria Tennis shoes $35 Evelyn Shirt $40 Pajaro Trousers $25 假如上面这个表用于生涯物品的价值 ,而你想要删除此中的一个顾主,这时你就必需同时删除一个价值 。范化就是要办理这个题目,你可以将这个表化为两个表,一 个用于存储每个顾主和他所买物品的信息,另一个用于存储每件产物和其价值 的信息,如许对此中一个表做添加或删除操纵就不会影响另一个表。 相干数据库的几种计划范式先容 1 第一范式(1NF) 在任何一个相干数据库中,第一范式(1NF)是对相干模式的根本 哀求 ,不满意第一范式(1NF)的数据库就不是相干数据库。 所谓第一范式(1NF)是指数据库表的每一列都是不可支解的根本 数据项,同一列中不能有多个值,即实体中的某个属性不能有多个值可能不能有频频的属性。如 果出现频频的属性,就也许必要 界说一个新的实体,新的实体由频频的属性构成 ,新实体与原实体之间为一对多相干。在第一范式(1NF)中表的每一行只包孕一 个实例的信息。譬喻,对付图3-2 中的员工信息表,不能将员工信息都放在一列中表现,也不能将此中的两列或多列在一列中表现;员工信息表的每一行只表示一个员工的信息,一个员工的信息在表 中只出现一次。简而言之,第一范式就是无频频的列。 2 第二范式(2NF) 第二范式(2NF)是在第一范式(1NF)的根本 上成立起来的,即满意第二范式(2NF)必需先满意第一范式(1NF)。第二范式(2NF)哀求 数据库表中的每个实例或行必需可以被惟一区域 分。为实现区分通常必要 为表加上一个列,以存储各个实例的惟一标识。如图3-2 员工信息表中加上了员工编号(emp_id)列,由于每个员工的员工编号是惟一的,因此每个员工可以被惟一区分。这个惟一属性列被称为首关键字或主键、主码。 第二范式(2NF)哀求 实体的属性完备 凭借于首关键字。所谓完备 凭借是指不能存在仅凭借首关键字一部分 的属性,假如存在,那么这个属性和首关键字的这一部 分应当星散出来形成一个新的实体,新实体与原实体之间是一对多的相干。为实现区分通常必要 为表加上一个列,以存储各个实例的惟一标识。简而言之,第二范式 就黑白主属性非部分 凭借于首关键字。 3 第三范式(3NF) 满意第三范式(3NF)必需先满意第二范式(2NF)。简而言之,第三范式(3NF)哀求 一个数据库表中不包孕已在其余表中已包孕的非首关键字信息。例 如,存在一个部分信息表,此中每个部分有部分编号(dept_id)、部分名称、部分简介等信息。那么在图3-2的员工信息表中列出部分编号后就不能再将 部分名称、部分简介等与部分有关的信息再介入员工信息表中。假如不存在部分信息表,则按照第三范式(3NF)也应当构建它,不然就会有大宗的数据冗余。简 而言之,第三范式就是属性不凭借于其余非主属性。 数据库计划三大范式操纵实例阐明 数据库的计划范式是数据库计划所必要 满意的类型,满意这些类型的数据库是简捷 的、结构明了的,同时,不会发生插入(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) 用户:用户名,email,主页,电话,联系所在 (2) 帖子:发帖问题,发帖内容,中兴问题,中兴内容 第一次我们将数据库计划为仅仅存在表:    这个数据库表切合第一范式,但是没有任何一组候选关键字能决议 数据库表的整行,唯一的关键字段用户名也不能完备 决议 所有元组。我们必要 增进"发帖ID"、"中兴ID"字段,即将表批改为: 如许数据表中的关键字(用户名,发帖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相干这种较出格的情况下,归并导致的不切合范式哀求 反而是公道的。 在我们计划数据库的时间,肯定 要时候思量 范式的哀求 。 转自

  • 1
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 1
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值