关闭

关闭

关闭

封号提示

内容

首页 数据库逻辑结构设计.doc.doc

数据库逻辑结构设计.doc.doc

数据库逻辑结构设计.doc.doc

上传者: 何万闲 2017-10-15 评分 0 0 0 0 0 0 暂无简介 简介 举报

简介:本文档为《数据库逻辑结构设计.docdoc》,可适用于综合领域,主题内容包含数据库逻辑结构设计doc数据库逻辑结构设计该系列计划包括部分:完整性约束理论及应用、范式理论及应用、需求分析、概念结构设计、逻辑结构设计。本文是第五符等。

数据库逻辑结构设计doc数据库逻辑结构设计该系列计划包括部分:完整性约束理论及应用、范式理论及应用、需求分析、概念结构设计、逻辑结构设计。本文是第五部分介绍逻辑结构设计的内容包括ER图向关系模型的转换、数据模型的优化、用户子模式的设计等问题。(逻辑设计概述概念结构是独立于任何一种数据模型的在实际应用中一般所用的数据库环境已经给定(如SQLServer或Oracel或MySql)本文讨论从概念结构向逻辑结构的转换问题。由于目前使用的数据库基本上都是关系数据库因此首先需要将ER图转换为关系模型然后根据具体DBMS的特点和限制转换为特定的DBMS支持下的数据模型最后进行优化。(ER图向关系模型的转换一个例子ER图如何转换为关系模型呢,我们先看一个例子。图是学生和班级的ER图学生与班级构成多对一的联系。根据实际应用我们可以做出这个简单例子的关系模式:学生(学号姓名班级)班级(编号名称)“学生班级”为外键参照“班级编号”取值。这个例子我们是凭经验转换的那么里面有什么规律呢,在节我们将这些经验总结成一些规则以供转换使用。转换规则()一个实体型转换为一个关系模式一般ER图中的一个实体转换为一个关系模式实体的属性就是关系的属性实体的码就是关系的码。()一个:联系可以转换为一个独立的关系模式也可以与任意一端对应的关系模式合并。图是一个一对一联系的例子。根据规则()有三种转换方式。(i)联系单独作为一个关系模式此时联系本身的属性以及与该联系相连的实体的码均作为关系的属性可以选择与该联系相连的任一实体的码属性作为该关系的码。结果如下:职工(工号姓名)产品(产品号产品名)负责(工号产品号)其中“负责”这个关系的码可以是工号也可以是产品号。(ii)与职工端合并职工(工号姓名产品号)产品(产品号产品名)其中“职工产品号”为外码。(iii)与产品端合并职工(工号姓名)产品(产品号产品名负责人工号)其中“产品负责人工号”为外码。()一个:n联系可以转换为一个独立的关系模式也可以与n端对应的关系模式合并。(i)若单独作为一个关系模式此时该单独的关系模式的属性包括其自身的属性以及与该联系相连的实体的码。该关系的码为n端实体的主属性。顾客(顾客号姓名)订单(订单号„„)订货(顾客号订单号)(ii)与n端合并顾客(顾客号姓名)订单(订单号„„顾客号)()一个m:n联系可以转换为一个独立的关系模式。该关系的属性包括联系自身的属性以及与联系相连的实体的属性。各实体的码组成关系码或关系码的一部分。教师(教师号姓名)学生(学号姓名)教授(教师号学号)()一个多元联系可以转换为一个独立的关系模式。与该多元联系相连的各实体的码以及联系本身的属性均转换为关系的属性各实体的码组成关系的码或关系码的一部分。()具有相同码的关系模式可以合并。()有些:n的联系将属性合并到n端后该属性也作为主码的一部分这类问题多出现在聚集类的联系中且部分实体的码只能在某一个整体中作为码而在全部整体中不能作为码的情况下才出现(其它情况本人还没碰到呵呵欢迎指教)。比如上篇文章介绍的管理信息系统中订单与订单细节的联系。关于什么是聚集节介绍。数据抽象的分类这部分本应在概念设计中介绍的用到了才想起来这里补充一下。关于现实世界的抽象一般分为三类:()分类:即对象值与型之间的联系可以用“ismemberof”判定。如张英、王平都是学生他们与“学生”之间构成分类关系。()聚集:定义某一类型的组成成分是“ispartof”的联系。如学生与学号、姓名等属性的联系。()概括:定义类型间的一种子集联系是“issubsetof”的联系。如研究生和本科生都是学生而且都是集合因此它们之间是概括的联系。例:猫和动物之间是概括的联系《TomandJerry》中那只名叫Tom的猫与猫之间是分类的联系Tom的毛色和Tom之间是聚集的联系。订单细节和订单之间订单细节肯定不是一个订单因此不是概括或分类。订单细节是订单的一部分因此是聚集。数据模型的优化有了关系模型可以进一步优化方法为:()确定数据依赖。()对数据依赖进行极小化处理消除冗余联系(参看范式理论)。()确定范式级别根据应用环境对某些模式进行合并或分解。以上工作理论性比较强主要目的是设计一个数据冗余尽量少的关系模式。下面这步则是考虑效率问题了:()对关系模式进行必要的分解。如果一个关系模式的属性特别多就应该考虑是否可以对这个关系进行垂直分解。如果有些属性是经常访问的而有些属性是很少访问的则应该把它们分解为两个关系模式。如果一个关系的数据量特别大就应该考虑是否可以进行水平分解。如一个论坛中如果设计时把会员发的主贴和跟贴设计为一个关系则在帖子量非常大的情况下这一步就应该考虑把它们分开了。因为显示的主贴是经常查询的而跟贴则是在打开某个主贴的情况下才查询。又如手机号管理软件可以考虑按省份或其它方式进行水平分解。设计用户子模式这部分主要是考虑使用方便性和效率问题主要借助视图手段实现包括:()建立视图使用更符合用户习惯的别名。()对不同级别的用户定义不同的视图以保证系统的安全性。()对复杂的查询操作可以定义视图简化用户对系统的使用。物理设计主要工作是选择存取方法(索引)以及确定数据库的存储结构这里就不说明了。好了可以在你的DBMS上建表了。

用户评论(0)

0/200

精彩专题

上传我的资料

每篇奖励 +2积分

资料评价:

/6
0下载券 下载 加入VIP, 送下载券

意见
反馈

立即扫码关注

爱问共享资料微信公众号

返回
顶部