7.3.2 逻辑结构设计
概念结构设计阶段得到的E-R图主要是面向用户的，这些模型独立于具体的DBMS。为了实现用户所需要的业务，需要将概念模型转换为某个DBMS所支持的数据模型（例如关系模型）。数据库逻辑结构设计的任务就是把概念结构设计阶段产生的E-R图转换为具体的数据库管理系统支持的数据模型（包括层次模型、网状模型、关系模型），也就是导出特定的DBMS可以处理的数据库逻辑结构（数据库的模式与外模式）。由于关系模型是当前DBMS的主流数据模型，因此以下仅讨论概念模型向关系模型的转换。
概念模型与数据模型、关系模型、SQL Server各概念的对应关系见表7-1。
表7-1 概念模型、数据模型、关系模型、SQL Server各概念对应表
逻辑结构设计一般包含3项工作：
将E-R模型转换为关系数据模型。
对关系数据模型进行优化。
设计面向用户的外模式。
1）E-R模型转换为关系模型
E-R模型转换为关系模型要解决的问题是如何将实体以及实体间的联系转换为关系模式，如何确定这些关系模式的属性和主码。这种转换一般遵循如下原则：
①一个实体型转换为一个关系模式。实体的属性就是关系的属性，实体的码就是关系的码。
②一个1∶1联系可以转换为一个独立的关系模式，也可以与任意一端实体所对应的关系模式合并。如果可以转换为一个独立的关系模式，则与该联系相连的各实体的码以及联系本身的属性均转换为此关系模式的属性，每个实体的码均是该关系的候选码；如果是与联系的任意一端实体所对应的关系模式合并，则需要在该关系模式中加入另一个实体的码和联系本身的属性。在1∶1的联系中，一般将其与任意一端实体对应的关系模式合并，不将1∶1联系转换成一个独立的关系模式。这样可以减少转换出来的关系模式的个数，因为在查询中，涉及的表越多，查询效率就越低。
设有图7-6所示的含有1∶1联系的E-R图，则相应有如下两种转换方法。
将“管理”联系以某一端实体对应的关系模式合并，这种情况下又分两种情况：
一是将“管理”联系与“部门”实体合并，转换后的关系模式为：
部门（部门号，部门名，经理号），部门号为部门关系模式的主码，经理号为部门关系模式的外码；
经理（经理号，经理名，电话），经理号为经理关系模式的主码。
二是将“管理”联系与“经理”实体合并，转换后的关系模式为：
部门（部门号，部门名），部门号为部门关系模式的主码；
经理（经理号，经理名，电话，部门号），经理号为经理关系模式的主码，部门号为经理关系模式的外码。
将“管理”联系转换成一个独立的关系模式，则该E-R图可转换为如下3个关系模式：
部门（部门号，部门名），部门号为部门关系模式的主码；
经理（经理号，经理名，电话），经理号为经理关系模式的主码；
管理（部门号，经理号），部门号和经理号都是管理关系模式的候选码，同时也都是管理关系模式的外码。
图7-6 1∶1联系示例
③一个1∶n联系可以转换为一个独立的关系模式，也可以与n端对应的关系模式合并。如果转换为一个独立的关系模式，则与该联系相连的各实体的码以及联系本身的属性均转换为此关系模式的属性，而关系的码为n端实体的码。如果与n端实体对应的关系模式合并，则需要在该关系模式中加入1端实体的码以及联系本身的属性。同样，在1∶n的联系中，如果能与n端实体对应的关系模式合并，就不将联系转换成一个独立的关系模式。这样也是为了减少关系的个数，提高查询效率。
设有如图7-7所示的含有1∶n联系的E-R图，则相应有如下两种转换方法：
图7-7 1∶n联系示例
将“属于”联系与n端实体对应的关系模式合并，则转换后的关系模式为：
学生（学号，姓名，性别，系名），学号为学生关系模式的主码，系名为引用“系别”关系模式的外码；
系别（系名，人数，电话，地址），系名为主码。
将“属于”联系转换为一个独立的关系模式，则该E-R图可以转换为如下3个关系模式：学生（学号，姓名，性别），学号为学生关系模式的主码；
系别（系名，人数，电话，地址），系名为主码；
属于（学号，系名）学号为属于关系模式的主码，同时也是引用“学生”关系模式的外码，系名为引用“系别”关系模式的外码。
④一个m∶n联系必须转换为一个独立的关系模式。与该联系相连的各实体的码以及联系本身的属性均转换为关系模式的属性，而关系的码为各实体码的组合。
设有如图7-8所示的含有m∶n联系的E-R图，则该E-R图转换后的关系模式为：
图7-8 m∶n联系示例
学生（学号，姓名，性别），学号是学生关系模式的主码；
课程（课程号，课程名，类型，学分），课程号是课程关系模式的主码；
选修（学号，课程号，成绩），（学号，课程号）为选修关系模式的主码，学号是引用“学生”关系模式的外码，课程号是引用“课程”关系模式的外码。
⑤3个或3个以上实体间的一个多元联系转换为一个关系模式。与该多元联系相连的各实体的码以及联系本身的属性均转换为关系的属性，关系的主码为各实体码的组合。
设有如图7-9所示的多元联系的E-R图，这种多元联系一般情况下也可以转换为一个独立的关系模式，这个独立的关系模式的主码只包含其关联实体所对应的各个关系模式的主码的组合。该E-R图转换后的关系模式为：
图7-9 多元联系示例
营业员（工号，姓名，系别），工号是主码；
商品（编号，名称，单价），编号是主码；
顾客（证件号，姓名，性别），证件号是主码；
销售（工号，编号，证件号，数量，销售日期），其中（工号，编号，证件号，销售日期）是主码，工号是引用“营业员”关系模式的外码，编号是引用“商品”关系模式的外码，证件号是引用“顾客”关系模式的外码。
⑥同一实体集的实体间的联系，即自联系，也可按上述1∶1、1∶n和m∶n的3种情况分别处理。
⑦具有相同码的关系模式可合并。
2）数据模型的优化
逻辑结构设计的结果并不是唯一的，为了进一步提高数据库系统的性能，还应该根据应用的需要对数据模型进行适当的修改和调整，这就是数据模型的优化。关系数据模型的优化通常以关系规范化理论为指导，并考虑系统的性能。具体方法如下：
①确定各个属性间的函数依赖关系。根据需求分析阶段得出的语义，分别写出每个关系模式的各属性之间的函数依赖以及不同关系模式中个属性之间的数据依赖关系；
②对各个关系模式之前的数据依赖进行极小化处理，消除冗余的联系；
③判断每个关系模式的范式，根据实际需要确定最合适的范式；
④根据需求分析阶段得到的处理需求，分析这些关系模式对于这样的应用环境是否合适，确定是否要对某些关系模式进行分解或者合并。
这里面需要注意的是如果系统的查询操作比较多，而且对查询响应速度的要求也比较高，则可以适当降低规范化的程度，即将几个表合为一个表，以减少查询时表的连接个数，甚至可以在表中适当增加冗余数据列，比如把一些经过计算得到的值作为表中的一列保存在表中，但这样做要考虑可能引起的潜在的数据不一致问题。
3）设计外模式
将概念模型转换为关系模型之后，还要根据局部应用需求，并结合具体的数据库管理系统的特点，涉及用户的外模式。
外模式概念对应于关系数据库的视图，设计外模式是为了更好地满足各个用户的需求。
定义数据库的模式主要是从系统的时间效率、空间效率、易于维护等角度出发，由于外模式与模式是相对独立的，因此在设计用户外模式时可以从满足每类用户需求的角度出发，同时考虑数据的安全性和用户的操作方便，在定义外模式时应该考虑如下问题：
（1）使用更符合用户习惯的名字
在概念模型设计阶段，当合并各个E-R图时，曾进行了消除命名冲突的工作，以便使数据库中的关系模式和属性具有唯一的名字，这在设计数据库的全局模式时是非常必要的。但在修改了某些属性或者关系模式的名字之后，可能会不符合某些用户的习惯，因此在设计用户模式时，可以利用视图的特点，对某些属性重新命名。视图的名字可以命名成符合用户习惯的名字，使用户操作方便。
（2）对不同级别的用户定义不同的视图，以保证数据的安全
假设有关系模式：职工（职工编号，姓名，工作部门，学历，专业，职称，联系电话，基本工资，业绩津贴，浮动工资）。在这个关系模式上可以创建两个视图：
职工1（职工编号，姓名，工作部门，专业，联系电话）
职工2（职工编号，姓名，学历，职称，联系电话，基本工资，业绩津贴，浮动工资）
职工1视图中只包含一般职工可以查看的基本信息，而职工2视图包含只允许某些人查看的信息。这样就可以防止非法用户访问不允许他们访问的数据，从而在一定程度上保证了数据的安全性。
（3）简化用户对系统的使用
如果某些局部应用经常要使用某些很复杂的查询，为了用户方便，可以将这些复杂的查询定义为一个视图，这样用户每次只对定义好的视图进行查询，而不必编写复杂的查询语句，从而简化用户对数据的操作。