国家“十一五”规划教材 数据库原理与应用教程(第3版)

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

8.1 数据库设计概述 8.1.1 数据库设计的特点 8.1.2 数据库设计方法概述 8.1.3 数据库设计的基本步骤

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

数据库设计的特点 数据库的结构设计在模式或外模式中定义。 数据库的行为设计在存取数据库的应用程序中设计和实现。 程序和数据不易结合。 数据库设计较为复杂。 结构设计和行为设计是分离进行的。

8.1.2 数据库设计方法概述 新奥尔良（New Orleans）方法 需求说明 需求 分析 概念结构 概念结 构设计 逻辑结构 逻辑结 物理结构结构 物理 设计 数据库设计方法从本质上看仍然是手工设计方法，其基本思想是过程迭代和逐步求精。

8.1.3 数据库设计的基本步骤 需求分析 结构设计 行为设计 数据库实施 数据库运行和维护

数据库设计全过程 运行和维护 需求分析 数据分析 功能分析 概念结构设计 逻辑结构设计 物理结构设计 加载数据 功能设计 事务设计 程序设计 调试运行

8.2 数据库需求分析 8.2.1 需求分析的任务 8.2.2 需求调查

8.2.1需求分析的任务 需求分析阶段的主要任务是对现实世界要处理的对象（公司，部门，企业）进行详细调查，在了解现行系统的概况、确定新系统功能的过程中，收集支持系统目标的基础数据及其处理方法。 需求分析是在用户调查的基础上，通过分析，逐步明确用户对系统的需求，包括数据需求和围绕这些数据的业务处理需求。

用户调查的重点是“数据”和“处理”。 信息需求 定义未来数据库系统用到的所有信息，明确用户将向数据库中输入什么样的数据，从数据库中要求获得哪些内容，将要输出哪些信息。同时还要描述数据间的联系等。 处理需求 定义了系统数据处理的操作功能，描述操作的优先次序，包括操作的执行频率和场合，操作与数据间的联系。处理需求还要明确用户要完成哪些处理功能，每种处理的执行频度，用户需求的响应时间以及处理的方式，比如是联机处理还是批处理，等等。 安全性与完整性要求 描述了系统中不同用户对数据库的使用和操作情况，完整性要求描述了数据之间的关联关系以及数据的取值范围要求。

数据处理流图 在需求分析中，通过自顶向下、逐步分解的方法分析系统。任何一个系统都可以抽象为数据流图的形式。 数据存储 数据源 数据输出 处理

8.3 数据库结构设计 8.3.1 概念结构设计 8.3.2 逻辑结构设计 8.3.3 物理结构设计

数据库设计分类 数据库设计分为：数据库结构设计和数据库行为设计。 结构设计包括设计数据库的概念结构、逻辑结构和存储结构。 行为设计包括设计数据库的功能组织和流程控制。

数据库结构设计过程 逻辑映象 综合与抽象 应用需求1 应用需求2 应用需求n 概念设计 逻辑设计 外模式1 外模式2 外模式m 内模式 … 应用需求1 应用需求2 应用需求n 概念设计 逻辑设计 外模式1 外模式2 外模式m 内模式 表示转换

数据库结构设计包含内容 概念结构设计：形成DB概念模式，用语义层模型描述，如E－R图 。 物理结构设计：形成DB内模式，用文件级术语描述。例DB文件或目录、索引。

8.3.1 概念结构设计 概念结构设计的任务是产生反映企业组织信息需求的数据库概念结构，即概念模型。

概念模型的特点 有丰富的语义表达能力。 易于交流和理解。 易于更改。 易于向各种数据模型转换，易于导出与DBMS有关的逻辑模型 。

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

采用E-R模型方法的概念结构设计 设计局部E-R模型 设计全局E-R模型 优化全局E-R模型

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

分类 学生 张三 李四 王五 … class （1）在相似的个体之间提取共性，建立“类”的概念（集合）。 Is a member of 个体与个体之间：具有相似的状态与行为，有相同的描述结构，相互用主码值区分。 个体与类之间：个体Is a member of 类（子类有且仅有一个超类）。 学生 张三 李四 王五 … class Is a member of

概括 学生 本科生 研究生 超类 子类 Is a subset of

聚集 学生 … 实体型 属性 学号 姓名 性别 Is a part of

设计全局E-R模型 将局部E-R图集成为全局E-R图； 需消除各分E-R图合并时产生的冲突； 解决冲突是合并E-R图的主要工作和关键所在。 冲突主要有三类： 属性冲突：属性域冲突、属性取值单位冲突 命名冲突：同名异义和异名同义 结构冲突：同一对象在不同应用中具有不同的抽象、同一实体在不同的局部E-R图中所包含的属性个数和属性的排列次序不完全相同。

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

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

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

8.3.2 逻辑结构设计 把概念结构设计阶段设计好的基本E-R模型转换为具体的数据库管理系统支持的数据模型，也就是导出特定的DBMS可以处理的数据库逻辑结构（数据库的模式和外模式），这些模式在功能、性能、完整性和一致性约束方面满足应用要求。 步骤： 将概念模型转换为某种组织层数据模型； 对数据模型进行优化。

E-R模型向关系模型的转换 一个实体转换为一个关系模式。实体的属性就是关系的属性，实体的标识符就是关系的码。 对于实体间的联系有以下不同的情况： 一个1：1联系可以转换为一个独立的关系模式，也可以与任意一端所对应的关系模式合并。 一个1：n联系可以转换为一个独立的关系模式，也可以与n端所对应的关系模式合并。 一个m：n联系转换为一个关系模式。 三个或三个以上实体间的一个多元联系可以转换为一个关系模式。 具有相同码的关系模式可以合并。

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

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

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

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

水平分解 以时间、空间、类型等范畴属性取值为条件，满足相同条件的数据行为一个子表。 分解的依据一般以范畴属性取值范围划分数据行。这样在操作同表数据时，时空范围相对集中，便于管理。 K# A1 … Am K# A1 … Am

垂直分解 以非主属性所描述的应用对象生命历程的先后为条件，对应相同历程的属性为一个子表。 分解的依据是将非主属性按其数据生成的时间段划分，描述相同时间段的属性划分在一个组中。 使操作同表数据时时空范围相对集中，便于管理。 K# A11 …A1m A21 … A2n K# A11 …A1m K# A21 … A2n

设计外模式 将概念模型转换为逻辑数据模型之后，还应该根据局部应用需求，并结合具体的数据库管理系统的特点，设计用户的外模式。 外模式概念对应关系数据库的视图概念，设计外模式是为了更好地满足局部用户的需求。 定义数据库的模式主要是从系统的时间效率、空间效率、易维护等角度出发。

定义外模式考虑事项 使用更符合用户习惯的别名。 对不同级别的用户定义不同的视图，以保证数据的安全。 简化用户对系统的使用。

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

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

确定存取方法 一般用户可以通过建立索引的方法来加快数据的查询效率。 建立索引的一般原则为： 一个表可以建立多个索引，但只能建立一个聚簇索引。 在经常作为查询条件的属性上建立索引。 在经常作为连接条件的属性上建立索引。 在经常作为分组依据列的属性上建立索引。 对经常进行连接操作的表可以建立索引。 一个表可以建立多个索引，但只能建立一个聚簇索引。

确定存储结构 一般的存储方式有： 顺序存储 散列存储 聚簇存储 一般情况下系统都会为数据选择一种最合适的存储方式。

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

8.4 数据库行为设计 8.4.1 功能需求分析 8.4.2 功能设计 8.4.3 事务设计

8.4.1 功能需求分析 在进行需求分析时，实际上进行了两项工作: 数据流的调查分析为数据库的信息结构提供了最原始的依据， “数据流”的调查分析， “事务处理”过程的调查分析。 数据流的调查分析为数据库的信息结构提供了最原始的依据， 事务处理的调查分析是行为设计的基础。

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

示例 教师退休行为的操作特征为： 该教师没有未教授完的课程。 删除此教师记录。 此教师记录不再在当前教师表中。

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

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

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

输入设计 原始单据的设计格式 制成输入一览表 制作输入数据描述文档

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

8.5 数据库实施 加载数据 调试和运行应用程序

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

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

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

数据库的备份和恢复 要对数据库进行定期的备份，一旦出现故障，要能及时地将数据库恢复到尽可能的正确状态，以减少数据库损失。

数据库的安全性和完整性控制 随着数据库应用环境的变化，对数据库的安全性和完整性要求也会发生变化。如： 收回某些用户的权限， 增加、修改某些用户的权限， 增加、删除用户， 数据的取值范围发生变化等。 这都需要系统管理员对数据库进行适当的调整，以反映这些新的变化。

监视、分析、调整数据库性能 监视数据库的运行情况，并对检测数据进行分析，找出能够提高性能的可行性，并适当地对数据库进行调整。 目前有些DBMS产品提供了性能检测工具，数据库系统管理员可以利用这些工具很方便地监视数据库。

数据库的重组 数据库经过一段时间的运行后，随着数据的不断添加、删除和修改，会使数据库的存取效率降低，数据库管理员可以改变数据库数据的组织方式， 通过增加、删除或调整部分索引等方法，改善系统的性能。 数据库的重组并不改变数据库的逻辑结构。