一、关系数据库规范理论
1.1 什么是“好” 的关系模式？
某学校要建立一个数据库以描述学生选修课程的情况。由现实世界的已知事实可以得到如下对应关系：每一名学生可以选修多门课程，每一门课程可以被多名学生所选修；每一名学生选修一门课程都会有一个成绩。
针对上述情况可能设计出以下两种关系模式
只产生一个关系模式
学生选课关系模式（学号，姓名，性别，年龄，系别，课程号，课程名，教师名，学分，成绩）
产生三个关系模式
学生关系模式（学号，姓名，性别，年龄，系别）
课程关系模式（课程号，课程名，教师名，学分）
选课关系模式（学号，课程号，成绩）
比较分析这两种关系模式，发现第一种设计方法可能带来如下问题：
数据冗余
更新异常（Update Anomalies）
插入异常（Insertion Anomalies）
删除异常（Deletion Anomalies）
出现的原因： 由存在于模式中的某些数据依赖引起的。我们可以用规范化理论改造关系模式来消除其中不合适的数据依赖
1.2 数据依赖
数据依赖是一个关系内部属性与属性之间的一种约束关系，这种约束关系是通过属性间值的相等与否体现出来的数据间的相互关系。数据依赖有多种类型，常用的数据依赖有函数依赖和多值依赖，其中函数依赖是最重要也是最基本的一种数据依赖
1.2.1 函数依赖
函数依赖普遍地存在于现实生活中，它反映属性或属性组合之间相互依存、相互制约的关系
什么是函数依赖？
设R(U)是属性集U上的关系模式，X与Y是U的子集，r是R(U)的任意一个可能的关系（即一个二维表）。如果对于r中的任意两个元组（即两个记录，或两行数据）t和s，由t[X]=s[X]导致t[Y]=s[Y],则称X函数决定Y，或称Y函数依赖于X，记作X→Y。
函数依赖的相关术语和记号如下：
若X→Y，则称X为决定因素。
若X→Y,Y→X，则记作X←→Y。
也就是说只要在X上取值相等，则在Y上的取值一定是相等的
1.2.2 函数依赖的分类
关系数据库中函数依赖主要有以下几类：
平凡函数依赖和非平凡函数依赖
完全函数依赖和部分函数依赖
传递函数依赖
1.2.2.1 平凡函数依赖和非平凡函数依赖
设R(U)是属性集U上的关系模式，若对于任何X、Y∈U，有X→Y且Y∉X，则称X→Y是非平凡的函数依赖。反之，如果Y包含于X，则称X→Y是平凡的函数依赖。
例如
在学生关系模式（学号，姓名，年龄，性别，所在系别）中，学号→性别，（学号，姓名）→年龄，均为非平凡函数依赖。（学号，姓名）→姓名，为平凡函数依赖。
1.2.2.2 完全函数依赖和部分函数依赖
设R(U)是属性集U上的关系模式，如果X→Y，并且对于X的任何一个真子集X′，都不存在X′→Y，则称X→Y是一个完全函数依赖，即Y完全函数依赖于X，用F表示。
如果存在X′→Y成立，则称X→Y是一个部分函数依赖，即Y部分函数依赖于X，用P表示。
例如
在学生关系模式（学号，姓名，年龄，性别，所在系别）中：
（学号，姓名）→年龄，为部分函数依赖。因为（学号，姓名）属性组合中存在真子集学号，使得“学号→年龄”也成立，所以它是部分函数依赖。
学号→年龄，为完全函数依赖。
简答理解就是说 属性组 X 的所有属性一起（即完全）才能决定属性 Y，去掉任何一个属性都不行。相反的，部分函数依赖就是说 属性组 X 中的 部分属性就可以决定 Y ，用不着全部。
1.2.2.3 传递函数依赖
设R(U)是属性集U上的关系模式，如果X→Y，Y→Z，Y∉X，Z∉X，Z∉Y并且不存在Y→X，则称X→Z是一个传递函数依赖，即Z传递函数依赖于X。
例如
在职工关系模式（职工编号，姓名，所在车间，车间主任）中，职工编号→所在车间，所在车间→车间主任，并且不存在所在车间→职工编号，则车间主任传递函数依赖于职工编号。
注意上述定义中的条件不存在Y→X。如果不加上这一限制，当X→Y时允许Y→X，则X←→Y。而在X←→Y的条件下，Y→Z就等于X→Z。这样X就直接函数决定Z，而不是通过Y传递决定Z了，即非传递函数依赖。
1.3 码
1.3.1 候选码
设K为R(U) 中的属性或属性组合。若K完全依赖于U，则K称为R的一个候选码(CandidateKey)
对于关系 R(U) 中的属性（组）K，如果 U 完全函数依赖于 K，即 K 中的所有属性一起才能决定 U，则称 K 为 R(U) 的候选键
1.3.2 主码
若关系模式R有多个候选码，则选定其中的一个做为主码(Primary key)。
1.3.3 主属性与非主属性
包含在任何一个候选码中的属性 ，称为主属性 （Prime attribute）
不包含在任何码中的属性称为非主属性（Nonprime attribute）或非码属性（Non-key attribute）
例如
S(Sno, Sdept, Sage)，单个属性Sno是码
SC(Sno, Cno, Grade)中，(Sno, Cno)是码
1.4 范式
在关系数据库中，关系模式设计的好坏取决于它的函数依赖是否满足特定的要求。满足特定要求的模式称为范式，满足不同程度要求的为不同范式。
一般地，关系模式R为第几范式就可以写成R∈xNF。对于各种范式之间的联系有5NF⊂ 4NF⊂BCNF ⊂3NF⊂2NF⊂1NF成立。
通过关系模式分解，可以将一个低一级范式的关系模式转换为若干个高一级范式的关系模式的集合，这种过程就叫规范化
1.4.1 第一范式
如果关系模式R中的每一个属性都是不可分解的，则称R属于第一范 式，记作R∈1NF。
例如
设关系模式R（系别名称，高级职称人数）表示某学校系别的基本信息，假设系别信息状况如表
可以看出，“高级职称人数”属性是可以分解的，所以R不满足1NF。解决问题的办法是：将“高级职称人数”属性拆开，形成关系模式R1（系别名称、教授人数、副教授人数）。
显然，此时关系模式R1中的每一个属性列都是不可再分的，所以R1∈1NF
1.4.2 第二范式
如果关系模式R∈1NF，且每一个非主属性都完全函数依赖于候选码，则称R属于第二范式，记作R∈2NF。
例如
设关系模式R（仓库号，设备号，数量，地点）表示仓库设备的存储情况。候选码是（仓库号，设备号）属性组合，由于关系模式R中的每一个属性都不可再分，所以R∈1NF。因为非主属性“数量”完全函数依赖于候选码。非主属性“地点”部分函数依赖于候选码。即有（仓库号，设备号）→地点，仓库号→地点，所以R不满足2NF。
关系模式R中存在异常，比如某一个仓库只有一种设备，当这种设备被移走后，在删除此设备信息的同时将这个仓库的信息也删除了。
解决问题的办法是：用投影分解把关系模式R分解为两个关系模式。将部分函数依赖关系的决定方属性和非主属性从关系模式中提出，单独构成一个关系模式；将余下属性加上码（仍要保留部分函数依赖的决定方属性）构成另一关系模式。
按照上述方法分解，将关系模式R分解为R1(仓库号,设备号，数量)和R2(仓库号，地点)两个关系模式。此时，R1和R2均属于第二范式
1.4.3 第三范式
如果关系模式R∈2NF，且每一个非主属性都不传递函数依赖于候选码，则称R属于第三范式，记作R∈3NF。
例如
设关系模式R（仓库号，仓库面积，所在城市，所在省）表示不同仓库在各省市分布情况。候选码是仓库号，由于关系模式R中的每一个属性都不可再分，所以R∈1NF。又因为R中每一个非主属性都完全函数依赖于候选码，所以R∈2NF。又因为函数依赖有仓库号→所在城市，所在城市→所在省，所以仓库号→所在省，R中存在传递函数依赖，所以R不满足3NF。
关系模式R中存在异常，比如要在辽宁省大连市设立一个仓库，此时想先存入有关所在城市的信息，但由于没有仓库号，主码为空，则插入是失败的。
解决问题的办法是：用投影分解把关系模式R分解为两个关系模式，将传递函数依赖的属性分解出来，消除传递函数依赖。
按照上述方法分解，将关系模式R分解为R1（仓库号，仓库面积，所在城市）和R2（所在城市，所在省）两个关系模式。此时，R1和R2均属于第三范式。
1.4.4 BCNF（修正的第三范式）
如果关系模式R∈3NF，且没有一个属性部分函数依赖或传递函数依赖于候选码，则称R属于修正的第三范式，记作R∈BCNF。
规范化的基本思想是，逐步消除数据依赖中不合理的部分，使每一个关系模式更趋于完美。但并不是范式越高越好，范式越高，模式分解的越多，我们在进行数据查询的时候往往要进行许多张表的连接，系统开销较大，查询效率较低。所以，在进行关系模式规范化的过程中，关系模式一般分解到3NF就认为是比较好的了。
在银行管理系统的数据库中，有一关系模式为R（BNO，SSNO，BNAME，ADDRESS，CITY，SNAME，SEX，AGE，ACCOUNT），其中属性分别表示银行编号，身份证号，银行名称，银行所在地点，银行所在城市，顾客姓名，性别，年龄，账户号。我们写出该关系模式的主码，并对其进行规范化，以达到3NF
该关系模式R的主码为（BNO，SSNO）。由于关系模式R中的每个分量都是不可再分的数据项，所以R满足1NF。关系模式R中存在以下函数依赖：
（BNO，SSNO）→BNAME， BNO→BNAME，
（BNO，SSNO）→ADDRESS， BNO→ADDRESS，
（BNO，SSNO）→CITY， ADDRESS→CITY，
（BNO，SSNO）→ACCOUNT， BNO→CITY，
（BNO，SSNO）→SNAME， SSNO→SNAME，
（BNO，SSNO）→SEX， SSNO→SEX，
（BNO，SSNO）→AGE， SSNO→AGE，
首先，关系模式R满足1NF，但存在部分函数依赖，所以，R不满足2NF,将其分解为：
R1（BNO，SSNO，ACCOUNT）∈2NF；
R2（BNO，BNAME，ADDRESS，CITY）∈2NF；
R3（SSNO，SNAME，SEX，AGE）∈2NF；
其次，关系模式R1、R3均已满足第三范式，但关系模式R2存在传递函数依赖，R2不满足第三范式，将R2分解为：
R4（BNO，BNAME，ADDRESS）∈3NF；
R5（ADDRESS，CITY）∈3NF；
最后，R1、R3、R4、R5满足第三范式，总结为：
R1（BNO，SSNO，ACCOUNT）；
R3（SSNO，SNAME，SEX，AGE）；
R4（BNO，BNAME，ADDRESS）；
R5（ADDRESS，CITY）。
二、数据库设计概述
2.1 数据库设计的方法
早期数据库设计主要采用手工与经验相结合的方法。设计的质量往往与设计人员的经验与水平有直接的关系，设计质量难以保证。人们通过运用软件工程的思想和方法，提出了各种数据库设计方法，以及各种设计准则和规程，这些都属于规范设计方法。
例如
关系模式的设计方法
新奥尔良（New Orleans）方法
基于E-R模型的数据库设计方法
3NF（第三范式）的设计方法
基于抽象语法规范的设计方法
计算机辅助数据库设计方法
2.2 数据库设计的步骤
从数据库应用系统设计和开发的全过程来考虑，一般将数据库设计的步骤分为七个阶段：
系统规划阶段
需求分析阶段
概念结构设计阶段
逻辑结构设计阶段
物理结构设计阶段
实施阶段
运行和维护阶段
三、系统规划阶段
3.1 系统规划的任务
系统规划阶段的主要任务就是进行系统的必要性和可行性分析。包括明确应用系统的基本功能，划分数据库支持的范围；规划人力资源调配；拟定设备配置方案；选择合适的操作系统、DBMS和其他软件；设备配置方案要在使用要求、系统性能、购置成本和维护代价各方面综合权衡；对系统的开发、运行、维护的成本作出估算；预测系统效益的期望值；拟定开发进度计划，还要对现行工作模式如何向新系统过渡作出具体安排。
3.2 系统规划的成果
规划阶段的工作成果是写出详尽的可行性分析报告和数据库应用系统规划书。内容应包括：系统的定位及其功能、数据资源及数据处理能力、人力资源调配、设备配置方案、开发成本估算、开发进度计划等。
可行性分析报告和数据库应用系统规划书经审定立项后，成为后续开发工作的总纲
