数据库逻辑结构设计

1、数据库逻辑结构设计数据库逻辑结构设计该系列计划包括 5 部分 : 完整性约束理论及应用、 范式理论及应用、需求分析、概念结构设计、逻辑结构设计。本文就是第五部分 , 介绍逻辑结构设计的内容 , 包括 e-r 图向关系模型的转换、数据模型的优化、用户子模式的设计等问题。1. 逻辑设计概述概念结构就是独立于任何一种数据模型的, 在实际应用中 , 一般所用的数据库环境已经给定 ( 如 sql server 或 oracel 或 mysql), 本文讨论从概念结构向逻辑结构的转换问题。由于目前使用的数据库基本上都就是关系数据库 , 因此首先需要将 e-r 图转换为关系模型 , 然后根据具体 dbms的

2、特点与限制转换为特定的 dbms支持下的数据模型 , 最后进行优化。2.e-r 图向关系模型的转换2、1 一个例子e-r 图如何转换为关系模型呢？我们先瞧一个例子。图 2、1 就是学生与班级的 e-r 图, 学生与班级构成多对一的联系。根据实际应用 , 我们可以做出这个简单例子的关系模式 :学生 ( 学号 , 姓名 , 班级 )班级 ( 编号 , 名称 )“学生、班级”为外键 , 参照“班级、编号”取值。这个例子我们就是凭经验转换的 , 那么里面有什么规律呢？在 2、2 节, 我们将这些经验总结成一些规则 , 以供转换使用。2、2 转换规则(1) 一个实体型转换为一个关系模式一般 e-r 图中

3、的一个实体转换为一个关系模式 , 实体的属性就就是关系的属性 , 实体的码就就是关系的码。数据库逻辑结构设计(2) 一个 1:1 联系可以转换为一个独立的关系模式 , 也可以与任意一端对应的关系模式合并。图 2、2 就是一个一对一联系的例子。根据规则(2), 有三种转换方式。联系单独作为一个关系模式此时联系本身的属性 , 以及与该联系相连的实体的码均作为关系的属性, 可以选择与该联系相连的任一实体的码属性作为该关系的码。结果如下:职工 ( 工号 , 姓名 )产品 ( 产品号 , 产品名 )负责 ( 工号 , 产品号 )其中“负责”这个关系的码可以就是工号, 也可以就是产品号。)与职工端合并职工

4、 ( 工号 , 姓名 , 产品号 )产品 ( 产品号 , 产品名 )其中“职工、产品号”为外码。i)与产品端合并职工 ( 工号 , 姓名 )产品 ( 产品号 , 产品名 , 负责人工号 )其中“产品、负责人工号”为外码。(3)一个 1:n 联系可以转换为一个独立的关系模式, 也可以与n 端对应的关系模式合并。数据 构 (i) 若 独作 一个关系模式此 独的关系模式的属性包括其自身的属性 , 以及与 系相 的 体的 。 关系的 n 端 体的主属性。 客 ( 客号 , 姓名 )订单 ( 号 , )订货 ( 客号 , 号 )(ii) 与 n 端合并 客 ( 客号 , 姓名 )订单 ( 号 , , 客

5、号 )(4) 一个 m:n 系可以 一个独立的关系模式。 关系的属性包括 系自身的属性 , 以及与 系相 的 体的属性。 各 体的 成关系 或关系 的一部分。教 ( 教 号 , 姓名 )学生 ( 学号 , 姓名 )教授 ( 教 号 , 学号 )(5) 一个多元 系可以 一个独立的关系模式。与 多元 系相 的各 体的 , 以及 系本身的属性均 关系的属性 , 各 体的 成关系的 或关系 的一部分。(6) 具有相同 的关系模式可以合并。数据库逻辑结构设计(7) 有些 1:n 的联系 , 将属性合并到 n 端后 , 该属性也作为主码的一部分这类问题多出现在聚集类的联系中 , 且部分实体的码只能在某一

6、个整体中作为码 , 而在全部整体中不能作为码的情况下才出现 ( 其它情况本人还没碰到 , 呵呵 , 欢迎指教 ) 。比如上篇文章介绍的管理信息系统中订单与订单细节的联系。关于什么就是聚集 ,2 、3 节介绍。2、3 数据抽象的分类这部分本应在概念设计中介绍的, 用到了才想起来 , 这里补充一下。关于现实世界的抽象 , 一般分为三类 :分类 : 即对象值与型之间的联系 , 可以用“ is member of ”判定。如张英、王平都就是学生 , 她们与“学生”之间构成分类关系。聚集 : 定义某一类型的组成成分 , 就是“ is part of ”的联系。如学生与学号、姓名等属性的联系。概括 : 定

7、义类型间的一种子集联系 , 就是“ is subset of ”的联系。如研究生与本科生都就是学生 , 而且都就是集合 , 因此它们之间就是概括的联系。例 : 猫与动物之间就是概括的联系 , tomand jerry 中那只名叫 tom的猫与猫之间就是分类的联系 ,tom 的毛色与 tom之间就是聚集的联系。订单细节与订单之间 , 订单细节肯定不就是一个订单 , 因此不就是概括或分类。订单细节就是订单的一部分 , 因此就是聚集。2、4 数据模型的优化有了关系模型 , 可以进一步优化 , 方法为 :确定数据依赖。对数据依赖进行极小化处理, 消除冗余联系 ( 参瞧范式理论 ) 。确定范式级别 ,

8、根据应用环境 , 对某些模式进行合并或分解。以上工作理论性比较强 , 主要目的就是设计一个数据冗余尽量少的关系模式。下面这步则就是考虑效率问题了:对关系模式进行必要的分解。如果一个关系模式的属性特别多, 就应该考虑就是否可以对这个关系进行垂直分解。如果有些属性就是经常访问的, 而有些属性就是很少访问的, 则应该把它们分解为两个关系模式。如果一个关系的数据量特别大 , 就应该考 虑就是否可以进行水平分解。如一个论坛中 , 如果设计时把会员发的主贴与跟贴设计为一个关系 , 则在帖子量非常大的情况下 , 这一步就应该考虑把它们分开了。因为 显示的主贴就是经常查询的 , 而跟贴则就是在打开某个主贴的情况下才查询。 又如手机号管理软件 , 可以考数据库逻辑结构设计虑按省份或其它方式进行水平分解。2、5 设计用户子模式这部分主要就是考虑使用方便性与效率问题, 主要借助视图手段实现 , 包括 :建立视图 , 使用更符合