数据库逻辑结构设计该系列计划包括5部分:完整性约束理论及应用、范式理论及应用、需求分析、概念结构设计、逻辑结构设计．本文就是第五部分，介绍逻辑结构设计得内容,包括E-R图向关系模型得转换、数据模型得优化、用户子模式得设计等问题。1。逻辑设计概述概念结构就是独立于任何一种数据模型得,在实际应用中,一般所用得数据库环境已经给定（如ＳＱLServer或Oｒaｃeｌ或MySql)，本文讨论从概念结构向逻辑结构得转换问题。由于目前使用得数据库基本上都就是关系数据库,因此首先需要将Ｅ—Ｒ图转换为关系模型,然后根据具体DBＭS得特点与限制转换为特定得DBMS支持下得数据模型，最后进行优化。２。E—R图向关系模型得转换２、１一个例子E-R图如何转换为关系模型呢?我们先瞧一个例子。图2、1就是学生与班级得E-R图，学生与班级构成多对一得联系．根据实际应用,我们可以做出这个简单例子得关系模式：学生（学号，姓名,班级)班级(编号，名称）“学生、班级”为外键,参照“班级、编号”取值。这个例子我们就是凭经验转换得，那么里面有什么规律呢？在2、2节,我们将这些经验总结成一些规则,以供转换使用。2、2转换规则（1）一个实体型转换为一个关系模式一般E－R图中得一个实体转换为一个关系模式，实体得属性就就是关系得属性,实体得码就就是关系得码。(2)一个1:1联系可以转换为一个独立得关系模式,也可以与任意一端对应得关系模式合并。图2、2就是一个一对一联系得例子。根据规则（2)，有三种转换方式。(i）联系单独作为一个关系模式此时联系本身得属性，以及与该联系相连得实体得码均作为关系得属性,可以选择与该联系相连得任一实体得码属性作为该关系得码。结果如下:职工(工号,姓名）产品(产品号,产品名)负责（工号,产品号)其中“负责"这个关系得码可以就是工号,也可以就是产品号。(ii)与职工端合并职工（工号,姓名,产品号)产品(产品号,产品名)其中“职工、产品号＂为外码.(ｉｉｉ)与产品端合并职工（工号，姓名）产品（产品号，产品名,负责人工号）其中“产品、负责人工号”为外码。(３)一个1：n联系可以转换为一个独立得关系模式，也可以与n端对应得关系模式合并。(i）若单独作为一个关系模式此时该单独得关系模式得属性包括其自身得属性,以及与该联系相连得实体得码。该关系得码为n端实体得主属性。顾客（顾客号，姓名）订单（订单号,……)订货(顾客号，订单号）(ii)与n端合并顾客(顾客号,姓名)订单(订单号,……，顾客号）（4）一个m：ｎ联系可以转换为一个独立得关系模式.该关系得属性包括联系自身得属性,以及与联系相连得实体得属性。各实体得码组成关系码或关系码得一部分.教师(教师号,姓名)学生(学号,姓名）教授(教师号,学号）(5）一个多元联系可以转换为一个独立得关系模式。与该多元联系相连得各实体得码，以及联系本身得属性均转换为关系得属性，各实体得码组成关系得码或关系码得一部分。(6)具有相同码得关系模式可以合并。(7)有些1:ｎ得联系,将属性合并到ｎ端后，该属性也作为主码得一部分这类问题多出现在聚集类得联系中，且部分实体得码只能在某一个整体中作为码,而在全部整体中不能作为码得情况下才出现(其它情况本人还没碰到,呵呵，欢迎指教）.比如上篇文章介绍得管理信息系统中订单与订单细节得联系。关于什么就是聚集，2、3节介绍.２、３数据抽象得分类这部分本应在概念设计中介绍得,用到了才想起来，这里补充一下.关于现实世界得抽象，一般分为三类：(1)分类:即对象值与型之间得联系，可以用“iｓmemberof”判定.如张英、王平都就是学生,她们与“学生"之间构成分类关系。（2）聚集：定义某一类型得组成成分,就是“ispartof”得联系。如学生与学号、姓名等属性得联系。(３)概括:定义类型间得一种子集联系，就是“issubsｅtof"得联系。如研究生与本科生都就是学生,而且都就是集合,因此它们之间就是概括得联系。例:猫与动物之间就是概括得联系,《ToｍａnｄJerry》中那只名叫Tｏm得猫与猫之间就是分类得联系,Tｏｍ得毛色与Tom之间就是聚集得联系。订单细节与订单之间,订单细节肯定不就是一个订单,因此不就是概括或分类。订单细节就是订单得一部分，因此就是聚集。2、4数据模型得优化有了关系模型，可以进一步优化,方法为：（1)确定数据依赖。(2）对数据依赖进行极小化处理,消除冗余联系(参瞧范式理论)。(3)确定范式级别,根据应用环境,对某些模式进行合并或分解.以上工作理论性比较强，主要目得就是设计一个数据冗余尽量少得关系模式。下面这步则就是考虑效率问题了:(4)对关系模式进行必要