SQL数据依赖.pptVIP

第11章 关系数据库设计理论 引入：问题的提出 针对具体问题，如何构造一个适合于它的数据模式 数据库逻辑设计的工具──关系数据库的规范化理论 问题 如何将所涉及到的数据组织存入到数据库中？ 是放在一个表中存放还是分在几个表中存放？ 每个表应由哪些属性组成？ 怎样设计才是科学合理的呢？ 一个例子 学生关系模式 关系模式： 学生(学号，姓名，课程号，课程名，成绩) 语义说明如下： (1) 一个学生可以选修多门课程， 每门课程有多个学生选修 (2) 每个学生选修每门课程都有一个成绩 学生关系实例 该关系模式存在的问题 (1) 插入异常 如果存在某个学生因为某些原因没有选课， 课程号为空，因此该学生的信息无法插入 (2) 删除异常 如果学生毕业，删除学生信息的同时 将课程的相关信息也删除了 该关系模式存在的问题 (3) 数据冗余 课程的信息重复出现，浪费存储空间。 (4) 更新异常 更新时系统要付出很大的代价。 11.2 函数依赖 11.1 函数依赖的定义 设R(U)是属性集U上的关系模式，X和Y是U的子集。 若对于R(U)的任意一个可能的关系r，r中不可能存 在两个元组在X上的属性值相等，而在Y上的属性值 不等，则称 “X函数确定Y” 或 “Y函数依赖于X”， 记作X→Y。X称为这个函数依赖的决定属性集。 举例 关系模式： 学生(学号，姓名，性别，年龄) 函数依赖： 学号→姓名 学号→性别 学号→年龄 说明 (1)函数依赖是指关系模式R的所有关系实例均要 满足的约束条件 (2)函数依赖要根据数据的语义来确定 例如，在关系模式学生中， 姓名→性别、姓名→年龄 这两个函数依赖在什么条件下才成立？ 补充：如何判断函数依赖 判断函数依赖的规则： 如果两属性集X,Y之间有 (1)1:1的联系，则X←→Y (2)n:1的联系，则X→Y (3)m:n的联系，则X→Y，Y→X 属性间是一对一联系学号与姓名关系：1:1（不允许有同名学生） 属性间是一对多联系学号与所在系关系：n:1(一个系有多名学生) 属性间是多对多联系学号和课程号关系：m:n 函数依赖的分类 非平凡函数依赖/平凡函数依赖 完全函数依赖/部分函数依赖 传递函数依赖/直接函数依赖 (1)非平凡函数依赖/平凡函数依赖 关系模式R（U），U是R的属性集合，X，Y是U的 子集，如果 X?Y，但Y不包含于X，则称X?Y是 非平凡函数依赖。 若Y是X的子集 ，则称X?Y是平凡函数依赖。 说明 (1)对任一关系模式，平凡函数依赖必然成立 (2)本节只讨论非平凡函数依赖 (3)非平凡函数依赖易产生问题 举例 例如：对关系模式：选修(学号，课程号，成绩) 来说，存在下面的函数依赖： ①(学号，课程号) →学号 ②(学号，课程号) →课程号 ③(学号，课程号) →成绩 (2)完全函数依赖/部分函数依赖 在关系模式R(U)中，如果X→Y，并且对于X的任何一个真子集Z，Z→Y都不成立，则称Y完全函数依赖于X。 如果X→Y，但Y不完全函数依赖于X，则称Y部分函数依赖于X。 说明 (1)部分函数依赖易产生问题 (2)完全函数依赖要求在函数依赖的决定因素中 没有多余属性 举例 例如：对关系模式： 选修(学号，姓名，课程号，成绩)来说， 存在下面的函数依赖： ①(学号，课程号) →成绩 ②学号 →姓名 函数依赖图 (3)传递函数依赖/直接函数依赖 关系模式R(U)，X、Y和Z是属性集U的子集，如果X→Y，Y→Z，Y不是X的子集，Y→X不成立，则称Z传递函数依赖于X。 如果X→Y，Y→Z，Y→X，Y不是X的子集，则称Z直接函数依赖于X。 举例 例如：关系模式： 学生(学号，所在系，系主任姓名)中 存在下列函数依赖： ①学号 →所在系 ②所在系 →系主任姓名 函数依赖图 11.2.2 码 说明 (1)一个关系模式可以有多个候选码，可以选定其中的一个作为主码。 (2)候选码可以有一个属性，也可以有多个属性。当候选码包含关系模式的所有属性时，称为全码。 (3)候选码中的属性称为主属性，不在任何候选码中的属性称为非主属性。 11.3 范式 范式(Normal Form)是对关系模式的规范形式的简称。 关系模式的范式主要有4种：第一范式(1NF)、第二范式(2NF)、第三范式(3NF)和BC范式(BCNF)。 (1)第一范式(1NF) 如果一个关系模式R的所有属性都是不可分的基本数据项，则称这个关系模式为第一范式，记为1NF。 第一范式是对关系模式的最基本要求，不满足第一范式的数据库模式不能称为关系数据库。 (2)第二范式(2NF) 如果关系模式R是1NF，并且每一个非主属性都完全函数依赖于R的码，则称R为第二范式，记为2NF。 举例 例如：关系模式： 选修