大家好,欢迎来到IT知识分享网。
第一范式(1NF)
在关系模式R中,当且仅当所有域只包含原子值,即每个分量都是不可再分的数据项,则称R是第一范式。
可理解为在一张数据表中,当列名(属性)不可拆分时则称此表是第一范式。
例如:
姓名 | |
个人信息 | |
张三 | 手机号:xxxxx,年龄23 |
王五 | 手机号:xxxxx,年龄25 |
上表中列个人信息可拆分为手机号、年龄两列,所以不是第一范式;
改为第一范式应是:
姓名 | 手机号 | 年龄 |
张三 | xxxxx |
23 |
王五 | xxxxx | 25 |
上表中每一列都不能再拆分,故此表为第一范式。
第一范式的重点:
确保原子性,即每一列数据都不能再拆分。
第二范式(2NF)
当且仅当关系R已经是第一范式时,且每一个非主属性完全依赖主键(即不存在部分依赖)时,则称关系R是第二范式。
主键可以由多个主属性构成,也可以由单一主属性构成。
可以理解为:当一张表已经是第一范式,且非主属性只能由全部主键推出,不可以由部分主键推出时满足第二范式要求。
例如:
学号(SNO) | 课程号(CNO) | 成绩(GRADE) | 学分(CREDIT) |
S01 | C01 | 75 | 4 |
S02 | C01 | 92 | 4 |
S03 | C01 | 87 | 4 |
S04 | C01 | 55 | 4 |
S01 | C02 | 87 | 2 |
S02 | C02 | 95 | 2 |
S01 | C03 | 94 | 5 |
…… | …… | …… |
上表中,每一列都不能再拆分,所以此表满足第一范式,(一个学生可以选多个课程,因此学号和课程号单独一个都无法确定成绩,必须二者合起来才能确定学生成绩,所以2个红底属性合并称为一个主键),由主键中的部分属性课程号可以直接确定学分,所以非主属性学分是部分依赖主键,所以上表中存在部分依赖,不满足第二范式;
表中存在问题:
数据冗余:
课程C01对应的学分是4分在表中多次出现;
更新异常:
如果数据多次重复存在,在更新时极易漏更;
插入异常:
如果想要插入新的课程C05学分是6分,但此课程并没有学生选,所以对应的学生学号不存在,但是学号(SNO)是主键,想要插入数据主键不能为0,所以无法插入此课程;
删除异常:
如果此表中的学生已经全部毕业,可以删除他们的成绩,但是学校每届的课程和课程的学分是不变的,此时如果删除成绩,其他属性可能会被连带删除;
改为第二范式应该是:
将表进行提取,分成2个表;
表1:表1中的非主属性完全依赖主键,不存在部分依赖,所以满足第二范式
学号(SNO) | 课程号(CNO) | 成绩(GRADE) |
S01 | C01 | 75 |
S02 | C01 | 92 |
S03 | C01 | 87 |
S04 | C01 | 55 |
S01 | C02 | 87 |
S02 | C02 | 95 |
S01 | C03 | 94 |
…… | …… | …… |
表2: 主键由一个属性构成,不存在部分主键,因此也就不存在部份依赖,所以满足第二范式。
所以如果表满足第一范式,且表中的主键只有一个属性的情况下此表满足第二范式。
课程号(CNO) | 学分(CREDIT) |
C01 | 4 |
C01 | 4 |
C01 | 4 |
C01 | 4 |
C02 | 2 |
C02 | 2 |
C03 | 5 |
…… |
而进一步可将表2简化为
课程号(CNO) | 学分(CREDIT) |
C01 | 4 |
C02 | 2 |
C03 | 5 |
…… |
可以解决掉部分: 数据冗余,更新异常,插入异常,删除异常等问题。
第二范式的重点:
确保唯一性,即一张表叙述一件事,例如表1只表述学生的课程成绩,表2只表述课程的学分。
第三范式(3NF)
当且仅当关系R已经满足第一范式和第二范式时,且表中没有非主属性传递依赖于主键时,则称关系R满足第三范式。
可以理解为:一个表满足第一、二范式的情况下,如果表中的非主键可以直接依赖于主键,而不是传递依赖于主键时,此表满足第三范式。
例如:
学号(SNO) | 姓名(SName) | 系号(DNO) | 系名(DNAME) | 系住址(LOCATION) |
S01 | 张三 | D01 | 计算机系 | 1号楼 |
S02 | 李四 | D01 | 计算机系 | 1号楼 |
S03 | 王五 | D01 | 计算机系 | 1号楼 |
S04 | 赵六 | D02 | 信息系 | 2号楼 |
…… | …… | …… | …… | …… |
上表中,主键是学号(SNO),表中各列不可再拆分满足第一范式,主键是单一属性不存在非主属性部分依赖主键,满足第二范式;
表中,根据学号可以直接推出姓名和系号,但是根据学号无法得到系名和系住址,
只能根据学号推得系号再推得系名,因此系名与学号之间不是直接依赖关系而是间接依赖关系;
据学号推得系号再推得系地址,因此系住址与学号之间不是直接依赖关系而是间接依赖关系;
因此表中非主属性系名,和非主属性系住址,与主键之间都是间接依赖,所以不满足第三范式。
上述表中仍然存在部分: 数据冗余,更新异常,插入异常,删除异常等问题。
改为第三范式应该是:
将表进行提取:分成2个表:
表1:主键是学号,非主属性姓名和系号均直接依赖于主键学号,表中不存在间接依赖关系,因此满足第三范式
学号(SNO) | 姓名(SName) | 系号(DNO) |
S01 | 张三 | D01 |
S02 | 李四 | D01 |
S03 | 王五 | D01 |
S04 | 赵六 | D02 |
…… | …… | …… |
表2:主键是系号,非主属性系名和非主属性系住址均直接依赖于主键学号,表中不存在间接依赖关系,满足第三范式。
系号(DNO) | 系名(DNAME) | 系住址(LOCATION) |
D01 | 计算机系 | 1号楼 |
D01 | 计算机系 | 1号楼 |
D01 | 计算机系 | 1号楼 |
D02 | 信息系 | 2号楼 |
…… | …… | …… |
而进一步可将表2简化为
系号(DNO) | 系名(DNAME) | 系住址(LOCATION) |
D01 | 计算机系 | 1号楼 |
D02 | 信息系 | 2号楼 |
…… | …… | …… |
可以解决掉部分: 数据冗余,更新异常,插入异常,删除异常等问题。
第三范式的重点:
确保独立性,除主键之外,每个属性之间不存在任何形式的依赖,即每个非主属性只完全依赖于主键。
BC范式(BCNF)
BC范式又称巴斯-科德范式或3.5范式,主要是对第三范式的补充,因为第三范式只明确非主属性之间不能存在依关系,并没有明确主键(特指多个属性组成的联合主键)之间不能存在依赖关系,BCNF修正的就是这一点。
上述利用概念区分范式的方式在BCNF中应用起来较难理解(其实主要是因为我不会),所以一般使用如下方法:
BC范式判断方法:
首先满足第一、二、三范式,再用有向图求解候选键(一般此类情况存在多个候选键),依次写出候选键的依赖关系,如果依赖关系的左边均是候选键,则可以确定此关系满足BC范式。
据给定关系画有向图
老师T可以确定课程J(T–>J);学生S和课程J可以确定老师(SJ–>T);所以得下图
此有向图中入度为0的属性是属性S,属性S并不能独自遍历全图,且没有其他入度为0的属性,所以寻找既有入度又有出度的属性并入入度为0的属性中作为合集遍历全图;
属性T和属性J均是既有入度又有出度的属性,
属性ST结合:T可指向J,可以遍历全图,所以SJ是候选键;
依赖关系:T–>J;
属性SJ结合:SJ指向T已经遍历完全图,所以ST是候选键;
依赖关系:SJ–>T;
每个属性不可再拆分,满足原子性即满足第一范式;
候选键中出现的属性均为主属性,所以此题目中STJ三个属性均为主属性,不存在非主属性。
没有非主属性,即不存在非主属性部分依赖主属性,满足第二范式;
没有非主属性,即不存在非主属性之间存在传递依赖,满足第三范式;
上述候选键的依赖关系分别是:T–>J 和 SJ–>T;在依赖关系T–>J中,不满足左侧是主键的要求,所以此关系不满足BC范式。
例题:
此类例目题严格来讲并不完善,存在许多地方并不严谨,做此类题目时最好根据选项判断,从选项中选择相对更正确一些的,或者直接根据选项的思路做排除。
问题(1):
A:部分依赖的只存在于主键(主码)是由多个主属性构成的情况下,题目中并未说明主键是单属性还是多属性,而单属性部门号完全可以做主键,所以当单属性部门号作为主键时,存在的说传递依赖而不是部分函数依赖,故排除。
B:同样在单属性做主码时,不存在部分函数依赖,故排除。
C:在单属性做主码时,已经不存在部份依赖只存在传递依赖,故选择。
D:同样在单属性做主码时,不存在部分函数依赖,故排除。
问题(2):
此空与问题(3)相关联,而(3)的选项中添加的是销售,即(2)中需要完善的只有职工号、部门号、姓名。因此可以排除BC,部门实体与职工实体之间是一对多的关系,联系E-R图,一般会将少的加在多的一方,所以选D。
问题(3):.
选项中可以确定是需要添加销售关系,第一项是职工号,,问题(2)结束后胡,职工号已经可以确定部门名了,所以为了避免冗余,二者保留其一,故排除CD,而选项B中,商品号和商品名二者存在冗余,所以二者选其一就可,故选A。
联系
反规范化
规范化是为了减少数据的冗余提高增、删、改的速度,但是由于表不断被拆分,导致表的数量过多增加了查询的工作量,系统需要进行多次连接才能进行查询操作,使得系统效率下降,因此提出反会反规范化理论。
反规范化理论的操作过程:
增加派生性冗余列、增加冗余列、重新组表、分割表。
免责声明:本站所有文章内容,图片,视频等均是来源于用户投稿和互联网及文摘转载整编而成,不代表本站观点,不承担相关法律责任。其著作权各归其原作者或其出版社所有。如发现本站有涉嫌抄袭侵权/违法违规的内容,侵犯到您的权益,请在线联系站长,一经查实,本站将立刻删除。 本文来自网络,若有侵权,请联系删除,如若转载,请注明出处:https://haidsoft.com/134526.html