3.3.5 逻辑结构设计
数据库逻辑结构设计的任务是：把概念结构设计阶段设计好的基本E-R图转换为与具体机器上的DBMS产品所支持的数据模型相符合的逻辑结构。
这一阶段是数据库结构设计的重要阶段。
数据库逻辑设计的基础是概念设计的结果，其成果应包括：
- 某DBMS所支持的外模式
- 概念模式
- 说明及建立外模式
- 概念模式的DDL程序。
逻辑结构设计步骤：
- 将概念结构向一般关系模型转化。
- 将第一步得到的结构向特定的DBMS支持下的数据模型转换。
- 依据应用的需求和具体的DBMS的特征进行调整与完善。
以常用的E-R模型和扩充E-R模型为主，介绍关系数据库的逻辑设计基本原则和方法：
1.基本E-R模型向关系模型的转换
基本E-R模型主要包含实体和联系两个抽象概念，实体和联系本身还可能附有若干属性。
其转换的基本原则是：实体和联系分别转换成关系，属性则转换成相应关系的属性。
E-R模型向关系模型的转换比较直观，但不同元数的联系具体转换方法稍有不同，不同情况：
(1)一对一联系。
设有两个实体E1和E2之间为一对一联系。此情况存在三种可能的转换方案。
方案1：
将实体E1、E2和联系名R分别转换成为关系E1、E2和R，它们的属性分别转为相应关系的属性，即得到：
E1(k1,a)
E2(k2,b)
R(k1,k2,r)(k2是候选关键字) 常用：属性下面带一横线者表示关系的关键字。
方案2：
将实体E1转换为关系E1，将实体E2与联系名R，一起转换成关系E2，E2的属性由E2和R的属性加上E1的关键字组成，其关键字k1、k2为其候选关键字。（跟下面的说法有冲突哈。。。感觉好奇怪）
转换后的关系：
E1(k1,a)
E2(k2,b,k1,r)，（k1是候选关键字）
方案3：跟方案2类似，将实体E1与联系R一起转换成关系E1，结果：
E1(k1,a,k2,r),(k2是候选关键字)
E2(k2,b)
上述三个方案实际上可归结为转换成三个关系和转换成两个关系两种。
如果每个实体的属性数较少，而联系的属性与两个实体之一关系又较密切，可采用方案2或方案3，优点是：可减少关系数，有利于减少连接运算从而提高查询效率。
如果每个实体的属性较多，且合并后，会造成较大数据冗余和操作异常，则采用方案1为宜。
（2）一对多联系。常用两种转换方案：
其一：把两个实体类和一个联系类分别转换成对应的关系，
实体类的属性转换为对应关系的属性，其标识属性即为对应关系的关键字，
联系类转换得到的关系，其属性由两个实体的标识属性和联系类本身的属性组成，
并以多端实体类的标识属性为其关键字。其转换结果为三个关系。
第二个方案是转换成两个关系，
设少端和多端的两个实体类分别为E1、E2，联系名R。转换时，将实体类E1转换为一个关系E1,E2和R合起来转换成一个关系E2'，E2'的属性由E2和R的属性加上E1的标识属性组成，并以E2的标识属性为其关键字。
（3）多对多联系。由两个实体类之间多对多联系组成的E-R模型向关系模型转换时，将两个实体类和一个联系类分别转换成关系，
实体类的属性分别转换成对应关系的属性，其标识属性为其关键字，
由联系类转换得到的关系 的属性由两个实体类的标识属性和联系类本身的属性组成，其关键字是由两个联系的实体类的标识属性组成。
（4）多元联系。
实体类分别转换为相应的关系，三个实体类间的多元联系转换为以该联系名为关系名的关系，关系的属性由各实体的标识属性及其联系的属性组成，并以各实体的标识属性为其关键字。
例：
部件（PART）、工程（PROJECT）、供应者（SUPPLIER）
三者之间的联系：PJS，其属性为QTY。
转换时，把PART、PROJECT、SUPPLER和联系PJS分别转换为相应的关系。
(5)自联系
是同一实体集的实体间的联系。
例如：对于职工实体类内部有领导与被领导的联系，
在部件这个实体集的实体之间有组成成分与组成者之间的联系等，
均属于实体类的自联系。
这种联系中，参与联系的实体虽然来自同一实体类，但所起的作用不一样。
（6）弱实体类的转换。
一个实体类，如果他的存在依赖于另一实体类，则称之为弱实体类。
例如：职工的亲属（DEPENDENTS）是依赖于职工（EMPLOYEE）实体类而存在的。实体集亲属（DEPENDENTS）是弱实体类，弱实体类不能独立存在，而是由其他实体标识而存在，所以不能单独地转换成一个关系，
可转换成如下两个关系：
EMPLOYEE(empno,name,birthday)
DEPENDENTS(empno,name,sex,age,kinship)
其中kinship表示职工亲属与职工的关系，可以取值为“配偶”、“儿子”、“女儿”等。
2.数据模型的优化
内容主要是：改善数据库的性能、节省存储空间两个方面。
（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'为假属性。
例如，在职工关系中，职工的经济状况这一属性通常由职工号决定，一个大型企业的职工人数很多，如每一职工逐一填写，就要占用较多的空间，
为了节省空间可把经济状况分为几种类型，在元组较多的职工关系中用经济状况的类型代替原来的经济状况，这里经济状况的类型就是假属性，另外建立一个较小的关系来描述每种经济状况类型的具体内容。
希赛专家提示：
数据库设计是一项综合性工作，受到各种各样的要求和因素的制约，有些要求往往又是彼此矛盾的，因此，设计结果很难说是最佳，
设计者必须根据实际情况，综合运用上述原则和有关理论，在基本合理的总体设计的基础上，做一些仔细的调整，力求最大限度地满足用户各种各样的要求。
3.3.6 物理结构设计
数据库在实际的物理设备上的存储结构和存取方法称为数据库的物理结构。
数据库物理设计是利用已确定的逻辑结构及DBMS提供的方法、技术，以较优的存储结构、数据存取路径、合理的数据存储位置及存储分配，设计出一个高效、可实现的物理数据库结构。
数据库的物理设计是完全依赖于给定的硬件环境和数据库产品 的。
由于不同的DBMS提供的硬件环境和存储结构、存取方法，以及提供给数据库设计者的系统参数、变化范围有所不同，因此，为了设计出一个较好的存储模式，设计者必须了解以下几方面的问题，做到心中有数。
（1）了解并熟悉应用要求，包括各个用户对应的数据视图，即数据库的外模式（子模式），分清哪些是主要的应用，了解各个应用的使用方式、数据量和处理频率等，以便对十几件和空间进行平衡，并保证优先满足应用的时间要求。
（2）熟悉使用的DBMS的性能，包括DBMS的功能，提供的物理环境、存储结构、存取方法和可利用的工具。
（3）了解存放数据的外存设备的特性，如物理存储区域的划分原则，物理块的大小等有关规定及I/O特性等。
存储模式 和概念模式不一样，它不是面向用户的，一般用户不一定也不需要了解数据库存储模式的细节。
数据库存储模式的设计可以不必考虑用户理解的方便，其设计目标主要是提高数据库的性能，其次是节省存储空间。
在进行物理设计时，因为设计人员可能用到的数据库产品是多种多样的，不同的数据库产品所提供的物理环境、存储结构和存取方法有很大差别，能供设计人员使用的设计变量、参数范围也不大相同，因此没有通用的物理设计方法可遵循，只能给出一般的设计内容和原则。
