2023年7月27日发(作者：)

数据库的逻辑结构设计逻辑结构是独⽴于任何⼀种数据模型的，在实际应⽤中，⼀般所⽤的数据库环境已经给定(如SQL Server或Oracle或MySql)。由于⽬前使⽤的数据库基本上都是关系数据库，因此⾸先需要将转换为关系模型，然后根据具体DBMS的特点和限制转换为特定的DBMS⽀持下的数据模型，最后进⾏优化。设计步骤( 1 ) 将概念结构转换为⼀般的关系、⽹状、层次模型;( 2 ) 将转换来的关系、⽹状、层次模型向特定 DBMS ⽀持下的数据模型转换;( 3 ) 对数据模型进⾏优化。E-R图基本组成的组件有很多，但概括起来说，可分为以下四种:线段:⽤于将实体、关系相连接对于双矩形、双菱形、双椭圆、双线段等等⼀些组件，可以不⽤去管，通常⽤以上四种组件就可以表达清楚实体及实体间的关系。从E-R图向关系模式转化 数据库的逻辑设计主要是将概念模型转换成⼀般的关系模式，也就是将E-R图中的实体、实体的属性和实体之间的联系转化为关系模式。在转化过程中会遇到如下问题:(1)命名问题。命名问题可以采⽤原名，也可以另⾏命名，避免重名。(2)⾮原⼦属性问题。⾮原⼦属性问题可将其进⾏纵向和横⾏展开。(3)联系转换问题。联系可⽤关系表⽰。建⽴E-R模型1、标识实体:通常有⽤户、⾓⾊这两个实体。2、标识关系:⽤户与⾓⾊间为多对多的互相拥有关系。3、标识实体、关系的属性:不仅仅是实体有属性，关系同样也有属性，这些属性在实体间建⽴关系时才会存在。有时属性太多，⽆法在图上⼀⼀列出，可以⽤表格，在后⾯的步骤中这个表格同样会⽤到，如下:实体属性性别⽤户年龄电话…4、确定属性域:属性域就是属性的取值范围。这时，可以⽤表格将属性的数据类型、数据长度、取值范围及是否可为空、简单/复合、单值/多值、是否为派⽣属性等域信息定义出来。这个过程，事实上包含了逻辑结构设计中的数据类型、NULL、CHECK、DEFAULT等信息。描述男/⼥多⼤了联系⽅式………实体属性性别描述男/⼥多⼤了联系⽅式…数据类型及长度1字节的短整形或布尔型1字节的短整形20字节的字符型或长整形…是否可为空NONOYES⽤户年龄电话…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)对复杂的查询操作，可以定义视图，简化⽤户对系统的使⽤。物理设计主要⼯作是选择存取⽅法(索引)，以及确定数据库的存储结构，这⾥就不说明了。