数据库系统概论第七章数据库设计

需求分析阶段：综合各个用户的应用需求
概念结构设计阶段：形成独立于机器特点、独立于各个关系数据库管理系统产品的概念模式，这里指 E-R 图
逻辑结构设计阶段：将 E-R 图转换成具体的数据库产品支持的数据模型，如关系模型，形成数据库逻辑模式；然后根据用户处理的要求、安全性的考虑，在基本表的基础上再建立必要的视图，形成数据的外模式
物理结构设计阶段：根据关系数据库管理系统的特点和处理的需要进行物理存储安排，建立索引，形成数据库内模式

7.2 需求分析

需求分析简单地说就是分析用户的要求。

需求分析是设计数据库的起点，需求分析结果是否准确反映用户的实际要求，将直接影响到后面各阶段的设计，并影响到设计结果是否合理和实用。

7.2.1 需求分析的任务

需求分析的任务：详细调查现实世界要处理的对象（组织、部门、企业等），充分了解原系统（手工系统或计算机系统）的工作概况，明确用户的各种需求，然后在此基础上确定新系统的功能。新系统必须充分考虑今后可能的扩充和改变。

调查的重点是“数据”和“处理”，通过调查、收集与分析，获得用户对数据库的如下要求：

（1）信息要求。指用户需要从数据库中获得信息的内容与性质。由信息要求可以导出数据要求，即在数据库中需要存储哪些数据。

（2）处理要求。指用户要完成的数据处理功能，对处理性能的要求。

（3）安全性与完整性要求。

确定用户最终需求的难点

用户缺少计算机知识，不能准确地表达自己的需求，所提出的需求往往不断地变化
设计人员缺少用户的专业知识，不易理解用户的真正需求，甚至误解用户的需求

解决方法：设计人员必须不断深入地与用户进行交流，才能逐步确定用户的实际需求

7.2.2 需求分析的方法

需求分析的目标：调查清楚用户的实际要求并进行初步分析，与用户达成共识，分析与表达这些需求。

调查用户需求的具体步骤：

（1）调查组织机构情况。包括了解该组织的部门组成情况、各部门的职责等，为分析信息流程做准备。

（2）调查各部门的业务活动情况。包括了解各部门输入和使用什么数据，如何加工处理这些数据，输出什么信息，输出到什么部门，输出结果的格式是什么等，这是调查的重点。

（3）在熟悉业务活动的基础上，协助用户明确对新系统的各种要求，包括信息要求、处理要求、完全性与完整性要求。这是调查的又一个重点。

（4）确定新系统的边界。对前面调查的结果进行初步分析，确定哪些功能由计算机完成或将来准备让计算机完成，哪些活动由人工完成。由计算机完成的功能就是新系统应该实现的功能。

常用的调查方法：

（1）跟班作业。通过亲身参加业务工作来了解业务活动的情况。

（2）开调查会。通过与用户座谈来了解业务活动情况及用户需求。

（3）请专人介绍。

（4）询问。对某些调查中的问题可以找专人询问。

（5）设计调查表请用户填写。如果调查表设计得合理，则很有效。

（6）查阅记录。查阅与原系统有关的数据记录。

调查了解用户需求后，还需要进一步分析和表达用户需求。

结构化分析方法（Structured Analysis，SA）：从最上层的系统组织机构入手，采用自顶向下、逐层分解的方式分析系统。

对用户需求进行分析与表达后，需求分析报告必须提交给用户，征得用户的认可。下图描述了需求分析的过程。

需求分析过程

7.2.3 数据字典

数据字典是进行详细的数据收集和数据分析所获得的主要成果。
数据字典是关于数据库中数据的描述，即元数据，而不是数据本身。
数据字典是在需求分析阶段建立，在数据库设计过程中不断修改、充实、完善的。

数据字典包括数据项、数据结构、数据流、数据存储和处理过程。

数据项是数据的最小组成单位。
若干个数据项可以组成一个数据结构。
数据字典通过对数据项和数据结构的定义来描述数据流、数据存储的逻辑内容。

1. 数据项

数据项是不可再分的数据单位。

对数据项的描述通常包括以下内容：

数据项描述={数据项名，数据项含义说明，别名，数据类型，长度，取值范围，取值含义，与其他数据项的逻辑关系，数据项之间的联系}

“取值范围”、“与其他数据项的逻辑关系”定义了数据的完整性约束条件，是设计数据检验功能的依据。
可以用关系规范化理论为指导，用数据依赖的概念分析和表示数据项之间的联系。

2. 数据结构

数据结构反映了数据之间的组合关系。

一个数据结构可以由若干个数据项组成，也可以由若干个数据结构组成，或由若干个数据项和数据结构混合组成。

对数据结构的描述通常包括以下内容：

数据结构描述={数据结构名，含义说明，组成：{数据项或数据结构}}

3. 数据流

数据流是数据结构在系统内传输的路径。

对数据流的描述通常包括以下内容：

数据流描述={数据流名，说明，数据流来源，数据流去向，组成：{数据结构}，平均流量，高峰期流量}

数据流来源：说明该数据流来自哪个过程
数据流去向：说明该数据流将到哪个过程去
平均流量：在单位时间（每天、每周、每月等）里的传输次数
高峰期流量：在高峰时期的数据流量

4. 数据存储

数据存储是数据结构停留或保存的地方，也是数据流的来源和去向之一。

对数据存储的描述通常包括以下内容：

数据存储描述={数据存储名，说明，编号，输入的数据流，输出的数据流，组成：{数据结构}，数据量，存取频度，存取方式}

存取频度：每小时、每天或每周存取次数及每次存取的数据量等信息
存取方式：批处理/ 联机处理；检索/ 更新；顺序检索/随机检索
输入的数据流：数据来源
输出的数据流：数据去向

5. 处理过程

处理过程的具体处理逻辑一般用判定表或判定树来描述。数据字典中只需要描述处理过程的说明性信息。

处理过程说明性信息的描述通常包括以下内容：

处理过程描述={处理过程名，说明，输入：{数据流}，输出：{数据流}，处理：{简要说明}}

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

功能：该处理过程用来做什么
处理要求：处理频度要求，如单位时间里处理多少事务，多少数据量、响应时间要求等
这些处理要求是后面物理设计的输入及性能评价的标准

把需求收集和分析作为数据库设计的第一阶段是十分重要的。第一阶段收集的基础数据（用数据字典来表达）是下一步进行概念设计的基础。强调两点：

（1）设计人员应充分考虑到可能的扩充和改变，使设计易于更改、系统易于扩充

（2）必须强调用户的参与

7.3 概念结构设计

将需求分析得到的用户需求抽象为信息结构（即概念模型）的过程就是概念结构设计。

7.3.1 概念模型

概念模型的主要特点：

（1）能真实、充分地反映现实世界，包括事物和事物之间的联系，是现实世界的一个真实模型

（2）易于理解，可以用它和不熟悉计算机的用户交换意见。

（3）易于更改，当应用环境和应用要求改变时容易对概念模型修改和扩充。

（4）易于向关系、网状、层次等各种数据模型转换。

7.3.2 E-R 模型

描述概念模型的工具：E-R 模型

1. 实体之间的联系

（1）两个实体型之间的联系

① 一对一联系（1:1）

如果对于实体集 A 中的每一个实体，实体集 B 中至多有一个（也可以没有）实体与之联系，反之亦然，则称实体集 A 与实体集 B 具有一对一联系，记为 1:1。

例如，学校里一个班级只有一个正班长，而一个班长只在一个班中任职，则班级与班长之间具有一对一联系。

② 一对多联系（1:n）

如果对于实体集 A 中的每一个实体，实体集 B 中有 n 个实体（𝑛⩾0 ）与之联系，反之，对于实体集 B 中的每一个实体，实体集 A 中至多只有一个实体与之联系，则称实体集 A 与实体集 B 有一对多联系，记为 1:n。

例如，一个班级中有若干名学生，而每个学生只在一个班级中学习，则班级与学生之间具有一对多联系。

③ 多对多联系（m:n）

如果对于实体集 A 中的每一个实体，实体集 B 中有 n 个实体（𝑛⩾0 ）与之联系，反之，对于实体集 B 中的每一个实体，实体集 A 中也有 m 个实体（𝑚⩾0 ）与之联系，则称实体集 A 与实体集 B 具有多对多联系，记为 m:n。

例如，一门课程同时有若干个学生选修，而一个学生可以同时选修多门课程，则课程与学生之间具有多对多联系。

（2）两个以上的实体型之间的联系

一般地，两个以上的实体型之间也存在着一对一、一对多、多对多联系。

例如，对于课程、教师与参考书 3 个实体型，如果一门课程可以有若干个教师讲授，使用若干本参考书，而每一个教师只讲授一门课程，每一本参考书只供一门课程使用，则课程与教师、参考书之间的联系是一对多的，如图(a)所示。

例如，有三个实体型：供应商、项目、零件，一个供应商可以供给多个项目多种零件，而每个项目可以使用多个供应商供应的零件，每种零件可由不同供应商供给，由此看出供应商、项目、零件三者之间是多对多的联系，如图(b)所示。

（3）单个实体型内的联系

同一个实体集内的各实体之间也可以存在一对一、一对多、多对多联系。

例如，职工实体型内部具有领导与被领导的联系，即某一职工（干部）“领导”若干名职工，而一个职工仅被另外一个职工直接领导，因此这是一对多的联系。

联系的度：参与联系的实体型的数目

两个实体型之间的联系度为 2，也称为二元联系；三个实体型之间的联系度为 3，称为三元联系；N个实体型之间的联系度为 N，也称为 N 元联系。

2. E-R 图

E-R 图提供了表示实体型、属性和联系的方法。

（1）实体型：用矩形表示，矩形框内写明实体名。

（2）属性：用椭圆形表示，并用无向边将其与相应的实体型连接起来。

（3）联系：用菱形表示，菱形框内写明联系名，并用无向边分别与有关实体型连接起来，同时在无向边旁标上联系的类型（1:1、1:n 或 m:n）。

如果一个联系具有属性，则这些属性也要用无向边与该联系连接起来。

3. 一个实例

某个工厂物资管理的概念模型。物资管理涉及的实体有：

仓库：属性有仓库号、面积、电话号码
零件：属性有零件号、名称、规格、单价、描述
供应商：属性有供应商号、姓名、地址、电话号码、账号
项目：属性有项目号、预算、开工日期
职工：属性有职工号、姓名、年龄、职称

这些实体之间的联系如下：

（1）一个仓库可以存放多种零件，一种零件可以存放在多个仓库中，因此仓库和零件具有多对多的联系。用库存量来表示某种零件在某个仓库中的数量。

（2）一个仓库有多个职工当仓库保管员，一个职工只能在一个仓库工作，因此仓库和职工之间是一对多的联系。

（3）职工之间具有领导与被领导关系，即仓库主任领导若干保管员，因此职工实体型中具有一对多的联系。

（4）供应商、项目和零件三者之间具有多对多的联系，即一个供应商可以供给若干项目多种零件，每个项目可以使用不同供应商供应的零件，每种零件可由不同供应商供给。

工厂物资管理 E-R 图

7.3.3 概念结构设计

1. 实体与属性的划分原则

为了简化 E-R 图的处置，现实世界的事物能作为属性对待的，尽量作为属性对待。

两条准则：

（1）作为属性，不能再具有需要描述的性质，即属性必须是不可分的数据项，不能包含其他属性。

（2）属性不能与其他实体具有联系，即 E-R 图中所表示的联系是实体之间的联系。

【例 7.1】销售管理子系统E-R图的设计。

该子系统的主要功能是：

处理顾客和销售员送来的订单
工厂是根据订货安排生产的
交出货物同时开出发票
收到顾客付款后，根据发票存根和信贷情况进行应收款处理

参照需求分析和数据字典中的详尽描述，遵循前述的两个准则，进行如下调整：

（1）每张订单由订单号、若干头信息和订单细节组成。订单细节又有订货的零件号、数量等来描述。按照第二条准则，订单细节就不能作为订单的属性处理而应该上升为实体。一张订单可以订若干产品，所以订单与订单细节两个实体之间是 1:n 的联系。

（2）原订单和产品的联系实际上是订单细节和产品的联系。每条订货细节对应一个产品描述，订单处理时从中获得当前单价、产品重量等信息。

（3）工厂对大宗订货给予优惠。每种产品都规定了不同订货数量的折扣，应增加一个“折扣规则”实体存放这些信息，而不应把它们放在产品实体中。

对每个实体定义的属性如下：

顾客：{顾客号，顾客名，地址，电话，信贷状况，账目余额}
订单：{订单号，顾客号，订货项数，订货日期，交货日期，工种号，生产地点}
订单细则：{订单号，细则号，零件号，订货数，金额}
应收账款：{顾客号，订单号，发票号，应收金额，支付日期，支付金额，当前余额，货款限额}
产品：{产品号，产品名，单价，重量}
折扣规则：{产品号，订货量，折扣}、

2. E-R图的集成

E-R 图的集成一般需要分两步：

合并。解决各分 E-R 图之间的冲突，将分 E-R 图合并起来生成初步 E-R 图。
修改和重构。消除不必要的冗余，生成基本 E-R 图

E-R 图集成

（1）合并 E-R 图，生成初步 E-R 图

各个局部应用所面向的问题不同，各个子系统的 E-R 图之间必定会存在许多不一致的地方，称之为冲突。

各子系统的 E-R 图之间的冲突主要有三类：属性冲突、命名冲突和结构冲突。

① 属性冲突

属性域冲突，即属性值的类型、取值范围或取值集合不同。例如零件号，有的部门把它定义为整数，有的部门把它定义为字符型。例如年龄，某些部门以出生日期形式表示职工的年龄，而另一些部门用整数表示职工的年龄。
属性取值单位冲突。例如零件的重量有的以公斤为单位，有的以斤为单位，有的以克为单位。

属性冲突理论上好解决，但实际上需要各部门讨论协商，解决起来并非易事。

② 命名冲突

同名异义，即不同意义的对象在不同的局部应用中具有相同的名字。
异名同义（一义多名），即同一意义的对象在不同的局部应用中具有不同的名字。

如对科研项目，财务科称为项目，科研处称为课题，生产管理处称为工程。

命名冲突可能发生在实体、联系一级上，也可能发生在属性一级上，通过讨论、协商等行政手段加以解决。

③ 结构冲突

主要包含以下三类冲突：

同一对象在不同应用中具有不同的抽象。

例如，职工在某一局部应用中被当作实体，而在另一局部应用中则被当作属性。

解决方法：把属性变换为实体或把实体变换为属性，使同一对象具有相同的抽象。

同一实体在不同子系统的 E-R 图中所包含的属性个数和属性排列次序不完全相同。

解决方法：使该实体的属性取各子系统的 E-R 图中属性的并集，再适当调整属性的次序。

实体间的联系在不同的 E-R 图中为不同的类型。

实体 E1 与 E2 在一个 E-R 图中是多对多联系，在另一个 E-R 图中是一对多联系。

解决方法：根据应用的语义对实体联系的类型进行综合或调整。

（2）消除不必要的冗余，设计基本 E-R 图

在初步 E-R 图中可能存在一些冗余的数据和实体间冗余的联系。
所谓冗余的数据是指可由基本数据导出的数据，冗余的联系是指可由其他联系导出的联系。
消除冗余主要采用分析方法，即以数据字典和数据流图为依据，根据数据字典中关于数据项之间逻辑关系的说明来消除冗余。
并不是所有的冗余数据与冗余联系都必须加以消除，有时为了提高效率，不得不以冗余信息作为代价。

用分析方法消除冗余

如下图，𝑄3=𝑄1×𝑄2 ，𝑄4=∑𝑄5 。所以 𝑄3 和 𝑄4 是冗余数据，可以消去；并且由于 𝑄3 消去，产品与材料间 m:n 的冗余联系也应消去。

消除冗余

用规范化理论来消除冗余

① 确定分 E-R 图实体之间的数据依赖。实体之间一对一、一对多、多对多的联系可以用实体码之间的函数依赖来表示。

如下图：

部门和职工之间一对多的联系可表示为职工号 → 部门号
职工和产品之间多对多的联系可表示为（职工号，产品号） → 工作天数等。

于是有函数依赖集 𝐹𝐿 。

② 求 𝐹𝐿 的最小覆盖 𝐺𝐿 ，差集为 𝐷=𝐹𝐿−𝐺𝐿 。

逐一考察 𝐷 中的函数依赖，确定是否是冗余的联系，若是就把它去掉。

由于规范化理论受到泛关系假设的限制，应注意下面两个问题：

冗余的联系一定在 𝐷 中，而 𝐷 中的联系不一定是冗余的
当实体之间存在多种联系时，要将实体之间的联系在形式上加以区分

集成过程中，解决了以下问题：

异名同义，项目和产品含义相同。某个项目实质上是指某个产品的生产。统一用产品作实体名。
库存管理中，职工与仓库的工作关系已包含在劳动人事管理的部门与职工之间的联系之中，所以可以取消。职工之间领导与被领导关系可由部门与职工（经理）之间的领导关系、部门与职工之间的从属关系两者导出，所以也可以取消。

7.4 逻辑结构设计

逻辑结构设计的任务是把概念结构设计阶段设计好的基本 E-R 图转换为与选用数据库管理系统产品所支持的数据模型相符合的逻辑结构。

7.4.1 E-R 图向关系模型的转换

转换内容

关系模型的逻辑结构是一组关系模式的集合。
E-R 图是由实体型、实体的属性和实体型之间的联系三个要素组成的。
将 E-R 图转换为关系模型，实际上就是要将实体型、实体的属性和实体型之间的联系转化为关系模式。

转换原则

一个实体型转换为一个关系模式，关系的属性就是实体的属性，关系的码就是实体的码。

实体型间的联系有以下不同情况：

（1）一个 1:1 联系可以转换为一个独立的关系模式，也可以与任意一端对应的关系模式合并

① 转换为一个独立的关系模式

关系的属性：与该联系相连的各实体的码以及联系本身的属性
关系的候选码：每个实体的码

② 与某一端实体对应的关系模式合并

合并后关系的属性：加入对应关系的码和联系本身的属性
合并后关系的码：不变

（2）一个 1:n 联系可以转换为一个独立的关系模式，也可以与 n 端对应的关系模式合并

① 转换为一个独立的关系模式

关系的属性：与该联系相连的各实体的码以及联系本身的属性
关系的码：n 端实体的码

② 与 n 端对应的关系模式合并

合并后关系的属性：在 n 端关系中加入 1 端关系的码和联系本身的属性
合并后关系的码：不变

可以减少系统中的关系个数，一般情况下更倾向于采用这种方法

（3）一个 m:n 联系转换为一个关系模式

关系的属性：与该联系相连的各实体的码以及联系本身的属性
关系的码：各实体码的组合

（4）三个或三个以上实体间的一个多元联系转换为一个关系模式

关系的属性：与该多元联系相连的各实体的码以及联系本身的属性
关系的码：各实体码的组合

（5）具有相同码的关系模式可合并

目的：减少系统中的关系个数
合并方法：将其中一个关系模式的全部属性加入到另一个关系模式中，然后去掉其中的同义属性（可能同名也可能不同名），适当调整属性的次序

某工厂管理信息系统的局部 E-R 图

部门（部门号，部门名，经理的职工号，…）
职工（职工号、部门号，职工名，职务，…）
产品（产品号，产品名，产品组长的职工号，…）
供应商（供应商号，姓名，…）
零件（零件号，零件名，…）
参加（职工号，产品号，工作天数，…）
供应（产品号，供应商号，零件号，供应量）

7.4.2 数据模型的优化

数据库逻辑设计的结果不是唯一的。
得到初步数据模型后，还应该适当地修改、调整数据模型的结构，以进一步提高数据库应用系统的性能，这就是数据模型的优化。
关系数据模型的优化通常以规范化理论为指导。

优化数据模型的方法：

（1）确定数据依赖

按需求分析阶段所得到的语义，分别写出每个关系模式内部各属性之间的数据依赖以及不同关系模式属性之间数据依赖。

（2）对于各个关系模式之间的数据依赖进行极小化处理，消除冗余的联系，具体方法见7.3.3“概念结构设计”

（3）按照数据依赖的理论对关系模式逐一进行分析，考察是否存在部分函数依赖、传递函数依赖、多值依赖等，确定各关系模式分别属于第几范式。

（4）根据需求分析阶段得到的处理要求，分析对于这样的应用环境这些模式是否合适，确定是否要对某些模式进行合并或分解。

注意：

并不是规范化程度越高的关系就越优。

当查询经常涉及两个或多个关系模式的属性时，系统经常进行连接运算
连接运算的代价是相当高的（可以说关系模型低效的主要原因就是由连接运算引起的）
因此在这种情况下，第二范式甚至第一范式也许是适合的

非 BCNF 的关系模式虽然从理论上会存在不同程度的更新异常或冗余，但如果在实际应用中对此关系模式只是查询，并不执行更新操作，就不会产生实际影响。

对于一个具体应用来说，到底规范化进行到什么程度，需要权衡响应时间和潜在问题两者的利弊才能决定。

（5）对关系模式进行必要分解，提高数据操作效率和存储空间的利用率。

水平分解：把（基本）关系的元组分为若干子集合，定义每个子集合为一个子关系，以提高系统的效率。

如何分解：根据“80/20原则”，把经常被使用的数据（约20%）水平分解出来，形成一个子关系。
水平分解为若干子关系，使每个事务存取的数据对应一个子关系。

垂直分解：把关系模式 𝑅 的属性分解为若干子集合，形成若干子关系模式

原则：将经常在一起使用的属性从 𝑅 中分解出来形成一个子关系模式
优点：可以提高某些事务的效率
缺点：可能使另一些事务不得不执行连接操作，降低了效率
适用范围：取决于分解后 𝑅 上的所有事务的总效率是否得到了提高

7.4.3 设计用户子模式

定义数据库全局模式主要是从系统的时间效率、空间效率、易维护等角度出发。

定义用户外模式时应该更注重考虑用户的习惯与方便。包括三个方面：

（1）使用更符合用户习惯的别名

合并各分 E-R 图曾做了消除命名冲突的工作，以使数据库系统中同一关系和属性具有唯一的名字。这在设计数据库整体结构时是非常必要的。
用视图机制可以在设计用户视图时重新定义某些属性名，使其与用户习惯一致，以方便使用。

（2）针对不同级别的用户定义不同的视图，以保证系统的安全性。

假设有关系模式产品（产品号，产品名，规格，单价，生产车间，生产负责人，产品成本，产品合格率，质量等级），可以在产品关系上建立两个视图：

为一般顾客建立视图：产品1（产品号，产品名，规格，单价）

为产品销售部门建立视图：产品2（产品号，产品名，规格，单价，车间，生产负责人）

（3）简化用户对系统的使用

如果某些局部应用中经常要使用某些很复杂的查询，为了方便用户，可以将这些复杂查询定义为视图。

7.5 物理结构设计

数据库在物理设备上的存储结构与存取方法称为数据库的物理结构，它依赖于选定的数据库管理系统。

为一个给定的逻辑数据模型选取一个最适合应用要求的物理结构的过程，就是数据库的物理设计。

数据库物理设计的步骤：

（1）确定数据库的物理结构，在关系数据库中主要指存取方法和存储结构

（2）对物理结构进行评价，评价的重点是时间和空间效率

7.5.1 数据库物理设计的内容和方法

首先对要运行的事务进行详细分析，获得选择物理数据库设计所需要的参数；其次，要充分了解所用关系数据库管理系统的内部特征，特别是系统提供的存取方法和存储结构。

选择物理数据库设计所需参数

对于数据库查询事务，需要得到如下信息：

查询的关系
查询条件所涉及的属性
连接条件所涉及的属性
查询的投影属性

对于数据更新事务，需要得到如下信息：

被更新的关系
每个关系上的更新操作条件所涉及的属性
修改操作要改变的属性值

还需要知道每个事务在各关系上运行的频率和性能要求。

关系数据库物理设计的内容主要包括为关系模式选择存取方法（建立存取路径），以及设计关系、索引等数据库文件的物理存储结构。

7.5.2 关系模式存取方法选择

数据库管理系统常用存取方法：B+树索引存取方法（索引方法）、hash 索引存取方法（索引方法）、聚簇存取方法（聚簇方法）

1. B+树索引存取方法的选择

根据应用要求确定对关系的哪些属性列建立索引、哪些属性列建立组合索引、哪些索引要设计为唯一索引

一般规则：

（1）如果一个（或一组）属性经常在查询条件中出现，则考虑在这个（或这组）属性上建立索引（或组合索引）

（2）如果一个属性经常作为最大值和最小值等聚集函数的参数，则考虑在这个属性上建立索引

（3）如果一个（或一组）属性经常在连接操作的连接条件中出现，则考虑在这个（或这组）属性上建立索引

关系上定义的索引数并不是越多越好，系统为维护索引要付出代价，查找索引也要付出代价。例如，若一个关系的更新频率很高，这个关系上定义的索引数不能太多。因为更新一个关系时，必须对这个关系上有关的索引做相应的修改。

2. hash索引存取方法的选择

如果一个关系的属性主要出现在等值连接条件中或主要出现在等值比较选择条件中，而且满足下列两个条件之一，则此关系可以选择 hash 存取方法。

（1）该关系的大小可预知，而且不变

（2）该关系的大小动态改变，但所选用的数据库管理系统提供了动态 hash 存取方法。

3. 聚簇存取方法的选择

聚簇：为了提高某个属性（或属性组）的查询速度，把这个或这些属性上具有相同值的元组集中存放在连续的物理块中。该属性（或属性组）称为聚簇码（cluster key）。

一个数据库可以建立多个聚簇，一个关系只能加入一个聚簇。选择聚簇存取方法，即确定需要建立多少个聚簇，每个聚簇中包括哪些关系。

首先设计候选聚簇，一般来说：

（1）对经常在一起进行连接操作的关系可以建立聚簇。

（2）如果一个关系的一组属性经常出现在相等比较条件中，则该单个关系可建立聚簇。

（3）如果一个关系的一个（或一组）属性上的值重复率很高，则此单个关系可建立聚簇。即对应每个聚簇码值的平均元组数不能太少，太少则聚簇的效果不明显。

然后检查候选聚簇中的关系，取消其中不必要的关系。

（1）从聚菱中删除经常进行全表扫描的关系。

（2）从聚簇中删除更新操作远多于连接操作的关系。

（3）不同的聚簇中可能包含相同的关系，一个关系可以在某一个聚簇中，但不能同时加入多个聚簇。要从这多个聚簇方案（包括不建立聚族）中选择一个较优的，即在这个聚簇上运行各种事务的总代价最小。

适用范围：

不但适用于单个关系，也适用于经常进行连接操作的多个关系。
当通过聚簇码进行访问或连接是该关系的主要应用，与聚簇码无关的其他访问很少或者是次要的，这时可以使用聚簇。尤其当 SQL 语句中包含有与聚簇码有关的 ORDER BY、GROUP BY、UNION、 DISTINCT 等子句或短语时，使用聚簇特别有利，可以省去或减化对结果集的排序操作

必须强调的是，聚簇只能提高某些应用的性能，而且建立与维护聚簇的开销是相当大的。对已有关系建立聚簇，将导致关系中元组的物理存储位置移动，并使此关系上原来建立的所有索引无效，必须重建。当一个元组的聚簇码改变时，该元组的存储位置也要做相应移动。

7.5.3 确定数据库的存储结构

确定数据库物理结构主要指确定数据的存放位置和存储结构，包括确定关系、索引、聚簇、日志、备份等的存储安排和存储结构，确定系统配置等。

确定数据的存放位置和存储结构要综合考虑存取时间、存储空间利用率和维护代价三方面的因素。这三个方面常常是相互矛盾的，因此需要进行权衡，选择一个折中方案。

1. 确定数据的存放位置

为了提高系统性能，应该根据应用情况将数据的易变部分与稳定部分、经常存取部分和存取频率较低部分分开存放。

例如：

可以将比较大的表分别放在两个磁盘上，以加快存取速度，这在多用户环境下特别有效
可以将日志文件与数据库对象（表、索引等）放在不同的磁盘上，以改进系统的性能。

2. 确定系统配置

关系数据库管理系统产品一般都提供了一些系统配置变量和存储分配参数，供设计人员和数据库管理员对数据库进行物理优化。初始情况下，系统都为这些变量赋予了合理的默认值。但是这些值不一定适合每一种应用环境，在进行物理设计时需要重新对这些变量赋值，以改善系统的性能。

7.5.4 评价物理结构

数据库物理设计过程中需要对时间效率、空间效率、维护代价和各种用户要求进行权衡，其结果可以产生多种方案。数据库设计人员必须对这些方案进行细致的评价，从中选择一个较优的方案作为数据库的物理结构。

评价物理数据库的方法完全依赖于所选用的关系数据库管理系统。

7.6 数据库的实施和维护

7.6.1 数据的载入和应用程序的调试

数据库实施阶段包括两项重要的工作：数据的载入、应用程序的编码和调试

数据装载方法：人工方法、计算机辅助数据入库

数据库应用程序的设计应该与数据库设计同步进行，因此在组织数据入库的同时还要调试应用程序。（应用程序的设计、编码和调试的方法、步骤在软件工程等课程中有详细讲解，这里不再赘述。）

7.6.2 数据库的试运行

在原有系统的数据有一小部分已输入数据库后，就可以开始对数据库系统进行联合调试，也称数据库的试运行。

主要工作包括

功能测试：实际运行应用程序，执行对数据库的各种操作，测试应用程序的各种功能。
性能测试：测试系统的性能指标，分析是否达到设计目标。

数据库性能指标的测量

数据库物理设计阶段在评价数据库结构估算时间、空间指标时，作了许多简化和假设，忽略了许多次要因素，因此设计时的考虑在很多方面只是近似估计，和实际系统运行有一定的差距。
数据库试运行则是要实际测量系统的各种性能指标（不仅是时间、空间指标），如果结果不符合设计目标，则需要返回物理设计阶段重新调整物理结构，修改系统参数；有时甚至需要返回逻辑设计阶段，修改逻辑结构。

数据的分期入库

重新设计物理结构甚至逻辑结构，会导致数据重新入库
由于数据入库工作量实在太大，所以可以采用分期分批输入数据的方法：先输入小批量数据供先期联合调试使用，待试运行基本合格后再输入大批量数据，逐步增加数据量，逐步完成运行评价

数据库的转储和恢复

在数据库试运行阶段，系统还不稳定，硬、软件故障随时都可能发生，系统的操作人员对新系统还不熟悉，误操作也不可避免，因此必须做好数据库的转储和恢复工作，尽量减少对数据库的破坏。

7.6.3 数据库的运行和维护

在数据库运行阶段，对数据库经常性的维护工作主要是由数据库管理员完成的，包括：

1. 数据库的转储和恢复

数据库管理员要针对不同的应用要求制定不同的转储计划，定期对数据库和日志文件进行备份。
一旦发生介质故障，即利用数据库备份及日志文件备份，尽快将数据库恢复到某种一致性状态。

2. 数据库的安全性、完整性控制

初始定义

数据库管理员根据用户的实际需要授予不同的操作权限
根据应用环境定义不同的完整性约束条件

修改定义

当应用环境发生变化，对安全性的要求也会发生变化，数据库管理员需要根据实际情况修改原有的安全性控制
由于应用环境发生变化，数据库的完整性约束条件也会变化，也需要数据库管理员不断修正，以满足用户要求

3. 数据库性能的监督、分析和改造

在数据库运行过程中，数据库管理员必须监督系统运行，对监测数据进行分析，找出改进系统性能的方法。

利用监测工具获取系统运行过程中一系列性能参数的值
通过仔细分析这些数据，判断当前系统是否处于最佳运行状态
如果不是，则需要通过调整某些参数来进一步改进数据库性能

4. 数据库的重组织与重构造

数据库的重组织

为什么要重组织数据库：数据库运行一段时间后，由于记录的不断增、删、改，将会使数据库的物理存储情况变坏，降低数据库存储空间的利用率和数据的存取效率，使数据库的性能下降。
重组织的形式：全部重组织、部分重组织（只对频繁增、删的表进行重组织）
数据库管理系统一般都提供数据重组织用的实用程序，帮助数据库管理员重新组织数据库。
在重组织的过程中，按原设计要求重新安排存储位置、回收垃圾、减少指针链。
数据库的重组织不会改变原设计的逻辑结构和物理结构。

数据库的重构造

为什么要进行数据库的重构造：数据库应用环境发生变化，增加了新的应用或新的实体，取消了某些应用，有的实体及实体间的联系也发生了变化，使原有的数据库设计不能满足新的需求。
数据库重构造的主要工作：根据新环境调整数据库的模式和内模式，部分修改数据库的模式和内模式。例如，在表中增加或删除某些数据项，改变数据项的类型，增加或删除某个表，改变数据库的容量，增加或删除某些索引。
重构造数据库的程度是有限的。

若应用变化太大，已无法通过重构数据库来满足新的需求，或重构数据库的代价太大，则表明现有数据库应用系统的生命周期已经结束，应该设计新的数据库应用系统。

7.7 小结

本章主要讨论数据库设计的方法和步骤，列举了较多的实例，详细介绍了数据库设计各个阶段的目标、方法以及应注意的事项，其中重点是概念结构的设计和逻辑结构的设计，这也是数据库设计过程中最重要的两个环节。
概念结构的设计着重介绍了 E-R 模型的基本概念和图示方法。应重点掌握实体型、属性和联系的概念，理解实体型之间的一对一、一对多和多对多联系。掌握 E-R 模型的设计以及把 E-R 模型转换为关系模型的方法。
学习本章要努力掌握书中讨论的基本方法，还要能在实际工作中运用这些思想设计符合应用需求的数据库模式和数据库应用系统。

水花花花花花

关注

46
点赞
踩
23

收藏

觉得还不错? 一键收藏
9
评论
数据库系统概论第七章数据库设计

数据库设计广义：数据库及其应用系统的设计，即设计整个数据库应用系统狭义：设计数据库本身，即设计数据库的各级模式并建立数据库，这是数据库应用系统设计的一部分一般定义：数据库设计是指对于一个给定的应用环境，构造（设计）优化的数据库逻辑模式和物理结构，并据此建立数据库及其应用系统，使之能够有效地存储和管理数据，满足各种用户的应用需求，包括信息管理要求和数据操作要求。信息管理要求：在数据库中应该存储和管理哪些数据对象。数据操作要求：对数据对象需要进行哪些操作，如查询、增、删、改、统计等操作。
复制链接

扫一扫