存在问题的原因:
• 上述表的关键字是(Ono, Pno, Cno)，而产品信息(Pname, Pprice)本 来可以由Pno唯一确定。也就是说，产品信息并不完全依赖于订单编 号；同样客户信息也不完全依赖于订单编号，这是引起插入、删除 异常及冗余的原因。
问题的提出
改进方案：用订单信息、产品信息、客户信息及订单细节
SD（Sno， Sdept）
DL（Sdept， Sloc） SD的码为Sno， DL的码为Sdept。
3NF（续） SD的码为Sno， DL的码为Sdept。
Sno
Sdept
Sdept
Sloc
SD
DL
BCNF
定义：若关系模式中有函数依赖，则必然是依赖于包含侯选
键的属性或属性组，换句话说，关系模式中不存在不依赖于 包含侯选键的属性或属性组的函数依赖；又被称为关系 Boyce‐Codd范式，通常又称扩充后的BCNF。
2NF（续）
SLC
Sno
Sdept
原因
Grade
Sdept、 Sloc部分函数依赖于码。
Cno
Sloc
解决方法
SLC分解为两个关系模式，以消除这些部分函数依赖 SLC（Sno,Sdept,Sloc, Cno,Grade） SC（Sno， Cno， Grade） SL（Sno， Sdept， Sloc）
⒈ 一个系有若干学生， 一个学生只属于一个系；
Sno → Sdept ⒉ 一个系只有一名主任； Sdept → Mname ⒊ 一个学生可以选修多门课程， 每门课程有若干学 生选修； ⒋ 每个学生所学的每门课程都有一个成绩。 (Sno, Cname) → Grade
问题的提出
属性组U上的一组函数依赖F：
四张表存储客户订货系统信息：
问题的提出
改进方案解决问题的分析：
• (1) 在订单信息、产品信息、客户信息及订单细节四张表 中，其中的订单信息、产品信息、客户信息分别反映了 客观存在的实体，而订单细节反映了订单与产品之间的 联系(实体之间的联系)。
• (2) 描述现实世界中实体及其关联是建立信息模型[概念模 型]的核心思想。
，那么我们说X函数决定Y, 或者Y函数依赖于X，记作X→Y. 若X → Y, Y → X, 则记作X←→ Y. 若Y不函数依赖于X，则记作X Y 例如：“学号”，“姓名”，“年龄”，“家庭住址” 则有：“姓名” “年龄”和“家庭住址”都函数依赖于“学号” 函数依赖的分析取决于对问题领域的限定和详细分析。 例如：问题领域(1)中，学生是没有重名的，则有： “年龄”和“家庭住址”都函数依赖于“姓名” 而在另一个问题领域(2)中，学生是有重名的，则上述函数依赖是不 成立的。 所以必须正确理解问题领域的相关业务规则
2NF（续） 例: 关系模式 SLC(Sno,Sdept,Sloc, Cno,Grade) Sloc为学生住处，假设每个系的学生住在同一个 地方。SLC的码为(Sno, Cno)。 函数依赖包括： F (Sno,Cno) → Grade P (Sno,Cno) → Sdept P (Sno,Cno) → Sloc Sno → Sloc Sdept → Sloc Sno → Sdept
F ＝｛ Sno → Sdept , Sdept → Mname , (Sno , Cname) → Grade ｝
Sno
Cname
Grade
Sdept
Mname
问题的提出
单一的关系模式Student<U , F>中存在的问题 U ＝｛ Sno, Sdept , Mname , Cname , Grade ｝ Student｛ Sno, Sdept , Mname , Cname , Grade ｝
各种范式之间存在联系：
1NF 2 NF 3NF BCNF 4 NF 5 NF
关系设计的第一范式
关系中，属性不可再分:又被称为关系第1范式
关系设计的第二范式
如果关系中的每一非主属性完全函数依赖于候选键，则称关系满足第2
范式。 存在非主属性部分依赖的关系设计将会存在非受控冗余、插入异常和删 除异常等问题。 例如：侯选键为“学号，系别”。“姓名”部分依赖于“学号，所 属系别”，“系主任”部分依赖于“学号，所属系别”。 第2范式消除了非主属性对侯选键的部分依赖。
第五章 数据库设计正确性分析
问题的提出
初始方案：设计一张表记录客户、订单及产品信息：
存在问题:
• (1) 如果删除订单信息，则产品信息也将删除，称为删除异常； • (2) 如果没有订单，则无法增加产品信息，称为插入异常； • (3) 客户、订单、产品信息冗余，会引起数据不一致
问题的提出
初始方案：设计一张表记录客户、订单及产品信息：
候选键和非主属性
在一个属性集合中，能够完全决定所有属性的那些属性(组)
被称为侯选键 一个属性集合可以拥有多个侯选键 在一个属性集合中，不包含在任何侯选键中的属性，被称为 非主属性 在后面关系设计原则中，要求首先要找到所有的函数依赖，然 后再分析侯选键和非主属性
例(1)： { “学号” ，“年龄”，“家庭住址”，“课程号”，“成绩”， “任课教师”，“教师职务” }；侯选键是？，非主属性是？ 例(2)：{“城市名”，“街道名”，“邮政编码”}；侯选键是？，非主属性 是？ 例(3)：{“商店”，“商品”，“商品经营部”，“商品经营部经理”} 例(4)：{“学号”，“姓名”，“所属系别”，“系主任” }
如何避免
设计满足规范性，由DBMS或数据
库本身来保证
设计不满足规范性，由使用者或应
用程序员使用过程中加以注意
什么是规范的数据库设计
数据库的规范性设计需要分析数据库 Table中的属性在取值
方面有什么依存关系？
• 函数依赖
完全函数依赖与部分函数依赖 传递函数依赖；
• 多值依赖
数据库设计过程中应遵循什么样的原则
Sno S1 S2 S3 S4 Sdept 计算机系 计算机系 计算机系 计算机系 Mname 张明 张明 张明 张明 Cname C1 C1 C1 C1 Grade 95 90 88 70
S5
计算机系
张明
C1
78
问题的提出
⒈ 数据冗余太大 • 浪费大量的存储空间 例：每一个系主任的姓名重复出现 ⒉ 更新异常（Update Anomalies） • 数据冗余 ，更新数据时，维护数据完整性代价大 例：某系更换系主任后，系统必须修改与该系学生有关 的每一个元组
(1) 插入异常 假设Sno＝95102，Sdept＝IS，Sloc＝N的学生还未选课， 因课程号是主属性，因此该学生的信息无法插入SLC。 (2) 删除异常 假定某个学生本来只选修了3号课程这一门课。现在因身体 不适，他连3号课程也不选修了。因课程号是主属性，此操 作将导致该学生信息的整个元组都要删除。 (3) 数据冗余度大 如果一个学生选修了10门课程，那么他的Sdept和Sloc值就 要重复存储了10次。 (4) 修改复杂 例如学生转系，在修改此学生元组的Sdept值的同时，还可 能需要修改住处（Sloc）。如果这个学生选修了K门课，则 必须无遗漏地修改K个元组中全部Sdept、Sloc信息。
请大家分析下列属性或属性组之间存在的函数依赖关系
Hale Waihona Puke “学号”， “年龄”，“家庭住址”，“课程号”，“课程名称 ”，“成绩”，“任课教师编号”，“教师姓名”
完全函数依赖和部分函数依赖
在一个属性集合中，若属性(组)X能够函数决定属性(组)Y, 但
是X的任何一个真子集都不能函数决定Y, 则说X完全决定Y, 或者Y完全函数依赖于X，记作X Y；否则说Y部分函数依 赖于X，记作X Y。
• 关系第 1范式原则 (1NF) • 关系第 2范式原则 (2NF) • 关系第 3范式原则 (3NF) • 关系 Boyce‐Codd范式原则 (BCNF) • 关系第 4范式原则 (4NF) • 关系第 5范式原则 (5NF)
函数依赖
对于两个属性(或属性组)X和Y, 如果X上的值相等，则Y上的值一定相等
传递函数依赖
在一个属性集合中，若属性(组)X能够函数决定属性(组)Y, 而
Y又函数决定属性(组)Z, 但Y不能函数决定X, 而且Y不包含于 X, 则说Z传递函数依赖于X。 例(1)：{ “学号” ，“姓名” ，“系号” ，“系主任” }中， “学号” 函数决定“系号”，而“系号”函数决定“系主任” ，则“系主任”传递依赖于“学号
问题的提出
例2：描述学校的数据库： 学生的学号（Sno）、所在系（Sdept） 系主任姓名（Mname）、课程名（Cname） 成绩（Grade）
单一的关系模式 ： Student <U，F>
U ＝｛ Sno, Sdept , Mname , Cname , Grade ｝
问题的提出 学校数据库的语义：
2NF（续）
SLC Sno Grade Sdept
Cno
Sloc
SLC的码为(Sno, Cno) SLC满足第一范式
非主属性Sdept和Sloc部分函数依赖于码(Sno,Cno)
2NF（续） 关系模式 SLC(Sno,Sdept,Sloc, Cno,Grade)
SLC不是一个好的关系模式
结论： • Student关系模式不是一个好的模式。 • “好”的模式： 不会发生插入异常、删除异常、更新异常， 数据冗余应尽可能少。 原因：由存在于模式中的某些数据依赖引起的 解决方法：通过分解关系模式来消除其中不合适的数据依赖。 S（SNO，SDEPT，SNO→SDEPT） SG（SNO，CNAME，G，（SNO，CNAME） →G） DEPT（SDEPT，MNAME，SDEPT →MNAME）