第七章 数据库设计 7.1 数据库设计概述 7.2 需求分析 7.3 概念结构设计 7.4 逻辑结构设计 7.5 数据库的物理设计 第七章 数据库设计 7.1 数据库设计概述 7.2 需求分析 7.3 概念结构设计 7.4 逻辑结构设计 7.5 数据库的物理设计 7.6 数据库实施和维护 7.7 小结 什么是数据库设计 数据库设计是指对于一个给定的应用环境，构造最优的数据库逻辑模式和物理结构，并根据此建立数据库及其应用系统，使之能够有效地存储和管理数据，满足各种用户的应用需求（信息管理要求和数据操作要求） 在数据库领域内，常常把使用数据库的各类系统统称为数据库应用系统。

7.1 数据库设计概述 7.1.1 数据库设计的特点 一、数据库建设的基本规律 三分技术，七分管理，十二分基础数据； 7.1 数据库设计概述 7.1.1 数据库设计的特点 一、数据库建设的基本规律 三分技术，七分管理，十二分基础数据； 二、结构（数据）设计和行为（处理）设计相结合 结构（数据）设计：设计数据库框架或数据库结构； 行为（处理）设计：设计应用程序、事务处理等。 三、结构和行为分离的设计 传统的软件工程忽视对应用中数据语义的分析和抽象，只要有可能就尽量推迟数据结构设计的决策 早期的数据库设计致力于数据模型和建模方法研究，忽视了对行为的设计

结构特性和行为特性结合起来 现实世界 概念模型设计 子模式设计 物理数据库设计 逻辑数据库设计 建立数据库 数据分析 功能分析 功能模型 功能说明 事务设计 程序说明 应用程序设计 程序编码调试 图7.1 结构和行为分离的设计

7.1.2 数据库设计方法 一、要求数据库设计人员应该具备的技术和知识 数据库的基本知识； 软件工程的原理和方法； 程序设计的方法和技巧； 7.1.2 数据库设计方法 一、要求数据库设计人员应该具备的技术和知识 数据库的基本知识； 软件工程的原理和方法； 程序设计的方法和技巧； 数据库的基本知识和设计技术； 应用领域的知识。 二、规范设计法(本质上看:手工设计方法) 新奥尔良（New Orleans）方法 将数据库设计分为四个阶段(需求分析、概念设计、逻辑设计、物理设计） 基于E-R模型的数据库设计方法 3NF的设计方法 ODL方法：面向对象的数据库设计方法 计算机辅助设计 ORACLE Designer 2000 SYBASE PowerDesigner

7.1.3 数据库设计的基本步骤 一、数据库设计的准备工作(选定参加设计的人员) 1. 数据库分析设计人员 数据库设计的核心人员 7.1.3 数据库设计的基本步骤 一、数据库设计的准备工作(选定参加设计的人员) 1. 数据库分析设计人员 数据库设计的核心人员 自始至终参与数据库设计 其水平决定了数据库系统的质量 2. 用户 在数据库设计中也是举足轻重的 主要参加需求分析和数据库的运行维护 用户积极参与带来的好处 加速数据库设计 提高数据库设计的质量 3. 程序员(在系统实施阶段参与进来，负责编制程序) 4. 操作员(在系统实施阶段参与进来，准备软硬件环境)

⒈需求分析阶段 ⒉概念结构设计阶段 ⒊逻辑结构设计阶段 ⒋数据库物理设计阶段 ⒌数据库实施阶段 ⒍数据库运行和维护阶段 二、数据库设计的过程(六个阶段) 准确了解与分析用户需求（包括数据与处理）； 是整个设计过程的基础，是最困难、最耗费时间的一步。 需求分析是设计数据库的起点 需求分析的结果是否准确地反映了用户的实际要求，将直接影响到后面各个阶段的设计，并影响到设计结果是否合理和实用 ⒈需求分析阶段 ⒉概念结构设计阶段 ⒊逻辑结构设计阶段 ⒋数据库物理设计阶段 ⒌数据库实施阶段 ⒍数据库运行和维护阶段 是整个数据库设计的关键； 通过对用户需求进行综合、归纳与抽象，形成一个独立于具体DBMS的概念模型（E-R图）。 将概念结构转换为某个DBMS所支持的数据模型（关系数据模型）； 对其进行优化。 然后根据用户处理的要求、安全性的考虑，在基本表的基础上再建立必要的视图(View)，形成数据的外模式 为逻辑数据模型选取一个最适合应用环境的物理结构（包括存储结构和存取方法） 根据DBMS特点和处理的需要，进行物理存储安排，建立索引，形成数据库内模式 运用DBMS提供的数据语言、工具及宿主语言，根据逻辑设计和物理设计的结果 建立数据库 编制与调试应用程序 组织数据入库 并进行试运行 数据库应用系统经过试运行后即可投入正式运行。 在数据库系统运行过程中必须不断地对其进行评价、调整与修改。 设计一个完善的数据库应用系统往往是上述六个阶段的不断反复。 （如：P202图7.2）

需求收集和分析 设计概念结构 设计逻辑结构 数据模型优化 设计物理结构 评价设计,性能预测 物理实现 试验性运行 使用、维护数据库 应用需求 数据、处理 转换规则、 DBMS功能 优化方法 应用要求, DBMS详 细特征 需求分析阶段 不满意 数据库实施阶段 物理设计阶段 逻辑设计阶段 概念设计阶段 图7.2 数据库设计步骤 数据库运行、维护阶段

设计特点 在设计过程中把数据库的设计和对数据库中数据处理的设计紧密结合起来 将这两个方面的需求分析、抽象、设计、实现在各个阶段同时进行，相互参照，相互补充，以完善两方面的设计 设计过程各个阶段的设计描述：P204图7.3

数 据 处 理 数据库重组和重构 图7.3 设计过程各个阶段的设计描述 设 计阶 段 数据流、数据存储的描述 设 计 描 述 数 据 处 理 需求分 析 数据字典、全系统中数据项、 数据流、数据存储的描述 数据流图和判定表（判定树）、数据字典中处理过程的描述 概念模型（E-R图）   数据字典 系统说明书包括： ①新系统要求、 方案和概图 ②反映新系统信息 流的数据流图 某种数据模型 关系 非关系 系统结构图 （模块结构） 存储安排 方法选择 存取路径建立 模块设计 IPO表 实施阶段 编写模式 装入数据 数据库试运行 程序编码、 编译联结、 测试 运行、维护 性能监测、转储/恢复 数据库重组和重构 新旧系统转换、运行、维护（修正性、适应性、改善性维护） IPO表…… 输入： 输出： 处理： Creat…… Load…… Main( ) …… if…… then end 分区1 分区2 逻辑结构设计 概念结构设计 物理设计 图7.3 设计过程各个阶段的设计描述

7.1.4 数据库设计过程中的各级模式 应用1 应用要求 应用2 应用3 概念 模式 综合 外模式1 外模式2 外模式3 逻辑 转换 映象 图7.4 数据库的各级模式 内模式

7.2 需求分析 7.2.1 需求分析的任务 一、需求分析的任务 二、需求分析的重点 三、需求分析的难点

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

二、需求分析的重点 需求分析的重点是调查、收集与分析用户在数据管理中的信息要求、处理要求、安全性与完整性要求。 信息要求 用户需要从数据库中获得信息的内容与性质 由用户的信息要求可以导出数据要求，即在数据库中需要存储哪些数据 处理要求 对处理功能的要求 对处理的响应时间的要求 对处理方式的要求(批处理 / 联机处理) 安全性与完整性要求。

三、需求分析的难点 确定用户最终需求的难点 用户缺少计算机知识，开始时无法确定计算机究竟能为自己做什么，不能做什么，因此无法一下子准确地表达自己的需求，他们所提出的需求往往不断地变化。 设计人员缺少用户的专业知识，不易理解用户的真正需求，甚至误解用户的需求。 新的硬件、软件技术的出现也会使用户需求发生变化。 解决方法 设计人员必须采用有效的方法，与用户不断深入地进行交流，才能逐步得以确定用户的实际需求

7.2.2 需求分析的方法 一、 调查用户需求的具体步骤 ⑴ 调查组织机构情况(为分析信息流程做准备) 组织部门的组成情况 各部门的职责等 7.2.2 需求分析的方法 调查清楚用户的实际需求并进行初步分析，与用户达成共识，然后 进一步分析与表达这些需求。 一、 调查用户需求的具体步骤 ⑴ 调查组织机构情况(为分析信息流程做准备) 组织部门的组成情况 各部门的职责等 ⑵ 调查各部门的业务活动情况。调查重点之一。 各个部门输入和使用什么数据 如何加工处理这些数据 输出什么信息 输出到什么部门 输出结果的格式是什么

⑶ 在熟悉业务活动的基础上，协助用户明确对新系统的各种要求（信息要求、处理要求、完全性与完整性要求）。调查重点之二。 ⑷ 确定新系统的边界 对前面调查的结果进行初步分析，确定哪些功能由计算机完成或将来准备让计算机完成；确定哪些活动由人工完成。 由计算机完成的功能就是新系统应该实现的功能。

二、常用调查方法 做需求调查时，往往需要同时采用多种方法 常用调查方法 ⑴跟班作业 ⑵开调查会 ⑶请专人介绍 ⑷询问 ⑸设计调查表请用户填写 ⑹查阅记录 无论使用何种调查方法，都必须有用户的积极参与和配合。 设计人员应该和用户取得共同的语言，帮助不熟悉计算机的用户建立数据库环境下的共同概念，并对设计工作的最后结果共同承担责任。 通过亲身参加业务工作了解业务活动的情况。能比较准确地理解用户的需求，但比较耗时。 通过与用户座谈来了解业务活动情况及用户需求。 对某些调查中的问题，可以找专人询问 如果调查表设计合理，则很有效，且易于为用户接受 查阅与原系统有关的数据记录

三、进一步分析和表达用户需求 分析和表达用户的需求的常用方法 自顶向下的结构化分析方法（Structured Analysis，简称SA方法） SA方法从最上层的系统组织机构入手，采用逐层分解的方式分析系统，并用数据流图和数据字典描述系统。 1．首先把任何一个系统都抽象为： 数据流 信息要求 数据 来源 处理 输出 处理要求 图7.5系统高层抽象图 数据存储

2．分解处理功能和数据 （1）分解处理功能 将处理功能的具体内容分解为若干子功能，再将每个子功能继续分解，直到把系统的工作过程表达清楚为止。 （2）分解数据 在处理功能逐步分解的同时，其所用的数据也逐级分解，形成若干层次的数据流图。 数据流图表达了数据和处理过程的关系。 （3）表达方法 处理过程：用判定表或判定树来描述 数据：用数据字典来描述 3．将分析结果再次提交给用户，征得用户的认可

四、需求分析过程 图7.6 需求分析过程

7.2.3 数据字典和数据流图 一、数据字典的用途 二、数据字典的内容 数据字典是各类数据描述的集合 7.2.3 数据字典和数据流图 一、数据字典的用途 数据字典是各类数据描述的集合 数据字典是进行详细的数据收集和数据分析所获得的主要结果 数据字典在数据库设计中占有很重要的地位 二、数据字典的内容 数据字典的内容 数据项 数据结构 数据流 数据存储 处理过程 数据项是数据的最小组成单位 若干个数据项可以组成一个数据结构 数据字典通过对数据项和数据结构的定义来描述数据流、数据存储的逻辑内容。

⒈ 数据项 ⒉ 数据结构 数据项是不可再分的数据单位 对数据项的描述 数据项描述＝｛数据项名，数据项含义说明， 别名，数据类型，长度，取值范围， 取值含义，与其他数据项的逻辑关系｝ 取值范围、与其他数据项的逻辑关系定义了数据的完整性约束条件 ⒉ 数据结构 数据结构反映了数据之间的组合关系。 一个数据结构可以由若干个数据项组成，也可以由若干个数据结构 组成，或由若干个数据项和数据结构混合组成。 对数据结构的描述 数据结构描述＝{数据结构名，含义说明，组成:{数据项或数据结构}}

⒊ 数据流 数据流是数据结构在系统内传输的路径。 对数据流的描述 数据流描述＝｛数据流名，说明，数据流来源， 　数据流描述＝｛数据流名，说明，数据流来源， 数据流去向，组成:｛数据结构｝， 平均流量，高峰期流量｝ 数据流来源是说明该数据流来自哪个过程 数据流去向是说明该数据流将到哪个过程去 平均流量是指在单位时间（每天、每周、每月等）里的传输次数 高峰期流量则是指在高峰时期的数据流量

⒋ 数据存储 数据存储是数据结构停留或保存的地方，也是数据流的来源和去向之一。 对数据存储的描述 数据存储描述＝｛数据存储名，说明，编号， 　数据存储描述＝｛数据存储名，说明，编号， 流入的数据流 ，流出的数据流 ， 组成:｛数据结构｝，数据量，存取方式｝ 流入的数据流：指出数据来源 流出的数据流：指出数据去向 数据量：每次存取多少数据，每天（或每小时、每周等）存取几次等信息 存取方法：批处理 / 联机处理；检索 / 更新；顺序检索 / 随机检索

⒌ 处理过程 处理过程的具体处理逻辑一般用判定表或判定树来描述。数据字典中只需要描述处理过程的说明性信息 处理过程说明性信息的描述 　处理过程描述＝｛处理过程名，说明， 输入:｛数据流｝，输出:｛数据流｝， 处理:｛简要说明｝｝ 简要说明：主要说明该处理过程的功能及处理要求 功能：该处理过程用来做什么 处理要求：处理频度要求（如单位时间里处理多少事务，多 少数据量）；响应时间要求等 处理要求是后面物理设计的输入及性能评价的标准

数据字典举例 例：学生学籍管理子系统的数据字典。 数据项，以“学号”为例： 数据项： 学号 含义说明：唯一标识每个学生 别名： 学生编号 数据项：　学号 含义说明：唯一标识每个学生 　别名：　　学生编号 类型：　　字符型 长度：　　 8 取值范围：00000000至99999999 　取值含义：前两位标别该学生所在年级， 后六位按顺序编号 　与其他数据项的逻辑关系：

数据结构 以“学生”为例 “学生”是该系统中的一个核心数据结构： 数据结构：学生 含义说明：是学籍管理子系统的主体数据结构，定义了一个学生 的有关信息 组成：　　学号，姓名，性别，年龄，所在系，年级

数据流“体检结果”可如下描述： 数据流：　　体检结果 说明：　　　学生参加体格检查的最终结果 数据流来源：体检 数据流去向：批准 组成：　　　…… 　平均流量：　…… 　高峰期流量：……

数据存储“学生登记表”可如下描述： 数据存储：　学生登记表 说明：　　　记录学生的基本情况 　流入数据流：…… 流出数据流：…… 组成：　　　…… 数据量：　　每年3000张 存取方式：　随机存取

处理过程“分配宿舍”可如下描述： 　处理过程：分配宿舍 　说明：　　为所有新生分配学生宿舍 　输入：　　学生，宿舍， 　输出：　　宿舍安排 　处理：　　在新生报到后，为所有新生分配学 生宿舍。要求同一间宿舍只能安排 同一性别的学生，同一个学生只能 安排在一个宿舍中。每个学生的居 住面积不小于3平方米。安排新生 宿舍其处理时间应不超过15分钟。

三、数据流图（Data Flow Diagram，简称DFD） 数据流图是描绘系统逻辑模型的一种网络表示(这里的系统可以是自动化系统、手工系统或是两者混合而成的系统)。数据流图通过它的成分及所标明各个成分之间的接口来描述系统，数据流图的基本成分是: 1.数据流; 2.文件(数据存储); 3.加工(亦称处理、过程或变换); 4.数据源点或终点。 是某种已知构成的信息所流过的通道 是数据的暂存区 是一种将进入数据流转化为流出数据流的变换 是系统之外的人或组织；这些人或组织是单纯数据的产生源或接收者 命名原则：要具体，便于区分，名副其实，反映功用

2.文件（数据存储） —用开口矩形或两条平行横线表示； 数据流图常用的符号 1.数据流 —用箭头线表示； 数据流 2.文件（数据存储） —用开口矩形或两条平行横线表示； 数据存储 3.加工（亦称处理、过程或变换） —用圆角矩形或圆形表示； 数据处理 4.数据源点或终点 —用正方形或立方体表示。 数据源点或终点

7.3 概念结构设计 7.3.1 概念结构 什么是概念结构设计 需求分析阶段描述的用户应用需求是现实世界的具体需求 7.3.1 概念结构 什么是概念结构设计 需求分析阶段描述的用户应用需求是现实世界的具体需求 将需求分析得到的用户需求抽象为信息结构即概念模型的过程就是概念结构设计 概念结构是各种数据模型的共同基础，它比数据模型更独立于机器、更抽象，从而更加稳定。 概念结构设计是整个数据库设计的关键 现实世界 机器世界 信息世界 需求分析 概念结构设计

概念结构设计的特点 （1）能真实、充分地反映现实世界，包括事物和事物之间的联系，能满足用户对数据的处理要求。是对现实世界的一个真实模型。 （2）易于理解，从而可以用它和不熟悉计算机的用户交换意见，用户的积极参与是数据库的设计成功的关键。 （3）易于更改，当应用环境和应用要求改变时，容易对概念模型修改和扩充。 （4）易于向关系、网状、层次等各种数据模型转换 描述概念模型的工具 E-R模型

7.3.2 概念结构设计的方法与步骤 设计概念结构的四类方法 自顶向下 首先定义全局概念结构的框架，然后逐步细化 自底向上 7.3.2 概念结构设计的方法与步骤 设计概念结构的四类方法 自顶向下 首先定义全局概念结构的框架，然后逐步细化 自底向上 首先定义各局部应用的概念结构，然后将它们集成起来，得到全局概念结构 逐步扩张 首先定义最重要的核心概念结构，然后向外扩充，以滚雪球的方式逐步生成其他概念结构，直至总体概念结构 混合策略 将自顶向下和自底向上相结合，用自顶向下策略设计一个全局概念结构的框架，以它为骨架集成由自底向上策略中设计的各局部概念结构。

… 全局概念模式 概念模式 (a)　自顶向下的设计方法 需求

… 概念模式 (b)　自底向上的设计方法 子需求 全局概念模式

(c)　逐步扩张的设计方法 核心需求 需求 核心概念结构 全局概念结构 …

图7.8 自顶向下需求分析与自底向上设计概念结构 概念结构设计的方法与步骤（续） …… 需求 1 .1 . 2 概念模式 n ( 应用 1) 全局概念模式 ) 需求分析 自顶向下 概念结构设计 自底向上 图7.8 自顶向下需求分析与自底向上设计概念结构

常用策略（P211图7.8） 自顶向下进行需求分析 自底向上设计概念结构 自底向上设计概念结构的步骤 （P211图7.9） 第1步：抽象数据并设计局部视图 第2步：集成局部视图，得到全局概念结构

图7.9 自底向上方法的设计步骤 DFD、DD 需求分析 数据抽象、 局部视图设计 局部E－R图 征求用户意见 全局E－R图 视图集成 逻辑结构设计 图7.9 自底向上方法的设计步骤

7.3.3 数据抽象与局部视图设计 学 生 张英 王平 刘勇 …… 赵亮 一、数据抽象 概念结构是对现实世界的一种抽象 7.3.3 数据抽象与局部视图设计 一、数据抽象 概念结构是对现实世界的一种抽象 从实际的人、物、事和概念中抽取所关心的共同特性，忽略非本质的细节 把这些特性用各种概念精确地加以描述 这些概念组成了某种模型 三种常用抽象 1. 分类（Classification） 定义某一类概念作为现实世界中一组对象的类型 这些对象具有某些共同的特性和行为 它抽象了对象值和型之间的“is member of”的语义 在E-R模型中，实体型就是这种抽象 例：P212图7.10 学 生 张英 王平 刘勇 …… 赵亮

本科生 学 生 研究生 “is subset of ” 2. 聚集（Aggregation） 定义某一类型的组成成分 学 生 学号 姓名 专业 班级 实体型 属性 图7.11 聚集 本科生 学 生 研究生 “is subset of ” 图7.13 概括 仓库号 面积 主任 仓库 姓名 年龄 性别 工资 图7.12 更复杂的聚集 2. 聚集（Aggregation） 定义某一类型的组成成分 它抽象了对象内部类型和成分之间“is part of”的语义 在E-R模型中若干属性的聚集组成了实体型，就是这种抽象 例：P212图7.11，图7.12 3. 概括（Generalization） 定义类型之间的一种子集联系 它抽象了类型之间的“is subset of”的语义 概括有一个很重要的性质：继承性。子类继承超类上定义的所有抽象。 例：P213图7.13 注：原E-R模型不具有概括，本书对E-R模型作了扩充，允许定义超类实体型和子类实体型。 用双竖边的矩形框表示子类， 用直线加小圆圈表示超类-子类的联系

二、局部视图设计 设计分E-R图的步骤: 选择局部应用 逐一设计分E-R图 数据抽象的用途 对需求分析阶段收集到的数据进行分类、组织（聚集），形成 实体 实体的属性，标识实体的码 确定实体之间的联系类型(1:1，1:n，m:n) 二、局部视图设计 设计分E-R图的步骤: 选择局部应用 逐一设计分E-R图

⒈ 选择局部应用 需求分析阶段，已用多层数据流图和数据字典描述了整个系统。 设计分E-R图首先需要根据系统的具体情况，在多层的数据流图 中选择一个适当层次的数据流图，让这组图中每一部分对应一个 局部应用，然后以这一层次的数据流图为出发点，设计分E-R图。 通常以中层数据流图作为设计分E-R图的依据。原因： 高层数据流图只能反映系统的概貌 中层数据流图能较好地反映系统中各局部应用的子系统组成 低层数据流图过细

…… … 实例:某工厂的信息管理系统 设计E-R图的出发点 图7.14 设计分E-R图的出发点 物资管理子系统 销售管理子系统 人事管理子系统 设计E-R图的出发点 …… … 图7.14 设计分E-R图的出发点

⒉ 逐一设计分E-R图 任务——标定局部应用中的实体、属性、码，实体间的联系 将各局部应用涉及的数据分别从数据字典中抽取出来，参照数据流图，标定各局部应用中的实体、实体的属性、标识实体的码，确定实体之间的联系及其类型（1:1，1:n，m:n） 如何抽象实体和属性 实体：现实世界中一组具有某些共同特性和行为的对象就可以抽象为一个实体。对象和实体之间是“is member of"的关系。 例：在学校环境中，可把张三、李四等对象抽象为学生实体。 属性：对象类型的组成成分可以抽象为实体的属性。组成成分与对象类型之间是“is part of"的关系。 例：学号、姓名、专业、年级等可以抽象为学生实体的属性。其中学号为标识学生实体的码

如何区分实体和属性 实体与属性是相对而言的。同一事物，在一种应用环境中作为“属性”，在另一种应用环境中就必须作为“实体”。 例：学校中的系，在某种应用环境中，它只是作为“学生”实体的一个属性，表明一个学生属于哪个系；而在另一种环境中，由于需要考虑一个系的系主任、教师人数、学生人数、办公地点等，这时它就需要作为实体了。 一般原则 属性不能再具有需要描述的性质。即属性必须是不可分的数据项，不能再由另一些属性组成。 属性不能与其他实体具有联系。联系只发生在实体之间。 符合上述两条特性的事物一般作为属性对待。 为了简化E-R图的处置，现实世界中的事物凡能够作为属性对待的，应尽量作为属性。

例1：“学生”由学号、姓名等属性进一步描述，根据准则１，“学生”只能作为实体，不能作为属性。 举例 例1：“学生”由学号、姓名等属性进一步描述，根据准则１，“学生”只能作为实体，不能作为属性。 例2：职称通常作为教师实体的属性，但在涉及住房分配时，由于分房与职称有关，也就是说职称与住房实体之间有联系，根据准则２，这时把职称作为实体来处理会更合适些。 图7.15 职称作为一个实体　 　职工 职工号 姓名 年龄 职称 职工 聘任 n 1 性别 职称代码 工资 住房标准 附加福利

病人 住院号 姓名 病房号 住在 n 1 病房 医疗 医生 m 图7.16　病房作为一个属性或实体

n n 1 存放 货物 m 仓库 货号 单价 仓库号 面积 货物 货号 单价 存放仓库号 存量 存放 货物 m 仓库 管理 职工 货号 单价 图7.17　仓库作为一个属性或实体

设计分E-R图的步骤 （1）以数据字典为出发点定义E-R图。 数据字典中的“数据结构”、“数据流”和“数据存储”等已是若干属性的有意义的聚合 （2）按上面给出的准则进行必要的调整。

例:销售子系统分E-R图的设计 第一层数据流图(P216 图7.18) 第二层数据流图(P216 图7.19~图7.22) 支付 顾客 1 n 应付帐款 订货 订单 产品 ？

逐一设计分E-R图（例） 图 7. 18 销售管理子系统第一层数据流图 顾客 1.0 接收订单 已批准订单 2 .0 处理订单 顾客账目状况 应收账款 产品描述 订单细节 3 开发票 订单记录本 包装通知单 结算数据 主管 部门 主管部门 批准 / 不批准 核对订 单数据 生产 生产通知单 准备发货细节 发票 4 支付过账 调整 未付差 额调整 5 提供应 收账款 应收账款报表 财务费 用变动 当前价格 订单数据 图 7. 18 销售管理子系统第一层数据流图 逐一设计分E-R图（例）

逐一设计分E-R图（例） 1. 3 批准订单 账目状况已核对的订单 已批准的订单 当前价格 应收账款 顾客账 目状况 批准 / 不批准 主管部门 核对订单数据 产品描述 已核对价 1. 2 订单数据 1.1 格的订单 顾客 核对账 核对价格 目状况 主管 部门 图7.19 接收订单

图7.20 处理订单 逐一设计分E-R图（例）

图7.21 开发票

图7.22 支付过账

图中在订单实体与产品实体之间的问号“？”表示还不能确定这两个实体之间的联系类型。然后参照第二层数据流图和数据字典中的详尽描述，遵循前面给出的两个准则，进行如下调整： 订单应作为实体 零件号+数量+ …… 订单：订单号+若干头信息+订单细节+… 每张订单由订单号、若干头信息和订单细节组成。订单细节又有订货的零件号、数量等来描述。按照准则（2），订单细节就不能作订单的属性处理而应该上升为实体。一张订单可以订若干产品，所以订单与订单细节两个实体之间是1∶n的联系。

原订单和产品的联系实际上是订单细节和产品的联系; 发票清单是否作为实体？ 否，因为该信息在应收帐款中体现了; 折扣规则实体——体现各种商品不同数量的折扣。

通过调整得到分E-R图如下： 1 图7.24 销售子系统的分E-R图 支付 顾客 n 应付帐款 订货 订单 组成 订单细节 参照2 产品描述 参照1 折扣规则 图7.24 销售子系统的分E-R图

每个实体定义的属性如下； 顾客：{顾客号，顾客名，地址，电话，信贷状况，帐目余额} 订单：{订单号，顾客号，订货项数，订货日期，交货日期，工种号，生产地点} 订单细则：{订单号，细则号，零件号，订货数，金额} 应收帐款：{顾客号，订单号，发票号，应收金额，支付日期，支付金额，当前余额，货款限额 折扣规则：{产品号，订货量，折扣}

7.3.4 视图的集成 各个局部视图即分E-R图建立好后，还需要对它们进行合并，集成为一个整体的数据概念结构即总E-R图。 7.3.4 视图的集成 各个局部视图即分E-R图建立好后，还需要对它们进行合并，集成为一个整体的数据概念结构即总E-R图。 视图集成的两种方式 一次集成（P219图7.25(a)） 一次集成多个分E-R图，通常用于局部视图比较简单时。 逐步集成（P220图7.25(b)） 首先集成两个局部视图（通常是比较关键的两个局部视图）以后每次将一个新的局部视图集成进来 集成局部E-R图的步骤 1. 合并 2. 修改与重构 第1种方法比较复杂，做起来难度较大。 第2种方法每次只集成两个分E-R图，可以降低复杂度。

分析 规范化 理论 集成 视图 基本 E-R 图 分 修改与重构 ( 消除不必 要的冗余 ) 初步 合并 消除冲突 图7.26 视图的集成

一、合并分E-R图，生成初步E-R图 各分Ｅ－Ｒ图存在冲突 冲突的种类 属性冲突 命名冲突 结构冲突

⒈ 属性冲突 两类属性冲突 属性域冲突：属性值的类型、取值范围或取值集合不同。例如：零件号（C/N）年龄（D/N） 属性取值单位冲突：例如：零件的重量（公斤/克） 属性冲突的解决方法 通常用讨论、协商等行政手段加以解决。

⒉ 命名冲突 两类命名冲突 同名异义：不同意义的对象在不同的局部应用中具有相同的名字。 异名同义（一义多名）：同一意义的对象在不同的局部应用中具有不同的名字 例如：有的部门把科研项目称项目 有的部门则把科研项目称课题 命名冲突可能发生在属性级、实体级、联系级上。其中属性的命名冲突更为常见。 命名冲突的解决方法 通过讨论、协商等行政手段加以解决

⒊ 结构冲突 三类结构冲突 同一对象在不同应用中具有不同的抽象 例，“课程”在某一局部应用中被当作实体在另一局部应用中则被当作属性 解决方法：通常是把属性变换为实体或把实体变换为属性，使同一对象具有相同的抽象。变换时要遵循两个准则。 同一实体在不同局部视图中所包含的属性不完全相同，或者属性的排列次序不完全相同。 产生原因：不同的局部应用关心的是该实体的不同侧面。 解决方法：使该实体的属性取各分E-R图中属性的并集，再适当设计属性的次序。 实体之间的联系在不同局部视图中呈现不同的类型 解决方法：根据应用语义对实体联系的类型进行综合或调整。(P221图7.27)

例如: 图7.27 合并两个分E-R图的综合

二、消除不必要的冗余，设计基本E-R图 1 ．冗余 分E-R图 初步E-R图 基本E-R图 所谓冗余的数据是指可由基本数据导出的数据，冗余的联系是指可由其他联系导出的联系。 分E-R图 冗余数据和冗余联系容易破坏数据库的完整性，给数据库维护增加困难 并不是所有的冗余数据与冗余联系都必须加以消除，有时为了提高某些应用的效率，不得不以冗余信息作为代价。 设计数据库概念结构时，哪些冗余信息必须消除，哪些冗余信息允许存在，需要根据用户的整体需求来确定。 消除不必要的冗余后的初步E-R图称为基本E-R图。 合并 解决冲突 可能存在冗余的数据 和冗余的实体间联系 初步E-R图 消除不必要的冗余 基本E-R图

2．消除冗余的方法 1) 分析方法 以数据字典和数据流图为依据，根据数据字典中关于数据项之间逻辑关系的说明来消除冗余。 如果是为了提高效率，人为地保留了一些冗余数据，则应把数据字典中数据关联的说明作为完整性约束条件。 一种更好的方法是把冗余数据定义在视图中。

消除不必要的冗余   冗余 Q3=Q1 × Q2          Q4=∑Q5 允许冗余 提高某些应用响应时间Q4保留，Q4=∑Q5是完整性约束条件。并且由于Q3消去，产品与材料间m∶n的冗余联系也应消去。 图7.28 消除冗余

2) 规范化理论 函数依赖的概念提供了消除冗余联系的形式化工具。 方法 (1) 确定分E-R图实体之间的数据依赖FL 。实体之间一对一、一对多、多对多的联系可以用实体码之间的函数依赖来表示。 (2) 求FL的最小覆盖GL ，差集为： D = FL-GL。 逐一考察D中的函数依赖，确定是否是冗余的联系，若是，就把它去掉。 由于规范化理论受到泛关系假设的限制，应注意下面两个问题： (1) 冗余的联系一定在D中，而D中的联系不一定是冗余的； (2) 当实体之间存在多种联系时要将实体之间的联系在形式上加以区分。

实例：某工厂信息管理系统的视图集成。 图1.14 工厂物资管理系统 职工 职工号 姓名 年龄 职称 (a) 实体及其属性图 零件号 名称 图1.14 工厂物资管理系统 职工 职工号 姓名 年龄 职称 (a) 实体及其属性图 零件号 名称 规格 单价 描述 零件 预算 项目 项目号 开工日期 地址 供应商号 电话号 账号 供应商 仓库 仓库号 面积

图1.14 工厂物资管理系统 供应商 m 供应 供应量 项目 n 仓库 库存 零件 p 工作 1 职工 库存量 领导 (b)实体及其联系图

图1.14 工厂物资管理系统E-R图 供应商 姓名 供应商号 地址 账号 电话号 仓库 仓库号 面积 职工号 年龄 职工 工作 1 n 领导 库存 供应量 m 供应 库存量 项目 项目号 预算 开工日期 零件 零件号 规格 名称 描述 单价 p (C)完整的实体联系图 职称

实例：某工厂信息管理系统的视图集成。 部门 1 n 职工 项目 m 图 7.29 劳动人事管理的分E-R图 生产 属于 负责 天数

支付 顾客 1 n 应付帐款 订货 订单 组成 订单细节 参照2 产品描述 参照1 折扣规则 图7.24 销售子系统的分E-R图

图1.14(c)、图7.24、图7.29分别为该厂物资、劳动人事和销售管理的分E-R图。把这3个分E-R图进行集成过程中解决了以下问题： （1）异名同义，“项目”和“产品”含义相同。某个“项目”实质上是指某个“产品”的生产。统一用“产品”作实体名。 （2）库存管理中职工与仓库的工作关系已包含在劳动人事管理部门与职工之间的联系之中，所以可以取消。职工之间领导与被领导关系可由部门与职工（经理）之间的领导关系、部门与职工之间的从属关系两者导出，所以也可以取消。 图7.30为该系统的基本E-R图。基本E-R图中各实体的属性因篇幅有限这里从略。

部门 属于 天数 1 n 职工 参加 负责 产品 m 领导 供应商 供应 供应量 零件 p 参照 2 库存 库存量 订单细节 仓库 组成 订单 订货 顾客 支付 应收款 折扣规则 图6. 30 某工厂管理信息系统的基本E-R图

三、验证整体概念结构 视图集成后形成一个整体的数据库概念结构，对该整体概念结构还必须进行进一步验证，确保它能够满足下列条件： 整体概念结构内部必须具有一致性，不存在互相矛盾的表达。 整体概念结构能准确地反映原来的每个视图结构，包括属性、实体及实体间的联系。 整体概念结构能满足需要分析阶段所确定的所有要求。 整体概念结构最终还应该提交给用户，征求用户和有关人员的意见，进行评审、修改和优化，然后把它确定下来，作为数据库的概念结构，作为进一步设计数据库的依据

概念结构设计小结 概念结构设计的步骤 抽象数据并设计局部视图 集成局部视图，得到全局概念结构 验证整体概念结构 数据抽象(分类、聚集、概括） ⒈ 选择局部应用 ⒉ 逐一设计分E-R图 标定局部应用中的实体、属性、码，实体间的联系 用E-R图描述出来 集成局部视图 1.合并分E-R图，生成初步E-R图 消除冲突（属性冲突、命名冲突、结构冲突） 2. 修改与重构 消除不必要的冗余，设计生成基本E-R图 分析方法 规范化理论

7.4 逻辑结构设计 逻辑结构设计的任务 概念结构是各种数据模型的共同基础 7.4 逻辑结构设计 逻辑结构设计的任务 概念结构是各种数据模型的共同基础 为了能够用某一DBMS实现用户需求，还必须将概念结构进一步转化为相应的数据模型，这正是数据库逻辑结构设计所要完成的任务。 逻辑结构设计的步骤 将概念结构转化为一般的关系、网状、层次模型 将转化来的关系、网状、层次模型向特定DBMS支持下的数据模型转换 对数据模型进行优化

逻辑结构设计 概念结 构设计 数据库 物理设计 转化为一般数据模型 转化为特定DBMS支持下的据模型 逻辑 模型 优化方法如规范化理论 优化模型 概念结 构设计 数据库 物理设计 基本E-R图 转换规则 特定DBMS的特点与限制 优化方法如规范化理论 逻辑 模型 图7.31 逻辑结构设计时的三个步骤

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

转换原则 ⒈ 一个实体型转换为一个关系模式。 关系的属性：实体型的属性 关系的码：实体型的码 例，职工实体可以转换为如下关系模式： 职工号 姓名 性别 职务 出生日期 部门号 转换原则 ⒈ 一个实体型转换为一个关系模式。 关系的属性：实体型的属性 关系的码：实体型的码 例，职工实体可以转换为如下关系模式： 　　职工（职工号，部门号，姓名，职务，性别，出生日期） ⒉ 一个m:n联系转换为一个关系模式。 关系的属性：与该联系相连的各实体的码以及联系本身的属性 关系的码：各实体码的组合 [例] “选修”联系是一个m:n联系，可以将它转换为如下关系模式，其中学号与课程号为关系的组合码： 　　选修（学号，课程号，成绩）

可以减少系统中的关系个数，一般情况下更倾向于采用这种方法。 ⒊ 一个1:n联系可以转换为一个独立的关系模式，也可以与n端对应的关系模式合并。 1) 转换为一个独立的关系模式 关系的属性：与该联系相连的各实体的码以及联系本身的属性 关系的码：n端实体的码 2) 与n端对应的关系模式合并 合并后关系的属性：在n端关系中加入1端关系的码和联系本身的属性 合并后关系的码：不变 可以减少系统中的关系个数，一般情况下更倾向于采用这种方法。

⒋ 一个1:1联系可以转换为一个独立的关系模式，也可以与任意一端对应的关系模式合并。 1) 转换为一个独立的关系模式 关系的属性：与该联系相连的各实体的码以及联系本身的属性 关系的候选码：每个实体的码均是该关系的候选码 2) 与某一端对应的关系模式合并 合并后关系的属性：加入对应关系的码和联系本身的属性 合并后关系的码：不变 ⒌ 三个或三个以上实体间的一个多元联系转换为一个关系模式。 关系的属性：与该多元联系相连的各实体的码以及联系本身的属性 关系的码：各实体码的组合 例，“供应”联系是一个三元联系，可以将它转换为如下关系模式，其中产品号、供应商号和零件号为关系的组合码： 　　供应（产品号，供应商号，零件号，供应量）

⒍ 同一实体集的实体间的联系，即自联系，也可按上述1:1、1:n和m:n三种情况分别处理。 职工：｛职工号，部门号，姓名，性别，职称，出生日期，部门领导｝ ⒎ 具有相同码的关系模式可合并。 目的：减少系统中的关系个数。 合并方法：将其中一个关系模式的全部属性加入到另一个关系模式中，然后去掉其中的同义属性（可能同名也可能不同名），并适当调整属性的次序。

下面把图7.30中虚线上部的E-R图转换为一组关系模式。关系模式的码用下横线标出。 部门（部门号，部门名，经理的职工号，……） 此为部门实体对应的关系模式。该关系模式已包含了联系“领导”所对应的关系模式。经理的职工号是关系的候选码。 职工（职工号，部门号，职工名，职务，……） 此为职工实体对应的关系模式。该关系模式已包含了联系“属于”所对应的关系模式。 产品（产品号，产品名，产品组长的职工，……） 此为产品实体对应的关系模式。 供应商（供应商号，姓名，……）------此为供应商实体对应的关系模式。 零件（零件号，零件名，……）-----此为零件实体对应的关系模式。 职工工作（职工号，产品号，工作天数，……） 此为联系“参加”所对应的关系模式。 供应（产品号，供应商号，零件号，供应量） 此为联系“供应”所对应的关系模式。

向特定DBMS规定的模型进行转换 一般的数据模型还需要向特定DBMS规定的模型进行转换。 对于关系模型来说，这种转换通常都比较简单。

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

数据模型的优化（方法） ⒈ 确定数据依赖 按需求分析阶段所得到的语义，分别写出每个关系模式内部各属性之间的数据依赖以及不同关系模式属性之间数据依赖。 ⒉ 对于各个关系模式之间的数据依赖进行极小化处理，消除冗余的联系。 ⒊ 按照数据依赖的理论对关系模式逐一进行分析，考查是否存在部分函数依赖、传递函数依赖、多值依赖等，确定各关系模式分别属于第几范式。

⒋ 按照需求分析阶段得到的各种应用对数据处理的要求，分析对于这样的应用环境这些模式是否合适，确定是否要对它们进行合并或分解。 并不是规范化程度越高的关系就越优。 当一个应用的查询中经常涉及到两个或多个关系模式的属性时，系统必须经常地进行联接运算，而联系运算的代价是相当高的，可以说关系模型低效的主要原因就是做联接运算引起的，因此在这种情况下，第二范式甚至第一范式也许是最好的。 非BCNF的关系模式虽然从理论上分析会存在不同程度的更新异常，但如果在实际应用中对此关系模式只是查询，并不执行更新操作，则就不会产生实际影响。 对于一个具体应用来说，到底规范化进行到什么程度，需要权衡响应时间和潜在问题两者的利弊才能决定。一般说来，第三范式就足够了。

⒌ 按照需求分析阶段得到的各种应用对数据处理的要求，对关系模式进行必要的分解或合并，以提高数据操作的效率和存储空间的利用率。 常用分解方法 水平分解 垂直分解

水平分解 什么是水平分解 把(基本)关系的元组分为若干子集合，定义每个子集合为一个子关系，以提高系统的效率。 水平分解的适用范围 1. 满足“80/20原则”的应用 80/20原则：一个大关系中，经常被使用的数据只是关系的一部分，约20%，把经常使用的数据分解出来，形成一个子关系，可以减少查询的数据量。 2.并发事务经常存取不相交的数据 如果关系R上具有n个事务，而且多数事务存取的数据不相交，则R可分解为少于或等于n个子关系，使每个事务存取的数据对应一个关系。

垂直分解 什么是垂直分解 把关系模式R的属性分解为若干子集合，形成若干子关系模式。 垂直分解的原则 垂直分解的优点 可以提高某些事务的效率 垂直分解的缺点 可能使另一些事务不得不执行连接操作，从而降低了效率。 垂直分解的适用范围 取决于分解后R上的所有事务的总效率是否得到了提高。 进行垂直分解的方法 简单情况：直观分解 复杂情况：用第五章中的模式分解算法 垂直分解必须不损失关系模式的语义(保持无损连接性和保持函数依赖)。

7.4.3 设计用户子模式 将概念模型转换为全局逻辑模型后，还应该根据局部应用需求，结合具体RDBMS的特点，设计用户的外模式。 7.4.3 设计用户子模式 将概念模型转换为全局逻辑模型后，还应该根据局部应用需求，结合具体RDBMS的特点，设计用户的外模式。 目前关系数据库管理系统一般都提供了视图（View）概念，可以利用这一功能设计更符合局部用户需要的用户外模式。 定义数据库模式主要是从系统的时间效率、空间效率、易维护等角度出发。 由于用户外模式与模式是相对独立的，因此在定义用户外模式时可以考虑用户的习惯与方便。包括三个方面：

7.4.3 设计用户子模式 (1) 使用更符合用户习惯的别名 7.4.3 设计用户子模式 (1) 使用更符合用户习惯的别名 合并各分E-R图曾做了消除命名冲突的工作，以使数据库系统中同一关系和属性具有唯一的名字。这在设计数据库整体结构时是非常必要的。但对于某些局部应用，由于改用了不符合用户习惯的属性名，可能会使他们感到不方便，因此在设计用户的子模式时可以重新定义某些属性名，使其与用户习惯一致。 当然，为了应用的规范化，我们也不应该一味地迁就用户。 (2) 针对不同级别的用户定义不同的外模式，以满足系统对安全性的要求。 例如，有关系模式： 产品（产品号，产品名，规格，单价，生产车间，生产负责人，产品成本，产品合格率，质量等级） 可以在该关系模式上建立两个视图： 为一般顾客建立视图： 产品1（产品号，产品名，规格，单价） 为产品销售部门建立视图： 产品2（产品号，产品名，规格，单价，车间，生产负责人）

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

逻辑结构设计小结 任务－将概念结构转化为具体的数据模型 逻辑结构设计的步骤 将概念结构转化为一般的关系、网状、层次模型； 将转化来的关系、网状、层次模型向特定DBMS支持下的数据模型转换； 对数据模型进行优化； 设计用户子模式。 E-R图向关系模型的转换内容 将E-R图转换为关系模型：将实体、实体的属性和实体之间的联系转化为关系模式。

逻辑结构设计小结 E-R图向关系模型的转换原则 ⒈ 一个实体型转换为一个关系模式。 ⒉ 一个m:n联系转换为一个关系模式。 ⒊ 一个1:n联系可以转换为一个独立的关系模式，也可以与n端对应的关系模式合并。 ⒋ 一个1:1联系可以转换为一个独立的关系模式，也可以与任意一端对应的关系模式合并。 ⒌三个或三个以上实体间的一个多元联系转换为一个关系模式。 ⒍ 同一实体集的实体间的联系，即自联系，也可按上述1:1、1:n和m:n三种情况分别处理。 ⒎ 具有相同码的关系模式可合并。

逻辑结构设计小结 优化数据模型的方法 ⒈ 确定数据依赖 ⒉ 对于各个关系模式之间的数据依赖进行极小化处理，消除冗余的联系。 ⒉ 对于各个关系模式之间的数据依赖进行极小化处理，消除冗余的联系。 ⒊ 确定各关系模式分别属于第几范式。 ⒋ 分析对于应用环境这些模式是否合适，确定是否要对它们进行合并或分解。 ⒌ 对关系模式进行必要的分解或合并 设计用户子模式 1. 使用更符合用户习惯的别名 2. 针对不同级别的用户定义不同的外模式，以满足系统对安全性的要求。 3. 简化用户对系统的使用

7.5 数据库的物理设计 数据库物理设计的步骤 数据库在物理设备上的存储结构与存取方法称为数据库的物理结构，它依赖于给定的计算机系统。 7.5 数据库的物理设计 数据库在物理设备上的存储结构与存取方法称为数据库的物理结构，它依赖于给定的计算机系统。 为一个给定的逻辑数据模型选取一个最适合应用环境的物理结构的过程，就是数据库的物理设计。 数据库物理设计的步骤 确定数据库的物理结构 对物理结构进行评价，评价的重点是时间和空间效率 如果评价结果满足原设计要求则可进入到物理实施阶段，否则，就需要重新设计或修改物理结构，有时甚至要返回逻辑设计阶段修改数据模型。

数据库物理设计 确定数据库的物理结构 评价数据库的物理结构 逻辑结 构设计 数据库 实施 物理 模型 逻辑 模型

7.5.1 数据库的物理设计的内容和方法 一、设计数据库物理结构的准备工作 7.5.1 数据库的物理设计的内容和方法 一、设计数据库物理结构的准备工作 1. 充分了解应用环境，详细分析要运行的事务，以获得选择物理数据库设计所需参数 2. 充分了解所用RDBMS的内部特征，特别是系统提供的存取方法和存储结构 二、选择物理数据库设计所需参数 数据库查询事务 查询的关系 查询条件所涉及的属性 连接条件所涉及的属性 查询的投影属性 数据更新事务 被更新的关系 每个关系上的更新操作条件所涉及的属性 修改操作要改变的属性值 每个事务在各关系上运行的频率和性能要求

三、关系数据库物理设计的内容 1. 为关系模式选择存取方法(建立存取路径) 2. 设计关系、索引等数据库文件的物理存储结构

7.5.2 关系模式存取方法选择 数据库系统是多用户共享的系统，对同一个关系要建立多条存取路径才能满足多用户的多种应用要求。 7.5.2 关系模式存取方法选择 数据库系统是多用户共享的系统，对同一个关系要建立多条存取路径才能满足多用户的多种应用要求。 物理设计的第一个任务就是要确定选择哪些存取方法，即建立哪些存取路径。 DBMS常用存取方法 索引方法，目前主要是B+树索引方法 聚簇（Cluster）方法 HASH方法 HASH方法是用 HASH函数存储和存取关系记录的方法。具体地讲是，指定某个关系上的一个（组）属性A作为HASH码，对该HASH码定义一个函数（称为HASH函数），关系记录的存储地址由HASH（a）来决定，a是该记录在属性A上的值。

一、索引存取方法的选择 选择索引存取方法的主要内容 根据应用要求确定 对哪些属性列建立索引 关系上定义的索引数过多会带来较多的额外开销 对哪些属性列建立组合索引 对哪些索引要设计为唯一索引 选择索引存取方法的一般规则 如果一个(或一组)属性经常在查询条件中出现，则考虑在这个(或这组)属性上建立索引(或组合索引) 如果一个属性经常作为最大值和最小值等聚集函数的参数，则考虑在这个属性上建立索引 如果一个(或一组)属性经常在连接操作的连接条件中出现，则考虑在这个(或这组)属性上建立索引 关系上定义的索引数过多会带来较多的额外开销 维护索引的开销 查找索引的开销

二、聚簇存取方法的选择 什么是聚簇 例：假设学生关系按所在系建有索引，现在要查询信息系的所有学生名单。 信息系的500名学生分布在500个不同的物理块上时，至少要执行500次I/O操作。 如果将同一系的学生元组集中存放，则每读一个物理块可得到多个满足查询条件的元组，从而显著地减少了访问磁盘的次数。 什么是聚簇 为了提高某个属性（或属性组）的查询速度，把这个或这些属性（称为聚簇码）上具有相同值的元组集中存放在连续的物理块称为聚簇 许多关系型DBMS都提供了聚簇功能 聚簇的用途 1. 大大提高按聚簇属性进行查询的效率 2. 节省存储空间 聚簇以后，聚簇码相同的元组集中在一起了，因而聚簇码值不必在每个元组中重复存储，只要在一组中存一次就行了。

聚簇的适用范围 1. 既适用于单个关系独立聚簇，也适用于多个关系组合聚簇 例：假设用户经常要按系别查询学生成绩单，这一查询涉及学生关系和选修关系的连接操作，即需要按学号连接这两个关系，为提高连接操作的效率，可以把具有相同学号值的学生元组和选修元组在物理上聚簇在一起。这就相当于把多个关系按“预连接”的形式存放，从而大大提高连接操作的效率。 2. 当通过聚簇码进行访问或连接是该关系的主要应用，与聚簇码无关的其他访问很少或者是次要的时，可以使用聚簇。 尤其当SQL语句中包含有与聚簇码有关的ORDER BY，GROUP BY，UNION，DISTINCT等子句或短语时，使用聚簇特别有利，可以省去对结果集的排序操作

当一个关系同时加入多个聚簇时，必须从这多个聚簇方案(包括不建立聚簇)中选择一个较优的，即在这个聚簇上运行各种事务的总代价最小。 选择聚簇存取方法 1. 设计候选聚簇 对经常在一起进行连接操作的关系可以建立组合聚簇； 如果一个关系的一组属性经常出现在相等比较条件中，则该单个关系可建立聚簇； 如果一个关系的一个(或一组)属性上的值重复率很高，则此单个关系可建立聚簇。即对应每个聚簇码值的平均元组数不太少。太少了，聚簇的效果不明显。 2. 检查候选聚簇中的关系，取消其中不必要的关系 从独立聚簇中删除经常进行全表扫描的关系； 从独立/组合聚簇中删除更新操作远多于查询操作的关系； 从独立/组合聚簇中删除重复出现的关系 当一个关系同时加入多个聚簇时，必须从这多个聚簇方案(包括不建立聚簇)中选择一个较优的，即在这个聚簇上运行各种事务的总代价最小。

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

建立聚簇索引 （复习） 聚簇索引 建立聚簇索引后，基表中数据也需要按指定的聚簇属性值的升序或降序存放。也即聚簇索引的索引项顺序与表中元组的物理顺序一致。 例： CREATE CLUSTER INDEX Stusname ON Student(Sname)； 在Student表的Sname（姓名）列上建立一个聚簇索引，而且Student表中的记录将按照Sname值的升序存放 。 在一个基本表上最多只能建立一个聚簇索引 聚簇索引的用途：对于某些类型的查询，可以提高查询效率 聚簇索引的适用范围 很少对基表进行增删操作 很少对其中的变长列进行修改操作

三、HASH存取方法的选择 什么是HASH存取方法 选择HASH存取方法的规则 HASH方法是用 HASH函数存储和存取关系记录的方法。具体地讲是，指定某个关系上的一个（组）属性A作为HASH码，对该HASH码定义一个函数（称为HASH函数），关系记录的存储地址由HASH（a）来决定，a是该记录在属性A上的值。 选择HASH存取方法的规则 如果一个关系的属性主要出现在等值连接条件中或主要出现在相等比较选择条件中，且满足下列两个条件之一时，可以选择HASH存取方法 该关系的大小可预知，而且不变； 该关系的大小动态改变，但所选用的DBMS提供了动态HASH存取方法。

主要任务： 1. 确定数据的存放位置和存储结构，包括： 2. 确定系统配置 7.5.3 确定数据库的存储结构 7.5.3 确定数据库的存储结构 主要任务： 1. 确定数据的存放位置和存储结构，包括： 关系、索引、聚簇、日志、备份等存储安排和存储结构。 2. 确定系统配置

1. 确定数据的存放位置 影响数据存放位置和存储结构的因素 硬件环境 应用需求 存取时间 存储空间利用率 这三个方面常常是相互矛盾的 维护代价 这三个方面常常是相互矛盾的 例：消除一切冗余数据虽能够节约存储空间和减少维护代价，但往往会导致检索代价的增加，必须进行权衡，选择一个折中方案。 基本原则 根据应用情况将： 易变部分与稳定部分 存取频率较高部分与存取频率较低部分 分开存放，以提高系统性能

例： 数据库数据备份、日志文件备份等由于只在故障恢复时才使用，而且数据量很大，可以考虑存放在磁带上。 如果计算机有多个磁盘，可以考虑将表和索引分别放在不同的磁盘上，在查询时，由于两个磁盘驱动器分别在工作，因而可以保证物理读写速度比较快。 可以将比较大的表分别放在两个磁盘上，以加快存取速度，这在多用户环境下特别有效。 可以将日志文件与数据库对象（表、索引等）放在不同的磁盘以改进系统的性能。

2. 确定系统配置 系统都为这些变量赋予了合理的缺省值。但是这些值不一定适合每一种应用环境，在进行物理设计时，需要根据应用环境确定这些参数值，以使系统性能最优。 在物理设计时对系统配置变量的调整只是初步的，在系统运行时还要根据系统实际运行情况做进一步的调整，以期切实改进系统性能。 DBMS产品一般都提供了一些存储分配参数 同时使用数据库的用户数 同时打开的数据库对象数 内存分配参数 使用的缓冲区长度、个数 时间片大小 物理块的大小 物理装填因子 锁的数目 等等

对数据库物理设计过程中产生的多种方案进行细致的评价，从中选择一个较优的方案作为数据库的物理结构。 评价方法 7.5.4 评价物理结构 评价内容 对数据库物理设计过程中产生的多种方案进行细致的评价，从中选择一个较优的方案作为数据库的物理结构。 评价方法 定量估算各种方案 存储空间 存取时间 维护代价 对估算结果进行权衡、比较，选择出一个较优的合理的物理结构； 如果该结构不符合用户需求，则需要修改设计。

7.6 数据库的实施和维护 完成数据库的物理设计之后，设计人员就要用RDBMS提供的数据定义语言将数据库逻辑设计和物理设计的结果严格描述出来，成为RDBMS可以接受的源代码，再经过调试产生目标模式，然后就可以组织数据入库了，这就是数据库实施阶段。 数据库实施的工作内容 用DBMS提供的语言定义数据库结构 组织数据入库 编制与调试应用程序 数据库试运行

数据库实施 定义数据库结构 数据 装载 数据库试运行 数据库物 理设计 数据库运 行和维护 物理 模型 编制与调试应用程序 数据库 系统

7.6.1 数据的载入和应用程序的调试 数据库实施阶段包括两项重要的工作，一项是数据的载入，另一项是应用程序的编码和调试。 7.6.1 数据的载入和应用程序的调试 数据库实施阶段包括两项重要的工作，一项是数据的载入，另一项是应用程序的编码和调试。 数据库应用程序的设计应该与数据设计并行进行。 在数据库实施阶段，当数据库结构建立好后，就可以开始编制与调试数据库的应用程序。调试应用程序时由于数据入库尚未完成，可先使用模拟数据。

7.6.2 数据库的试运行 输入一小部分数据后就可以开始对数据库系统进行联合调试，这又称为数据库的试运行。 7.6.2 数据库的试运行 输入一小部分数据后就可以开始对数据库系统进行联合调试，这又称为数据库的试运行。 这一阶段要实际运行数据库应用程序，执行对数据库的各种操作，测试应用程序的功能是否满足设计要求。如果不满足，对应用程序部分则要修改和调整，直到达到设计要求为止。 数据库试运行也称为联合调试，其主要工作包括： 1）功能测试：实际运行应用程序，执行对数据库的各种操作，测试应用程序的各种功能。 2）性能测试：测量系统的性能指标，分析是否符合设计目标。

数据库性能指标的测量 数据库物理设计阶段在评价数据库结构估算时间、空间指标时，作了许多简化和假设，忽略了许多次要因素，因此结果必然很粗糙。 数据库试运行则是要实际测量系统的各种性能指标（不仅是时间、空间指标），如果结果不符合设计目标，则需要返回物理设计阶段，调整物理结构，修改参数；有时甚至需要返回逻辑设计阶段，调整逻辑结构。 特别强调两点 数据的分期入库 数据库的转储和恢复 重新设计物理结构甚至逻辑结构，会导致数据重新入库。由于数据入库工作量实在太大，所以可以采用分期输入数据的方法。 先输入小批量数据供先期联合调试使用； 待试运行基本合格后再输入大批量数据； 逐步增加数据量，逐步完成运行评价。 在数据库试运行阶段，系统还不稳定，硬、软件故障随时都可能发生； 系统的操作人员对新系统还不熟悉，误操作也不可避免； 因此必须做好数据库的转储和恢复工作，尽量减少对数据库的破坏。

7.6.3 数据库的运行与维护 数据库试运行结果符合设计目标后，数据库就可以真正投入运行了。数据库投入运行标着开发任务的基本完成和维护工作的开始 由于应用环境在不断变化，数据库运行过程中物理存储会不断变化，对数据库设计进行评价、调整、修改等维护工作是一个长期的任务，也是设计工作的继续和提高。

7.6.3 数据库的运行与维护 数据库的转储和恢复 数据库的安全性、完整性控制 数据库性能的监督、分析和改进 数据库的重组织和重构造 7.6.3 数据库的运行与维护 在数据库运行阶段，对数据库经常性的维护工作主要是由DBA完成的，包括： DBA必须根据用户的实 际需要授予不同的操作权限 在数据库运行过程中，由 于应用环境的变化，对安全 性的要求也会发生变化， DBA需要根据实际情况修 改原有的安全性控制。 由于应用环境的变化，数 据库的完整性约束条件也会 变化，也需要DBA不断修 正，以满足用户要求。 转储和恢复是系统正式运行后最重要的维护工作之一。 DBA要针对不同的应用要求制定不同的转储计划，定期对数据库和日志文件进行备份。 一旦发生介质故障，即利用数据库备份及日志文件备份，尽快将数据库恢复到某种一致性状态。 数据库运行一段时间后，由于记录不断增、删、改，会使数据库的物理存储情况变坏，降低了数据的存取效率，数据库性能下降，这时DBA就要对数据库进行重组织，或部分重组织（只对频繁增、删的表进行重组织）。RDBMS一般都提供数据重组织用的实用程序。 在数据库运行过程中， DBA必须监督系统运行，对监测数据进行分析，找出改进系统性能的方法。 利用监测工具获取系统运行过程中一系列性能参数的值 通过仔细分析这些数据，判断当前系统是否处于最佳运行状态 如果不是，则需要通过调整某些参数来进一步改进数据库性能 数据库的转储和恢复 数据库的安全性、完整性控制 数据库性能的监督、分析和改进 数据库的重组织和重构造

7.7 小结 数据库的设计过程 需求分析 概念结构设计 逻辑结构设计 物理设计 实施 运行维护 设计过程中往往还会有许多反复。

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