数据库设计理论及方法

2.1 数据库设计的理论依据
如何评价一个数据库设计得是否合理？
人们总结出衡量数据库的理论标准——就是关系数据库的规范化理论，它也是指导数据库设计的理论依据。

数据库设计完后，就得到关系模式的集合，为了评价一个关系模式集合的优劣，常常使用范式（Normal Form）来进行描述。

可以把范式理解为符合某一种级别标准的关系模式的集合。

目前专家们提出了第一范式到第五范式的概念，本章只讨论前三个范式及第三范式的改进形式BCNF（Boyce Codd Normal Form）范式。

用R(U,F)来描述一个关系，其中：
R：关系名；
U：关系中所有属性的集合；
F：关系中所有函数依赖的集合。

函数依赖：如由学号能唯一确定一个学生的姓名，则称“学号”决定“姓名”，也称：“姓名”函数依赖于“学号” 。

记作：学号→姓名，即学号是决定因素。

第一范式
所谓第一范式(1NF)：是指关系（数据表）的每一属性（列）都是不可分割的基本数据项,同一列不能有多个含义。

1NF是关系数据库的基本规则，不满足1NF的要求，就不能称其为关系数据库。

第一范式表达了以下三个意思：
(1) 一个表中不能存在两个含义重复的属性。

如：员工信息表中有员工编号、工作证编号及其它属性，而员工编号、工作证编号都是唯一区分员工记录的属性，且取值相同，保留一个即可。

(2)一个表中的一列不能是其他列计算的结果。

例：商品信息表中的
最高售价=建议售价+浮动价格
例商品信息表中，“建议售价”只能代表一个币种的价格，不可能既表示人民币价格又表示美元价格。

如果一定要标出两个币种的价格，可以将“建议售价”分解为两列：“人民币售价”和“美元售价”。

第二范式(2NF)：
第二范式:是指非主属性完全函数依赖于主码（主键）的属性组。

2NF是在1NF的基础上制定的，即设计数据库时，在考虑第二范式的规定时首先要满足第一范式的要求。

例如
关系模式S-L-C(学号,课程号,系,住处,成绩)，并且每个系的学生住在同一个地方，即系决定住处。

这里主码为(学号,课程号)。

关系模式的函数依赖如下：
(学号,课程号)→成绩,表示成绩完全函数依赖于(学号,课程号) ，即(学号,课程号)完全决定成绩。

学号→系，表示学号决定系，即系函数依赖于学号；
(学号,课程号)→系，表示系部分函数依赖于主码(学号,课程号)；
学号→住处，表示学号决定住处
(学号,课程号) →住处， 表示住处部分函数依赖于主码(学号,课程号)
可见非主属性系、住处并不完全函数依赖于码。

因此S-L-C(学号,系,课程号,住处,成绩) 不符合2NF 定义，即S-L-C 不属于2NF 。

一个关系模式不属于2NF ，就会产生以下几个问题：
插入异常。

假若要插入一个学生记录：学号=’0403030430’，系=’IS’，住处=’L2’，但该生还未选课，即这个学生无课程号值，这样的元组就插不进S-L-C 中。

因为插入元组（记录）时必须给定主码值，而这时主码值的部分为空（主属性为空），因而学生的基本信息无法插入。

删除异常。

假定某个学生只选一门课，如0403030430就选了一门课c01。

现在就连c01这门课他也不选了，那么c01这个数据项就要删除。

而c01是主属性，删除了c01，整个元组就必须跟着删除，使得0403030430的其他信息也被删除了，从而造成删除异常，即不应删除的信息也删除了。

数据冗余度大。

如某学生选10门课，则其系和住处信息要重复存储10次。

修改复杂。

某个学生从数学系转到计算机科学系，这本来只需修改此学生元组中的系分量。

但因为关系模式S-L-C 中还含有学生的住处属性，学生转系同时还将改变住处，因而还必须修改元组中的住处分量。

另外，如果这个学生选修了k 门课，系和住处重复存储了k 次，不仅存储冗余度大，而且必须修改k 个元组中全部系和住处信息，造成修改的复杂化。

可见由于系，住处，对主码不是完全函数依赖,会出现以上问题。

解决的办法是将关系模式S-L-C 分解为以下两个关系模式： SC(学号，课程号，成绩) S-L(学号，系，住处)
2NF 。

第三范式(3NF)：
第三范式：指非主属性不传递函数依赖于码, 即非主属性都直接函数依赖于码。

3NF 是在2NF 的基础上制定的，若要满足第三范式，必须先满足第二范式。

例，图2.3
中关系模式S-L 存在非主属性对主码传递函数依赖： 学号→系 系→住处 学号→住处 不符合3NF 。

SC(学号，课程号，成绩) S-L(学号，系，住处)
不符合3NF 也会产生以下几个问题：
插入异常：如某系刚成立，当前还没有学生(无学号值)，也就无法插入该系的信息。

删除异常：如果某系的学生全部毕业了，在删除学生信息时，也删除了系的信息。

数据冗余大：每个学生都住在同一楼。

住处信息重复出现。

修改复杂：当学校调整学生宿舍时，一个系的学生都迁到另一个楼，由于每个系的学生住处信息重复存储，修改时要重复修改。

解决办法：
图2.2 SC 中的函数依赖
图2.3 S-L 中的函数依赖
将关系 S-L(学号，系，住处)分解为以下两个关系： S-D(学号，系) D-L(系，住处)
分解后的关系模式S-D 与D-L 都属于3NF 。

同时每个决定因素都是候选码，所以S-D 与D-L 也属于BCNF 。

BCNF 比3NF 更进了一步。

在3NF 的基础上,消去所有部分函数依赖，包括主属性对不包含它的候选码的部分函数依赖, 就属于BCNF.
关系规范化的过程就是将一个非规范化关系或低级范式关系分解为多个高级范式关系的过程。

任何一个非规范的关系都可以经过分解达到3NF ，但不一定能达到BCNF 。

关系分解通常可以遵循图2.4所示过程。

2.2 数据库设计方法
数据库的设计大概分如下几步进行：
规划阶段：系统调查、可行性分析、制订项目开发计划
需求分析：计算机人员（系统分析员）和用户双方共同收集数据库所需要的信息内容和用户对处理的需求。

并以需求说明书的形式确定下来，作为以后系统开发和系统验证的依据。

概念结构设计 逻辑结构设计 物理结构设计 数据库的实现
数据库的运行和维护 2.2.1 规划阶段
对于数据库系统，特别是大型数据库系统或大型信息系统中的数据库群，规划阶段是十分必要的。

规划的好坏将直接影响到整个系统的成功与否。

一般分以下三步：
（1）系统调查。

对企业组织进行全面的调查，画出组织层次图，以了解企业的组织机构。

（2）可行性分析。

从经济、效益和法律等方面对建立数据库的可行性进行分析；然后写出可行性分析报告；组织专家进行讨论其可行性。

（3）确定数据库系统的总目标和制订项目开发计划。

在得到决策部门批准后，就正式进入数据
把组合属性分解为不可再分的属性
消去非主属性对主码的部分函数依赖
消去所有部分函数依赖，包括主属性对不包含它的候选码的部分函数依赖
图2.4 关系分解过程
库系统的开发工作。

2.2.2 需求分析
数据库的性能是由用户决定的，所以充分了解用户需求是完成数据库设计的关键。

计算机人员（系统分析员）和用户双方共同收集数据库所需要的信息内容和用户对处理的需求。

并以需求说明书的形式确定下来，作为以后系统开发和系统验证的依据。

需求工作可分以下四步完成：
分析用户活动，产生用户活动图
确定系统范围，产生系统关联图
分析用户活动所涉及的数据，产生数据流图
分析系统数据产生数据字典
下面通过一个简单的教学管理系统来说明这四个步骤应完成的功能。

例2-1 学校教学管理信息系统要完成如下功能
（1）教师聘课、（2）学生选课
1 分析用户活动，产生业务流程图
如果系统比较复杂，可以从了解用户日常工作流程入手，通过座谈会、与职员共同工作、设计调查问卷、查阅历史业务记录等途径来搞清业务的处理过程。

在分析之后画出“用户活动图”。

这一步是确定系统的边界，即确定用计算机处理的范围。

在和用户经过充分协商的基础上确定计算机所能进行的数据处理的范围，确定哪些工作由人工完成，哪些工作由计算机系统完成，即确定人机界面。

深入分析用户的业务处理，以数据流图形式表示出数据的流向和对数据所进行的加工。

数据流图（Data Flow Diagram,简记为DFD）
是从“数据”和“对数据的加工”两方面表达数据处理系统工作过程的一种图形表示法，具有直观、易于被用户和软件人员双方都能理解的一种表达系统功能的描述方式。

数据流图由四部分组成：数据流、加工、文件、源点和终点。

数据流图的组成：
(1)数据流：表示流动着的数据，它可以是一项数据，也可以是一组数据，也可以是表示数据文
件的存储操作。

数据流图通常用箭头表示，在它上方标明数据流的名称。

(2)加工又称功能处理：用圆形来表示处理逻辑，圆形内部填写处理的名称(如任课、选课等 )。

(3)文件：用一条横线表示，旁边注明文件名或内容。

(4)源头和终点: 用矩形表示，表示数据流的开始和结束（可以省略）。

以下是一个简单的数据流图
数据流图的每个部分都要命名以便区分。

上图是一个简单的数据流图,其含义是数据流D1从始点S 流出，经过P1加工处理变成数据流D2，P1加工时要调用文件F1中的内容，数据流D2再经过P2加工处理，加工处理时要把部分结果存放到文件F2中，同时产生数据流D3，数据流D3流往终点E 。

如前面讨论的学校教学管理，最初的数据流图可表示成图2-7的样子。

教学信息管理系统教师学生教师学生任课请求选课请求聘书课程表图2-7学校教学管理系统的最初数据流图
教师提出任课请求，经教学信息管理系统处理后，形成聘书交给教师。

学生提出选课请求后，经教学信息管理系统处理后，形成课程表交给学生。

逐步细化：在图2-7基础上，详细画出的系统内部各数据流图分别如图2-8、图2-9所示。

图2-7 学校教学管理系统的最初数据流图
设计者必须对数据流图中的每个数据流名、文件名、加工名都要给出具体定义，并用一个条目来描述，描述后的产物就是“数据字典”。

数据字典和数据流图共同构成系统说明书。

数据流的描述：也就是定义数据流的组成，每个数据流通常包括若干个数据项。

下面是对图2-8中的几个数据流的描述：
任课请求=教师号+教师姓名+课程号+课程名称+总学时+班级数
聘书=教师姓名+课程名称+上课时间+上课地点
文件的描述
教师=教师编号+姓名+性别+年龄+系名
数据项的描述
是指对数据项进行定义，一般包括对数据项的名称、类型、长度、取值范围进行定义。

如对“学生”文件中的数据项，可按表2-8进行描述。

加工的描述：
用来对实现加工的处理过程进行描述和定义，包括过程名、过程说明、输入输出和过程功能说明等。

如对学生选课处理过程描述如下：
过程名称：选课。

过程说明：主要说明该处理过程的功能及处理要求。

例如：学生根据自己的需要选课。

输入：执行该处理过程需要输入的数据。

例如：选课请求和学生基本信息。

输出：执行该处理过程后输出的数据。

例如：课程表。

至此，需求分析阶段已经完成，已经得到了由“数据流图”和“数据字典”组成的“系统说明书”，基本上解决了做什么的问题，在下一阶段将解决“怎样做”的问题。

2.2.3 概念结构设计（E-R模型）
1. E-R图的组成要素及其画法
E-R图有三个基本要素：实体、联系、属性
其表示方法如下：
实体名属性名联系名
E-R图的画法：
把相互有联系的实体(矩形)通过联系(菱形)连接起来，再把实体的属性(椭圆框)连到实体上。

2. 实体间不同联系情况的E-R图
根据数据的复杂程度不同，实体间的联系基本有以下三种：
一对一(1 : 1)、一对多(1 : n)、多对多(n : m)
例1 两个实体集之间的一对一(1 : 1) 联系的绘制
设某学院有若干个教研室，每个教研室只有一个主任，则主任和教研室之间就是一对一的关系。

主任和教研室的属性分别如下：
主任：编号、姓名、年龄、学历
教研室：教研室编号、教研室名
主任和教研室之间的联系是“管理”关系，这个“管理”用一个属性——“任职时间”来描述
描述主任和教研室之间的信息关系的E-R图：
例2 两个实体集之间的一对多的联系的绘制
假设某仓库管理系统中，有两个实体集：仓库、商品，且规定一类商品只能存放在一个仓库中，每个仓库可以存放多种商品。

仓库和商品之间是一对多的联系。

属性如下
仓库：仓库号、地点、面积
商品：商品号、商品名、价格
两实体间是“存放”的联系,并反映存放商品的数量。

描述仓库和商品之间的信息关系的E-R图：
例3. 两个实体集之间的多对多的联系的绘制
设某教务管理系统中，一个教师可以讲述多门课，一门课可以有多个老师讲授，则教师和课程之间是多对多的联系。

教师和课程两实体属性如下：
教师：教师编号、教师姓名、职称
课程：课程编号、课程名、学分
两实体间是“讲授”的联系,另外在“讲授”联系中，要反映授课质量。

描述教师和课程之间的信息关系的E-R图：
如果实体的属性太多，则可以将实体及其属性单独画图，在E-R图中只画实体及其联系。

如例3可以这样画：
E-R图的设计方法
设计E-R图一般经过以下两个阶段：
（1）画出每一用户的局部E-R图，确定该用户的实体、属性和联系。

（2）综合局部E-R图，生成总体E-R图。

在总体E-R图中，同名的实体只能出现一次。

注意：一个系统E-R图不是唯一的，强调不同的侧面画出的E-R图可能有很大不同。

1 局部E-R模型的设计
根据数据流图和数据字典的相关内容，确定实体，及其属性、实体之间的联系。

例2-2 设计教学信息管理系统的局部E-R图。

如图2-10至图2-13所示。

2 总体E-R模型的设计
综合局部E-R图，生成总体E-R图。

在总体E-R图中，同名的实体只能出现一次。

例2-3 将上例的局部E-R图2-12、2-13，合并成总体E-R图。

2.2.4 逻辑结构设计
逻辑结构设计的实质是把E-R图转换为具体的DBMS支持的数据模型——关系模型。

把E-R图转换为关系模型的方法，通常分为初步设计和优化设计两步进行。

初步设计——根据转换规则，把E-R图转换为关系模型
优化设计——对模式进行调整和改善
1 E-R图转换为关系模型遵循的一般规则
(1)对于E-R图的每个实体集转换为一个关系模型(对应一个表)，其中包括实体的所有属性，并确定某个属性或几个属性组作为主码（主键）。

(2)对各种“联系”进行转换的规则：
对于E-R图中的“联系”，要根据不同的联系方式，采取不同的手段加以实现。

多对多(m : n)联系的转换
对于这种联系，必须对“联系”单独建立一个关系（表），用来联系双方实体集，该关系中要包含双方实体集的主码，若“联系”本身有属性，也要纳入该关系中。

而该关系的主码为各实体主码的组合。

例2-4 将图2-12转换成关系模式
学生（学号，姓名，性别，年龄，系），主码是学号。

课程（课程号，课程名称，先修课号，学分），主码是课程号。

将m:n(多对多)的联系转换为独立的关系模式：
选修（学号，课程号，成绩），主码是学生实体的主码（学号）和课程实体的主码（课程号）的组合。

一对多(1 : n)联系的转换：
方法1：可将“1方”实体集的主码，纳入“n方”实体集关系(表)中作为外码，同时把“联系”的属性也一并纳入“n方”关系中。

方法2：对“联系”单独建立一个关系，该关系中要包含双方实体集的主码，若“联系”有属性，也要纳入该关系中。

主码是n端实体的主码.
对例2的仓库与商品的E-R图（1 : n）
方法1：可转换为以下两个关系模式(带下划线的红色属性表示主码，兰色表示外码)：
仓库（仓库号、地点、面积）
商品（商品号、商品名、价格、数量、仓库号）
方法2：将“存放”联系转换为一个独立的关系模式
仓库（仓库号、地点、面积）
商品（商品号、商品名、价格）
存放（商品号、仓库号、数量）,主码是n端实体的码，即商品号。

一对一(1 : 1)联系的转换有三种方法：
方法1.
建立第三个关系，关系中包含两个实体集的主码，如果联系有属性，也一并加入。

方法2.
把B实体集的主码加入到A实体集对应的关系中，如果联系有属性，也一并加入。

方法3.
把A实体集的主码加入到B实体集对应的关系中，如果联系有属性，也一并加入。

例2-6 将图2-16转换成关系模式。

方法1、“任职”联系转换为一个独立的关系模式：
班长（班长学号，姓名，性别，年龄，系）
班级（班号，人数）
任职（班长学号，班号，任职时间）主码是班长学号或班号。

方法2、将“班级”关系中的主码及联系的属性纳入“班长”的关系模式中：
班长（班长学号，姓名，性别，年龄，系，班号，任职时间），主码是班长学号。

班级（班号，人数），主码是班号。

方法3、将“班长”关系中的主码及联系的属性纳入“班级”的关系模式中：
班长（班长学号，姓名，性别，年龄，系），主码是学号。

班级（班号，人数，班长学号，任职时间），主码是班号。

多元联系的转换：
三个或三个以上实体间的多元联系可以转换为一个单独的关系模式。

与该多元联系相连的各实体的主码以及联系本身的属性均转换为此关系的属性，而此关系的主码为各实体码的组合。

例2-7 将图2-17 转换成关系模式
各实体的属性如下：
售货员：售货员编号、姓名、性别、年龄、工龄
顾客：顾客编号、顾客名称、住址、电话
商品：商品编号、商品名称、价格、进货时间
转换以后的关系模式如下：
售货员（售货员编号，姓名，性别，年龄，工龄）
顾客（顾客编号、顾客名称、住址、电话）
商品（商品编号、商品名称、价格、进货时间）。

销售（售货员编号，顾客编号，商品编号，销售量），主码为：售货员编号，顾客编号，商品编号这三个属性的组合。

例2-8. 将图2-15的全局E-R图转换为关系模型。

根据上述规则，转换的方法如下：
(1) 将实体转换为独立的关系模式：
学生（学号，姓名，性别，年龄，系）
教师（教师号，性名，性别，职称，电话号码）
课程（课程号，课程名称，学时，学分）
(2) 将多对多联系转换为独立的关系模式：
选修（学号，课程号，成绩），主码是（学号，课程号）两个属性的组合。

任课（教师号，课程号，学期，授课类别，班数）主码是（教师号，课程号，学期）三个属性的组合。

每个关系模型就对应一个表了
2 优化
所谓优化，就是从提高效率的角度出发，根据具体情况，对模式结构作进一步调整和改善.
一般用三方面指标来衡量：
单位时间内所访问的逻辑记录个数要少；
单位时间内数据传送量要少；
系统占用的存储空间尽量要少。

虽然可以通过计算，对性能进行预测，但是实用意义不一定很大，通常采取定性判断方法，估计不同设计方案的性能优劣。

最常用的优化方法就是通过对记录进行垂直或水平分解，改善性能。

下面举例说明。

例2-9 要查询学生信息时，经常对在校生进行查询，但有时也查询离校生的相关信息，为改善性能，使得单位时间内访问逻辑记录的个数尽量少，请给出一个分解方法。

原来的学生的关系为：
学生（学号，姓名，性别，年龄，系）
可对其进行水平分解，使其成为两个关系，一个关系用来存放在校生的信息，另一个关系用来存放离校生的信息，如下：
在校学生（学号，姓名，性别，年龄，系）
离校学生（学号，姓名，性别，年龄，系）
这样，当查询在校生或离校生的信息时，就只需在相应的关系中查找，显然单位时间内访问的记录数量大大减少了。

2.2.5 物理结构设计
数据库在实际的物理设备上的存储结构和存取方法称为数据库的物理结构，数据库的物理结构与具体的DBMS(数据库管理系统)有关。

数据库物理设计的任务是使数据库的逻辑结构在物理设备上得以实现，建立一个性能优良的数据库物理结构。

数据库的物理设计，主要应考虑4个方面的问题：
1 存储结构的选择
选择何种存储结构，与选定的DBMS类型有关
2 属性存储类型的确定
不同DBMS系统的数据类型稍微有点区别，因此需要针对不同的DBMS来确定每个属性的存储类型。

3 表的索引结构的确定
为了提高表的检索速度，确定表的索引结构。

4 存取路径的确定
对关系模型而言，由系统自动完成的。

2.2.6 数据库的实现
根据逻辑设计和物理设计的结果，利用特定的DBMS（如SQL Server 2000、Access等）在计算机系统上建立实际数据库结构、数据表、装入数据、编制应用程序、测试和试运行的过程称为数据库的实现阶段。

2.2.7 数据库的运行与维护
1 对日常数据库操作进行维护
可以随时对数据库进行增、删、改、插入、更新等操作.
2 维护数据库的结构
指重构和重组数据库
3 维护数据库的安全性与完整性
检查系统的安全性，能及时调整授权和密码，数据的备份及恢复
4 改善运行性能
2.3 编写技术文档
技术文档主要包括
1 系统说明书
包括数据流图、数据字典，表达用户的需求
2 技术说明书
用户活动图、数据流图、数据字典
E-R图
关系模型
表结构
3 使用说明书
用来指导使用者使用本数据库系统。

使用说明书包括软件的操作步骤、维护中应注意的问题等内容。

小结
主要介绍数据库系统的开发过程。

数据库的开发过程基本上可分成规划阶段，需求分析，概念结构设计，逻辑结构设计，物理结构设计，数据库的实现，数据库的运行和维护等七个阶段。

在需求分析阶段，产生用户活动图，根据用户活动图设计出数据流图和数据字典，最后根据数据流图和数据字典设计出数据库模式。

E-R图的设计方法，E-R模型转换为关系模型的方法
作业：
题2.11图书借阅管理数据库要求提供下述服务：
（1）可随时查询书库中现有书籍的品种、数量与存放位置。

所有各类书籍均可由书号惟一标识。

（2）可随时查询书籍借还情况，包括借书人单位、姓名、借书证号、借书日期和还书日期。

我们约定：任何人可借多种书，任何一种书可为多个人所借，借书证号具有惟一性。

（3）当需要时，可通过数据库中保存的出版社的电报编号、电话、邮编及地址等信息向相应出版社增购有关书籍。

我们约定，一个出版社可出版多种书籍，同一本书仅为一个出版社出版，出版社名具有惟一性。

出版社出版书应有出版时间。

请根据以上描述解答以下问题：
1）设计满足以上要求的E-R图。

2）根据E-R图转换为等价的关系模式。

题2.12 在某教务管理系统中，涉及如下实体：
分院：分院编号，分院名称，院长姓名，电话
教师：教师编号，教师姓名，性别，年龄，职称，专业
学生：学号，姓名，性别，年龄，专业，入学时间
课程：课程号，课程名，学时数，学分
这些实体之间的联系如下：
一个学院有多个教师，一个教师只能属于一个学院；
一个学院有多个学生，一个学生只能在一个学院注册；
一个教师可以讲授多门课程，一门课程可以由多位教师讲授，教师讲授某门课程有一个评价。

请根据以上描述解答以下问题：
1）设计满足以上要求的E-R图。

2）根据E-R图转换为等价的关系模式。

第2章结束。