系统架构设计笔记（8）——数据库设计

朴灿烈づ我的快乐病毒、 2023-05-28 14:25 21阅读 0赞

数据库设计的过程是将数据库系统与现实世界密切地、有机地、协调一致地结合起来的过程。

数据库的设计质量与设计者的知识、经验和水平密切相关。作为数据库应用系统的重要组成部分，数据库设计的成败往往直接关系到整个应用系统的成败。

以数据库为基础的数据库应用系统与其他计算机应用系统相比往往具有数据量庞大、数据保存时间长、数据关联复杂、用户要求多样化等特点。

数据库设计中面临的主要困难和问题有：  
（1）同时具备数据库知识与应用业务知识的人很少。懂得计算机与数据库的人一般都缺乏应用业务知识和实际经验，而熟悉应用业务的人又往往不懂计算机和数据库。  
（2）项目初期往往不能确定应用业务的数据库系统的目标。  
（3）缺乏完善的设计工具和设计方法。  
（4）需求的不确定性。用户总是在系统的开发过程中不断提出新的要求，甚至在数据库建立之后还会要求修改数据库结构或增加新的应用。  
（ 5）应用业务系统千差万别，很难找到一种适合所有业务的工具和方法，这就增加了研究数据库自动生成工具的难度。因此，研制适合一切应用业务的全自动数据库生成工具是不可能的。

## 1 数据库设计的方法 ##

目前已有的数据库设计方法可分为四类，即直观设计法、规范设计法、计算机辅助设计法和自动化设计法。直观设计法又称单步逻辑设计法，它依赖于设计者的知识、经验和技巧，缺乏工程规范的支持和科学根据，设计质量也不稳定，因此越来越不适应信息管理系统发展的需要。为了改变这种状况， 1978 年 10 月来自 30 多个欧美国家的主要数据库专家在美国新奥尔良市专门讨论了数据库设计问题，提出了数据库设计规范，把数据库设计分为需求分析、概念结构设计、逻辑结构设计和物理结构设计 4 个阶段。目前，常用的规范设计方法大多起源于新奥尔良方法，如基于 3NF 的设计方法、 LRA 方法、 面向对象的数据库设计方法及基于视图概念的数据库设计方法等。我们需要了解基于 3NF 的数据库设计方法。

基于 3NF 的数据库设计方法是由 S.Atre 提出的数据库设计的结构化设计方法，其基本思想是在需求分析的基础上，识别并确认数据库模式中的全部属性和属性间的依赖，将它们组织成一个单一的关系模型，然后再分析模式中不符合 3NF 的约束条件，用投影和连接的办法将其分解，使其达到 3NF 条件。其具体设计步骤分为 5 个阶段，如图 1 所示。

![format_png][]

> 3NF，第三范式(Third Normal Form) 是指表中的所有数据元素不但要能唯一地被主关键字所标识，而且它们之间还必须相互独立，不存在其他的函数关系。

**（1）设计企业模式**  
利用上述得到的 3NF 关系模型画出企业模式。具体包括：

1.  分析应用环境，并设定环境中所使用的各种资料。
2.  确定每一种报表各自所包含的数据元素。
3.  确定数据元素之间的关系，如确定主关键字和一般的数据元素。
4.  对每一组或若干组数据元素推导出 3NF 的关系模型。
5.  在 3NF 关系模型的基础上画出数据库的企业模式。

**（2）设计数据库逻辑模式**

根据上一步得到的企业模式选定数据模型，从而得出适用于某个 DBMS 的逻辑模式。根据逻辑模式导出各种报表与事务处理所使用的外模式。

**（3）设计数据库物理模式（存储模式）**

根据数据库的逻辑模式和给定的计算机系统设计物理模式。

**（4）评价物理模式**

对物理模式估算空间利用情况，并推算输入输出的概率。必要时根据物理模式调整各种报表与事务处理的外模式。对外模式进行存取时间的估算。

**（5）数据库实现**

具体实现数据库。

## 2 数据库设计的基本步骤 ##

分步设计法遵循自顶向下、逐步求精的原则，将数据库设计过程分解为若干相互独立又相互依存的阶段，每一阶段采用不同的技术与工具，解决不同的问题，从而将问题局部化，减少了局部问题对整体设计的影响。目前，此方法已在数据库设计中得到了广泛应用并获得了较好的效果。

在分步设计法中，通常将数据库的设计分为需求分析、概念结构设计、逻辑结构设计和数据库物理设计 4 个阶段，如图 2 所示。

![format_png 1][]

**（1）需求分析**

需求分析是指收集和分析用户对系统的信息需求和处理需求，得到设计系统所必需的需求信息，建立系统说明文档。其目标是通过调查研究，了解用户的数据要求和处理要求，并按一定格式整理形成需求说明书。需求说明书是需求分析阶段的成果，也是今后设计的依据，它包括数据库所涉及的数据、数据的特征、使用频率和数据量的估计，如数据名、属性及其  
类型、主关键字属性、保密要求、完整性约束条件、更改要求、使用频率、数据量估计等。

这些关于数据的数据称为元数据。在设计大型数据库时，这些数据通常由数据字典来管理。用数据字典管理元数据有利于避免数据的重复或重名，以保持数据的一致性及提供各种统计数据，因而有利于提高数据库设计的质量，同时可以减轻设计者的负担。

**（2）概念结构设计**

它是数据库设计的第二阶段，其目标是对需求说明书提供的所有数据和处理要求进行抽象与综合处理，按一定的方法构造反映用户环境的数据及其相互联系的概念模型，即用户的数据模型或企业数据模型。这种概念数据模型与 DBMS 无关，是面向现实世界的、极易为用户所理解的数据模型。为保证所设计的概念数据模型能正确、完整地反映用户的数据及其相互关系，便于进行所要求的各种处理，在本阶段设计中可吸收用户参与和评议设计。在进行概念结构设计时，可先设计各个应用的视图（view），即各个应用所看到的数据及其结构，然后再进行视图集成，以形成一个单一的概念数据模型。这样形成的初步数据模型还要经过数据库设计者和用户的审查与修改，最后形成所需的概念数据模型。

**（3）逻辑结构设计**

这一阶段的设计目标是把上一阶段得到的与 DBMS 无关的概念数据模型转换成等价的，并为某个特定的 DBMS 所接受的逻辑模型所表示的概念模式，同时将概念设计阶段得到的应用视图转换成外部模式，即特定 DBMS 下的应用视图。在转换过程中要进一步落实需求说明，并满足 DBMS 的各种限制。该阶段的结果是用 DBMS 所提供的数据定义语言（DDL）写成的数据模式。逻辑设计的具体方法与 DBMS 的逻辑数据模型有关。逻辑模型应满足数据库存取、一致性及运行等各方面的用户需求。

**（4）数据库物理设计**

物理设计阶段的任务是把逻辑设计阶段得到的满足用户需求的已确定的逻辑模型在物理上加以实现，其主要内容是根据 DBMS 提供的各种手段，设计数据的存储形式和存取路径，如文件结构、索引设计等，即设计数据库的内模式或存储模式。数据库的内模式对数据库的性能影响很大，应根据处理需求及 DBMS、操作系统和硬件的性能进行精心设计。

--------------------

实际上，数据库设计的基本过程与任何复杂系统开发一样，在每一阶段设计基本完成后，都要进行认真的检查，看是否满足应用需求，是否符合前面已执行步骤的要求和满足后续步骤的需要，并分析设计结果的合理性。在每一步设计中，都可能发现前面步骤的遗漏或处理不当之处，此时，往往需要返回去重新处理并修改设计和有关文档。所以，数据库设计过程通常是一个反复修改、反复设计的迭代过程。

## 3 需求分析 ##

需求分析是数据库设计过程的第一步，是整个数据库设计的依据和基础。需求分析做得不好，会导致整个数据库设计重新返工。需求分析的目标是通过对单位的信息需求及处理要求的调查分析得到设计数据库所必需的数据集及其相互联系，形成需求说明书，作为后面各设计阶段的基础。因此，这一阶段的任务是：

**（1）确认需求、确定设计目标**

数据库设计的第一项工作就是要对系统的整个应用情况进行全面、详细的实地调查，弄清现行系统的组织结构、功能划分、总体工作流程，收集支持系统总的设计目标的基础数据和对这些数据的处理要求，明确用户总的需求目标；通过分析，确定相应的设计目标，即确定数据库应支持的应用功能和应用范围，明确哪些功能由计算机完成或准备让计算机完成，哪些环节由人工完成，以确定应用系统实现的功能。这一阶段收集到的基础数据和一组数据流程图是下一步进行概念设计的基础。

**（2）分析和收集数据**

这是整个需求分析的核心任务。它包括分析和收集用户的信息需求、处理需求、完整性需求、安全性需求，以及对数据库设计过程有用的其他信息。

信息需求是指在设计目标范围内涉及的所有实体、实体的属性及实体间的联系等数据对象，包括用户在数据处理中的输入/输出数据及这些数据间的联系。在收集中，要收集数据的名称、类型、长度、数据量、对数据的约束及数据间联系的类型等信息。

处理需求是指为了获得所需的信息而对数据加工处理的要求。它主要包括，处理方式是实时还是批处理，各种处理发生的频度、响应时间、优先级别及安全保密要求等。所要收集的其他信息还有企业在管理方式、经营方式等方面可能发生的变化等。

分析和收集数据的过程是数据库设计者对各类管理活动进行深入调查研究的过程，调查对象包括数据管理部门的负责人、各使用部门的负责人及操作员等各类管理人员，通过与各类管理人员相互交流，逐步取得对需求的一致认识。

**（3）整理文档**

分析和收集得到的数据必须经过筛选整理，并按一定格式和顺序记载保存，经过审核成为正式的需求说明文档，即需求说明书。实际上，需求说明书是在需求分析的过程中逐渐整理形成的，是随着这一过程的不断深入而反复修改与完善的对系统需求分析的全面描述。由用户、领导和专家共同评审，是以后各设计阶段的主要依据。这一步的工作是进行全面的汇总与整理，使之系统化，以形成标准化的统一形式。

## 4 概念结构设计 ##

概念结构设计阶段所涉及的信息不依赖于任何实际实现时的环境，即计算机的硬件和软件系统。概念结构设计的目标是产生一个用户易于理解的，反映系统信息需求的整体数据库概念结构。概念结构设计的任务是，在需求分析中产生的需求说明书的基础上按照一定的方法抽象成满足应用需求的用户的信息结构，即通常所称的概念模型。概念结构的设计过程就是正确选择设计策略、设计方法和概念数据模型并加以实施的过程。

概念数据模型的作用是：提供能够识别和理解系统要求的框架；为数据库提供一个说明性结构，作为设计数据库逻辑结构，即逻辑模型的基础。

概念模型的描述工具应该能够体现概念模型的特点，如 E-R 模型。近年来，由于面向对象数据模型具有更丰富的语义、更强的描述能力而越来越受到人们的重视，不但出现了商品化的面向对象 DBMS，而且开始实际应用于概念模型的设计中，作为数据库概念设计的工具。

Teory 等人提出的扩展的 E-R 模型增加了类似面向对象数据模型中的普遍化和聚合等语义描述机制，为这种最为人们熟悉的数据模型注入了新的生机，为概念模型的描述增加了一种理想的选择。

E-R 模型简称 E-R 图，它是描述概念世界，建立概念模型的实用工具。 E-R 图包括3个要素 :

1.  实体( 型) : 用矩形框表示，框内标注实体名称；
2.  属性 : 用椭圆形表示，并用连线与实体连接起来；
3.  实体之间的联系 : 用菱形框表示，框内标注联系名称，并用连线将菱形框分别与有关实体相连，并在连线上注明联系类型。

图 12 就是一个教学系统的 E-R图 ( 为了简单起见，省略了部分实体的属性和联系的属性 )：

![format_png 2][]

概念结构的设计策略主要有自底向上、自顶向下、由里向外和混合策略。在具体实现设计目标时有两种极端的策略或方案，一是建立一个覆盖整个单位所有功能域的全局数据库，称之为全局方案或全局策略；另一种则是对每一个应用都建立一个单独的数据库，称之为应用方案或应用策略。

由于各个部门对于数据的需求和处理方法各不相同，对同一类数据的观点也可能不一样，它们有自己的视图，所以可以首先根据需求分析阶段产生的各个部门的数据流图和数据字典中的相关数据设计出各自的局部视图，然后进行视图集成。

### 4.1 视图设计 ###

在实体分析法中，局部视图设计的第一步是确定其所属的范围，即它所对应的用户组，然后对每个用户组建立一个仅由实体、联系及它们的标识码组成的局部信息结构（局部数据模式）框架，最后再加入有关的描述信息，形成完整的局部视图（局部数据模式）。这样做的目的是为了集中精力处理好用户数据需求的主要方面，避免因无关紧要的描述细节而影响局部信息结构的正确性。整个过程可分为 4 个步骤：确定局部视图的范围；识别实体及其标识；确定实体间的联系；分配实体及联系的属性。

#### 4.1.1 确定局部视图的范围 ####

需求说明书中标明的用户视图范围可以作为确定局部视图范围的基本依据，但它通常与子模式范围相对应，有时因为过大而不利于局部信息结构的构造，故可根据情况修改，但也不宜分得过小，过小会造成局部视图的数量太大及大量的数据冗余和不一致性，给以后的视图集成带来很大的困难。

局部视图范围确定的基本原则是：各个局部视图支持的功能域之间的联系应最少。

实体个数适量。 一个局部视图所包含的实体数量反映了该局部视图的复杂性， 按照信息论中“7 2”的观点， 人们在同一时刻可同时顾及的事情一般在 5～9 之间， 其中以 6 或 7 最为适当。因此，一个局部视图内的实体数不宜超过 9 个，否则就会过于复杂，不便于人们理解和管理。

#### 4.1.2 识别实体及其标识 ####

在需求分析中，人们已经初步地识别了各类实体、实体间的联系及描述其性质的数据元素，这些统称为数据对象，它们是进一步设计的基本素材。这一步的任务就是在确定的局部视图范围内，识别哪些数据对象作为局部视图的基本实体及其标识，并定义有关数据对象在 E-R 模型中的地位。

#### 4.1.3 确定实体间的联系 ####

实际上，识别联系的主要任务是在需求分析阶段完成的。这里的工作一是从局部视图的角度进行一次审核，检查有无遗漏之处，二是确切地定义每一种联系。

在现实世界中，诸多形式的联系大致可分为三类：存在性联系、功能性联系和事件联系。

1.  存在性联系如学校有教师、教室有学生、工厂有产品、产品有顾客等；
2.  功能性联系如教师讲授课程、教师参与科研、仓库管理员管理仓库等；
3.  事件联系如学生借书、产品发运等。

根据上述分类仔细检查在给定的局部视图范围内是否有未识别的联系，在确认所有的联系都已识别并无遗漏之后，还需对联系进行正确的定义。定义联系就是对联系语义的仔细分析，识别联系的类型，确定实体在联系中的参与度。

**（1）二元联系的类型与定义**

二元联系是指两个实体类之间的联系。根据参与联系的两个实体类值之间的对应关系分为一对一、一对多及多对多三种类型。

1.  一对一联系

这是一种最简单的联系类型。若对于实体集 A 中的每一个实体，实体集 B 中至多有一个实体与之联系，反之亦然，则称实体集 A 与实体集 B 具有一对一联系，记为 1:1。

例如在一个施工单位中，如果规定每项工程最多只能由一名工程师负责管理，而一名工程师最多也只能负责一项工程，则工程师与工程间的这种管理联系便是一对一联系。

![format_png 3][]

1.  一对多联系

若对于实体集 A 中的每一个实体，实体集 B 中有 n 个实体（n≥0）与之联系；反之，对于实体集 B 中的每一个实体，实体集 A 中至多有一个实体与之联系，则称实体集 A 与实体集 B 有一对多的联系，记为 1:n。以专业与学生间的关系为例：如规定一个专业可以管理许多学生，每个学生只能属于一个专业，这种联系就是一对多联系。

![format_png 4][]

1.  多对多联系

若对于实体集 A 中的每一个实体，实体集 B 中有 n 个实体（n≥0）与之联系，反过来，对实体集 B 中每一个实体，实体集 A 中也有 m 个实体（m≥0）与之联系，则称实体集 A 与实体集 B 具有多对多联系，记为 m:n。教师与学生这两个实体类间的教与学的联系就是多对多的联系。这时，只有<教师、学生>对才能确定一个特定的教学联系。

![format_png 5][]

因此，一般情况下可以以两个关联实体的标识拼凑作为联系的标识。但这种方法对某些情况就不能构成有效的联系标识。当一个实体值在同一个联系上可能存在多个不同的联系值时，就会出现这种情况。如教师与其讲授的课程之间的联系，同一个教师可讲授几门不同的课程，也可以多次讲授同一门课程，这是一种特殊的多对多联系。显然，对于教师与讲授课程间的联系，如在教师档案中要求记录担任教学工作的情况，就需要在联系标识中增加表示授课日期的属性，即其合适的联系标识可能为（教师号，课程号，授课日期）。

![format_png 6][]

1.  实体类内部的联系

这种联系发生在同一类实体的不同实体之间，因此称为内部联系或自联系，它也是一种二元联系，其表示方式与前面的二元联系并无不同，要注意仔细区别同一实  
体类中的不同实体在联系中扮演的不同角色及联系标识的选择。

例如在职工类实体中间就存在着管理者与被管理者的联系。一个职工可以管理别的职工，称为管理者或领导者。一个管理者可以管理多个职工，而一个职工最多只从属于一位管理者，从而构成了一对多联系。若规定所有职工都要受管理（最高管理者考虑自己管理自己），但不是所有职工都是管理者，则此联系在“多”端呈现强制性。其中每个联系实体包含两个职工号值：职工号和管理员职工号，以区别不同的实体在联系中的角色。

![format_png 7][]

**（2）多元联系的识别与定义**

两个以上的实体类之间的联系称为多元联系。例如在供应商向工程供应零件这类事件中，如果任一供应商可向任一工程供应任一种零件，则为了确定哪个供应商向哪个工程供应了何种零件，就必须定义一个三元联系，因为只有供应商、工程及零件三者一起才能唯一地确定一个联系值。其联系的标识由参与联系的实体类的标识拼接而成，在此例中由供应商、工程、零件三个实体类的标识拼接而成。

![format_png 8][]

### 4.2 视图集成 ###

视图集成就是要将反映各用户组数据的局部数据模式综合成单位中某个确定范围内的单一数据视图，即全局数据模式，又称模式汇总。该全局数据模式是未来数据库结构的基础，因此视图集成是数据库设计过程中一个十分重要的步骤，也是一项较为复杂和困难的任务。

当所有局部视图设计完毕，就可开始视图集成。集成过程中会发生一些冲突，冲突的表现和处理策略如下：

**（1）同名异义**

为了发现不同视图间的同名异义问题，可以列出所有同名数据对象，然后逐一判别其语义。对同名异义冲突通常采用换名加以解决，既可对同名者之一换名，也可对两者都给以重新命名。识别语义的主要方法是进行值域分析。

**（2）异名同义**

识别异名同义比较困难，一般由设计者对所有对象一个不漏地逐一鉴别。它同样采用换名的方法解决。若归并时试图将它们合并为一个对象，则可以把其中之一的名称作为合并后的对象名；若集成后，它们仍以两个不同的对象存在，则可对其一换名。当然，若原名都不合适，则可以对两者都重新命名。

**（3）同名不同层次**

如果两个对象同名，但其中之一是作为一个视图中的实体，而另一个是另一视图中的属性，则在集成时就会发生同名不同层次的冲突。解决这种冲突的办法有两个，一是将属性转换为实体，二是将实体变换成属性。

例如，设一局部视图中有一部门实体 DEPT，而在另一与之集成的视图中有职工实体 EMP，且 EMP 有属性 DEPT，于是发生了同名不同层次的冲突。此时，可将 EMP 的 DEPT属性去掉，另设一个实体 DEPT 与 EMP 建立联系，这时再与另一视图集成就容易多了。

![format_png 9][]

再如，设一局部视图中有一名为 STOR 的仓库实体，其中含有一属性部门号（ DEPT-NO）；在另一局部视图中有一单位实体 DEPT，其中仅含有一个属性 DEPT-NO。对这类同名不同层次的冲突，可将 DEPT 实体变换为其所在视图中与 DEPT 相关的另一实体的属性，然后再进行集成。

![format_png 10][]

> 实体变换为属性时通常要满足一些特定条件，例如，该实体通常只含有一个与同名属性具有共同特征的属性，且一定存在一个与该实体存在联系的另外的实体。

**（4）同名同义，但对象联系测度不同**

所谓联系测度是指实体的联系是一对一、一对多还是多对多。若同名同义对象在一个局部视图中为一对多联系，在另一局部视图中为多对多联系，则在集成时将发生联系测度冲突。一般而言，一对多包含一对一，多对多包含一对多。所以解决这种冲突的方法往往取较高测度为集成后的相应联系的测度。

## 5 逻辑结构设计 ##

数据库逻辑结构设计的任务就是把概念结构设计阶段设计好的基本 E-R 图转换为与具体机器上的 DBMS 产品所支持的数据模型相符合的逻辑结构。这一阶段是数据库结构设计的重要阶段。

数据库逻辑设计的基础是概念设计的结果，而其成果应包括某 DBMS 所支持的外模式、概念模式及其说明及建立外模式和概念模式的 DDL 程序。因此，进行逻辑设计前，必须了解数据库设计的需求说明和概念设计的成果（包括 E-R 图和其他文档），并仔细阅读有关DBMS 的文件。数据库的外模式和概念模式是用户所看到的数据库，是应用程序访问数据库的接口，因此在数据库逻辑设计阶段，还必须提供应用程序编制的有关说明，最好试编一些典型的访问数据库的应用程序，以检验所设计的概念模式是否满足使用要求。概念模式是数据库的基础，它的设计质量对数据库的使用和性能，以及数据库在今后发展过程中的稳定性均有直接的影响。为了设计出能够正确反映一个项目数据间内在联系的好的概念模式，设计时必须正确处理各种应用程序之间、数据库性能与数据模式的合理性和稳定性之间的各种矛盾，对设计中出现的各种矛盾要权衡利弊，分清主次，按统筹兼顾的原则加以正确处理。

逻辑结构设计一般分为以下几个步骤：

1.  将概念结构向一般关系模型转化；
2.  将第一步得到的结构向特定的 DBMS 支持下的数据模型转换。
3.  依据应用的需求和具体的 DBMS 的特征进行调整与完善。

下面以常用的 E-R 模型和扩充 E-R 模型为主，针对关系数据库的逻辑设计介绍基本原则和方法。

### 5.1 基本 E-R 模型向关系模型的转换 ###

基本 E-R 模型主要包含实体和联系两个抽象概念，实体和联系本身还可能附有若干属性。其转换的基本原则是，实体和联系分别转换成关系，属性则转换成相应关系的属性。因此， E-R 模型向关系模型的转换比较直观，但不同元数的联系具体转换方法稍有不同，下面根据不同的情况分别讨论。

**（1）一对一联系**

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

如果转换为一个独立的模式，则与该联系相连的各实体的码以及联系本身的属性均转换为关系的属性，每个实体的码均是该关系的候选键。

![format_png 11][]

如果与某一端实体对应的关系模式合并，则需要在该关系模式的属性中加入另一个关系模式的码和联系本身的属性。

![format_png 12][]

**（2）一对多联系**

一个 1: n 联系可以转换为一个独立的关系模式，也可以与任意 n 端对应的关系模式合并。如果转换为一个独立的模式，则与该联系相连的各实体的码以及联系本身的属性均转换为关系的属性，而关系的码为 n 端实体的码。如果与 n 端实体对应的关系模式合并，则需要在该关系模式的属性中加入1 端关系模式的码和联系本身的属性 。转换模式本质上与一对一联系转换模式相同。

**（3）多对多联系**

由两个实体类之间多对多联系组成的 E-R 模型向关系模型转换时，将两个实体类和一个联系类分别转换成关系，实体类的属性分别转换成对应关系的属性，其标识属性为其关键字，由联系类转换得到的关系的属性由两个实体类的标识属性和联系类本身的属性组成，其关键字是由两个联系的实体类的标识属性组成。

**（4）多元联系**

实体类分别转换为相应的关系，三个实体类间的多元联系转换为以该联系名为关系名的关系，关系的属性由各实体的标识属性及其联系的属性组成，并以各实体的标识属性为其关键字。例如下图所示的部件（PART）、工程（PROJECT）和供应者（SUPPLIER）三者之间的联系为 PJS，其属性为 QTY。转换时，把 PART、 PROJECT、 SUPPLIER 和联系 PJS 分别转换为相应的关系，其结果如下：

![format_png 13][]

**（5）自联系**

自联系是同一实体集的实体间的联系。例如对于职工实体类内部有领导与被领导的联系，在部件这个实体集的实体之间有组成成分与组成者之间的联系等，均属于  
实体类的自联系。在这种联系中，参与联系的实体虽然来自同一实体类，但所起的作用不一样。

**（6）弱实体类的转换**

一个实体类，如果它的存在依赖于另一实体类，则称之为弱实体类。例如职工的亲属（ DEPENDENTS）是依赖于职工（ EMPLOYEE）实体类而存在的，因此实体集亲属（ DEPENDENTS）是弱实体类。由于弱实体类不能独立地存在，而是由其他实体标识而存在，所以不能单独地转换成一个关系。

![format_png 14][]

其中 kinship 表示职工亲属与职工的关系，可以取值为“配偶”、“儿子”、“女儿”等。

另外，还有4种情况是需要特别注意的 :

1.  多值属性的处理。如果 ER 图中某实体具有一个多值属性，则应该进行优化，把该属性提升为一个实体。或者在转化为关系模式时，将实体的码与多值属性单独构成一个关系模式。
2.  BLOB 型属性的处理。典型的 BLOB 是一张图片或一个声音文件，由于它们的容量比较大，必须使用特殊的方式来处理。处理 BLOB 的主要思想就是让文件处理器 ( 如数据库管理器 ) 不去理会文件是什么，而是关心如何去处理它。因此，从优化的角度考虑，应采用的设计方案是将 BLOB字段与关系的码独立为一个关系模式；
3.  派生属性的处理。因为派生属性可由其他属性计算得到，因此，在转化成关系模式时，通常不转换派生属性 。
4.  在对象 - 关系数据模型中，这里的关系模式就对应类，关系模式的属性就对应类的属性。

### 5.2 数据模型的优化 ###

由 E-R 图表示的概念模型转换得到的关系模型经过规范化以后，基本上可以反映一个企业数据的内在联系，但不一定能满足应用的全部需要和系统要求，因此，还必须根据需求分析对模型做进一步的改善和调整，其内容主要是改善数据库的性能和节省存储空间两个方面。

#### 5.2.1 改善数据库性能的考虑 ####

查询速度是关系数据库应用中影响性能的关键问题，必须在数据库的逻辑设计和物理设计中认真加以考虑，特别是那些对响应时间要求较苛刻的应用，应予以特别注意。

就数据库的逻辑设计而论，可从下列几个方面提高查询的速度。

**（1）减少连接运算**

连接运算对关系数据库的查询速度有着重要的影响，连接的关系越多，参与连接的关系越大，开销也越大，因而查询速度也越慢。对于一些常用的、性能要求较高的数据库查询，最好是一元查询，但这与规范化的要求相矛盾。有时为了保证性能，往往不得不牺牲规范化要求，把规范化的关系再合并起来，称之为逆规范化。当然，这样做会  
引起更新异常。总之，逆规范化有得有失，设计者可根据实际情况进行权衡。

**（2）减小关系大小及数据量**  
被查询的关系的大小对查询速度影响较大。为了提高查询速度，可以采用水平分割或垂直分割等方法把一个关系分成几个关系，使每个关系的数据量减少。例如，对于大学中有关学生的数据，既可以把全校学生的数据集中在一个关系中，也可以用水平分割的方法，分系建立关系，从而减少了每个关系的元组数。前者对全校范围内的查询较方便，后者则可以显著提高对指定系的查询速度。也可采用垂直分割的方法，把常用数据与非常用数据分开，以提高常用数据的查询速度。例如，高校中教职工档案，属性很多，有些需经常查询，有些则很少查询，如果放在一起，则关系的数据量就会很大，影响查询速度，因此把常用属性和非常用属性分开，就可提高对常用属性的查询速度。

**（3）尽量使用快照**

快照是某个用户所关心的那部分数据，与视图一样是一种导出关系，但它与视图有两点不同：一是视图是虚关系，数据库中并不存储作为视图的导出关系，仅仅保留它的定义，快照则是一个由系统事先生成后保留在数据库中的实关系；二是视图随数据当前值的变化而变化，快照则不随原来关系中数据的改变而及时改变，它只反映数据库中某一时刻的状态，不反映数据库的当前状态，犹如照片只反映某一时刻的情景，不能反映情景变化一样，之所以称它为快照，原因就在于此。但它与照片又有不同，快照不是一成不变的，它可以由系统周期性地刷新，或由用户用命令刷新。刷新时用当前值更新旧值。在实际应用中，快照可满足相当一部分应用的需要，甚至有些应用就是需要快照，而不是当前值。例如注明列出“某年某月某日截止”的统计或报表就是快照。由于快照是事先生成并存储在数据库中的，因而可大大缩短响应时间。目前不少 DBMS，如 Oracle、 MS SQL Server 等支持快照。对不支持快照的 DBMS，用户也可以把需要作为实关系使用的导出关系作为一个独立关系存于数据库中，但这种做法只能供查询使用，对它们的刷新及管理由用户负责。

#### 5.2.2 节省存储空间的一些考虑 ####

尽管随着硬件技术的发展，提供给用户使用的存储空间越来越大，但毕竟是有限度的。而数据库，尤其是复杂应用的大型数据库，需要占用较大的外存空间。因此，节省存储空间仍是数据库设计中应该考虑的问题，不但要在数据库的物理设计中考虑，而且还应在逻辑设计中加以考虑。在数据库逻辑设计中可采取以下措施：

**（1）缩小每个属性占用的空间**

减少每个属性占用的空间，是节省存储空间的一个有效的措施。通常可以有两种方法：即用编码和用缩写符号表示属性，但这两种方法的缺点是失去了属性值含义的直观性。

**（2）采用假属性**

采用假属性可以减少重复数据占用的存储空间。设某关系模型 R 的属性 A 和 B 之间存在函数依赖 A→B， B 的每一个值需要占用较大的空间，但 B 的域中不同的值却比较少， A 的域中具有较多的不同值，则 B 的同一值可能在多个元组中重复出现，从而需要占用较多的空间。为了节省空间，可利用属性 B 的域中不同值少的特点，对 B 的值进行分类，用 B′表示 B 的类型，则 A→B 可分解成两个函数依赖，即：A→B′， B′→B。

这样，就可用 B′代替原来元组较多的关系 R 中的属性 B，而另外建立一个较小的关系 R′来描述 B′与 B 的对应关系。这里 B′在原关系 R 中起了属性 B 的替身的作用，所以称 B′ 为假属性。例如，在职工关系中，职工的经济状况这一属性通常由职工号决定，一个大型企业的职工人数很多，如每一职工逐一填写，就要占用较多的空间，为了节省空间可把经济状况分为几种类型，在元组较多的职工关系中用经济状况的类型代替原来的经济状况，这里经济状况的类型就是假属性，另外建立一个较小的关系来描述每种经济状况类型的具体内容。

> 数据库设计与数学问题求解不同，它是一项综合性工作，受到各种各样的要求和因素的制约，有些要求往往又是彼此矛盾的，因此，设计结果很难说是最佳的，常常有得有失，设计者必须根据实际情况，综合运用上述原则和有关理论，在基本合理的总体设计的基础上，做一些仔细的调整，力求最大限度地满足用户各种各样的要求。

## 6 物理结构设计 ##

数据库在实际的物理设备上的存储结构和存取方法称为数据库的物理结构。数据库物理设计是利用已确定的逻辑结构及 DBMS 提供的方法、技术，以较优的存储结构、数据存取路径、合理的数据存储位置及存储分配，设计出一个高效的、可实现的物理数据库结构。显然，数据库的物理设计是完全依赖于给定的硬件环境和数据库产品的。数据库物理设计过程如图 11 所示。

![format_png 15][]

由于不同的 DBMS 提供的硬件环境和存储结构、存取方法，以及提供给数据库设计者的系统参数、变化范围有所不同，因此，为了设计出一个较好的存储模式，设计者必须了解以下几方面的问题，做到心中有数。

（1）了解并熟悉应用要求，包括各个用户对应的数据视图，即数据库的外模式（子模式），分清哪些是主要的应用，了解各个应用的使用方式、数据量和处理频率等，以便对时间和空间进行平衡，并保证优先满足应用的时间要求。

（2）熟悉使用的 DBMS 的性能，包括 DBMS 的功能，提供的物理环境、存储结构、存取方法和可利用的工具。

（3）了解存放数据的外存设备的特性，如物理存储区域的划分原则，物理块的大小等有关规定及 I/O 特性等。

存储模式和概念模式不一样，它不是面向用户的，一般的用户不一定也不需要了解数据库存储模式的细节。所以数据库存储模式的设计可以不必考虑用户理解的方便，其设计目标主要是提高数据库的性能，其次是节省存储空间。

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

[format_png]: /images/20230528/2bacb4e8546a4e51a61acdfefeab9a5c.png
[format_png 1]: /images/20230528/73ea2398fb15499ca35e281495306afc.png
[format_png 2]: /images/20230528/e5f725a6b71c4d8ab8dda1b426fb46d0.png
[format_png 3]: /images/20230528/86f2bc06d1734a8b96078d080f047003.png
[format_png 4]: /images/20230528/7ae0ecaa8f5a4c57b829de155e7f1504.png
[format_png 5]: /images/20230528/08cbfca1bc8840a08f7621841c019984.png
[format_png 6]: /images/20230528/37aa715250714b6fa418e825e78b7d87.png
[format_png 7]: /images/20230528/19840d2d93554428a5f0f8678586bd7a.png
[format_png 8]: /images/20230528/6d078b6e42a7460f8a6eb7577c82b081.png
[format_png 9]: /images/20230528/06d5dac0f1214c218b59f29d9ecf3bf9.png
[format_png 10]: /images/20230528/b6f7198d9ab44acf96fe0f4af678c5f4.png
[format_png 11]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly91cGxvYWQtaW1hZ2VzLmppYW5zaHUuaW8vdXBsb2FkX2ltYWdlcy8zMzg2MTA4LTVkZjIyYjZjYTcwZjBiZDcucG5n?x-oss-process=image/format,png
[format_png 12]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly91cGxvYWQtaW1hZ2VzLmppYW5zaHUuaW8vdXBsb2FkX2ltYWdlcy8zMzg2MTA4LWY3NTI3MGMxNDU0OGJhYjQucG5n?x-oss-process=image/format,png
[format_png 13]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly91cGxvYWQtaW1hZ2VzLmppYW5zaHUuaW8vdXBsb2FkX2ltYWdlcy8zMzg2MTA4LWZkNDc5MDA5ZmY5NzExYjMucG5n?x-oss-process=image/format,png
[format_png 14]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly91cGxvYWQtaW1hZ2VzLmppYW5zaHUuaW8vdXBsb2FkX2ltYWdlcy8zMzg2MTA4LWMxMzMxMTNhYWQzNGZiZDYucG5n?x-oss-process=image/format,png
[format_png 15]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly91cGxvYWQtaW1hZ2VzLmppYW5zaHUuaW8vdXBsb2FkX2ltYWdlcy8zMzg2MTA4LTI0MTA4NTI0M2ZmMTQ3YmMucG5n?x-oss-process=image/format,png