数据库设计三大范式应用实例分析,数据库范式

  1. 先是范式(1NF):元组的轻重不可再分;

  2.  第贰范式(2NF):全部分量唯一决定主键码,不容许一些依赖;

  3. 其三范式(3NF):不容许传递依赖。

  4. Bath-科德范式(BCNF)

  5. 第五范式(4NF)
  6. 第伍范式(5NF,又称完美范式)。

  7. 先是范式(1NF)

**引言

基础概念:重要字、主关键字、候选关键字,非关键字

数据库的筹划范式是数据库设计所急需满意的正规化,满意这几个专业的数据库是不难的、结构明晰的,同时,不会发生插入(insert)、删除(delete)和换代(update)操作10分。反之则是乌烟瘴气,不仅给数据库的编制程序职员创立麻烦,而且精神可憎,恐怕存储了大气不须要的冗余消息。

      强调的是列的原子性,即列不可见再分为其余几列。 
      考虑这样一个表:【联系人】(姓名,性别,电话) 
     
要是在其实情况中,二个关联人有家庭电话和集团电话,那么那种表结构划设想计就从未达到
1NF。要顺应 1NF
大家只需把列(电话)拆分,即:【联系人】(姓名,性别,家庭电话,公司电话)。1NF
很好辨认,然则 2NF 和 3NF 就便于搞混淆。

**  数据库的布署性范式是数据库设计所急需知足的正规化,满意那一个专业的数据库是简单的、结构明晰的,同时,不会发出插入(insert)、删除(delete)和更新(update)操作十三分。反之则是乌烟瘴气,不仅给数据库的编制程序职员创制麻烦,而且精神可憎,恐怕存款和储蓄了大气不供给的冗余音讯。

假使有个别字段或多个字段的值能够唯一地方统一标准识一条记下,则该字段或字段组就称为关键字
假定1个首要字是用以标识每条记下的唯一性,并视作该表与此外表达成关系之用,则称其为主关键字(主键,primary
key)或主码

除主关键字以外的别的重要字称呼候选关键字

 

2.次之范式( 2NF )

  设计范式是或不是很难懂吗?非也,大学教材上给大家一堆数学公式大家自然看不懂,也记不住。所以我们广大人就一向不服从范式来规划数据库。

除重点字意外的字称为非关键字

范式表达

     
所谓第①范式,是指具有的非主属性都统统依赖于重点字。从那几个概念能够观看,第③范式不存在非主属性对于部分候选关键字的有些依赖,可是允许非主属性之间存在着传递信赖。

  实质上,设计范式用很形象、很不难的言辞就能说理解,道驾驭。本文将对范式实行开端地证实,并以作者曾经设计的1个简练论坛的数据库为例来讲解怎么着将那几个范式应用于实际工程。

比如说,有三个表字段为:
id  firstname lastname address phone IDcard
这就是说id或IDcard或firstname+lastname(不设有同名的情事下)都足以说是首要字。
其中id为主关键字,IDcard和firstname+lastname为候选关键字。

 

      上面是第叁范式的优化实例:

  范式表达

数据库设计范式

1.1 第3范式(1NF)无重复的列

     
假定选课关系表为SelectCourse(学号,姓名,年龄,课程名称,成绩,学分),关键字为组合关键字(学号,课程名称),因为存在如下决定涉及:

  第叁范式(1NF):数据库表中的字段皆以单一属性的,不可再分。这几个单一属性由基本项目构成,蕴涵整型、实数、字符型、逻辑型、日期型等。

首先范式(1NF):数据表中的字都以单一属性,不可再分的(原子性)。单一属性由中央类型构成,包括整型、实数、字符型、逻辑型、日期型等。

 

  (学号,课程名称) → (姓名,年龄,战绩,学分)

  例如,如下的数据库表是顺应第叁范式的:

在其他一个关周详据库中,第2范式(1NF)是对关系模式的骨干必要,不满足第叁范式(1NF)的数据库就不是关全面据库。

    所谓第叁范式(1NF)是指多少库表的每一列都以不可分割的基本数据项,同一列中无法有多个值,即实体中的某些属性不能够有多个值大概不能够有再次的性质。假若出现重复的习性,就也许供给定义二个新的实体,新的实体由重复的属性构成,新实体与原实体之间为一对多涉及。在首先范式(1NF)中表的每一行只含有三个实例的音信。简单的说,第②范式便是无重复的列。

数据库设计三大范式应用实例分析,数据库范式。  这些数据库表不满意第2范式,因为存在如下决定涉及:

字段1 字段2 字段3 字段4
       

第①范式(2NF):数据表中国和亚洲关键字都不存在对候选关键字的局地函数依赖(部分函数信赖指的是存在组合关键字中的有些字段决定非关键字段的场馆),则吻合第3范式(完全依靠于主键),也即具备非关键字段都统统依赖于自由一组候选关键字。

 

  (课程名称) → (学分)

  而那样的数据库表是不吻合第贰范式的:

例:设若选课关系表为SelectCourse(学号, 姓名, 年龄, 课程名称, 战绩,
学分),关键字为组合关键字(学号, 课程名称),因为存在如下决定涉及:

表达:在任何二个关周详据库中,第②范式(1NF)是对涉及情势的中坚要求,不满足第②范式(1NF)的数据库就不是关全面据库。

  (学号) → (姓名,年龄)

字段1

  (学号, 课程名称) → (姓名, 年龄, 战绩, 学分)

 

  即存在组合关键字中的字段决定非关键字的地方。

字段2

  那一个数据库表不满意第2范式,因为存在如下决定涉及:

譬如,如下的数目库表是吻合第③范式的:

  由于不符合2NF,那几个选课关系表会存在如下难点:

字段3

  (课程名称) → (学分)

 

  (1) 数据冗余:

字段4

  (学号) → (姓名, 年龄)

 

  同一门科目由n个学生选修,”学分”就重新n-3遍;同三个学生选修了m门课程,姓名和年龄就再一次了m-一次。

 

  即存在组合关键字中的字段决定非关键字的事态。

字段1

字段2

字段3

字段4

  (2) 更新11分:

 

  由于不符合2NF,这么些选课关系表会存在如下难题:

 

  若调整了某门课程的学分,数据表中全数行的”学分”值都要立异,不然会油但是生同样门学科学分差别的情状。

字段3.1

  (1) 数据冗余:

而那般的数据库表是不相符第1范式的:

  (3) 插入卓殊:

字段3.2

  同一门科目由n个学生选修,”学分”就再度n-3次;同3个学童选修了m门课程,姓名和年龄就重新了m-一回。

 

  若是要开办一门新的课程,近年来还从未人选修。那样,由于还尚未”学号”关键字,课程名称和学分也不知所可记录入数据库。

 

  (2) 更新格外:

 

  (4) 删除卓殊:

  很肯定,在此时此刻的其余关全面据库管理体系(DBMS)中,傻瓜也不恐怕做出不符合第叁范式的数据库,因为那一个DBMS不允许你把多少库表的一列再分为二列或多列。因而,你想在存活的DBMS中安顿出不切合第贰范式的数据库都以不容许的。

  若调整了某门课程的学分,数据表中全数行的”学分”值都要更新,不然会见世同样门科目学分分化的图景。

字段1

字段2

字段3

字段4

 

 

字段3.1

字段3.2

 

         

  假诺一批学员已经到位课程的选修,那几个选修记录就应有从数据库表中删除。然而,与此同时,课程名称和学分消息也被去除了。很明朗,那也会促成插入十分。

  第2范式(2NF):数据库表中不存在非关键字段对任一候选关键字段的有个别函数注重(部分函数重视指的是存在组合关键字中的有个别字段决定非关键字段的境况),也即怀有非关键字段都完全依靠于自由一组候选关键字。

  (3) 插入十分:

 

  把选课关系表SelectCourse改为如下多个表:

  假定选课关系表为SelectCourse(学号, 姓名, 年龄, 课程名称, 战表,
学分),关键字为组合关键字(学号, 课程名称),因为存在如下决定涉及:

  固然要设置一门新的科目,暂时还并未人选修。那样,由于还尚无”学号”关键字,课程名称和学分也无力回天记录入数据库。

数据库表中的字段都以单一属性的,不可再分。这一个单一属性由宗旨类型构成,包括整型、实数、字符型、逻辑型、日期型等。很显然,在方今的别的关全面据库管理体系(DBMS)中,傻瓜也不恐怕做出不切合第③范式的数据库,因为那个DBMS不容许你把数据库表的一列再分为二列或多列。由此,你想在存活的DBMS中执会调查计算局筹出不吻合第二范式的数据库都以不容许的。

  学生:Student(学号,姓名,年龄);

  (学号, 课程名称) → (姓名, 年龄, 成绩, 学分)

  (4) 删除很是:

997755.com澳门葡京 , 

  课程:Course(课程名称,学分);

  这一个数据库表不知足第③范式,因为存在如下决定涉及:

  假如一批学生早已完成课程的选修,那几个选修记录就相应从数据库表中删除。可是,与此同时,课程名称和学分音信也被剔除了。很显明,那也会促成插入分外。 

1.2 第一范式(2NF)属性完全重视于主键 [ 消除部分子函数正视 ]

  选课关系:SelectCourse(学号,课程名称,战绩)。

  (课程名称) → (学分)

  把选课关系表SelectCourse改为如下多个表:

 

  那样的数目库表是适合第③范式的,
消除了数量冗余、更新非凡、插入极度和删除格外。

  (学号) → (姓名, 年龄)

  学生:Student(学号, 姓名, 年龄);

若果涉嫌格局PAJERO为第2范式,并且凯雷德中每1个非主属性完全函数重视于Sportage的有个别候选键, 则称为第2范式方式。

  别的,全部单关键字的数据库表都符合第贰范式,因为十分小概存在组合关键字。

  即存在组合关键字中的字段决定非关键字的意况。

  课程:Course(课程名称, 学分);

第1范式(2NF)是在首先范式(1NF)的底子上创立起来的,即满意第壹范式(2NF)必须先满意第壹范式(1NF)。第叁范式(2NF)须要数据库表中的种种实例或行必须能够被惟一地有别于。为贯彻区分平日必要为表加上一个列,以存款和储蓄各样实例的惟一标识。这么些惟一属性列被号称主关键字或主键、主码。

③ 、第二范式(3NF)

  由于不吻合2NF,那些选课关系表会存在如下问题:

  选课关系:SelectCourse(学号, 课程名称, 战表)。

 

     
所谓第一范式,是指每3个非主属性既不有的依赖于也不传递依赖于重点字,也正是在其次范式的基本功上革除传递重视(A>B>C)。

  (1) 数据冗余:

  那样的多少库表是契合第3范式的,化解了数额冗余、更新万分、插入卓殊和删除分外。

诸如职员和工人信息表中丰富了职工编号(emp_id)列,因为种种职员和工人的员工编号是惟一的,因而种种职工可以被惟一区分。

     
假定学生关系表为Student(学号,姓名,年龄,所在大学,高校地方,大学电话),关键字为单纯关键字”学号”,因为存在如下决定涉及:

  同一门学科由n个学生选修,”学分”就再度n-三回;同3个学员选修了m门课程,姓名和年龄就重新了m-二回。

  此外,全数单关键字的数据库表都符合第叁范式,因为不容许存在组合关键字。

简言之,第一范式(2NF)便是非主属性完全依靠于主关键字。

  (学号) → (姓名,年龄,所在大学,高校地方,高校电话)

  (2) 更新格外:

其三范式(3NF):在第1范式的底子上,任何非关键字段对私行一候选关键字存在传递函数注重,则吻合第叁范式(不注重于别的非主属性)。所谓传递函数正视,指的是一旦存在”A →
B →
C”的主宰涉及,则C传递函数注重于A。因而,满意第贰范式的数码库表应该不设有如下正视关系:关键字段
→ 非关键字段x → 非关键字段y

 

  那些数据库是吻合2NF的,可是不合乎3NF,因为存在如下决定涉及:

  若调整了某门课程的学分,数据表中全体行的”学分”值都要翻新,不然会出现相同门课程学分区别的情状。

例:如若学生关系表为Student(学号, 姓名, 年龄, 所在大学, 高校地方,
高校电话),关键字为单纯关键字”学号”,因为存在如下决定涉及:

所谓完全注重是指不能够存在仅凭借主关键字一部分的习性(设有函数依赖W→A,若存在XW,有X→A创建,那么称W→A是局部依赖,不然就称W→A是一点一滴函数正视)。借使存在,那么这天性情和主关键字的这一部分应该分离出来形成二个新的实业,新实体与原实体之间是一对多的关系。

  (学号) → (所在高校) → (高校地方,高校电话)

  (3) 插入格外:

  (学号) → (姓名, 年龄, 所在高校, 大学地点, 高校电话)

 

  即存在非关键字段”高校地点”、”高校电话”对重庆大学字段”学号”的传递函数依赖。

  尽管要设立一门新的学科,一时还没有人选修。那样,由于还未曾”学号”关键字,课程名称和学分也无能为力记录入数据库。

  那么些数据库是切合2NF的,不过不适合3NF,因为存在如下决定涉及:

倘使选课关系表为SelectCourse(学号, 姓名, 年龄, 课程名称, 战表, 学分),关键字为组合关键字(学号, 课程名称),因为存在如下决定涉及:

  它也会存在数量冗余、更新非常、插入卓殊和删除很是的景况,读者可活动分析得知。

  (4) 删除卓殊:

  (学号) → (所在大学) → (大学地方, 大学电话)

 

  把学生关系表分为如下五个表:

  若是一批学生一度成功课程的选修,那一个选修记录就应当从数据库表中删除。然而,与此同时,课程名称和学分新闻也被删除了。很显眼,这也会招致插入分外。

  即存在非关键字段”高校地点”、”大学电话”对根本字段”学号”的传递函数注重。

(学号, 课程名称) → (姓名, 年龄, 成绩, 学分)

  学生:(学号,姓名,年龄,所在大学);

  把选课关系表SelectCourse改为如下八个表:

  它也会存在多少冗余、更新相当、插入十分和删除极度的处境,读者可自行分析得知。

以此数据库表不满意第一范式,因为存在如下决定涉及:

  学院:(学院,地点,电话)。

  学生:Student(学号, 姓名, 年龄);

  把学生关系表分为如下两个表:

 

  那样的数额库表是切合第③范式的,消除了数额冗余、更新万分、插入很是和删除相当。

  课程:Course(课程名称, 学分);

  学生:(学号, 姓名, 年龄, 所在大学);

(课程名称) → (学分)

参考:

  选课关系:SelectCourse(学号, 课程名称, 成绩)。

  学院:(学院, 地点, 电话)。

 

  那样的多寡库表是顺应第1范式的,消除了多少冗余、更新非凡、插入卓殊和删除十分。

  那样的数额库表是切合第3范式的,消除了多少冗余、更新相当、插入相当和删除相当。

(学号) → (姓名, 年龄)

  此外,全部单关键字的数据库表都符合第①范式,因为不容许存在组合关键字。

鲍依斯-科得范式(BCNF):在第二范式的基础上,数据表中不存在别的字段对任一候选关键字段的传递函数重视,则吻合鲍依斯-科得范式(BCNF)

 

  第叁范式(3NF):在第叁范式的基础上,数据表中一经不设有非关键字段对任一候选关键字段的传递函数正视则吻合第叁范式。所谓传递函数正视,指的是如若存在”A
→ B →
C”的决定涉及,则C传递函数正视于A。由此,满足第二范式的数量库表应该不存在如下依赖关系:

例:假诺仓库管理关系表为StorehouseManage(仓库ID, 存储物品ID,
管理员ID,
数量),且有叁个大班只在1个储藏室工作;1个仓库能够储存各类物品。这么些数据库表中设有如下决定涉及:

即存在组合关键字中的字段决定非关键字的意况。

  关键字段 → 非关键字段x → 非关键字段y

  (仓库ID, 存款和储蓄物品ID) →(管理员ID, 数量)

 

  假定学生关系表为Student(学号, 姓名, 年龄,
所在学院, 大学地方,
高校电话),关键字为单一关键字”学号”,因为存在如下决定涉及:

  (管理员ID, 存款和储蓄物品ID) → (仓库ID, 数量)

由于不合乎2NF,那么些选课关系表会存在如下难题:

  (学号) → (姓名, 年龄, 所在高校, 学院地方, 大学电话)

  所以,(仓库ID, 存款和储蓄物品ID)和(管理员ID,
存款和储蓄物品ID)都以StorehouseManage的候选关键字,表中的绝无仅有非关键字段为数量,它是切合第一范式的。不过,由于存在如下决定关
      系:

 

  那个数据库是吻合2NF的,不过不切合3NF,因为存在如下决定涉及:

  (仓库ID) → (管理员ID)

(1) 数据冗余:

  (学号) → (所在大学) → (大学地点, 高校电话)

  (管理员ID) → (仓库ID)

 

  即存在非关键字段”大学地方”、”高校电话”对关键字段”学号”的传递函数正视。

  即存在根本字段决定重庆大学字段的情况,所以其不相符BCNF范式。它会冒出如下很是情状:

如出一辙门学科由n个学生选修,”学分”就再次n-3次;同三个学员选修了m门课程,姓名和年龄就再一次了m-3次。

  它也会设有数量冗余、更新分外、插入很是和删除十分的景观,读者可活动分析得知。

  (1) 删除极度:

 

  把学生关系表分为如下五个表:

  当仓库被清空后,全体”存款和储蓄物品ID”和”数量”新闻被删除的还要,”仓库ID”和”管理员ID”新闻也被去除了。

(2) 更新非凡:

  学生:(学号, 姓名, 年龄, 所在大学);

  (2) 插入相当:

 

  学院:(学院, 地点, 电话)。

  当仓库没有存款和储蓄任何物品时,不可能给仓库分配管理员。

若调整了某门课程的学分,数据表中全数行的”学分”值都要翻新,不然会产出同等门科目学分差别的景观。

  那样的数目库表是吻合第③范式的,解决了数据冗余、更新分外、插入相当和删除十分。

  (3) 更新至极:

 

  鲍依斯-科得范式(BCNF):在第3范式的根底上,数据库表中即使不设有其余字段对任一候选关键字段的传递函数看重则吻合第叁范式。

  假设仓库换了协会者,则表中全部行的总指挥ID都要修改。

(3) 插入格外:

  假如仓库管理关系表为StorehouseManage(仓库ID, 存款和储蓄物品ID, 管理员ID,
数量),且有叁个大班只在贰个储藏室工作;三个仓库能够储存各个物品。那些数据库表中设有如下决定涉及:

  把仓库管理涉及表分解为一个涉及表:

 

  (仓库ID, 存储物品ID) →(管理员ID, 数量)

  仓库管理:StorehouseManage(仓库ID, 管理员ID);

设若要开办一门新的教程,一时半刻还从未人选修。那样,由于还尚未”学号”关键字,课程名称和学分也无从记录入数据库。

  (管理员ID, 存款和储蓄物品ID) → (仓库ID, 数量)

  仓库:Storehouse(仓库ID, 存储物品ID, 数量)。

 

  所以,(仓库ID, 存款和储蓄物品ID)和(管理员ID,
存储物品ID)都以StorehouseManage的候选关键字,表中的绝无仅有非关键字段为多少,它是相符第贰范式的。不过,由于存在如下决定涉及:

  那样的数额库表是切合BCNF范式的,化解了删除非常、插入十分和更新非常。

(4) 删除至极:

  (仓库ID) → (管理员ID)

 

  (管理员ID) → (仓库ID)

就算一批学生早已做到课程的选修,这么些选修记录就活该从数据库表中删除。然则,与此同时,课程名称和学分新闻也被剔除了。很扎眼,那也会促成插入极度。

  即存在重庆大学字段决定第3字段的事态,所以其不符合BCNF范式。它会见世如下十分情况:

 

  (1) 删除十分:

把选课关系表SelectCourse改为如下多少个表:

  当仓库被清空后,全体”存款和储蓄物品ID”和”数量”新闻被剔除的还要,”仓库ID”和”管理员ID”音信也被去除了。

 

  (2) 插入格外:

学生:Student(学号, 姓名, 年龄);

  当仓库没有存款和储蓄任何物品时,不可能给仓库分配管理员。

 

  (3) 更新很是:

学科:Course(课程名称, 学分);

  固然仓库换了组织者,则表中全体行的总指挥ID都要修改。

 

  把库房产和土地资金财产管理理关系表分解为一个事关表:

选课关系:SelectCourse(学号, 课程名称, 成绩)。

  仓库管理:StorehouseManage(仓库ID, 管理员ID);

 

  仓库:Storehouse(仓库ID, 存款和储蓄物品ID, 数量)。

这般的数额库表是切合第③范式的, 化解了多少冗余、更新12分、插入格外和删除万分。

  那样的数目库表是吻合BCNF范式的,化解了删除非常、插入万分和翻新至极。

 

上一页 1 2

范式应用

  我们来逐步搞定一个论坛的数据库,有如下信息:

  (1) 用户:用户名,email,主页,电话,联系地址

  (2) 帖子:发帖标题,发帖内容,回复标题,回复内容

  第一次我们将数据库设计为仅仅存在表:
  

用户名 email 主页 电话 联系地址 发帖标题 发帖内容 回复标题 回复内容

  这个数据库表符合第一范式,但是没有任何一组候选关键字能决定数据库表的整行,唯一的关键字段用户名也不能完全决定整个元组。我们需要增加"发帖ID"、"回复ID"字段,即将表修改为:

用户名 email 主页 电话 联系地址 发帖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.3 第壹范式(3NF)属性不依靠于别的非主属性 [ 解决传递依赖 ]

 

一旦波及形式帕杰罗是第1范式,且每一个非主属性都不传递注重于大切诺基的候选键,则称兰德路虎极光为第贰范式情势。

    知足第③范式(3NF)必须先满足第一范式(2NF)。第叁范式(3NF)要求一个数据库表中不带有已在任何表中已盈盈的非主关键字音信。

 

譬如说,存在二个机构新闻表,个中各种单位有单位编号(dept_id)、部门名称、部门简介等音讯。那么在的职员和工人音信表中列出单位编号后就无法再将单位名称、部门简介等与部门有关的音讯再投入职员和工人音讯表中。借使不存在机构消息表,则基于第一范式(3NF)也应有创设它,不然就会有雅量的多少冗余。

 

其三范式(3NF):在其次范式的根底上,数据表中假若不存在非关键字段对任一候选关键字段的传递函数信赖则吻合第叁范式。简单的讲,第贰范式便是性质不借助于任何非主属性。

 

所谓传递函数正视,指的是一旦存在”A → B → C”的控制涉及,则C传递函数依赖于A。

 

所以,满意第3范式的数据库表应该不设有如下注重关系:

 

一言九鼎字段 → 非关键字段x → 非关键字段y

 

借使学生关系表为Student(学号, 姓名, 年龄, 所在大学, 大学地方, 大学电话),关键字为单纯关键字”学号”,因为存在如下决定涉及:

 

(学号) → (姓名, 年龄, 所在大学, 大学地方, 高校电话)

 

本条数据库是适合2NF的,不过不合乎3NF,因为存在如下决定涉及:

 

(学号) → (所在学院) → (大学地方, 高校电话)

 

即存在非关键字段”大学地方”、”大学电话”对第1字段”学号”的传递函数信赖。

 

它也会存在数据冗余、更新相当、插入卓殊和删除非常的情状,读者可自动分析得知。

 

把学生关系表分为如下八个表:

 

学员:(学号, 姓名, 年龄, 所在大学);

 

学院:(学院, 地点, 电话)。

 

那样的数码库表是切合第3范式的,解决了数量冗余、更新格外、插入万分和删除万分。

相关文章

发表评论

电子邮件地址不会被公开。 必填项已用*标注

*
*
Website