数据库系统概论 - 第七章 - 数据库设计


第七章 数据库设计

7.1 数据库设计概述

1. 数据库设计定义

  • 数据库设计是指对于一个给定的应用环境,构造(设计)优化的数据库逻辑模式和物理结构,并据此建立数据库及其应用系统,使之能够有效地存储和管理数据.满足各种用户的应用需求,包括信息管理要求和数据操作要求。

2. 信息管理要求

  • 在数据库中应该存储和管理哪些数据对象。

3. 数据操作要求

  • 对数据对象需要进行哪些操作,如查询、增、删、改、统计等操作。

4. 数据库设计的目标

  • 为用户和各种应用系统提供一个信息基础设施和高效率的运行环境。

5. 高效率的运行环境

  • ① 数据库数据的存取效率高;
  • ② 数据库存储空间的利用率高;
  • ③ 数据库系统运行管理的效率高。

7.1.1 数据库设计的特点

1. 数据库建设的基本规律

  • 三分技术,七分管理,十二分基础数据。
  • 管理:数据库建设项目管理和企业(应用部门) 的业务管理。
  • 基础数据:数据的收集、整理、组织和不断更新。

2. 结构(数据)设计和行为(处理)设计相结合

  • 将数据库结构设计和数据处理设计密切结合。
  • 传统的软件工程:重行为设计。
  • 早期的数据库设计:重结构设计。

7.1.2 数据库设计方法

1. 规范设计法

  • (1)基本思想:过程迭代和逐步求精
  • (2)典型方法:
  • ① 新奥尔良(New Orleans)方法
  • ② 基于E-R模型的数据库设计方法
  • ③ 3NF(第三范式)的设计方法
  • ④ 面向对象的数据库设计方法
  • ⑤ 统一建模语言(UML)方法

7.1.3数据库设计的基本步骤

数据库设计分6个阶段

  • 需求分析、概念结构设计、逻辑结构设计、物理结构设计、数据库实施、数据库运行和维护。
  • 【说明】
  • ① 需求分析和概念设计独立于任何数据库管理系统。
  • ② 逻辑设计和物理设计与选用的数据库管理系统密切相关。

各阶段的主要任务

  • ① 需求分析阶段:了解用户需求,该阶段是否做得充分与准确,决定了构建数据库的速度和质量。
  • ② 概念结构设计阶段:对用户需求进行综合、归纳与抽象,形成一个独立于具体数据库管理系统的概念模型。(E-R图)
  • ③ 逻辑结构设计阶段:将概念结构转换为数据库管理系统所支持的数据模型,并对其进行优化。
  • ④ 物理结构设计阶段:逻辑数据结构选取一个最适合应用环境的物理结构,包括存储结构和存取方法。
  • ⑤ 数据库实施阶段:根据逻辑设计和物理设计的结果构建数据库,编写与调试应用程序,组织数据入库并进行试运行。
  • ⑥ 数据库运行和维护阶段:经过试运行后即可投入正式运行,在运行过程中必须不断对其进行评估、调整与修改。
  • 【说明】
  • ① 设计一个完善的数据库应用系统往往是上述6个阶段的不断反复。
  • ② 设计步骤既是数据库设计的过程,也包括了数据库应用系统的设计过程。
  • ③ 把数据库的设计和数据处理的设计紧密结合,将这两个方面的需求分析、抽象、设计、实现在各个阶段同时进行。

各个阶段的数据设计描述

7.1.4 数据库设计过程中的各级模式

7.2 需求分析

7.2.1 需求分析的任务

  • 详细调查现实世界要处理的对象(组织、部门、企业等)。
  • 充分了解原系统工作概况。
  • 明确用户的各种需求。
  • 确定新系统的功能,新系统必须充分考虑今后可能的扩充和改变。
  • 【说明】
  • 调查的重点是 “数据” 和 “处理” ,获得用户对数据库在信息、处理、安全性与完整性的要求。

7.2.2 需求分析的方法

  • 需求分析的目的:调查清楚用户的实际需求并进行初步分析,最终与用户达成共识。

调查用户需求的步骤:

  • (1)调查组织机构情况。
  • (2)调查各部门的业务活动情况。
  • (3)协助用户明确对新系统的各种要求,包括信息要求、处理要求、安全性与完整性要求。
  • (4)确定新系统的边界。

调查方法

  • (1)跟班作业
  • (2)开调查会
  • (3)请专人介绍
  • (4)询问
  • (5)设计调查表请用户填写
  • (6)查阅记录

分析

  • 结构化分析方法(简称SA方法),SA方法从最上层的系统组织机构入手,采用自顶向下、逐层分解的方式分析系统。

7.2.3 数据字典

  • 数据字典是关于数据库中数据的描述,即元数据,不是数据本身。数据字典是在需求分析阶段建立,是进行详细的数据收集和数据分析所获得的,并在数据库设计过程中不断修改、充实、完善。
  • 数据字典的内容:数据项、数据结构、数据流、数据存储、处理过程。

1. 数据项:数据项是不可再分的数据单位。

  • 数据项描述 = { 数据项名,数据项含义说明,别名,数据类型,长度,取值范围,取值含义,与其他数据项的逻辑关系,数据项之间的联系 }
    【说明】
  • ① “取值范围”、“与其他数据项的逻辑关系” 定义了数据的完整性约束条件,是设计数据检验功能的依据。
  • ② 可以用关系规范化理论为指导,用数据依赖的概念分析和表示数据项之间的联系。

2. 数据结构:数据结构反映了数据之间的组合关系。

  • 数据结构描述 = { 数据结构名,含义说明,组成:{ 数据项或数据结构 } }
  • 【说明】
  • 一个数据结构可以由若干个数据项组成,也可以由若干个数据结构组成,或由若干个数据项和数据结构混合组成。

3. 数据流:是数据结构在系统内传输的路径。

  • 数据流描述 = { 数据流名,说明,数据流来源,数据流去向,组成:{ 数据结构 },平均流量,高峰期流量 }
  • 【说明】
  • ① 数据流来源:说明该数据流来自哪个过程。
  • ② 数据流去向:说明该数据流将到哪个过程去。
  • ③ 平均流量:在单位时间(每天、每周、每月等)里的传输次数。
  • ④ 高峰期流量:在高峰时期的数据流量。

4. 数据存储:数据结构停留或保存的地方,也是数据流的来源和去向之一。

  • 数据存储描述 = { 数据存储名,说明,编号,输入的数据流,输出的数据流,组成:{ 数据结构 },数据量,存取频度,存取方式 }
  • 【说明】
  • ① 存取频度:每小时、每天或每周存取次数,每次存取的数热量等信息。
  • ② 存取方法:批处理/联机处理;检索/更新;顺序检索/随机检索。
  • ③ 输入的数据流:数据来源。
  • ④ 输出的数据流:数据去向。

5. 处理过程:处理过程的具体处理逻辑一般用判定表或判定树来描述。数据字典中只需要描述处理过程的说明性信息。

  • 处理过程描述 = { 处理过程名,说明,输入:{ 数据流 },输出:{ 数据流 },处理:{ 简要说明 } }
  • 【说明】
  • “简要说明” 说明该处理过程的功能及处理要求。其中功能是指该处理过程用来做什么。处理要求是指处理频度要求,如单位时间里处理多少事务,多少数据量、响应时间要求等。

需求分析小结

  1. 需求收集和分析作为数据库设计的第一阶段是十分重要的。
  2. 第一阶段收集的基础数据(用数据字典来表达)是下一艺进行概念设计的基础。
  3. 强调两点
  • (1)设计人员应充分考虑到可能的扩充和改变,使设计易于更改,系统易于扩充。
  • (2)必须强调用户的参与。

7.3 概念结构设计

7.3.1 概念模型

  • 概念结构设计是将需求分析得到的用户需求抽象为信息结构(即概念模型)的过程。
  • 概念模型的特点
  • (1)能真实、充分地反映现实世界,是现实世界的一个真实模型。
  • (2)易于理解,可以用它和不熟悉计算机的用户交换意见。
  • (3)易于更改,当应用环境和应用要求改变时,容易对概念模型修改和扩充。
  • (4)易于向关系、网状、层次等各种数据模型转换。
  • 概念模型的描述工具:E-R模型

7.3.2 E-R模型

  • E-R模型 是用 E-R图 来描述现实世界的概念模型。
  • 第1章1.2.2节已经简单介绍实体、属性、实体之间的联系等。

1. 实体之间的联系

  • (1)两个实体型之间的联系
  • 一对一联系(1∶1)、一对多联系(1:n)、多对多联系(m :n)。
  • (2)两个以上的实体型之间的联系
  • 一般地,两个以上的实体型之间也存在着一对一、一对多、多对多联系。
  • 【例】对于课程、教师与参考书3个实体型,如果一门课程可以有若干个教师讲授,使用若干本参考书,而每一个教师只讲授一门课程,每一本参考书只供一门课程使用,则课程与教师、参考书之间的联系是一对多的。

  • (3)单个实体型内的联系
  • 同一个实体集内的各实体之间也可以存在一对一、一对多、多对多的联系。
  • 【例】职工实体型内部具有领导与被领导的联系,即某一职工(干部)“领导”若干名职工,而一个职工仅被另外一个职工直接领导,因此这是一对多的联系,如下图。

联系的度:参与联系的实体型的数目
  • 2个实体型之间的联系度为2,也称为二元联系;
  • 3个实体型之间的联系度为3,称为三元联系;
  • N个实体型之间的联系度为N,也称为N元联系。

2. E-R图

  • E-R图提供了表示实体型、属性和联系的方法。
  • 实体型:用矩形表示,矩形框内写明实体名。
  • 属性:用椭圆形表示,并用无向边将其与相应的实体型连接起来。
  • 联系:用菱形表示,菱形框内写明联系名,并用无向边分别与有关实体型连接起来,同时在无向边旁标上联系的类型(1:1、1∶n或m : n)。联系也可以具有属性

  • 工厂实例可看书本P217~219,此处略。

7.3.3 扩展的E-R模型(*)(了解即可)(书本P218~222)

  • E-R模型得到了广泛的应用,人们在基本E-R模型的其础上进行了某些方面的扩展,使其表达能力更强。

1. ISA 联系

2. 基数约束

3. Part-of 联系

7.3.4 UML(*)(了解即可)

  • UML是统一建模语言或标准建模语言,也可以作为表示E-R图的一种方法。
  • UML表示E-R图的说明:
  • ① 实体型:用类表示,矩形框上部写实体名,下面列出属性名。
  • ② 实体的码:在类图中属性后面加“PK”。
  • ③ 联系:用类图之间的“关联”来表示。

7.3.5 概念结构设计

  • 概念设计的第一步就是对需求分析阶段收集到的数据进行分类、组织,确定实体、实体属性、实体间联系类型,形成E-R图。

1. 实体与属性的划分原则

  • 为了简化E-R图的处置,现实世界的事物能作为属性对待的,尽量作为属性对待。
两条准则:
  • (1)作为属性,不能再具有需要描述的性质。属性必须是不可分的数据项,不能包含其他属性。
  • (2)属性不能与其他实体具有联系,即E-R图中所表示的联系是实体之间的联系。

2. E-R图的集成

  • E-R图的集成一般需要分两步:
  • 第一步:合并。解决各分E-R图之间的冲突,将分E-R图合并起来生成初步E-R图。
  • 第二步:修改和重构。消除不必要的冗余,生成基本E-R图
(1)合并E-R图,生成初步E-R图
  • 各个局部应用所面向的问题不同,各个子系统的E-R图之间必定会存在许多不一致的地方,称之为冲突。
  • 子系统E-R图之间的冲突主要有三类:
  • ① 属性冲突
  • 属性域冲突,即属性值的类型、取值范围或取值集合不同。(整数?字符型)
  • 属性取值单位冲突。(公斤?斤?克)
  • ② 命名冲突
  • 同名异义
  • 异名同义(一义多名)
  • 命名冲突
  • ③ 结构冲突
  • 同一对象在不同应用中具有不同的抽象。
  • 解决方法:把属性变换为实体或把实体变换为属性,使同一对象具有相同的抽象。
  • 同一实体在不同子系统的E-R图中所包含的属性个数和属性排列次序不完全相同。
  • 解决方法:该实体的属性取各子系统的E-R图中属性的并集,再适当调整属性的次序。
  • 实体间的联系在不同的E-R图中为不同的类型。
  • 例:实体E1与E2在一个E-R图中是多对多联系,在另一个E-R图中是一对多联系。
  • 解决方法:是根据应用的语义对实体联系的类型进行综合或调整。
(2)消除不必要的冗余,设计基本E-R图
  • 所谓冗余的数据是指可由基本数据导出的数据,冗余的联系是指可由其他联系导出的联系。
  • 消除冗余主要采用分析方法,即以数据字典和数据流图为依据,根据数据字典中关于数据项之间逻辑关系的说明来消除冗余。
  • 消除冗余后的初步E-R图,称为基本E-R图。
  • 【说明】并不是所有的冗余数据与冗余联系都必须加以消除,有时为了提高效率,不得不以冗余信息作为代价。
  • 例子可看书本P229~231
除分析方法外,还可以用用规范化理论来消除冗余:
  • ① 确定分E-R图实体之间的数据依赖。
  • 实体之间一对一、一对多、多对多的联系可以用实体码之间的 函数依赖来表示。
  • 于是有函数依赖集FL。
  • (实例可看书本P230~231)

7.4 逻辑结构设计

  • 逻辑结构设计的任务:把概念结构设计阶段设计好的基本E-R图转换为与选用数据库管理系统产品所支持的数据模型相符合的逻辑结构。
  • E-R图 由实体型、实体的属性和实体型之间的联系三个要素组成。
  • E-R图 向关系模型的转换就是将实体型、实体的属性和实体型之间的联系转化为关系模式。
  1. 转换原则:一个实体型转换为一个关系模式。关系的属性为实体的属性,关系的码为实体的码。
  2. 实体型间的联系有以下不同情况
  • (1)一个 1:1 联系可以转换为一个独立的关系模式,也可以与任意一端对应的关系模式合并。
  • ① 转换为一个独立的关系模式
  • 关系的属性:与该联系相连的各实体的码及联系本身的属性。
  • 关系的候选码:每个实体的码均是该关系的候选码。
  • ② 与某一端实体对应的关系模式合并
  • 合并后关系的属性:加入对应关系的码和联系本身的属性
  • 合并后关系的码:不变。
  • (2)一个 1:n 联系可以转换为一个独立的关系模式,,也可以与 n端 对应的关系模式合并。
  • ① 转换为一个独立的关系模式
  • 关系的属性:与该联系相连的各实体的码及联系本身的属性。
  • 关系的候选码:n端 实体的码。
  • ② 与 n端 对应的关系模式合并
  • 合并后关系的属性:在 n端 关系中加入 1端 关系的码和联系本身的属性。
  • 合并后关系的码:不变。
  • 该方法可以减少系统中的关系个数,一般情况下更倾向于采用这种方法。
  • (3)一个 m: n联系 转换为一个关系模式。
  • 关系的属性:与该联系相连的各实体的码及联系本身的属性。
  • 关系的候选码:各实体码的组合。
  • (4)三个或三个以上实体间的一个多元联系转换为一个关系模式。
  • 关系的属性:与该联系相连的各实体的码及联系本身的属性。
  • 关系的候选码:各实体码的组合。
  • (5)具有相同码的关系模式可合并。
  • 目的:减少系统中的关系个数。
  • 合并方法:
  • 第一步:将其中一个关系模式的全部属性加入到另一个关系模式中。
  • 第二步:去掉其中的同义属性(可能同名也可能不同名)
  • 第三步:适当调整属性的次序。
  • (实例可看书本P232)

7.4.2 数据模型的优化

  • 数据库逻辑设计的结果不是唯一的。
  • 进一步提高数据库应用系统的性能,还应该适当地修改、调整数据模型的结构,这就是数据模型的优化。
  • 优化数据模型的方法:
  • (1)确定数据依赖。按需求分析阶段所得到的语义,分别写出每个关系模式内部各属性之间的数据依赖以及不同关系模式属性之间数据依赖。
  • (2)对于各个关系模式之间的数据依赖进行极小化处理,消除冗余的联系。
  • (3)按照数据依赖的理论对关系模式进行分析,考察是否存在部分函数依赖、传递函数依赖、多值依赖等,确定各关系模式分别属于第几范式。
  • (4)按照需求分析阶段得到的各种应用对数据处理的要求,分析对于这样的应用环境这些模式是否合适,确定是否要对它们进合并或分解。
  • 【说明】并不是规范化程度越高的关系就越优。
  • 例如:当查询经常涉及两个或多个关系模式的属性时,系统必须经常地进行连接运算,代价相当高,因此在这种情况下,第二范式甚至第一范式也许是适合的。
  • (5)对关系模式进行必要分解,提高数据操作效率和存储空间的利用率。
  • 常用分解方法有水平分解和垂直分解:
  • ① 水平分解:把(基本)关系的元组分为若干子集合,定义个子集合为一个子关系。
  • 分解方法:
  • 一是对符合80/20的,把经常使用的数据(约20%)水平分解来,形成一个子关系。
  • 二是使每个事务存取的数据对应一个子关系。
  • ② 垂直分解:把关系模式R的属性分解为若干子集合,形成若干子关系模式。
  • 分解原则:经常在一起使用的属性从R中分解出来形成一个子关系模式。
  • 分解优点:可以提高某些事务的效率。
  • 分解缺点:可能使另一些事务不得不执行连接操作,降低了效率。
  • 适用范围:取决于分解后R上的所有事务的总效率是否得到了提高。

7.4.3 设计用户子模式

  • 定义数据库模式主要是从系统的时间效率、空间效率、易维护等角度出发。
  • 定义用户外模式时应该更注重考虑用户的习惯与方便。包括三个方面:
  • (1)使用更符合用户习惯的别名
  • (2)针对不同级别的用户定义不同的视图,以保证系统的安全性。
  • (3)简化用户对系统的使用

7.5 物理结构设计

1. 什么是数据库的物理设计

  • 数据库在物理设备上的存储结构与存取方法称为数据库的物理结构,它依赖于选定的数据库管理系统。
  • 为一个给定的逻辑数据模型选取一个最适合应用要求的物理结构的过程,就是数据库的物理设计。

2. 数据库物理设计的步骤

  • (1)确定数据库的物理结构
  • 在关系数据库中主要指存取方法和存储结构。
  • (2)对物理结构进行评价
  • 评价的重点是时间和空间效率。

7.5.1 数据库物理设计的内容和方法

设计物理数据库结构的准备工作

  • (1)充分了解应用环境,详细分析要运行的事务,以获得选择物理数据库设计所需参数。
  • (2)充分了解所用关系型数据库管理系统的内部特征,特别是系统提供的存取方法和存储结构。

选择物理数据库设计所需参数

  • (1)对于数据库查询事务,需要得到以下信息:
  • ① 查询的关系
  • ② 查询条件所涉及的属性
  • ③ 连接条件所涉及的属性
  • ④ 查询的投影属性
  • (2)对于数据更新事务,需要得到以下信息:
  • ① 被更新的关系。
  • ② 每个关系上的更新操作条件所涉及的属性
  • ③ 修改操作要改变的属性值。
  • (3)每个事务在各关系上运行的频率和性能要求。

关系数据库物理设计的内容

  • 为关系模式选择存取方法(建立存取路径)以及设计关系、s索引等数据库文件的物理存储结构。

7.5.2 关系模式存取方法选择

  • 数据库系统是多用户共享的系统,对同一个关系要建立多条存取路径才能满足多用户的多种应用要求。
  • 物理结构设计的任务之一是根据关系数据库管理系统支持的存取方法确定选择哪些存取方法。
  • 数据库管理系统常用存取方法:(B+树 和 Hash索引 最经典)
  • ① B+树索引存取方法
  • ② Hash索引存取方法
  • ③ 聚簇存取方法

7.5.3 确定数据库的存储结构

  • 确定数据库物理结构主要指确定数据的存放位置和存储结构。
  • 包括:确定关系、索引、聚簇、日志、备份等的存储安排和存储结构,确定系统配置等。
  • 确定数据的存放位置和存储结构要综合考虑存取时间、存储空间利用率 和 维护代价 3个方面的因素。

确定数据的存放位置

  • 根据应用情况将易变部分与稳定部分分开存放、经常存取部分与存取频率较低部分分开存放。

确定系统配置

7.5.4 评价物理结构

  • 评价方法主要是定量估算各种方案的存储空间、存取时间、维护代价,对估算结果进行权衡、比较,选择出一个较优的合理的物理结构。

7.6 数据库的实施和维护

7.6.1 数据的载入和应用程序的调试

数据的载入

  • 数据装载方法:人工方法、计算机辅助数据入库。

应用程序的调试

7.6.2 数据库的试运行

  • 应用程序调试完成,并且已有一小部分数据入库后,就可以开始对数据库系统进行联合调试,也称数据库的试运行。
  • 主要工作包括:
  • 功能测试:实际运行应用程序,执行对数据库的各种操作,测试应用程序的各种功能。
  • 性能测试:测量系统的性能指标,分析是否符合设计目标。
  • 【说明】
  • ① 数据的分期入库。
  • ② 做好数据库的转储和恢复。

7.6.3 数据库的运行和维护

  • 在数据库运行阶段,对数据库经常性的维护工作主要是由数据库管理员完成。
  • 主要工作包括:
  • 数据库的转储和恢复
  • 数据库的安全性、完整性控制
  • 数据库性能的监督、分析和改进
  • 数据库的重组织与重构造

7.7 小结

数据库设计的方法和步骤

数据库设计6个阶段

  • 重点是概念结构的设计和逻辑结构的设计。

概念结构的设计

  • 概念结构的设计着重介绍了E-R模型的基本概念和图示方法
  • 应重点掌握实体型、属性和联系的概念
  • 理解实体型之间的一对一,一对多和多对多联系
  • 掌握E-R模型的设计以及把E-R模型转换为关系模型的方法。

逻辑结构的设计

  • 将概念结构转化为具体的数据模型。

声明:三二一的一的二|版权所有,违者必究|如未注明,均为原创|本网站采用BY-NC-SA协议进行授权

转载:转载请注明原文链接 - 数据库系统概论 - 第七章 - 数据库设计


三二一的一的二