关系数据库设计实例(20190417224320)
- 格式：docx
- 大小：17.59 KB
- 文档页数：3
文档推荐
-
规范化设计的必要性在关系数据库设计中页数:118
-
关系数据库设计理论练习题答案页数:6
-
关系数据库设计理论练习题答案页数:6
-
关系数据库设计理论练习题(答案)页数:6
下载文档原格式
合集下载
关系数据库模型与关系数据库设计精品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) 实体完整性规则是针对基本关系而言的。一个基本表通常对应现
关系数据模型的数据结构(续)
属性的取值范围。
– 关系模式
是对关系的描述，格式如下： 关系名（属性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章 关系数据库设计PPT教学课件
• 对于例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个阶段：需求分析阶段、概念 结构设计阶段、逻辑结构设计阶段、数 据库物理设计阶段、数据库实施阶段、 数据库运行和维护阶段。
学生-系（学号，姓名，系名） 学生成绩（学号，课程号，成绩）
系-系主任（系名，系主任名）
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个阶段：需求分析阶段、概念 结构设计阶段、逻辑结构设计阶段、数 据库物理设计阶段、数据库实施阶段、 数据库运行和维护阶段。
数据库课件 第六章 关系数据库设计理论优秀课件
注：主码和外码一起提供了表示关系间联系的手段。
6.3 规范化
• 范式是对关系数据库的规范化过程中为不同 程度的规范化要求设立的不同标准。
• 范式是符合某一种级别的关系模式的集合。
• 范式的种类： 第一范式(1NF) 第二范式(2NF) 第三范式(3NF) BC范式(BCNF) 第四范式(4NF) 第五范式(5NF)
6.1 问题的提出
存在的问题： ⒈ 数据冗余太大
– 浪费大量的存储空间 ⒉ 更新异常
– 更新代价大，可能导致数据不一致 ⒊ 插入异常
– 该插的数据插不进去 ⒋ 删除异常
– 不该删除的数据不得不删，造成某些数据丢失
6.1 问题的提出
结论： • WAE关系模式不是一个好的模式。 • “好”的模式：不会发生插入异常、删除异常、 更新异常，数据冗余应尽可能少。
例：在关系wae中有：
仓库号→所在区域，所在区域→区域主管 可得到传递函数依赖：仓库号 t 区域主管
6.2.2 码
定义6.5 设K为R<U,F>中的属性或属性组合。若 K F U，则K称为R的一个侯选码。 若关系模式R有多个候选码，则选定其中的一 个做为主码。 • 主属性：包含在任何一个候选码中的属性
注：对任一关系模式，平凡函数依赖必然存在，则一般讨论非平凡函 数依赖。
6.2.1 函数依赖
• 完全函数依赖与部分函数依赖 定义6.3 在R(U)中，如果X→Y，并且对于X的任何 一个真子集X’ ，都有X’ → Y, 则称Y对X完全函数依 赖，记作X ｆ Y。
若X→Y，但Y不完全函数依赖于X，则称Y对X 部分函数依赖，记作X P Y。
注：当确定函数依赖关系时,可从属性间的联系入手
6.2.1 函数依赖
6.3 规范化
• 范式是对关系数据库的规范化过程中为不同 程度的规范化要求设立的不同标准。
• 范式是符合某一种级别的关系模式的集合。
• 范式的种类： 第一范式(1NF) 第二范式(2NF) 第三范式(3NF) BC范式(BCNF) 第四范式(4NF) 第五范式(5NF)
6.1 问题的提出
存在的问题： ⒈ 数据冗余太大
– 浪费大量的存储空间 ⒉ 更新异常
– 更新代价大，可能导致数据不一致 ⒊ 插入异常
– 该插的数据插不进去 ⒋ 删除异常
– 不该删除的数据不得不删，造成某些数据丢失
6.1 问题的提出
结论： • WAE关系模式不是一个好的模式。 • “好”的模式：不会发生插入异常、删除异常、 更新异常，数据冗余应尽可能少。
例：在关系wae中有：
仓库号→所在区域，所在区域→区域主管 可得到传递函数依赖：仓库号 t 区域主管
6.2.2 码
定义6.5 设K为R<U,F>中的属性或属性组合。若 K F U，则K称为R的一个侯选码。 若关系模式R有多个候选码，则选定其中的一 个做为主码。 • 主属性：包含在任何一个候选码中的属性
注：对任一关系模式，平凡函数依赖必然存在，则一般讨论非平凡函 数依赖。
6.2.1 函数依赖
• 完全函数依赖与部分函数依赖 定义6.3 在R(U)中，如果X→Y，并且对于X的任何 一个真子集X’ ，都有X’ → Y, 则称Y对X完全函数依 赖，记作X ｆ Y。
若X→Y，但Y不完全函数依赖于X，则称Y对X 部分函数依赖，记作X P Y。
注：当确定函数依赖关系时,可从属性间的联系入手
6.2.1 函数依赖
《数据库系统》：关系数据库设计
《数据库系统》：关系数据库设计关系数据库设计关系数据库设计的⽬的是得到⼀组合适的关系模式，使其不含冗余，结构良好，便于获取信息。
概念和数学基础码超码：⼀个或多个属性的集合，这个集合可以唯⼀地区分出⼀个元组（⼀⾏）候选码：包含属性最少的超码，可能有多个主码：⼈为地选中，作为⼀⾏的区分标准的候选码。
本节中候选码更常⽤另⼀个常⽤的码是外码，与本节⽆关，不详细介绍函数依赖函数依赖是⼀个形如 α→β 的逻辑推理式，表⽰属性集 α 决定(determine)属性集 β ，或称 β 依赖 α . 同⼀模式中包含的多条函数依赖称为函数依赖集。
例如，R 上的两个属性 α 和 β ，如果关系实例中的所有元组对 t1，t2 都符合 若 t1[α]=t2[α] ，则 t1[β]=t2[β]。
也就是说，只要我们知道 α 的值，就能唯⼀确定 β 的值，称 α 决定β 。
特别地，如果β⊆α，称为平凡的函数依赖。
由此，我们得出超码的新定义：对于关系R和函数依赖集K，若 K→R 在 r(R) 上成⽴，则 K 是 r(R) 的⼀个超码。
闭包有了函数依赖集F，我们就可以由已知的函数依赖得出其他的函数依赖。
如 r(A,B,C)中有A→B,B→C，则 A→C（具体推理⽅法见下⽂Armstrong公理）。
类似的推理被称为逻辑蕴涵。
不断将这些新的函数依赖加⼊F，最终能够得到⼀个被原F逻辑蕴涵的所有函数依赖的集合，称为F的闭包，记作 F+.Armstrong公理系统反复运⽤以下三条Armstrong公理，就能通过F求出F+，保证结果是正确有效的。
⾃反律：若α为⼀属性集，β⊆α，则α→β增补律：若α→β，γ为⼀属性集，则γα→γβ传递律：若α→β且β→γ，则α→γArmstrong公理是完备的。
下⾯还有⼀些推论规则，使⽤起来更⽅便。
合并律：若α→β且α→γ，则α→βγ分解律：若α→βγ，则α→β且α→γ伪传递律：若α→β且γβ→δ，则αγ→δ属性闭包与函数依赖集的闭包相似，属性闭包是某⼀属性（或属性集）决定的所有属性的集合。
数据库第四章 关系数据库设计理论PPT课件
影响数据库模式的主要是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 函数依赖与存储异常
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 函数依赖与存储异常
第6章关系数据库设计实例
业务规则分析
– 配送单的配送状态记录了该配送单的当前配送情况：未发货、 已发货、已送到等。
– 订单中的订单状态记录了该订单的当前处理情况：未审核、退 回、已审核、已部分配送、已全部配送、已处理结束等。
– 订单明细的配送状态记录了该图书的当前配送情况：未配送、 已部分配送、已全部配送等。
– 当订单中的某种图书全部送到后，则更新该图书的配送状态为 “已全部送到”。当订单内全部图书的配送状态为“已全部送 到”时，则更新该订单的订单状态为“已处理结束”。
– 选书完成后，会员填写配送信息、发票单位及选择支付方式。 配送信息默认为会员注册时填写的基本信息，也可重新填写。
– 确认所填信息后，提交生成订单。每张订单记录：订单号、订 购日期、应收总金额、会员折扣、实收总金额、付款方式、订 单状态、订单明细(ISBN、书名、订购数量、定价、应收金额、 图书折扣、实收金额、配送状态)和发票信息(如发票单位等)。
– 图书入库。当订购的图书到货后办理图书入库，并 增加新图书信息、更新图书库存数量。入库单：入 库单号、出版社、入库日期、入库人、收货人、入 库明细(ISBN、书名、入库数量)等。
功能需求及数据需求分析
• 在线订书
– 会员登录后，选购图书放入购物车中，并填写购买数量。购物 车中的图书可增加、删除和修改，并自动统计图书总价格。
– 如果选择在线支付方式，则还需进行网上结算。若余额不足， 则取消订单（本设计不作考虑）。
功能需求及数据需求分析
• 配送管理
– 假设一张订单所订购的图书可拆分成不同的配送 单发货，但一个配送单不能包含不同订单的图书。
– 会员在生成订单之后需要进一步进行配送设置， 包括填写配送信息(收货人、送货地址、邮政编码、 联系电话等) ，定义配送明细(ISBN、书名、配送数 量等) 。
关系数据库设计范式
4
第一范式(1NF)
数据库表的每一列都是不可分割的基本数据项，同一列中 不能有多个值，即实体中的某个属性不能有多个值或者不 能有重复的属性。
“注塑备件”表示产品类型
“已经不用”表示 记录的状态是否可用
被设置成“已经不用”的小件，无法查看到他原来的类型！！
© Yanfeng Plastic Omnium Proprietary / All Rights Reserved
2
范式的作用
更好的解决:
数据冗余，数据有效性和存储 效率等问题
© Yanfeng Plastic Omnium Proprietary / All Rights Reserved
3
常用范式
© Yanfeng Plastic Omnium Proprietary / All Rights Reserved
√
×
疑问：
如果没有包装类型，那产品的安全库存，最低最高库存在哪里定义？？？
© Yanfeng Plastic Omnium Proprietary / All Rights Reserved
7
第三范式
一个数据库表中不包含已在其它表中已包含的非主关键 字信息!!!
© Yanfeng Plastic Omnium Proprietary / All Rights Reserved
关系数据库设计范式
什么是范式(Normal Form)？
设计范式（范式,数据库设计范式,数据库的设计范式） 是符合某一种级别的关系模式的集合
构造数据库必须遵循一定的规则。在关系数据 库中，这种规则就是范式。
© Yanfeng Plastic Omnium Proprietary / All Rights Reserved
数据库5版讲稿第七章---关系数据库设计
学号→姓名 学号→学号姓名性别年龄系别 如果设计者强行规定所有学生都不重名，则 姓名→学号 姓名→性别年龄系别 姓名→学号姓名性别年龄系别。
2020/10/28
数据库系统概念----关系数据库设计
22
7.3 函数依赖的分解
函数依赖的类型
1．平凡函数依赖
如果Y X ，按定义，则X→Y，称平凡函 数依赖，否则为非平凡函数依赖
数据库系统概念----关系数据库设计
33
7.4 函数依赖理论
2．函数依赖集的逻辑蕴涵定义
设F是关系模式R的一个函数依赖集，X、 Y是R的属性子集，如果从F中的函数依赖 能够推出X→Y，则称F逻辑蕴涵X→Y。
3 . 函数依赖的推理规则
设R=(U)，F是R的函数依赖集，X、Y、Z 均是U的子集，推理规则如下：
26
7.3 函数依赖的分解
学号课程号系别→学号姓名性别年龄系 别系主任名系办公电话，课程号课程名 先行课号成绩，学号课程号系别是超码
例如：教学参考书=（教师名，课程名， 参考书名），M：N：P联系
教学参考书模式中没有任何依赖 全码：教师名课程名参考书名
2020/10/28
数据库系统概念----关系数据库设计
32
7.4 函数依赖理论
函数依赖集的逻辑蕴涵 1．引例 给定R=(A，B，C)，F=｛A→B,B→C｝，
由传递函数依赖定义，A→C也成立。 给定R=(U)，通过语义说明可以得到函数
依赖集F，通过推理规则可以得到F之外的 函数依赖。因此说，F只是R=(U)全部函数 依赖的一部分。
2020/10/28
29
7.3 函数依赖的分解
存在非主属性部分依赖于码： 学号→姓名 等， 课程号→课程名 等 学生∈1NF 注意： （1）如果关系模式的每个侯选码只含一
2020/10/28
数据库系统概念----关系数据库设计
22
7.3 函数依赖的分解
函数依赖的类型
1．平凡函数依赖
如果Y X ，按定义，则X→Y，称平凡函 数依赖，否则为非平凡函数依赖
数据库系统概念----关系数据库设计
33
7.4 函数依赖理论
2．函数依赖集的逻辑蕴涵定义
设F是关系模式R的一个函数依赖集，X、 Y是R的属性子集，如果从F中的函数依赖 能够推出X→Y，则称F逻辑蕴涵X→Y。
3 . 函数依赖的推理规则
设R=(U)，F是R的函数依赖集，X、Y、Z 均是U的子集，推理规则如下：
26
7.3 函数依赖的分解
学号课程号系别→学号姓名性别年龄系 别系主任名系办公电话，课程号课程名 先行课号成绩，学号课程号系别是超码
例如：教学参考书=（教师名，课程名， 参考书名），M：N：P联系
教学参考书模式中没有任何依赖 全码：教师名课程名参考书名
2020/10/28
数据库系统概念----关系数据库设计
32
7.4 函数依赖理论
函数依赖集的逻辑蕴涵 1．引例 给定R=(A，B，C)，F=｛A→B,B→C｝，
由传递函数依赖定义，A→C也成立。 给定R=(U)，通过语义说明可以得到函数
依赖集F，通过推理规则可以得到F之外的 函数依赖。因此说，F只是R=(U)全部函数 依赖的一部分。
2020/10/28
29
7.3 函数依赖的分解
存在非主属性部分依赖于码： 学号→姓名 等， 课程号→课程名 等 学生∈1NF 注意： （1）如果关系模式的每个侯选码只含一
第八章 关系数据库设计-PPT精选文档
第八章
关系数据库设计
数据库设计的步骤
数据库设计是综合运用计算机软、硬件技术， 结合应用系统领域的知识和管理技术的系统工程。 • 数据库设计归纳为如下几个阶段：
1.需求分析阶段 2.概念结构设计阶段 3.逻辑结构设计阶段 4.物理结构设计阶段 5.实施阶段 6.使用与维护阶段
第八章
关系数据库设计
ห้องสมุดไป่ตู้
需求分析
（1）信息要求：了解用户将从数据库中获得信 息的内容、性质，数据库应用系统用到的所有基 础信息类型及其联系，了解用户希望从数据库中 获得哪些类型的信息，数据库中需要存储哪些数 据。 （2）处理要求：了解用户希望数据库应用系统 对数据进行什么处理，对各种数据处理的响应时 间的要求，对各种数据处理的频率的要求，对数 据处理方式的要求是批处理还是联机处理等。
第八章
关系数据库设计
第八章 关数据库设计
8.1.1 E-R模型的设计方法
• 自顶向下 • 自底向上 • 逐步扩张 • 混合策略 通常情况下，是自顶向下进行需求分析； 再自下向上进行概念设计。
第八章
关系数据库设计
第八章 关数据库设计
E-R模型的设计实例 • “阳光超级市场信息管理系统”是一个包含商 品信息管理、员工信息管理、销售信息管理、仓 储信息管理、采购信息管理和财务信息管理子系 统的综合信息管理系统。 • 设计这样一个综合系统E-R模型，由于实体集 个数较多，实体集中实体公共属性较多，实体集 之间的相互关联关系复杂，直接绘制一个E-R模 型图相对复杂，通常采用的设计思想是：“化全 局”为“局部”，再做“局部集成”。
关系数据库设计
第八章 关系数据库设计
Access属于关系型数据库管理系统之一。关系数据 库设计就是针对具体的应用问题，进行信息的抽象，构造 优化概念模型，设计最佳的逻辑模型和物理结构，并以此 为依据建立关系型数据库及应用系统。通过设计减少数据 冗余，达到一定范围内的数据共享，满足用户对信息和信 息处理的需求。 其主要内容就是：概念模型、逻辑模型和物理模型， 以及关系模式的规范化。 在进行数据库开发的过程中，数据库模式一经设计完 成，通常情况下是不轻易改动的，它不仅作为应用程序存 取数据、处理数据的数据结构参照，还要成为实现数据物 理存储的数据结构定义的依据
关系数据库设计范式(实例介绍) 完
关系数据库设计范式1、第一范式（1NF）：无重复的列所谓第一范式（1NF）是指数据库表的每一列都是不可分割的基本数据项，同一列中不能有多个值，即实体中的某个属性不能有多个值或者不能有重复的属性。
如果出现重复的属性，就可能需要定义一个新的实体，新的实体由重复的属性构成，新实体与原实体之间为一对多关系。
在第一范式（1NF）中表的每一行只包含一个实例的信息。
简而言之，第一范式就是无重复的列。
（说明：在任何一个关系数据库中，第一范式（1NF）是对关系模式的基本要求，不满足第一范式（1NF）的数据库就不是关系数据库。
）2、第二范式（2NF）：属性完全依赖于主键[消除部分子函数依赖]第二范式（2NF）是在第一范式（1NF）的基础上建立起来的，即满足第二范式（2NF）必须先满足第一范式（1NF）。
第二范式（2NF）要求数据库表中的每个实例或行必须可以被惟一地区分。
为实现区分通常需要为表加上一个列，以存储各个实例的惟一标识。
例如员工信息表中加上了员工编号（emp_id）列，因为每个员工的员工编号是惟一的，因此每个员工可以被惟一区分。
这个惟一属性列被称为主关键字或主键、主码。
第二范式（2NF）要求实体的属性完全依赖于主关键字。
所谓完全依赖是指不能存在仅依赖主关键字一部分的属性，如果存在，那么这个属性和主关键字的这一部分应该分离出来形成一个新的实体，新实体与原实体之间是一对多的关系。
为实现区分通常需要为表加上一个列，以存储各个实例的惟一标识。
简而言之，第二范式就是属性完全依赖于主键。
3、第三范式（3NF）：属性不依赖于其它非主属性[消除传递依赖]满足第三范式（3NF）必须先满足第二范式（2NF）。
简而言之，第三范式（3NF）要求一个数据库表中不包含已在其它表中已包含的非主关键字信息。
例如，存在一个部门信息表，其中每个部门有部门编号（dept_id）、部门名称、部门简介等信息。
那么在的员工信息表中列出部门编号后就不能再将部门名称、部门简介等与部门有关的信息再加入员工信息表中。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
第 6 章关系数据库设计实例——网上书店学习目标
通过本章学习，加深对 E-R 模型和关系数据理论的进一步理解，并熟练掌握关系数据
库的设计步骤与方法，从而具备正确设计关系数据库的基本能力。
另外，在学习过程
中还要体会到，正确的数据库设计不是一蹴而就的，它是一个循序渐进和反复设计的过
程。
学习方法
本章主要介绍如何将所学的数据库设计理论指导具体应用设计实践。
在学习本章内
容的同时，要多回顾和复习前两章所学内容。
在进行需求分析和建立 E-R 模型时，能运用抽象方法对具体应用业务流程和系统功能进行分析、提炼和归纳。
学习指南
重点：需求分析，包括业务需求分析、功能需求分析和业务规则分析；
如何确定实体集及属性和确定联系集及 E-R 图；检查是否满足需求；逻辑数据库设计。
难点：如何检查是否满足需求。
本章导读
本章综合运用第 4 章和第 5 章所学知识，给出了一个完整的关系数据库设计实例。
在学习时，要学会如何在需求描述的基础上进行需求分析，如何根据需求分析确定实体
集、联系集及其属性，如何根据得到的 E-R 图生成关系模式，以及如何对得到的关系模式进
行求精。
在学习本章之前，要回顾以前学过的知识：
1.数据库设计通常包括哪几个步骤？各个步骤之间的联系是什么？
2.为什么要进行需求分析？
3.需求分析的任务是什么？有哪些需求分析方法？
4.为什么不能直接设计出数据库的关系模式，而要先设计概念模式？
5.请至少列出两种可用于描述概念模式的工具，并对它们进行比较。
6.E-R 模型是如何表达概念模式的？
7.如何确定实体集和联系集？实体集和联系集的主码分别是如何确定的？
8.E-R 模型的设计原则是什么？
9.数据在关系模型是如何表示的？
10.如何通过 E-R 图得到关系模式？
11.数据冗余会带来什么问题？关系模式分解又会带来什么问题？
12.什么样的关系模式是一个“好”的关系模式？
13.什么是关系模式的范式？如何判断一关系模式属于哪一范式？
14.如何进行 BCNF 和 3NF 范式分解？本章教学设计
任课教师
教
学
设
计
一
教
学
设
计
二
教
学
设
计
三
刘爱红计划课时 6 课时上课地点250
1
第 6 章关系数据库设计实例——网上书店
本章主要是以案例驱动的方法，将学生重新分 4 组，分别完成用户管理、商品管理、订单及配送管理、留言管理等功能。
由于书上有数据
库设计的参考信息，要求每一组学生能根据现有材料做更为详细合理的
分析，提出新的方法和思路，供同学们深入讨论和补充。
为鼓励学生积极参与和思考，进一步提高学生的学习兴趣和学习热
情，增强他们的自信心，原则上奖励每一组同学的进步和成绩，对热别
优秀的小组和学生给予“表现好”的课堂表现成绩并在全班表扬这些学
生。
6.1需求描述和系统边界：参考信息见教学内容。
6.2定义需求分析：参考信息见教学内容。
6.3确定实体集及属性：参考信息见教学内容。
6.4确定联系集及E-R 图：参考信息见教学内容。
6.5检查是否满足需求：参考信息见教学内容。
6.6逻辑数据库设计：参考信息见教学内容。
6.7模式求精：参考信息见教学内容。
6.8 进一步思考：参考信息见教学内容。
这部分信息要求每一组同学必
须作出进一步补充和细化，真正掌握数据库设计的基本方法。
最后，可以让同学们谈谈这次大讨论的感受、收获以及不解之处，
以便更好地完成大作业。
*****温馨提示*****
同学们必须要完成大作业的概念设计了，做好的同学可以提交到
FTP、 QQ或邮箱了，老师要分别给每个小组同学指导概念设计。
本章教学内容
见附件 6.
本章小结
本章综合运用前两章所学知识，给出了一个网上书店的数据库设计实例，包括需求
分析、概念数据库设计和逻辑数据库设计。
主要内容小结如下：
1．需求分析包括业务流程分析、功能分析和业务规则分析。
系统设计人员要根据用户的
需求描述和系统边界，与用户进行深入交流和沟通，分析各个应用业务的具体流程。
然后，根
据业务流程，抽象出所开发系统拟实现的具体功能。
最后，根据功能描述，进
一步确定具体的业务规则和数据约束。
2．概念数据库设计即E-R 模型设计，包括实体集、联系集及属性的确定。
实体集
通常是功能分析中出现的具有一组属性且需要存储的“名词” 。
而联系集对应的概念为一种动作，即描述实体集间的一种行为。
当两个或多个实体集之间的某种行为需要记录时，
可建模为一个联系集。
确定联系集的难点是分清联系集的映射基数并确定主码属性。
属
性的确定原则是，只需要将那些与应用相关的特征建模为实体集或联系集的属性。
3．逻辑数据库设计是根据E-R 模型转换为数据库模式，并对数据库模式求精。
该
步骤应根据E-R 图转换规则和模式求精的步骤依次进行。
在进行数据库模式转换时要注
意联系集的转化：多对多联系集转化为一个单独的关系表；一对多或多对一联系集与“多”方实体集的表合并；一对一联系集与任何一方实体集的表合并。
通过本章的分析和设计过程可以看出：
(1)正确的数据库设计不是一蹴而就的，而是一个循序渐进和反复设计的过程。
因此，
在完成 E-R 模型设计后，还需仔细检查是否包含了所有的需求，如果没有，则需对已得
出的 E-R 模型进行调整甚至重新设计。
(2) 如果能仔细分析用户需求，并正确识别出所有的实体集和联系集，由E-R 图转换生成的数据库模式并不需要太多的进一步模式求精。
然而，如果一个实体集中的属性
之间可能存在函数依赖( 不包括主码依赖关系)，则需要根据函数依赖理论将其规范化。