关系数据库设计理论
关系数据库设计理论
构造一个关系数据库模式的方法可有多种
1、举例(学生选课数据库)
*数据库模式的构造方法一
用一个关系模式来描述学生选课信息()
SCG( S no , S name, S sex, S age, S dept , C no , C name, C pno, C credit,Grade )
*数据库模式的构造方法二
*概念模型为(E-R图):
m n
*将概念模型转换为以下关系模式:
*学生表S tudent( S no , S name, S sex, S age, S dept) ;
*课程表C ourse( C no , C name, C pno, C credit)
*学生选课 SC( Sno,Cname ,Grade)
SCG( S no , S name, S sex, S age, S dept , C no , C name, C pno, C credit,Grade )
S no |
S name |
S sex |
S age |
S dept |
C no |
C name |
C credit |
Grade |
001 |
张三 |
男 |
18 |
计 |
101 |
Pascal |
4 |
90 |
001 |
张三 |
男 |
18 |
计 |
102 |
操作系统 |
4 |
80 |
001 |
张三 |
男 |
18 |
计 |
103 |
编译 |
3 |
98 |
001 |
张三 |
男 |
18 |
计 |
105 |
数据库 |
4 |
87 |
001 |
张三 |
男 |
18 |
计 |
110 |
数据结构 |
4 |
70 |
002 |
李四 |
女 |
17 |
信电 |
103 |
编译 |
4 |
82 |
002 |
李四 |
女 |
17 |
信电 |
105 |
数据库 |
4 |
87 |
003 |
王五 |
男 |
19 |
化工 |
107 |
网络 |
3 |
86 |
*学生表S tudent( S no , S name, S sex, S age, S dept) ;
*课程表C ourse( C no , C name, C pno, C credit)
C no |
C name |
C credit |
101 |
Pascal |
4 |
102 |
操作系统 |
4 |
103 |
编译 |
3 |
105 |
数据库 |
4 |
107 |
网络 |
3 |
110 |
数据结构 |
4 |
*学生选课 SC( Sno,Cname ,Grade)
S no |
C no |
Grade |
001 |
101 |
90 |
001 |
102 |
80 |
001 |
103 |
98 |
001 |
105 |
87 |
001 |
110 |
70 |
002 |
103 |
82 |
002 |
105 |
87 |
003 |
107 |
86 |
S no |
S name |
S sex |
S age |
S dept |
001 |
张三 |
男 |
18 |
计 |
002 |
李四 |
女 |
17 |
信电 |
003 |
王五 |
男 |
19 |
化工 |
2、数据库模式(关系模式)的不同构造方法与数据冗余度、插入异常、删除异常、更新异常的关系
1) 冗余度比较
*方法1冗余度很大:学生信息冗余大(一个学生如选修n门课,其信息要重复存放n遍。如001号张三,重复存放5遍);课程信息冗余大(一门课程被 n 个学生选修,课程信息存放 n 次)
*方法2冗余度小:只有学号课程号有冗余。冗余度大大小于前一个,它仅有少量冗余数据,这些冗余数据保持在合理水平。
2) 更新异常(修改复杂)
*方法1:由于数据冗余,更新数据库中的数据时,系统需要付出很大的代价来维护数据库的完整性;
*方法2:修改复杂度大大减少。
3) 插入异常
*方法1:没选课程的学生信息,没被选修的课程信息,没法插入到表中;(插入异常)
*方法2:不同信息存放在不同的关系中,不产生插入异常现象。
4) 删除异常
*方法1:如某门课只有一个学生选修,学生毕业或因病退学后,删除相关信息后,课程等信息也被全部删除;(删除异常)
*方法2:不同信息存放在不同的关系中,不产生删除异常现象。
3、小结
1) 在关系数据库设计中,关系模式的设计方案可以有多个;
2) 不同的设计方案有好坏之分;
3) 要设计一个好的关系模式方案,要以规范化理论作为指导,规范化理论研究属性间的数据依赖关系,主要有函数依赖与多值依赖。关系规范化按属性间不同的依赖程度分为第一范式、第二范式、第三范式、BC范式、第四范式。
4.1 函数依赖
函数依赖是关系模式内属性间最常见的一种依赖关系
1、 关系中属性间函数依赖举例
学生关系属性的集合U={ Sno,Sdept,Mname,Cname,Grade }
现实世界的已知事实:
1) 一个学生只属于一个系(含义:学号确定后,学生所在的系也就被唯一确定了。类似于数学中的函数y=f(x),x=Sno,y= Sdept 。我们说 Sno 函数决定 Sdept, 或者说 ,Sdept 函数依赖于 Sno, 记做 sno → sdept ; 反过来一个系有若干学生(解释系不能决定学生)
2) 一个系只有一名系主任(含义:系确定后系主任名被唯一确定了,类似于数学中的函数,我们说 Sdept 函数决定 Mname, 或者说 ,Mname 函数依赖于 Sdept 。记做 S dept → Mname )
3) 一个学生可以选修多门课,每门课程有若干学生选修(含义:学号与课程号间够不成决定被决定关系)
4) 每个学生所学的每门课程都有一个成绩,含义: (sno,cname) → Grade
属性组 U 上的一组函数依赖 F={ sno → sdept, S dept → Mname,(sno,cname) → Grade }
2、 函数依赖定义(4 . 1)
设 R(U) 是一个关系模式, U 是 R 的属性集合, X 和 Y 是 U 的子集。对于 R(U) 的任意一个可能的关系 r ,如果 r 中不存在两个元组,他们在 X 上的属性值相同,而在 Y 上属性值不同,则称“ X 函数决定 Y ”或“ Y 函数依赖于 X ” , 记作 X → Y
见下表,如Sno →Sname,则 不存在 蓝色 两元组(即学号确定后,姓名不确定):
S no |
S name |
S sex |
S age |
S dept |
001 |
张三 |
男 |
18 |
计 |
001 |
赵六 |
|
|
|
002 |
李四 |
女 |
17 |
信电 |
003 |
王五 |
男 |
19 |
化工 |
思考题:1)码是否一定函数决定非码属性?非码属性间是否存在函数依赖
2)SNo → Sdept 成立 (Sno,Cno) → Sdept 是否也成立?
3)找出以下几个表的中的函数依赖
SCG( S no , S name, S sex, S age, S dept , C no , C name, C pno, C credit,Grade )
*学生表S tudent( S no , S name, S sex, S age, S dept) ;
*课程表C ourse( C no , C name, C pno, C credit)
*学生选课 SC( Sno,Cname ,Grade)
函数依赖的几点说明:
1) 函数依赖是所有关系实例(关系模式值的每一状态)均要满足的约束条件。
2) 函数依赖是语义范畴。只能根据语义确定函数依赖。如:在没有同名的情况下“姓名 → 年龄”成立
3) 数据库设计者可以对现实世界作强制的规定。
4) 若 X → Y ,则 X 称为这个函数依赖的决定属性集
5) 若 X → Y,Y → X 则记为 X Y
6) 若 Y 不函数依赖于 X ,则记为 X Y
3、 平凡函数依赖与非平凡函数依赖定义( 4.2 )
在关系模式 R(U) 中,对于 U 的子集 X 和 Y ,如果 X → Y ,但 Y 不是 X 的子集,则称 X → Y 是非平凡函数依赖。若 Y 是 X 的子集,则称 X → Y 为平凡函数依赖。
对于任一关系模式,平凡函数依赖都是必然成立的,它不反映新的语义。(为什么?)
4、 完全函数依赖与部分函数依赖
在关系模式 R(U) 中,如果 X → Y, 并且对于 X 的任何一个真子集 X' 都有 X' → Y ,则称 Y 完全函数依赖于 X ,记作 X → Y( 少 f) 。若 X → Y ,但 Y 不完全函数依赖于 X ,则称 Y 部分函数依赖于 X ,记 X → Y (少 P )。
5、 传递函数依赖
在关系模式 R(U) 中,如果 X → Y , Y → Z ,且 Y 不是 X 的子集, X 不函数依赖于 Y ,则称 Z 传递函数依赖于 X 。
Std(Sno,Sdept,Mname) 有 Sno → Sdept, Sdept → Mname , Mname 传递函数依赖于 Sno
6、 码
设 K 为关系模式 R( U, F )中属性或属性组。若 U 完全依赖于 K ,则 K 称为 R 的一个侯选码。若关系模式中有多个侯选码,则选定一个作为主码。
4.2范式
*1 NF :关系模式 R 的所有属性都是不可分割的基本数据项,则 R ∈ 1NF
( 非主属性函数依赖于码 )
*不满足1NF的举例:
学生 ( 学号,姓名,年龄, 入学毕业年月 )
*1 NF 是关系模式的起码要求
*第一范式举例:
SLC(Sno,Sdept,Sloc,Cno,Grade)
属性函数依赖情况:
(虚线表示部分函数依赖,实线表示完全函数依赖)
插入异常:未选课的学生不能插入,因为码值部分为空( 原因是对码的部分函数依赖造成 )。(解决问题的办法:把部分函数以来部分分解出来)
删除异常:某一学生的选课信息全部删除后,学生的其他信息也被删除,否则码值部分为空(不允许)( 原因是对码的部分函数依赖造成 )。(解决问题的办法:把部分函数以来部分分解出来)
数据冗余度大:一个学生选修了多门课程,同一学生的基本信息( Ssept,Sloc )需要保存多次。( 原因是对码的部分函数依赖造成 )。(解决问题的办法:把部分函数以来部分分解出来)
修改复杂:修改某学生基本信息时,如果其选修多门课程,同一信息需要重复修改多次。( 原因是对码的部分函数依赖造成 )(解决问题的办法:把部分函数以来部分分解出来)
2 NF :满足第一范式,非主属性完全函数依赖于码
前面的关系模式不满足第二范式,分解为下面两个模式后,部分函数依赖被消除:
SC(sno,cno,grade)
SL(Sno,Sdept,Sloc)
分解成第二范式后 SC(sno,cno,grade) , SL(Sno,Sdept,Sloc) 。以上4个问题在一定程度上得到了解决。
1) SL 关系中可以插入尚未选修的学生
2) 删除学生选课关系,只涉及 SC 关系,不涉及 SL 中的学生基本信息。
3) 由于学生选课信息于学生基本信息分开存放,不论该学生选修了几门课, Sdept 与 Sloc 值都只存储一次。
4) 某学生转系,只需要修改相关关系中的一个元组。
第二范式 SL 中存在传递函数依赖,使得 SL 仍然存在上述4个问题。
1) 插入异常:系刚成立,无在校学生,无法存入系信息。(解决问题的办法:把与主码无关的函数部分分解出来独立构成关系模式,即消除 对主码的传递函数依赖)
2) 删除异常:某系的全部学生毕业了,系的信息也丢失了。(解决问题的办法:把与主码无关的函数部分分解出来独立构成关系模式,即消除对主码的传递函数依赖)
3) 数据冗余度大:每一个系的学生都住在同一个地方,关于系的住处信息却要重复出现。
4) 修改复杂:当某系学生调整住处时,需要修改所有学生的 Sloc 属性值。
造成上述4个问题的主要原因:非主属性传递函数依赖于主码。
解决办法:将传递函数依赖关系分解出来。
3NF :满足第2范式,且主属性既不部分函数依赖于码,也不传递函数依赖于码
SL(Sno,Sdept,Sloc) 分解为
SD(sno,sdept)
DL(Sdept,Sloc)
规范化过程:
规范化过程即为关系模式的不断分解过程。
规范化的实质:概念的单一化。
规范化的目的:
不断解决关系插入异常、删除异常、数据冗余度大、修改复杂问题。
3NF 是工程上的标准,在工程应用上,达到第三范式一般情况下就可以了
4.3 关系模式的规范化
1、 第一范式到第三范式的分解过程:分解关系模式消除非主属性对码的部分函数依赖,分解关系模式消除非主属性对码的传递函数依赖。
2、 关系模式的分解方法并不唯一,只有能够保证分解后的关系模式与原关系模式等价的方法才有意义。
1) 分解具有无损连接性:分解后不能丢失信息,即分解前的关系与分解后关系的自然连接结果相等。
2) 分解后应能保持函数依赖。分解前的函数依赖F被分解后关系模式函数依赖F i 所逻辑蕴含
3) 分解既保持函数依赖,又保持无损连接。
3、 第3范式是工业标准
若要求分解既具有无损连接,又保持函数依赖,那么模式分解一定能达到3 NF ,但不一定能达到 BCNF 。
习题: P 143
第3题
学生(学号,姓名,出生年月,系名,班号,宿舍区)
班级(班号,专业名,系名,人数,入校年份)
系(系名,系号,系办公室地址,人数)
学会(学会名,成立年份,地点,人数)
学生参加学会(学号,学会名,入会年份)
只考虑与1、2、3 NF 有关的函数依赖(非主属性部分或完全函数依赖于码,非主属性传递函数依赖于码)
学生(学号,姓名,出生年月,系名,班号,宿舍区)
分解为:学生( 学号 ,姓名,出生年月,班号,系) 系宿舍( 系名 。宿舍区)
班级(班号,专业名,系名,人数,入校年份)
分解为:班级(班号,专业名,人数,入校年份) 专业系(专业名,系名)
系(系号,系名,系办公室地址,人数)
学会(学会名,成立年份,地点,人数)
学生参加学会(学号,学会,入会年份)
作者:
RDIF
出处:
http://www.cnblogs.com/huyong/
Email:
406590790@qq.com
QQ:
406590790
微信:
13005007127(同手机号)
框架官网:
http://www.guosisoft.com/
http://www.rdiframework.net/
框架其他博客:
http://blog.csdn.net/chinahuyong
http://www.cnblogs.com/huyong
国思RDIF开发框架
,
给用户和开发者最佳的.Net框架平台方案,为企业快速构建跨平台、企业级的应用提供强大支持。
关于作者:系统架构师、信息系统项目管理师、DBA。专注于微软平台项目架构、管理和企业解决方案,多年项目开发与管理经验,曾多次组织并开发多个大型项目,在面向对象、面向服务以及数据库领域有一定的造诣。现主要从事基于
RDIF
框架的技术开发、咨询工作,主要服务于金融、医疗卫生、铁路、电信、物流、物联网、制造、零售等行业。
如有问题或建议,请多多赐教!
本文版权归作者和CNBLOGS博客共有,欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出原文连接,如有问题,可以通过微信、邮箱、QQ等联系我,非常感谢。