数据库物理设计.pptVIP

第六章 数据库设计 第六章 数据库设计 6.1 数据库设计概述 6.2 需求分析 6.3 概念结构设计 6.4 逻辑结构设计 6.5 数据库的物理设计 6.6 数据库实施 6.7 数据库运行与维护 6.8 小结 6.1数据库设计的步骤（1） 目前主要采用以逻辑数据库设计和物理数据库设计为核心的规范设计方法。 逻辑数据库设计-设计全局逻辑结构和每个用户的局部逻辑结构，将概念结构转换为某个DBMS支持的数据模型并优化 物理数据库设计-为逻辑数据模型选一个最适合应用环境的物理结构，设计数据库的存储结构、存取方法及其他实现细节 6.1数据库设计的步骤（2） 选定参加设计的人员： 数据库分析设计人员-核心，自始至终 用户-重要，需求分析(头)，运行和维护(尾) 程序员-编制程序 操作员-准备软硬件环境 数据库设计过程图 6.2需求分析6.2.1任务 重点是调查、收集与分析用户在数据管理中的信息要求、处理要求、安全性和完整性要求 信息要求-用户需从库中获得信息的内容和性质，存储哪些信息于库中 处理要求-要求完成的功能、响应时间、方式是批处理还是联机处理 6.2需求分析6.2.1任务 困难在： 用户缺少计算机知识，无法准确表达自己的需求，需求往往不断变化 设计人员缺乏用户的专业知识，不易理解甚至误解用户的需求。 软硬件技术的出现会使用户需求发生变化 6.2需求分析6.2.2需求分析的方法（1） 调查与初步分析用户需求需四步： 调查组织机构情况：部门组成、职责，为分析信息流程做准备 调查各部门业务活动情况：输入和使用什么数据，如何加工处理这些数据，输出什么信息、到哪里、输出结果的格式 协助用户明确对新系统的要求 确定新系统边界，哪些是计算机完成的功能 6.2需求分析6.2.2需求分析的方法（2） 常用的调查方法： 跟班作业 开调查会-用户彼此启发 请专人介绍 询问-专人 设计调查表请用户填写 查阅记录-与原系统有关的数据记录 6.2需求分析 分析和表达用户需求的方法主要包括：自顶向下（SA）和自底向上方法 自顶向下（SA）方法从最上层的系统组织机构入手，采用逐层分解的方式分析系统，并用数据流图和数据字典描述系统 用SA方法做需求分析，设计人员需要把任何一个系统都抽象为如下形式 数据存储 数据流 数据流 数据来源 处理 数据输出 然后将处理功能分解，不停分解，直至系统工作过程被表达清楚；数据也逐级分解，形成若干层次的数据流图。 数据流图表达了数据和处理过程的关系 数据借助数据字典描述 处理过程的处理逻辑借助判定表或判定树来描述 实例：开发学校管理系统 高层数据流图 实例（续） 学生管理子系统的主要功能：学籍管理和课程管理。包括：学生报到、入学、毕业、上课情况管理。通过详细的信息流程分析和数据收集后，生成该系统的数据流图。见188-189 6.3概念结构设计 6.3.1概念结构设计方法与步骤 概念结构设计--将需求分析得到的用户需求抽象为概念模型的过程 概念结构独立于数据库逻辑结构，也独立于DBMS 四类方法： 自顶向下 自底向上—经常采用。即自顶向下进行需求分析，再自底向上设计概念结构。 逐步扩张-先定义核心概念，然后向外扩充 混合策略 6.3.2分E-R图设计（1） 在多层数据流图中选择一个适当层次的数据流图，让每一部分对应一个局部应用，因为中层的数据流图能较好地反映系统中各局部应用的子系统组成，所以一般作为分E-R图的依据 参照数据流图，标定局部应用中的实体、实体的属性、标识实体的码，确定实体之间的联系及其类型。 6.3.2设计分E-R图（2） 现实世界中一组具有共同特性和行为的对象可抽象为一个实体，例，张三、李斯、王五可抽象为学生实体 对象的组成成分可抽象为实体的属性，例，学号、姓名、年级等可抽象为学生实体的属性，其中学号为标识实体的码 实体与属性很难划分界限。例，系是学生实体的属性，在需要考虑系主任、教师人数、学生人数、办公地点时就需要作为实体了。 6.3.2设计分E-R图（3） 属性和实体区别的原则： 属性不能再具有需要描述的性质。即为不可再分的数据项 属性不能与其他实体具有联系。联系只能发生在实体之间。 能做属性对待尽量作属性。 “职称”分别作为实体和属性 学籍管理分E-R图草图 对学籍管理E-R草图调整 一般，性别应作为学生实体的属性，本应用中由于宿舍分配与性别有关，依据准则2-属性不能与其他实体有联系，性别应作为实体对待 数据存储“学生登记表”由手工完成，有用部分转入学生档案材料中，因此这里不必作为实体