第 3 章关系数据库

第3章关系数据库 本章主要介绍: 关系数据库设计步骤概念模型的设计(难点) 逻辑模型的设计（难点）关系模式的规范化处理（难点）

3.1 数据库设计概述 • 数据库设计是指对一个给定的应用环境，构造最优的数据库模式，建立数据库及其应用系统，使之能够有效地存储数据，满足各种用户的应用需求（包括信息要求和处理要求）。

3.1 数据库设计概述 • 关系数据库设计分为以下五个阶段： 1)需求分析 2)概念模式设计（E-R模型） 3)逻辑模式设计（RDBMS） 4)数据库实施 5)数据库运行和维护见下图所示。

数据库运行 和维护需求分析概念模式设计逻辑模式设计数据库实施 E/R图 RDBMS 模式存储模式图3.1.1 数据库的设计过程 3.1 数据库设计概述

3.2 概念模式设计 • 数据库概念模式与计算机实现无关。它是对现实世界的第1层抽象。 • 直接把现实世界事物及其联系抽象为数据世界的数据模型过于复杂，因此一般是先将现实世界的事物及其联系抽象为信息世界实体及其联系（概念模型），然后再将其转换为计算机世界的数据模型（关系数据库模式）。

现实世界(事物及其联系) 抽象信息世界（概念模式）转换计算机世界（关系数据库模式） 3.2 概念模式设计数据建模过程

3.2.1 实体联系模型 • 实体-联系模型(Entity-Relationship Model，简称为E-R模型)是1976年美籍华人P.S.Chen（陈平山）提出的。这个模型直接将现实世界中的事物及其之间的联系抽象为实体类型和实体间联系，然后用实体联系图表示数据模型。

3.2.1 实体联系模型 P39 E-R模型是用E-R图表示的。E-R图中有下面四个基本成分： ①矩形框：表示实体型。 ②菱形框：表示联系。 ③椭圆形框：表示实体或联系类型的属性。 ④直线：联系类型与其所涉及的实体之间用直线连接，实体与实体之间用直线连接。

3.2.1 实体联系模型

3.2.1 实体联系模型 (1)实体（entity）：客观存在并可相互区别的事物称为实体。实体可以是具体可触及到的对象，如一个大学生、一辆汽车等；也可以是抽象的事件，如一场足球赛，一次借书等。 (2)属性（attribute）：实体所具有的某一特征称为实体的属性。一个实体可由若干属性来刻画。例如，学生实体有学号、姓名、性别、年龄、班级等属性。

3.2.1 实体联系模型 (3)键（key）：也称关键字或码。唯一标识实体的最小的属性集称为实体的键。例如，学生（学号,姓名,年龄,性别,班级）键是“学号”；课程(课号,课名,学分,学时)，键是“课号”；选课(学号，课号，分数，学年)，键是（学号,课号）足球赛（场次，日期，地点）则是全键。

3.2.1 实体联系模型 (4)联系（relationship）：现实世界的事物彼此是有联系的，反映在信息世界就是实体之间的联系。 • 实体之间的联系有两类：一是不同实体集之间的联系；另一种是同一实体集中不同个体之间的联系。 • 首先，考察两个实体集之间的联系，可以分为三类：

管理校长学校坐坐座位座位学生学生 3.2.1 实体联系模型 ①1:1联系:已知实体集A和B，若其中每个实体集中任一实体至多与另一实体集中的一个实体有联系，则称A和B的联系为“1对1联系”，简记为1:1联系。

工作教师学校学习坐座位班级学生学生 3.2.1 实体联系模型 ②1:n联系: 已知实体集A和B，若A中每个实体可与B中任意个实体有联系，而B中每个实体至多与A中的一个实体有联系，则称A和B的联系为“1对多联系”，简记为1:n联系。

选修学生课程任课坐座位课程学生教师 3.2.1 实体联系模型 ③m:n联系: 已知实体集A和B，若其中每个实体集中任一实体可与另一实体集中的多个实体有联系，则称A和B的联系为“多对多联系”，简记为m:n联系。

供应项目供应商 1 零件 3.2.1 实体联系模型 • 类似地，我们可以定义多个实体集（三个或三个以上）之间的各种联系，也可以定义同一实体集中不同个体之间的联系。如下所示。例如：有三个实体型：供应商、项目和零件。有如下联系。

3.2.1 实体联系模型 例如：同一实体集内各实体间联系。如职工实体集内部具有领导与被领导的联系。如下图所示。职工领导

姓名年龄性别学号所属系学生 isa isa 学号学号班级研究方向本科生研究生班主任指导老师 3.2.2 子类的设计 • 子类：定义类型之间的一种子集关系。它抽象了类型之间的“is a”的语义联系。例如：

3.2.3 E-R模型实例 例1：教学管理系统E-R图如下所示。方法： 1）确定实体类型。系、学生、教师、研究生、课程 2）确定实体间联系类型。 3）根据实体类型和联系类型画出E-R图。 4）确定实体类型和联系类型的属性。

性别课号课名学分年龄专业成绩姓名 n m 学生选课课程学号 n n 工作量 isa isa 任课学号时间学号研究方向 m 工号名字本科生研究生指导 n 年龄教师班级 1 班主任 n 职称学习工作入学日期 1 1 系进校日期编号名称办公地点 3.2.3 E-R模型实例

3.3 逻辑模式设计 • E-R模型向关系模型转换规则规则1：每个实体型转换为一个关系模式，实体的属性就是关系的属性，实体的键就是关系的键。键用下划线标出。规则2：若实体之间联系是1:n (包括1:1)，在“n”端关系模式中加入“1”端实体的主键，作为其外键，“联系”本身的属性也进入“n”端关系模式。

学号系名工号 n 学习 1 1 工作 n 学生系教师入学时间到系时间 3.3 逻辑模式设计例如：学生(学号,姓名,性别,年龄 ,入学时间, 系名) 教师(工号,名字,性别,年龄,到系时间,系名) 系(系名,负责人,联系电话)

学号课号 n 选修 m 学生课程成绩 3.3 E-R图向关系模型的转换规则3：若实体的联系是m:n，则将联系转换为一个关系模式。“联系” 两端实体的主键以及“联系”本身的属性转换为该关系的属性。该关系的主键为各实体键的组合。选修(学号,课号,成绩) 学生(学号,姓名,性别,年龄 ,入学时间, 系名) 课程(课号,课名,学分)

编号供应商 p 工程号零件号 n 供应 m 零件工程供应量 3.3 E-R图向关系模型的转换规则4：两个以上实体之间的m:n联系转换为一个关系模式。其属性为相连实体的主键加上联系自身的属性构成, 其键由相连实体的键的组合. 例：供应( 编号, 零件号, 工程号, 供应量 )

姓名年龄性别学号所属系学生 isa isa 学号学号班级研究方向本科生研究生班主任导师 3.3 E-R图向关系模型的转换规则5：“isa”联系不用单独转换。具体处理见下例。

3.3 E-R图向关系模型的转换 学生(学号,姓名,性别,年龄 ,入学时间, 系名) 本科生(学号, 班级，班主任) 研究生(学号，研究方向，导师)

性别课号课名学分年龄专业成绩姓名 n m 学生选课课程学号 n n 工作量 isa isa 任课学号时间学号研究方向 m 工号名字本科生研究生指导 n 年龄教师班级 1 班主任 n 职称学习工作入学日期 1 1 系进校日期编号名称办公地点 3.3 E-R图向关系模型的转换例：教学管理系统E-R模型转换为关系模型。

3.3 E-R图向关系模型的转换 转换为关系模型：学生(学号,姓名,性别,年龄 ,专业，入学日期, 编号) 本科生(学号, 班级，班主任) 研究生(学号，研究方向，导师工号) 选修(学号,课号,成绩) 课程(课号,课名,学分) 教师(工号, 名字,年龄 ,职称，进校日期, 编号) 任课(工号,课号,时间，工作量) 系(编号,名称,办公地点)

3.3.2 关系模式的规范化处理 • 关系模式的规范化处理主要研究关系模式内各属性之间的依赖关系（一种数据联系），保持属性间好的数据依赖关系，消除导致异常的依赖关系，使得关系模式由低一级的规范模式上升到高一级的规范模式的过程称为规范化处理。

3.3.2 关系模式的规范化处理 • 1. 问题的提出 • 下面我们通过例子来考察数据库模式设计的必要性。即为什么要设计关系数据库模式，为什么有些关系模式是不好的，存在哪些方面的问题。

3.3.2 关系模式的规范化处理 例：建立一个数据库来描述学生的一些情况，假设需要了解这样一些信息：学生（Snum）、姓名(Sname)、系（Sdept）、系负责人(Mname)、课程(Cname)、成绩（Grade）。分析：为该数据库建一个关系模式来描述所要信息。 S(Snum,Sname,Sdept,Mname,Cname,Grade）

3.3.2 关系模式的规范化处理 • 这个关系模式存在的问题： • 插入异常：如果一个系刚成立，尚无学生或者虽然有了学生，但尚未安排课程，则我们无法把这个系及其负责人的信息存入数据库，从而，数据库用户也就无法从数据库中查找到该系及其负责人的信息。这种现象叫插入异常。 • 这是因为，该关系模式的主键为(Snum,Cname)，不能取空值，在学生未选课之前，相关信息无法插入。

3.3.2 关系模式的规范化处理 (2)删除异常：如果某系的学生全部毕业，我们在删除该系学生的选课信息时，也把该系及其负责人信息也丢失了，这种现象称为删除异常。 (3)数据冗余大：每一个系负责人的信息要与该系每个学生的每一门课程的成绩出现次数一样多，造成大量数据冗余。不仅浪费存储，而且还会带来下面问题。

3.3.2 关系模式的规范化处理 (4) 更新异常(潜在的数据不一致性)。由于数据存储冗余，当更新某些元组，如某系负责人更换，就可能一部分涉及的元组被修改，而另一部分涉及的元组被忽略，造成存储数据的不一致。否则，必须逐一修改该系每个学生的每门选课元组。造成更新复杂化。

3.3.2 关系模式的规范化处理 • 由于上述4个毛病，我们知道它是一个不好的数据库模式，一个好的模式应当不会发生插入异常、删除异常、数据冗余大、数据不一致。为什么会发生这些异常现象呢？这是因为这个关系模式中函数依赖存在不好的性质. • 将单一模式改造一下，分成三个模式： • S（Snum，Sname,Sdept ） • SG(Snum ，Cname，Grade) • Dept（Sdept，Mname） • 这样的三个模式都不会发生上述三个毛病。

3.3.2 关系模式的规范化处理 2. 问题的根源之所以出现上述的关系模式的异常状况，主要原因之一就是数据冗余；另一点就是本节要讨论的各个属性之间的数据依赖关系。在数据依赖中，函数依赖是最基本的一种数据依赖。它主要表达数据表内各个属性之间的依赖关系。

3.3.2 关系模式的规范化处理 • 函数依赖： • 设R(U)是属性U上的关系模式，X,YU，若对R(U)的任一可能的关系r，若r中任何两个元组在X上的属性值相等，则在Y上的属性值也必相等，则称“X函数确定了Y”或“Y函数依赖于X”。记作：XY。

3.3.2 关系模式的规范化处理 例如：S（Snum，Sdept，Mname，…）对SdeptMname, 若对任意的元组t1,t2有 t1[sdept]=t2[sdept], 则 t1[Mname]=t2[Mname] 注意： (1)函数依赖是语义范畴的概念，我们只能根据语义来确定一个函数依赖。不能杜撰。 (2)另外，函数依赖是对关系模式R的一切关系r均要成立。

3.3.2 关系模式的规范化处理 对于S ( Snum,Sname, Sdept, Mname,Cname, Grade）现实世界的已知事实告诉我们： ①一个学生只有一个名字,有SnumSname ②一个系有若干学生，但一个学生只能属于一个系，有 SnumSdept ③一个系只有一个负责人，Sdept Mname ④一个学生学习每一门课程有一个成绩。有 (Snum,Cname)Grade

部分函数依赖和完全函数依赖 • 在R(U)中，如果XY，并且对于X的任何真子集X(XX)， Y都不函数依赖X，则称Y对X是完全函数依赖，记作XY。但若存在X的真子集X, 使XY，则称Y对X部分依赖。记作：XY. f p 3.3.2 关系模式的规范化处理对上例S表，有

3.3.2 关系模式的规范化处理 • 传递函数依赖 • 在R(U)中，如果XY，YX，YZ, (ZY)则称Z对X是传递函数依赖。 • 说明：条件YX，是因为YX，XY， • 等于XZ是直接函数依赖，而不是传递函数依赖了。

3.3.2 关系模式的规范化处理 • 3. 范式(Normal Form) • 范式是用来判断模式好坏的标准。 • 满足最低范式要求的称为第1范式，在第1范式中满足进一步要求的为第2范式，其余类推。共6种范式,各种范式之间的关系为： • 5NF4NFBCNF3NF2NF1NF

3.3.2 关系模式的规范化处理 (1) 1NF 若关系R的每个分量都是不可再分的数据项，则称R属于第1范式的，简记为R1NF。 (2)2NF 若R1NF，且每一个非主属性都完全函数依赖于键，则R2NF。 (3)3NF 若R1NF，且不存在非主属性对于键的传递函数依赖，则称R3NF。

3.3.2 关系模式的规范化处理 (3)BCNF 若R1NF，XY且YX时，X必含有键，则称RBCNF。即每个决定因素中都包含键。 4. 模式分解规范化是指：一个低一级范式的关系模式，通过模式分解转换为若干高一级范式的关系模式的集合的过程。

3.3.2 关系模式的规范化处理 • 对于一个模式的分解是多种多样的，但是要求分解后产生的模式与原模式等价。 • 模式分解的基本原则： • ① 分解的无损连接性（lossless join） • 设关系模式R（U，F），这里U为R的属性全集，F为R的函数依赖全集，R被分解为若干个关系模式R1，R2，…，Rn，如果R与R1，R2，…，Rn自然连接的结果相等，则称关系模式R的分解具有无损连接性。

3.3.2 关系模式的规范化处理 自然连接的结果与原关系R一致，所以属于无损连接。自然连接的结果与原关系R不一致，元组多了三个，所以属于有损连接。

3.3.2 关系模式的规范化处理 ②分解保持函数依赖设关系模式R（U，F）被分解为若干个关系模式R1，R2，…，Rn，如果R中的函数依赖集F与关系分解模式R1，R2，…，Rn中所有的函数依赖是一致的，则称关系模式R的分解具有保持函数依赖性。

5. 规范化实例分析 3.3.2 关系模式的规范化处理例：已知 S(Snum,Sname,Sdept,Mname,Cname,Grade）分析其达到第几范式，并对它进行规范化，使其达到BCNF。分析:S的函数依赖集为: F={ SnumSname, SnumSdept, Sdept Mname, (Snum,Cname)Grade } ① S中所有属性都是不可再分的数据项。因此S1NF。

3.3.2 关系模式的规范化处理 ②确定S是否2NF S的键是(Snum,Cname),存在非主属性 Sdept对键的部分依赖, 即 (Snum,Cname)  Sdept, 因此S  2NF P • 不是2NF的关系模式，存在的问题： • 插入异常、删除异常、数据冗余大、更新异常。 • 解决办法：模式分解，消除部分依赖: • S1 ( Snum , Sname, Sdept , Mname ) • SC ( Snum , Cname , Grade)

3.3.2 关系模式的规范化处理 ③ 确定是否3NF 对于S1 关系，由于 Snum  Sdept , Sdept  Mname 存在非主属性Mname对键Snum的传递依赖，因此S1  3NF。对于SC关系，不存在非主属性对于键的传递依赖，因此SC  3NF。 • 不是3NF的关系模式，存在的问题： • 插入异常、删除异常、数据冗余大、更新异常。

第 3 章 关系数据库