An Introduction to Database System

Presentation on theme: "An Introduction to Database System"— Presentation transcript:

1 An Introduction to Database System
数据库系统概论 An Introduction to Database System 第七章 数据库设计 计算机学院

2 7.1 数据库设计概述 数据库设计 (Database Design)
7.1 数据库设计概述 数据库设计 (Database Design) 概念：是指对于一个给定的应用环境,设计最优的数据库模式 ,并据此建立数据库及其应用系统，使之能够有效地存储和管理数据,满足各种用户的应用需求,包括信息管理要求和数据操作要求。 目标：是在DBMS的支持下,按照应用的要求,为某一部门或组织设计一个结构合理、使用方便、效率较高的数据库及其应用系统

3 7.2 数据库设计的基本步骤 数据库设计分6个阶段 需求分析 概念结构设计 逻辑结构设计 物理结构设计 数据库实施 数据库运行和维护

4 7.2 数据库设计的基本步骤 其中, 需求分析和概念设计独立于任何数据库管理系统 逻辑设计和物理设计与选用的DBMS密切相关

5 7.2 数据库设计的基本步骤之一 　⒈需求分析阶段 调查和分析用户的业务活动和数据的使用情况，弄清所用数据的种类、范围、数量以及它们在业务活动中交流的情况，确定用户对数据库系统的使用要求和各种约束条件等，形成用户需求规约。 最困难、最耗费时间的一步

6 1. 需求分析的任务 详细调查现实世界要处理的对象（组织、部门、企业等） 充分了解原系统（手工系统或计算机系统） 明确用户的各种需求
确定新系统的功能 充分考虑今后可能的扩充和改变

7 分析和表达用户需求 -------数据流图
1．首先把任何一个系统都抽象为DFD:是一种能全面地描述信息系统逻辑模型的主要工具，它可以用少数几种符号综合地反映出信息在系统中的流动、处理和存储情况。 DFD由数据流、加工、数据存储和外部实体4个要素构成。外部实体是指存在于软件系统之外的人员或组织，它指出系统所需数据的发源地和系统所产生数据的归宿地。 数据流 数据 存储 信息要求 来源 处理 输出 处理要求

8 进一步分析和表达用户需求（续） 2．分解处理功能和数据 3．将分析结果再次提交给用户，征得用户的认可 (1)分解处理功能 (2)分解数据
将处理功能的具体内容分解为若干子功能 (2)分解数据 处理功能逐步分解同时，逐级分解所用数据，形成若干层次的数据流图DFD (3)表达方法 处理逻辑：用判定表或判定树来描述 数据：用数据字典来描述 3．将分析结果再次提交给用户，征得用户的认可

9 需求分析过程 需求分析过程

10 什么是数据字典 数据字典:数据库中所有对象及其关系的信息集合。 数据字典的用途:进行详细的数据收集和数据分析所获得的主要结果 数据字典的内容
数据项 数据结构 数据流 数据存储 处理过程

11 数据字典举例 例：学生学籍管理子系统的数据字典。 (1)数据项，以“学号”为例： 编号： 1 数据项名称 学号 数据项别名 Sno 说 明
唯一标识每个学生 类 型 字符型 长 度 10 取值范围及含义 至 ,前4位是入学年份，5-6位院系编号，7-8位专业编号，9-10位自然序号

12 数据字典举例 (2)数据结构，以“学生”为例 “学生”是该系统中的一个核心数据结构： 数据结构 学生
数据结构 学生 含义说明 是学籍管理子系统的主体数据结构, 定义了 一个学生的有关信息 组成 学号，姓名，性别，年龄，所在系，年级

13 数据字典举例 (3)数据流，“学生成绩数据”可如下描述： 编号： 12 数据流名称 学生成绩数据 数据流别名 无 说 明 学生所选课程的成绩
数据流来源 院系（教师） 数据流流向 教务处 数据流组成 学生基本信息数据=学号+姓名+性别+年龄+所在系+年级 数据流量 1次/半年

14 数据字典举例 (4)处理过程“分配宿舍”可如下描述： 处理过程 分配宿舍 说明 为所有新生分配学生宿舍 输入 学生，宿舍 输出 宿舍安排
　处理过程 分配宿舍 　说明 　　 为所有新生分配学生宿舍 　输入 　　 学生，宿舍 　输出 　　 宿舍安排 　处理 　　 在新生报到后，为所有新生分配学生宿舍。 要求同一间宿舍只能安排同一性别的学生， 同一个学生只能安排在一个宿舍中。 每个学生的居住面积不小于3平方米。 安排新生宿舍其处理时间应不超过15分钟。

15 数据字典小结 数据字典是关于数据库中数据的描述，是元数据，而不是数据本身 数据字典在需求分析阶段建立，在数据库设计过程中不断修改、充实、完善
元数据:描述数据及其环境的数据

16 需求分析小结 设计人员应充分考虑到可能的扩充和改变，使设计易于更改，系统易于扩充 必须强调用户的参与

17 7.2 数据库设计的基本步骤之二 ⒉ 概念结构设计阶段 整个数据库设计的关键
　⒉ 概念结构设计阶段 整个数据库设计的关键 通过对用户需求进行综合、归纳与抽象，形成一个独立于具体DBMS的概念模型 概念结构是对现实世界的一种抽象

18 ⒉ 概念结构设计阶段 现实世界 机器世界 信息世界 需求分析 概念结构设计 工具：DFD，DD 工具：E-R

19 概念结构设计的特点 概念结构设计的特点 (1) 能真实、充分地反映现实世界 (2) 易于理解 (3) 易于更改
(4) 易于向关系、网状、层次等各种数据模型转换

20 概念结构设计的方法与步骤 常用策略 自顶向下地进行需求分析 自底向上地设计概念结构

21 设计 E-R 模型 在多层的数据流图中选择一个适当层次的数据流图，作为设计分E-R图的出发点 通常以中层数据流图作为设计分E-R图的依据

22 设计 E-R模型 设计分E-R图的出发点

23 逐一设计分E-R图（续） ［实例］销售管理子系统分E-R图的设计 销售管理子系统的主要功能： 处理顾客和销售员送来的订单
工厂是根据订货安排生产的 交出货物同时开出发票 收到顾客付款后，根据发票存根和信贷情况进行应收款处理 接受订单 生产 提交货物 开发票 收款处理 收款处理

24 逐一设计分E-R图（续） 下图是第一层数据流图，虚线部分划出了系统边界 图7.18 销售管理子系统第一层数据流图

25 逐一设计分E-R图（续） 上图中把系统功能又分为4个子系统，下面四个图是第二层数据流图 图7.19 接收订单

26 逐一设计分E-R图（续） 图7.20 处理订单

27 逐一设计分E-R图（续） 图7.21 开发票

28 逐一设计分E-R图（续） 图7.22 支付过账

29 逐一设计分E-R图（续） 参照第二层数据流图和数据字典，遵循两个准则，进行如下调整： (1) 订单与订单细节是1∶n的联系
(2) 原订单和产品的联系实际上是订单细节和产品的联系。 (3) 图7.21中“发票主清单”是一个数据存储，不必作为实体加入分E-R图 (4) 工厂对大宗订货给予优惠

30 逐一设计分E-R图（续） 得到分E-R图如下图所示 销售管理子系统的分E-R图

31 逐一设计分E-R图（续） 对每个实体定义的属性如下： 顾客：{顾客号，顾客名，地址，电话，信贷状况，账目余额}
订单：{订单号，顾客号，订货项数，订货日期，交货日期，工种号，生产地点} 订单细则：{订单号，细则号，零件号，订货数，金额} 应收账款：{顾客号，订单号，发票号，应收金额，支付日期，支付金额， 当前余额，货款限额} 产品描述：{产品号，产品名，单价，重量} 折扣规则：{产品号，订货量，折扣}

32 7.2 数据库设计的基本步骤（续） ⒊逻辑结构设计阶段 逻辑结构：是一种由具体的DBMS支持的数据模型。
主要任务：按照一定的规则，将概念结构(独立于任何DBMS的数据结构)转换为某个DBMS所支持的一组关系模式，并利用关系数据库的规范理论对这组关系模式进行规范化设计和处理。

33 逻辑结构设计的步骤 对于E-R图表示的概念结构来说，逻辑结构的设计一般分为三个步骤： (1)将由E-R图表示的概念结构转换成关系模型
(2)利用规范化理论对关系模型进行规范化设计 (3)对关系模型进行优化

34 步骤1: E-R图向关系模型的转换 E-R图向关系模型转换的一般规则 ：
(1)一个1:1联系可以转换为一个独立关系模式,也可以与任意一端对应的关系模式合并. 如“院系”和“系主任”. (2)一个1:n联系可以转换为一个独立的关系模式,也可以与n端对应的关系模式合并. 如”院系”和”学生” (3) 一个m:n联系转换为一个关系模式。 例，“选修”联系是一个m:n联系，可以将它转换为如下关系模式，其中学号与课程号为关系的组合码： 　　选修（学号，课程号，成绩）

35 步骤1: E-R图向关系模型的转换(续) (4)三个或三个以上实体间的一个多元联系转换为一个关系模式。
例，“讲授”联系是一个三元联系，可以将它转换为如下关系模式，其中课程号、职工号和书号为关系的组合码： 　　讲授（课程号，职工号，书号）

36 步骤1: E-R图向关系模型的转换(续) (5)具有相同码的关系模式可合并 目的：减少系统中的关系个数
合并方法：将其中一个关系模式的全部属性加入到另一个关系模式中，然后去掉其中的同义属性（可能同名也可能不同名），并适当调整属性的次序

37 步骤1: E-R图向关系模型的转换(续) 注意： 从理论上讲,1:1联系可以与任意一端对应的关系模式合并.
但在一些情况下，与不同的关系模式合并效率会大不一样。因此究竟应该与哪端的关系模式合并需要依应用的具体情况而定。 由于连接操作是最费时的操作，所以一般应以尽量减少连接操作为目标。 例如，如果经常要查询某个班级的班主任姓名，则将管理联系与教师关系合并更好些。

38 步骤1: E-R图向关系模型的转换(续) [例] 把图7.30(P223)中虚线上部的E-R图转换为关系模型 部门实体对应的关系模式
部门（部门号，部门名，经理的职工号，…） 此关系模式已包含了联系“领导”所对应的关系模式 经理的职工号是关系的候选码 职工实体对应的关系模式 职工（职工号、部门号，职工名，职务，…） 该关系模式已包含了联系“属于”所对应的关系模式

39 步骤1: E-R图向关系模型的转换(续) [例] 把图7.30中虚线上部的E-R图转换为关系模型（续） 产品实体对应的关系模式
产品（产品号，产品名，产品组长的职工号，…） 供应商实体对应的关系模式 供应商（供应商号，姓名，…） 零件实体对应的关系模式 零件（零件号，零件名，…）

40 步骤1: E-R图向关系模型的转换(续) [例] 把图7.30中虚线上部的E-R图转换为关系模型（续） 联系“参加”所对应的关系模式
职工工作（职工号，产品号，工作天数，…） 联系“供应”所对应的关系模式 供应（产品号，供应商号，零件号，供应量）

41 步骤2: 关系数据模型的规范化设计 关系模型的规范化设计就是按照函数依赖理论和范式理论,对逻辑结构设计的第一步所设计的关系模型进行规范化设计
规范化设计的方法:

42 步骤2: 关系数据模型的规范化设计(续) 规范化设计的方法 1. 确定数据依赖
按需求分析阶段所得到的语义，分别写出每个关系模式内部各属性之间的数据依赖以及不同关系模式属性之间数据依赖 2. 消除冗余的联系 对于各个关系模式之间的数据依赖进行极小化处理，消除冗余的联系。

43 步骤2: 关系数据模型的规范化设计(续) 规范化设计的方法 3. 确定所属范式 按照数据依赖的理论对关系模式逐一进行分析
考查是否存在部分函数依赖、传递函数依赖、多值依赖等 确定各关系模式分别属于第几范式

44 步骤3: 关系数据模型的优化 注意：并不是规范化程度越高的关系就越优 一般说来，第三范式就足够了 关系数据模型的优化
前面两步基本上是一些形式化的方法，没有太多考虑用户的需求。 关系模型的优化，按照需求分析阶段得到的各种应用对数据处理的要求,分析对于这样的应用环境这些模式是否合适,确定是否要对它们进行合并或分解。 注意：并不是规范化程度越高的关系就越优 一般说来，第三范式就足够了

45 步骤3: 关系数据模型的优化 例：在关系模式 学生成绩单(学号,英语,数学,语文,平均成绩) 中存在下列函数依赖： 问题1:属于几范式?
问题2:该模式的优劣？ 存在传递函数信赖，是2NF关系 　学号→英语 　学号→数学 　学号→语文 　学号→平均成绩 (英语, 数学, 语文)→平均成绩 虽然平均成绩可以由其他属性推算出来,但如果应用中需要经常查询学生的平均成绩,为提高效率,仍然可保留该冗余数据,对关系模式不再做进一步分解.

46 7.2 数据库设计的基本步骤（续） ⒋数据库物理设计阶段 为逻辑数据模型选取一个最适合应用环境的物理结构（包括存储结构和存取方法）
它取决于DBMS

47 7.2 数据库设计的基本步骤（续） 运用DBMS提供的数据库语言(如SQL)及宿主语言，根据逻辑设计和物理设计的结果 ⒌数据库实施阶段
建立数据库 编制与调试应用程序 组织数据入库 进行试运行

48 7.2 数据库设计的基本步骤（续） ⒍数据库运行和维护阶段 数据库应用系统经过试运行后即可投入正式运行
在数据库系统运行过程中必须不断地对其进行评价、调整与修改

49 小结

50 数据库设计各个阶段的设计描述

51 下课了。。。 攀 登 休息一会儿。。。