下载掌阅APP，畅读海量书库
立即打开
数据库逻辑结构设计的任务就是把概念结构设计阶段设计好的基本E-R图转换为与具体机器上的DBMS产品所支持的数据模型相符合的逻辑结构。这一阶段是数据库结构设计的重要阶段。
数据库逻辑设计的基础是概念设计的结果，而其成果应包括某DBMS所支持的外模式、概念模式及其说明及建立外模式和概念模式的DDL程序。因此，进行逻辑设计前，必须了解数据库设计的需求说明和概念设计的成果（包括E-R图和其他文档），并仔细阅读有关DBMS的文件。数据库的外模式和概念模式是用户所看到的数据库，是应用程序访问数据库的接口，因此在数据库逻辑设计阶段，还必须提供应用程序编制的有关说明，最好试编一些典型的访问数据库的应用程序，以检验所设计的概念模式是否满足使用要求。概念模式是数据库的基础，它的设计质量对数据库的使用和性能，以及数据库在今后发展过程中的稳定性均有直接的影响。为了设计出能够正确反映一个项目数据间内在联系的好的概念模式，设计时必须正确处理各种应用程序之间、数据库性能与数据模式的合理性和稳定性之间的各种矛盾，对设计中出现的各种矛盾要权衡利弊，分清主次，按统筹兼顾的原则加以正确处理。
逻辑结构设计一般分为以下几个步骤：
（1）将概念结构向一般关系模型转化。
（2）将第一步得到的结构向特定的DBMS支持下的数据模型转换。
（3）依据应用的需求和具体的DBMS的特征进行调整与完善。
下面以常用的E-R模型和扩充E-R模型为主，针对关系数据库的逻辑设计介绍基本原则和方法。
基本E-R模型主要包含实体和联系两个抽象概念，实体和联系本身还可能附有若干属性。其转换的基本原则是，实体和联系分别转换成关系，属性则转换成相应关系的属性。因此，E-R模型向关系模型的转换比较直观，但不同元数的联系具体转换方法稍有不同，下面根据不同的情况分别讨论。
（1）一对一联系。设有两个实体E 1 和E 2 之间为一对一联系。此情况存在三种可能的转换方案。
方案1：将实体E 1 、E 2 和联系名R分别转换成为关系E 1 、E 2 和R，它们的属性分别转为相应关系的属性，即得到：
E 1 （ k 1 ，a）
E 2 （ k 2 ，b）
R（ k 1 ，k 2 ，r）（k 2 是候选关键字）
其中属性下面带一横线者为关系的关键字。
方案2：将实体E 1 转换为关系E 1 ，将实体E 2 与联系名R一起转换成关系E 2 ´，E 2 ´的属性由E 2 和R的属性加上E 1 的关键字组成，其关键字k 1 、k 2 为其候选关键字。转换后的关系为：
E 1 （ k 1 ，a）
E 2 ´（ k 2 ，b，k 1 ，r），（k 1 是候选关键字）
方案3：与方案2类似，不过把实体E 1 与联系R一起转换成关系E 1 后，其结果为：
E 1 ´（ k 1 ，a，k 2 ，r），（k2是候选关键字）
E 2 （ k 2 ，b）
上述三个方案实际上可归结为转换成三个关系和转换成两个关系两种。如果每个实体的属性数较少，而联系的属性与两个实体之一关系又较密切，则可采用方案2或方案3，其优点是可减少关系数，有利于减少连接运算从而提高查询效率，但如果每个实体的属性较多，且合并后，会造成较大数据冗余和操作异常，则以采用方案1为宜。
（2）一对多联系。这种情况存在两种转换方案，其一是把两个实体类和一个联系类分别转换成对应的关系，实体类的属性转换为对应关系的属性，其标识属性即为对应关系的关键字，而联系类转换得到的关系，其属性由两个实体的标识属性和联系类本身的属性组成，并以多端实体类的标识属性为其关键字。其转换结果为三个关系。第二个方案是转换成两个关系，设少端和多端的两个实体类分别为E 1 、E 2 ，联系名R。转换时，将实体类E 1 转换为一个关系E 1 ，E 2 和R合起来转换成一个关系E 2 ´，E 2 ´的属性由E 2 和R的属性加上E 1 的标识属性组成，并以E 2 的标识属性为其关键字。
（3）多对多联系。由两个实体类之间多对多联系组成的E-R模型向关系模型转换时，将两个实体类和一个联系类分别转换成关系，实体类的属性分别转换成对应关系的属性，其标识属性为其关键字，由联系类转换得到的关系的属性由两个实体类的标识属性和联系类本身的属性组成，其关键字是由两个联系的实体类的标识属性组成。
（4）多元联系。实体类分别转换为相应的关系，三个实体类间的多元联系转换为以该联系名为关系名的关系，关系的属性由各实体的标识属性及其联系的属性组成，并以各实体的标识属性为其关键字。例如图2-19所示的部件（PART）、工程（PROJECT）和供应者（SUPPLIER）三者之间的联系为PJS，其属性为QTY。转换时，把PART、PROJECT、SUPPLIER和联系PJS分别转换为相应的关系，其结果如下：
PART（P#，PN）
PROJECT（PNO，PNAME）
SUPPLIER（S#，SN）
PJS（P#，PNO，S#，QTY）
图2-19 部件工程和供应者之间的关系
（5）自联系。自联系是同一实体集的实体间的联系。例如对于职工实体类内部有领导与被领导的联系，在部件这个实体集的实体之间有组成成分与组成者之间的联系等，均属于实体类的自联系。在这种联系中，参与联系的实体虽然来自同一实体类，但所起的作用不一样。
（6）弱实体类的转换。一个实体类，如果它的存在依赖于另一实体类，则称之为弱实体类。例如职工的亲属（DEPENDENTS）是依赖于职工（EMPLOYEE）实体类而存在的，因为实体集亲属（DEPENDENTS）是弱实体类，它们之间的关系如图2-20所示。由于弱实体类不能独立地存在，而是由其他实体标识而存在，所以不能单独地转换成一个关系，因此图2-20可转换成如下两个关系：
EMPLOYEE（ empno ，name，birthday）
DEPENDENTS（ empno ， name ，sex，age，kinship）
其中kinship表示职工亲属与职工的关系，可以取值为“配偶”、“儿子”、“女儿”等。
图2-20 职工与职工的亲属间的关系
（7）带有非原子属性的实体的转换。属性的原子性是关系模型对每个关系的基本要求。但E-R数据模型允许用集合或聚合作为属性，这类实体的转换与一般实体的转换有所不同。假如k是标识属性，a是普通原子属性，r是集合属性，r={r i | i =1，1，……， n }，g是聚合属性，由原子属性g 1 、g 2 聚合而成，则此实体E可转换成下列两个关系：
E（ k ，a，g 1 ，g 2 ）
E´（ k ，r i ）， i ＝1，2，……， n
其中k表示关系的主关键字。
扩充E-R模型是基本E-R模型的扩充。它主要扩充了两点，一是一个实体集可能是另一个实体集中的某个属性，即一个实体集可以附属于另一个实体集，二是增加了一种叫ISA的特殊联系，这种联系建立了两个实体集间的继承关系，通过这种联系可以构成实体集之间的普遍化/特殊化层次结构。下面讨论这些扩充部分的转换，这些转换方法也可推广到其他具有这些概念的数据模型。
（1）一个实体集同时是另一实体集的属性。设实体集E 1 有属性k 1 、a 1 、k 2 ，其中k 1 为E 1 的标识属性，而属性k 2 是另一实体E 2 的标识属性，E 2 有属性k 2 、e 1 、e 2 ，则可转换成两个关系：
E 1 （k 1 ，a 1 ，k 2 ）
E 2 （k 2 ，e 1 ，e 2 ）
图2-21（a）是这种情况的一个实例，它可转换成工厂与厂长两个关系：
工厂（ 厂名 ，性质，地址，厂长工作证号）
厂长（ 身份证号 ，姓名，性别，年龄）
（2）两个实体集间ISA联系的转换。这种情况下的实体E 0 是实体集E 1 的超集，而实体E 1 是实体集E 0 的子集。E 1 继承E 0 的全部属性，同时，E 1 可以有其自己的属性。图2-21（b）是这种联系的一个实例。
图2-21 扩充E-R模型向关系模型的转换示例
对于这种E-R图，将其超类和子类分别转换成两个关系，并且子实体集以其超类实体集的关键字为关键字，即：
E 0 （k，a）
E 1 （k，b，c）
据此，图2-21（b）所示的实例可转换成下面两个关系：
学生（ 学号 ，姓名，年龄，系别）
研究生（ 学号 ，导师姓名，研究方向，攻读学位）
（3）一个超集具有多个子集时的转换。设超实体集E 0 的属性集为{k，a1，……，a n }，它有m个子实体集E 1 ，……，E m ，子实体集的属性集为Attr（E i ）（1≤ i ≤ m ），子实体可能不相交，也可能重叠。在这种情况下可把E 0 ，E 1 ，……，E m 分别转换成关系：
E 0 （k，a 1 ，……，a n ）；
E i （ k ，Attr（E i ））；（1≤ i ≤ m ）
在逻辑结构方面，一般关系模型结构与目前较常用的DBMS支持的关系模型结构并无明显冲突。设计时需要注意以下问题：
（1）注意DBMS支持的数据类型。一般而言，E-R数据模型不像DBMS那样只支持有限的几种数据类型，据此转换而得到的关系模型，必然保留了E-R模型中的数据类型。因此，在向具体的DBMS所支持的关系模型转换时，对DBMS不支持的数据类型必须做相应的修改。如果用户坚持要使用原来的数据类型，就可能导致数据库的数据类型与应用程序中的数据类型不一致，应用程序必须负责这两者之间数据类型的转换。
（2）DBMS对关系模型的数量、一个关系中属性的个数、关系名与属性名的长度等的限制。如果一般关系模型与DBMS的这些限制存在冲突，则按特定DBMS的要求进行修正。
希赛教育专家提示： 在向特定DBMS转换之前，需先对转换所得到的关系模型进行规范化处理。
用户子模式（外模式）是用户所看到的数据库的数据逻辑结构。各个用户（或用户组）可以有各自的外模式。外模式是概念模式的子集，但在结构和形式上可以不同于概念模式，甚至可采用不同的数据模型，不过一般都是同一数据模型。
关系数据库的外模式由与用户有关的基表及按需要定义的视图构成。设计外模式时，可参照概念设计中的局部E-R图。在关系模型中，利用SQL语言中视图的功能设计更符合局部用户需要的用户子模式，可按如下操作工作：
（1）使用更符合用户习惯的别名。在合并各部分E-R图时，曾做了消除命名冲突的工作，这在设计数据库整体结构时是非常必要的。它使得在数据库系统中对同一关系和属性使用唯一的名字，但这对局部应用说来，可能使某些用户感到不方便，不符合以往的习惯。利用视图（View）就可以让视图名和视图中的属性名与用户习惯一致，让用户对视图查询，使系统更符合用户的习惯。
例如，在数据库中有个关系“部门”，它的属性为部门号、部门名称、经理姓名，但在某个局部应用中，习惯称此关系为单位，属性为单位代码、名称、领导姓名。那么，可对这个局部应用定义如下的视图：
CREATE VIEW UNIT（UNO，NAME，LEADER）
AS SELECT DNO，DEPTNAME，MGR
FROM DEPT
这样用户可以每次只对视图查询，而不查询基本表，使用户感到系统更符合自己的习惯。
（2）定义不同的视图。可以对不同级别的用户定义不同的视图，以满足系统对安全性的要求。例如，在希赛教育视频系统中有一视频关系，包含的属性有：视频编号、视频名称、所属级别、单价、开发部门、录制负责人、技术数据、测试结果。对于视频编号、视频编号、名称、所属级别、单价，允许任何顾客查询，对于视频销售部门还允许查询开发部门与录制负责人，对于希赛教育管理部门则允许查询全部数据。这样，可以为一般顾客和视频销售部门各定义一个视图，在为顾客定义的视图中只包含允许顾客查询的属性；在为视频销售部门定义的视图中只包含允许销售部门查询的属性。建立应用系统时，顾客只查询为他们定义的视图，销售部门也只查询为他们定义的视图，而管理部门则可以对视频关系查询，这样便保证了系统的安全性要求。
（3）简化用户对系统的使用。SQL语句中有些查询是比较复杂的，对于那些不熟悉计算机的人是不易于理解的。如果在某些应用中对某个或某些复杂查询是经常要用的，则可以将这个（或这些）复杂的查询定义为视图，用户每次只对定义好的视图进行查询，以使用户使用系统时感到简单直观、易于理解。
由E-R图表示的概念模型转换得到的关系模型经过规范化以后，基本上可以反映一个企业数据的内在联系，但不一定能满足应用的全部需要和系统要求，因此，还必须根据需求分析对模型做进一步的改善和调整，其内容主要是改善数据库的性能和节省存储空间两个方面。
（1）改善数据库性能的考虑。查询速度是关系数据库应用中影响性能的关键问题，必须在数据库的逻辑设计和物理设计中认真加以考虑，特别是那些对响应时间要求较苛刻的应用，应予以特别注意。
就数据库的逻辑设计而论，可从下列几个方面提高查询的速度。
① 减少连接运算。连接运算对关系数据库的查询速度有着重要的影响，连接的关系越多，参与连接的关系越大，开销也越大，因而查询速度也越慢。对于一些常用的、性能要求较高的数据库查询，最好是一元查询，但这与规范化的要求相矛盾。有时为了保证性能，往往不得不牺牲规范化要求，把规范化的关系再合并起来，称之为逆规范化。当然，这样做会引起更新异常。总之，逆规范化有得有失，设计者可根据实际情况进行权衡。
② 减小关系大小及数据量。被查询的关系的大小对查询速度影响较大。为了提高查询速度，可以采用水平分割或垂直分割等方法把一个关系分成几个关系，使每个关系的数据量减少。例如，对于大学中有关学生的数据，既可以把全校学生的数据集中在一个关系中，也可以用水平分割的方法，分系建立关系，从而减少了每个关系的元组数。前者对全校范围内的查询较方便，后者则可以显著提高对指定系的查询速度。也可采用垂直分割的方法，把常用数据与非常用数据分开，以提高常用数据的查询速度。例如，高校中教职工档案，属性很多，有些需经常查询，有些则很少查询，如果放在一起，则关系的数据量就会很大，影响查询速度，因此把常用属性和非常用属性分开，就可提高对常用属性的查询速度。
③ 尽量使用快照。快照是某个用户所关心的那部分数据，与视图一样是一种导出关系，但它与视图有两点不同：一是视图是虚关系，数据库中并不存储作为视图的导出关系，仅仅保留它的定义，快照则是一个由系统事先生成后保留在数据库中的实关系；二是视图随数据当前值的变化而变化，快照则不随原来关系中数据的改变而及时改变，它只反映数据库中某一时刻的状态，不反映数据库的当前状态，犹如照片只反映某一时刻的情景，不能反映情景变化一样，之所以称它为快照，原因就在于此。但它与照片又有不同，快照不是一成不变的，它可以由系统周期性地刷新，或由用户用命令刷新。刷新时用当前值更新旧值。在实际应用中，快照可满足相当一部分应用的需要，甚至有些应用就是需要快照，而不是当前值。例如注明列出“某年某月某日截止”的统计或报表就是快照。由于快照是事先生成并存储在数据库中的，因而可大大缩短响应时间。目前不少DBMS，如Oracle、MS SQL Server等支持快照。对不支持快照的DBMS，用户也可以把需要作为实关系使用的导出关系作为一个独立关系存于数据库中，但这种做法只能供查询使用，对它们的刷新及管理由用户负责。
（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′为假属性。例如，在职工关系中，职工的经济状况这一属性通常由职工号决定，一个大型企业的职工人数很多，如每一职工逐一填写，就要占用较多的空间，为了节省空间可把经济状况分为几种类型，在元组较多的职工关系中用经济状况的类型代替原来的经济状况，这里经济状况的类型就是假属性，另外建立一个较小的关系来描述每种经济状况类型的具体内容。
希赛教育专家提示： 数据库设计与数学问题求解不同，它是一项综合性工作，受到各种各样的要求和因素的制约，有些要求往往又是彼此矛盾的，因此，设计结果很难说是最佳的，常常有得有失，设计者必须根据实际情况，综合运用上述原则和有关理论，在基本合理的总体设计的基础上，做一些仔细的调整，力求最大限度地满足用户各种各样的要求。
对模式的评价包括设计质量评价和性能评价两个方面。设计质量标准有：可理解性、完整性、可恢复性、安全性和扩充性。目前对这些标准的评价只能做大致的估计，还没有十分严格有效的度量方法。至于数据模式的性能评价，由于缺乏物理设计所提供的数量测量标准，因此也只能进行实际性能的估计，它包括逻辑记录存取数、传输量及物理设计算法的模型等。常用LRA方法来进行数据模式的性能评价。它主要从逻辑记录存取数、传送量、物理设计算法的模型等方面进行评估，具体评价的标准有LRA、TV、SS三个参数。LRA（Logical Record Access）指单位时间内需要访问的逻辑记录数；TV（Transport Volume）指单位时间的数据传输量；SS（Storage Space）指数据库存储空间，包括数据占用空间和指针占用空间两部分。
理想情况是LRA、TV、SS均较小，但实际上是不可能的。因为要想LRA较少，很可能是把每个记录类的长度设计得较大，从而增加数据传输量。因此，根据这三个参数可对设计的数据模式做一个评估以便改进。
根据对数据模式的性能估计，对那些明显地影响性能的因素加以改进，如利用逆规范化以减少单位时间内存取的逻辑记录数LRA来减少连接运算的次数，利用分解操作减少单位时间内数据传输量TV，利用减少属性长度或假属性以节省存储空间等。此外，在物理设计时可利用特定的DBMS的特点，如索引、聚簇功能来进一步提高系统的效率。
必须强调指出的是，在进行模式的改进时，绝对不能修改数据库的信息内容，若不修改信息内容便无法改进数据模式的性能，则必须重新进行概念设计。