《数据库原理与应用》课件第7章

第7章数据库系统设计7.1数据库设计概述7.2需求分析7.3概念结构设计7.4逻辑结构设计7.5物理结构设计7.6设计举例小结数据库设计是建立数据库及其应用系统的技术，是信息系统开发和建设中的核心技术。具体地说，数据库设计是指对于一个给定的应用环境，构造最优的数据库模式，建立数据库及其应用系统，使之能够有效地存储数据，满足各种用户的应用需求(信息要求和处理要求)。

在数据库领域内，常常把使用数据库的各类系统统称为数据库应用系统。

学习内容：

(1)数据库设计步骤。

(2)需求分析。

(3)概念设计。

(4)逻辑设计。

(5)物理设计。

7.1.1数据库设计的基本任务

数据库设计的基本任务是：根据一个单位的信息需求、处理需求和数据库的支撑环境(包括DBMS、操作系统和硬件)，设计出数据模式(包括外模式、模式和内模式)以及典型的应用程序。7.1数据库设计概述信息需求表示一个单位所需要的数据及其结构。处理需求表示一个单位经常需要进行的数据处理，如工资计算、成绩统计等。信息需求表达了对数据库的内容及结构上的要求，也就是静态要求；处理需求表达了基于数据库的数据处理要求，也就是动态要求。DBMS、操作系统和硬件是建立数据库的软、硬件基础，也是其制约因素。数据库设计的成果有二：一是数据模式；二是以数据库为基础的典型应用程序。7.1.2数据库设计的特点

数据库设计既是一项涉及多学科的综合性技术，又是一项庞大的工程项目。有人讲“三分技术，七分管理，十二分基础数据”是数据库建设的基本规律，这是有一定道理的。技术与管理的界面(称之为“干件”)十分重要。数据库建设是硬件、软件和干件的结合。这是数据库设计的特点之一。

数据库设计应该和应用系统设计相结合，也就是说，整个设计过程中要把结构(数据)设计和行为(处理)设计密切结合起来。这是数据库设计的特点之二。传统的软件工程忽视对应用中数据语义的分析和抽象。例如，结构化设计和逐步求精的方法着重于处理过程的特性，只要有可能就尽量推迟数据结构设计的决策。这种方法显然对于数据库应用系统是不妥的。数据库模式是各应用程序共享的结构，是稳定的、永久的，不像以文件系统为基础的应用系统，文件是某一应用程序私用的。数据库设计质量的好坏直接影响系统中各个处理过程的性能和质量。早期的数据库设计致力于数据模型和建模方法研究，着重结构特性的设计而忽视了对行为的设计。也就是说，比较重视在给定的应用环境下，采用什么原则、方法来建造数据库的结构，而没有考虑应用环境要求与数据库结构的关系，因此结构设计与行为设计是分离的。而事实上，数据需求分析是建立在功能分析之上的，通过功能分析产生系统数据流图与数据字典，再通过数据分析设计实体与属性。所以数据库设计应包括结构设计和行为设计。数据库设计也和其他工程设计一样，具有如下三个特征：

(1)反复性(iterative)。数据库设计不可能“一气呵成”，需要反复推敲和修改才能完成。前阶段的设计是后阶段的基础和起点，后阶段也可向前阶段反馈其要求。如此反复修改，日臻完善。

(2)试探性(tentative)。数据库设计不同于求解一个数学题，设计结果一般不是唯一的。设计过程往往是一个试探的过程。在设计过程中，有各种各样的要求和制约因素，它们之间往往是矛盾的。数据库设计很难说是最佳的，常常得之于东，而失之于西；何去何从，取决于数据库设计者的权衡和本单位的决策。决策是设计过程中的一个组成部分，而决策不一定是完全客观的，往往与用户的偏爱和观点有关。

(3)分布进行(multistage)。数据库设计常常由不同的人员分阶段进行。这样做，一是有技术上分工的需要；二是为了分段把关，逐步审核，保证设计的质量和进度。尽管后阶段会向前阶段反馈其要求。但正常情况下，这些反馈的修改不应是大量的。7.1.3数据库设计的基本步骤

按照软件生命周期的划分，综合考虑数据库及其应用系统设计的全过程，我们将数据库设计分为6个阶段，如图7.1所示。

1．需求分析阶段

进行数据库设计之前，设计者必须准确了解用户的需求，确定系统与环境的界线。用户需求包括数据和处理两部分需求。数据需求是指数据库中存储哪些数据；处理需求是指用户要完成什么处理功能，以及对这些处理的响应时间、处理方式等有什么要求。需求分析是基础工作。如果需求分析做得充分、准确，则可以为以后的工作打下坚实的基础。参与需求分析的人员主要有系统分析人员、数据库设计人员和用户。需求分析得到的成果是需求分析说明书。

图7.1数据库设计步骤

2．概念结构设计阶段

概念结构设计(又称概念设计)是把用户的信息要求统一到一个整体逻辑结构中。概念结构能表达用户的要求，且独立于支持数据库的DBMS和硬件结构。概念结构设计是整个数据库设计的关键。参与的人员主要有系统分析人员和数据库设计人员。概念结构设计得到的成果为完整的E-R模型。

3．逻辑设计阶段

逻辑设计阶段主要分为两部分：逻辑结构设计和应用程序设计。逻辑结构设计是静态结构设计，主要任务是将概念设计阶段的E-R模型转换为特定机器上的、DBMS所支持的数据模型，并进行优化。应用程序设计是动态行为设计，主要任务是使用主语言和数据库管理系统的DDL数据定义语言进行结构式的程序设计。参与逻辑设计的人员主要有系统分析人员、数据库设计人员和程序设计员。逻辑设计得到的成果为数据模型和应用程序模块结构。

4．物理设计阶段

物理设计也分为两部分：数据库物理结构设计和程序模块结构的精确化。物理结构设计的主要任务是为逻辑数据模型选取一个最适合应用环境的物理结构，并对程序进行精确化设计。参与物理设计的人员主要有数据库人员和程序设计人员。物理设计得到的成果为物理设计说明书，其中包括物理结构说明书和程序设计说明书。

5．数据库实施阶段

数据库实施阶段的主要任务是利用DBMS提供的数据语言及其宿主语言将逻辑设计和物理设计的结果严格地描述出来，编制和调试源程序，组织数据入库，并进行试运行。参与实施阶段的人员主要有系统分析人员、数据库人员、程序设计人员和用户。

6．数据库运行和维护阶段

系统在进行试运行后即可投入正式运行，并不断对其进行评价、调整、修改，直到退役。参与这一阶段的人员有数据库管理员和用户。以上6个阶段呈线性关系，设计过程的每一步都要有明确的结果，并且前一阶段的结果就是后一阶段的基础。设计人员应反复地对每个步骤的过程和结果进行审核，尽早地发现系统设计中的错误，并及时纠正，减少开发成本。

需求分析是设计数据库的起点，需求分析就是要分析用户的要求，其结果是否准确地反映了用户的实际要求，将直接影响到后面各个阶段的设计，并决定设计结果是否合理和实用。该阶段收集的基础数据(用数据字典来表达)和一组数据流程图(DadaFlowDiagram，简称DFD)是下一步进行概念设计的基础。7.2需求分析7.2.1需求分析的任务

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

调查的重点是“数据”和“处理”，通过调查、收集与分析，获得用户对数据库的如下要求：

(1)信息要求。指用户需要从数据库中获得信息的内容与性质。由信息要求可以导出数据要求，即在数据库中需要存储哪些数据。

(2)处理要求。指用户要完成什么处理功能，对处理的响应时间有什么要求，处理方式是批处理还是联机处理。

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

7.2.2需求分析的方法

进行需求分析首先要调查清楚用户的实际要求，与用户达成共识，然后分析与表达这些需求。图7.2描述了需求分析阶段的各步工作的联系。

图7.2需求分析的步骤调查用户需求的具体步骤如下：

(1)调查组织机构情况，包括了解该组织的部门组成情况、各部门的职责等，为分析信息流程做准备。

(2)调查各部门的业务活动情况，包括了解各个部门输入和使用什么数据，如何加工处理这些数据，输出什么信息，输出到什么部门，输出结果的格式是什么，这是调查的重点。

(3)在熟悉了业务活动的基础上，协助用户明确对新系统的各种要求，包括信息要求、处理要求、安全性与完整性要求，这是调查的又一个重点。

(4)确定新系统的边界。对前面调查的结果进行初步分析，确定哪些功能由计算机完成或将来准备让计算机完成，哪些活动由人工完成。由计算机完成的功能就是新系统应该实现的功能。

在调查过程中，可以根据不同的问题和条件，使用不同的调查方法。

常用的调查方法有：

(1)跟班作业。通过亲身参加业务工作来了解业务活动的情况。这种方法可以比较准确地理解用户的需求，但比较耗费时间。

(2)开座谈会。通过与用户座谈来了解业务活动情况及用户需求。座谈时，参加者之间可以相互启发，一般可按职能部门组织座谈会。

(3)询问或请专人介绍。一般应包括领导、管理人员、操作员等。

(4)设计调查表请用户填写需求。如果调查表设计得合理，这种方法是很有效的，也易于为用户接受。

(5)查阅记录。查阅与原系统有关的数据记录。

进行需求调查时，往往需要同时采用上述多种方法。但无论使用何种调查方法，都必须有用户的积极参与和配合，最好能由双方人员参加的项目实施保障小组负责沟通联系。

调查了解了用户的需求以后，还需要进一步分析和表达用户的需求。在众多的分析方法中，结构化分析(StructuredAnalysis，简称SA)方法是一种简单实用的方法。SA方法是从最上层的系统组织机构入手，采用自顶向下、逐层分解的方式分析系统的。即由最高层次抽象系统开始，将处理功能分解为若干子功能，每个子功能还可以继续分解，直到把系统工作过程表示清楚为止。在处理功能逐步分解的同时，它们所用的数据也逐级分解，形成若干层次的数据流图。

SA方法用自顶向下、逐层分解的方式分析系统。用数据流图、数据字典描述系统。任何一个系统都可以抽象为如图7.3所示的情况。

图7.3系统高层抽象图7.2.3数据流图

数据流图表达了数据和处理过程的关系，反映的是对事务处理所需的原始数据及经处理后的数据及其流向。数据流是数据在系统内的传输途径，数据流图从数据传递和加工的角度，以图形的方式刻画出数据流从输入到输出的变换过程。数据流图是结构化系统分析的主要工具，它去掉了具体的组织机构、工作场所、物质流等，仅反映信息和数据存储、流动、使用以及加工的情况。

1．数据流图的符号规定

一般地，规定数据流图的符号如图7.4所示。

图7.4数据流图的符号

1)数据流

数据流由一组确定的数据组成。例如学生基础信息由学号、姓名、年龄等组成。由于数据流是流动中的数据，因此必须有流向，箭头表示数据流动的方向。除了与数据存储之间的数据流不用命名外，其他数据流应该用名词或名词短语命名。

2)处理

处理是对数据进行的操作或处理。

3)文件

文件是数据暂时存储或永久保存的地方，可以是数据库存储文件。

4)外部实体

外部实体是独立于系统而存在的，是和系统有联系的实体。它表示数据的外部来源和最后的去向。

设计人员通过对调查结果进行分析，可以获得业务流程以及业务与数据之间的联系。结果一般用数据流程图表示。

例7.1

教学管理的数据流图。

通过对教学管理系统的信息及业务流程进行初步分析后，首先抽象出该系统最高层的数据流图，即把整个数据处理过程看成是一个加工的顶层数据流图，如图7.5所示。

图7.5教学管理系统顶层数据流图顶层数据流图反映了教学管理系统与外界的接口，但未表明数据的加工要求，需要进一步细化。根据需求分析阶段对教学管理系统功能边界的确定，再对教学管理系统顶层数据流图中的处理功能做进一步分解，可以分解为选课、成绩录入和查询三个子功能。这样，就得到了教学管理系统的第一层数据流图，如图7.6所示。从第一层到第二层，再从第二层到第三层依次分解下去。图7.7和图7.8是第一层到第二层的数据流图(查询的数据流图略)。

图7.6教学管理系统第一层数据流图

图7.7选课的数据流图

图7.8成绩录入的数据流图7.2.4数据字典

数据字典(DataDictionary，简称DD)是系统中各类数据描述的集合，是进行详细的数据收集和数据分析所获得的主要成果。

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

1．数据项

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

数据项描述={数据项名，数据项含义说明，别名，数据

类型，长度，取值范围，与其他数据项的逻辑关系}

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

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

2．数据结构

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

对数据结构的描述通常包括以下内容：

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

3．数据流

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

数据流描述={数据流名，说明，数据流来源，数据流去向，

组成：{数据结构}，平均流量，高峰期流量}

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

4．数据存储

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

数据存储描述={数据存储名，说明，编号，输入的数据流，输出的数据流，

组成：{数据结构}，数据量，存取频度，存取方式}

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

5．处理过程

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

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

输出：{数据流}，处理：{简要说明}}

其中，“简要说明”中主要说明该处理过程的功能及处理要求。功能是指该处理过程用来做什么(而不是怎么做)，处理要求包括处理频度要求，如单位时间里处理多少事务，多少数据量，响应时间要求等。这些处理要求是后面物理设计的输入及性能评价的标准。可见，数据字典是关于数据库中数据的描述，即元数据，而不是数据本身。

数据字典是在需求分析阶段建立，在数据库设计过程中不断修改、充实和完善的。

例7.2

以教学管理系统来说明如何定义数据字典。

(1)数据项描述举例。

数据项名：学号

含义说明：唯一标识一个学生

类型：字符型

长度：8

别名：学号

取值范围：00000000~99999999

(2)数据结构描述举例。

数据结构：学生基本信息

含义说明：是学籍管理子系统的主体数据结构，定义了一个学生的有关信息

组成：学号、姓名、性别、年龄、民族、所属班级、籍贯……

(3)数据流描述举例。

数据流名：成绩单

说明：选修课程考试结果返回的单据

数据流来源：教师

数据流去向：考试成绩

组成：学号、课程编号、成绩

平均流量：班级数

高峰期流量：……

(4)数据存储描述举例。

数据存储名：学生基本信息

说明：学生的基本情况

流入数据流：学生信息

流出数据流：选课、查询……

组成：学号、姓名、性别、年龄、民族、所属班级、籍贯

数据量：每年4000条

存取方式：随机存取

(5)处理过程描述举例。

处理过程名：修改学生成绩

说明：修改输入错误的学生成绩

输入：学生、课程号、成绩

输出：成绩信息

处理：当学生成绩输入错误时，要修改学生的成绩。首先输入要修改学生的学

号、课程号；根据输入的学号和课程号查询原始的输入成绩，如果是错

误的，则修改(但修改时必须看原始的成绩单)以上简单举例说明数据字典中对于数据项、数据结构、数据流、数据存储和处理过程的描述方式，省略的部分请读者自己完成。

最终形成的数据流图和数据字典为“需求分析说明书”的主要内容，这是进行概念设计的基础。

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

概念结构是对现实世界的一种抽象，即对实际的人、物、事和概念进行人为处理，抽取人们关心的共同特性，忽略非本质的细节，并把这些特性用各种概念精确地加以描述，如图7.9所示。7.3概念结构设计

(1)概念结构独立于数据库逻辑结构，也独立于支持数据库的DBMS，不受其约束。

(2)它是现实世界与机器世界的中介，它一方面能够充分反映现实世界，包括实体和实体之间的联系，同时又易于向关系、网状、层次等各种数据模型转换。

(3)它应是现实世界的一个真实模型，易于理解，便于和不熟悉计算机的用户交换意见，使用户易于参与。

(4)当现实世界需求改变时，概念结构又可以很容易地做相应调整，因此，概念结构设计是整个数据库设计的关键所在。

图7.9概念结构设计的步骤7.3.1数据库概念设计的基本方法

要进行数据库的概念设计，首先必须选择适当的数据模型。用于概念设计的数据模型既要有足够的表达能力，可以表示各种类型的数据及其相互间的联系和语义，又要简明易懂，能够为非计算机专业人员所接受。可供选择的数据模型不少，例如各种语义数据模型、面向对象数据模型等。目前应用得最广泛的是E-R数据模型及其扩充版本(EER)。E-R数据模型除了具有上述的特点外，还可以用E-R图表示数据模式，便于理解与交流。下面将以扩充的E-R数据模型为例，介绍概念设计的基本方法。用E-R数据模型设计数据模式，首先必须根据需求说明，确认实体、联系和属性。如前所述，实体、联系和属性的区分不是绝对的。实体本来是一个无所不包的概念，属性和联系都可以看成是实体。引入属性和联系的概念，无非是为了更清晰、明确地表示现实世界中各种对象彼此之间的联系。概念设计所产生的模式本来就要求比较自然地反映现实世界，因此，实体、属性和联系的划分实质上反映了数据库设计者和用户对现实世界的理解和观察。它既是客观世界的描述，又反映设计者的观点甚至偏爱。对于同一个单位，不同的设计者设计出不同的数据模式是不足为奇的。一个单位有许多部门、用户组和各种应用，需求说明来自对它们的调查和分析。这些不同来源的需求可能不一致，甚至矛盾。如何要在这样的需求说明的基础上设计出一个单位的数据模式，一般有下列两种不同的方法。

1．集中式模式设计法(CentralizedSchemaDesignApproach)

在这种方法中，首先将需求说明综合成一个一致的、统一的需求说明，一般由一个权威组织或授权的DBA进行此项综合工作。

然后，

在此基础上设计一个单位的全局数据模式，再根据全局数据模式为各个用户组或应用定义外模式。这种方法强调统一，对各用户组和应用可能照顾不够，一般用于小的、不太复杂的单位。如果一个单位很大、很复杂，则综合需求说明是很困难的工作，而且在综合过程中，难免要牺牲某些用户的要求。

2．视图集成法(ViewIntegrationApproach)

视图集成法不要求综合成一个统一的需求说明，而是以各部分的需求说明为基础，分别设计各自的局部模式。这些局部模式实际上相当于各部分的视图，然后再以这些视图为基础，集成为一个全局模式。在视图集成过程中，可能会发现一些冲突，须对视图做适当的修改。由于集成和修改在E-R数据模型表示的模式上进行，因此一般可用计算机辅助设计工具进行，修改后的视图可以作为外模式设计的基础。从表面上看，集中式模式设计法修改的是局部需求说明，而视图集成法修改的是视图，两者似乎无多大差别，但两者的设计思想是有区别的：视图集成法是以局部需求说明为设计的基础，在集成时，尽管要对视图做必要的修改，但视图是设计的基础，全局模式是视图的集成；而集中式模式设计法是在统一需求说明的基础上，设计全局模式，再设计外模式，全局模式是设计的基础。视图集成法适合于大型数据库的设计，可以多组并行进行，可以免除综合需求说明的麻烦。目前，视图集成法用得较多，下面将以此法为主介绍概念设计。7.3.2概念设计

1．视图设计次序

视图是按照某个用户组、应用或部门的需求说明，用E-R数据模型设计的局部模式。视图的设计一般从小开始，逐步扩大，直至完备，一般有三种可能的设计次序。

1)自顶向下

自顶向下的视图设计先从抽象级别高、普遍的对象开始，逐步细化、具体化、特殊化。例如，图书这个视图，可从一般的出版物开始，再分为书籍和期刊，再加上借阅人、购置、流通等模式。

2)自底向上

自底向上的视图设计从具体的基本对象开始，逐步抽象化、普遍化。这相当于面向对象数据模型和EER中的普遍化过程。

3)由内向外

由内向外的视图设计从最基本、最明显的对象开始，逐步扩大至有关的其他对象。以学生视图为例，先表示有关学生的基本数据，再表示诸如课外活动、兴趣小组、家庭情况等有关的其他数据。

上面三种次序都可以完成视图的设计。设计E-R图一般无一定的程式，上面所介绍的次序无非提供了一个系统考虑问题的方法。如果设计者认为合适，也可混合运用上面几种设计次序。

2．概念结构设计

概念结构设计的第一步就是利用上面介绍的抽象机制对需求分析阶段收集到的数据进行分类、组织(聚集)，形成实体、实体的属性、标识实体的码，确定实体之间的联系类型

(1∶1，1∶n，；m∶n)，设计分E-R图。具体做法是：

(1)选择局部应用。根据某个系统的具体情况，在多层的数据流图中选择一个适当层次的数据流图，作为设计分E-R图的出发点，让这组图中的每一部分对应一个局部应用。

由于高层的数据流图只能反映系统的概貌，而中层的数据流图能较好地反映系统中各局部应用的子系统组成，因此人们往往以中层数据流图作为设计分E-R图的依据。

(2)逐一设计分E-R图。选择好局部应用之后，就要对每个局部应用逐一设计分E-R图，亦称局部E-R图。

在前面选好的某一层次的数据流图中，每个局部应用都对应了一组数据流图，局部应用涉及的数据都已经收集在数据字典中了。现在就是要将这些数据从数据字典中抽取出来。参照数据流图，标定局部应用中的实体、实体的属性、标识实体的码，确定实体之间的联系及其类型。

设计分E-R图可以从第一层数据流图入手。若某一局部应用仍比较复杂，则可以从更下层的数据流图入手，分别设计它们的分E-R图，再汇总成该局部应用的分E-R图。

教学管理的分E-R图如图7.10和图7.11所示。

图7.10教学管理的部分E-R图(管理部分)

图7.11教学管理的部分E-R图(选课部分)为了清晰表述实体及实体之间的联系，该E-R图中省略了各个实体的属性描述。这些实体的属性分别为：

·院系(院系号，院系名，电话)。

·专业(专业号，专业名，专业类别，学制)。

·班级(班级号，班级名，班级人数)。

·班主任(职工号，姓名)。

·学生(学号，姓名，性别，出生日期，年龄，民族，籍贯，平均成绩)。

·课程(课程编号，课程名称，学期，学时，学分)。

·教师(教师编号，教师名，性别，籍贯，职称)。

·教材(书号，书名，价钱，出版社)。

3．设计数据库E-R模式的选择

E-R数据模式使得我们通过设计数据库模式来给企业建模时有足够的灵活性。下面讨论数据库设计者在建模时需要做的选择：

(1)用属性表示某个对象更恰当还是用实体集表示更恰当。

(2)要最准确地描述现实世界中的某个概念，是用实体集还是联系集合适。

(3)使用三元联系还是一对二元联系。

(4)使用强实体集还是弱实体集。数据库中的一个强实体集和依附于它的弱实体集可被视为单一的“对象”，因为弱实体存在依赖于强实体。

(5)使用概括是否合适。概括，或称ISA联系的层次结构，是指允许在E-R图的某个地方表示相似实体集的共同属性，它有助于进行模块化。

(6)使用聚集是否合适。聚集是将E-R图的某个部分集成为单一实体，使得我们可以将被聚集实体看做一个单元，而不必关心其内部结构的细节。

事实上，在现实世界中，具体的应用环境常常对实体和属性已经做了大体的、自然的划分。在数据字典中，“数据结构”、“数据流”和“数据存储”都是若干属性有意义的聚合，就体现了这种划分。可以先从这些内容出发定义E-R图，然后再进行必要的调整。在调整中遵循的一条原则是：为了简化E-R图的处理，现实世界的事物能作为属性对待的，应尽量作为属性对待。

那么符合什么条件的事物可以作为属性对待呢?实体与属性之间并没有形式上可以截然划分的界限，具体可以参照下面两条准则：

(1)作为“属性”，不能再具有需要描述的性质。“属性”必须是不可分的数据项，不能包含其他属性。

(2)“属性”不能与其他实体具有联系，即E-R图中所表示的联系是实体之间的联系。凡满足上述两条准则的事物，一般均可作为属性对待。

可以看出，数据库设计者要做出正确的决定，就必须对被建模的企业有深刻的理解。

例7.4

教学管理中的教师职称，在有些环境下只作为属性描述，而在另一些环境中作为实体描述。

教师(教师编号，教师名，性别，籍贯，职称，所属专业)，如图7.12所示。

图7.12教师与职称的E-R图(a)职称作为属性；(b)职称作为实体

4．视图集成

各子系统的分E-R图设计好以后，下一步就是要将所有的分E-R图综合成一个系统的总E-R图。一般来说，视图集成可以有两种方式：第一种是多个分E-R图一次集成；第二种是逐步集成，用累加的方式一次集成两个分E-R图，如图7.13所示。

图7.13一次集成和分步集成两种方式

(a)一次集成；(b)分步集成第一种方式比较复杂，做起来难度较大。第二种方式每次只集成两个分E-R图，可以降低复杂度。

无论采用哪种方式，每次集成局部E-R图时都需要分两步走：一是合并，其目的是解决各分E-R图之间的冲突，将各分E-R图合并起来生成初步E-R图；二是修改和重构，其目的是消除不必要的冗余，生成基本E-R图，如图7.14所示。

图7.14视图集成视图的设计从局部的需求出发，比起一开始就设计全局模式要简单得多、单纯得多。有了各个局部的视图，就可通过视图集成设计全局模式。在视图集成时，必须解决下列问题：

(1)确认视图中的对应和冲突。对应是指视图中语法和语义都相同的概念，也就是它们的共同部分；冲突指它们有矛盾的概念。常见的冲突有下列四种：

①命名冲突。命名冲突有同名异义和同义异名两种。前者指两个同名的实体、属性在两个视图中的含义是不同的；后者指在两个视图中含义相同的实体、属性命名不同。

②概念冲突。同一概念在一个视图中可能作为实体，在另一视图中可能作为属性或联系。例如在某些场合下，如果用户要求，有些概念可以当做实体，也可以当做联系来看待。③域冲突。相同的属性在不同的视图中有不同的域。例如，学号在一个视图中可能当作字符串，在另一个视图中可能当作整数。有些属性采用不同的度量单位，也属域冲突。

④约束冲突。不同视图可能有不同的约束。例如，对于“选课”这个联系，大学生和研究生选课的最少门数和最多门数可能不一样。

(2)对视图进行某些修改，解决部分冲突。例如，同名异义的可加以不同命名；同义异名的应规范为同一名字；域冲突的应取相同的值域；约束冲突的可将相关的概念特殊化等。

(3)合并视图，形成全局模式。尽可能合并对应的部分，保留特殊的部分，删除冗余部分，必要时对模式进行适当的修改，力求使模式简明清晰。

例7.5

教学管理的视图集成E-R。将图7.8、7.9的分E-R图集成视图存在一定的冲突。

(1)学籍管理中的“班主任”与课程管理的“教师”在一定程度上属于异名同义，统一为教师；教师属性中增加是否为班主任，即教师(教师编号，教师名，性别，籍贯，职称，是否班主任)。

(2)班主任改为教师后，将两种联系(指导与教学)也综合为教学联系。

(3)教师可以通过学生选修课程实现教学，班主任可以通过管理班级实现对学生的指导，所以教师和班主任与学生之间的联系就是冗余的。合并的E-R图如图7.15所示。

图中，各实体的属性如下：

·院系(院系号，院系名，电话)。

·专业(专业号，专业名，专业类别，学制)。

·班级(班级号，班级名，班级人数)。

·学生(学号，姓名，性别，出生日期，年龄，民族，籍贯，平均成绩)。

·课程(课程编号，课程名称，学期，学时，学分)。

·教师(教师编号，教师名，性别，籍贯，职称，是否班主任)。

·教材(书号，书名，价钱，出版社)。

图7.15教学管理集成的E-R图

(4)消除不必要的冗余，设计基本E-R图。在初步E-R图中，可能存在一些冗余的数据和实体间冗余的联系。所谓冗余的数据，是指可由基本数据导出的数据，冗余的联系是指可由其他联系导出的联系。冗余数据和冗余联系容易破坏数据库的完整性，给数据库的维护增加困难，应当予以消除。消除了冗余后的初步E-R图称为基本E-R图。

消除冗余主要采用分析方法，即以数据字典和数据流图为依据，根据数据字典中关于数据项之间逻辑关系的说明来消除冗余。但并不是所有的冗余数据与冗余联系都必须加以消除，有时为了提高效率，不得不以冗余信息作为代价。因此在设计数据库概念结构时，哪些冗余信息必须消除，哪些冗余信息允许存在，需要根据用户的整体需求来确定。如果人为地保留了一些冗余数据，则应把数据字典中数据关联的说明作为完整性约束条件。

除分析方法外，还可以用规范化理论来消除冗余。在规范化理论中，函数依赖的概念提供了消除冗余联系的形式化工具。具体方法如下：

(1)确定分E-R图实体之间的数据依赖。实体之间一对一、一对多、多对多的联系可以用实体候选键之间的函数依赖来表示。

(2)求函数依赖FL的最小覆盖GL，差集为D=FL－GL。逐一考察D中的函数依赖，确定是否是冗余的联系，若是，就把它去掉。

由于规范化理论受到泛关系假设的限制，因此应注意下面两个问题：一是冗余联系一定在D中，而D中的联系不一定是冗余的；二是当实体之间存在多种联系时要将实体之间的联系在形式上加以区分。注意：

(1)并不是所有冗余数据与冗余联系都必须加以消除：为了提高某些应用效率，不得不以冗余信息作为代价。如需要经常查询学生的平均成绩，则每次读都需要计算就使得效率太低，保留该冗余数据能提高效率。

(2)冗余数据的一致性维护：触发器。例如，任何一门课程的成绩修改或学生学了新的科目并有了成绩后，就触发该触发器去修改该学生的平均成绩属性值。

例7.6

对教学管理系统，消除继承的E-R图中的数据冗余。图7.16反映了教学管理系统的基本E-R图。

图7.16教学管理系统的基本E-R图学生实体中的年龄属性可以由出生日期推算出来，属于冗余数据，应该去掉。这样不仅可以节省存储空间，而且当某个学生的出生日期有误，进行修改后，无须相应修改年龄，减少了产生数据不一致的机会。平均成绩由学生选课联系中的成绩属性推算出。

其各实体的属性如下：

·院系(院系号，院系名，电话)。

·专业(专业号，专业名，专业类别，学制)。

·班级(班级号，班级名，班级人数)。

·学生(学号，姓名，性别，出生日期，民族，籍贯)。

·课程(课程编号，课程名称，学期，学时，学分)。

·教师(教师编号，教师名，性别，籍贯，职称，是否班主任)。

·教材(书号，书名，价钱，出版社)。

概念结构是独立于任何一种数据模型的信息结构，逻辑结构设计的任务就是把概念结构设计阶段设计好的基本E-R图转换为与选用DBMS产品所支持的数据模型相符合的逻辑结构。

从理论上讲，设计逻辑结构应该选择最适于相应概念结构的数据模型，然后对支持这种数据模型的各种DBMS进行比较，从中选出最合适的DBMS。7.4逻辑结构设计但实际情况往往是已给定了某种DBMS，设计人员没有选择的余地。目前DBMS产品一般支持关系、网状、层次三种模型中的某一种(绝大多数支持关系模型)。对某一种数据模型，各个机器系统又有许多不同的限制，提供不同的环境与工具，所以设计逻辑结构时一般要分三步进行：

(1)将概念结构转换为一般的关系、网状、层次模型。

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

(3)对数据模型进行优化。7.4.1E-R图向关系模型的转换

E-R图向关系模型的转换要解决的问题是如何将实体和实体间的联系转换为关系模式，如何确定这些关系模式的属性和候选键。

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

(1)一个实体型转换为一个关系模式，实体的属性就是关系的属性，实体的键就是关系的键。例如，学生(学号，姓名，性别，出生日期，民族，所属班级，籍贯)。

(2)对于实体间的联系，有以下不同的情况：

①一个1∶1联系可以转换为一个独立的关系模式，也可以与任意一端对应的关系模式合并。如果转换为一个独立的关系模式，则与该联系相连的各实体的键以及联系本身的属性均转换为关系的属性，每个实体的键均是该关系的候选键。如果与某一端实体对应的关系模式合并，则需要在该关系模式的属性中加入另一个关系模式的键和联系本身的属性。

例7.7

教师“管理”班级联系(反映了班主任与班级的对应关系)可以转换为

·独立的关系模式：

管理(教师编号，班级号)或管理(教师编号，班级号)

·与任一端合并：

班级(班级号，班级名，所属专业，班级人数，教师编号)

或

教师(教师编号，教师名，性别，籍贯，职称,院系号，班级号)注：基于效率考虑，有时联系比某一端合并效率更高。如要经常查询某个班级的班主任名，则联系比教师关系合并更好些，原因是能减少连接操作。

②一个1∶n联系可以转换为一个独立的关系模式，也可以与n端对应的关系模式合并。如果转换为一个独立的关系模式，则与该联系相连的各实体的键以及联系本身的属性均转换为关系的属性，而关系的键为n端实体的键。

例7.8

学生“组成”班级联系，可以转换为

组成(学号，班级号)(独立的关系模式，主键为n端实体的主键)

或

学生(学号，姓名，性别，出生日期，民族，籍贯，班级号)

这两种表示方法能达到同样的目的，但后一种情况能减少系统中表的个数，更常用。

③一个n∶m联系转换为一个关系模式。与该联系相连的各实体的键以及联系本身的属性均转换为关系的属性，而关系的键为各实体键的组合。如学生选课联系：选课(学号，课程编号，成绩)。

④三个或三个以上实体间的一个多元联系可以转换为一个关系模式。与该多元联系相连的各实体的键以及联系本身的属性均转换为关系的属性，而关系的键为各实体键的组合。如授课(课程号，教师编号，书号)。

(3)具有相同键的关系模式可合并。如管理(教师编号，班级号)与班级(班级号，班级名，专业号，班级人数)可以合并为：班级(班级号，班级名，专业号，班级人数，教师编号)。

在转换中除了要遵循以上原则外，还应注意两点：

(1)命名和属性域的处理。关系模式的命名，可以采用E-R图中原来的命名，也可以另行命名。命名应有助于对数据的理解和记忆，同时应尽可能避免重名。DBMS一般只支持有限的几种数据类型，而E-R数据模型是不受这个限制的。如果DBMS不支持E-R图中某些属性的域，则应做相应的修改。如果用户坚持要使用原来的数据类型，那就可能导致数据库的数据类型与应用程序中的数据类型不一致，这只能由应用程序去转换。

(2)非原子属性的处理。E-R数据模型中允许非原子属性，这不符合关系模型的第一范式条件。非原子属性主要有两种基本类型：集合型和元组型。当然，集合的元素可以是元组，元组的分量可以是集合。只要解决了这两种基本的非原子属性的转换问题，就不难推广到其他复杂的非原子属性的处理。可以采用对集合属性纵向展开，对元组属性横向展开的办法解决E-R图中非原子属性的问题。

E-R模型和关系数据库模型都是现实世界抽象的逻辑表示。由于两种模型采用类似的设计原则，因此可以将E-R设计转换为关系设计。将数据库的表示从E-R图转为表的形式是由E-R图产生关系数据库设计的基础。虽然关系和表之间存在重大区别，但在不很严格的情况下，可以将关系看作是由某些值形成的一个表。符合E-R数据模式的数据库可以表示为一些表的集合。数据库的每个实体集和联系集都有唯一的表与之对应，表名即为相应的实体集或联系集的名称。每个表有多个列，每列有唯一的列名。

例7.9

依照上述的转换规则，将教学管理系统中的7个实体和8个联系可以转换为下列关系模型：

·院系(院系号，院系名，电话)。

·专业(专业号，专业名，院系号，专业类别，学制)。

·班级(班级号，班级名，班级人数，专业号，教师编号)。

·学生(学号，姓名，性别，出生日期，民族，籍贯，班级号)。

·课程(课程编号，课程名称，学期，学时，学分)。

·教师(教师编号，教师名，性别，籍贯，职称，是否班主任，院系号，聘期)。

·教材(书号，书名，价钱，出版社)。

·讲授(课程号，职工号，书号)。

·选修(学号，课程号，成绩)。7.4.2逻辑模式的规范化、调整和实现

从E-R图转换而来的关系模式只是逻辑模式的雏形，要成为逻辑模式，还须进行如下处理：

·规范化。

·适应DBMS限制条件的修改。

·满足性能、存储空间等要求的调整。

·用DBMS所提供的DDL定义逻辑模式。

关于DBMS对逻辑模式的限制，可参阅有关DBMS的手册。下面主要讨论逻辑模式在满足性能、存储空间等要求上的调整。

1．改善数据库性能的调整

数据库的性能是用户经常关注的问题之一。在模式设计中，侧重于模式的合理性，而较少注意数据库的性能问题。数据库的性能与数据库的物理设计关系十分密切，但数据库的逻辑设计对它也有一定的影响。下面从数据库逻辑设计的角度，讨论改善数据库性能的一些措施。

1)减少连接运算

连接是开销很大的运算。参与连接的关系越多、越大，开销就越大。对于一些常用的、性能要求比较高的数据库查询，最好是一元操作。这与规范化的要求往往是矛盾的。有时为了保证性能，不得不牺牲规范化的要求，把数据模式中规范化了的关系再连接起来，这就是所谓的逆规范化。逆规范化有更新异常的危险。如果用户的专业水平较高，例如是程序员，则可提醒他们采取措施，避免更新异常，这种情况下，逆规范化不失为一种提高数据库性能的措施。如果用户是偶然用户，或用户不固定，则很难保证他们理解更新异常，并在更新时采取相应的措施，在此情况下，最好不要采取逆规范化措施，或限制这些用户进行更新操作。

2)减小关系的大小和数据量

关系的大小对查询的速度影响颇大。有时为了提高查询速度，把一个大关系分成多个小关系是有利的，例如关于学生的数据，可以把全校学生的数据放在一个关系中，也可按系建立学生关系。前者对全校范围内的查询是方便的，后者可以显著提高一个系范围内的查询速度。如果按系查询是主要的，则按系建立学生关系可以提高性能，这是把关系从水平方向分割。如果数据库系统有多个磁盘驱动器，则可把水平分割的关系分布在不同的磁盘组上，可以并行访问，提高数据库的性能。有时也可以考虑从垂直方向分割关系。例如，教职工档案属性很多，有些是经常查询的，有些很少用到，如果都放在一个关系里，则关系的数据量比较大，势必影响查询的速度。若把常用的属性和很少使用的属性分成两个关系，则可提高常用查询的速度。

3)尽可能使用快照

在不少的应用中，只需数据的某一时间的值，并不一定需要数据的当前值，绝大部分报表都属于这一类。对于这些应用，可以对数据定义一个快照，并定期刷新。由于查询结果在快照刷新时已经自动生成，并存于数据库中，因此在查询时只要取出快照就行了，这可以显著地提高查询速度。

2．节省存储空间的调整

节省数据库的存储空间也是数据库设计的目标之一，尤其当存储空间很紧张时，在这方面要做更多的努力。在数据库的逻辑设计方面，可做如下的考虑。

1)节省每个属性所占的空间

在定义属性时，既要表示得自然和易于理解，也要考虑节省存储空间。这两方面的要求往往是矛盾的，须根据实际条件斟酌决定。

一般地讲，用编码代替实际属性值、用缩写名代替全称可以节省存储空间，但用户看起来就不那么直观了。

2)采用假属性(DummyAttribute)减少重复数据所占存储空间

在有些关系中，某些数据会多次出现。设某关系有函数依赖A→B，如果B的域所取的值比较少，但每一值所占存储空间比较大，而A的域具有较多的不同的值，则B的同一值可能在多个元组中重复出现。例如，学生的经济状况一般包括家庭人均收入的档次、奖学金等级、有无其他经济来源等，与其在学生记录中逐个填写，还不如把它分成几个类型。设A代表学号，B代表经济状况，C代表经济状况类型，则A→B可分解成两个函数依赖：

A→C，C→B

这时，A→C可保留在原来的学生关系中，而将C→B表示在另一个关系中。在元组很多的学生关系中，仅用简短的类型号表示经济状况，而用另一个很小的关系描述每个经济状况类型的内容。这里，C实际上起了经济状况替身的作用，称为假属性。适当地采用假属性可以节省存储空间。

3．数据模型的优化

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

(1)确定数据依赖。用数据依赖分析和表示数据项之间的联系，写出每个数据项之间的数据依赖。即按需求分析阶段所得到的语义，分别写出每个关系模式内部各属性之间的数据依赖以及不同关系模式属性之间的数据依赖。

(2)对于各个关系模式之间的数据依赖进行极小化处理，消除冗余的联系。

(3)按照数据依赖的理论对关系模式逐一进行分析，考察是否存在部分函数依赖、传递函数依赖、多值依赖等，确定各关系模式分别属于第几范式。

(4)按照需求分析阶段得到的处理要求，分析这些模式对于这样的应用环境是否合适，确定是否要对某些模式进行合并或分解。

必须注意的是，并不是规范化程度越高的关系就越优。例如，当查询经常涉及到两个或多个关系模式的属性时，系统经常进行连接运算。连接运算的代价是相当高的，可以说关系模型低效的主要原因就是连接运算引起的。这时可以考虑将这几个关系合并为一个关系。因此在这种情况下，第二范式甚至第一范式也许是合适的。

又如，非BCNF的关系模式虽然从理论上分析会存在不同程度的更新异常或冗余，但如果在实际应用中对此关系模式只是查询，并不执行更新操作，则不会产生实际影响。所以对于一个具体应用来说，到底规范化到什么程度，需要权衡响应时间和潜在问题两者的利弊决定。

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

水平分解是把(基本)关系的元组分为若干子集合，定义每个子集合为一个子关系，以提高系统的效率。根据“80／20原则”，一个大关系中，经常被使用的数据只是关系的一部分，约20％，可以把经常使用的数据分解出来，形成一个子关系。如果关系R上具有n个事务，而且多数事务存取的数据不相交，则R可分解为少于或等于n个子关系，使每个事务存取的数据对应一个关系。

垂直分解是把关系模式R的属性分解为若干子集合，形成若干子关系模式。垂直分解的原则是，将经常在一起使用的属性从R中分解出来形成一个子关系模式。垂直分解可以提高某些事务的效率，但也可能使另一些事务不得不执行连接操作，从而降低了效率。因此是否进行垂直分解取决于分解后的所有事务的总效率是否得到了提高。垂直分解需要确保无损连接性和保持函数依赖，即保证分解后的关系具有无损连接性和保持函数依赖性。这可以用模式分解算法对需要分解的关系模式进行分解和检查。

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

将概念模型转换为全局逻辑模型后，还应该根据局部应用需求，结合具体DBMS的特点，设计用户的外模式。

外模式是用户所看到的数据模式，各类用户有各自的外模式。外模式不单是逻辑模式的子集，虽然它来自逻辑模式，但在结构和形式上可以不同于逻辑模式，甚至可以采用不同的数据模型，不过一般都用同一数据模型。外模式的主要作用有如下三点。

1)提供一定的逻辑数据独立性

数据库的逻辑模式是会随着应用而不断地扩充、修改和重构的。逻辑模式变了，使用这些逻辑模式的应用程序也须做相应的修改，这是很麻烦的维护工作。有了外模式这一级后，尽管逻辑模式变了，我们仍然可以通过外模式使用户看到的数据模式不变，也就是用外模式屏蔽掉逻辑模式的变化。因此，外模式可以提供一定的逻辑数据独立性，即应用程序在一定程度上不受逻辑模式变化的影响。

2)更好地适应不同用户对数据的需求

一个综合数据库是非常庞大而复杂的。对某一用户来说，不需要了解所有的数据，也不希望了解这么多的数据，用户只希望数据库提供他所关心的数据，少了也不行，多了也不好，最好这个数据库是为他个人服务似的。例如，在一个大学中，人事部门只希望了解与人事有关的数据，而后勤部门对教务方面的数据就不感兴趣；同样是人事方面的数据，但教务处、科研处、研究生院所需要的数据各有不同。数据库技术解决了数据的集中管理和共享问题，这是一大进步，但是如果大家看到的都是同一数据模式，这也影响数据库的推广和使用。外模式比较好地解决了集中共享和个别需要兼顾的问题。

3)有利于数据保密

众所周知，保密的原则就是不让人知道他不该知道的事情。外模式实际上为用户划定了访问数据的范围，因而有利于保密。

如何实现外模式呢?单靠控制数据的访问权限是不够的，必须提供一些手段来对概念模式进行修改和变换。

目前，关系数据库管理系统一般都提供了视图(View)概念，可以为用户定义他们所希望看到的虚表，设计出更符合局部用户需要的用户外模式。一部分与用户有关的基表，加上按需要为之定义的视图，就构成了一个用户的外模式，在设计外模式时，可以参照局部E-R图，因为局部E-R图本来就是用户对数据需求的反映。有了逻辑模式，设计外模式就比较简单了。因此，外模式的设计可以看成数据库逻辑设计的一部分。

定义数据库全局模式主要是从系统的时间效率、空间效率、易维护等角度出发的。由于用户外模式与模式是相对独立的，因此在定义用户外模式时可以注重考虑用户的习惯与方便。包括：

(1)使用符合用户习惯的别名。在合并各分E-R图时，曾做了消除命名冲突的工作，以使数据库系统中同一关系和属性具有唯一的名字。这在设计数据库整体结构时是非常必要的。用View机制可以在设计用户View时重新定义某些属性名，使其与用户习惯一致，以方便使用。

(2)可以对不同级别的用户定义不同的View，以保证系统的安全性。

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

数据库物理设计的任务是选择合适的存储结构和存取路径，也就是设计数据库的内模式。内模式和逻辑模式不一样，它不直接面向用户，一般的用户不一定、也不需要了解内模式的设计细节。内模式的设计可以不考虑用户理解的方便，其主要的设计目标有两个：一是提高数据库的性能，特别是满足主要应用的性能要求；二是有效地利用存储空间。在这两个目标中，第一个目标也许更为重要，因为性能仍然是当今数据库系统的薄弱环节。7.5物理结构设计数据库用户通过DBMS使用数据库。数据库的物理设计只能在DBMS所提供的手段范围内，根据需求和实际条件适当地选择。数据库的物理设计比起逻辑设计，更加依赖于DBMS。在进行数据库的物理设计时，设计者必须仔细阅读DBMS的有关手册，充分了解其限制条件，充分利用其提供的各种手段。

数据库的物理设计与多种因素有关，除了应用的处理需求(例如事务的内容和事务出现的频率外，还与数据的特性(例如属性值的分布、元组的长度及个数等)有关。处理需求会随应用环境的不同而变化，数据特性也会随数据库状态的改变而变化，而且数据特性在数据库设计阶段很难准确估计。此外，在物理设计时还要考虑DBMS、操作系统以及计算机硬件的特性。以整个计算机系统来说，数据库应用仅是其负荷的一部分。数据库的性能不但决定于数据库的设计，而且与计算机系统的运行环境有关。例如，计算机系统是单用户还是多用户的，负荷的轻重如何，数据库分布在多个磁盘组上还是集中在单个磁盘组上，磁盘是数据库专用的还是全系统共享的等。在数据库物理设计时，可供选择的方案很多，例如，各种文件结构和存取路径的选择就可以形成庞大的组合。要穷尽各种可能，寻求最佳设计，几乎是不可能的。目前，数据库的物理设计不外乎有两种途径：第一种用启发式方法，即根据一般的原则和需求说明，选择方案；第二种用启发式方法初选一批较好的方案，再用代价比较法从中选出一个最好的。第一种方法主要用于人工设计；第二种方法主要用于计算机辅助设计工具。数据库的设计和一般产品的设计不一样，数据库设计只提供一个初始设计(InitialDesign)，在数据库运行过程中还可根据用户的要求不断地调整(Tuning)，过分追求所谓精确设计，企图一次成功，是不符合数据库应用特点的。

数据库的物理设计通常分为两步：

(1)确定数据库的物理结构，在关系数据库中主要指存取方法和存储结构。

(2)对物理结构进行评价，评价的重点是时间和空间效率。

如果评价结果满足原设计要求，则可进入到物理实施阶段，否则，就需要重新设计或修改物理结构，有时甚至要返回逻辑设计阶段修改数据模型。7.5.1数据库的物理设计的内容和方法

不同的数据库产品所提供的物理环境、存取方法和存储结构有很大差别，能供设计人员使用的设计变量、参数范围也很不相同，因此没有通用的物理设计方法可遵循，只能给出一般的设计内容和原则。希望设计优化的物理数据库结构，使得在数据库上运行的各种事务响应时间小、存储空间利用率高、事务吞吐率大。为此，首先对要运行的事务进行详细分析，获得和选择物理数据库设计所需要的参数。其次，要充分了解所用的DBMS的内部特征，特别是系统提供的存取方法和存储结构。对于数据库查询事务，需要得到如下信息：

·查询的关系。

·查询条件所涉及的属性。

·连接条件所涉及的属性。

·查询的投影属性。

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

·被更新的关系。

·每个关系上的更新操作条件所涉及的属性。

·修改操作要改变的属性值。

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

上述这些信息是确定关系的存取方法的依据。

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

通常，关系数据库物理设计的内容主要包括：

·为关系模式选择存取方法。

·设计关系、索引等数据库文件的物理存储结构。7.5.2关系模式存取方法选择

数据库系统是多用户共享的系统，对同一个关系要建立多条存取路径才能满足多用户的多种应用要求。也就是要确定选择哪些存取方法，即建立哪些存取路径。

存取方法是快速存取数据库中数据的技术。数据库管理系统一般都提供多种存取方法。常用的存取方法有三类：第一类是索引方法，目前主要是B+树索引方法；第二类是聚簇(Cluster)方法，又称簇集；第三类是HASH方法。B+树索引方法是数据库中经典的存取方法，使用最普遍。

1．索引存取方法的选择

所谓索引存取方法，实际上就是根据应用要求确定对关系的哪些属性列建立索引、哪些属性列建立组合索引、哪些索引要设计为唯一索引等。索引的选择是数据库物理设计的基本问题之一，也是比较困难的问题。原则上可以穷举各种可能的方案，进行代价估算，从中挑选最佳的方案。但这样做至少有下面5个困难。

1)数据库中的文件不是孤立的，要考虑彼此的影响

传统的文件设计都是把一个文件作为孤立的设计对象，这在数据库中就有些不合适了。例如，关系数据库中有连接操作，常涉及多个文件，在计算某关系进行连接操作的代价时，往往与其他关系参与连接操作的方法有关，这就使得各个文件往往不能孤立地设计。

2)解空间太大，即使使用计算机计算，也难以承受

为了说明这个问题，不妨举一个具有五个文件的数据库的例子，设每个文件有五个属性(这是偏小的估计)。对于每个文件，最多可按其中一个属性簇集或排序，也就是在记录的存放方式方面，每个文件有六种可能(包括无序情况)。对每个文件的每个属性可以建立索引，也可以不建立索引，因而每个文件在建立索引方面有25种可能。如果把这些情况组合起来，则这个小数据库的存取结构的可能方案有65×(25)6种，而实际的数据库的文件数一般远不止五个，而且不但在单属性上可以建立索引，在多属性上也可建立索引。显然，这样的解空间太大了。

3)访问路径与DBMS的优化策略有关

对于某一事务，如何执行，不仅决定于数据库设计者所提供的访问路径，而且还决定于DBMS的优化策略。如果设计者所认为的事务执行方式不同于DBMS实际执行事务的方式，将导致设计结果与实际的偏离。有些DBMS提供EXPLAIN命令，可以通过这种命令了解一个查询语句的执行情况和有关执行的统计数据。这有助于缓解这方面的困难。

4)设计目标比较复杂

总的来说，数据库设计的目标是在系统的制约条件下，最大限度地满足应用的需要。就数据库的物理设计来说，一般须考虑减少CPU代价、I/O代价以及存储代价。而这三种代价又互相影响，减少某种代价常会导致另一种代价的增加。对于存储代价，有些系统只要求不超过某一限制值就行了，有些则希望尽可能压低存储代价。数据库的各种不同的应用，对前述三方面的要求也各不一样。有些事务执行得慢一点还可以接受，有些则不行。以上这些因素如果在设计中都要考虑，则问题将变得非常复杂。

5)代价估算比较困难

CPU代价涉及到系统软件和运行环境，很难准确估计。I/O代价和存储代价比较容易估算，但代价模型与系统有关，很难形成一套通用的代价估算公式。代价估算还与数据本身的特性有关，必须对数据进行统计分析，才能获得所必需的设计参数，而在数据库设计阶段，对数据特性的了解往往是不充分的。

鉴于上述原因，在手工设计时，一般按启发式规则选择索引。即使在数据库的计算机辅助设计工具中，也是先用启发式规则限制选择范围，再用简化的代价比较法选择索引。下面介绍用启发式规则选择索引的一般步骤：

(1)确定文件的存储结构，即记录的存放是无序的(堆文件)，还是按主键排序或按某一属性或属性组簇集存放的。

(2)凡是满足下列条件之一的属性或表，不宜建立索引。

①不出现或很少出现在查询条件中的属性。

②属性值很少的属性。例如，属性“性别”只有两个值，若在其上建立索引，则平均起来，每个属性值对应一半的元组，因此用索引检索还不如顺序扫描。

③属性值分布严重不均的属性。例如，学生的年龄往往集中在几个属性值上，若在年龄属性上建立索引，则在检索某个年龄的学生时，会涉及到相当多的学生，因此用索引查询还不如顺序扫描。

④经常更新的属性或表。因为更新时索引需要维护。

⑤过长的属性。例如，超过30个字节。因为在过长的属性上建立索引，索引所占的存储空间较大，而且索引级数也随之增加，有诸多不利之处。如果实在需要在其上建立索引，必须采取索引键压缩措施。

⑥太小的表。例如，小于6个物理块的表。因为采用顺序扫描最多也不过6次I/O，不值得采用索引。

(3)凡符合下列条件之一的属性和表，可以考虑在有关属性上建立索引。

①主键和外键上一般都建有索引。这样做带来如下好处：

·有利于主键唯一性检查。

·有助于引用完整性约束检查。在检查引用完整性约束时，删、改主键须检查有无引用此主键的外键；增、改外键要检查是否有对应的主键。在主键和外键上都建立索引，显然可以方便这种检查。

·可以加速以主键和外键为连接属性的连接操作。这种连接非常普遍，若在主键和外键上都建有索引，则可减少连接开销。

②对于以读为主或只读的表，只要需要，且存储空间允许，则可以多建索引。

③对于等值查询(即查询条件以等号为比较符)，如果满足条件的元组是少量的，如小于5％，则可以考虑在有关属性上建立索引。

④对于范围查询(即查询条件以<、>、≤、≥等为比较符)，最好在有关的属性上建立簇集索引。如果已在其他属性上建立簇集索引，且满足条件的元组数一般低于15％，则可以考虑在有关属性上建立非簇集索引。

⑤有些查询可以从索引直接得到结果，不必访问数据块。对于这种查询，在有关属性上建立索引是有利的。这些查询有：查询某属性的MIN、MAX、AVG、SUM、COUNT等聚集函数值(无GROUPBY子句)，可沿该属性的索引的顺序集扫描，直接求得结果；查询某属性值EXISTS或NOTEXISTS，只要通过该属性的索引就可获得结果，不必访问数据块。

⑥如果一个(或一组)属性经常在查询条件中出现，则考虑在这个(或这组)属性上建立索引(或组合索引)。

⑦如果一个(或一组)属性经常在连接操作的连接条件中出现，则考虑在这个(或这组)属性上建立索引。

上述选择索引的规则仅仅是原则性的。也许有些索引既有建立的理由，又有不宜建立的理由，这只能由设计者权衡。数据库在运行以后，还可能需要调整。有些索引一时难以决定是否建立，可以留待运行时通过实验来确定。

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

2．簇集存取方法的选择

簇集就是把某个属性或属性组(称为簇集码)上具有相同值的有关元组集中在一个物理块内或物理上相邻的区域内，以提高某些数据访问的速度。簇集功能可以大大提高按簇集码进行查询的效率。为了说明簇集的必要性，不妨举个简单的例子。设有一关系TEACHER(教