当前位置：文档之家 › 关系数据库范式规则

关系数据库范式规则

  • 格式：ppt
  • 大小：496.50 KB
  • 文档页数：54

下载文档原格式

  / 54

合集下载

关系型数据库三大范式

关系型数据库三大范式

关系型数据库三⼤范式基础概念：关键字、主关键字、候选关键字,⾮关键字如果某个字段或多个字段的值可以唯⼀地标识⼀条记录，则该字段或字段组就称为关键字。

如果⼀个关键字是⽤以标识每条记录的唯⼀性，并作为该表与其他表实现关联之⽤，则称其为主关键字（主键，primary key）或主码。

除主关键字以外的其他关键字称为候选关键字。

除关键字意外的字称为⾮关键字例如，有⼀个表字段为：id firstname lastname address phone IDcard那么id或IDcard或firstname+lastname（不存在同名的情况下）都可以说是关键字。

其中id为主关键字，IDcard和firstname+lastname为候选关键字。

数据库设计范式第⼀范式(1NF)：数据表中的字都是单⼀属性，不可再分的（原⼦性）。

单⼀属性由基本类型构成，包括整型、实数、字符型、逻辑型、⽇期型等。

在任何⼀个关系数据库中，第⼀范式（1NF）是对关系模式的基本要求，不满⾜第⼀范式（1NF）的数据库就不是关系数据库。

第⼆范式(2NF)：数据表中⾮关键字都不存在对候选关键字的部分函数依赖（部分函数依赖指的是存在组合关键字中的某些字段决定⾮关键字段的情况），则符合第⼆范式（完全依赖于主键），也即所有⾮关键字段都完全依赖于任意⼀组候选关键字。

例：假定选课关系表为SelectCourse(学号, 姓名, 年龄, 课程名称, 成绩, 学分)，关键字为组合关键字(学号, 课程名称)，因为存在如下决定关系： (学号, 课程名称) → (姓名, 年龄, 成绩, 学分) 这个数据库表不满⾜第⼆范式，因为存在如下决定关系： (课程名称) → (学分) (学号) → (姓名, 年龄) 即存在组合关键字中的字段决定⾮关键字的情况。

由于不符合2NF，这个选课关系表会存在如下问题： (1) 数据冗余： 同⼀门课程由n个学⽣选修，"学分"就重复n-1次；同⼀个学⽣选修了m门课程，姓名和年龄就重复了m-1次。

范式理论

范式理论
第二范式（2NF）要求实体的属性完全依赖于主关键字。所谓完全依赖是指不能存在仅依赖主关键字一部分的属性，如果存在，那么这个属性和主关键字的这一部分应该分离出来形成一个新的实体，新实体与原实体之间是一对多的关系。为实现区分通常需要为表加上一个列，以存储各个实例的唯一标识。简而言之，第二范式就是非主属性非部分依赖于主关键字。
一是重复存储职工号和姓名。这样，关键字只能是电话号码。
二是职工号为关键字，电话号码分为单位电话和住宅电话两个属性
三是职工号为关键字，但强制每条记录只能有一个电话号码。
以上三个方法，第一种方法最不可取，按实际情况选取后两种情况。
第二范式（2NF）：如果关系模式R（U，F）中的所有非主属性都完全依赖于任意一个候选关键字，则称关系R 是属于第二范式的。
方法：将关系模式投影分解成两个或两个以上的关系模式。
要求：分解后的关系模式集合应当与原关系模式等价，即经过自然联接可以恢复原关系而不丢失信息，并保持属性间合理的联系。
注意：一个关系模式结这分解可以得到不同关系模式集合，也就是说分解方法不是唯一的。最小冗余的要求必须以分解后的数据库能够表达原来数据库所有信息为前提来实现。其根本目标是节省存储空间，避免数据不一致性，提高对关系的操作效率，同时满足应用需求。实际上，并不一定要求全部模式都达到BCNF不可。有时故意保留部分冗余可能更方便数据查询。尤其对于那些更新频度不高，查询频度极高的数据库系统更是如此。
关系数据库设计之时是要遵守一定的规则的。尤其是数据库设计范式 现简单介绍1NF（第一范式），2NF（第二范式），3NF（第三范式）和BCNF，另有第四范式和第五范式留到以后再介绍。 在你设计数据库之时，若能符合这几个范式，你就是数据库设计的高手。

什么是数据库三大范式，它们是做什么的？

什么是数据库三大范式，它们是做什么的？

什么是数据库三⼤范式，它们是做什么的？设计关系数据库时，遵从不同的规范要求，设计出合理的关系型数据库，这些不同的规范要求被称为不同的范式，各种范式呈递次规范，越⾼的范式数据库冗余越⼩。

关系数据库有六种范式：第⼀范式（1NF）、第⼆范式（2NF）、第三范式（3NF）、巴斯-科德范式（BCNF）、第四范式(4NF）和第五范式（5NF，⼜称完美范式）。

满⾜最低要求的范式是第⼀范式（1NF）。

在第⼀范式的基础上进⼀步满⾜更多规范要求的称为第⼆范式（2NF），其余范式以次类推。

⼀般来说，数据库只需满⾜第三范式(3NF）就⾏了。

1、第⼀范式（1NF）：所谓第⼀范式（1NF）是指在关系模型中，对于添加的⼀个规范要求，所有的域都应该是原⼦性的，即数据库表的每⼀列都是不可分割的原⼦数据项，⽽不能是集合，数组，记录等⾮原⼦数据项。

即实体中的某个属性有多个值时，必须拆分为不同的属性。

在符合第⼀范式（1NF）表中的每个域值只能是实体的⼀个属性或⼀个属性的⼀部分。

简⽽⾔之，第⼀范式就是⽆重复的域。

2、第⼆范式（2NF）在1NF的基础上，⾮码属性必须完全依赖于候选码（在1NF基础上消除⾮主属性对主码的部分函数依赖）第⼆范式（2NF）是在第⼀范式（1NF）的基础上建⽴起来的，即满⾜第⼆范式（2NF）必须先满⾜第⼀范式（1NF）。

第⼆范式（2NF）要求数据库表中的每个实例或记录必须可以被唯⼀地区分。

选取⼀个能区分每个实体的属性或属性组，作为实体的唯⼀标识。

例如在员⼯表中的⾝份证号码即可实现每个⼀员⼯的区分，该⾝份证号码即为候选键，任何⼀个候选键都可以被选作主键。

在找不到候选键时，可额外增加属性以实现区分，如果在员⼯关系中，没有对其⾝份证号进⾏存储，⽽姓名可能会在数据库运⾏的某个时间重复，⽆法区分出实体时，设计辟如ID等不重复的编号以实现区分，被添加的编号或ID选作主键。

（该主键的添加是在ER设计时添加，不是建库时随意添加），第⼆范式（2NF）要求实体的属性完全依赖于主关键字。

范式间区别

范式间区别

(1) 数据冗余：
同一门课程由n个学生选修，"学分"就重复n-1次；同一个学生选修了m门课程，姓名和年龄就重复了m-1次。
(2) 更新异常：
若调整了某门课程的学分，数据表中所有行的"学分"值都要更新，否则会出现同一门课程学分不同的情况。
(3) 插入异常：
假设要开设一门新的课程，暂时还没有人选修。这样，由于还没有"学号"关键字，课程名称和学分也无法记录入数据库。
选课关系：SelectCourse(学号, 课程名称, 成绩)。
stuቤተ መጻሕፍቲ ባይዱent2(sno,sname,age,sex,class)
---------------------------------
class(class,department)
-----------------------
所以关系模式student 可分解成 4个3NF的关系模式student2 ,class ,course,sc
(4) 删除异常：
假设一批学生已经完成课程的选修，这些选修记录就应该从数据库表中删除。但是，与此同时，课程名称和学分信息也被删除了。很显然，这也会导致插入异常。
把选课关系表SelectCourse改为如下三个表：
学生：Student(学号, 姓名, 年龄)；
课程：Course(课程名称, 学分)；
其实范式是关系型数据的基本知识.
1Nf--第1范式就是没有表中有表,即二维表就可以了
2Nf--第2范式就是表中没有重复列.
3Nf--第3范式就是没有传递依赖,表中所有列都函数依赖于主关键字.(比如,表a(ID,sum1,Sid,a1),表b(Sid,a1)例子中ID为表a的关键字,Sid为表b的关键字.

第一范式(1NF)、第二范式(2NF)和第三范式(3NF)之间的区别是什么？

第一范式(1NF)、第二范式(2NF)和第三范式(3NF)之间的区别是什么？

第一范式（1NF）、第二范式（2NF）和第三范式（3NF）之间的区别是什么？构造数据库必须遵循一定的规则。

在关系数据库中，这种规则就是范式。

范式是符合某一种级别的关系模式的集合。

关系数据库中的关系必须满足一定的要求，即满足不同的范式。

目前关系数据库有六种范式：第一范式（1NF）、第二范式（2NF）、第三范式（3NF）、第四范式（4NF）、第五范式（5NF）和第六范式（6NF）。

满足最低要求的范式是第一范式（1NF）。

在第一范式的基础上进一步满足更多要求的称为第二范式（2NF），其余范式以次类推。

一般说来，数据库只需满足第三范式（3NF）就行了。

下面我们举例介绍第一范式（1NF）、第二范式（2NF）和第三范式（3NF）。

3.4.1 第一范式（1NF）在任何一个关系数据库中，第一范式（1NF）是对关系模式的基本要求，不满足第一范式（1NF）的数据库就不是关系数据库。

所谓第一范式（1NF）是指数据库表的每一列都是不可分割的基本数据项，同一列中不能有多个值，即实体中的某个属性不能有多个值或者不能有重复的属性。

如果出现重复的属性，就可能需要定义一个新的实体，新的实体由重复的属性构成，新实体与原实体之间为一对多关系。

在第一范式（1NF）中表的每一行只包含一个实例的信息。

例如，对于图3-2 中的员工信息表，不能将员工信息都放在一列中显示，也不能将其中的两列或多列在一列中显示；员工信息表的每一行只表示一个员工的信息，一个员工的信息在表中只出现一次。

简而言之，第一范式就是无重复的列。

3.4.2 第二范式（2NF）第二范式（2NF）是在第一范式（1NF）的基础上建立起来的，即满足第二范式（2NF）必须先满足第一范式（1NF）。

第二范式（2NF）要求数据库表中的每个实例或行必须可以被惟一地区分。

为实现区分通常需要为表加上一个列，以存储各个实例的惟一标识。

如图3-2 员工信息表中加上了员工编号（emp_id）列，因为每个员工的员工编号是惟一的，因此每个员工可以被惟一区分。

数据库之闭包，范式

数据库之闭包，范式

数据库之闭包，范式.1 第⼀范式（1NF）⽆重复的列 所谓第⼀范式（1NF）是指数据库表的每⼀列都是不可分割的基本数据项，同⼀列中不能有多个值，即实体中的某个属性不能有多个值或者不能有重复的属性。

如果出现重复的属性，就可能需要定义⼀个新的实体，新的实体由重复的属性构成，新实体与原实体之间为⼀对多关系。

在第⼀范式（1NF）中表的每⼀⾏只包含⼀个实例的信息。

简⽽⾔之，第⼀范式就是⽆重复的列。

说明：在任何⼀个关系数据库中，第⼀范式（1NF）是对关系模式的基本要求，不满⾜第⼀范式（1NF）的数据库就不是关系数据库。

1.2 第⼆范式（2NF）属性完全依赖于主键[消除部分⼦函数依赖] 第⼆范式（2NF）是在第⼀范式（1NF）的基础上建⽴起来的，即满⾜第⼆范式（2NF）必须先满⾜第⼀范式（1NF）。

第⼆范式（2NF）要求数据库表中的每个实例或⾏必须可以被唯⼀地区分。

为实现区分通常需要为表加上⼀个列，以存储各个实例的唯⼀标识。

例如员⼯信息表中加上了员⼯编号（emp_id）列，因为每个员⼯的员⼯编号是唯⼀的，因此每个员⼯可以被唯⼀区分。

这个唯⼀属性列被称为主关键字或主键、主码。

第⼆范式（2NF）要求实体的属性完全依赖于主关键字。

所谓完全依赖是指不能存在仅依赖主关键字⼀部分的属性，如果存在，那么这个属性和主关键字的这⼀部分应该分离出来形成⼀个新的实体，新实体与原实体之间是⼀对多的关系。

为实现区分通常需要为表加上⼀个列，以存储各个实例的唯⼀标识。

简⽽⾔之，第⼆范式就是属性完全依赖于主键。

1.3 第三范式（3NF）属性不依赖于其它⾮主属性[消除传递依赖] 满⾜第三范式（3NF）必须先满⾜第⼆范式（2NF）。

简⽽⾔之，第三范式（3NF）要求⼀个数据库表中不包含已在其它表中已包含的⾮主关键字信息。

例如，存在⼀个部门信息表，其中每个部门有部门编号（dept_id）、部门名称、部门简介等信息。

那么在的员⼯信息表中列出部门编号后就不能再将部门名称、部门简介等与部门有关的信息再加⼊员⼯信息表中。

SQL server范式(NF)

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）、部门名称、部门简介等信息。

数据库 第四范式

数据库第四范式
数据库第四范式（4NF）是关系数据库设计中的一种范式，它建立在第三范式（3NF）的基础上。

第三范式要求所有的非关键字列都必须和所有的超键直接依赖，但是在某些情况下，数据库设计可能会出现类似于多对多的关系，使得依赖关系的复杂度增加。

此时，第四范式就可以帮助我们通过消除多值依赖和联合依赖等复杂关系，从而减少冗余数据，提高数据库的性能和查询效率。

在第四范式中，我们可以定义一个关系模式R（A，B，C，D），其中A是关系模式的主键（也可以是超键）。

若在该关系模式中存在以下两种情况之一，则该关系模式R符合第四范式要求：
1. 对于每个非主属性B，如果它与关系的其他非主属性C存在多值依赖，那么B可以被拆分成两个关系模式，其中一个包含属性B和A，另一个包含属性C和A。

2. 对于每个非主属性B和C，如果它们之间存在联合依赖，那么B和C可以被拆分成两个关系模式，其中一个包含属性B、A和C，另一个包含属性C和A。

通过将一个大的关系模式分解成多个小的关系模式，我们可以消除重
复的数据，提高数据库的性能和查询效率。

同时，第四范式也可以保证数据库的数据一致性和完整性，减少数据冗余和异常，避免数据的不一致性和混乱。

总之，数据库第四范式是关系数据库设计中的一种重要的范式，它可以有效地提高数据库的性能和查询效率，同时也可以保证数据库的数据一致性和完整性。

然而，在实际应用中，我们需要根据具体的业务需求和数据特点来选择不同的范式和设计方案，以达到最优的数据库设计效果。

sql 规则和范式

sql 规则和范式
SQL规则和范式是数据库设计和管理中非常重要的概念。

首先，让我们来谈谈SQL规则。

SQL是结构化查询语言的缩写，它是一种
用于管理关系型数据库的标准化语言。

SQL规则是指在编写SQL语
句时需要遵循的一系列规则和约定，以确保数据库操作的准确性和
一致性。

这些规则包括语法规则、数据类型规则、约束规则等。

例如，SQL语句必须按照特定的语法结构编写，数据类型必须与字段
定义一致，约束条件必须满足数据库设计的要求等。

接下来是范式的概念。

范式是用来规范化数据库设计的一组原则，旨在减少数据冗余和提高数据的一致性。

常见的范式包括第一
范式（1NF）、第二范式（2NF）、第三范式（3NF）等。

第一范式要求每个字段具有原子性，不可再分；第二范式要求每个非主键字段
完全依赖于全部主键而不是部分主键；第三范式要求每个字段都直
接依赖于主键，而不是依赖于其他非主键字段。

在SQL中，范式的应用可以提高数据库的性能和可维护性，减
少数据冗余和提高数据的完整性。

但是，过度范式化也可能导致查
询性能下降，需要在设计数据库时权衡范式化和性能之间的关系。

总的来说，SQL规则和范式是数据库设计和管理中非常重要的概念，它们能够帮助我们设计出高效、可靠的数据库结构，提高数据的一致性和完整性。

在实际应用中，需要根据具体的业务需求和性能要求来灵活运用这些原则。

关系模式设计


若存在对键码的部分依赖，则作为决定因素的
键码的真子集就应作为公共属性，用来把分别存 在部分依赖（指在原来关系）和完全依赖的两个 模式自然连接在一起。
若存在对键码的完全依赖，则传递链的中间属
性就应作为公共属性，用来把构成传递链的两个 基本链所组成的模式自然连接在一起。
2.相关属性合一 把以函数依赖的形式联系在一起的相关属性放
对于关系R，若R∈1NF，且每一个非主属性完 全函数依赖于码，则R∈2NF。
第二范式不允许关系模式中的非主属性部分依
赖于键码。如果数据库模式中每个关系模式都是 2NF，则称数据库模式为2NF的数据库模式。
2NF 在 1NF基础上消除了非主属性对码的部分 函数依赖。
分解成2NF模式集的算法： 设关系模式R（U），主键是W，R上还存在函 数依赖 X → Z，并且Z是非主属性和X W，那 么W → Z就是一个部分依赖。此时应把R分解成 两个模式：
当且仅当一个关系R中，每一个元组的每一个 属性只含有一个值时,该关系属于第一范式(1NF)。
在任何一个关系数据库系统中，第一范式是对 关系模式的一个起码要求。不满足1 NF关系称为
非规范化关系，满足1 NF的关系称为规范化关系。 在任何一个关系数据库系统中，关系至少应该是 1 NF。不满足1NF的数据库模式不能称为关系数 据库。在以后的讨论中，我们假定所有关系模式 都是1NF。但是满足第一范式的关系模式并不一 定是好的关系模式，不能排除数据冗余和更新异 常等情况。 1.2第二范式（2NF）
数据库原理与应用
关系模式设计 关系数据库中的关系是满足一定要求的，满足
不同程度要求的为不同的范式。关系模式的常见 范式主要有四种，它们是第一范式（1NF）、第 二范式（2NF）、第三范式（3NF）和BC范式 （BCNF）,除此之外还有第四范式（4NF）和第 五范式（5NF）。本节主要介绍关系模式的各种 范式的基本概念以及规范化算法。 1.1第一范式（1NF）
  1. 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。

对关系进行规范化分为六个级别，从高到 底为第一范式、第二范式、第三范式、 BC范式、第四范式、第五范式。通常只 要求规范到第三范式就可以了，并且前 三个范式能够很好地保持数据的无损连 接性和函数依赖性，再向后规范化容易 破坏这两个特性，有时可能得不偿失。
3.21关系规范化 定义8：设一个关系R（U），若U中的每个属性 都是不可再分的，或者说都是不被其他属性所 包含的独立属性，则称关系R（U）是符合第 一范式的。记为1NF。 关系数据库中的每个关系都必须达到第一范式— 最起码的要求。 若一个关系不满足第一范式，则称为非规范化的 关系，否则称为规范化的关系。 若库中所有关系都满足1NF，则称为
关系数据库系统具有三级模式结构，最主 要的是中间层的全局模式结构，简称关 系数据库模式或数据库模式。 一个关系数据库模式由一个面向具体应用 所涉及的若干个关系模式所 组成，这些 关系模式通过外码建立相互联系，形成 一个结构化的数据整体。
一个数据库系统逻辑设计的好坏主要看数据库模 式设计的好坏，一个数据库模式设计的好坏又 主要看所含的各个关系模式设计的好坏。 如果各个关系模式结构结构合理、功能简单明确、 规范化程度高。就能够确保所建立的数据库具 有： 较少的数据冗余、较高的数据共享度、较好的数 据一致性、较灵活和方便的数据更新能力。
例3-9P57 通信录关系T（姓名，性别，单位，省市， 邮编，电话（长途区号，办公电话，家庭电话）） 因为电话属性不是一个原子属性，所以它不是一个 规范化的关系。提升规范为1NF，得到的T（姓 名，性别，单位，省市，邮编，长途区号，办公 电话，家庭电话）。或分解为两个关系： T1（姓名，性别，单位，省市，邮编） T2（姓名，长途区号，办公电话，家庭电话，手机 号码）
定义1：设一个关系为R（U），X和Y为属性集U 上的子集，若对于元组中X上的每个值都有Y 上的一个惟一值与之对应，则称X和Y具有函 数依赖关系，并称X函数决定Y，或称Y函数依 赖于X，记作X→Y，称X为决定因素。 例3-1设一个职工关系（职工号，姓名，性别， 年龄，职务）就有函数依赖关系： 职工号→姓名，职工号→性别，职工号→年龄， 职工号→职务。
3.2.3第三范式 定义10：设一个关系R（U），它是满足第一范 式的，若R中的不存在非主属性对侯选码的传 递函数依赖，则称该关系R（ U）是符合第三 范式的。记为3NF。 若一个数据库中所有关系都达到了3NF（自然也 就包括达到2NF）则称该数据库是符合第三范 式的。 一个关系若只满足第二范式，仍然存在着由传递 依赖带来数据冗余和操作异常。
若一个关系中的属性子集X不能函数决定另一个 属性子集Y，则记作X→/Y，读作X不能函数决 定Y，或Y不能函数依赖于X。 定义2：设一个关系为R（U），X和Y为属性集U 上的子集， 若X→Y且X≯Y （Y不是X的子 集），则称X→Y为非平凡函数依赖，否则若 X﹥Y （Y是X的子集） ，则必有X→Y，称 X→Y 为平凡函数依赖。因为整体决定局部， 平凡函数总是成立的。就是说，
正确的分解要求关系的无损分解和无损连接。即 通过外码自然连接完全能得到原来的关系；同 时，分解后的每个关系的最小函数依赖集都是 原关系的最小函数依赖集的子集。这种分解才 是正确、有效和合理的分解。 一个关系中所有侯选码都是单属性，就不存在部 分函数依赖，满足1NF也就满足2NF。只有出 现复合侯选码时才有可能存在部分函数依赖， 才需要判断和消除部分函数依赖，通过分解 达 到2NF。
定义4：设一个关系为R（U），X，Y和Z为属性 集U上的子集， 其中X→Y， Y→Z，但Y→\X， Y≯Z （Z不是Y的子集） 则存在X→Z ，称此 为传递函数依赖，即X传递函数决定Z，Z传递 函数依赖于X。
例3-3设一个学生关系（学号，姓名， 性别，系号，系名，系主任名）， 函数依赖分析：
定义5：设一个关系为R（U），X，Y 和Z为属性集U上的子集， 若X→Y， 则存在XZ→YZ 和XZ→Y 。
例3-12P63 一个关系SDH=（学号，姓名，性别，籍贯， 系号，系名，系地址，系电话，宿舍号，宿舍电话） 实例表3-10 根据SDH关系模式的语义，可得出最小函数依赖集FD： FD={学号→姓名，学号→性别，学号→籍贯，学号→系 号，系号→系名，系号→系地址，系号→系电话，学 号→宿舍号，宿舍号→宿舍电话} 由于该关系是单属 性侯选码，所以不存在部分依赖，自然 满足2NF。但 存在传递依赖，所以必然会产生数据冗余和操作异常 P64。 消除R的传递依赖也是通过R的分解来实现的。
例3-10P58 借阅图书关系J（借阅证号，姓名，性别，借 阅图书登记（图书号1，书名1，图书号2，书名2，图 书号3，书名3 ）） 因为借阅图书登记属性不是一个原子属性，所以它不是 一个规范化的关系。提升规范为1NF。方法一：再原 关系中增加独立属性，取消分栏。得到： J（借阅证号，姓名，性别，图书号1，书名1，图书号2， 书名2，图书号3，书名3 ）。由于每个人借阅情况不 同，按这种方法规范化将出现许多空值，浪费存储空 间，不便于DBMS进行管理，应采用第二种方法。
↘关系中一个元组的任一属性值能够函数决定它自己的 值，任一属性组的值能够函数决定任一属性或属性子 集的值。 平凡函数依赖又称为函数依赖的自反性规则。 如在职工关系中，职工号总能函数决定它本身，对于任 给一个职工号，都有它本身的职工号值惟一对应；职 工号和性别构成的属性子集总是能够函数决定其中的 职工号或性别属性，记作 （职工号，性别）→职工号和（职工号，性别）→性别。 通常讨论的都是非平凡函数。
例如：在职工关系中，职工号与其他每个属性之 间的函数依赖都是完全函数依赖。 真子集职工号→年龄，所以存在部分函数依赖： （职工号，性别）--p→年龄。 下图
– （SNO，CNO） f GRADE – （完全函数依赖） – （SNO，CNO） p CREDIT – （部分函数依赖） SNO G
3.2 关系规范化
关系数据库由相互联系的一组关系所组成， 每个关系包括关系模式和关系值两个方 面。 关系模式是对关系的抽象定义，给出关系 的具体结构； 关系值是关系的具体内容，反映关系在某 一时刻的状态。
一个关系包含许多元组，每个元组都是符 合关系模式结构的一个具体值，并且部 分属于相应的属性。 在关系数据库中的每个关系都需要进行规 范化，使之达到一定的规范化程度，从 而提高数据的结构化程度、共享性、一 致性和可操作性。
例3-8P56 设R（A，B，C，D，E，F）， 最小函数依赖集FD={A →B，A →C， （C，D） →E}，求侯选码？ 分析： 侯选码（A，D，F）
函数依赖的常用规则：P56 自反性：若X﹥Y，则存在X→Y。 增广性：若X→Y，则存在XZ→YZ。 传递性：若X→Y和Y→Z，则存在X→Z。 合并性：若X→Y和X→Z，则有X→YZ。 分解性：若X→Y且Y﹥Z，则存在X→Z。 伪传递性：若X→Y和WY→Z，则存在WX→Z。 复合性：若X→Y和Z→W，则存在XZ→YW。 自增性：若X→Y，则存在WX→Y。
每一种类型的数据与数据之间的联系，在关系数 据库系统中都是 利用相应的关系来描述的。因 为关系是由属性构成的，所以数据依赖的基础 是属性之间的数据依赖。 数据依赖包括函数依赖和多值依赖两个方面。 在一个关系中，属性=变量，属性域=变量的取值 范围，属性在元组上的取值=属性变量的当前 值。单值（映射）函数，多值函数。如： f(x)=2x,f(n)=(-1)n等。
方法二：分解为两个关系： J1（借阅证号，姓名，性别） J2（借阅证号，图书号，书名，借阅日期， 归还日期） 方法三：P60
3.2.2第二范式 定义9：设一个关系R（U），它是满足第 一范式的，若R中的不存在非主属性对侯 选码的部分函数依赖，则称该关系R（U） 是符合第二范式的。记为2NF。 一个关系若只满足第一范式，那可能会带 来数据冗余和操作异常。 操作异常：插入、删除和修改异常，又称 为更新函数依赖示意图
例3-2设一个教师任课关系（教工号，姓名，职 称，课程号，课程名，课时数，课时费）函数 依赖分析： 主码：（教工号，课程号） 教工号→姓名，教工号→职称；课程号→课程名， 课程号→课时数； 完全函数依赖：（职称，课程号） --f→课时费 部分函数依赖：（教工号，课程号） --p→姓名， （教工号，课程号） --p→职称，…
数据库基础与应用
• 主教材： • 《数据库基础与应 用》（新版） 辅导教师：吴旻倩
Email: wuli1977@
3.1数据依赖 在现实生活中，事物之间（内部）的各特 征之间存在着相互依赖和制约的关系。 用数据来描述和处理，需要把具有共同 特征的事物归为一类。并可进一步细分。 如把人归为一类，把书归为一类等。 如针对学校的数据库管理需要，把所有人 员分为教师类、管理人员类和学生类。
“事务”的概念：P61 为了消除部分函数依赖，对SSC分解为： S（学生号，姓名，性别，专业） C（课程号，课程名，课程学分） SC（学生号，课程号，成绩） 对应的最小函数依赖集分别为： FD1={学生号→姓名，学生号→性别，学生号→专业} FD2={课程号→课程名，课程号→课程学分} FD3={（学生号，课程号） →成绩} 关系实例P62表3-7、3-8、3-9
定义6：设一个关系为R（U），X和Y为属性集U 上的子集， 若X→Y， 并且为完全非平凡函数 依赖，同时Y为单值属性，则称X→Y为R的最 小函数依赖。由R中所有最小函数依赖构成R 的最小函数依赖集，其中不含有冗余的传递函 数依赖 。 例3-4设一个关系R（A，B，C，D），函数依赖 集FD={A →B，B →C，A →C，B →D}，判断 它是否为R的最小函数依赖集。 分析：A →C 冗余，应去掉，就成为R的最小函数依赖集。
例3-5P54 分析：最小函数依赖集为 FD1={职工号→姓名，职工号→性别，职工号→ 年龄，职工号→职务} FD2={教工号→姓名，教工号→职称，课程号→ 课程名，课程号→课时数，（职称，课程号） →课时费} FD3={学号→姓名，学号→性别，学号→系号， 系号→系名，系号→系主任名}