数据库原理及应用 7

数据库设计

对于一个给定的应用环境，构造（设计）优化的数据库逻辑模式和物理结构，并据此建立数据库及其应用系统，使之能够有效地存储和管理数据，满足各种用户的应用需求，包括信息管理要求和数据操作要求。

• 目标：为用户和各种应用系统提供一个信息基础设施和高效率的运行环境。
• 结构（数据）设计和行为（处理）设计相结合
  将数据库结构设计和数据处理设计密切结合

设计方法

• 手工与经验相结合方法
  设计质量与设计人员的经验和水平有直接关系
  数据库运行一段时间后常常不同程度地发现各种问题，增加了维护代价
• 规范设计法
  基本思想：过程迭代和逐步求精
• 新奥尔良（New Orleans）方法
  将数据库设计分为若干阶段和步骤
• 基于E-R模型的数据库设计方法
  概念设计阶段广泛采用
• 3NF（第三范式）的设计方法
  逻辑阶段可采用的有效方法
• ODL（Object Definition Language）方法
  面向对象的数据库设计方法

7.1 基本步骤

准备工作：选定参加设计的人

1.系统分析人员、数据库设计人员:
自始至终参与数据库设计
2. 用户和数据库管理员
主要参加需求分析和数据库的运行维护
3. 应用开发人员（程序员和操作员）
在系统实施阶段参与进来，负责编制程序和准备软硬件环境

步骤：

1. 需求分析

准确了解与分析用户需求（包括数据与处理）
最困难、最耗费时间的一步

2. 概念结构设计

整个数据库设计的关键
通过对用户需求进行综合、归纳与抽象，形成一个独立于具体DBMS的概念模型

3. 逻辑结构设计

将概念结构转换为某个DBMS所支持的数据模型
对其进行优化

4. 物理结构设计

为逻辑数据模型选取一个最适合应用环境的物理结构（包括存储结构和存取方法）

5. 数据库实施

运用DBMS提供的数据库语言（如SQL）及宿主语言，根据逻辑设计和物理设计的结果

建立数据库
编制与调试应用程序
组织数据入库
进行试运行

6. 数据库运行和维护

数据库应用系统经过试运行后即可投入正式运行
在数据库系统运行过程中必须不断地对其进行评价、调整与修改

注意：
需求分析和概念设计独立于任何数据库管理系统；
逻辑设计和物理设计与选用的DBMS密切相关。

设计一个完善的数据库应用系统往往是上述六个阶段的不断反复。

数据库设计不同阶段形成的数据库各级模式

7.2.1 需求分析

任务

• 详细调查现实世界要处理的对象（组织、部门、企业等）

调查用户需求的具体步骤:
⑴ 调查组织机构情况
⑵ 调查各部门的业务活动情况。
⑶ 在熟悉业务活动的基础上，协助用户明确对新系统的各种要求。
⑷ 确定新系统的边界

• 充分了解原系统（手工系统或计算机系统）
• 明确用户的各种需求

进一步分析和表达用户需求：
结构化分析方法（Structured Analysis，简称SA方法）
从最上层的系统组织机构入手
自顶向下、逐层分解分析系统

1.把任何一个系统都抽象为:

2. 分解处理功能和数据
(1)分解处理功能
将处理功能的具体内容分解为若干子功能
(2)分解数据
处理功能逐步分解同时，逐级分解所用数据，形成若干层次的数据流图
(3)表达方法
处理逻辑：用判定表或判定树来描述
数据：用数据字典来描述

3. 将分析结果再次提交给用户，征得用户的认可

• 确定新系统的功能
• 充分考虑今后可能的扩充和改变

重点

调查的重点是***数据***和***处理***，获得用户对数据库的要求：

信息要求
处理要求
安全性与完整性要求

数据字典

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

• 数据项

不可再分的数据单位。

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

数据结构

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

数据结构描述＝｛数据结构名，含义说明，组成:｛数据项或数据结构｝｝

数据流

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

数据流描述＝｛ 数据流名，说明，数据流来源，数据流去向，组成:｛数据结构｝，平均流量，高峰期流量｝

数据存储

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

数据存储描述＝｛数据存储名，说明，编号，输入的数据流 ，输出的数据流 ，组成:｛数据结构｝，数据量，存取频度，存取方式｝

处理过程

具体处理逻辑一般用判定表或判定树来描述。

处理过程描述＝｛处理过程名，说明，输入:｛数据流｝，输出:｛数据流｝，处理:｛简要说明｝｝

• 需求分析小结

设计人员应充分考虑到可能的扩充和改变，使设计易于更改，系统易于扩充
必须强调用户的参与

7.2.2 概念结构设计

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

描述概念模型的工具：E-R模型
概念结构是各种数据模型的共同基础，它比数据模型更独立于机器、更抽象，从而更加稳定。
概念结构设计是整个数据库设计的关键。

特点

(1) 能真实、充分地反映现实世界
(2) 易于理解
(3) 易于更改
(4) 易于向关系、网状、层次等各种数据模型转换

概念结构设计的方法与步骤

• 设计概念结构的四类方法

• 自顶向下
  首先定义全局概念结构的框架，然后逐步细化。
  

• 自底向上
  首先定义各局部应用的概念结构，然后将它们集成起来，得到全局概念结构。
  

• 逐步扩张
  首先定义最重要的核心概念结构，然后向外扩充，以滚雪球的方式逐步生成其他概念结构，直至总体概念结构。
  

• 混合策略
  将自顶向下和自底向上相结合，用自顶向下策略设计一个全局概念结构的框架，以它为骨架集成由自底向上策略中设计的各局部概念结构。

常用策略

• 自顶向下地进行需求分析

自底向上设计概念结构的步骤：
第1步：抽象数据并设计局部视图
第2步：集成局部视图，得到全局概念结构

• 自底向上地设计概念结构
  

1. 抽象数据并设计局部视图

数据抽象

三种常用抽象

1. 分类（Classification）
   定义某一类概念作为现实世界中一组对象的类型
   抽象了对象值和型之间的“is member of”的语义
2. 聚集（Aggregation）
   定义某一类型的组成成分
   抽象了对象内部类型和成分之间“is part of”的语义
3. 概括（Generalization）
   定义类型之间的一种子集联系
   抽象了类型之间的“is subset of”的语义
   ⚠️继承性

局部视图设计

设计分E-R图的步骤:

⒈选择局部应用

在多层的数据流图中选择一个适当层次的数据流图，作为设计分E-R图的出发点
通常以中层数据流图作为设计分E-R图的依据

⒉逐一设计分E-R图

任务:

1. 将各局部应用涉及的数据分别从数据字典中抽取出来
2. 参照数据流图，标定各局部应用中的实体、实体的属性、标识实体的码
3. 确定实体之间的联系及其类型（1:1，1:n，m:n）

⚠️两条准则：
（1）属性不能再具有需要描述的性质。即属性必须是不可分的数据项，不能再由另一些属性组成；
（2）属性不能与其他实体具有联系。联系只发生在实体之间。

2. 集成局部视图，得到全局概念结构

集成局部E-R图的步骤

1. 合并
2. 修改与重构
   各个局部视图即分E-R图建立好后，还需要对它们进行合并，集成为一个整体的数据概念结构即总E-R图。

• 多个分E-R图一次集成：
  一次集成多个分E-R图，通常用于局部视图比较简单时。
  

• 逐步集成
  用累加的方式一次集成两个分E-R图

• 合并分E-R图的主要工作与关键：
  合理消除各分E-R图的冲突

• 冲突的种类：

1. 属性冲突

• 属性域冲突:
  属性值的类型
  取值范围
  取值集合不同
• 属性取值单位冲突

2. 命名冲突

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

3. 结构冲突

• 同一对象在不同应用中具有不同的抽象
• 同一实体在不同分E-R图中所包含的属性个数和属性排列次序不完全相同
• 实体之间的联系在不同局部视图中呈现不同的类型

基本任务:
消除不必要的冗余，设计生成基本E-R图
1. 冗余的数据：
可由基本数据导出的数据

以数据字典和数据流图为依据。

2. 冗余的实体间联系：
可由其他联系导出的联系 

根据数据字典中关于数据项之间的逻辑关系。

3. 验证整体概念结构

视图集成后形成一个整体的数据库概念结构，对该整体概念结构还必须进行进一步验证，确保它能够满足下列条件：

1. 整体概念结构内部必须具有一致性，不存在互相矛盾的表达；
2. 整体概念结构能准确地反映原来的每个视图结构，包括属性、实体及实体间的联系；
3. 整体概念结构能满足需要分析阶段所确定的所有要求。

整体概念结构最终还应该提交给用户，征求用户和有关人员的意见，进行评审、修改和优化，然后把它确定下来，作为数据库的概念结构，作为进一步设计数据库的依据。

7.2.3 逻辑结构设计

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

逻辑结构设计的步骤

1. 将概念结构转化为一般的关系、网状、层次模型

E-R图向关系模型的转换：
将实体、实体的属性和实体之间的联系转换为关系模式，并确定这些关系模式的属性和码。

实体型间的联系有以下不同情况 ：
(1)一个1:1联系可以转换为一个独立的关系模式，也可以与任意一端对应的关系模式合并。

• 转换为一个独立的关系模式
• 与某一端实体对应的关系模式合并
  (2)一个1:n联系可以转换为一个独立的关系模式，也可以与n端对应的关系模式合并。
• 转换为一个独立的关系模式
• 与n端对应的关系模式合并
  (3) 一个m:n联系转换为一个关系模式。
  (4)三个或三个以上实体间的一个多元联系转换为一个关系模式。
  (5)具有相同码的关系模式可合并

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

⚠️注意：

1. 从理论上讲，1:1联系可以与任意一端对应的关系模式合并
2. 由于连接操作是最费时的操作，所以一般应以尽量减少连接操作为目标。

2. 将转换来的关系、网状、层次模型向特定DBMS支持下的数据模型转换

• 实体集到关系的转换
  在E-R模型向关系模型的转化中，对每一个实体集创建一个同名且具有相同属性集的关系。
• 联系集到关系的转换

1. 设计E-R模型；
2. 将E-R模型转换成一组关系模式；
3. 用数据结构图描述关系模式之间的逻辑联系；
   在关系模型中，常用数据结构图表示关系数据库的逻辑结构，长方形表示关系、连接线表示联系、主码加下划线、联系线端点的“鸡爪型”表示“多”的一边。
4. 用SQL语言定义表的结构。

• 一对一联系的转换方法:
  将一个表的主码作为外码放在另一个表中。外码通常是放在存取操作比较频繁的表中，或者根据问题的语义决定放在哪一个表中。

• 一对多联系的转换规则：
  一对多联系的转换方法是将“一”方向表的主码作为外码放在“多”方向转换的表中，实现一对多联系。

• 多对多联系转换规则：
  将联系集本身转换成一个表，该表的主码由两个父表的主码复合而成，主码非空（NOT NULL），且该表的主码也是外码。

3. 对数据模型进行优化

得到初步数据模型后，还应该适当地修改、调整数据模型的结构，以进一步提高数据库应用系统的性能。
通常以规范化理论为指导。
优化数据模型的方法

1. 确定数据依赖
   按需求分析阶段所得到的语义，分别写出每个关系模式内部各属性之间的数据依赖以及不同关系模式属性之间数据依赖
2. 消除 冗余的联系
   对于各个关系模式之间的数据依赖进行极小化处理，消除 冗余的联系。
3. 确定所属范式
   按照数据依赖的理论对关系模式逐一进行分析
   考查是否存在部分函数依赖、传递函数依赖、多值依赖等
   确定各关系模式分别属于第几范式
4. 按照需求分析阶段得到的各种应用对数据处理的要求，分析对于这样的应用环境这些模式是否合适，
   确定是否要对它们进行合并或分解。

注意：并不是规范化程度越高的关系就越优，一般说来，第三范式就足够。

5. 按照需求分析阶段得到的各种应用对数据处理的要求，对关系模式进行必要的分解，以提高数据操作的效率和存储空间的利用率

• 常用分解方法
  水平分解
  把(基本)关系的元组分为若干子集合，定义每个子集合为一个子关系，以提高系统的效率

适用范围
满足“80/20原则”的应用:80/20原则：一个大关系中，经常被使用的数据只是关系的一部分，约 20%
把经常使用的数据分解出来,形成一个子关系,可以减少查询的数据量 。
并发事务经常存取不相交的数据

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

适用范围
取决于分解后R上的所有事务的总效率是否得到了提高

设计用户子模式

(1) 使用更符合用户习惯的别名
(2) 针对不同级别的用户定义不同的View ，以
满足系统对安全性的要求。
(3) 简化用户对系统的使用

7.2.4 物理设计

为一个给定的逻辑数据模型选取一个最适合应用环境的物理结构的过程。

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

步骤

• 确定数据库的物理结构，在关系数据库中主要指存取方法和存储结构
• 对物理结构进行评价，评价的重点是时间和空间效率
• 如果评价结果满足原设计要求，则可进入到物理实施阶段，否则，就需要重新设计或修改物理结构，有时甚至要返回逻辑设计阶段修改数据模型

内容

• 为关系模式选择存取方法(建立存取路径)

DBMS常用存取方法

• 索引方法

选择索引存取方法的一般规则:

1. 如果一个(或一组)属性经常在查询条件中出现，则考虑在这个(或这组)属性上建立索引(或组合索引)
2. 如果一个属性经常作为最大值和最小值等聚集函数的参数，则考虑在这个属性上建立索引
3. 如果一个(或一组)属性经常在连接操作的连接条件中出现，则考虑在这个(或这组)属性上建立索引

⚠️关系上定义的索引数过多会带来较多的额外开销：
维护索引的开销
查找索引的开销

• 目前主要是B+树索引方法
• 经典存取方法，使用最普遍
• 聚簇（Cluster）方法

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

1. 大大提高按聚簇码进行查询的效率
2. 节省存储空间
   ⚠️：1）聚簇只能提高某些特定应用的性能
   2）建立与维护聚簇的开销相当大
   3）对已有关系建立聚簇，将导致关系中元组移动其物理存储位置，并使此关系上原有的索引无效，必须重建
   4）当一个元组的聚簇码改变时，该元组的存储位置也要做相应移动

适用范围

1. 既适用于单个关系独立聚簇，也适用于多个关系组合聚簇
2. 当通过聚簇码进行访问或连接是该关系的主要应用，与聚簇码无关的其他访问很少或者是次要的时，可以使用聚簇

• 设计候选聚簇

1. 对经常在一起进行连接操作的关系可以建立聚簇
2. 如果一个关系的一组属性经常出现在相等比较条件中，则该单个关系可建立聚簇
3. 如果一个关系的一个(或一组)属性上的值重复率很高，则此单个关系可建立聚簇。即对应每个聚簇码值的平均元组数不太少。太少则聚簇的效果不明显。

• 优化聚簇设计

1. 从聚簇中删除经常进行全表扫描的关系；
2. 从聚簇中删除更新操作远多于连接操作的关系；
3. 不同的聚簇中可能包含相同的关系，一个关系可以在某一个聚簇中，但不能同时加入多个聚簇
4. 从这多个聚簇方案(包括不建立聚簇)中选择一个较优的，即在这个聚簇上运行各种事务的总代价最小

• HASH方法
  该关系的属性主要出现在等值连接条件中或主要出现在相等比较选择条件中；
  该关系的大小可预知，而且不变，或该关系的大小动态改变，但所选用的DBMS提供了动态HASH存取方法。

• 设计关系、索引等数据库文件的物理存储结构

确定数据库物理结构的内容
基本原则：根据应用情况将

1. 易变部分与稳定部分，分开存放
2. 存取频率较高部分与存取频率较低部分，分开存放

1. 确定数据的存放位置和存储结构
   关系
   索引
   聚簇
   日志
   备份
2. 确定系统配置

评价方法（完全依赖于所选用的DBMS ）：
定量估算各种方案
存储空间
存取时间
维护代价
对估算结果进行权衡、比较，选择出一个较优的合理的物理结构。
如果该结构不符合用户需求，则需要修改设计。

7.2.5 数据库的实施和维护

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

组织数据入库：
数据库实施阶段最主要的工作。

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

应用程序的编码和调试:
数据库应用程序的设计应该与数据设计并行进行。
在组织数据入库的同时还要调试应用程序。

数据库的试运行

在原有系统的数据有一小部分已输入数据库后，就可以开始对数据库系统进行联合调试
数据库试运行主要工作包括：
1）功能测试
实际运行数据库应用程序，执行对数据库的各种操作，测试应用程序的功能是否满足设计要求
如果不满足，对应用程序部分则要修改、调整，直到达到设计要求
2）性能测试
测量系统的性能指标，分析是否达到设计目标
如果测试的结果与设计目标不符，则要返回物理设计阶段，重新调整物理结构，修改系统参数，某些情况下甚至要返回逻辑设计阶段，修改逻辑结构
⚠️强调两点：

• 分期分批组织数据入库
  重新设计物理结构甚至逻辑结构，会导致数据重新入库。
  由于数据入库工作量实在太大，费时、费力，所以应分期分批地组织数据入库
  先输入小批量数据供调试用
  待试运行基本合格后再大批量输入数据
  逐步增加数据量，逐步完成运行评价
• 数据库的转储和恢复
  在数据库试运行阶段，系统还不稳定，硬、软件故障随时都可能发生
  系统的操作人员对新系统还不熟悉，误操作也不可避免
  因此必须做好数据库的转储和恢复工作，尽量减少对数据库的破坏。

数据库的运行与维护

在数据库运行阶段，对数据库经常性的维护工作主要是由DBA完成的，包括：
数据库的转储和恢复
数据库的安全性、完整性控制
数据库性能的监督、分析和改进
数据库的重组织和重构造

• 重组织的形式：
  全部重组织
  部分重组织
  只对频繁增、删的表进行重组织
• 重组织的目标：提高系统性能
• 重组织的工作：
  按原设计要求
  重新安排存储位置
  回收垃圾
  减少指针链

• 数据库的重组织不会改变原设计的数据逻辑结构和物理结构。

数据库重构造

• 根据新环境调整数据库的模式和内模式：
  增加新的数据项
  改变数据项的类型
  改变数据库的容量
  增加或删除索引
  修改完整性约束条件

小结

数据库的设计过程

需求分析
概念结构设计
逻辑结构设计
物理设计
实施和维护

数据库各级模式的形成

数据库的各级模式是在设计过程中逐步形成的
需求分析阶段综合各个用户的应用需求（现实世界的需求）
概念设计阶段形成独立于机器特点、独立于各个DBMS产品的概念模式（信息世界模型），用E-R图来描述
在逻辑设计阶段将E-R图转换成具体的数据库产品支持的数据模型如关系模型，形成数据库逻辑模式。然后根据用户处理的要求，安全性的考虑，在基本表的基础上再建立必要的视图（VIEW）形成数据的外模式
在物理设计阶段根据DBMS特点和处理的需要，进行物理存储安排，设计索引，形成数据库内模式