本文属于「数据库系统」系列文章之一，这一系列着重于「数据库系统知识的学习与实践」。由于文章内容随时可能发生更新变动，欢迎关注和收藏数据库系统系列文章汇总目录一文以作备忘。需要特别说明的是，为了透彻理解和全面掌握数据库系统，本系列文章中参考了诸多博客、教程、文档、书籍等资料，限于时间精力有限，这里无法一一列出。部分重要资料的不完全参考目录如下所示，在后续学习整理中还会逐渐补充：

数据库系统概念第六版 Database System Concepts, Sixth Edition ，作者是 Abraham Silberschatz, Henry F. Korth, S. Sudarshan ，机械工业出版社

数据库系统概论第五版，王珊萨师煊编著，高等教育出版社

文章目录

本章参考文献
7.1 数据库设计概述
- 7.1.1 数据库设计的特点
- - 1. 数据库建设的基本规律
  - 2. 结构（数据）设计和行为（处理）设计相结合
- 7.1.2 数据库设计方法
- 7.1.3 数据库设计的基本步骤
- 7.1.4 数据库设计过程中的各级模式
7.2 需求分析
- 7.2.1 需求分析的任务
- 7.2.2 需求分析的方法
- 7.2.3 数据字典
- - 1. 数据项
  - 2. 数据结构
  - 3. 数据流
  - 4. 数据存储
  - 5. 处理过程
7.3 概念结构设计
7.4 逻辑结构设计
- 7.4.1 E-R图向关系模型的转换
- 7.4.2 数据模型的优化
- 7.4.3 设计用户子模式
7.5 物理结构设计
- 7.5.1 数据库物理设计的内容和方法
- 7.5.2 关系模式存取方法
- - 1. B+树索引存取方法的选择
  - 2. 哈希索引存取方法的选择
  - 3. 聚簇存取方法的选择
- 7.5.3 确定数据库的存储结构
- - 1. 确定数据的存放位置
  - 2. 确定系统配置
- 7.5.4 评价物理结构
7.6 数据库的实施和维护
- 7.6.1 数据的载入和应用程序的调试
- 7.6.2 数据库的试运行
- 7.6.3 数据库的运行和维护
- - 1. 数据库的转储和恢复
  - 2. 数据库的安全性、完整性控制
  - 3. 数据库性能的监督、分析和改造
  - 4. 数据库的重组织与重构造

本章讨论数据库设计的技术与方法，详细介绍了数据库设计各个阶段的目标、方法以及应注意的事项。主要讨论基于关系数据库管理系统的关系数据库设计问题。

本章参考文献

7.1 数据库设计概述

在数据库领域内，通常把使用数据库的各类信息系统都称为数据库应用系统。例如，以数据库为基础的各种管理信息系统 MIS 、办公自动化系统、地理信息系统、电子政务系统、电子商务系统等。

数据库设计，广义地说是「数据库及其应用系统的设计」，即设计整个数据库应用系统；狭义地讲，是「设计数据库本身」，即设计数据库的各级模式并建立数据库，这也是数据库应用系统设计的一部分。本文重点是讲解狭义的数据库设计。当然，设计一个好的数据库与设计一个好的数据库应用系统是密不可分的，一个好的数据库结构是应用系统的基础，特别是在实际的系统开发项目中，二者更是密切相关、并行进行的。

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

信息管理要求是指，在数据库中应该存储和管理哪些数据对象；
数据操作要求是指，对数据对象需要进行哪些操作，如查询、增、删、改、统计等操作。

数据库设计的目标是「为用户和各种应用系统提供一个信息基础设施和高效的运行环境」。高效的运行环境指，数据库数据的存取效率、数据库存储空间的利用率、数据库系统运行管理的效率等都是高的。

7.1.1 数据库设计的特点

大型数据库的设计和开发，是一项庞大的工程，是涉及多学科的综合性技术。数据库建设是指，数据库应用系统从设计、实施到运行与维护的全过程，数据库建设与一般软件系统的设计、开发和运行与维护有许多相同之处（软件工程学习与实践系列文章汇总目录），更有其自身的一些特点。

1. 数据库建设的基本规律

三分技术、七分管理、十二分基础数据是数据库设计的特点之一。即数据库建设中，不仅涉及技术，还涉及管理。要建设好一个数据库应用系统，开发技术固然重要，但是相比之下管理更加重要。这里的管理不仅仅包括「数据库建设作为一个大型的工程项目本身」的项目管理，还包括该企业（即应用部门）的业务管理。

企业的业务管理更加复杂、也更重要，对数据库结构的设计有直接影响。因为数据库结构（即数据库模式）就是对企业中业务部门数据、以及各业务部门之间的数据联系（和各部门的职能、整个企业的管理模式密切相关）的描述和抽象。

人们在数据库建设的长期实践中，深刻认识到：一个企业数据库建设的过程，是企业管理模式的改革和提高的过程。只有把企业的管理创新做好，才能实现技术创新并建设好一个数据库应用系统。

十二分基础数据则强调了，数据的收集、整理、组织和不断更新，是数据库建设中的重要环节。许多人往往忽视基础数据在数据库建设中的地位和作用。基础数据的收集、入库是数据库建立初期工作量最大、最繁琐、也最细致的工作。在以后数据库的运行过程中，更需要不断把新数据加到数据库中，把历史数据加入数据仓库中，以便分析挖掘、改进业务管理、提高企业竞争力。

2. 结构（数据）设计和行为（处理）设计相结合

数据库设计应该与应用系统设计相结合，这是数据库设计的特点之二，即整个设计过程中，要把「数据库结构设计」和「对数据的处理设计」密切结合起来。

在早期的数据库应用系统开发过程中，常常把数据库设计和应用系统的设计分离开来，如下图所示。由于数据库设计有其专门的技术和理论，因此需要专门讲解数据库设计。但这并不等于数据库设计和在数据库之上开发应用系统是相互分离的，相反，必须强调设计过程中、数据库设计和应用系统设计的密切结合，并把它作为数据库设计的重要特点。

传统的软件工程，忽视了对应用中数据语义的分析和抽象。例如，结构化设计 Structure Design, SD 方法和逐步求精的方法，着重于处理过程的特性，只要有可能就尽量推迟数据结构设计的决策。这种方法对于数据库的设计显然是不妥的。
早期的数据库设计，致力于数据模型和数据库建模方法的研究，着重结构特性的设计，而忽视了行为设计对结构设计的影响，这种方法也是不完善的。

我们强调，在数据库设计中，要把结构特性和行为特性结合起来。

7.1.2 数据库设计方法

大型数据库设计是涉及多学科的综合性技术，又是一项庞大的工程项目。它要求从事数据库设计的专业人员，具备多方面的知识和技术，主要包括：

计算机的基础知识；
程序设计的方法和技巧；
软件工程的原理和方法；
数据库的基本知识；
数据库设计技术；
应用领域的知识

只有这样，才能设计出符合具体领域要求的数据库及其应用系统。

早期数据库设计，主要采用手工与经验相结合的方法，设计质量往往与设计人员的经验和水平有直接的关系。数据库设计是一项技艺，缺乏科学理论和工程方法的支持，设计质量难以保证。常常是数据库运行一段时间后、又不同程度地发现各种问题，需要进行修改并重新设计，增加了系统维护的代价。

为此，人们努力探索并提出了各种数据库设计方法。例如，新奥尔良 New Orleans 方法、基于E-R模型的设计方法、3NF（第三范式）的设计方法、面向对象的数据库设计方法、统一建模语言 Unified Model Language, UML 方法等。

数据库工作者也一直在研究和开发数据库设计工具（数据库设计工具有哪些？）。经过多年的努力，数据库设计工具已经实用化和产品化。这些工具软件可以辅助设计人员，完成数据库设计过程中的很多任务，已经普遍地用于大型数据库设计之中。

7.1.3 数据库设计的基本步骤

按照结构化系统设计的方法，考虑数据库及其应用系统开发全过程，将数据库设计分为以下六个阶段（如下图所示），设计一个完善的数据库应用系统不是一蹴而就的，它往往是这六个阶段的不断反复：

需求分析阶段：进行数据库设计，首先必须了解与分析用户需求（包括数据与处理）。需求分析是整个设计过程的基础，是最困难和最耗费时间的一步。作为地基的需求分析是否做得充分与准确，决定了在其上构建数据库大厦的速度与质量。需求分析做得不好，可能导致整个数据库设计返工重做。
概念设计阶段：概念结构设计是整个数据库设计的关键，它通过对用户需求进行综合、归纳和抽象，形成一个独立于具体数据库管理系统的概念模型。
逻辑设计阶段：这一阶段，将概念结构转换为某个数据库管理系统所支持的数据模型，并对其进行优化。
物理设计阶段：为逻辑数据模型，选取一个最适合应用环境的物理结构（包括存储结构和存取方法）。
数据库实施阶段：在数据库实施阶段，设计人员运用数据库管理系统提供的数据库语言及其宿主语言，根据逻辑设计和物理设计的结果建立数据库，编写与调试应用程序，组织数据入库，并进行试运行。
数据库运行和维护阶段：数据库应用系统经过试运行后，即可投入正式运行。在数据库系统运行过程中，必须不断地对其进行评估、调整与修改。

在数据库设计过程中，需求分析和概念结构设计，可以独立于任何数据库管理系统进行；逻辑结构设计和物理结构设计，则与选用的数据库管理系统密切相关。

数据库设计开始之前，首先必须选定参加设计的人员，包括系统分析人员、数据库设计人员、应用开发人员、数据库管理员和用户代表：

系统分析和数据库设计人员是数据库设计的核心人员，将自始至终参与数据库设计，其水平决定了数据库系统的质量。
用户和数据库管理员在数据库设计中，也是举足轻重的，主要参加需求分析和数据库系统的运行与维护，其积极参与（不仅仅是配合）不仅能加速数据库设计，而且也是决定数据库设计质量的重要因素。
应用开发人员（包括程序员和操作员），分别负责编制程序和准备软硬件环境，他们在系统实施阶段参与进来。

如果设计的数据库应用系统比较复杂，还应该考虑是否需要使用数据库设计工具、以及选用何种工具，以提高数据库设计质量，并减少设计工作量。

需要指出的是，这个设计步骤既是数据库设计的过程，也包括了数据库应用系统的设计过程。在设计过程中，把数据库的设计、和对数据库中数据处理的设计紧密结合起来，将两个方面的需求分析、抽象、设计、实现在各个阶段同时进行，相互参照、相互补充，以完善两方面的设计。事实上，如果不了解应用环境对数据的处理要求，或没有考虑如何去实现这些处理要求，是不可能设计一个良好的数据库结构的。

有关处理特性的设计描述，包括设计原理、采用的设计方法及工具等，在软件工程和信息系统设计的课程中有详细介绍，这里不再赘述。下图概括地给出了，设计过程中各个阶段关于数据特性的设计描述：

7.1.4 数据库设计过程中的各级模式

按照7.1.3小节的设计过程，数据库设计的不同阶段，形成数据库的各级模式。如下图所示：

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

下文以设计过程为主线，讨论数据库各阶段的设计内容、设计方法和工具。

7.2 需求分析

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

7.2.1 需求分析的任务

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

调查的重点是“数据”和“处理”，通过调查、收集和分析，获得用户对数据库的如下要求：
（1）信息要求。指用户需要从数据库中获得信息的内容与性质。由信息要求可以导出数据要求，即在数据库中需要存储哪些数据；
（2）处理要求。指用户要完成的数据处理功能，对处理性能的要求；
（3）安全性与完整性要求；

确定用户的最终需求是一件很困难的事，这是因为一方面用户缺少计算机知识，开始时无法确定计算机究竟能为自己做什么、不能做什么，因此往往不能准确地表达自己的需求，所提出的需求往往不断地变化。另一方面，设计人员缺少用户的专业知识，不易理解用户的真正需求、甚至误解用户的需求。因此，设计人员必须不断深入地与用户交流，才能逐步确定用户的实际需求。

7.2.2 需求分析的方法

进行需求分析，首先是调查清楚用户的实际需求，与用户达成共识，然后分析与表达这些需求。调查用户需求的具体步骤是：
（1）调查组织机构情况。包括了解该组织的部门组成情况、各部门的职责等，为分析信息流程做准备。
（2）调查各部门的业务活动情况。包括了解各部门输入和使用什么数据，如何加工处理这些数据，输出什么信息，输出到什么部门，输出结果的格式是什么等，这是调查的重点。
（3）在熟悉业务活动的基础上，协助用户明确对新系统的各种要求，包括信息要求、处理要求、完整性与安全性要求，这是调查的又一个重点。
（4）确定新系统的边界。对前面调查的结果进行初步分析，确定哪些功能由计算机完成、或将来准备让计算机完成，哪些活动由人工完成。由计算机完成的功能，就是新系统应该实现的功能。

在调查过程中，可根据不同的问题和条件，使用不同的调查方法。常用的调查方法有：
（1）跟班作业。通过亲身参加业务工作来了解业务活动的情况。
（2）开调查会。通过与用户座谈，了解业务活动情况及用户需求。
（3）请专人介绍。
（4）询问。对某些调查中的问题，可以找专人询问。
（5）设计调查表，请用户填写。如果调查表设计得合理，这种方法是很有效的。
（6）查阅记录。查阅与原系统有关的数据记录。
做需求调查时，往往需要同时采用上述多种方法，但无论使用何种调查方法，都必须有用户的积极参与和配合。

调查了解用户需求后，还需要进一步分析和表达用户的需求。在众多分析方法中，结构化分析 Structured Analysis, SA 方法是一种简单实用的方法。SA方法从最上层的系统组织机构入手，采用自顶向下、逐层分解的方式分析系统。

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

7.2.3 数据字典

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

数据字典通常包括数据项、数据结构、数据流、数据存储和处理过程几部分，其中数据项是数据的最小组成单位，若干个数据项可以组成一个数据结构。数据字典通过对数据项和数据结构的定义来描述数据流、数据存储的逻辑内容。

1. 数据项

数据项是不可再分的数据单位。对数据项的描述通常包括以下内容：

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

其中，“取值范围”、“与其他数据项的逻辑关系”（如该数据项等于其他几个数据项的和、该数据项等于另一数据项等）定义了数据的完整性约束条件，是设计数据检验功能的依据。

可以用关系规范化理论为指导，用「数据依赖」的概念分析和表示「数据项之间的联系」，即按实际语义写出每个数据项之间的数据依赖，它们是数据库逻辑设计阶段进行数据模型优化的依据。

2. 数据结构

数据结构反映了数据之间的组合关系。一个数据结构可由若干个数据项组成，也可以由若干个数据结构组成，或由若干个数据项和数据结构混合组成。对数据结构的描述通常包括以下内容：

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

3. 数据流

数据流是数据结构在系统内传输的路径。对数据流的描述通常包括以下内容：

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

其中，“数据流来源”是说明该数据流来自哪个过程；“数据流去向”是说明该数据流将到哪个过程去；“平均流量”是指在单位时间（每天、每周、每月等）里的传输次数；“高峰期流量”则是指在高峰时期的数据流量。

4. 数据存储

数据存储是数据结构停留或保存的地方，也是数据流的来源和去向之一。它可以是手工文档或凭单，也可以是计算机文档。对数据存储的描述通常包括以下内容：

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

其中，“存取频度”是指每小时、每天或每周存取次数，及每次存取的数据量等信息；“存取方式”指是批处理还是联机处理、是检索还是更新、是顺序检索还是随机检索等；另外，“输入的数据流”要指出其来源；“输出的数据流”要指出其去向。

5. 处理过程

处理过程的具体处理逻辑一般用判定表或判定树来描述。数据字典中，只需要描述处理过程的说明性信息即可，通常包括以下内容：

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

其中，“简要说明”主要说明该处理过程的功能及处理要求。功能是指，该处理过程用来做什么（而不是怎么做），处理要求指处理频度要求，如单位时间里处理多少事务、多少数据量、响应时间要求等。这些处理要求是后面物理设计的输入及性能评价的标准。

明确地把需求收集和分析，作为数据库设计的第一阶段是十分重要的。这一阶段收集到的基础数据（用数据字典来表达），是下一步进行概念设计的基础。

最后，要强调两点：
（1）需求分析阶段的一个重要而困难的任务是收集将来应用所涉及的数据。设计人员应充分考虑到可能的扩充和改变，使设计易于更改、系统易于扩充。
（2）必须强调用户的参与，这是数据库应用系统设计的特点。数据库应用系统和广泛的用户有密切的联系，许多人要使用数据库，数据库的设计和建立，又可能对更多人的工作环境产生重要影响。因此，用户的参与是数据库设计不可分割的一部分。在数据分析阶段，任何调查研究没有用户的积极参与，都是寸步难行的。设计人员应该和用户取得共同的语言，帮助不熟悉计算机的用户建立数据库环境下的共同概念，并对设计工作的最后结果承担共同的责任。

7.3 概念结构设计

【数据库系统】第二部分设计与应用开发(7) 数据库设计(3) 概念结构设计

7.4 逻辑结构设计

概念结构是独立于任何一种数据模型的信息结构。逻辑结构设计的任务，就是把概念设计阶段设计好的基本E-R图，转换为与「选用的数据库管理系统产品所支持的数据模型」相符合的逻辑结构。由于目前的数据库应用系统，基本上都采用支持关系数据模型的关系DBMS，所以这里只介绍E-R图向关系数据模型的转换原则与方法。

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

E-R图向关系模型的转换，要解决的问题是，如何将「实体型和实体间的关系」转换为「关系模式」，如何确定这些关系模式的属性和键。注意，因为扩展E-R模型是选学的，本节不包括扩展E-R图的集成以及向关系模型的转换。

关系模型的逻辑结构是「一组关系模式的集合」。E-R图则是由实体型、实体的属性和实体型之间的联系三个要素组成的，所以将E-R图转换为关系模型，实际上就是要将实体型、实体的属性和实体型之间的联系转换为关系模式。下面将介绍转换的一般原则，一个实体型转换为一个关系模式，实体的属性就是关系的属性，实体的键就是关系的键。

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

如果转换为一个独立的关系模式：
- 关系的属性：与该联系相连的各实体的键、以及联系本身的属性，均转换为关系的属性；
- 关系的候选键：每个实体的键均是该关系的候选键
如果与某一端实体对应的关系模式合并：
- 合并后关系的属性：在该关系模式的属性中，加入另一个关系模式的键和联系本身的属性；
- 合并后关系的键：不变

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

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

（3）一个 m : n m:n m:n 联系转换为一个关系模式。与该联系相连的各实体的键、以及联系本身的属性，均转换为关系的属性；各实体的键组成关系的键或关系键的一部分。

（4）三个或三个以上实体间的一个多元联系，可转换成一个关系模式。与该多元联系相连的各实体的键、以及联系本身的属性，均转化为关系的属性，各实体的键组成关系的键或关系键的一部分。

（5）具有相同码的关系模式，可以合并，目的也是减少系统中的关系个数。合并方法是：

将其中一个关系模式的全部属性，加入到另一个关系模式中；
然后去掉其中的同义属性（可能同名，也可能不同名）；
适当调整属性的次序

下面把图7.28中的E-R图转换为关系模型，关系的键用下划线标出。

部门（部门号，部门名，经理的职工号，……）：此为部门实体对应的关系模式，该关系模式已包含了联系“领导”所对应的关系模式，经理的职工号是关系的候选键。
职工（职工号，部门号，职工名，职务，……）：此为职工实体对应的关系模式。该关系模式已包含了联系“属于”所对应的关系模式。
产品（产品号，产品名，产品组长的职工号，……）：此为产品实体对应的关系模式。
供应商（供应商号，姓名，……）：此为供应商实体对应的关系模式。
零件（零件号，零件名，……）：此为零件实体对应的关系模式。
参加（职工号，产品号，工作天数，……）：此为联系“参加”所对应的关系模式。
供应（产品号，供应商号，零件号，供应量，……）：此为联系“供应”所对应的关系模式。

7.4.2 数据模型的优化

数据库逻辑设计的结果不是唯一的。为了进一步提高数据库应用系统的性能，还应该根据应用需要，适当地修改、调整数据模型的结构，这就是数据模型的优化。关系数据模型的优化，通常以规范化理论为指导，方法为：
（1）确定数据依赖。在7.2.3“数据字典”一节中已讲到，用数据依赖的概念分析和表示数据项之间的联系，写出每个数据项之间的数据依赖。按需求分析阶段所得到的语义，分别写出每个关系模式内部各属性之间的数据依赖，以及不同关系模式属性之间的数据依赖。
（2）对于各个关系模式之间的数据依赖，进行极小化处理，消除冗余的联系，具体方法见7.3.5“概念结构设计”一节。
（3）按照数据依赖的理论，对关系模式逐一分析，考察是否存在部分函数依赖、传递函数依赖、多值依赖等，确定各关系模式分别属于第几范式。
（4）根据需求分析阶段得到的处理要求，分析对于这样的应用环境、这些模式是否合适，确定是否要对某些模式进行合并或分解。必须注意的是，并不是规范化程度越高的关系就越优。例如：

当查询频繁涉及两个或多个关系模式的属性时，系统经常进行连接运算。连接运算的代价是相当高的，可以说关系模式低效的主要原因就是由连接运算引起的。这时，可考虑将这几个关系合并为一个关系，因为在这种情况下，第二范式甚至第一范式也许是合适的。
又如，非BCNF的关系模式，虽然从理论上分析会存在不同程度的更新异常或冗余，但如果在实际应用中对此关系模式只是查询，并不执行更新操作，则不会产生实际影响。所以，对于一个具体应用来说，到底规划化到什么程度，需要权衡响应时间和潜在问题二者的利弊来决定。

（5）对关系模式进行必要分解，提高数据操作效率和存储空间利用率。常用的两种分解方法是水平分解和垂直分解：

水平分解是把（基本）关系的元组分为若干子集合，定义每个子集合为一个子关系，以提高系统的效率。根据80/20原则，一个大关系中，经常被使用的数据只是关系的一部分、约占20%，可以把经常使用的数据分解出来，形成一个子关系。如果关系 R R R 上具有 n n n 个事务，而且多数事务存取的数据不相交，则 R R R 可分解为少于或等于 n n n 个子关系，使每个事务存取的数据对应一个关系。
垂直分解是把关系模式 R R R 的属性分解为若干子集合，形成若干子关系模式。垂直分解的原则是，将经常在一起使用的属性从 R R R 中分解出来，形成一个子关系模式。垂直分解可提高某些事务的效率，但也可能使另一些事务不得不执行连接操作，从而降低了效率。因此，是否进行垂直分解，取决于分解后 R R R 上的所有事务的总效率是否得到了提高。垂直分解需要确保无损连接性和保持函数依赖，即保证分解后的关系具有无损连接性、保持函数依赖性。这可用第6章中的模式分解算法，对需要分解的关系模式进行分解和检查。

规范化理论为数据库设计人员判断关系模式的优劣，提供了理论标准，可用来预测模式可能出现的问题，使数据库设计工作有了严格的理论基础。

7.4.3 设计用户子模式

将概念模型转换为全局逻辑模型后，还应该根据局部应用需求、结合具体关系DBMS的特点，设计用户的外模式。目前，关系DBMS一般都提供了视图概念，可利用这一功能，设计更符合局部用户需要的用户外模式。

定义数据库全局模式时，我们主要是从系统的时间效率、空间效率、维护代价等角度出发。由于用户外模式与模式是相对独立的，因此在定义用户外模式时，可注重考虑用户的习惯与方便。具体包括以下几个方面：
（1）使用更符合用户习惯的别名。在合并各分E-R图时，曾做过消除命名冲突的工作，以使数据库系统中同一关系和属性具有唯一的名字。这在设计数据库整体结构时，是非常必要的。用视图机制可在设计用户视图时，重新定义某些属性名，使其与用户习惯一致，以方便使用。
（2）可对不同级别的用户定义不同的视图，以保证系统的安全性。假设有关系模式——产品（产品号，产品名，规格，单价，生产车间，生产负责人，产品成本，产品合格率，质量等级），可在产品关系上建立以下两个视图，防止用户非法访问本来不允许其查询的数据，保障系统的安全性：

为一般顾客建立视图——产品1（产品号，产品名，规格，单价）：顾客视图中只包含允许顾客查询的属性；
为产品销售部门建立视图——产品2（产品号，产品名，规格，单价，生产车间，生产负责人）：销售部门视图中，只包含允许销售部门查询的属性；
生产部门领导则可查询全部产品数据。

（3）简化用户对系统的使用。某些局部应用中，经常要使用某些很复杂的查询。为了方便用户，可将这些复杂查询定义为视图，用户每次只对定义好的视图进行查询，大大简化了用户的使用。

7.5 物理结构设计

数据库在物理设备上的存储结构与存取方法，称为数据库的物理结构，它依赖于选定的数据库管理系统。为一个「给定的逻辑数据模型」选取一个「最适合应用要求的物理结构」的过程，就是数据库的物理设计。

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

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

不同的数据库产品所提供的物理环境、存取方法和存储结构有很大差别，能供设计人员使用的设计变量、参数范围也很不相同，因此没有通用的物理设计方法可遵循，只能给出一般的设计内容和原则。

希望设计优化的物理数据库结构，使得在数据库上运行的各种事务响应时间小、存储空间利用率高、事务吞吐率大。为此，首先对要运行的事务进行详细分析，获得物理数据库设计所需要的参数；其次，要充分了解所用关系DBMS的内部特征，特别是系统提供的存取方法和存储结构。

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

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

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

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

除此之外，还需要知道每个事务在各关系上运行的频率和性能要求。例如，事务 T T T 必须在10秒内结束，这对于存取方法的选择具有重大影响。上述这些信息，就是确定关系的存取方法的依据。

应注意的是，数据库上运行的事务会不断变化，增加或减少，以后需要根据上述设计信息的变化，调整数据库的物理结构。

通常来说，关系数据库物理设计的内容，主要包括为关系模式选择存取方法，以及设计关系、索引等数据库文件的物理存储结构。下面介绍这些内容。

7.5.2 关系模式存取方法

数据库系统是多用户共享的系统，对同一个关系要建立多条存取路径，才能满足多用户的多种应用要求。物理结构设计的任务之一就是，根据关系DBMS支持的存取方法，确定选择哪些存取方法。

存取方法是快速存取数据库中数据的技术。数据库管理系统一般提供多种存取方法。常见的存取方法为索引方法和聚簇方法 clustering 。 B + B^+ B+ 树索引和 h a s h hash hash 索引是数据库中经典的存取方法，使用最普遍。

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

所谓选择索引存取方法，实际上就是根据应用要求，确定对关系的哪些属性列建立索引、哪些属性列建立联合索引、哪些索引要设计为唯一索引等。一般来说：

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

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

2. 哈希索引存取方法的选择

选择哈希存取方法的规则如下：如果一个关系的属性，主要出现在「等值连接条件」中、或主要出现在「等值比较选择条件」中，而且满足下列两个条件之一，则此关系可以选择哈希存取方法：
（1）一个关系的大小可预知，而且不变；
（2）关系的大小动态改变，但是数据库管理系统提供了动态 hash 存取方法。

3. 聚簇存取方法的选择

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

聚簇功能可以大大提高按聚簇键进行查询的效率。例如，要查询信息系的所有学生名单，设信息系有 500 500 500 名学生，在极端情况下，这 500 500 500 名学生所对应的数据元组，分布在 500 500 500 个不同的物理块上。尽管对学生关系已按所在系建有索引，由索引很快找到信息系学生的元组标识，避免了全表扫描。然而在由元组标识、去访问数据块时，还要存取 500 500 500 个物理块，执行 500 500 500 次I/O操作……如果将同一系的学生元组集中存放，则每读一个物理块可得到多个满足查询条件的元组，从而显著减少了访问磁盘的次数。

聚簇功能不但适用于单个关系，也适用于经常进行连接操作的多个关系。即把多个连接关系的元组、按连接属性值聚集存放。这就相当于把多个关系按「预连接」的形式存放，从而大大提高连接操作的效率。

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

首先设计候选聚簇，一般来说：
（1）对经常在一起进行连接操作的关系，可以建立聚簇；
（2）如果一个关系的一组属性，经常出现在相等比较条件中，则该单个关系可建立聚簇；
（3）如果一个关系的一个（或一组）属性上的值重复率很高，则此单个关系可建立聚簇。注意，对应每个聚簇键值的平均元组数不能太少，太少则聚簇的效果不明显。
然后检查候选聚簇中的关系，取消其中不必要的关系。
（1）从聚簇中删除经常进行全表扫描的关系；
（2）从聚簇中删除更新操作远多于连接操作的关系；
（3）不同的聚簇中可能包含相同的关系，一个关系可以在某个聚簇中，但不能同时加入多个聚簇。要从这多个聚簇方案（包括不建立聚簇）中选择一个较优的，即在这个聚簇上运行各种事务的总代价最小。

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

因此，当通过聚簇键进行访问、或连接是该关系的主要应用，与聚簇键无关的其他访问很少或者是次要的，这时可以使用聚簇。尤其当SQL语句中，包含有与聚簇键有关的 order by, group by, union, distinct 等子句或短语时，使用聚簇特别有利，可以省去对结果集的排序操作；否则很可能会适得其反。

7.5.3 确定数据库的存储结构

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

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

1. 确定数据的存放位置

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

例如，目前很多计算机有多个磁盘或磁盘阵列，因此：

可将表和索引放在不同的磁盘上，在查询时由于磁盘驱动器并行工作，可以提高物理I/O读写的效率；
也可将比较大的表分放在两个磁盘上，以加快存取速度，这在多用户环境下特别有效；
还可以将日志文件与数据库对象（表、索引等）放在不同的磁盘上，以改进系统的性能。

由于各个系统所能提供的、对数据进行物理安排的手段、方法差异很大，因此设计人员应仔细了解，给定的关系DBMS提供的方法和参数，针对应用环境的要求，对数据进行适当的物理安排。

2. 确定系统配置

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

系统配置变量很多。例如，同时使用数据库的用户数、同时打开的数据库对象数、内存分配参数、缓冲区分配参数（使用的缓冲区长度、个数等）、存储分配参数、物理块的大小、物理块装填因子、时间片大小、锁的数目等。这些参数值影响存取时间和存储空间的分配，在物理设计时就要根据应用环境、确定这些参数值，以使系统性能最佳。

在物理设计时，我们对系统配置变量的调整只是初步的，在系统运行时还要根据实际运行情况，做进一步的调整，以期切实改进系统性能。

7.5.4 评价物理结构

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

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

7.6 数据库的实施和维护

完成数据库的物理设计之后，设计人员就要用关系DBMS提供的数据定义语言，以及其他实用程序，将数据库逻辑设计和物理设计结果严格描述出来，成为关系DBMS可以接受的源代码，再经过调试产生目标模式，然后就可以组织数据入库了，这就是数据库实施阶段。

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

数据库实施阶段包括两项重要的工作，一项是数据的载入，另一项是应用程序的编码和调试。

一般的数据库系统中数据量都很大，而且数据来源于部门中的各个不同的单位，数据的组织方式、结构和格式，都与新设计的数据库系统有相当的差距。组织数据载入，就要将各类源数据从各个局部应用中抽取出来、输入计算机，再分类转换，最后综合成符合新设计的数据库结构的形式、输入数据库。因此，这样的数据转换、组织入库的工作，是相当费时费力的。特别是原系统是手工数据处理系统时，各类数据分散在各种不同的原始表格、凭证、单据之中。在向新的数据库系统中输入数据时，还要处理大量的纸质文件，工作量就更大。

为提高数据输入工作的效率和质量，应该针对具体的应用环境，设计一个数据录入子系统，由计算机来完成数据入库的任务。在源数据入库之前，还要采用多种方法对其进行核验，以防止不正确的数据入库——这部分的工作，在整个数据输入子系统中是非常重要的。

现有的关系DBMS，一般都提供不同关系DBMS之间数据转换的工具，若原来是数据库系统，就要充分利用新系统的数据转换工具。

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

7.6.2 数据库的试运行

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

这一阶段要实际运行数据库应用程序，执行对数据库的各种操作，测试应用程序的功能是否满足设计要求。如果不满足，对应用程序部分则要修改、调整，直到达到设计要求为止。
在数据库试运行时，还要测试系统的性能指标，分析其是否达到设计目标。在对数据库进行物理设计时，已初步确定了系统的物理参数值，但一般情况下，设计时的考虑在许多方面只是近似估算，和实际系统运行总有一定的差距。因此必须在试运行阶段，实际测量和评价系统性能指标。事实上，有些参数的最佳值，往往是经过运行调试后找到的。如果测试的结果与设计目标不符，则要返回物理设计阶段，重新调整物理结构，修改系统参数，某些情况下甚至要返回逻辑设计阶段修改逻辑结构。

特别强调两点：

第一，上面已经讲到，组织数据入库是十分费时、费力的事，如果试运行后还要修改数据库的设计，就还要重新组织数据入库。因此应分期、分批地组织数据入库，先输入小批量数据做调试用，待试运行基本合格后再大批量输入数据，逐步增加数据量，逐步完成运行评价。
第二，在数据库试运行阶段，由于系统还不稳定，硬软件故障随时都可能发生；而系统的操作人员对新系统还不熟悉，误操作也不可避免，因此要做好数据库的转储和恢复工作。一旦故障发生，能使数据库尽快恢复，尽量减少对数据库的破坏。

7.6.3 数据库的运行和维护

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

在数据库运行阶段，对数据库经常性的维护工作，主要是由数据库管理员完成的。数据库的维护工作主要包括以下几个方面。

1. 数据库的转储和恢复

数据库的转储和恢复，是系统正式运行后最重要的维护工作之一。数据库管理员要针对不同的应用要求，制定不同的转储计划，以保证一旦发生故障后，能尽快将数据库恢复到某种一致的状态，并尽可能减少对数据库的破坏。

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

在数据库运行过程中，由于应用环境的变化，对安全性的要求也会发生变化，比如有的数据原本是机密的，现在则可以公开查询，而新加入的数据又可能是机密的。系统中用户的密级也会改变。这些都需要数据库管理员，根据实际情况，修改原有的安全性控制。同样，数据库的完整性约束条件也会变化，也需要数据库管理员不断修改，以满足用户的要求。

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

在数据库运行过程中，监督系统运行、对监测数据进行分析，找出改进系统性能的方法，是数据库管理员的又一重要任务。目前，有些关系DBMS提供了监测系统性能参数的工具，数据库管理员可以利用这些工具，方便地得到系统运行过程中一系列性能参数的值。数据库管理员应仔细分析这些数据，判断当前系统运行状况是否为最佳，应当做哪些改进，例如调整系统物理参数、或对数据库进行重组织或重构造等。

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

数据库运行一段时间后，由于记录不断增、删、改，将会使数据库的物理存储情况变坏，降低数据的存取效率，使数据库的性能下降。这时，数据库管理员就要对数据库进行重组织或部分重组织（只对频繁增、删、改的表进行重组织）。关系DBMS一般都会提供数据重组织用的实用程序。在重组织的过程中，按原设计要求重新安排存储位置、回收垃圾、减少指针链等，提高系统性能。

数据库的重组织，并不修改原设计的逻辑和物理结构，而数据库的重构造则不同，它是指部分修改数据库的模式和内模式。

由于数据库应用环境发生变化，增加了新的应用或实体，取消了某些应用，有的实体与实体间的联系发生了变化等，使原有的数据库设计不能满足新的需求，需要调整数据库的模式和内模式。例如，在表中增加或删除某些数据项，改变数据项的类型，增加或删除某个表，改变数据库的容量，增加或删除某些索引等。当然，数据库的重构造也是有限的，只能做部分修改。如果应用变化太大，重构造也无济于事，说明此数据库应用系统的生命周期已经结束，应该设计新的数据库应用系统了。

【数据库系统】第二部分设计与应用开发(7) 数据库设计相关推荐

系统架构设计笔记（8）——数据库设计
数据库设计的过程是将数据库系统与现实世界密切地.有机地.协调一致地结合起来的过程. 数据库的设计质量与设计者的知识.经验和水平密切相关.作为数据库应用系统的重要组成部分,数据库设计的成败往往直接关系到 ...
基于ArcGIS10.0和Oracle10g的空间数据管理平台（C#开发）-数据库设计
先打一个广告:我的独立博客网址是:http://wuyouqiang.sinaapp.com/. 我的新浪微博:http://weibo.com/freshairbrucewoo. 欢迎大家相互交流, ...
物流信息管理系统MySQL设计,物流管理系统的SQL数据库设计(含代码)
物流管理系统的SQL数据库设计(含代码) 物流管理信息系统的数据库设计班级xxx系统名称:物流管理信息系统一.需求分析物流管理系统是为制造商和零售商设计的管理系统数据库系统,目的是:1.实现上游制造商 ...
mysql数据库设计三大范式_了解数据库设计三大范式
数据库设计范式什么是范式:简言之就是,数据库设计对数据的存储性能,还有开发人员对数据的操作都有莫大的关系.所以建立科学的,规范的的数据库是需要满足一些规范的来优化数据数据存储方式.在关系型数据库中 ...
点餐系统mysql设计,外卖点餐系统数据库设计.doc
外卖点餐系统数据库设计.doc 外卖点餐系统数据库设计需求分析: 现要开发外卖点餐系统.经过可行性分析和初步的需求调查,确定了系统的功能边界,该系统应能完成下面的功能: 订餐管理. (2)菜单管理. ...
服装系统mysql设计_服装销售系统数据库设计.ppt
* * * 数据库应用技术山东外贸职业学院服装销售系统数据库设计项目描述开发一套服装销售管理软件,对服装销售进行信息化管理. 包括:采购订货.退货.前台零售.批发业务.销售管理.会员管理.库存 ...
考试系统mysql数据库设计_在线考试系统数据库设计(表)
<在线考试系统数据库设计(表)>由会员分享,可在线阅读,更多相关<在线考试系统数据库设计(表)(7页珍藏版)>请在人人文库网上搜索. 1.在线考试系统数据库设计数据库名OnLi ...
数据库设计冗余_域和数据库设计中的冗余
数据库设计冗余介绍设计域可能是一个真正的挑战. 许多错误的做法很容易使您陷入错误的设计中,并且在大多数情况下,只有在业务逻辑开发的高级阶段之后才能发现这些问题. 幸运的是,有几种好的设计方法和&q ...
系统中mysql设计过程_某系统数据库设计过程记录
数据库设计文档(MySQL) XXX 项目 MySQL + Elasticsearch 数据库架构设计 What & Why What 现在需要一个能够暂时/临时承担系统检索需求, 长期承担 ...

【数据库系统】第二部分 设计与应用开发(7) 数据库设计