数据库的一般设计方法

5.1.5　数据库的一般设计方法

数据库是将大量相关数据按一定的模式组织在一起，以满足应用的需求。因此，如何合理地将这些数据集中在数据库中，是实现数据存储、使用和维护功能的关键。数据库设计是数据库应用系统开发和建设的首要任务。根据规范化设计方法，将数据库设计归纳为需求分析、概念结构设计、逻辑结构设计、物理结构设计、数据库实施、数据库的使用和维护等六个阶段，如图5-13所示。

图5-13　数据库设计步骤

1.需求分析阶段

1)需求分析的任务

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

需求分析的重点是调查、收集与分析用户在数据管理中的信息要求、处理要求、安全性与完整性要求。信息要求是指用户需要从数据库中获得信息的内容与性质。由用户的信息要求可以导出数据要求，即在数据库中需要存储哪些数据。处理要求是指用户要求完成什么处理功能，对处理的响应时间有什么要求，处理方式是批处理还是联机处理。新系统的功能必须能够满足用户的信息要求、处理要求、安全性与完整性要求。

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

2)需求分析的方法

需求分析首先从调查组织机构情况开始，包括了解该组织的部门组成情况、各部门的职能等，为分析信息流程作准备。然后调查各部门的业务活动情况，包括了解各个部门输入和使用什么数据，如何加工处理这些数据，输出什么信息，输出到什么部门，输出结果的格式是什么。调查时需协助用户明确对新系统的各种要求，包括信息要求、处理要求、完全性与完整性要求。根据需求分析调查的结果，确定新系统的边界，确定哪些功能由计算机完成或将来准备让计算机完成，哪些活动由人工完成，由计算机完成的功能就是新系统应该实现的功能。常用的调查方法有如下几种。

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

(2)开调查会。通过与用户座谈来了解业务活动情况及用户需求。座谈时，参加者之间可以相互启发。

(3)请专人介绍。

(4)询问。对某些调查中的问题，可以找专人询问。

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

(6)查阅记录。即查阅与原系统有关的数据记录，包括原始单据、账簿、报表等。

通过调查了解了用户需求后，还需要进一步分析用户的需求。分析用户需求的方法主要包括自顶向下和自底向上两类方法。

自顶向下的结构化分析方法(structured analysis，SA)从最上层的系统组织机构入手，采用逐层分解的方式分析系统，并且把每一层用数据流图和数据字典进行描述。

以学校管理信息系统为例，学校管理信息系统管理高层数据流图如图5-14所示。

然后将处理功能的具体内容分解为若干子功能，再将每个子功能继续进行分解，直到表达清楚系统的工作过程为止。学校管理信息系统管理高层逐层分解后的数据流图如图5-15所示。

图5-14　学校管理高层数据流图

图5-15　逐层分解后的数据流图

在处理功能逐步分解的同时，其所用的数据也逐级进行分解，形成若干层次的数据流图。数据流图表达了数据和处理过程的关系。学校管理信息系统学籍管理的数据流图如图5-16所示。

图5-16　学籍管理的数据流图

系统中的数据则借助数据字典(data dictionary，DD)来描述。

3)数据字典

对数据库设计来讲，数据字典是进行数据收集和数据分析所获得的主要成果。数据字典是各类数据描述的集合。

数据字典通常包括数据项、数据结构、数据流、数据存储和处理过程五个部分。(1)数据项。数据项是不可再分的数据单位。对数据项的描述通常包括以下内容：

数据项描述＝｛数据项名，数据项含义说明，别名，数据类型，长度，取值范围，取值含义，与其他数据项的逻辑关系｝

其中，取值范围、与其他数据项的逻辑关系定义了数据的完整性约束条件，是设计数据检验功能的依据。

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

数据结构描述＝｛数据结构名，含义说明，组成:｛数据项或数据结构｝｝

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

数据流描述＝｛数据流名，说明，数据流来源，数据流去向，组成:｛数据结构｝，平均流量，高峰期流量｝

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

(4)数据存储。数据存储是数据结构停留或保存的地方，也是数据流的来源和去向之一。对数据存储的描述通常包括以下内容：

数据存储描述＝｛数据存储名，说明，编号，流入的数据流，流出的数据流，组成:｛数据结构｝，数据量，存取方式｝

其中，数据量是指每次存取多少数据，每天(或每小时、每周等)存取几次信息。存取方法包括是批处理还是联机处理，是检索还是更新，是顺序检索还是随机检索等。另外，流入的数据流要指出其来源，流出的数据流要指出其去向。

(5)处理过程。数据字典中只需要描述处理过程的说明性信息，通常包括以下内容：

处理过程描述＝｛处理过程名，说明，输入:｛数据流｝，输出:｛数据流｝, 处理:｛简要说明｝｝

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

数据字典是关于数据库中数据的描述，即元数据，而不是数据本身。数据本身将存放在物理数据库中，由数据库管理系统管理。数据字典有助于这些数据的进一步管理和控制，为设计人员和数据库管理员在数据库设计、实现和运行阶段控制有关数据提供依据。以学生学籍管理子系统为例，简要说明如何定义数据字典。该子系统涉及很多数据项，其中的“学号”数据项如表5-2所示。

表5-2　“学号”数据项描述

“学生”是该系统中的一个核心数据结构，如表5-3所示。

表5-3　“学生”数据项描述

数据流“体检结果”如表5-4所示，数据存储“学生登记表”如表5-5所示。

表5-4　数据流“体检结果”数据项描述

表5-5　数据存储“学生登记表”数据项描述

处理过程“分配宿舍”如表5-6所示。

表5-6　处理过程“分配宿舍”数据项描述

数据字典中关于其他数据项、数据结构、数据流、数据存储、处理过程的描述，读者可参阅其他资料。

2.概念结构设计阶段

将需求分析得到的用户需求抽象为信息结构，即概念模型的过程就是概念结构设计。概念结构是对现实世界的一种抽象，即对实际的人、物、事和概念进行人为处理，抽取人们关心的共同特性，忽略非本质的细节，并把这些特性用各种概念精确地加以描述。通过对用户需求进行综合、归纳与抽象，形成一个独立于具体DBMS的概念数据模型，可以用E-R图表示。

概念结构独立于数据库逻辑结构，也独立于支持数据库的DBMS。它是现实世界与机器世界的中介，它一方面能够充分反映现实世界，包括实体和实体之间的联系，同时又易于向关系、网状、层次等各种数据模型转换。它是现实世界的一个真实模型，易于理解，便于和不熟悉计算机的用户交换意见，使用户易于参与，当现实世界需求改变时，概念结构又可以很容易地进行相应调整。因此，概念结构设计是整个数据库设计的关键所在。

1)概念结构设计方法与步骤

设计概念结构通常有以下四类方法。

(1)自顶向下。即首先定义全局概念结构的框架，然后逐步细化。

(2)自底向上。即首先定义各局部应用的概念结构，然后将它们集成起来，得到全局概念结构。最常采用的策略是自底向上方法。即自顶向下地进行需求分析，然后再自底向上地设计概念结构。

(3)逐步扩张。首先定义最重要的核心概念结构，然后向外扩充，以滚雪球的方式逐步生成其他概念结构，直至总体概念结构。

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

无论采用哪种设计方法，一般都以E-R模型为工具来描述概念结构。

2)数据抽象与局部视图设计

以自底向上设计概念结构的方法为例，它通常分为两步：第一步，首先要根据需求分析的结果(数据流图、数据字典等)对现实世界的数据进行抽象，设计各个局部视图即分E-R图；第二步，集成局部视图。

设计分E-R图的步骤：首先选择局部应用。在需求分析阶段，通过对应用环境和要求进行详尽的调查分析，用多层数据流图和数据字典描述整个系统。设计分E-R图的第一步，就是要根据系统的具体情况，在多层的数据流图中选择一个适当层次的(经验很重要)数据流图，让该组图中的每一部分对应一个局部应用，即可以这一层次的数据流图为出发点，设计分E-R图。一般而言，中层的数据流图能较好地反映系统中各局部应用的子系统组成，因此往往以中层数据流图作为设计分E-R图的依据，然后逐一设计分E-R图。每个局部应用都对应了一组数据流图，局部应用涉及的数据都已经收集在数据字典中了。现在就是要将这些数据从数据字典中抽取出来，参照数据流图，标定局部应用中的实体、实体的属性、标识实体的码，确定实体之间的联系及其类型(1:1、1:n、m:n)。

现实世界中一组具有某些共同特性和行为的对象就可以抽象为一个实体。对象和实体之间是“is member of”的关系。例如，在学校环境中，可以把张三、李四、王五等对象抽象为学生实体。 对象类型的组成成分可以抽象为实体的属性。组成成分与对象类型之间是“is part of”的关系。例如，学号、姓名、专业、年级等可以抽象为学生实体的属性，其中学号为标识学生实体的码。实际上，实体与属性是相对而言的，很难有截然划分的界限。同一事物，在一种应用环境中作为“属性”，在另一种应用环境中就必须作为“实体”。一般说来，在给定的应用环境中，属性不能再具有需要描述的性质，即属性必须是不可分的数据项。属性不能与其他实体具有联系，联系只发生在实体之间。

在本书的实例中，学籍管理局部应用中主要涉及的实体包括学生、宿舍、档案材料、班级、班主任。那么，这些实体之间的联系又是怎样的呢？

由于一个宿舍可以住多个学生，而一个学生只能住在某一个宿舍中，因此宿舍与学生之间是1:n的联系。由于一个班级往往有若干名学生，而一个学生只能属于一个班级，因此班级与学生之间也是1:n的联系。由于班主任同时还要授课，因此班主任与学生之间存在指导联系，一个班主任要教多名学生，而一个学生只对应一个班主任，因此班主任与学生之间也是1:n的联系。而学生和他自己的档案材料之间，班级与班主任之间都是1:1的联系。

接下来需要进一步斟酌该E-R图，做出适当调整。一般情况下，性别通常作为学生实体的属性，但在本局部应用中，由于宿舍分配与学生性别有关，根据准则2，应该把性别作为实体对待。由于数据存储“学生登记表”是手工填写，供存档使用，其中有用的部分已转入学生档案材料中，因此这里就不必作为实体了。这样，得到学籍管理局部应用的分E-R图如图5-17所示。

图5-17　学籍管理局部应用的分E-R图

各个实体的属性分别包含如下内容。

学生：｛学号，姓名，出生日期，｝

档案材料：｛档案号，……｝

班级：｛班级号，学生人数｝

班主任：｛职工号，姓名，性别，是否为优秀班主任｝

宿舍：｛宿舍编号，地址，人数｝

教室：{教室编号，地址，容量}

其中有下划线的属性为实体的码。同样方法，可以得到课程管理局部应用的分E-R图，如图5-18所示。

图5-18　课程管理局部应用的分E-R图

各实体的属性分别如下。

学生：｛姓名，学号，性别，年龄，所在系，年级，平均成绩｝

课程：｛课程号，课程名，学分｝

教师：｛职工号，姓名，性别，职称｝

教科书：｛书号，书名，价钱｝

教室：｛教室编号，地址，容量｝

接下来的工作是视图的集成。集成局部E-R图时都需要两步，即合并后修改与重构。

在合并分E-R图、生成初步E-R图的过程中，各分E-R图之间有三类冲突，即属性冲突、命名冲突和结构冲突。

属性冲突落实到属性域冲突，即属性值的类型、取值范围或取值集合不同，还包含属性取值单位冲突。命名冲突包含同名异义和异名同义(一义多名)两种。结构冲突包含如下几种。

(1)同一对象在不同应用中具有不同的抽象。例如“课程”在某一局部应用中被当作实体，而在另一局部应用中则被当作属性。

(2)同一实体在不同局部视图中所包含的属性不完全相同，或者属性的排列次序不完全相同。

(3)实体之间的联系在不同局部视图中呈现不同的类型。例如，实体E1与E2在局部应用A中是多对多联系，而在局部应用B中是一对多联系；又如在局部应用X中E1与E2发生联系，而在局部应用Y中E1、E2、E3三者之间有联系。冲突的解决方法是根据应用的语义对实体联系的类型进行综合或调整。

下面来看看如何生成学校管理系统的初步E-R图。本例着重介绍学籍管理局部视图与课程管理局部视图的合并。这两个分E-R图存在着多方面的冲突。

(1)班主任实际上也属于教师，也就是说，学籍管理中的班主任实体与课程管理中的教师实体在一定程度上属于异名同义，可以将学籍管理中的班主任实体与课程管理中的教师实体统一称为教师，统一后教师实体的属性构成为：

教师：｛职工号，姓名，性别，职称，是否为优秀班主任｝

(2)将班主任改为教师后，教师与学生之间的联系在两个局部视图中呈现两种不同的类型，一种是学籍管理中教师与学生之间的指导联系，一种是课程管理中教师与学生之间的教学联系，由于指导联系实际上可以包含在教学联系之中，因此可以将这两种联系综合为教学联系。

(3)在两个局部E-R图中，学生实体属性组成及次序都存在差异，应将所有属性综合并重新调整次序。假设调整结果为：

学生：｛学号，姓名，出生日期，年龄，所在系，年级，平均成绩｝

解决上述冲突后，学籍管理分E-R图与课程管理分E-R图合并为初步E-R图。

3)修改与重构，生成基本E-R图

分E-R图经过合并生成的是初步E-R图。之所以称其为初步E-R图，是因为其中可能存在冗余的数据和冗余的实体间联系，即存在可由基本数据导出的数据和可由其他联系导出的联系。冗余数据和冗余联系容易破坏数据库的完整性，给数据库维护增加难度，因此得到初步E-R图后，还应当进一步检查E-R图中是否存在冗余，如果存在，则一般应设法予以消除。

修改、重构初步E-R图以消除冗余主要采用分析方法。除分析方法外，还可以用规范化理论来消除冗余。

在前面初步E-R图中存在着一些冗余数据和冗余联系。如学生实体中的年龄属性可以由出生日期推算出来，属于冗余数据，应该去掉。这样不仅可以节省存储空间，而且当某个学生的出生日期有误，进行修改后，无须相应修改年龄，减少了产生数据不一致的机会。

学生｛学号，姓名，出生日期，所在系，年级，平均成绩｝

另外，教室实体与班级实体之间的上课联系可以由教室与课程之间的开设联系、课程与学生之间的选修联系、学生与班级之间的组成联系三者推导出来，因此属于冗余联系，可以消去。学生实体中的平均成绩可以从选修联系中的成绩属性中推算出来，但如果应用中需要经常查询某个学生的平均成绩，每次都进行这种计算效率就会太低，因此为了提高效率，可以考虑保留该冗余数据，但是为了维护数据一致性应该定义一个触发器来保证学生的平均成绩等于该学生各科成绩的平均值。任何一科成绩修改后，或该学生学习了新的科目并有成绩后，就要触发该触发器去修改该学生的平均成绩属性值；否则会出现数据的不一致。进行修改和重构后生成的基本E-R图如图5-19所示。

图5-19　进行修改和重构后生成的基本E-R图

学生管理子系统的基本E-R图还必须进一步和教师管理子系统以及后勤管理子系统的基本E-R图合并，生成整个学校管理系统的基本E-R图。

视图集成后形成一个整体的数据库概念结构，对该整体概念结构还必须进行进一步验证，确保它能够满足下列条件：

(1)整体概念结构内部必须具有一致性，即不能存在互相矛盾的表达；

(2)整体概念结构能准确地反映原来的每个视图结构，包括属性、实体及实体间的联系；

(3)整体概念结构能满足需要分析阶段所确定的所有要求；

(4)整体概念结构最终还应该提交给用户，征求用户和有关人员的意见，进行评审、修改和优化，然后把它确定下来，作为数据库的概念结构，作为进一步设计数据库的依据。

3．逻辑结构设计阶段

设计逻辑结构应该选择最适于描述与表达相应概念结构的数据模型，然后将概念结构转换为某个DBMS所支持的结构数据模型(如关系模型)，并对其进行优化。

设计逻辑结构时一般要分三步进行：首先将概念结构转换为一般的关系、网状、层次模型；然后将转化来的关系、网状、层次模型向特定DBMS支持下的数据模型转换；最后对数据模型进行优化。

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

1)E-R图向关系模型转换

(1)一个实体型转换为一种关系模式。实体的属性就是关系的属性，实体的码就是关系的码。例如，学生实体可以转换为如下关系模式，其中学号为学生关系的码：学生(学号，姓名，出生日期，所在系，年级，平均成绩)，同样，性别、宿舍、班级、档案材料、教师、课程、教室、教科书都分别转换为一种关系模式。

(2)一个m:n联系转换为一种关系模式。与该联系相连的各实体的码以及联系本身的属性均转换为关系的属性，而关系的码为各实体码的组合。

例如“选修”联系是一个m:n联系，可以将它转换为如下关系模式，其中学号与课程号为关系的组合码：

选修(学号，课程号，成绩)

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

例如，“组成”联系为1:n联系，将其转换为关系模式是使其成为一种独立的关系模式：组成(学号，班级号),其中学号为“组成”关系的码。

另一种方法是将其学生关系模式合并，这时学生关系模式为：学生(学号,姓名,出生日期,所在系,年级,班级号,平均成绩)。后一种方法可以减少系统中的关系个数，一般情况下更倾向于采用这种方法。

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

例如，“管理”联系为1:1联系，可以将其转换为一种独立的关系模式：

管理(职工号，班级号)或 管理(职工号，班级号)。“管理”联系也可以与班级或教师关系模式合并。如果与班级关系模式合并，则只需在班级关系中加入教师关系的码，即职工号：

班级：｛班级号，学生人数，职工号｝

同样，如果与教师关系模式合并，则只需在教师关系中加入班级关系的码，即班级号：

教师：｛职工号，姓名，性别，职称，班级号，是否为优秀班主任｝

(5)三个或三个以上实体间的一个多元联系转换为一种关系模式。与该多元联系相连的各实体的码以及联系本身的属性均转换为关系的属性，而关系的码为各实体码的组合。

例如，“讲授”联系是一个三元联系，可以将它转换为如下关系模式，其中课程号、教师号和书号为关系的组合码。

讲授(课程号，教师号，书号)

(6)同一实体集的实体间的联系，即自联系，也可按上述1:1、1:n和m:n三种情况分别进行处理。

例如，如果教师实体集内部存在领导与被领导的1:n自联系，可以将该联系与教师实体合并，这时主码职工号将多次出现，但作用不同，可用不同的属性名加以区分，比如在合并后的关系模式中，主码仍为职工号，再增设一个“系主任”属性，存放相应系主任的职工号。

(7)具有相同码的关系模式可合并。为了减少系统中的关系个数，如果两个关系模式具有相同的主码，则可以考虑将其合并为一种关系模式。合并方法是将其中一种关系模式的全部属性加入另一种关系模式中，然后去掉其中的同义属性(可能同名也可能不同名)，并适当调整属性的次序。

例如，有一种“拥有”关系模式：拥有(学号，性别)，有一种学生关系模式：学生(学号，姓名，出生日期，所在系，年级，班级号，平均成绩)。这两种关系模式都以学号为码，可以将它们合并为一种关系模式，假设合并后的关系模式仍叫学生：学生(学号，姓名，性别，出生日期，所在系，年级，班级号，平均成绩)。

按照上述七条原则，学生管理子系统中的18个实体和联系可以转换为下列关系模型：

学生(学号，姓名，性别，出生日期，所在系，年级，班级号，平均成绩，档案号)；

性别(性别，宿舍楼)；

宿舍(宿舍编号，地址，性别，人数)；

班级(班级号，学生人数)；

教师(职工号，姓名，性别，职称，班级号，是否为优秀班主任)；

教学(职工号，学号)；

课程(课程号，课程名，学分，教室号)；

选修(学号，课程号，成绩)；

教科书(书号，书名，价钱)；

教室(教室编号，地址，容量)；

讲授(课程号，教师号，书号)；

档案材料(档案号，……)。

该关系模型由12种关系模式组成。其中学生关系模式包含了“拥有”联系、“组成”联系、“归档”联系所对应的关系模式；教师关系模式包含了“管理”联系所对应的关系模式；宿舍关系模式包含了“住宿”联系所对应的关系模式；课程关系模式包含了“开设”联系所对应的关系模式。

2)数据模型优化

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

数据模型的优化方法如下所述。

(1)确定数据依赖。对于各种关系模式之间的数据依赖进行极小化处理，消除冗余的联系。按照数据依赖的理论对关系模式逐一进行分析，考察是否存在部分函数依赖、传递函数依赖、多值依赖等，确定各关系模式分别属于第几范式(请参看其他资料)。

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

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

(3)设计用户子模式。前面根据用户需求设计了局部应用视图，这种局部应用视图只是概念模型，用E-R图表示。将概念模型转换为逻辑模型后，即生成了整个应用系统的模式后，还应该根据局部应用需求，结合具体DBMS的特点，设计用户的外模式。

目前关系数据库管理系统一般都提供了视图概念，支持用户的虚拟视图。可以利用这一功能设计更符合局部用户需要的用户外模式。

定义数据库模式主要是从系统的时间效率、空间效率、易维护等角度出发的。由于用户外模式与模式是独立的，因此在定义用户外模式时应该更注重考虑用户的习惯与方便，包括使用更符合用户习惯的别名；针对不同级别的用户定义不同的外模式，以满足系统对安全性的要求；简化用户对系统的使用等。

4．数据库物理设计阶段

数据库最终是要存储在物理设备上的。为一个给定的逻辑数据模型选取一个最适合应用环境的物理结构(存储结构与存取方法)的过程，就是数据库的物理设计。物理结构依赖于给定的DBMS和硬件系统，因此设计人员必须充分了解所用DBMS的内部特征，特别是存储结构和存取方法，充分了解应用环境，特别是应用的处理频率和响应时间要求，以及充分了解外存设备的特性。

数据库的物理设计通常分为确定数据库的物理结构和对物理结构进行评价，评价的重点是时间和空间效率两步。

1)确定数据库的物理结构

(1)确定数据的存储结构。

确定数据库存储结构时要综合考虑存取时间、存储空间利用率和维护代价三方面的因素。这三个方面常常是相互矛盾的，例如消除一切冗余数据虽然能够节约存储空间，但往往会增加检索的代价，因此必须进行权衡，选择一个折中方案。

许多关系型DBMS都提供了聚簇功能，即为了提高某个属性(或属性组)的查询速度，把在这个或这些属性上有相同值的元组集中存放在一个物理块中，如果存放不下，则可以存放到预留的空白区或链接多个物理块。

聚簇功能可以大大提高按聚簇码进行查询的效率。例如，假设学生关系按所在系建有索引，现在要查询信息系的所有学生名单，设信息系有120名学生，在极端情况下，这120名学生所对应的元组分布在120个不同的物理块上，由于每访问一个物理块需要执行一次I/O操作，因此该查询即使不考虑访问索引的I/O次数，也要执行120次I/O操作。如果将同一系的学生元组集中存放，则每读一个物理块可得到多个满足查询条件的元组，从而显著地减少了访问磁盘的次数。

聚簇以后，聚簇码相同的元组集中在一起，因而聚簇码值不必在每个元组中重复存储，只要在一组中存一次就行，因此可以节省一些存储空间。

聚簇功能不但适用于单个关系，也适用于多个关系。假设用户经常要按系别查询学生成绩单，这一查询涉及学生关系和课程关系的连接操作，即需要按学号连接这两个关系，为提高连接操作的效率，可以把具有相同学号值的学生元组和课程元组在物理上聚簇在一起。

必须注意的是，聚簇只能提高某些特定应用的性能，而且建立与维护聚簇的开销是相当大的。对已有关系建立聚簇，将导致关系中元组移动其物理存储位置，并使此关系上原有的索引无效，必须重建。当一个元组的聚簇码改变时，该元组的存储位置也要做相应移动。因此只有在用户应用满足下列条件时才考虑建立聚簇，否则很可能会适得其反。

(2)设计数据的存取路径。

在关系数据库中，选择存取路径主要是指确定如何建立索引。例如，应把哪些域作为次码建立次索引，建立单码索引还是组合索引，建立多少个为合适，是否建立聚集索引等。

(3)确定数据的存放位置。

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

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

(4)确定系统配置。

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

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

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

2)评价物理结构

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

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

5．数据库的实施阶段

数据库的实施主要包括用数据定义语言(data definition language，DDL)定义数据库结构、组织数据入库、编制与调试应用程序和数据库试运行等工作。运用DBMS提供的数据语言(如SQL语言)及其宿主语言(如C语言)，根据逻辑设计和物理设计的结果建立数据库，编制与调试应用程序，组织数据入库，并进行试运行。

1)定义数据库结构

确定了数据库的逻辑结构与物理结构后，就可以用所选用的DBMS提供的数据定义语言来严格描述数据库结构。

2)数据装载

数据库结构建立好后，就可以向数据库中装载数据了。组织数据入库是数据库实施阶段最主要的工作。对于数据量不是很大的小型系统，可以用人工方法完成数据的入库，其步骤如下。

(1)筛选数据。需要装入数据库中的数据通常都分散在各个部门的数据文件或原始凭证中，所以首先必须把需要入库的数据筛选出来。

(2)转换数据格式。筛选出来的需要入库的数据，其格式往往不符合数据库要求，还需要进行转换。这种转换有时可能很复杂。

(3)输入数据。将转换好的数据输入计算机中。

(4)校验数据。检查输入的数据是否有误。对于中大型系统，由于数据量极大，用人工方式组织数据入库将会耗费大量人力物力，而且很难保证数据的正确性。因此应该设计一个数据输入子系统由计算机辅助数据的入库工作。

3)编制与调试应用程序

数据库应用程序的设计应该与数据设计并行进行。在数据库实施阶段，当数据库结构建立好后，就可以开始编制与调试数据库的应用程序，也就是说，编制与调试应用程序是与组织数据入库同步进行的。调试应用程序时由于数据入库尚未完成，可先使用模拟数据。

4)数据库试运行

应用程序调试完成，并且已有一小部分数据入库后，就可以开始数据库的试运行。数据库试运行也称为联合调试，其主要工作包括：功能测试，即实际运行应用程序，执行对数据库的各种操作，测试应用程序的各种功能；性能测试，即测量系统的性能指标，分析是否符合设计目标。

6.数据库使用和维护阶段

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

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

1)数据库的转储和恢复

定期对数据库和日志文件进行备份，以保证一旦发生故障，能利用数据库备份及日志文件备份，尽快将数据库恢复到某种一致性状态，并尽可能减少对数据库的破坏。

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

数据库管理员必须对数据库的安全性和完整性控制负责任。根据用户的实际需要授予不同的操作权限。另外，由于应用环境的变化，数据库的完整性约束条件也会发生变化，也需要数据库管理员不断修正，以满足用户的要求。

3)数据库性能的监督、分析和改进

目前许多DBMS产品都提供了监测系统性能参数的工具，数据库管理员可以利用这些工具方便地得到系统运行过程中一系列性能参数的值。数据库管理员应该仔细分析这些数据，通过调整某些参数来进一步改进数据库性能。

4)数据库的重组织和重构造

数据库运行一段时间后，由于记录的不断增、删、改，会使数据库的物理存储变坏，从而降低数据库存储空间的利用率和数据的存取效率，使数据库的性能下降。这时数据库管理员就要对数据库进行重组织，或部分重组织(只对频繁增、删的表进行重组织)。数据库的重组织不会改变原设计的数据逻辑结构和物理结构，只是按原设计要求重新安排存储位置，回收垃圾，减少指针链，提升系统性能。DBMS一般都提供了供重组织数据库使用的实用程序，帮助数据库管理员重新组织数据库。

当数据库应用环境发生变化时，会导致实体及实体间的联系也发生相应的变化，使原有的数据库设计不能很好地满足新的需求，从而不得不适当调整数据库的模式和内模式，这就是数据库的重构造。DBMS都提供了修改数据库结构的功能。

重构造数据库的程度是有限的。若应用变化太大，已无法通过重构数据库来满足新的需求，或重构数据库的代价太大，则表明现有数据库应用系统的生命周期已经结束，应该重新设计新的数据库系统，开始新数据库应用系统的生命周期了。

以关系数据库为例，设计时一般按照以下的步骤进行。

(1)需求分析。需求分析是数据库设计的基础，是数据库设计的最初阶段。需求分析的目的就是要确定用户要做什么。该阶段要分析用户的要求，详细调查要处理的对象，并加以分析归类和初步规划，确定设计思路，同时要考虑以后可能的功能扩充和改变。需求分析做得好与坏，将直接影响后续设计的质量和速度。

(2)建立数据库中的表。数据库中表的建立是数据库设计过程中最重要的步骤，将直接影响数据库中其他对象的设计和使用。在设计表时，应该遵循以下设计原则。

①一个表对应一个主题。这个主题应该是尽量细化过的，表中的每个字段都是与之相关的，不含无关字段。

②属性的基础性和不可再分性。表中每个属性的数据类型是唯一的，表中不要含有计算数据或推导数据的属性，并且表中的每个属性都必须是不可再分的，对应的数据项是最小的单位。

③记录的唯一性。表中不能含有完全相同的记录。数据库中的每个表必须定义主关键字来保证记录的唯一性。任何一条记录中的主关键字都必须有明确的取值。

④属性间的关系。表中的属性是有一定关系的，包含在主关键字中的属性叫主属性，反之叫非主属性。主关键字唯一确定一条记录，也就是说，非主属性都依赖于主关键字。非主属性间的关系应该是相互独立的。当某个非主属性的值的改变会影响另一个非主属性的值，或者部分主属性的值已经可以唯一确定某个非主属性的值时，需要重新考虑表的划分。

数据库中表的划分和设计原则有一套完整的理论，有兴趣的读者可以参阅其他参考书。下面以一个实例简单介绍表的划分和设计方法。

例5-1　设计一个学生成绩管理系统，需要包括的信息有学号、姓名、性别、出生日期、籍贯、系别、课程号、课程名和成绩。

①根据题目要求可以得到如下关系模式：

学生(学号，姓名，性别，出生日期，籍贯，系别，课程号，课程名，成绩)

明显地，这种关系模式中的主关键字应该是(学号，课程号)。“学号”和“课程号”是主属性，其他的属性都是非主属性。其中非主属性“姓名”、“性别”、“出生日期”、“系别”只与主属性“学号”有关；非主属性“课程名”只与主属性“课程号”有关；非主属性“成绩”则完全依赖于“学号”与“课程号”。由于主关键字是(学号，课程号)，这两个属性必须有明确的值，那么当一个新生刚进校还没有选任何课程时，他的记录就无法插入表中；又或者将某个学生的选课记录都删除后，这个学生的基本信息也随之丢失了。也就是说，这种关系模式存在插入异常和删除异常的问题，这时就需要考虑对表进行重新划分。可将上述关系模式重新划分为以下三种关系模式：

学生(学号，姓名，性别，出生日期，籍贯，系别)

课程(课程号，课程名)

选课(学号，课程号，成绩)

三种关系模式对应三张表，就可以消除上面存在的插入异常和删除异常的问题。

②输入数据并创建其他数据库对象。

在表设计完成之后，就可以在表中添加数据，并且可以创建所需的查询、窗体、报表等其他数据库对象。