第7章 数据库设计 本章要点数据库设计的任务和特点数据库设计的方法数据库设计的步骤概念结构设计概念模型及其表示方法概念结构设计的步骤逻
辑结构设计E-R图向关系模型的转换数据库设计实例7.1 数据库设计概述一般地讲，数据库设计是指对于一个给定的应用环境，构造
优化的数据库逻辑模式和物理结构，并据此建立数据库及其应用系统，使之能够有效地存储和管理数据，满足用户的信息管理需求和数据操作需求。
7.1.1 数据库设计的任务和特点对开发人员要求更高数据库设计的基本规律三分技术，七分管理，十二分基础数据 数据结构设计与应用系
统设计相结合评判准则完备性数据库应能表示应用领域所需的所有信息，满足数据存储需求，满足信息需求和处理需求，同时数据是可用的、准确的
、安全的 。一致性数据库中的信息是一致的，没有语义冲突和值冲突。尽量减少数据的冗余。评判准则优化数据库应该规范化和高效率，易于各种
操作，满足用户的性能需求。 易维护好的数据库维护工作量比较少，需要维护时，改动比较少而且方便修改，扩充性好，不影响数据库的完备性和
一致性，也不影响数据库性能。 7.1.2 数据库设计方法手工试凑法规范设计法计算机辅助设计方法7.1.3 数据库设计步骤需求分析
；概念结构设计；逻辑结构设计；物理结构设计；数据库实施；数据库运行和维护。7.1.4 数据库设计过程中的各级模式数据库的各级模式是
在设计过程中逐步形成的需求分析阶段综合各个用户的应用需求。概念设计阶段形成独立于机器、独立于各个DBMS产品的概念模式，用E-R图
来描述。在逻辑设计阶段将E-R图转换成具体的数据库产品支持的数据模型如关系模型，形成数据库逻辑模式。然后根据用户处理的要求，安全性
的考虑，在基本表的基础上再建立必要的视图形成数据的外模式。在物理设计阶段根据DBMS特点和处理的需要，进行物理存储安排，设计索引，
形成数据库内模式。需求分析阶段 概念设计阶段 逻辑设计阶段 物理设计阶段需求分析阶段综合各个用户
的应用需求概念设计阶段形成独立于机器、独立于各个DBMS产品的概念模式，用E-R图来描述。在逻辑设计阶段将E-R图转换成具体的数据
库产品支持的数据模型如关系模型，形成数据库逻辑模式。然后根据用户处理的要求、安全性的考虑，在基本表的基础上再建立必要的视图形成数据
的外模式。在物理设计阶段根据DBMS特点和处理的需要，进行物理存储安排，设计索引，形成数据库内模式。7.2 需求分析7.2.
1 需求分析的任务需求分析的任务是通过详细调查现实世界要处理的对象（组织、部门、企业等），充分了解原系统（手工系统或计算机系统）工
作概况，明确用户的各种需求，然后在此基础上确定新系统的功能。新系统必须充分考虑今后可能的扩充和改变，不能仅仅按当前应用需求来设计数
据库。获得用户对数据库的要求： 信息要求。 处理要求。 安全性与完整性要求。7.2.2 需求分析的方法和步骤调查组织机构情况调查
各部门的业务活动情况在熟悉业务活动的基础上，协助用户明确对新系统的各种要求。确定新系统的边界 数据流图和数据字典数据流图表达了数
据和处理过程的关系数据字典是各类数据描述的集合数据字典是进行详细的数据收集和数据分析所获得的主要结果数据字典通过对数据项和数据结构
的定义来描述数据流、数据存储的逻辑内容。1. 数据项：数据项是不可再分的数据单位。2. 数据结构：数据结构反映了数据之间的组合关系
。3. 数据流：据流是数据结构在系统内传输的路径。4. 数据存储：数据存储是数据及其结构停留或保存 的地方，也是数据流的来源和去向
之一。数据存储可以是手工文档、手工凭单或计算机文档。7. 处理过程：用判定表或判定树来描述。数据字典的构成面向对象的需求分析方法(
1) 确定系统的参与者。参与者是目标系统直接接触的一切人或物，包括:系统的使用者管理或维护人员系统控制的硬件设备与其有交互的其他系
统面向对象的需求分析方法(2) 为每个参与者确定其所有的用例，确定系统的边界。对于参与者来说，一个用例应该是一个完整的任务。一个用
例一般是在一个相对连续的时间内完成。用例的内容需要和用户反复讨论，逐步修改和细化。用例之间存在包含（include）与扩展（ext
end）关系。包含关系表示一种从属关系，即子用例是主用例中相对独立的、必须调用的一部分功能。扩展关系表示一个功能是对另一个功能的扩
展，即被扩展功能不一定调用扩展功能，但扩展功能是对被扩展功能的加强与延伸。面向对象的需求分析方法(3) 为每个用例生成用例描述表和
用例活动图用例描述表的内容包括用例名称执行者前置条件、后置条件用例过程的详细描述分支过程描述异常过程描述业务规则7.2.3 需求
分析的结果需求分析的主要成果是需求说明书需求说明具有正确性、无歧义性、完整性、一致性、可理解性、可修改性、可追踪性和注释等。需求说
明要得到用户的验证和确认。7.3 概念结构设计概念结构设计的目的获取数据库的概念模型，将现实世界转化为信息世界，形成一组描述现
实世界中的实体及实体间联系的概念。7.3.1 概念模型及表示方法 概念模型的用途概念模型用于信息世界的建模现实世界到机器世界的一
个中间层次数据库设计的有力工具数据库设计人员和用户之间进行交流的语言对概念模型的基本要求较强的语义表达能力，能够方便、直接地表达应
用中的各种语义知识简单、清晰、易于用户理解。1、概念模型中的基本概念 实体客观存在并可以相互区别的事物称为实体例：一个学生、一个
学校、一个操作流程 属性实体所具有的某一特性称为属性例：（081637121，黎明，男，1987-5-11 ）多个实体集间的联系
(续)实例1课程、教师与参考书三个实体集一门课程可以由若干个教师讲授，使用若干本参考书；每一个教师只讲授一门课程；每一本参考书只供
一门课程使用。课程与教师、参考书之间的联系是一对多的1、概念模型中的基本概念 码唯一标识实体的属性集称为码。例：学生实体的学号属
性 域某个(些)属性的取值范围。例：性别的域为（男，女）1、概念模型中的基本概念实体集所有属性完全相同的同型实体的集合，称为实体
集。例：学生（学号，姓名，性别，系，入学时间）联系不同实体集之间的关系。实体集之间的联系可以归结为三种类型：一对一联系(1：1）一
对多联系(1：n)多对多联系(n：m)2、概念模型中实体的联系 一对一联系（1：1）一对多联系（1：n）多对多联系（n：m）一对一
联系(1：1）语义如果对于实体集A中的每一个实体，实体集B中至多有一个实体与之联系，反之亦然，则称实体集A与实体集B具有一对一联系
。记为1:1。 实例部门与经理之间的联系：一个部门只能有一名经理每一名经理只能在一个部门任职请再举例……一对多联系(1：n)语义如
果对于实体集A中的每一个实体，实体集B中有n个实体（n≥0）与之联系，反之，对于实体集B中的每一个实体，实体集A中至多只有一个实体
与之联系，则称实体集A与实体集B有一对多联系。 记为1:n实例部门与职工之间的联系一个部门有若干名职工每一名职工只能在一个部门
工作请再举例……多对多联系(n：m)语义如果对于实体集A中的每一个实体，实体集B中有n个实体（n≥0）与之联系，反之，对于实体集B
中的每一个实体，实体集A中也有m个实体（m≥0）与之联系，则称实体集A与实体集B具有多对多联系。记为m:n实例 课程与学生之间的联
系一门课程同时有若干个学生选修一个学生可以同时选修多门课程请再举例……练习：判断下列联系的类型产品 、材料借书人、图书工厂、职工病
房、病人工厂、厂长多个实体集间的联系(续)实例2 供应商、项目与零件三个实体集一个供应商可以供给多个项目多种零件；每个项目可
以使用多个供应商的零件；每种零件可由不同供应商供给。供应商、项目与零件之间的联系是多对多的。多个实体集间的联系一对多联系语义若实体
集E1，E2，...，En存在联系，对于实体集Ej（j=1，2，...，i-1，i+1，...，n）中的给定实体，最多只和Ei中的
一个实体相联系，则我们说Ei与E1，E2，...，Ei-1，Ei+1，...，En之间的联系是一对多的。多个实体集间的联系(续)课
后自己写出定义多个实体集间的一对一联系多个实体集间的多对多联系同一实体集内各实体间的联系一对多联系实例 职工实体集内部具有领导与被
领导的联系：某一职工（干部）“领导”若干名职工，一个职工仅被另外一个职工直接领导，这是一对多的联系。一对一联系多对多联系3、概念模
型的表示方法概念模型的表示方法很多实体－联系模型(E-R模型)用E-R图来描述现实世界的概念模型E-R 图实体（实体集）用矩形表示
，矩形框内写明实体名。E-R 图（续）属性用椭圆形表示，并用无向边将其与相应的实体连接起来。E-R 图（续）联系联系本身：用菱形表
示，菱形框内写明联系名，并用无向边分别与有关实体连接起来，同时在无向边旁标上联系的类型（1:1、1:n或m:n）联系的属性：联系本
身也是一种实体，也可以有属性。如果一个联系具有属性，则这些属性也要用无向边与该联系连接起来 。E-R 图（续）联系的表示方法E-R
图（续）联系属性的表示方法概念模型举例【例7.1】为某百货公司设计一个E-R模型。百货公司管辖若干个连锁商店，每家商店经营若干商
品，每家商店有若干职工，但每个职工只能服务于一家商店。商店的属性有：店号，店址，经理。商品的属性有：商品号，商品名，单价，产地。职
工的属性有：职工号，职工名，性别，工资。在联系中应反映出职工参加某商店工作的开始时间，商店销售商品的有销售量。 概念模型举例（续）
建立E-R模型的步骤：(1) 确定实体和实体的属性；(2) 确定实体之间的联系及联系的类型；(3) 给实体和联系加上属性。 7.3
.2 概念结构设计的方法 数据库设计各阶段的任务相对单一化，设计复杂程度得到降低，便于组织管理。 概念模型能准确、客观、充分地反映
现实世界，包括事物及事物之间的联系，能满足用户对数据的处理要求，是现实世界的真实模型，具有较强的表达能力。概念模型不受特定数据库管
理系统限制，也独立于存储安排，因而比逻辑设计得到的模式更为稳定。 概念模型不含具体的数据库管理系统所附加的技术细节，更容易为用户所
理解，因而能准确反映用户的信息需求。从而可以用它和不熟悉计算机的用户交换意见，用户的积极参与是数据库设计成功的关键。 当应用需求和
应用环境改变时，容易对概念模型进行修改和扩充。概念模型易于向机器世界的各种数据模型转换，如层次模型、网状模型、关系模型等。7.3.
2 概念结构设计的方法自顶向下自底向上逐步扩张混合策略常用策略7.3.3 概念设计的步骤1. 局部E-R图设计选择局部应用逐一设
计局部E-R图2. 全局E-R图设计E-R图合并修改和重构3. 验证整体概念结构1. 局部E-R图设计选择局部应用设计分E-
R图首先需要根据系统的具体情况，在多层的数据流图中选择一个适当层次的数据流图，让这组图中每一部分对应一个局部应用，然后以这一层次的
数据流图为出发点，设计分E-R图。 通常以中层数据流图作为设计分E-R图的依据。逐一设计局部E-R图将各局部应用涉及的数据分别从数
据字典中抽取出来，参照数据流图，标定各局部应用中的实体、实体的属性、标识实体的码，确定实体之间的联系及其类型（1:1，1:n，m:
n）如何抽象实体和属性实体：现实世界中一组具有某些共同特性和行为的对象就可以抽象为一个实体。对象和实体之间是“is member
of”的关系。例：在学校环境中，可把张三、李四等对象抽象为学生实体。属性：对象类型的组成成分可以抽象为实体的属性。组成成分与对象类
型之间是“is part of”的关系。例：学号、姓名、专业、年级等可以抽象为学生实体的属性。其中学号为标识学生实体的码。如何区分
实体和属性实体与属性是相对而言的。同一事物，在一种应用环境中作为“属性”，在另一种应用环境中就必须作为“实体”。一般准则为了简化E
-R图，现实世界中的事物凡能够作为属性对待的，应尽量作为属性。符合下述两条特性的事物一般作为属性对待。准则一：属性不能再具有需要描
述的性质。即属性必须是不可分的数据项，不能再由另一些属性组成。准则二：属性不能与其他实体具有联系。联系只发生在实体之间。举例如何划
分实体和联系当描述发生在实体之间的行为时，最好用联系 怎样划分联系的属性 一是只有在联系产生时才具有的属性应作为联系的属性二是和联
系中的所有实体都有关的属性 2.全局E-R图设计视图集成的两种方式一次集成一次集成多个分E-R图通常用于局部视图比较简单时逐步累积
式首先集成两个局部E-R图（通常是比较关键的两个局部视图）以后每次将一个新的局部E-R图集成进来集成局部E-R图的步骤(1) E-
R图合并冲突的种类命名冲突属性冲突结构冲突命名冲突同名异义：不同意义的对象在不同的局部应用中具有相同的名字例，局部应用A中将教室称
为房间；局部应用B中将学生宿舍称为房间异名同义：同一意义的对象在不同的局部应用中具有不同的名字例，有的部门把教科书称为课本；有的部
门则把教科书称为教材命名冲突可能发生在属性级、实体级、联系级上。其中属性的命名冲突更为常见。属性冲突属性域冲突：属性值的类型、取值
范围或取值集合不同。例1， 某些部门（即局部应用）将教师编号定义为整数形式，另一些部门（即局部应用）则定义为字符型形式。例2， 某
些部门（即局部应用）以出生日期形式表示学生的年龄，而另一些部门（即局部应用）用整数形式表示学生的年龄。属性取值单位冲突。例：如零件
的重量，有的以公斤为单位，有的以斤为单位，有的以克为单位。 命名冲突和属性冲突的解决方法通常用讨论、协商等行政手段加以解决。满足整
体需求基础上的方便原则结构冲突同一对象在不同应用中具有不同的抽象例，“课程”在某一局部应用中被当作实体；在另一局部应用中则被当作属
性解决方法：通常是把属性变换为实体或把实体变换为属性，使同一对象具有相同的抽象。变换时要遵循两个准则。同一实体在不同局部E-R图中
所包含的属性不完全相同，或者属性的排列次序不完全相同。产生原因：不同的局部应用关心的是该实体的不同侧面。解决方法：使该实体的属性取
各分E-R图中属性的并集，再适当设计属性的次序。另一种情况是实体间的联系在不同的局部E-R图中为不同的类型，如实体E1与E2在一个
局部E-R图中是多对多联系，在另一个局部E-R图中是一对多联系。解决方法：根据语义对实体和联系的类型进行综合或调整。 【例7.2
】 【例7.3】 局部E-R图(一) 【例7.3】 局部E-R图(二) 【例7.3】 合并后的E-R图
(2) 修改和重构生成基本E-R图 在初步E－R图中，可能存在一些冗余的数据和实体间冗余的联系。 修改和重构消除不必要的冗余，生成
基本E-R图 冗余的数据是指可由基本数据导出的数据， 冗余的联系是指可由其他联系导出的联系。 冗余数据和冗余联系容易破坏数据库的完
整性，给数据库维护增加困难并不是所有的冗余数据与冗余联系都必须加以消除，有时为了提高某些应用的效率，不得不以冗余信息作为代价。 消
除冗余消除冗余的方法以数据字典和数据流图为依据，根据数据字典中关于数据项之间逻辑关系的说明来消除冗余。如果是为了提高效率，人为地保
留了一些冗余数据，则应把数据字典中数据关联的说明作为完整性约束条件。 3. 验证整体概念结构整体概念结构内部必须具有一致性，不存在
互相矛盾的表达。整体概念结构能准确地反映原来的每个E-R图结构，包括属性、实体及实体间的联系。整体概念结构能满足需求分析阶段所确定
的所有要求。7．4 逻辑结构设计逻辑设计分为如下几步 (1) 将概念模型向一般关系模型转化；(2) 将得到的一般关系模型向特
定的DBMS产品所支持的数据模型转化；(3) 依据应用的需求和具体的DBMS的特征进行调整和完善。7.4.1 E-R图向关系模型的
转换E-R图由实体、实体的属性和实体之间的联系三个要素组成关系模型的逻辑结构是一组关系模式的集合将E-R图转换为关系模型：将实体、
实体的属性和实体之间的联系转化为关系模式。关系模式的描述：属性集合、码一个实体转换为一个关系模式。实体的属性就是关系的属性，实体的
码就是关系的码实体之间的联系和联系的属性：转换分情况处理具有相同码的关系模式可合并。转换规则(1) 1:1联系的转换方法将1:1联
系转换为一个独立的关系模式：与该联系相连的各实体的码以及联系本身的属性均转换为关系的属性，且每个实体的码均是该关系模式的候选码。将
1:1联系与某一端实体集所对应的关系模式合并，则需要在被合并关系模式中增加属性，其新增的属性为联系本身的属性和与联系相关的另一个实
体的码。【例7.4】 将E-R图转换为关系模型。方案1：联系形成的关系独立存在：车间(车间编号，车间名称，车间位置，车间电话)车间
主任(职工编号，姓名，职称，出生年月)管理(车间编号，职工编号，任职时间) 码：车间编号或职工编号方案2：“管理
”与“车间主任”两关系合并：车间(车间编号，车间名称，车间位置，车间电话)车间主任(职工编号，姓名，职称，出生年月，车间编号，任职
时间) 方案3：“管理”与“车间”两关系合并：车间(车间编号，车间名称，车间位置，车间电话，职工编号，任职时间) 车间主任(职工编
号，姓名，职称，出生年月)(2) 1:n联系的转换方法 一种方法是将联系转换为一个独立的关系模式，其属性由与该联系相连的各实体的码
以及联系本身的属性组成，而该关系模式的码为n端实体集的码；另一种方法是在n端实体所对应的关系模式中增加新属性，新属性由联系对应的1
端实体的码和联系自身的属性构成，新增属性后原关系模式的码不变。【例7.5】将E-R图转换为关系模型。【例7.5】将E-R图转换为关
系模型。方案1：联系形成的关系独立存在： 车间(车间编号，车间名称，车间位置，车间电话) 车间成员(职工编号，姓名，职称，出生年月
) 属于(车间编号，职工编号，岗位)方案2：联系形成的关系与n端对象合并。车间(车间编号，车间名称，车间位置，车间电话)车间成员(
职工编号，姓名，职称，出生年月，车间编号，岗位)(3) m:n联系的转换方法在向关系模型转换时，一个m:n联系转换为一个关系模式。
转换方法为：与该联系相连的各实体的码以及联系本身的属性均转换为关系模式的属性，改关系模式的码为两个相连实体码的组合（该码为多属性构
成的组合码）。 【例7.6】将E-R图转换为关系模型。【例7.6】将E-R图转换为关系模型。学生(学号，姓名，年龄，性别)课程(课
程号，课程名，学分，先修课号)，选修(学号，课程号，成绩) 对于多元联系，转换为关系模型的方法是新建一个独立的关系，该关系的属性为
多元联系相连的各实体的码以及联系本身的属性，码为各实体码的组合。 (4) 三个或三个以上实体间的多元联系的转换【例7.7】将E-R
图转换为关系模型【例7.6】将E-R图转换为关系模型零件(零件号，名称，规格，单价) 供应商(供应商号，姓名，地址，账号) 项目(
项目号，预算，开工日期) 供应(供应商号，项目号，零件号，供应量)7.4.2 逻辑模式的优化数据库逻辑设计的结果不是唯一的。得到
初步数据模型后，还应该适当地修改、调整数据模型的结构，以进一步提高数据库应用系统的性能，这就是数据模型的优化。关系数据模型的优化通
常以规范化理论为指导。优化数据模型的方法（1）确定数据依赖按需求分析阶段所得到的语义，分别写出每个关系模式内部各属性之间的数据依赖
以及不同关系模式属性之间数据依赖。（2） 对于各个关系模式之间的数据依赖进行极小化处理，消除冗余的联系。 优化数据模型的方法（3
）按照数据依赖的理论对关系模式逐一进行分析，考查是否存在部分函数依赖、传递函数依赖、多值依赖等，确定各关系模式分别属于第几范式。并
不是规范化程度越高的关系就越优（4）按照需求分析阶段得到的数据处理要求，分析对于这样的应用环境这些模式是否合适，确定是否要对它们进
行合并或分解。（5）对关系模式进行必要的分解或合并，以提高数据操作的效率和存储空间的利用率常用分解方法水平分解垂直分解优化数据模型
的方法水平分解什么是水平分解把(基本)关系的元组分为若干子集合，定义每个子集合为一个子关系，以提高系统的效率。水平分解的适用范围满
足“80/20原则”的应用并发事务经常存取不相交的数据垂直分解什么是垂直分解把关系模式R的属性分解为若干子集合，形成若干子关系模式
。垂直分解的原则经常在一起使用的属性从R中分解出来形成一个子关系模式。垂直分解的优缺点可以提高某些事务的效率可能使另一些事务不得不
执行连接操作，从而降低了效率。说明仅仅在结构上达到3NF (BCNF) 是不够的。“一事一地”包括每项信息的唯一，要提取出问题的
本质，识别出本质上同一概念的信息项。对于表达类似信息，模式相似只是取值不同的表，应尽量合并。如学习经历、进修经历；奖励信息、惩处
信息等。考虑到效率、用途等因素，该分开的表还应分开。如本科生基本信息和研究生基本信息。结合DBMS内部实现技术，合理设计索引和文件
结构，为查询优化准备好存取路径。在结构规范化、减少数据冗余和提高数据库访问性能 之间仔细权衡，适当折中。7.4.3 设计用户子模
式定义数据库模式主要是从系统的时间效率、空间效率、易维护等角度出发。定义用户外模式时应该更注重考虑用户的习惯与方便。 (1) 使
用更符合用户习惯的别名合并各分E-R图曾做了消除命名冲突的工作，以使数据库系统中同一关系和属性具有唯一的名字。这在设计数据库整体结
构时是非常必要的。但对于某些局部应用，由于改用了不符合用户习惯的属性名，可能会使他们感到不方便。因此在设计用户的子模式时可以重新定
义某些属性名，使其与用户习惯一致。当然，为了应用的规范化，我们也不应该一味地迁就用户。(2) 安全性的要求针对不同级别的用户定义不
同的外模式，以满足系统对安全性的要求。例：有关系模式：产品(产品号，产品名，规格，单价，生产车间，生产负责人，产品成本，产品合格率
，质量等级)。可以在产品关系上建立两个视图：为一般顾客建立视图：产品1(产品号，产品名，规格，单价)为产品销售部门建立视图：产品2
(产品号，产品名，规格，单价，车间，生产负责人)(3) 简化用户对系统的使用如果某些局部应用中经常要使用某些很复杂的查询，为了方便
用户，可以将这些复杂查询定义为视图。7.5 数据库的物理设计数据库在物理设备上的存储结构与存取方法称为数据库的物理结构，它依
赖于给定的计算机系统。为一个给定的逻辑数据模型选取一个最适合应用环境的物理结构的过程，就是数据库的物理设计。数据库物理设计的步骤确
定数据库的物理结构 （存取方法、存储结构）对物理结构进行评价，评价的重点是时间和空间效
率7.5.1 数据库物理设计的内容和方法设计物理数据库结构的准备工作 1. 充分了解应用环境，详细分析要运行的事务，以获得选择物理
数据库设计所需参数 2. 充分了解所用RDBMS的内部特征，特别是系统提供的存取方法和存储结构分析要运行的事务数据库查询事务查询的
关系查询条件所涉及的属性连接条件所涉及的属性查询的投影属性数据更新事务被更新的关系每个关系上的更新操作条件所涉及的属性修改操作要改
变的属性值每个事务在各关系上运行的频率和性能要求 关系数据库物理设计的内容为关系模式选择存取方法。设计关系、索引等数据库文件的物理
存储结构。数据库系统是多用户共享的系统，对同一个关系要建立多条存取路径才能满足多用户的多种应用要求。物理设计的任务之一就是要确定选
择哪些存取方法，即建立哪些存取路径。7.5.2 确定数据库的物理结构DBMS常用存取方法索引方法目前主要是B+树索引方法聚簇（C
luster）方法为了提高某个属性（或属性组）的查询速度，把这个或这些属性（称为聚簇码）上具有相同值的元组集中存放在连续的物理块称
为聚簇HASH方法该关系的属性主要出现在等值连接条件中或主要出现在相等比较选择条件中；该关系的大小可预知，而且不变； 或该关系的大
小动态改变，但所选用的DBMS提供了动态HASH存取方法。7.5.2 确定数据库的物理结构确定数据的存放位置和存储结构关系、索引
、聚簇、日志、备份确定系统配置(1) 确定数据的存放位置影响数据存放位置和存储结构的因素硬件环境应用需求存取时间存储空间利用率维护
代价基本原则分开存放，以提高系统性能：易变部分与稳定部分存取频率较高部分与存取频率较低部分（2) 确定系统配置调整存储分配参数 同
时使用数据库的用户数 同时打开的数据库对象数 使用的缓冲区长度、个数 内存分配 物理块的大小……7.5.3 评价物理结构 存储空
间 存取时间 维护代价7.6 数据库的实施和维护用DBMS提供的数据定义语言和其他应用程序将数据库逻辑设计和物理设计结果严格地
描述出来，使之成为DBMS可以接受的源代码，再经过调试产生出数据库模式。 数据库结构建立好后，就可以向数据库中装载数据了。组织数据
入库是数据库实施阶段最主要的工作。7.6.1 建立数据库和应用程序调试建立数据库是在指定的计算机平台上和特定的DBMS下，建立数据
库和组成数据库的各种对象。数据库模式的建立数据的载入 编制与调试应用程序数据库应用程序的设计应该与数据设计并行进行。在数据库实施阶
段，当数据库结构建立好后，就可以开始编制与调试数据库的应用程序。调试应用程序时由于数据入库尚未完成，可先使用模拟数据。7.6.2
数据库的试运行应用程序调试完成，并且已有一小部分数据入库后，就可以开始数据库的试运行。1）功能测试：实际运行应用程序，执行对数据
库的各种操作，测试应用程序的各种功能。2）性能测试：测量系统的性能指标，分析是否符合设计目标。数据的分期入库重新设计物理结构甚至逻
辑结构，会导致数据重新入库。由于数据入库工作量很大，所以可以采用分期输入数据的方法先输入小批量数据供先期联合调试使用待试运行基本合
格后再输入大批量数据逐步增加数据量，逐步完成运行评价数据库的转储和恢复在数据库试运行阶段，系统还不稳定，硬、软件故障随时都可能发生
系统的操作人员对新系统还不熟悉，误操作也不可避免因此必须做好数据库的转储和恢复工作，尽量减少对数据库的破坏。7.6.3 数据库运
行与维护数据库试运行结果符合设计目标后，数据库就可以真正投入运行了。对数据库设计进行评价、调整、修改等维护工作是一个长期的任务，也
是设计工作的继续和提高。应用环境在不断变化数据库运行过程中物理存储会不断变化维护工作包括⒈数据库的转储和恢复转储和恢复是系统正式运
行后最重要的维护工作之一。DBA要针对不同的应用要求制定不同的转储计划，定期对数据库和日志文件进行备份。一旦发生故障，即利用数据库
备份及日志文件备份，尽快将数据库恢复到某种一致性状态。⒉数据库的安全性、完整性控制在数据库运行过程中，由于应用环境的变化，对安全性
的要求也会发生变化，DBA需要根据实际情况修改原有的安全性控制。由于应用环境的变化，数据库的完整性约束条件也会变化，也需要DBA不
断修正，以满足用户要求。⒊数据库性能的监督、分析和改进在数据库运行过程中， DBA必须监督系统运行，对监测数据进行分析，找出改进系
统性能的方法。⒋数据库的重组织和重构造数据库的重组织不会改变原设计的数据逻辑结构和物理结构数据库重构造则根据新环境部分修改数据库的
模式和内模式重构造数据库的程度是有限的7.7 数据库设计实例7.7.1 需求分析1．需求概述(1) 商店经营的商品分为三类
：球类：足球、篮球、排球、网球、乒乓球、羽毛球等球拍类：羽毛球拍、网球拍、乒乓球拍等器材类：哑铃、跳绳、滑板等(2) 客户可以浏览
商品信息、查找商品。先将商品放入购物车，并自动计算总金额。确定购物后生成订单，确定支付后提交订单，系统生成订单号返回给客户。7.7
.1 需求分析(3)客户可以撤销提交后未审核的订单，但订单内容不能更改。每个客户可以使用多个送货地址，送货地址长期保存，由客户提
交订单时选择添加。每个订单只能使用一个送货地址。(4) 客户收到商品后，不满意的商品可以在7日内填写退货单申请退货，系统生成退货单
号返回给客户。销售员收到退货后，将商品退回到库存，并退款。客户对于收到的商品可以在网上进行评价。(5) 销售员负责维护客户的基本信
息，审核客户提交的订单，完成商品出库和配送的工作；审核客户提交的退货单和退货处理。7.7.1 需求分析(6) 供应商按品牌供应商
品，每个品牌的商品只有一个供应商。供货员负责维护和更新系统中的商品信息和供应商信息，完成进货和入库的操作。(7) 销售经理查看统计
数据，包括月销售统计、年销售统计、单品的累积销售数量、单品的销售情况月分布曲线、品牌销售情况的月分布曲线等，查看商品的客户评价，查
看商品的库存情况。(8) 仓库审核员要对所有出库单和入库单进行审核，并负责打印库存报表。(9) 系统管理员负责维护员工的基本信息和
操作权限。2．功能划分3．需求描述需要说明的是，需求分析的过程是一个与用户反复交流、沟通、不断修改和迭代的过程。(1) 确定系统的
参与者。与系统用户进行了充分的交流，确定目标系统的参与者有：客户、销售员、供货员、销售经理、系统管理员。(2) 提取用例提取用例，
确定系统的边界，为每个参与者确定其所有的用例。用例的内容是与用户反复讨论、逐步修改而成的。最终得出系统的用例图和边界。为每个参与者
列出他所涉及的所有用例。(3) 用例描述表用例活动图7.7.2 概念结构设计1．局部E-R图设计选择子系统为局部应用，分别设计局
部E-R图。对每一个用例描述表和用例活动图进行详细的分析，对需求分析阶段收集到的数据进行抽象，标定出实体，确定实体的属性、码以及实
体之间的联系。（1）客户订购子系统标定出以下实体：商品、客户、订单、订单细节、送货地址、退货单。各实体的属性如下：商品（商品编号，
商品名称，商品照片，规格，型号，品牌，生产厂商，产地，商品售价，库存量）客户（客户编号，客户名称，客户所在城市，客户电话）订单（订
单编号，订单状态，支付状态，支付方式，送货方式，订单总金额），订单状态包括：已提交、已审核、未通过审核、已发货、已收货、已完成。客
户提交订单后，系统生成订单号返回给客户。定单编号的编码规则为：D+4位年+2位月+2位日+2位小时+2位分钟+3位流水号，例如：D
201509121712001。购物车（购物车编号）订单明细（订单明细编号，商品编号，数量）送货地址（地址编号，地址，邮编，联系电
话，联系人）退货单（退货单编号，退货单状态，商品编号，数量）（2）订单处理子系统标定出以下实体：销售员、仓库审核员、商品、订单、订
单细节、退货单。各实体的属性如下：销售员（职员编号，姓名，性别，出生年月，文化程度，联系电话，电子邮箱）仓库审核员（职员编号，姓名
，性别，出生年月，文化程度，联系电话，电子邮箱）商品（商品编号，商品名称，商品照片，规格，型号，品牌，产地，商品售价，库存量）订单
（订单编号，送货地址，订单总金额）订单明细（订单明细编号，商品编号，数量）退货单（退货单编号，退货单状态，商品编号，数量）（3）库
存管理子系统标定出以下实体：供应商、品牌、商品、类别、供货员、仓库审核员。各实体的属性如下：供应商（供应商编号，供应商名称，地址，
传真，联系电话，联系人，电子邮箱，账号，开户行）品牌（品牌编号，品牌名称，商标LOGO，所属公司，公司地址）商品（商品编号，商品名
称，商品照片，规格，型号，产地，商品售价，商品简介，库存量）类别（类别编号，类别名称，说明）供货员（职员编号，姓名，性别，出生年月
，文化程度，联系电话，电子邮箱）仓库审核员（职员编号，姓名，性别，出生年月，文化程度，联系电话，电子邮箱）2．全局E-R设计各子系
统的局部E-R图设计好以后，将所有的局部E-R图综合成一个系统的总E-R图。E-R图合并时需要修改和重构。(1) 在两个局部E-R
图中都有“收货”联系，存在同名异义的冲突。将其分别改为“订购收货”和“退货收货”(2) 存在多个“属于”联系，均为同名异义，将商品
实体与品牌实体的联系改为“标牌”，将客户实体与送货地址实体的联系改为“填写”。(3) 在客户订购子系统和订单处理子系统中，“品牌”
为商品实体的一个属性，但在库存管理子系统中，“品牌”为实体，存在结构冲突。合并时统一处理成实体。(4) 订单总金额虽然是一个冗余的
属性，但处于查询效率和处理方便的考虑，保留此属性。(5) 调整、合并各实体和联系的属性。全局E-R图7.7.3 逻辑结构设计商品
（商品编号，商品名称，商品照片，规格，型号，品牌编号，类别编号，生产厂商，产地，商品售价，库存量）品牌（品牌编号，品牌名称，商标L
OGO，所属公司，公司地址，供应商编号）客户（客户编号，客户名称，客户所在城市，客户电话）订单（订单编号，订单状态，支付状态，支付
方式，送货方式，订单总金额，提交时间，客户编号，地址编号，支付时间，销售员编号，审核时间，收货时间，）购物车（购物车编号，客户编号
，商品编号，数量）订单明细（订单明细编号，商品编号，订单编号，数量，运单号）送货地址（地址编号，客户编号，地址，邮编，联系电话，联
系人）评价（客户编号，商品编号，评价等级，评价内容，评价时间）退货单（退货单编号，退货单状态，商品编号，数量，退货时间，退货原因，
运单号，销售员编号，审核时间，退货收货时间，退款时间，入库时间，仓库审核员编号，审核时间）7.7.3 逻辑结构设计销售员（职员编
号，姓名，性别，出生年月，文化程度，联系电话，电子邮箱）仓库审核员（职员编号，姓名，性别，出生年月，文化程度，联系电话，电子邮箱）
供应商（供应商编号，供应商名称，地址，传真，联系电话，联系人，电子邮箱，账号，开户行）类别（类别编号，类别名称，说明）供货员（职员
编号，姓名，性别，出生年月，文化程度，联系电话，电子邮箱）仓库审核员（职员编号，姓名，性别，出生年月，文化程度，联系电话，电子邮箱
）入库（入库单号，供货员编号，商品编号，入库时间，数量，供货价格，仓库审核员编号，审核时间）报损（报损单号，供货员编号，商品编号，
数量，报损时间，报损原因，处理方式，入库单号，仓库审核员编号，审核时间），主码：供货员编号，商品编号，仓库审核员编号销售出库（订单
明细编号，出库单号，商品编号，入库单号，出库时间，销售员编号，仓库审核员编号，审核时间）优化和调整（1）为了处理方便，在购物车的订
单明细表中增加商品实际售价属性。选购（购物车编号，客户编号，商品编号，数量，实际售价）订单明细（订单细节编号，商品编号，订单编号，
数量，实际售价）优化和调整（2）销售员、供货员、仓库审核员具有相同的码，将其合并为职员。增加“岗位”属性，以对其区别。考虑到权限和
安全的管理，为使用系统的用户账号增加“登录密码”属性。职员（职员编号，姓名，性别，出生年月，文化程度，联系电话，电子邮箱，岗位，登
录密码）客户（客户编号，客户名称，客户所在城市，客户电话，登录密码）（3）为了处理方便，将报损的主码调整为报损单号，销售出库的主码
调整为出库单号。7.7.4 数据库的物理设计和实施系统采用关系型数据库管理系统SQL Server在物理设计和实施过程中的主要工
作有设置合理的数据库参数为每个数据列选择合适的数据类型设置合理的索引使用SQL语句建立数据库结构和加载数据应用程序的调试和试运行。
SaleProduct数据库的参数建立数据库SaleProductCREATE DATABASE SaleProduct4
ON PRIMARY ( NAME =''SaleProduct'', FILENAME = ''D:\Sal
eDATA\SaleProductDB4.mdf'' , SIZE = 5120KB , MAXSIZE = UNLIMITED, FILEGROWTH = 10%) LOG ON ( NAME = ''SaleProduct_log'', FILENAME = ''D:\SaleDATA\SaleProduct_log '' , SIZE = 1024KB , MAXSIZE = UNLIMITED , FILEGROWTH = 2048KB )为每个数据表的属性列选择合适的数据类型、设置合理的索引。CREATE TABLE Product( pdID varchar(5) PRIMARY KEY, pdName varchar(20) NOT NULL, pdPhoto varchar(30), pdSpec varchar(10), pdModel varchar(10), brandID varchar(8) FOREIGN KEY REFERENCES Brand(brandID) ON DELETE cascade ON UPDATE cascade, categoryID varchar(2) FOREIGN KEY REFERENCES Category(categoryID) ON DELETE cascade ON UPDATE cascade, pdSupplier varchar(20) NOT NULL, pdLocality varchar(10), pdPrice numeric(10, 2) DEFAULT 0, pdStockSize int DEFAULT 0, CHECK (pdPrice>=0), CHECK (pdStockSize>=0), CHECK (pdStockSize>=0),)物理设计完成后，需要对其存储空间、存取时间和维护代价进行评价。之后在指定的计算机平台上和特定的数据库管理系统下建立数据库和组成数据库的各种对象装入实际的数据，并在组织数据入库的同时调试应用程序、测试系统的性能指标。7.7 小结数据库的设计过程需求分析概念结构设计逻辑结构设计物理设计实施运行维护设计过程中往往还会有许多反复。整个数据库设计过程体现了结构特征与行为特征的紧密结合。 |
|
