- 1、本文档共30页,可阅读全部内容。
- 2、原创力文档(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。
- 3、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载。
- 4、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
- 5、该文档为VIP文档,如果想要下载,成为VIP会员后,下载免费。
- 6、成为VIP后,下载本文档将扣除1次下载权益。下载后,不支持退款、换文档。如有疑问请联系我们。
- 7、成为VIP后,您将拥有八大权益,权益包括:VIP文档下载权益、阅读免打扰、文档格式转换、高级专利检索、专属身份标志、高级客服、多端互通、版权登记。
- 8、VIP文档为合作方或网友上传,每下载1次, 网站将根据用户上传文档的质量评分、类型等,对文档贡献者给予高额补贴、流量扶持。如果你也想贡献VIP文档。上传文档
查看更多
[常用实验设计方法2013pdf
逻辑结构设计 逻辑结构向关系模型的转换 应用规范化理论优化逻辑模型 设计用户子模式 逻辑结构向关系模型的转换 一个实体类型转换为一个关系模式 实体的属性就是关系的属性,实体的关键字就是关系的关键字 联系 一对一的联系(1:1) 转换方法 转换为一个独立的关系模式 联系名为关系模式名,与该联系相连的两个实体的关键字及联系本身的属性为关系模式的属性。 其中,每个实体的关键字均为该关系模式的候选键。 与任意一端的关系模式合并。 可将相关的两个实体转换为两个关系,并在任意一个关系的属性中加入另一个关系的主关键字 采用哪种转换方法视情况而定。 一对多的联系(1:M) 转换方式 将一对多的联系(1:M)转换为一个独立的关系模式。 联系名为关系模式名,与该联系相连的两个实体的关键字及联系本身的属性为关系模式的属性。 关系模式的关键字为M端实体的关键字 将一对多的联系(1:M)与M端关系合并 1端的关键字及联系的属性并入M端的关系模式即可 实例:“学生”与“专业”之间的联系为: 1:M 多对多的联系(M:N) 转换方法: 将多对多的联系(M:N)转换为一个关系模式 关系模式名为联系名,与该联系相连的两个实体的关键字及联系本身的属性为关系模式的属性 关系模式的关键字为联系中各实体关键字的并集 实例:学校中,“学生”实体和“课程”实体之间的联系为多对多的。见下图: 同一实体内部的联系 可将该实体集分为相互联系的两个子集,然后根据它们相互不同的联系(1:1、1:M、M:N)按照上述规则处理。 实例:职工实体集内部有领导和被领导的关系1:M 三个或三个以上实体间的多元联系 转换为一个关系模式 与该联系相连的各实体的关键字及联系本身的属性为关系模式的属性 关系模式的关键字为联系中各实体关键字的并集 应用规范化理论优化逻辑模型 确定出每个关系模式内部属性之间的数据依赖和不同关系属性之间的数据依赖 对各个关系模式之间的数据依赖进行极小化,消除冗余的联系 按照数据依赖和规范化理论对关系模式逐一进行分析,考察是否存在部分函数依赖,传递函数依赖,多值依赖等,从而确定各关系模式分别属于第几范式。 根据需求分析阶段所得的实际应用需求,确定是否对某个关系模式进行分解或者合并。 对关系模式进行进一步的分解和合并,减低数据的冗余度和提高数据操作的效率。 设计用户子模式 子模式的作用 屏蔽逻辑模式,为应用程序提供了一定的逻辑独立性 可以更好地适应不同用户对数据的需求 为用户划定了访问数据的范围,由利于数据库的管理 子模式的设计内容 子表的名字 子表的组成 子表的每个列分别来自哪张基本表 DBMS的视图功能很容易实现子模式 物理设计 任务:根据具体计算机系统(DBMS和硬件等)的特点,为给定的数据库模型确定合理的存储结构和存取方法: 使设计出的物理数据库占用较少的存储空间 对数据库的操作具有尽可能高的速度 设计数据库的物理结构,设计人员必须充分了解: 所用DBMS的内部特征 数据系统的实际应用环境,特别是数据应用处理的频率和响应时间的要求 外存设备的特征 内容 确定数据的存取方法 确定数据的存储结构 影响物理设计的因素 设计之前,对数据库系统所支持的事务要进行仔细的分析,获得优化数据库物理设计的参数。 对于数据库查询事务,需要得到如下信息 要查询的关系 查询条件(即选择条件)所涉及的属性 连接条件所涉及的属性 查询的投影属性 对于数据更新事务,需要得到如下信息: 要更新的关系 每个关系上的更新操作的类型 删除和修改操作所涉及到的属性 修改操作要更改的属性值 知道每个事务在各关系上运行的频率,某些事务可能具有严格的性能要求(如时间要求) 注意:在进行数据库物理设计时,通常并不知道所有的事务 确定关系模式的存取方法 确定建立哪些存储路径以实现快速存取数据库中的数据。 DBMS提供的存取方法 索引方法 HASH法,等 索引:表中数据和相应存储位置的列表 优点 大大的减少数据的查询时间 缺点 占用存储空间。 每个索引都将需要占用一定的存储空间 降低数据的更新数度 当对表中的数据进行增加、删除和修改的时候,索引也要动态的维护 在创建索引的时候,一般遵循以下的一些经验性原则: 在经常需要搜索的列上建立索引 在主关键字上建立索引 在经常用于连接的列上建立索引 在经常需要根据范围进行搜索的列上建立索引 在经常需要排序的列上建立索引 在经常成为查询条件的列上建立索引 对于某些列不应该创建索引。应该考虑以下指导性原则: 对于那些在查询中很少使用和参考的列不应该创建索引 对于那些只有很少值的列 属性值分布严重不均的列 过长的属性 经常更新的属性或表 实例: 学生学籍管理系统中,三个表如下: 学生(学号、姓名、出生年月、些别、系名、班号) 课程(课程名、课程号、教师、学分) 成绩(学号、课程号、成
文档评论(0)