一,超码、主码、候选码之间的定义与联系

码是数据系统中的基本概念

它包括超码,候选码,主码

(1)超码是一个或多个属性的集合,这些属性可以让我们在一个实体集中唯一地标识一个实体。
如果K是一个超码,那么K的任意超集也是超码,也就是说如果K是超码,那么所有包含K的集合也是超码。

(2)候选码是从超码中选出的,自然地候选码也是一个或多个属性的集合,候选码是最小超码,它们的任意真子集都不能成为超码
如果K是超码,那么所有包含K的集合都不能是候选码
如果K,J都不是超码,那么K和J组成的集合(K,J)有可能是候选码

(3)主码是从多个候选码中任意选出一个做为主码,如果候选码只有一个,那么候选码就是主码。
虽然说主码的选择是比较随意的,但在实际开发中还是要靠一定的经验,不然开发出来的系统会出现很多问题。一般来说主码都应该选择那此从不或者极少变化的的属性。

二,函数依赖、

函数依赖简单点说就是:某个属性集决定另一个属性集时,称另一属性集依赖于该属性集。

(1)完全函数依赖
存在 X 属性集(注意是集合,说明是联合主键)决定 唯一的 Y ,且 X 中的任一子集都不能决定 唯一的 Y,则 Y 完全依赖于 X。

学生数学成绩完全由该学生的学号和数学课决定,所以数学课成绩完全依赖于(学号,数学课)

(2)部分函数依赖
X 的属性集中任一子集可以决定唯一的 Y

学生学号和姓名可以决定唯一的学生,但是学生号也可以决定唯一的学生

(3)传递函数依赖
设 R 为任一给定关系, X Y Z 为其不同的属性子集,若 X —> Y, Y 不决定 X 且 Y —>Z,则有 X —>Z,称为 Z 传递函数依赖于 X

书的出版编号是唯一,版权归出版社所有,所以只能由该出版社出版、 书出版编号—>出版社名,出版社名—>出版社地址

在这里插入图片描述

三,三大范式

首先要明白,范式的包含关系。一个数据库设计如果符合第二范式,一定也符合第一范式。如果符合第三范式,一定也符合第二范式…

第一范式(1NF):

属性不可分

第二范式(2NF):

符合1NF,并且,非主属性完全依赖于码。一个候选码中的主属性也可能是好几个。如果一个主属性,它不能单独做为一个候选码,那么它也不能确定任何一个非主属性。
2NF要求实体的属性完全依赖于主关键字。所谓完全依赖是指不能存在仅依赖主关键字一部分的属性,如果存在,那么这个属性和主关键字的这一部分应该分离出来形成一个新的实体,新实体与原实体之间是一对多的关系。

假设存在如下决定关系:
(学号, 课程名称) → (姓名, 年龄, 成绩, 学分) 这个数据库表不满足第二范式,因为存在如下决定关系:
(课程名称) → (学分)
(学号) → (姓名, 年龄)

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

第三范式(3NF):

在第二范式的基础上,数据表中如果不存在非关键字段对任一候选关键字段的传递函数依赖则符合第三范式。所谓传递函数依赖,指的是如果存在"A → B → C"的决定关系,则C传递函数依赖于A。因此,满足第三范式的数据库表应该不存在如下依赖关系:
关键字段 → 非关键字段x → 非关键字段y

假定学生关系表为 Student(学号, 姓名, 年龄, 所在学院, 学院地点, 学院电话)
,关键字为单一关键字"学号",因为存在如下决定关系:
(学号) → (姓名, 年龄, 所在学院, 学院地点, 学院电话) 这个数据库是符合2NF的,但是不符合3NF,因为存在如下决定关系:
(学号) → (所在学院) → (学院地点, 学院电话)
即存在非关键字段"学院地点"、"学院电话"对关键字段"学号"的传递函数依赖。

BCNF

在第三范式的基础上,数据库表中如果不存在任何字段对任一候选关键字段的传递函数依赖则符合第三范式。
符合3NF,并且,主属性不依赖于主属性

Logo

腾讯云面向开发者汇聚海量精品云计算使用和开发经验,营造开放的云计算技术生态圈。

更多推荐