逻辑结构设计
 
逻辑结构设计的任务 
 把概念结构设计阶段设计好的基本E-R图转换为与选用DBMS产品所支持的数据模型相符合的逻辑结构 
 逻辑结构设计的步骤 
 将概念结构转化为一般的关系、网状、层次模型 
 将转换来的关系、网状、层次模型向特定DBMS支持下的数据模型转换 
 对数据模型进行优化
 
E-R图向关系模型的转换
 
E-R图向关系模型的转换要解决的问题 
 如何将实体型和实体间的联系转换为关系模式 
 如何确定这些关系模式的属性和码 
 转换内容 
 将E-R图转换为关系模型：将实体、实体的属性和实体之间的联系转换为关系模式。
 
实体型间的联系有以下不同情况 ：
 
(1)一个1:1联系可以转换为一个独立的关系模式，也可以与任意一端对应的关系模式合并。
转换为一个独立的关系模式
 与某一端实体对应的关系模式合并
 
(2)一个1:n联系可以转换为一个独立的关系模式，也可以与n端对应的关系模式合并。
 转换为一个独立的关系模式
与n端对应的关系模式合并
 
(3) 一个m:n联系转换为一个关系模式。
    例，“选修”联系是一个m:n联系，可以将它转换为如下关系模式，其中学号与课程号为关系的组合码：
　　选修（学号，课程号，成绩）
 
教师（教师号，姓名，职称） 
 主键：教师号 
 课程（课程号，课程名称，教师号，教材） 
 主键：课程号 外键：教师号 
 学生（学号，姓名，性别，教师号） 
 主键：学号 外键：教师号 
 选课（学号，课程号， 成绩） 
 主键：（学号，课程号） 
 外键 1：学号，外键 2：课程号
 
(4)三个或三个以上实体间的一个多元联系转换为一个关系模式。
    例，“讲授”联系是一个三元联系，可以将它转换为如下关系模式，其中课程号、职工号和书号为关系的组合码：
　　讲授（课程号，职工号，书号）
(5)具有相同码的关系模式可合并
目的：减少系统中的关系个数
合并方法：将其中一个关系模式的全部属性加入到另一个关系模式中，然后去掉其中的同义属性（可能同名也可能不同名），并适当调整属性的次序
 
注意： 
 从理论上讲，1:1联系可以与任意一端对应的关系模式合并 
 但在一些情况下，与不同的关系模式合并效率会大不一样。因此究竟应该与哪端的关系模式合并需要依应用的具体情况而定。 
 由于连接操作是最费时的操作，所以一般应以尽量减少连接操作为目标。 
 例如，如果经常要查询某个班级的班主任姓名，则将管理联系与教师关系合并更好些。
 
[例] 把图7.30中虚线上部的E-R图转换为关系模型 
部门实体对应的关系模式 
    部门（部门号，部门名，经理的职工号，…） 
此关系模式已包含了联系“领导”所对应的关系模式 
经理的职工号是关系的候选码 
职工实体对应的关系模式 
    职工（职工号、部门号，职工名，职务，…） 
该关系模式已包含了联系“属于”所对应的关系模式 
 
[例] 把图7.30中虚线上部的E-R图转换为关系模型（续） 
产品实体对应的关系模式 
    产品（产品号，产品名，产品组长的职工号，…）
供应商实体对应的关系模式 
    供应商（供应商号，姓名，…） 
零件实体对应的关系模式 
    零件（零件号，零件名，…） 
 
[例] 把图7.30中虚线上部的E-R图转换为关系模型（续） 
联系“参加”所对应的关系模式 
    职工工作（职工号，产品号，工作天数，…） 
联系“供应”所对应的关系模式 
   供应（产品号，供应商号，零件号，供应量） 
 
数据模型的优化
 
得到初步数据模型后，还应该适当地修改、调整数据模型的结构，以进一步提高数据库应用系统的性能，这就是数据模型的优化 
 关系数据模型的优化通常以规范化理论为指导
 
优化数据模型的方法 
 确定数据依赖 
 按需求分析阶段所得到的语义，分别写出每个关系模式内部各属性之间的数据依赖以及不同关系模式属性之间数据依赖 
 消除 冗余的联系 
 对于各个关系模式之间的数据依赖进行极小化处理，消除 冗余的联系。 
 确定所属范式 
 按照数据依赖的理论对关系模式逐一进行分析 
 考查是否存在部分函数依赖、传递函数依赖、多值依赖等 
 确定各关系模式分别属于第几范式
 
按照需求分析阶段得到的各种应用对数据处理的要求，分析对于这样的应用环境这些模式是否合适， 
 确定是否要对它们进行合并或分解。 
 注意：并不是规范化程度越高的关系就越优，一般说来，第三范式就足够了
 
例：在关系模式
           学生成绩单(学号,英语,数学,语文,平均成绩) 
           中存在下列函数依赖：
　           学号→英语
　           学号→数学
　           学号→语文
　           学号→平均成绩
            (英语, 数学, 语文)→平均成绩
 
  显然有：
          学号→(英语,数学,语文)
因此该关系模式中存在传递函数信赖，是2NF关系

   虽然平均成绩可以由其他属性推算出来，但如果应用中需要经常查询学生的平均成绩，为提高效率，仍然可保留该冗余数据，对关系模式不再做进一步分解
 
按照需求分析阶段得到的各种应用对数据处理的要求，对关系模式进行必要的分解，以提高数据操作的效率和存储空间的利用率 
 常用分解方法 
 水平分解 
 垂直分解 
 水平分解 
 什么是水平分解 
 把(基本)关系的元组分为若干子集合，定义每个子集合为一个子关系，以提高系统的效率 
 水平分解的适用范围 
 满足“80/20原则”的应用 
 并发事务经常存取不相交的数据 
 垂直分解 
 什么是垂直分解 
 把关系模式R的属性分解为若干子集合，形成若干子关系模式 
 垂直分解的适用范围 
 取决于分解后R上的所有事务的总效率是否得到了提高
 
设计用户子模式
 
定义用户外模式时应该注重的问题 
 包括三个方面： 
 (1) 使用更符合用户习惯的别名 
 (2) 针对不同级别的用户定义不同的View ，以 满足系统对安全性的要求。 
 (3) 简化用户对系统的使用
 
[例] 关系模式产品（产品号，产品名，规格，单价，生产车间，生产负责人，产品成本，产品合格率，质量等级），可以在产品关系上建立两个视图：
        为一般顾客建立视图：
            产品1（产品号，产品名，规格，单价）
        为产品销售部门建立视图：
            产品2（产品号，产品名，规格，单价，车间，生产负责人）
顾客视图中只包含允许顾客查询的属性
销售部门视图中只包含允许销售部门查询的属性
生产领导部门则可以查询全部产品数据
可以防止用户非法访问不允许他们查询的数据，保证系统的安全性
 
任务 
 将概念结构转化为具体的数据模型 
 逻辑结构设计的步骤 
 将概念结构转化为一般的关系、网状、层次模型 
 将转化来的关系、网状、层次模型向特定DBMS支持下的数据模型转换 
 对数据模型进行优化 
 设计用户子模式
 
逻辑结构设计小结
 
E-R图向关系模型的转换内容 
 E-R图向关系模型的转换原则
 
优化数据模型的方法 
 1. 确定数据依赖 
 2. 对于各个关系模式之间的数据依赖进行极小化处理，消除冗余的联系。 
 3. 确定各关系模式分别属于第几范式。 
 4. 分析对于应用环境这些模式是否合适，确定是否要对它们进行合并或分解。 
 5. 对关系模式进行必要的分解或合并 
 设计用户子模式 
 1. 使用更符合用户习惯的别名 
 2. 针对不同级别的用户定义不同的外模式，以满足系统对安全性的要求。 
 3. 简化用户对系统的使用

转载： https://blog.csdn.net/HaoDaWang/article/details/78098937?locationNum=4&fps=1
 
如何把ER模型转换为关系模型
 
这是数据库工程设计进行到逻辑设计的一重大环节，简单的说，如果概念设计是用ER模型， 整合为全局的ER模型，那么在逻辑设计这块， 主要任务就是把ER模型转换为关系模型。
 
转换只需知道三个转换准则:
 
1:1
 
遇到1:1 关系的话在两个实体任选一个添加另一个实体的主键即可。
 
1:N
 
遇到 1:N 关系的话在N端添加另一端的主键。
 
假如有学生和班级两个实体，一个班级可以容纳多个学生，但是一个学生只能选择一个班级， 因此班级和学生是1:N的关系，现在要转换为关系模型， 我们只需在学生的这端加上班级的唯一标识即可，这样做的原因是，因为一个学生只能有一个班级，班级是相对学生唯一的。
 
N:M
 
遇到N:M，我们需要将联系转换为实体，然后在该实体上加上另外两个实体的主键，作为联系实体的主键，然后再加上该联系自身带的属性即可。
 
例如有学生和老师两个实体， 一个学生可以由多名老师来授课，一名老师也可以授课多名学生，它们是M:N关系的，假如联系为授课，该联系上有成绩属性，因此当我们把它转换为关系模型时，我们把联系转换为联系实体，并添加学生实体的主键（学号）和教师实体的主键（教师编号）作为自己的主键，值得注意的是，授课实体的外键分别是学号和教师编号，但是它的主键是（学号，教师编号），另外它还拥有自己的一个属性成绩。
 
1:1:N
 
这是三元联系的对应关系，但是当转换为关系模型时，和1:N的情况是差不多的。我们只需将N端添加另外两端的主键即可。
 
M:N:P
 
这种三元联系的三种多对应关系，看上去很复杂，其实转换起来并不是那么复杂了，我们要做的仅仅是将其中的联系转换为联系实体，然后在联系实体上添加M端N端P端的主键，然后加上联系实体自身的属性，就行了。
 
例子：
 
说了这么多看个小例子。
 
 
这是一份关于商店商品仓库的ER图。
 
先看仓库和商品之间是M:N的关系，于是我们首先想到的应该是把联系 库存转换为库存实体。 
 库存 （仓库号，商品号，日期，库存量） 
 然后是商品实体和仓库实体 
 商品（商品号，商品名，单价） 
 仓库（仓库号，仓库名，地址）
 
除此之外仓库和商品还有一个供应关系，同样是M:N关系： 
 供应 （仓库号，商品号 ，月份，月供应量）
 
在上图的商店和仓库之间的关系可能写漏了，但是它们应该也是M:N的关系，一个商店可以被多个仓库供应，一个仓库也可以供应多个商店。上面已经创建了供应实体，现在只需在供应实体中加入商店号即可，也就是商店实体的主键。
 
供应（仓库号，商品号，商店号 ，月份，月供应量） 
 商店（商店号，商店名，地址）
 
总结
 
至此，转换关系模型也完成了，当然这只是个例子，实际的开发中，我们可能会遇到各式各样奇怪的需求，这就更要求我们做好概念设计的环节，对后来的数据库设计和维护都有好处。ER图的好坏，始终是数据库设计的重要一节。

 

  
逻辑结构是独立于任何一种数据模型的，在实际应用中，一般所用的数据库环境已经给定(如SQL Server或Oracle或MySql)。由于目前使用的数据库基本上都是关系数据库，因此首先需要将E-R图转换为关系模型，然后根据具体DBMS的特点和限制转换为特定的DBMS支持下的数据模型，最后进行优化。
 

折叠编辑本段设计步骤

 

  
( 1 ) 将概念结构转换为一般的关系、网状、层次模型;
  
( 2 ) 将转换来的关系、网状、层次模型向特定 DBMS 支持下的数据模型转换;
  
( 3 ) 对数据模型进行优化。
 

折叠编辑本段E-R图

 
折叠基本组成
 

  
教务管理系统的E-R图E-R图的组件有很多，但概括起来说，可分为以下四种:
  
线段:用于将实体、关系相连接
  
对于双矩形、双菱形、双椭圆、双线段等等一些组件，可以不用去管，通常用以上四种组件就可以表达清楚实体及实体间的关系。
  
从E-R图向关系模式转化 数据库的逻辑设计主要是将概念模型转换成一般的关系模式，也就是将E-R图中的实体、实体的属性和实体之间的联系转化为关系模式。在转化过程中会遇到如下问题:
  
(1)命名问题。命名问题可以采用原名，也可以另行命名，避免重名。
  
(2)非原子属性问题。非原子属性问题可将其进行纵向和横行展开。
  
(3)联系转换问题。联系可用关系表示。
 
 
折叠建立E-R模型
 

  
1、标识实体:标识实体
  
通常有用户、角色这两个实体。
  
2、标识关系:
  
用户与角色间为多对多的互相拥有关系。标识关系
  
3、标识实体、关系的属性:
  
不仅仅是实体有属性，关系同样也有属性，这些属性在实体间建立关系时才会存在。
  
有时属性太多，无法在图上一一列出，可以用表格，在后面的步骤中这个表格同样会用到，如下:
  
实体
属性
描述
…
用户
性别
年龄
电话
…
男/女
多大了
联系方式
…
…
  
4、确定属性域:
  
属性域就是属性的取值范围。
  
这时，可以用表格将属性的数据类型、数据长度、取值范围及是否可为空、简单/复合、单值/多值、是否为派生属性等域信息定义出来。
  
这个过程，事实上包含了逻辑结构设计中的数据类型、NULL、CHECK、DEFAULT等信息。
  
实体
属性
描述
数据类型及长度
是否可为空
用户
性别
年龄
电话
…
男/女
多大了
联系方式
…
1字节的短整形或布尔型
1字节的短整形
20字节的字符型或长整形
…
NO
NO
YES
  
5、确定键:键就是可用于标识实体的属性，有:主键、唯一键、外键。
  
实体
属性
描述
键
用户
用户编号
性别
年龄
电话
…
男/女
多大了
联系方式
…
主键
  
6、实体的特化/泛化:
  
也就是面向对象模型中父类和子类的概念，这是个可选的步骤。实体的特化/泛华举个例子，用户中大部分人都是普通员工，但有一小部分是从事销售的，销售人员
  
有个负责区域的属性，如果将这个属性放在用户实体中，如右图:
  
这时我们会发现，除了销售人员外，其他非销售人员这个属性全都不存在，这就是特化的过程。可以另建一个销售人员的实体来泛化用户实体，如右图:
  
这样就完成了对用户实体的泛化，泛化的过程也就是抽出实体间公共属性的过程，但通常，除非特化的部分太多，才会考虑将一个实体抽象成两个
  
1对1关系的实体，所有这个步骤是可选的。
  
7、检查模型:
  
(1)检查冗余
  
首先检查实体:1对1关系的实体中有没有非外键的重复属性，或者就是同一个实体;
  
其次检查关系:有没有通过其他关系也可以得到的重复属性;
  
当然有时，需要考虑时间维度，因为有些属性是有时效性的，也就是虽然是同一个属性，但不同的时间表示的却是不同的内容，这一点在后面的逻辑结构设计中会提到，这并不是真正的冗余。
  
(2)检查业务
  
检查当前的E-R模型是否满足当前业务的场景。可以从某个实体开始，沿着当前E-R模型的各个节点去模拟业务场景。尤其需要和《需求规格说明书》去做校验。
  
到这里，也就完成了E-R模型建立的全过程，有时，对于比较复杂的E-R模型，一张图可能显得太过局促，可以建立全局、局部E-R模型图，以便于查看和分析。
 

折叠编辑本段图向关系

 

  
模型的转换
 
 
折叠示例
 

  
E-R图如何转换为关系模型呢?我们先看一个例子。
  
图2.1是学生和班级的E-R图，学生与班级构成多对一的联系。根据实际应用，我们可以做出这个简单例子的关系模式:
  
学生(学号，姓名，班级)
  
班级(编号，名称)
  
"学生.班级"为外键，参照"班级.编号"取值。
  
这个例子我们是凭经验转换的，那么里面有什么规律呢?在2.2节，我们将这些经验总结成一些规则，以供转换使用。
 
 
折叠转换规则
 

  
(1)一个实体型转换为一个关系模式
  
一般E-R图中的一个实体转换为一个关系模式，实体的属性就是关系的属性，实体的码就是关系的码。
  
(2)一个1:1联系可以转换为一个独立的关系模式，也可以与任意一端对应的关系模式合并。
  
图2.2是一个一对一联系的例子。根据规则(2)，有三种转换方式。
  
(i) 联系单独作为一个关系模式
  
此时联系本身的属性，以及与该联系相连的实体的码均作为关系的属性，可以选择与该联系相连的任一实体的码属性作为该关系的码。结果如下:
  
职工(工号，姓名)
  
产品(产品号，产品名)
  
负责(工号，产品号)
  
其中"负责"这个关系的码可以是工号，也可以是产品号。
  
(ii) 与职工端合并
  
职工(工号，姓名，产品号)
  
产品(产品号，产品名)
  
其中"职工.产品号"为外码。
  
(iii) 与产品端合并
  
职工(工号，姓名)
  
产品(产品号，产品名，负责人工号)
  
其中"产品.负责人工号"为外码。
  
(3)一个1:n联系可以转换为一个独立的关系模式，也可以与n端对应的关系模式合并。
  
(i) 若单独作为一个关系模式
  
此时该单独的关系模式的属性包括其自身的属性，以及与该联系相连的实体的码。该关系的码为n端实体的主属性。
  
顾客(顾客号，姓名)
  
订单(订单号，……)
  
订货(顾客号，订单号)
  
(ii) 与n端合并
  
顾客(顾客号，姓名)
  
订单(订单号，……，顾客号)
  
(4)一个m:n联系可以转换为一个独立的关系模式。
  
该关系的属性包括联系自身的属性，以及与联系相连的实体的属性。各实体的码组成关系码或关系码的一部分。
  
教师(教师号，姓名)
  
学生(学号，姓名)
  
教授(教师号，学号)
  
(5)一个多元联系可以转换为一个独立的关系模式。
  
与该多元联系相连的各实体的码，以及联系本身的属性均转换为关系的属性，各实体的码组成关系的码或关系码的一部分。
  
(6)具有相同码的关系模式可以合并。
  
(7)有些1:n的联系，将属性合并到n端后，该属性也作为主码的一部分
  
这类问题多出现在聚集类的联系中，且部分实体的码只能在某一个整体中作为码，而在全部整体中不能作为码的情况下才出现(其它情况本人还没碰到，呵呵，欢迎指教)。
  
比如上篇文章介绍的管理信息系统中订单与订单细节的联系。
  
关于什么是聚集，2.3节介绍。
 
 
折叠数据抽象的分类
 

  
这部分本应在概念设计中介绍的，用到了才想起来，这里补充一下。
  
关于现实世界的抽象，一般分为三类:
  
(1) 分类:即对象值与型之间的联系，可以用"is member of"判定。如张英、王平都是学生，他们与"学生"之间构成分类关系。
  
(2) 聚集:定义某一类型的组成成分，是"is part of"的联系。如学生与学号、姓名等属性的联系。
  
(3) 概括:定义类型间的一种子集联系，是"is subset of"的联系。如研究生和本科生都是学生，而且都是集合，因此它们之间是概括的联系。
  
例:猫和动物之间是概括的联系，《Tom and Jerry》中那只名叫Tom的猫与猫之间是分类的联系，Tom的毛色和Tom之间是聚集的联系。
  
订单细节和订单之间，订单细节肯定不是一个订单，因此不是概括或分类。订单细节是订单的一部分，因此是聚集。
 
 
折叠数据模型的优化
 

  
有了关系模型，可以进一步优化，方法为:
  
(1) 确定数据依赖。
  
(2) 对数据依赖进行极小化处理，消除冗余联系(参看范式理论)。
  
(3) 确定范式级别，根据应用环境，对某些模式进行合并或分解。
  
以上工作理论性比较强，主要目的是设计一个数据冗余尽量少的关系模式。下面这步则是考虑效率问题了:
  
(4) 对关系模式进行必要的分解。
  
如果一个关系模式的属性特别多，就应该考虑是否可以对这个关系进行垂直分解。如果有些属性是经常访问的，而有些属性是很少访问的，则应该把它们分解为两个关系模式。
  
如果一个关系的数据量特别大，就应该考 虑是否可以进行水平分解。如一个论坛中，如果设计时把会员发的主贴和跟贴设计为一个关系，则在帖子量非常大的情况下，这一步就应该考虑把它们分开了。因为 显示的主贴是经常查询的，而跟贴则是在打开某个主贴的情况下才查询。又如手机号管理软件，可以考虑按省份或其它方式进行水平分解。
 
 
折叠设计用户子模式
 

  
这部分主要是考虑使用方便性和效率问题，主要借助视图手段实现，包括:
  
(1) 建立视图，使用更符合用户习惯的别名。
  
(2)对不同级别的用户定义不同的视图，以保证系统的安全性。
  
(3)对复杂的查询操作，可以定义视图，简化用户对系统的使用。
  
物理设计主要工作是选择存取方法(索引)，以及确定数据库的存储结构，这里就不说明了。
 

       数据库的概念结构设计：需求分析阶段所得到的应用需求应该首先抽象成信息世界的结构，才能更好地、更准确地用某一DBMS实现。
 
       数据库的逻辑结构设计：逻辑结构设计的任务就是将概念结构设计阶段设计好的全局E-R图转换成DBMS产品所支持的数据模型（关系模型），并进行规范化和优化，然后为每个应用设计外模式。
 
       数据库的物理结构设计：数据库在物理设备上的存储结构和存取方法就称为数据库的物理结构。