数据库逻辑结构设计.pdfVIP

数据库逻辑结构设计 该系列计划包括5部分：完整性约束理论及应用、范式理论及应用、需求分 析、概念结构设计、逻辑结构设计。本文是第五部分，介绍逻辑结构设计的内容， 包括E-R 图向关系模型的转换、数据模型的优化、用户子模式的设计等问题。 1．逻辑设计概述 概念结构是独立于任何一种数据模型的，在实际应用中，一般所用的数据库 环境已经给定（如SQL Server或Oracel或MySql），本文讨论从概念结构向逻 辑结构的转换问题。 由于目前使用的数据库基本上都是关系数据库，因此首先需要将E-R 图转换 为关系模型，然后根据具体DBMS 的特点和限制转换为特定的DBMS支持下的数据 模型，最后进行优化。 2．E-R 图向关系模型的转换 2.1 一个例子 E-R 图如何转换为关系模型呢？我们先看一个例子。 图2.1是学生和班级的E-R 图，学生与班级构成多对一的联系。根据实际应 用，我们可以做出这个简单例子的关系模式： 学生（学号，姓名，班级） 班级（编号，名称） “学生.班级”为外键，参照“班级.编号”取值。 这个例子我们是凭经验转换的，那么里面有什么规律呢？在2.2节，我们将 这些经验总结成一些规则，以供转换使用。 2.2 转换规则 (1) 一个实体型转换为一个关系模式 一般E-R 图中的一个实体转换为一个关系模式，实体的属性就是关系的属性， 实体的码就是关系的码。 (2) 一个1:1联系可以转换为一个独立的关系模式，也可以与任意一端对应 的关系模式合并。 图2.2是一个一对一联系的例子。根据规则（2），有三种转换方式。 联系单独作为一个关系模式 此时联系本身的属性，以及与该联系相连的实体的码均作为关系的属性，可 以选择与该联系相连的任一实体的码属性作为该关系的码。结果如下： 职工（工号，姓名） 产品（产品号，产品名） 负责（工号，产品号） 其中“负责”这个关系的码可以是工号，也可以是产品号。 ) 与职工端合并 职工（工号，姓名，产品号） 产品（产品号，产品名） 其中“职工.产品号”为外码。 i) 与产品端合并 职工（工号，姓名） 产品（产品号，产品名，负责人工号） 其中“产品.负责人工号”为外码。 (3) 一个1:n联系可以转换为一个独立的关系模式，也可以与n端对应的关 系模式合并。 (i)若单独作为一个关系模式 此时该单独的关系模式的属性包括其自身的属性，以及与该联系相连的实体 的码。该关系的码为n端实体的主属性。 顾客（顾客号，姓名） 订单（订单号，……） 订货（顾客号，订单号） (ii) 与n端合并 顾客（顾客号，姓名） 订单（订单号，……，顾客号） (4) 一个m:n联系可以转换为一个独立的关系模式。 该关系的属性包括联系自身的属性，以及与联系相连的实体的属性。各实体 的码组成关系码或关系码的一部分。 教师（教师号，姓名） 学生（学号，姓名） 教授（教师号，学号） (5) 一个多元联系可以转换为一个独立的关系模式。 与该多元联系相连的各实体的码，以及联系本身的属性均转换为关系的属性， 各实体的码组成关系的码或关系码的一部分。 (6) 具有相同码的关系模式可以合并。 (7) 有些 1：n 的联系，将属性合并到 n 端后，该属性也作为主码的一部分 这类问题多出现在聚集类的联系中，且部分实体的码只能在某一个整体中作 为码，而在全部整体中不能作为码的情况下才出现 （其它情况本人还没碰到，呵 呵，欢迎指教） 比如上篇文章介绍的管理信息系统中订单与订单细节的联系 关于什么是聚集，2.3 节介绍 2.3 数据抽象的分类 这部分本应在概念设计中介绍的，用到了才想起来，这里补充一下 关于现实世界的抽象，一般分为三类： 分类：即对象值与型之间的联系，可以用“is member of”判定 如张英、王平都是学生，他们与“学生”之间构成分类关系