关系数据库规范化理论与数据库设计大全.docx
《关系数据库规范化理论与数据库设计大全.docx》由会员分享，可在线阅读，更多相关《关系数据库规范化理论与数据库设计大全.docx（22页珍藏版）》请在冰豆网上搜索。
关系数据库规范化理论与数据库设计大全
7.1知识点
7.1.1关系模式的设计问题
给出一组数据，如何构造一个适合于它们的数据库模式，这是数据库设计的问题。
关系数据库设计理论主要包括三个方面的内容：
数据依赖，范式，模式设计方法。
其
中数据依赖起着核心作用。
把现实问题的所有属性组成一个关系模式，记为R（U），它由属性集U和U上成立的
数据完整性约束集组成。
关系r是关系模式R（U）的当前值，是一个元组的集合。
这里的关
系模式和关系一般称为泛关系模式和泛关系。
用一个关系模式的集合ρ={R1，R2，.，Rk}
来代替R（U），其中每个Ri（1≤i≤k）的属性是U的子集。
这里的ρ称为数据库模式。
对数
据库模式的每一个关系模式赋予一个当前值，就得到一个数据库实例（简称数据库）。
泛关系模式存在的存储异常问题有：
数据冗余，更新异常，插入异常，删除异常。
7.1.2数据依赖
数据依赖是可以作为关系模式的取值的任何一个关系所必须满足的一种约束条件，是
通过一个关系中数据间值的相等与否体现出来的相互关系。
它是现实世界属性间相互联系
的抽象，是数据内在的性质，也是语义的体现。
人们已经提出了许多种类型的数据依赖，
其中最重要的是函数依赖和多值依赖。
7.1.3函数依赖
设R（A1，A2，.，An）是一个关系模式，X和Y是{A1，A2，.，An}的子集，若只
文本框:
考纲要求
1．关系数据库的规范化理论。
2．数据库设计的目标、内容和方法。
要关系r是关系模式R的可能取值，则r中不可能有两个元组在X中的属性值相等，而在
Y中的属性值不等，则称“X函数决定Y”，或“Y函数依赖于X”，记作X→Y。
非平凡函数依赖
若X→Y，但Y.X，则称X→Y为非平凡的函数依赖。
完全函数依赖
在关系模式R中，如果X→Y，并且对于X的任何一个真子集X’，都有Y不函数依
赖于X’，则称Y对X完全函数依赖，记做。
.ü..?
..?
..?
..?
..?
..
YXf.→.
不完全函数依赖
若X→Y，但Y不完全函数依赖于X，则称Y对X部分函数依赖，记做Y.ü..?
..?
..?
..?
..?
..
YXp.→.
传递函数依赖
在关系模式R中，如果X→Y而且X不函数依赖于Y，（Y.ü..?
..?
..?
..?
..?
..
.X），Y→Z，则称Z对X
传递函数依赖。
7.1.4多值依赖
多值依赖的定义是：
设R是属性集U上的一个关系模式，X、Y是U的子集，Z=U-X-Y。
若在R的任一关系r中，只要存在元组t，s，使得t[X]=s[X]，就必然存在元组ω，ν（ω，
ν可以与s，t相同），使得ω[X]=ν[X]=t[X]=s[X]，而ω[Y]=ν[Y],s[Z]＝s[Z]，ν[Y]=s[y]，
ν[Z]=t[Z]，则称Y多值依赖于X，记做X→→Y。
7.1.5函数依赖的逻辑蕴含
设F是关系模式R的一个函数依赖集，X、Y是R的属性子集，如果从F中的函数依赖能够推出X→Y，则称F逻辑蕴涵X→Y。
被F逻辑蕴涵依赖的全体构成的集合，称为F的闭包，记为F+。
7.1.6码
设有关系模式R（A1，A2，.，An），F是R上的函数依赖集，X是{A1，A2，.，An}
的一个子集。
如果X→A1，A2.，An∈F+，且不存在X的真子集Y，使得Y→A1，A2.，
An成立，则称X是R的一个候选码。
包含在任何一个候选码中的属性称为主属性，不包
含在任何码中属性称为非主属性或非属性。
7.1.7Armstrong公理系统
Armstrong公理系统包括三条推理规则：
自反律：
若Y，则X→Y为F所逻辑蕴含。
.ü..?
..?
..?
..?
..?
..
UX..
增广律：
若X→Y为F所逻辑蕴含，且，则XZ→YZ为F所逻辑蕴含。
.ü..?
..?
..?
..?
..?
..
UZ.
传递律：
若X→Y及Y→Z为F所逻辑蕴含，则X→Z为F所逻辑蕴含。
由这三条推理规则还可以推出三条有用的规则：
合并规则：
由X→Y，X→Z，有X→YZ。
伪传递规则：
由X→Y，WY→Z，有XW→Z。
分解规则：
由X→Y及，有X→Z。
.ü..?
..?
..?
..?
..?
..
YZ.
7.1.8范式
第一范式（1NF）
关系模式需要满足一定的条件，不同程度的条件称做不同的范式。
最低要求的条件是
元组的每个分量必须是不可分的数据项，这叫做第一范式，简称1NF，是最基本的规范化。
第二范式（2NF）
若关系模式R∈lNF，且每一个非主属性完全函数依赖于码，则R∈2NF。
2NF就是不
允许关系模式的属性之间有这样的函数依赖X→Y，其中X是码的真子集，Y是非主属性。
即不允许有非主属性对码的部分函数依赖。
第三范式（3NF）
若关系模式R∈2NF，且每一个非主属性都不传递依赖于码，则R∈3NF。
3NF就是不允许关系模式的属性之间有这样的非平凡函数依赖X→Y，其中X不包含码，Y是非主属性。
Boyce-Codd范式（BCNF）
若关系模式R∈lNF，且对于每一个非平凡的函数依赖X→Y，都有X包含码，则R∈
BCNF。
BCNF是3NF的进一步规范化，即限制条件更严格。
3NF不允许有X不包含码，
Y是非主属性的非平凡函数依赖X→Y。
BCNF则不管Y是主属性还是非主属性，只要X
不包含码，就不允许有X→Y这样的非平凡函数依赖。
因此，若R∈BCNF，则必然R∈3NF。
然而，BCNF又是概念上更加简单的一种范式，判断一个关系模式是否属于BCNF，只要
考察每个非平凡函数依赖X→Y的决定因素X是否包含码就行了。
1NF，2NF，3NF，BCNF的相互关系是：
BCNF3NF.2NF.1NF。
在函数依赖的
范畴内，BCNF达到了最高的规范化程度。
.ü..?
..?
..?
..?
..?
..
第四范式（4NF）
若关系模式R∈1NF，且对于每一个非平凡的多值依赖X→→Y，（Y），都有X
包含码，则R∈4NF。
.ü..?
..?
..?
..?
..?
..
X.
虽然4NF是基于多值依赖的概念定义的，但4NF是BCNF的进一步规范化。
可以证
明有关系4NFBCNF.3NF2NF.1NF。
.ü..?
..?
..?
..?
..?
..
..ü..?
..?
..?
..?
..?
..
7.1.9关系模式的分解
设有关系模式R＝A1A2.An，R1，R2，.，Rk都是R的子集，R=R1∪R2∪.∪Rk。
关系模式R1，R2，.，Rk的集合用ρ表示，ρ＝{R1，R2，.，Rk}。
用ρ代替R的过程
称为关系模式的分解。
这里ρ称为R的一个分解，也称为数据库模式。
数据库模式对应的
当前值σ称为数据库实例，它是由数据库模式中的每一个关系模式的当前值组成，用σ＝
＜rl，r2，.，rn＞表示。
关系模式的分解的衡量标准有：
分解具有无损联接；分解要保持
函数依赖；分解既要保持函数依赖，又要具有无损联接。
7.1.10关系模式分解的等价标准
分解具有无损连接性
设R是一关系模式，分解成关系模式ρ={R1，R2，.，Rk}，F是R上的一个函数依
赖集。
如果对R中满足F的每一个关系r都有：
r=πRl（r）∞πR2（r）∞.∞πRK（r），
则称这个分解ρ相对于F是“无损联接分解”。
即T为它在Ri上投影的自然联接。
r的投
影联接表达式πRl（
r）∞πR2（r）∞.∞πRK（r）用M（r）表示，即Mρ（r）表示，即M称为关系r的投影联接变换。
对于关系模式R关于F的无损联接条件是：
任何满足F的关系r，有M.ü..?
..?
..?
..?
..?
..）（）（1rrRikiπρ=∞=ρ（r）。
如果R的分解为ρ={Rl，R2}，F为R所满足的函数依赖集合，分解ρ具有无损联接的充分必要条件为：
R1∩R2→R1-R2或R1∩R2-R1。
其中，R1∩R2表示模式的交集，为R1与R2中公共属性组成，R1-R2或R2-R1表示模式的差集，R1-R2表示R1中去了R1和R2的公共属性所组成。
当模式R分解成两个关系模式R1和R2时，如果R1与R2的公共属性能函数决定马中或R2中的其它属性，这样的分解具有无损联接性。
分解保持函数依赖
设F是属性集U上的函数依赖集，Z是U上的一个子集，F在Z上的一个投影用πz（F）表示，定义为：
πz（F）={X→Y|X→Y∈F+且XY.Z}。
设关系模式R的一个分解
ρ={R1,R2,.，Rk}，F是R上的函数依赖集，如果，则称分解ρ保持
函数集F。
.ü..?
..?
..?
..?
..?
..
UkiRiFF1））（
=
++π.ü..?
..?
..?
..?
..?
..
（=
7.1.11数据库设计
数据库设计是指对于一个给定的应用环境，提供一个确定最优数据模型与处理模式的
逻辑设计，以及一个确定数据库存储结构与存取方法的物理设计，建立起既能反映现实世
界信息和信息联系，满足用户数据要求和加工要求，又能被某个数据库管理系统所接受，
同时能实现系统目标，并有效存取数据的数据库。
数据库设计方法中比较著名的有新奥尔良（NewOrleans）方法。
它将数据库设计过程
分为四个阶段：
需求分析、概念结构设计、逻辑结构设计和物理设计，如图7－1所示：
图7－1新奥尔良方法的数据库设计步骤
7.1.12需求分析
需求分析阶段应该对系统的整个应用情况作全面的、详细的调查，确定企业组织的目
标，收集支持系统总的设计目标的基础数据和对这些数据的要求，确定用户的需求，并把
这些要求写成用户和数据库设计者都能接受的文档。
需求分析就是把总体信息需求、处理
需求以及企业自身的制约条件等几方面的因素进行综合考虑，最后规划出一份既切合实际，
又具有远见的需求说明书。
需求分析大致分为三步来完成，即需求信息的收集、分析整理和评审。
需求信息的收
集又称为系统调查，在调查研究之前，要做好充分的准备工作，要明确调查的目的、调查
的内容和调查的形式。
需求信息的分析整理包括业务流程分析和分析结果的描述，业务流
程分析一般采用数据流分析法，分析结果以数据流图（DFD）表示，除了DFD以外，还要
用一些规范表格进行补充描述。
评审的目的在于确认某一阶段的任务是否全部完成，以避
免重大的疏漏或错误。
7.1.13概念结构设计
概念设计的目标是产生反映企业组织信息需求的数据库概念结构，即概念模式。
概念
模式是独立于数据库逻辑结构，独立于支持数据库的DBMS，不依赖于计算机系统的。
概
念设计的必要性表现在：
1，数据库设计过程中各阶段的任务相对单一化，设计复杂程度大大降低，便于组织管
理；
2，不受特定的DBMS的限制，也独立于存储安排和效率方面的考虑，因而比逻辑模
式更为稳定；
3，概念模式不含具体的DBMS所附加的技术细节，更容易为用户所理解，因而才有
可能准确地反映用户的信息要求。
7.1.14逻辑结构设计
逻辑设计的目的是把概念设计阶段设计好的基本E－R图转换为与选用的具体机器上
的DBMS所支持的数据模型相符合的逻辑结构（包括数据库模式和外模式）。
这些模式在
功能上、完整性和一致性约束及数据库的可扩充性等方面均应满足用户的各种要求。
椭圆:
需求
分析
椭圆:
概念结构设计
椭圆:
逻辑结构设计
椭圆:
物理
设计
文本框:
需求说明
文本框:
概念结构
文本框:
逻辑结构
文本框:
物理结构
7.1.15物理设计
对一个给定的逻辑数据模型选取一个最适合应用环境的物理结构的过程，称为数据库
的物理设计。
所谓数据库的物理结构，主要指数据库在物理设备上的存储结构和存取方法。
它是完全依赖于给定的计算机系统的。
在物理结构中，数据的基本单位是存储记录。
“文件”
是某一类型的所有存储记录的集合。
一般我们用“文件”表示单记录类型的物理数据库。
物理设计阶段的输出是物理数据库结构说明书，包括存储记录格式、存储记录位置分
布及访问方法。
它能满足所有的操作需求并给出对硬件、软件系统的约束。
在设计过程中，
效率问题只能在各种约束得到满足且获得可行方案之后进行。
7.1.16数据库的实现与维护
数据库的实现
根据逻辑结构设计和物理设计的结果，在计算机上建立起实际数据库结构，装入数据，
测试和运行的过程称为数据库的实现。
实现阶段的主要工作有：
1．建立实际数据库结构；
2．试运行；
3．装入数据。
在数据库正式投入使用之前，还有一些工作要做。
如数据库的重新组织
设计，故障恢复方案设计、安全性考虑和事务控制等。
数据库的维护
运行维护阶段的主要工作是：
1．维护数据库的安全性与完整性控制及系统的转储和恢复；
2．性能的监督、分析与改进；
3．增加新功能；
4．发现错误，修改错误。
7.2重点难点
7.2.1函数依赖
函数依赖的定义
设有关系模式R（A1，A2，.，An）或简记为R（U），X、Y是U的子集，r是R的
任何一具体关系，如果对r的任意两个元组t1、t2，由t1［X］＝t2［X］导致t1[Y]=t2[y]，
则称X函数决定Y，或Y函数依赖于X，记为X→Y。
X→Y为模式R的一个函数依赖。
函数依赖是对关系R的一切可能的当前值r定义的，不是针对某个特定关系。
在关系模式
R中，要判断函数依赖是否成立，惟一的办法是仔细地考察属性的含义。
函数依赖极为普遍地存在于现实生活中。
比如描述一个学生的关系，可以有学号（SNO）
姓名（SNAME）系名（SDEPT）等几个属性。
由于一个学号只对应一个学生。
一个学生
只在一个系学习。
因而当“学号”值确定之后，姓名和该生所在系的值也就被唯一地确定
了。
就象自变量x确定之后，相应的函数值f（x）也就唯一地确定了一样，称SNO函数
决定SNAME和SDEPT，或者说SNAME，SDEPT函数依赖于SNO。
记为：
SNO→SNAME，
SNO→SDEPT。
假设现在要建立一个数据库来描述学生的一些情况，面临的对象有：
学生（用学号SNO
描述），系（用系名SDEPT描述），系负责人（用其姓名MN描述），课程（用课程名CNAME
描述）和成绩（G）。
于是得到一组属性：
U＝｛SNO，SDEPT，MN，CNANE，G｝
由现实世界的已知事实得知：
1．一个系有若干学生，但一个学生只属于一个系；
2．一个系只有一名（正职）负责人；
3．一个学生可以选择多门课程，每门课程有若干学生选修；
4．每个学生学习每一门课程有一个成绩。
于是得到属性组U上的一组函数依赖：
F＝｛SNO→SDEPT，SDEPT→MN，（SNO，CNAME）→G｝
函数依赖是数据的重要性质，关系模式应能反映这些性质。
因此，我们可以把关系模
式表示成R〈U，F〉，其中U是一组属性，F是属性组U上的一组数据依赖。
当且仅当U
上的一个关系r满足F时，r称为关系模式R〈U，F〉的一个关系。
例如，在表7－1所示的关系中存在着函数依赖：
课程号→学习期限，这是因为任何两
个ui,uj∈r，若ui[课程号]＝uj[课程号]，就必有ui[学习期限]=uj[学习期限]，如：
文本框:
$函数依赖的成立条件
函数依赖和别的数据依赖一样是语义范畴的概念。
只能根据语义来确定一个函数依赖，例如姓名→年龄这个函数依赖只有在该部门没有同名人的条件下成立。
如果允许有同名人，则年龄就不再函数依赖于姓名了。
设计者也可以对现实世界作强制的规定。
例如规定不允许同名人出现。
因而使姓名→年龄函数依赖成立。
这样当插入某个元组时这个元组上的属性值必须满足规定的函数依赖。
若发现有同名人存在，则拒绝插入该元组。
所以我们应当注意，函数依赖不是指关系模式R的某个或某些关系满足的约束条件，而是指R的一切关系均要满足的约束条件。
u1[课程号]＝u2[课程号]＝J2
u1[学习期限]=u2[学习期限]＝3
r1中还存在着成绩→奖学金，特别是还存在着（学号，课程号）→成绩，这是因为一
个学生的一门课程只可能有一个成绩，但在关系r1中，没有两个不同的元组ui与uj使ui[学
号,课程号]=uj[学号，课程号]，所以体现得不像前两个那么明显。
我们还可以注意到若在一
个个关系r中，对任何两个不同的元组ui，uj都有ui[X]≠uj[X]。
则这时不论ui[Y]是否等于
uj[Y]，条件“只要
函数依赖的推理规则
为了确定一个关系模式的码，为了从一组函数依赖求得蕴含的函数依赖，我们需要从
F计算F+，或者至少，需要判断函数依赖X→Y是否在F+中。
为此我们需要一套推理规则。
这样的推理规则1974年由Armstrong首先提出来，称做Armstro
增广律、传递律、合并律、伪传递律、分解律六个规则。
例如，利用这
步骤如下：
1．从F本身定义的函数依赖中
号）→成绩，成绩→奖学金；
2．由增广律可
学习期限）；
3．因为
学金；
4．根据合并规则，就可以得到：
（学号，课程号）→（学号，成绩，奖学金），所以（学号，课程号）是一个候选码。
Armstrong公理系统是正确的、完备的。
正确性是指由F出发根据推理规则推导出的函数依赖
计算数学张平数学分析
关系模型Teaching（C，T，B）的码是（C，T，B），即关系模式的所有属性组合是它的码。
因而关系模式中不存在不包含码的非平凡函数依赖，Teaching∈BCNF。
但是当某一课程（如
物理）增加一名讲课教员（如周英）时，必须插入多个（这里是三个）元组：
（物理，周英，普通
物理学）；（物理，周英，光学原理）；（物理，周英，物理习题集
掉一本参考书（如微分方程），则必须删除除多个（这里是两个）元组；（数学，李勇，微
分方程）；（数学，张平，微分方程）。
对数据的增删很不方便。
数据的冗余也十分明显。
仔
细考察这类关系模式，可以发现它具有多值依赖。
设R（U）是属性集U上的一个关系模式。
X，Y，Z是U的子集，并且Z＝U－X－Y。
当且仅当对R（U）的任一关系r给定的一对（x，z）值，有一组Y的值，这组值仅仅决定于x
值而与z值无关，关系模式R（U）中多值依赖X→→Y成立。
例如，在值仅仅决定于课程C上的值
T值仍是{李勇，王军}，尽管这时参考书B的值已经改变了。
因此T多值依赖于C，
即C→→T。
多值依赖具有以下性质：
1．若X→→Y，则X→→Z，其中，Z=U-X-Y，即多值依赖具有对称性。
从关系模式
CTB的例子可以看出，C→→T的同时显然有C→→B。
2．若X→Y，则X→→Y，即函数依赖可以看作多值依赖的特殊情况。
因为当X→Y
时，对于X的每一个值x，都有Y的一个确
每一对X，Z值（Z=U-X-Y），都有的一个值与之对应，这个Y值只依赖于X值，
不依赖于Z值。
这符合对多值依赖X→→Y的描述，只是将Y的“一组值”换成“一个值”，
因此，函数依赖是多值依赖的特殊情况。
3．设属性集之间的包含关系是XY.W.U，那么当X→→Y在R（U）上成立时，X→→Y也在R（W）上成立；反过来当X→→Y在R（W）上成立时，X.ü..?
..?
..?
..?
..?
..
的一定成立，即多值依赖的有效性与属性集范围有关。
这是因为多值依赖的定义中不
仅涉及属性组X，Y，而且涉及U中其余属性Z。
一般地，在R（U）上若有X→→Y在R（W）（W.U）上成立，则称X→→Y为R（U）的嵌入型多值依赖。
4．若X→→Y在R（U）上成立。
且Y’.ü..?
..?
..?
..?
..?
..
否成立时涉及的其余属性Z=U-X-Y’比
7.2.3关系模式的范式
前面讨论的描述学生情况数据库模式可以表示为R{
这个模式有下述四个“毛病”：
1．如果一个系刚成立尚无学生，或者显然有了学生但尚未安排课程，那么就无法把这
个系及其负责人的信息存入数据库，这称为插入异常。
2．反过来
其负责人的信息也丢掉了，称为删除异常。
3．冗余太大。
比如，每一个系负责人的姓名要与该系每一个学生的每一门功课的成绩
出现的次数一样多。
这样，一方面浪费存储，另一方面系统要付出
完整性。
4．某系负责人更换后，就必须逐一修改有关的
在一个元组中更改了某系负责人的姓名，而没有更改另一个元组中同一负责人姓名，
于是同一系出现了两个负责人，与实际情况不符。
称为更新异常由于上述“毛病”它是一个“不好”的数据库模式，那么如何得到一个“好”的关系模式呢，这就要涉及到关系模式的规范化问题。
规范化的关系模式需要满足一定的条件，不同程度的条件称做不同的范式。
所谓“第几范式”是表示关系模式满足的一定条件，所以经常称某一关系模果关系模式R的所
∈
第二范式（2NF）
如果关系模式R为第一范式，并且R中每一个非主属性完全
则称R是第二范式（2NF）模
则称该数据库模式是属于第二范式和数据库模式。
比如表7－l中给出的那个“不好”的关系模式：
R（学号，课程号，课程名，学习期限，成绩，奖学金）
其属性组上的
F={课程号→课程名，课程号→学习期限，（学号，课程号）→成绩，成绩→奖学金}
显然（学号，课程号）是码，学号，课程号是主属性，课程名，学习期限都是非主属
性，课程号→课程名，课程号→学习期限是非主属性对码的部分函数依赖，所以该关系模
式不属于2NF。
表7－l中指出的关系模式R的种种“毛病”就是由于这两个函数依赖的存在造成的。
比如“课程号”是码的真
同值，数据的冗余引起了更新异常。
课程号的值确定了，则课程名的值也随之确定，
这样的信息应存在数据库中，但由于课程号只是码的真子集
删除异常的问题。
可以用分解的方法将一个非2NF的关系模式分解为多个2NF的关
1的学生课程和成绩
R2（课程号，课程名，学习期限）
就不再有非主属性对
第三范式（3NF）
称
显然（学号，课程号）是码，其余的属性都是非主属性。
非主属性“奖学金”传递依
数据的冗余引起了更新异常。
“成奖
学金”的值也随之确定，
可以一
为三个关系模式：
R1（学号，课程号，成绩）
R2（课程号，课程名，学习期限）
R3（成绩，奖学金）
这样就不再有非主属性对码的传递依赖，都是3NF的关系模式了。
Boyce-Codd范式（BCNF）
由及的定义来看，只要求对
赖于码，而且还要求没有主属性对非主属性的函数依赖，所以BCNF.3NF。
→教师是（U的关键。
生，课程），进而还有关键字。
于是R中的每一个属性都是主属性，3NF定义中涉及到的非主属性根本不存在，当然定义的条件一定满足，所以R（U，F）.3NF但教师→课程，课程→教师，“教师”不包含关键字，所以（U，F）不属于BCNF。
第四范式（4NF）
.ü..?
..?
..?
..?
..?
..
据定义，要求每
，所以，所允许的非平凡多值依赖实际上是函数依赖。
比如上面讨论的关系
不含码（C，T，W），因此，CTB.4NF。
正是由于C→→T，C→→B
个关系模式：
Teaching2（C，B）
就不再有非平凡且非函数依赖的多值依赖，都是4NF的关系模式了。
.4关系模式的模式分解的等价标准
规范化过程中将一个关系模式分解为若干个关系模式，应该保证分解后产生的模式与
原来的模式等价。
常用的等价标准有要求分解是具有无损连接性的和要求分解是保持函数
依赖的两种。
由于R中存在传递函数依赖SNO
3系的系主任是王五的信息也就丢掉了。
反过来，如果一个系D5尚无在校学生，那么
这个系的系
ρ1={R1，（SNO，φ），R2（SDEPT，φ），R3（MN，φ）}
分解后诸Ri的
升级会员 