关系数据库设计范式 PPT课件

– 域（Domain）
属性的取值范围。
– 关系模式
是对关系的描述，格式如下： 关系名（属性1，属性2，…，属性n） 学生（学号，姓名，年龄，性别，系，年级）
关系数据模型的数据结构
实体及实体间的联系的表示方法
– 实体型：直接用关系（二维表）表示。 – 属性：用属性名（列名）表示。 – 一对一联系：隐含在实体对应的关系中。 – 一对多联系：隐含在实体对应的关系中。 – 多对多联系：直接用关系表示。
4
数据结构
4
编译
4
PASC AL 2
性别
女 男 男 女 男
班级代号 年龄
1001
19
1001
20
1001
20
1002
20
1002
19
学生选课
学号
课程号
成绩
801
04
92
801
03
78
801
02
85
802
03
82
802
04
90
803
04
88
2.1.2关系模型的数据操纵
查询、插入、删除、更新 数据操作是集合操作，操作对象和操作结果都
是关系，即若干元组的集合
2.1.3关系模型的完整性约束
实体完整性 参照完整性 用户定义的完整性
1. 实体完整性
实体完整性规则（Entity Integrity） 若属性A是基本关系R的主属性，则属性 A不能取空值 例：学生（学号，姓名，年龄，性别，班级代号）
实体完整性(续)
关系模型必须遵守实体完整性规则的原因 (1) 实体完整性规则是针对基本关系而言的。一个基本表通常对应现
关系数据模型的数据结构(续)

• 对于例5-1，分解为三个新的关系模式：
学生-系（学号，姓名，系名） 学生成绩（学号，课程号，成绩）
系-系主任（系名，系主任名）
2020/12/11
5
• 那么如何判断分解后的三个关系模式是否是 “好”模式呢？
• 这就需要从理论上来解决这个关系数据库的 逻辑设计问题。
• 这个理论就是关系规范化理论，通过分解关 系模式来消除其中不合适的数据依赖，以解 决插入异常、删除异常、更新异常和数据冗 余问题。
• 关系数据库设计需要找到一个“好”的 关系模式，避免数据冗余、避免数据更 新时的各种异常。
2020/12/11
2
5.1 关系数据库设计中出现的问题
【例5-1】试分析以下关系模式是否存在问题。
学生信息（学号，姓名，系名，系主任名， 课程号，成绩），
该关系模式包含如下语义：书71页
通过分析，确定主键为（学号，课程号），但 这是一个“不好”的关系模式。该关系模式主 要存在以下问题：
2020/12/11
14
5.3关系模式的规范化
1、第一范式 定义8 如果一个关系模式R的所有属性都是不
可分的基本数据项，则R∈1NF。
2020/12/11
15
2、第二范式
定义11 如果R∈1NF，且每一个非主属性完全 函数依赖于候选码，则R∈2NF。
• 由定义可以看出2NF在1NF基础上消除了非主 属性对候选码的部分函数依赖。
• 因此，关系模式学生-系不属于第三范式。将
其投影分解，将传递依赖的属性分离出来。分 解为：
学生（学号，姓名，系名）
系（系名，系主任名）
2020/12/11
19
5.4 数据库设计过程
• 数据库设计是软件工程的一个部分，主 要包括6个阶段：需求分析阶段、概念 结构设计阶段、逻辑结构设计阶段、数 据库物理设计阶段、数据库实施阶段、 数据库运行和维护阶段。

R ABC 123 456 789
S ABC 123 258 704
T ABC 456 789
3、交运算（Intersection） 设有关系R和S，它们具有相同的关系模式，
并且对应属性的作用域相同，R与S的交运算结 果生成一个新的关系，由既属于R同时也属于S 的元组组成。记作：
R∩S={t|t∈R∧t∈S}
▲关系操作集合 ➢选择、投影、连接 ➢并、差、交、除 ➢插入、删除、更新、查询
▲关系的完整性约束 ➢关系模型的数据完整性是指数据库中数据的
正确性、相容性和一致性。 ➢数据的完整性由完整性规则来维护，关系模
型的完整性规则是对关系的某种约束，也称为完 整性约束。
➢完整性性约束是为了保证数据库中数据的完 整性对关系模型提出的某种约束条件和规则。
▲关键字（码、键）
能唯一识别一个元组的属性或属性的组合称为 该关系的关键字（在数据表中即为字段或字段的 组合）。
关键字可分为：
➢候选关键字（候选码）
如果一个关系关系中的一个关键字移去了其中 任何一个属性，它就不再是这个关系的关键字， 则称这样的关键字为该关系的候选关键字。
➢主关键字（主码）
一个关系中往往有多个候选关键字，若选定其 中一个用来唯一标识该关系的元组，则称这个被 指定的关键字为该关系的主关键字。
Select gh , xm , zc From js （2）从kc表中查询kcdm和kcmc信息。
Select kcdm , kcmc From kc
3、笛卡尔积运算（Cartrdisn Product）
若需对两个结构不同的关系模式进行合并操作，
则可以用笛卡尔积表示。设关系R有n个属性、p行
R ABC 123 456 789

2020/12/09
3
2.1.2 关系模型 关系模型是用二维表格结构来表示实体及实体间
联系的模型。 关系模型由关系数据结构、关系操作集合和完整
性规则三部分组成。
关系模型的特点： (1) 关系必须规范化，指关系模型中的每一个关系 模式都必须满足一定的要求； (2) 模型概念单一； (3) 集合操作，操作对象和结果都是元组的集合， 即关系。
3. 集合的交运算 设有关系R、S(R、S具有相同的关系模式)，二者的“交”运
算定义为： R∩S={ t|t ∈ R ∧ t ∈ S } 式中“∩”为交运算符，结果R∩S为一个新的与R、S同类的
关系，该关系是由属于R而且属于S的元组构成的集合，即两者所 有的相同的那些元组的集合。
2020/12/09
关系的描述称为关系模式(relation schema)。它可以形式化 地表示为：
R(U，D，Dom，F) 其中R为关系名，U为组成关系的属性名集合，D为属性组 U中属性所来自的域，Dom为属性向域的映像集合，F为属性 间数据依赖关系的集合。
2020/12/09
7
2.3 关系代数
关系数据操作就是关系的运算。关系的基本运算有两类：传 统的集合运算(并、交、差等)和专门的关系运算(选择、投影、联 接)，关系数据库进行数据查询时有时需要几个基本运算的组合。
2020/12/09
4
2.2 关系数据结构及形式化表示
在关系模型中，无论是实体还是实体之间的联系都由单一 的结构类型关系来表示。
2.2.1 关系数据结构
(1) 笛卡儿积(Cartesian Product) 设有一组域D1，D2，…，Dn，这些域可以部分或者全部相同。 域D1，D2，…，Dn的笛卡儿积定义为如下集合： D1×D2 × … × Dn={(d1,d2, …,dn)|di∈Di，i=1，2， …，n} 其中每一个元素(d1,d2, …,dn)称为一个n元组(或简称元组)，元素 中的每一个值称为一个分量。

数据库第6章-关系范式规范 化理论
6. 关系数据理论
6.1 问题的提出 6.2 规范化
6.1 问题的提出
关系数据库的逻辑设计
针对具体问题，如何构造一个适合于它的数 据模式 数据库逻辑设计的工具──关系数据库的规 范化理论
二、关系模式的形式化定义
一个关系模式由五部分组成，即是一个五元组： R（U， D， DOM， F）
解决方法如下：
☺把关系模式 S <U, F>分解为3个关系模式：
S（Sno，Sdept，Sno Sdept）； SG（Sno,Cname,Grade,(Sno,Cname)Grade)；
Dept（Sdept，Mname，SdeptMname）
6.2 规范化
规范化理论 正是用来改造关系模式，通过分解 关系模式来消除其中不合适的数据依赖，以解 决插入异常、删除异常，和数据冗余问题。
1. 数据冗余太大 ➢ 在每个学生元组中，系主任姓名重复出现浪费大量存储
空间
☺另外，如果某个系的系主任换人了，就要更改每个学生
的元组，维护代价很大
2. 插入异常
☺如果一个系刚成立尚无学生（没有Sno），就无法把这个
系及其系主任的信息存入数据库
3. 删除异常
☺如果某个系的学生全部毕业了，Sno将被全部删除，同时
规范化：通过分析关系（关系模式）中存在的 弱点，将该关系分解为若干个高一级的关系。
范式：关系规范化的程度称为范式，1NF， 2NF，3NF，BCNF
6.2.1 函数依赖
一、函数依赖 二、平凡函数依赖与非平凡函数依赖 三、完全函数依赖与部分函数依赖 四、传递函数依赖
一、函数依赖
定义6.1 设R(U)是一个属性集U上的关系模式 ,X和Y是U的子集。 若对于R(U)的任意一个可 能的关系r，r中不可能存在两个元组在X上的 属性值相等， 而在Y上的属性值不等， 则称 “X函数确定Y” 或 “Y函数依赖于X”，记作 X→Y。

影响数据库模式的主要是U和F，因此，关系简化三元 组为R（U，F）
4-
5
4.1 数据依赖
4.1.1 关系模式的形式化定义 4.1.2 函数依赖与存储异常 4.1.3 有关概念
4-
6
4.1.2 函数依赖与存储异常
数据依赖：通过一个关系中属性间值的相等与 否体现出来的数据间的相互关系的抽象，是数 据内在的性质，是语义的体现。
4-
20
4.2.1 1NF
例.SCL(Sno,Sdept,Sloc学生住处,Cno,Grade)假 设每个系学生住在同一地方.
该关系满足1NF
存在问题:
(1)插入异常 若要插入
3.插入异常:如一个系刚成立,尚无学生,则无法把系信息 存入
4.删除异常:如某系学生全毕业,学生全删,则系信息也丢 了.
鉴于以上种种,Student不是一个好的模式
以上四个问题称为存储异常
4-
9
4.1.2 函数依赖与存储异常
一个”好”的模式应当不会发生存储来自常：插入异常 更新异常 删除异常 数据冗余多
Y X,YZ, 则称Z对X传递函数依赖；
例：上例中SnoSdept SdeptMname 则 SnoMname
4-
15
4.1.3 有关概念
5.码（关键字） 定义:设K为R<U,F>中的属性或属性组合，若 K F U，则K为R的侯选码(Candidate key). 若
侯选码多于一个，则选定其中的一个为主码 (Primary key). 例：student中Sno F U（完全决定），则Sno为 主关键字
(Sno,Cname)Grade
4-
8
4.1.2 函数依赖与存储异常

数据库管理系统
现实世界随着时间在不断地变化，因而在不同的时 刻，关系模式的关系也会有所变化。但是，现实世界的 许多已有事实限定了关系模式所有可能的关系必须满足 一定的完整性约束条件。
这些约束或者通过对属性取值范围的限定，或者通过 属性值间的相互关连(主要体现于值的相等与否)反映出 来。后者称为数据依赖，它是数据模式设计的关键，关 系模式应当刻划这些完整性约束条件。
数据的冗余度尽量低。 不出现插入、删除等操作异常； 能尽量如实反映现实世界的实际情况，而且又 易懂。 这就要求研究关系模式中各属性之间的依赖关 系，及其对关系模式性能的影响，探讨关系模式应 满足什么样的约束，这就是关系规范化的目的。
数பைடு நூலகம்库管理系统
关键字
学号 姓名 SNO sname
2001 李样
年龄 系 系主任 课程号
Cname)→Grade }
数据库管理系统
我们就得到了一个描述学校的数据库模式S〈U，F 〉：
U = { Sno，Sdept，Mname，Cname， Grade }
F = { Sno→Sdept，Sdept→Mname，(Sno ，Cname)→Grade }
数据库管理系统
3.2关系的规范化
设计一个的关系数据库，首先要定义一组关系， 这组关系定义的好，系统的性能就好，定义的差， 系统的性能就差。一般的设计原则是：
同样课程信息的操作也存在着插入异常、删除异常和数 据冗余。
数据库管理系统
上述问题出现的原因
上述问题的出现是因为在学生关系的属性之间存在
着数据依赖。
该关系的关键字是SNO（学号）+CNO（课程号）
属性dept(系)和mn（系主任）仅与SNO（学号）有关

❖ 在bor_loan模式中，loan_number不是候选 码，loan的amount将会被重复。也就是说， 我们需要分解bor_loan
S.J.T.U.
更小的模式 (续…)
❖ 并不是所有的分解都是有益的，假定我们将 employee分解为：
▪ employee1 = (employee_id, employee_name) ▪ employee2 = (employee_name, telephone_number,
▪ 范例：customer_street customer_city
S.J.T.U.
子的 ▪ 这种做法并不好：使得解析信息的工作将由应用程序
完成，而不是数据库。
S.J.T.U.
目标：设计以下理论
❖ 判断一个关系R是否属于良好的范式 ❖ 关系R不属于良好范式的情况：将其分解为关系
集合{R1, R2, ..., Rn} ：
▪ 其中每个关系均属于良好的范式 ▪ 分解是无损的
❖ 我们的理论基于：
❖ 无冗余
S.J.T.U.
更小的模式
❖ 假定我们开始得到的是bor_loan模式，我们应 如何将其分解为borrower和loan？
❖ 写一条规则“如果存在模式(loan_number, amount)，则loan_number应该是候选码”
❖ 表示为函数依赖：
▪ loan_number amount
关系数据库设计
S.J.T.U.
关系数据库设计
❖ 好的关系设计的特点 ❖ 原子域和第一范式 ❖ 使用函数依赖的分解 ❖ 函数依赖理论 ❖ 分解的算法 ❖ 使用多值依赖的分解 ❖ 更多的范式 ❖ 数据库设计过程 ❖ 时态数据建模
S.J.T.U.

isbn → category_tag
BookInfo的决定组合（isbn，author_id,category_id）
码
定义5.2 设K为R〈U,F〉中的属性或属性组合,若K U，则称K为R的一
个候选码（Candidate key）。若R中有多个候选码，则选定其中的一 个做为主码（Primary key）。
3
5.1 问题的提出
关系数据库逻辑设计
针对具体问题，如何构造一个适合于它的数据模式 数据库逻辑设计的工具──关系数据库的规范化理论
例如：与之前的在线书店数据库的关系模式不同，我们将 图书的信息保存在一个单独的关系模式BookInfo中：
BookInfo ( ISBN, title, author_id, author_name, serial, press, price, category_id, category_tag)
第5章 关系数据库 设计
数据库原理及应用 郑轶（2010）
1
第一部分
整体概述
THE FIRST PART OF THE OVERALL OVERVIEW, PLEASE SUMMARIZE THE CONTENT
2
目录
5.1 5.2 5.3 5.4
问题的提出 函数依赖 关系模式的分解 范式及其规范化
当且仅当U上的一个关系 r 满足F时,r称为关系模式R 〈U,F〉的一个关系。
7
函数依赖的定义
函数依赖（Functional Dependency, FD)
定义5-1 设有关系模式R(U),X和Y是属性集U的子集，若 对R(U)的任意一个可能的关系r，r中不可能存在两个元 组在X上的属性值相等，而在Y上的属性值不等，则称X函 数确定Y，或Y函数依赖于X，记作X→Y。

4
假定选课关系表为SelectCourse(学号, 姓名, 年龄, 课程名称, 成绩, 学分)，关键字为组合关键字(学号, 课程名称)，因为存在如下决定关系：
(学号, 课程名称) → (姓名, 年龄, 成绩, 学分)
在这个数据库表中，有某些依赖不满足第二范式的 要求，分析以下关系哪些符合第二范式哪些不符合：
(2) 更新异常：
若调整了某门课程的学分，数据表中所有行的"学分"值都要 更新，否则会出现同一门课程学分不同的情况。
(3) 插入异常：
假设要开设一门新的课程，暂时还没有人选修。这样，由于 还没有"学号"关键字，课程名称和学分也无法记录入数据库。
(4) 删除异常：
假设一批学生已经完成课程的选修，这些选修记录就应该从 数据库表中删除。但是，与此同时，课程名称和学分信息也被删 除了。很显然，这也会导致插入异常。
(课程名称) → (学分) (学号) → (姓名, 年龄) (学号, 课程名称) → (成绩)
解决办法：将部分依赖的属性和这个被部分依赖的主属 性从原表中分离，形成一个新表。
5
由于不符合2NF，这个选课关系表会存在如下问题：
(1) 数据冗余：
同一门课程由n个学生选修，"学分"就重复n-1次；同一个 学生选修了m门课程，姓名和年龄就重复了m-1次。
7
为下表找出关键字组，并分析它是否符 合第二范式：
课程号 教师号 课程名 教师名 所在教室 上课时间
8
第三范式（3NF）
满足第三范式（3NF）必须先满足第二范式 （2NF）。
第三范式（3NF）要求一个数据库表中不包含 已在其它表中已包含的非主关键字信息。
例如，存在一个部门信息表，其中每个部门有 部门编号（dept_id）、部门名称、部门简介 等信息。那么在员工信息表中列出部门编号后

Ｄ１×Ｄ２ × … ×Ｄｎ＝{（d1,d2, … ,dn）| di∈Ｄ
i,i=1,2, …,n}
其中每一个元素（d1,d2, … ,dn）叫做一个n元组或简称 元组，元素中的每一个值di叫做一个分量。
10 10
• 例：关系account的三个属性branchname,account-name,balance对应三个域
Ｄ１=(CCB,BOC) Ｄ２=(A-101,A-102) Ｄ3=(500,400) 则笛卡儿积为： Ｄ１×Ｄ２ × Ｄ3＝ {(CCB, A-101, 500),(CCB, A-101,400), (CCB, A-102,500),(CCB, A-102,400), (BOC, A-101,500),(BOC, A-101, 400), (BOC, A-102,500),(BOC, A-102,400)}
11 11
还可表示为
D1 CCB CCB CCB CCB BOC BOC BOC BOC
D2
D3
A-101
500
A-101
400
A-102
500
A-102
400
A-101
500
A-101
400
A-102
500
A-102
400
12 12
• 3、关系
Ｄ１×Ｄ２ × … ×Ｄｎ的子集叫做在域Ｄ１，Ｄ２， …Ｄ ｎ上的关系，表示为R（Ｄ１，Ｄ２ ，… ，Ｄｎ），n是 关系的目或度。 关系中的每个元素是关系中的元组。 – n＝1时，称该关系为单元关系。 – n＝2时，称该关系为二元关系。 • 关系中元组的个数与域的基数有关，例如上例中元组 的个数为2×2×2＝8。
是虚表，不对应实际存储的数据。
16 16

部类型和成分之间“is part of”的语义，在 E-R 模型中，若干属性的聚集所组成的实体型就是这 种抽象，如图5.7所示。
图5.7 聚集
NINGBO University of Technology
概括(Generalization) 定义类型之间的一种子集联系。它抽象了类
型之间的“is subset of”的语义。例如学生是一 个实体型，本科生、研究生也是实体型。本科生 、研究生均是学生的子集。把学生称为超类 (Superclass)，本科生、研究生称为学生的子类 (Subclass) ，如图5.8所示。
为以下六个阶段： 阶段1:需求分析阶段
第1步：了解和分析用户的应用需求（包括 数据与处理），进行需求收集和分析。
阶段2:概念结构设计阶段 第2步：对用户需求进行综合、归纳与抽象， 形成一个独立于具体RDBMS的概念数据模 型。
NINGBO University of Technology
阶段3:逻辑结构设计阶段
NINGBO University of Technology
阶段5:数据库应用系统实施阶段 第7步：运用RDBMS提供的数据语言及其 宿主语言，根据逻辑设计和物理设计的结 果建立数据库，编制与调试数据库应用系 统的程序，并组织数据入库；通过对程序 的试验性运行，来判断对数据库实施满意 程度，如不满意则转第5步进行。
数，金额} 应收帐款：{顾客号，订单号，发票号，应收
金额，支付日期，当前余额，贷款限额} 产品描述：{产品号，产品名，单价，重量} 折扣规则：{产品号，订货量，折扣}
[注] 为了节省篇幅，实体与属性的关系没有用图 形表示，实体的键码用下划线表示。
NINGBO University of Technology

并不是所有的分解都是 有益的 如将 employee 表分解
该分解是有损的，即 无法通过自然连接重 建原模式
更小的模式—实例分析3
模式S-C-M（S学号，C班级，M班主任）
该模式设计不好，存在数据冗余、插入异常、删除异常和更新异常 以下哪一个分解是好的呢？
1{SC (学 号 ， 班 级 )， CM (班 级 ， 班 主 任 )} 2{SC (学 号 ， 班 级 )， SM (学 号 ， 班 主 任 )} 3{SM (学 号 ， 班 主 任 )， CM (ห้องสมุดไป่ตู้ 级 ， 班 主 任 )}
更大的模式—实例分析2
方案1：loan_branch = (loan_number, branch_name) loan = (loan_number, amount)
方案2：loan_amt_br = (loan_number, amount, branch_name) 显然，方案2对应的表不必连接运算，且没有信息冗余
模式分解可以消除冗余，解决更新异常等问题，但也要付出 做连接运算等昂贵的代价
函数依赖
定义 设R(U)是属性集U上的关系模式。X,Y是U的子集。若 对于R(U)的任意一个可能的关系r，r中不可能存在两个 元组在X上的属性值相等，而在Y上的属性值不等，则 称X函数确定Y或Y函数依赖于X，记作 XY
术语和记号 XY，但 Y X ，则称 XY 是平凡函数依赖 XY，但 Y X ，则称 XY 是非平凡函数依赖
更大的模式—实例分析1
方案1：borrower = (customer_id, loan_number) loan = (loan_number, amount)
方案2：bor_loan = (customer_id, loan_number, amount) 显然，方案2对应的表不必连接运算，但可能出现信息冗余