8.5 逻辑结构设计
概念结构是独立于任何一个数据模型的信息结构。逻辑结构设计任务就是把概念结构设计阶段设计好的基本E-R图转换为与选用：DBMS产品所支持的数据模型相符合的逻辑结构。
从理论上讲，设计逻辑应该选择最适于相应概念结构的数据模型，然后对支持这种数据模型的各种DBMS进行比较，从中选出最合适的DBMS。但实际情况往往是已给定了某种DBMS，设计人员没有选择的余地。目前DBMS产品一般支持关系、网状、层次三种模型种的某一种，对某一种数据模型，各个机器系统又有许多不同的限制，提供不同的环境与工具。所以设计逻辑结构时一般要分三步进行（如图8-7所示）。
图8-7 逻辑结构设计时的三个步骤
（1）将概念结构转换为一般的关系、网状、层次模型。
（2）将转换来的关系、网状、层次模型向特定DBMS支持下的数据模型转换。
（3）对数据模型进行优化。
8.5.1 E-R图向关系模型的转换
E-R图向关系模型的转换要解决的问题是如何将实体和实体间的联系转换成关系模式，如何确定这些关系模式的属性和码。
关系模型的逻辑结构是一组关系模式的集合。E-R图则是由实体、实体的属性和实体之间的联系三个要素组成的。所以将E-R图转换为关系模型实际上就是要将实体、实体的属性和实体之间的联系转换为关系模式，这种转换一般遵循如下原则：
（1）一个实体型转换为一个关系模式。实体的属性就是关系的属性，实体的码就是关系的码。
对于实体间的联系则有以下不同的情况：
（2）一个1∶1联系可以转换为一个独立的关系模式，也可以与任意一端对应的关系模式合并。如果转换为一个独立的关系模式，则与该联系相连的各实体的码以及联系本身的属性均转换为关系的属性，每个实体的码均是该关系的候选码。如果与某一端实体对应的关系模式合并，则需要在该关系模式的属性中加入另一个关系模式的码和联系本身的属性。
（3）一个1∶n联系可以转换一个独立的关系模式，也可以与n端对应的关系模式合并。
如果转换一个独立的关系模式，则与该联系相连的各实体的码以及联系本身的属性均转换为关系的属性，而关系的码为n端实体的码。
（4）一个m∶n联系转换一个关系模式。与该联系相连的各实体的码以及联系本身的俑性均转换为关系的属性，而关系的码为各实体码的组合。
（5）三个或三个以上实体间的一个多元联系可以转换为一个关系的模式。与该多元联系相连的各实体的码以及联系本身的属性均转换为关系的属性，而关系的码为各实体码的组合。
（6）具有相同码的关系模式可合并。
下面把图8-6中的销售管理系统的E-R图转换为关系模型。关系的标识码用下横线标出。
顾客（顾客号，顾客名，地址，电话，信贷状况，账目余额）此为顾客实体对应的关系模式。
应收账款（顾客号，订单号，发票号，应收金额，支付日期，支付金额，当前余额，货款限额）此为应付账款实体对应的关系模式。该关系模式已包含了联系——“支付”所对应的关系模式。
订单（订单号，顾客号，订货项数，订货日期，交货日期，工种号，生产地点）
此为订单实体对应的关系模式。该关系模式中已包含了联系——“订货”所对应的关系模式。
订单细则（订单号，细项号，产品号，订货量，金额）
此为订单实体对应的关系模式。该关系模式中已包含了联系——“组成”和“参照1”
所对应的关系模式。
产品描述（产品号，产品名，单价，重量）
此为产品描述实体对应的关系模式。
折扣规则（产品名，订货量，折扣）
此为折扣规则实体对应的关系模式。
形成了一般的数据模式后，下一步就是向特定的RDBMS的模型转换。设计人员必须熟悉所用的RDBMS的功能与限制。这一步是依赖于机器的，不能给出一个普通的规则，但对于关系模型来说，这种转换通常都比较简单，不会有太多的困难。
8.5.2 数据模型的优化
数据库逻辑设计的结果不是唯一的。为了进一步提高数据库应用系统的性能，还应该根据应用需要适当地修改、调整数据模型的结构，这就是数据模型的优化。关系数据模型的优化通常以规范化理论为指导，方法为：
（1）确定数据依赖。
（2）对于各个关系模式之间的数据依赖进行极小化处理，消除冗余的联系。
（3）按照数据依赖的理论对关系模式逐一进行分析，考察是否存在部分函数依赖、传递函数依赖、多值依赖等，确定各关系模式分别属于第几范式。
（4）按照需求分析阶段得到的处理要求，分析这些模式对于这样的应用环境是否合适，确定是否要求对某些模式合并或分解。
（5）对关系模式进行必要的分解，提高数据操作的效率和存储空间的利用率。常用的两种分解方法是水平分解和垂直分解。
8.5.3 设计用户子模式
将概念模型转换为全局逻辑模型后，还应该根据局部应用需求，结合具体DBMS的特点，设计用户的外模式。
目前关系数据库管理系统一般都提供了视图（Viewr）概念，可以利用这一功能设计更糟合局部用户需要的用户外模式。
定义数据全局模式主要是从系统的时间效率、空间效率、易维护等角度出发。由于用户外模式是相对独立的，因此在定义用户外模式时可以注重用户的习惯和方便。包括：
（1）使用更符合用户习惯的别名。
用View机制可以在设计用户View时重新定义某些属性名，使其与用户习惯一致，以方便使用。
（2）可以对不同级别的用户定义不同的View，以保证系统的安全性。
（3）简化用户对系统的使用。
如果某些局部应用中经常要使用某些很复杂的查询，为了方便用户，可以将这些复杂的查询定义为视图，用户每次只对定义好的视图进行查询，大大简化了用户的使用。
8.5.4 基本表
1.Table：Clients
Table：Clients如表8-l所示。
表8-1 顾客表
2.Table：Charge
Table：Charge如表8-2所示。
表8-2 应收账款表
3.Table：Order_Form
Table：Order_Form如表8-3所示。
表8-3 订单表
4.Table：Detailed_Rules
Table：Detailed_Rules如表8-4所示。
表8-4 订单细则表
5.Table：Production_Description
Table：Production_Description如表8-5所示。
表8-5 产品描述表
6.Table：Discount_Rule
Table：Discount_Rule如表8-6所示。
表8-6 折扣规则表
免责声明：以上内容源自网络，版权归原作者所有，如有侵犯您的原创版权请告知，我们将尽快删除相关内容。
