3.4 数据库逻辑结构的设计

E-R图表示的概念模型是用户数据要求的形式化。正如前面所述，E-R图独立于任何一种数据模型，它也不被任何一个DBMS所支持。逻辑结构设计的任务就是把概念模型结构转换成某个具体的DBMS所支持的数据模型。

从理论上讲，设计数据库逻辑结构的步骤应该是：首先选择最适合的数据模型，并按转换规则将概念模型转换为选定的数据模型；然后要从支持这种数据模型的各个DBMS中选出最佳的DBMS，根据选定的DBMS的特点和限制，对数据模型做适当修正。但实际情况常常是先给定了计算机和DBMS，再进行数据库逻辑模型设计。由于设计人员并无选择DBMS的余地，所以在概念模型向逻辑模型转换时就要考虑到适合给定的DBMS的问题。

现行的DBMS一般主要支持关系、网状或层次模型中的某一种，即使是同一种数据模型，不同的DBMS也有其不同的限制，提供不同的环境和工具。

通常把概念模型向逻辑模型的转换过程分为3步进行。

1）把概念模型转换成一般的数据模型。

2）将一般的数据模型转换成特定的DBMS所支持的数据模型。

3）通过优化方法将其转化为优化的数据模型。

概念模型向逻辑模型的转换步骤，如图3-17所示。

图3-17 逻辑结构设计的3个步骤

3.4.1 概念模型向网状模型的转换

1.不同型实体集及其联系的转换规则

概念模型中的实体集和不同型实体集间的联系可按下列规则转换为网状模型中的记录和系。

1）每个实体集转换成一个记录。

2）每个1∶n的二元联系转换成一个系，系的方向由1方实体记录指向n方实体记录。图3-18a所示的是一个1∶n二元联系转换的实例。

3）每个m∶n的二元联系，在转换时要引入一个联结记录，并形成两个系，系的方向由实体记录方指向联结记录方。图3-18b所示的是一个m∶n二元联系转换的实例。

图3-18 二元联系的概念模型向网状模型转换的实例

a)1∶n联系转换的实例 b)m∶n联系转换的实例

4）K（≥3）个实体型之间的多元联系，在转换时也引入一个联结记录，并将联系转换成K个实体记录型和联结记录型之间的K个系，系的方向均为实体型指向联结记录。具体实例如图3-19所示。

图3-19 多元联系的概念模型向网状模型转换的实例

2.同型实体之间联系的模型转换规则

在现实世界中，不仅不同型实体之间有联系，而且在同型实体（即同一实体集合）中也存在联系。例如，部门负责人与这一部门的职工都属于职工这个实体集合，他们都是职工这个实体集的一个子集，但他们之间又存在着领导与被领导的联系。再如，部件与其构成成分之间的联系，因为每个部件又是另一些部件的构成成分，因此这是同型实体之间的多对多的联系。在向网状模型转换时，同型实体之间联系的转换规则如下。

1）对于同一实体集的一对多联系，在向网状模型转换时要引入一个联结记录，并转换为两个系，系的方向不同。图3-20a为职工中领导联系转换的实例。

2）对于同一实体集之间的m∶n联系，转换时也要引入一个联结记录，所转换的两个系均由实体记录方指向联结记录方。图3-20b为部件中构成联系的转换实例。

图3-20 同一实体集间联系的概念模型向网状模型转换的实例

a)1∶n联系转换的实例 b)m∶n联系转换的实例

3.4.2 概念模型向关系模型的转换

将E-R图转换成关系模型要解决两个问题：一个是如何将实体集和实体间的联系转换为关系模式；另一个是如何确定这些关系模式的属性和码。关系模型的逻辑结构是一组关系模式，而E-R图则是由实体集、属性及联系3个要素组成，将E-R图转换为关系模型实际上就是要将实体集、属性及联系转换为相应的关系模式。

概念模型转换为关系模型的基本方法如下。

1.实体集的转换规则

概念模型中的一个实体集转换为关系模型中的一个关系，实体的属性就是关系的属性，实体的码就是关系的码，关系的结构是关系模式。

2.实体集间联系的转换规则

在向关系模式转换时，实体集间的联系可按以下规则转换。

（1）1∶1联系的转换方法

一个1∶1联系可以转换为一个独立的关系，也可以与任意一端实体集所对应的关系合并。如果将1∶1联系转换为一个独立的关系，则与该联系相连的各实体的码，以及联系本身的属性均转换为关系的属性，且每个实体的码均是该关系的候选码。如果将1∶1联系与某一端实体集所对应的关系合并，则需要在被合并关系中增加属性，其新增的属性为联系本身的属性和与联系相关的另一个实体集的码。

图3-21 两元1∶1联系转换为 关系模式的实例

【例3-1】 将图3-21中含有1∶1联系的E-R图转换为关系模式。

该例有3种方案可供选择（注意：关系模式中标有下划线的属性为码）。

方案1：联系形成的独立关系，关系模式如下：

方案2：“负责”与“职工”两关系合并，关系模式如下。

方案3：“负责”与“产品”关系合并，关系模式如下。

将上面的3种方案进行比较，不难发现：方案1中，由于关系多，增加了系统的复杂性；方案2中，由于并不是每个职工都负责产品，就会造成产品号属性的NULL值过多；相比较起来，方案3比较合理。

（2）1∶n联系的转换方法

在向关系模式转换时，实体间的1∶n联系可以有两种转换方法：一种方法是将联系转换为一个独立的关系，其关系的属性由与该联系相连的各实体集的码，以及联系本身的属性组成，而该关系的码为n端实体集的码；另一种方法是在n端实体集中增加新属性，新属性由联系对应的1端实体集的码和联系自身的属性构成，新增属性后原关系的码不变。

【例3-2】 将图3-22中含有1∶n联系的E-R图转换为关系模式。

图3-22 两元1∶n联系转换为 关系模式的实例

该转换有两种转换方案供选择（注意：关系模式中标有下划线的属性为码）。

方案1：1∶n联系形成的关系独立存在。

方案2：联系形成的关系与n端对象合并。

比较以上两种转换方案可以发现：尽管方案1使用的关系多，但是对仓储变化大的场合比较适用；相反，方案2中关系少，它适应仓储变化较小的应用场合。

【例3-3】 图3-23中含有同实体集的1∶n联系，将它转换为关系模式。

图3-23 实体集内部1∶n联系转换为关系模式的实例

该例题转换的方案如下（注意：关系模式中标有下划线的属性为码）。

方案1：转换为两个关系模式。

方案2：转换为一个关系模式。

其中，由于同一关系中不能有相同的属性名，故将领导的职工号改为领导工号。以上两种方案相比较，第2种方案的关系少，且能充分表达原有的数据联系，所以采用第2种方案会更好些。

（3）m∶n联系的转换方法

在向关系模式转换时，一个m∶n联系转换为一个关系。转换方法为：与该联系相连的各实体集的码，以及联系本身的属性均转换为关系的属性，新关系的码为两个相连实体码的组合（该码为多属性构成的组合码）。

【例3-4】 将图3-24中含有m∶n二元联系的E-R图，转换为关系模式。

该例题转换的关系模式如下（注意：关系模中标有下划线的属性为码）。

【例3-5】 将图3-25中含有同实体集间m∶n联系的E-R图转换为关系模式。

转换的关系模式如下（注意：关系模式中标有下划线的属性为码）。

其中，组装件号为组装后的复杂零件号。由于同一个关系中不允许存在同属性名，因而改为组装件号。

图3-24 m∶n二元联系转换为关系模式的实例

图3-25 同一实体集内m∶n联系转换为关系模式的实例

（4）3个或3个以上实体集间的多元联系的转换方法

要将3个或3个以上实体集间的多元联系转换为关系模式，可根据以下两种情况采用不同的处理方法。

1）对于一对多的多元联系，转换为关系模式的方法是修改n端实体集对应的关系，即将与联系相关的1端实体集的码和联系自身的属性作为新属性加入到n端实体集中。

2）对于多对多的多元联系，转换为关系模式的方法是新建一个独立的关系，该关系的属性为多元联系相连的各实体的码及联系本身的属性，码为各实体码的组合。

【例3-6】 将图3-26中含有多实体集间的多对多联系的E-R图转换为关系模式。

转换后的关系模式如下。

其中，关系模式中标有下划线的属性为码。

图3-26 多实体集间联系转换为关系模式的实例

3.关系合并规则

在关系模式中，具有相同码的关系，可根据情况合并为一个关系。

3.4.3 用户子模式的设计

用户子模式也称外模式。关系数据库管理系统中提供的视图是根据用户子模式设计的。设计用户子模式时只考虑用户对数据的使用要求、习惯及安全性要求，而不用考虑系统的时间效率、空间效率和维护等问题。用户子模式设计时应注意以下问题。

1.使用更符合用户习惯的别名

前面提到，在合并各分E-R图时应消除命名的冲突，这在设计数据库整体结构时是非常有必要的。但命名统一后会使某些用户感到别扭，用定义子模式的方法可以有效地解决该问题。必要时，可以对子模式中的关系和属性名重新命名，使其与用户习惯一致，以方便用户的使用。

2.对不同级别的用户可以定义不同的子模式

由于视图能够对表中的行和列进行限制，所以它还具有保证系统安全性的作用。对不同级别的用户定义不同的子模式，可以保证系统的安全性。

例如，假设有关系模式：产品（产品号，产品名，规格，单价，生产车间，生产负责人，产品成本，产品合格率，质量等级）。如果在产品关系上建立以下两个视图。

1）为一般顾客建立视图。

产品1（产品号，产品名，规格，单价）

2）为产品销售部门建立视图。

产品2（产品号，产品名，规格，单价，车间，生产负责人）

在建立视图后，产品1视图中包含了允许一般顾客查询的产品属性；产品2视图中包含允许销售部门查询的产品属性；生产领导部门则可以利用产品关系查询产品的全部属性数据。这样，既方便了使用，又可以防止用户非法访问本来不允许他们查询的数据，保证了系统的安全性。

3.简化用户对系统的使用

利用子模式可以简化使用，方便查询。实际中经常要使用某些很复杂的查询，这些查询包括多表连接、限制、分组和统计等。为了方便用户，可以将这些复杂查询定义为视图，用户每次只对定义好的视图进行查询，避免了每次查询都要对其进行重复描述，大大简化了用户的使用。

3.4.4 数据库逻辑结构设计的实例

假如要为某基层单位建立一个“基层单位”数据库。通过调查得出，用户要求数据库中存储下列基本信息。

部门：部门号，名称，领导人编号

职工：职工号，姓名，性别，工资，职称，照片，简历

工程：工程号，工程名，参加人数，预算，负责人

办公室：地点，编号，电话

这些信息的关联语义如下。

每个部门有多个职工，每个职工只能在一个部门工作；

每个部门只有一个领导人，领导人不能兼职；

每个部门可以同时承担若干工程项目，数据库中应记录每个职工参加项目的日期；

一个部门可有多个办公室；

每个办公室只有一部电话；

数据库中还应存储每个职工在所参加的工程项目中承担的具体职务。

1.概念模型的设计

调查得到数据库的信息要求和语义后，还要进行数据抽象，才能得到数据库的概念模型。设基层单位数据库的概念模型如图3-27所示。为了清晰，图中将实体的属性略去了。该E-R图表示的“基层单位”数据库系统中应包括“部门”“办公室”“职工”和“工程”4个实体集，其中，部门和办公室间存在1∶n的“办公”联系；部门和职工间存在着1∶1的“领导”联系和1∶n的“工作”联系；职工和工程之间存在1∶n的“负责”联系和m∶n的“参加”联系；部门和工程之间存在着1∶n的“承担”联系。

2.关系模型的设计

图3-27的E-R图可按规则转换一组关系模式。表3-2中列出了这组关系模式及相关信息。表中的一行为一个关系模型，关系的属性根据数据字典得出。

图3-27 基层单位数据库的概念模型

表3-2 基层单位数据库的关系模式信息

注：表中带有下划线的属性为关系的码；带有删除线的内容是开始设计有，后来优化时应该与其他关系合并，具体情况在说明列中叙述。

该关系模型开始设计为10个关系，将1∶n联系和1∶1联系形成的关系模式与相应的实体形成的关系模式合并后，有5个关系优化掉了，结果为5个关系模式。这样，该“基本单位”数据库中应该有5个基本关系。