第8章 数据库设计 8.1 数据库设计概述 8.2 数据库需求分析 8.3 数据库结构设计 8.4 数据库行为设计 8.5 数据库的实施 8.6 数据库的运行和维护

8.1数据库设计概述 数据库设计 数据库设计是指对于一个给定的应用环境，构造（设计）优化的数据库逻辑模式和物理结构，并据此建立数据库及其应用系统，使之能够有效地存储和管理数据，满足各种用户的应用需求，包括信息管理要求和数据操作要求。 目标：为用户和各种应用系统提供一个信息基础设施和高效率的运行环境

8.1数据库设计概述

8.1数据库设计概述 数据库设计面临的主要问题 同时具备数据库与应用业务知识的人很少。 应用业务的数据库系统的目标是什么在一开始往往不能很明确。 缺乏完善的设计工具和设计方法。 用户的要求往往并不是一开始就能完全说清楚。 应用业务系统千差万别，很难找到一种适合所有应用业务的工具和方法。

8.1数据库设计概述 成功的数据库系统应具备的特点 功能强大。 能准确地表示业务数据。 容易使用和维护。 对最终用户操作的响应时间合理。 便于数据库结构的改进。 便于数据的检索和修改。 较少的数据库维护工作。 有效的安全机制能确保数据安全。 冗余数据最少或不存在。 便于数据的备份和恢复。 数据库结构对最终用户透明。

8.1.1 数据库设计的特点 数据库建设的基本规律 三分技术，七分管理，十二分基础数据 管理 数据库建设项目管理 企业（即应用部门）的业务管理 基础数据 收集、入库 更新的数据

8.1.1 数据库设计的特点 综合性 涉及面广，需包含计算机专业知识及业务系统专业知识； 要解决技术及非技术两方面的问题； 静态结构（数据）设计与动态行为（处理）设计是分离。 静态结构设计是指数据库的模式框架设计（包括语义结构（概念）、数据结构（逻辑）、存储结构（物理））； 动态行为设计是指应用程序设计（动作操纵：功能组织、流程控制）

8.1.1 数据库设计的特点 需求分析 数据分析 功能分析 概念模型设计 逻辑模型设计 物理数据库设计 加载数据库 功能模型 功能说明 事务设计 用户界面及程序设计 调试运行

8.1.2 数据库设计方法概述 规范设计法 新奥尔良（New Orleans）方法 将数据库设计分为若干阶段和步骤 基于E-R模型的数据库设计方法 概念设计阶段广泛采用 3NF（第三范式）的设计方法 逻辑阶段可采用的有效方法

8.1.2 数据库设计方法概述 新奥尔良（New Orleans）方法 需求说明 需求 分析 概念结构 概念结 构设计 逻辑结构 逻辑结 物理结构 物理 设计

8.1.3 数据库设计的基本步骤 需求分析 结构设计 概念结构设计 逻辑结构设计 物理结构设计 行为设计 （应用系统）功能设计 事务设计 用户界面及程序设计 数据库实施 数据库运行和维护

8.1.3 数据库设计的基本步骤 说明 需求分析和概念设计独立于任何数据库管理系统 逻辑设计和物理设计与选用的DBMS密切相关 数据库设计的准备工作--选定参加设计的人 系统分析人员、数据库设计人员：自始至终参与数据库设计。 用户和数据库管理员：主要参加需求分析和数据库的运行维护 应用开发人员（程序员和操作员）：在系统实施阶段参与进来，负责编制程序和准备软硬件环境。

数据库设计各个阶段的设计描述

8.1.3 数据库设计的基本步骤 设计一个完善的数据库应用系统往往是上述几个阶段的不断反复 把数据库设计和对数据库中数据处理的设计紧密结合起来 将这两个方面的需求分析、抽象、设计、实现在各个阶段同时进行，相互参照，相互补充，以完善两方面的设计

8.1.3 数据库设计的基本步骤 数据库设计不同阶段形成的数据库各级模式

8.2 数据库需求分析 分析用户的要求； 是数据库设计的起点； 其结果将直接影响到后面各阶段的设计； 并影响到最终的数据库系统能否被合理地使用。

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

8.2.1 需求分析的任务 调查的重点是“数据”和“处理”，获得用户对数据库要求 信息要求 处理要求 安全性与完整性要求

8.2.1 需求分析的任务 需求分析的难点 确定用户最终需求 用户缺少计算机知识 设计人员缺少用户的专业知识 解决方法 设计人员必须不断深入地与用户进行交流

8.2.2 需求分析方法 调查需求 业务现状 信息源流 外部要求:安全性、完整性要求等 达成共识 分析表达需求：数据流图、数据字典

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

8.3 数据库结构设计 数据库结构设计包括 设计数据库的概念结构 设计数据库的逻辑结构 设计数据库的存储结构

8.3.1 概念结构设计 什么是概念结构设计 将需求分析得到的用户需求抽象为信息结构即概念模型的过程就是概念结构设计 概念结构是各种数据模型的共同基础，它比数据模型更独立于DBMS 、更抽象，从而更加稳定 概念结构设计是整个数据库设计的关键

8.3.1 概念结构设计 现实世界 机器世界 信息世界 需求分析 概念结构设计

8.3.1 概念结构设计 概念模型的特点 有丰富的语义表达能力。 易于交流和理解。 易于更改。 易于向各种数据模型转换。

8.3.1 概念结构设计 概念结构设计的策略 自底向上。先定义局部应用的概念结构，然后按一定的规则把它们集成起来，从而得到全局概念模型。 自顶向下：先定义全局概念模型，然后再逐步细化。 由里向外：先定义最重要的核心结构，然后再逐步向外扩展。 混合策略。将自顶向下和自底向上结合起来使用。

自底向上

自顶向下地进行需求分析自底向上地设计概念结构

自顶向下

由里向外

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

8.3.1 概念结构设计 采用E-R模型方法的概念结构设计 设计局部E-R模型 将所有局部E-R图集成为一个全局E-R图，即全局E-R模型。 优化全局E-R模型

自底向上设计概念结构的步骤

8.3.1 概念结构设计 设计局部E-R模型 概念结构是对现实世界的一种抽象。 所谓抽象是对实际的人、物、事和概念进行人为处理，抽取所关心的共同特性，忽略非本质细节，并把这些特性用各种概念准确的加以描述。 一般有三种抽象方法： 分类 概括 聚集

8.3.1 概念结构设计 分类 定义某一类概念作为现实世界中一组对象的类型 抽象了对象值和型之间的“is member of”的语义

8.3.1 概念结构设计 概括 定义类型之间的一种子集联系 抽象了类型之间的“is subset of”的语义 继承性

8.3.1 概念结构设计 聚集 定义某一类型的组成成分 抽象了对象内部类型和成分之间“is part of”的语义

8.3.1 概念结构设计 复杂的聚集 某一类型的成分仍是一个聚集

8.3.1 概念结构设计 设计分E-R图的步骤 选择局部应用 逐一设计分E-R图

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

选择局部应用（续） 设计分E-R图的出发点

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

逐一设计分E-R图（续） 两条准则： 属性不能再具有需要描述的性质。即属性必须是不可分的数据项，不能再由另一些属性组成 属性不能与其他实体具有联系。联系只发生在实体之间

逐一设计分E-R图（续） 职称作为一个实体

逐一设计分E-R图（续） 病房作为一个实体

8.3.1 概念结构设计 设计全局E-R模型 各个局部视图即分E-R图建立好后，还需要对它们进行合并，集成为一个整体的数据概念结构即全局E-R图。 把局部E-R图集成为全局E-R图时，可以采用一次将所有的E-R图集成在一起的方式，也可以用逐步集成、进行累加的方式，即一次只集成少量几个E-R图，这样实现起来会比较容易些。

8.3.1 概念结构设计 多个分E-R图一次集成 一次集成多个分E-R图 通常用于局部视图比较简单时

8.3.1 概念结构设计 逐步集成 用累加的方式一次集成两个分E-R图

8.3.1 概念结构设计 集成局部E-R图的步骤 合并 修改与重构

8.3.1 概念结构设计

8.3.1 概念结构设计 各分E-R图存在冲突 合并分E-R图的主要工作与关键 各个分E-R图之间必定会存在许多不一致的地方

8.3.1 概念结构设计 冲突的种类 属性冲突 命名冲突 结构冲突

⒈ 属性冲突 两类属性冲突 属性域冲突 属性值的类型 取值范围 取值集合不同 属性取值单位冲突（如：斤、公斤）

⒉ 命名冲突 两类命名冲突 同名异义：不同意义的对象在不同的局部应用中具有相同的名字 异名同义（一义多名）：同一意义的对象在不同的局部应用中具有不同的名字

⒊ 结构冲突 三类结构冲突 同一对象在不同应用中具有不同的抽象（职工实体/属性？） 同一实体在不同分E-R图中所包含的属性个数和属性排列次序不完全相同 实体之间的联系在不同局部视图中呈现不同的类型

8.3.1 概念结构设计 消除不必要的冗余，设计生成基本E-R图 分E-R图 合并 初步E-R图 基本E-R图 可能存在冗余的数据 和冗余的实体间联系 基本E-R图 消除不必要的冗余

8.3.1 概念结构设计 冗余的数据是指可由基本数据导出的数据 冗余的联系是指可由其他联系导出的联系 冗余数据和冗余联系容易破坏数据库的完整性，给数据库维护增加困难 消除不必要的冗余后的初步E-R图称为基本E-R图

8.3.1 概念结构设计 优化全局E-R模型 实体个数尽可能少； 实体所包含的属性尽可能少； 实体间联系无冗余。

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

示例 n m 产品 产品号 性能参数 零件 零件号 价格 组成 零件个数 材料 零件 n m 材料号 材料类型 零件号 规格 使用 使用量 库存量 局部ER图

示例（续） 零件号 产品号 产品 m 组成 n 零件 规格 性能参数 m 价格 零件个数 使用 p 材料号 n 使用量 材料类型 材料 库存量 合并局部ER图

8.3.2 逻辑结构设计 步骤： 将概念模型转换为某种组织层数据模型； 对数据模型进行优化。

8.3.2 逻辑结构设计 E-R模型向关系模型的转换 一个实体转换为一个关系模式。实体的属性就是关系的属性，实体的码就是关系的码。 对于实体间的联系有以下不同的情况： 一个1：1联系可以转换为一个独立的关系模式。与该联系相连的各实体的码以及联系本身的属性均转换为关系的属性，每个实体的码均是该关系模式的候选码，可任选一个候选码作为主码。 一个1：n联系可以转换为一个独立的关系模式。与该联系相连的各实体的码以及联系本身的属性均转换为关系的属性，而关系的码为n端实体的码。 一个m：n联系转换为一个关系模式。与该联系相连的各实体的码以及联系本身的属性均转换为关系的属性，而关系的码为各实体码的组合。 三个或三个以上实体间的一个多元联系可以转换为一个关系模式。与该多元联系相连的各实体的码以及联系本身的属性均转换为此关系的属性，而此关系的码为各实体码的组合。 具有相同码的关系模式可以合并。

1:1转换示例 部门号 部门 部门名 部门表（部门号，部门名，经理号） 经理表（经理号，经理名，电话） 或者： 部门表（部门号，部门名） 管理 部门名 部门号 经理号 经理名 电话 部门表（部门号，部门名，经理号） 经理表（经理号，经理名，电话） 或者： 部门表（部门号，部门名） 经理表（经理号，部门号，经理名，电话）

1:n转换示例 部门号 部门 部门名 1 部门表（部门号，部门名） 职工表（职工号，部门号，职工名，工资） 工作 职工号 n 职工 职工名

m:n转换示例 教师表（教师号，教师名，职称） 课程表（课程号，课程名，学分） 授课表（教师号，课程号，授课时数） 教师号 职称 教师

ER模型到关系模型的转换实例 仓库（仓库号，仓库名，地址） 商店（商店号，商店名） 商品（商品号，商品名） 进货（商店号，商品名，仓库号，日期，数量） 零件（零件号，零件名，规格） 组成（零件号，子零件号，数量） 仓库 商品 商店 仓库号 仓库名 地址 数量 商店号 商品名 商品号 商店名 日期 进货 M N P 零件 零件号 零件名 规格 数量 组成 M N

8.3.2 逻辑结构设计 数据模型的优化 关系数据模型的优化通常以规范化理论为指导，并考虑系统的性能。具体方法为： 确定各属性间的数据依赖。 消除冗余的联系。 确定最合适的范式。 确定是否要对某些模式进行分解或合并 。 对关系模式进行必要的分解，以提高数据的操作效率和存储空间的利用率。

8.3.2 逻辑结构设计 水平分解 K# A1 … Am K# A1 … Am 以时间、空间、类型等范畴属性取值为条件，满足相同条件的数据行为一个子表。 分解的依据一般以范畴属性取值范围划分数据行。这样在操作同表数据时，时空范围相对集中，便于管理。 例如：学校学生情况的“学生情况表”，我们可以将其分解为“历史学生情况表”和“在册学生情况表”。 K# A1 … Am K# A1 … Am

8.3.2 逻辑结构设计 垂直分解 以非主属性所描述的应用对象生命历程的先后为条件，对应相同历程的属性为一个子表。 分解的依据是将非主属性按其数据生成的时间段划分，描述相同时间段的属性划分在一个组中。 使操作同表数据时时空范围相对集中，便于管理。 例如，可以将“学生情况表”拆为“学生基本信息表”、“学生家庭情况表” 。 K# A11 …A1m A21 … A2n K# A11 …A1m K# A21 … A2n

8.3.2 逻辑结构设计 设计外模式 定义外模式考虑事项 将概念模型转换为逻辑数据模型之后，还应该根据局部应用需求，并结合具体的数据库管理系统的特点，设计用户的外模式。 外模式概念对应关系数据库的视图概念，设计外模式是为了更好地满足局部用户的需求。 定义数据库的外模式主要是从系统的时间效率、空间效率、易维护等角度出发。 定义外模式考虑事项 使用更符合用户习惯的别名。 对不同级别的用户定义不同的视图，以保证数据的安全。 简化用户对系统的使用。

8.3.3 物理结构设计 对已确定的逻辑数据结构，利用DBMS提供的方法、技术，以较优的存储结构、数据存取路径、合理的数据存储位置以及存储分配，设计出一个高效的、可实现的物理数据库结构。 数据库的物理设计通常分为两步： 确定数据库的物理结构； 对物理结构进行时间和空间效率的评价。

1.物理结构设计的内容和方法 物理数据库设计的好，可以使各种事务的响应时间小、存储空间利用率高、事务吞吐量大。 在设计数据库时首先要对经常用到的查询和对数据进行更新的事务进行详细地分析，获得物理结构设计所需的各种参数。 要充分了解所使用的DBMS的内部特征，特别是系统提供的存取方法和存储结构。

1.物理结构设计的内容和方法 对于数据查询，需要得到如下信息： 查询所涉及的关系； 查询条件所涉及的属性； 连接条件所涉及的属性； 查询列表中涉及的属性。 对于更新数据的事务，需要得到如下信息： 更新所涉及的关系； 每个关系上的更新条件所涉及的属性； 更新操作所涉及的属性。

1.物理结构设计的内容和方法 确定存取方法 存取方法是快速存取数据库中的数据的技术，数据库管理系统一般都提供多种存取方法。具体采取哪种存取方法由系统根据数据的存储方式来决定，一般用户不能干预。 一般用户可以通过建立索引的方法来加快数据的查询效率。 建立索引的一般原则为： 在经常作为查询条件的属性上建立索引。 在经常作为连接条件的属性上建立索引。 在经常作为分组依据列的属性上建立索引。 对经常进行连接操作的表可以建立索引。 一个表可以建立多个索引，但只能建立一个聚簇索引。

8.3.3 物理结构设计 确定存储结构 物理结构设计中一个重要的考虑就是确定数据记录的存储方式。 一般的存储方式有： 顺序存储。这种存储方式的平均查找次数为表中记录数的1/2。 散列存储。这种存储方式的平均查找次数由散列算法决定。 聚簇存储。聚簇存储是指将不同类型的记录分配到相同的物理区域中，充分利用物理顺序性的优点，提高数据访问速度。即使经常在一起使用的记录聚簇在一起，以减少物理I/O次数。 一般情况下系统都会为数据选择一种最合适的存储方式。 用户可以通过建立索引的方法来改变数据的存储方式，其他情况下，数据是采用顺序存储还是散列存储。

2. 物理结构设计的评价 评价物理结构设计的方法完全依赖于具体的DBMS，主要考虑的是操作开销，即为使用户获得及时、准确的数据所需的开销和计算机的资源的开销。具体可分为如下几类： 查询和响应时间 更新事务的开销 生成报告的开销 主存储空间的开销 辅助存储空间的开销

8.4 数据库行为设计 数据库行为设计一般分为如下几个步骤： 功能需求分析； 功能设计； 事务设计； 应用程序实现。

8.4.1 功能需求分析 在进行需求分析时，主要进行两项工作，一项是“数据流”的调查分析，另一项是“事务处理”过程的调查分析。 数据流的调查分析为数据库的信息结构提供了最原始的依据， 事务处理的调查分析是行为设计的基础。 功能需求分析是在需求分析之后功能设计之前的一个步骤。

8.4.1 功能需求分析 对行为特性要进行的分析 标识所有的查询、报表、事务及动态特性，指出对数据库所要进行的各种处理； 指出对每个实体所进行的操作（增、删、改、查）； 给出每个操作的语义，包括结构约束和操作约束； 给出每个操作（针对某一对象）的频率； 给出每个操作（针对某一应用）的响应时间； 给出该系统总的目标。

8.4.2 功能设计 系统目标的实现是通过系统的各功能模块来达到的。由于每个系统功能又可以划分为若干个更具体的功能模块，因此，可以从目标开始，一层一层分解下去，直到每个子功能模块只执行一个具体的任务。 ¨¨ 目标 功能2 功能n 功能1 功能22 功能23 功能21

8.4.2 功能设计 例：“学籍管理”的功能结构图 学籍管理 录取分班 入学报到 … 录入 修改 查询 修课管理

8.4.3 事务设计 事务处理是计算机模拟人处理事务的过程，包括： 输入设计 输出设计 功能设计 等等

1.输入设计 在进行输入设计时应作如下几方面工作： 原始单据的设计格式。对于原有的单据，表格要根据新系统的要求重新设计，其设计的原则是：简单明了，便于填写，尽量标准化，便于归档，简化输入工作。 制成输入一览表。将全部功能所用的数据整理成表。 制作输入数据描述文档。包括数据的输入频率、数据的有效范围和出错校验。

2.输出设计 在输出设计时要考虑如下因素： 用途。区分输出结果是给客户的还是用于内部或报送上级领导的。 输出设备的选择。是仅仅显示出来，还是要打印出来或需要永久保存。 输出量。 输出格式。

8.5 数据库的实施和维护 完成数据库的结构设计和行为设计之后，下一步就需要利用DBMS提供的功能将数据库逻辑设计和物理设计的结果描述出来，然后再经过编写实现用户需求的应用程序，就可以将整个数据库系统投入运行了。这就是数据库的实施阶段。

8.5.1数据库数据的加载和试运行 数据加载 在数据库系统中，一般数据量都很大，各应用环境差异也很大 。 为了保证数据库中的数据正确、无误，必须十分重视数据的校验工作。 在将数据输入系统进行数据转换过程中，应该进行多次的校验。 对于重要的数据的校验更应该反复多次，确认无误后再进入到数据库中。

8.5.1数据库数据的加载和试运行 数据库的试运行 在有一部分数据加载到数据库之后，就可以开始对数据库系统进行联合调试了，这个过程又称为数据库试运行。 这一阶段要实际运行数据库应用程序，执行对数据库的各种操作，测试应用程序的功能是否满足设计要求。如果不满足，则要对应用程序进行修改、调整，直到达到设计要求为止。 在数据库试运行阶段，还要对系统的性能指标进行测试，分析其是否达到设计目标。

8.5.2 数据库的运行和维护 数据库投入运行标志着开发工作的基本完成和维护工作的开始，数据库只要存在一天，就需要不断地对它进行评价、调整和维护。 在数据库运行阶段，对数据库的经常性的维护工作主要由数据库系统管理员(DBA)完成，其主要工作包括： 数据库的备份和恢复 数据库的安全性和完整性控制 监视、分析、调整数据库性能 数据库的重组

本章小结 本章介绍了数据库设计的全部过程 数据库的设计包括需求分析、结构设计。 结构设计又分为概念结构设计、逻辑结构设计、物理结构设计。 概念结构设计是用概念模型来描述用户的业务需求； 逻辑设计是将概念设计的结果转换数据的组织模型； 物理结构设计是设计数据的存储方式和存储结构。 数据库的行为设计是对系统的功能需求的设计，一般设计思想是将大的功能模块划分为功能相对专一的小的功能模块，这样便于用户的使用和操作。 数据库设计完成后，是数据库的实施和维护。