③⭐全网首发☀️数据有道之数据库技术❤️干货大全【持续更新】❗❗❗

我就是我 2022-09-10 04:25 77阅读 0赞

**目录**

3.1　数据库概念设计

考点1　概念设计的任务

考点2　概念设计的依据及过程

考点3　数据建模方法

考点4　概念设计实例

3.2　数据库逻辑设计

考点1　任　务

考点2　目　标

3.3　数据库物理设计

考点1　物理设计的目的

考点2　数据库的物理结构

考点3　索　引

考点4　数据库物理设计

考点5　其他物理设计环节

每文一语

--------------------

## 3.1　数据库概念设计 ##

### 考点1　概念设计的任务 ###

（1）概念设计的任务

数据库概念设计的主要任务是理解和获取应用领域中的**数据需求，分析、抽取、描述和表示清楚目标系统需要存储和管理什么数据**，这些数据具有什么样的属性特征及组成格式。数据之间存在什么样的依赖关系。

（2）概念设计的目标

**①定义和描述应用领域涉及的数据范围；**

**②获取应用领域或问题域的信息模型；**

**③描述清楚数据的属性特征；**

**④描述清楚数据之间的关系；（老师与学生）**

**⑤定义和描述数据的约束；**

**⑥说明数据的安全性要求；**

**⑦支持用户的各种数据处理需求；**

**⑧保证信息模型方便地转换成数据库的逻辑结构（数据库模式）。同时也便于为用户理解。**

【真题演练】

下列不属于概念设计目标的是（ ）。

A．定义和描述应用领域涉及的数据范围

B．描述清楚数据的属性特征

C．定义和描述数据的约束

D．确定数据的结构

【答案】D

### 考点2　概念设计的依据及过程 ###

（1）概念设计的依据

①需求分析阶段的文档，包括需求说明书、功能模型（数据流程图或IDEFO图）；

②在需求分析阶段收集到的应用领域或问题域中的各类报表等。

通过对这些文档的分析和理解，从中抽象出数据的结构、语义、数据之间的相互联系及数据满足的约束条件，从而构造信息模型，编写数据库概念设计说明书。

（2）概念设计的过程

**①明确建模目标**

确定模型覆盖的问题范围和目标说明，将两者结合起来定义的建模目标有助于建模人员标识所关心的数据。

**②定义实体集**

a．通过需求分析阶段得到的功能模型DFD图、需求说明书以及需求分析阶段收集到的原始单据、统计报表、表格等来标识和定义应用领域中的实体集。

b．通常采用自底向上的方式，从一个局部或子系统入手，标识和定义实体集。对于复杂的数据库应用系统可分别画出子系统的ER图，然后将各局部ER图集成整合成应用系统总体的信息模型。

c．定义实体集的方法是分类标识、概括命名。

第一，将应用域收集到的原始数据进行分类，即按照具有相同属性特征原则归类；

第二，依次列出每个实体集的名称。

d．对于一些复杂问题或应用域，也可以通过分类标识原材料中所有名词的方法标识和定义实体集，但不是所有名词都可作为实体集名词。实体集名词具有下列特征：

第一，能够被描述或说明；

第二，有多个同类的实例；

第三，每个实例可以被标识和区分。

③定义联系

a．联系用于描述实体集之间的关联关系，而联系的实例表示一个联系中的两个实例之间有意义的关联或连接。

b．标识实体集之间关系的简单方法是建立联系矩阵，联系矩阵由一个二维数组表示。

将前阶段定义的实体集沿水平轴和垂直轴两个方向列出，依次分析两个实体集之间可能的联系。如果两个实体集之间存在联系，则在它们的交叉点上写上×，不存在联系则用空格标注。

c．间接联系不需要标注。

d．在标识联系之后进行定义联系，主要包括：表示依赖、命名联系及关于联系的说明。

e．根据联系矩阵，从两个方向进一步检验实体集之间存在的依赖关系，以确定实体集之间联系的基数。

f．确定了实体集之间的联系之后，给联系命名。要求定义的联系名的动词或者动词短语必须是具体的、简明的和有意义的。

④建立信息模型 （ER模型）

根据前阶段标识定义的联系基数，选择一种建模方法，从局部或子系统入手，先建立局部信息模型，然后再综合成为总体信息模型。

⑤确定实体集属性

a．属性被用来描述一个实体集的特征或性质；

b．为了使模型更简明，实体集的属性可以不画在模型图中，而通过实体集—属性列表的形式将它们附在模型后面；或者在数据库的逻辑设计阶段给出。

⑥对信息模型进行集成与优化 （命名，结构一致）

在局部数据建模的基础上，进行模型的集成、汇总与优化，保证构造的概念数据模型是正确的、一致的和满足数据需求的。

【真题演练】

下列关于数据库概念设计的说法中，错误的是（ ）。

A．抽象实体集时需将具有相同属性特征的事物归为一类，并对分类进行概括和命名

B．确定描述每个实体集特征的属性，并为属性命名

C．确定各实体之间的联系，但不需要确定联系具有的属性

D．确定联系的种类

【答案】C

### 考点3　数据建模方法 ###

（1）概述

数据建模工具的出现使得建模人员表示数据结构的方式产生了变革。自Peter Chen之后人们又陆续推出了其他的数据建模方法，例如**IDEFIX、UML中的类图等**。这些数据建模方法的共同特点是：

①能够真实客观地描述现实世界中的数据及数据之间的关系。

②组成模型的概念少，语义清楚，容易理解。

③不同概念的语义不重叠，概念无多义性。

④用图形方式描述数据，数据直观易懂，有利于数据库设计者和用户交流。

⑤这种数据模型容易转换成数据库逻辑设计阶段需要的数据结构。

（2）ER建模方法

①定义

实体联系（Entity Relationship，ER）方法是一种面向数据存储需求建模，将现实世界中需要处理的数据抽象组织成某种不依赖于具体的计算机系统，仅从存储需求描述数据的属性特征及数据之间的关系的信息结构。

②与ER模型有关的几个概念

a．实体或实例（Instance）

实体指客观存在并可相互区分的事物（也称为实体集实例或实例）,可以是一个具体的人或物，也可以是抽象的事件或概念。

b．实体集

实体集表示具有相同的属性或特征的事物的抽象集合，这些事物必须具有相同的属性或特征。例如，学生实体集指全部学生的集合。这个集合中的一个元素就是这个实体集的一个实例（Instance）。

c．属性

属性用于描述一个实体集的性质和特征。

d．域

每个属性的取值范围称为域。

e．码 （键）

实体集中能唯一标识每一个实例的属性或属性组称为该实体集的码（学号）

f．联系

联系描述现实世界中实物之间的关系。

现实世界事物之间的联系可归纳为三类：

第一，一对一联系（1︰1）

若对于实体集A中的每一个实例，实体集B中至多有一个实例与之联系，反之亦然，则称实体集A和实体集B具有1︰1联系。

第二，一对多联系（1︰n）

若对于实体集A中的每一个实例，实体集B中有n个实例（n≥0）与之联系，而对于实体集B中的每个实例，实体集A中至多有一个实例与之联系，则称实体集A与实体集B存在1︰n的联系。

第三，多对多联系（m︰n）

若对于实体集A中的每一个实例，实体集B中有n个实例（≥0）与之联系，而对于实体集B中的每个实例，实体集A中有m个实例（m≥0）与之联系，则称实体集A与实体集B存在m︰n的联系。

③ER图的表示方法

a．**矩形框表示实体集，矩形框内写上实体集的名称**。

b．**菱形框表示联系，联系名写在菱形框内**。

c．**椭圆或圆角矩形框表示属性，属性的名字写在椭圆或圆角矩形框中**。

按照给出的建模过程及ER模型规范，描述目标系统的数据需求。通常模型描述了一个企业或组织全部数据的存储需求，即数据库中将要存储的数据范围、数据的属性特征与数据之间的关系。

（3）IDEFlX建模方法

①**IDEFlX与IDEFO**

a．联系

IDEFlX与IDEFO是一个系列的建模工具。

b．区别

IDEFO侧重描述系统功能需求，被称为功能建模方法；IDEFlX侧重分析、抽象和概括应用领域中的数据需求，被称为数据建模方法。

**②IDEFlX模型的建模元素**

a．实体集

用矩形框来表示的独立标识符实体集（独立实体集）是指每个实例都能被唯一地标识而不决定于它与其他实体集的联系；用加了圆角的矩形框来表示的从属标识符实体集（从属实体集）是指一个实例的唯一标识依赖于该实体集与其他实体集的联系。

b．联系

一个“确定型连接联系”或简称“连接联系”，是实体集之间的一种连接或关系。在这种连接联系中，被称为双亲实体集的每一个实例与子女实体集的0个、1个或多个实例相连接。子女实体集中的每个实例精确地同双亲实体集的1个实例相联系。

**第一，标定型联系**

在“确定型连接联系”中，如果子女实体集中的每个实例都是由它与双亲的联系而确定的，那么这个联系就被称为是“标定型联系”（Identifying Relationship）

**第二，非标定型联系**

在“确定型连接联系”中，如果子女实体集中的每一个实例都能被唯一地确认而无需了解与之相联系的双亲实体集的实例，则该联系就被称为“非标定型联系”（Non-Identifying Relationship）

**第三，分类联系**

“分类联系”是两个或多个实体集之间的联系，且在这些实体集中存在一个一般实体集（Generic Entity），它的每一个实例都恰好与一个且仅一个分类实体集（Category Entity）的一个实例相联系。

一般实体集的每一个实例和与之相关的一个分类实体集实例描述的是现实世界的同一事物，因此它们具有相同的唯一标识符。

**第四，非确定联系**

一个非确定联系又称为“多对多关系”（Many to Many Relationship）或m︰n联系。在这种联系关联的两个实体集之间，任一实体集的一个实例都将对应另一实体集的0个、1个或多个实例

在最终的IDEF1X模型中，所有实体集之间的联系都必须用确定联系来描述。但在建模的初始阶段，标识两个实体集之间的一些“非确定联系”（Not-Specific Relationships）

常常对开发模型是有帮助的。在最终的模型中不允许出现非确定联系，任何一个非确定联系必须被转化成为确定的连接联系。

### 考点4　概念设计实例 ###

（1）建模目标

根据商场经营管理系统的总目标可知，该待建模型将支持商场经营管理中包括顾客管理、采购与库存管理、销售管理、人力资源管理、财务管理多项业务活动。

①顾客管理部分

存储与管理的数据要能支持顾客申请成为会员、个人积分信息查询、个人信息更新、自动生成生日邮件祝福需要的信息，以及会员卡的升级管理需要的信息；

②采购与库存管理部分

存储与管理的数据要能支持商品入库上架及库存管理，当某商品达到最小库存时自动生成采购单引发采购活动需要的信息；

③销售管理部分

存储和管理的数据要能支持商品的价格管理，如根据销售渠道制定合理的销售价格，根据库存和销售情况为一些在售商品调价，以及支持各类销售统计信息的生成；

④人力资源管理部分

存储和管理的数据要能支持员工招聘、合同管理及员工业绩考核需要的信息；

⑤财务管理部分

存储与管理的数据要能支持商场各项资金的收支管理、员工工资发放，以及生成各类财务统计报表需要的信息。

（2）定义实体集

首先从标识实体集开始，从需求分析阶段产生的DFD图中的输入数据流、输出数据流、数据存储，以及需求分析阶段收集到的单据、统计报表等材料中发现事实，捕捉需要的信息，忽略无关的数据。

在标识实体集的基础上分类抽象，将具有相同属性特征的同类对象抽象为实体集，然后归纳整理，用一个有意义的名词或名词短语为每一个实体集命名。

（3）定义联系 **（难点）**

定义联系的工作从标识联系开始。分析商场经营管理系统业务活动与管理规范可知，其数据之间存在如下约束：

①一个顾客可以申请0或一张会员卡，一张会员卡属一个顾客拥有；

②一张会员卡可用于多个销售单据，一个销售单据只能使用一张会员卡；

③一个收银台可以收取多个销售单据的缴费额，一个销售单据仅限于在一个收银台缴费；

④一个供应商可提供多种商品，一种商品可以由多个供应商提供，一个采购单据可以购进多个供应商提供的多种商品；

⑤一个员工可以开出多个销售单据，一个销售单据仅限于一个员工开出；

⑥一个销售单据可以售出多种商品，一种商品可以由多个销售单据售出；

⑦一种商品允许在不同时间有多次调价，但在同一时间只有一次调价；

⑧一个员工可以领导多个员工，每个员工的直接领导只有一个。

（4）建立信息模型

根据联系矩阵描述的实体集之间的关联关系及数据之间的约束，可画出商场经营管理系统的ER图，如图3\-8所示（注：图中省略了“员工”实体的属性），员工及员工领导与被领导之间的关系如图3-9所示。

（5）确认实体集属性

①确认过程

在ER模型中画出每个实体集的属性，并逐一检查确认每个属性的正确性，在此基础上标出ER图中每个实体集的主码属性（用下画线标注）。如果ER模型所含的实体集很多，可在ER图中仅给出每个联系的属性。

②实体集—属性列表

实体集所含的全部属性通过实体集—属性列表给出。实体集—属性列表按照实体集在ER图中的位置，由上到下、从左到右依次列出，其表示范如下：

a．实体集名：顾客

b．属性列表：顾客编号、姓名、性别、出生日期、身份证号、地址、邮编、电话、电子邮箱、顾客密码

c．实体集名：会员卡

d．属性列表：会员卡号、有效起始日期、有效截止日期、积分、状态

（6）对信息模型进行集成与优化

①目的

进一步检查确认模型中是否存在重复命名的联系和信息，以保证其中不存在有歧义的名字。通常实体集名、属性名用一个有意义的名词或名词短语命名，联系名用一个有意义的动词或动词短语命名，父实体集通常安排在子女实体集的上面或左边，联系名由父到子命名，如顾客“拥有”会员卡等。

②注意事项

对于大型复杂的数据库应用系统可能需要划分为多个子系统，并由不同的人员先对各子系统建模，然后汇总集成为系统的数据模型。在进行模型的汇总集成时应注意：

a．如果模型涉及的实体集在一页内放不下，可以安排多页描述，除了用于表示各子系统相交或页面相交的实体集可以重复以外，在一个模型中不允许出现重复的实体集。

b．在模型汇总集成的过程中需要检查模型的各组成部分之间是否存在命名冲突、结构不一致等方面的问题。

## 3.2　数据库逻辑设计 ##

### 考点1　任　务 ###

把数据库概念设计的结果（ER模型）**，转换为具体的数据库管理系统支持的数据模型**。这个阶段将按照具体数据库管理系统支持的数据模型来组织和存储数据，包括定义和描述数据库的全局逻辑结构、数据之间的关系、数据的完整性及安全性要求等。

### 考点2　目　标 ###

得到实际的数据库管理系统可处理的数据库模式，各模式结构合理，数据之间不存在不合理的数据依赖关系，且满足各类应用的处理和使用要求，为数据库的物理设计及数据库高效、正确地运行打下基础。

## 3.3　数据库物理设计 ##

### 考点1　物理设计的目的 ###

（1）将数据的逻辑描述转换为实现技术规范，设计数据存储方案，以便提供足够好的性能并确保数据库数据的完整性、安全性和可恢复性。

（2）选择最优数据存储方案以加快数据检索速度，了解不同文件组织方式、索引技术及其使用方法。

（3）确定数据库的物理结构。

### 考点2　数据库的物理结构 ###

（1）概述

数据库中的应用数据是以文件形式存储在外设存储介质（如磁盘）上的，文件在逻辑上被组织成记录的序列，即每个DB文件可以看作是逻辑记录的集合。一个文件在磁盘上占有一定的物理存储空间，文件中的每个逻辑记录被映射存储到某个特定的磁盘块上。一个文件在物理上可以看作是由存放文件记录的一系列磁盘块组成的，称之为物理文件。

（2）逻辑结构与物理结构的映射方式

文件的逻辑记录与磁盘块间的映射关系是由操作系统或DBMS来管理的。当需要对一个文件逻辑记录查询、插入、删除、修改时，首先要根据这种映射关系找到该逻辑记录所在的磁盘块，然后再进行相应的操作。

（3）构建物理结构时需注意的问题

①文件的组织

如何将数据库映射到操作系统文件中，也即如何将关系数据库中的关系表映射为数据库文件，以及将关系表中的元组映射到文件的逻辑记录，如何管理这些数据库文件；数据库文件中逻辑记录采用何种格式。

②文件的结构

也称为文件中记录的组织。如何在外设磁盘上安排、存放数据库文件的逻辑记录，也即如何将DB文件的逻辑记录映射到物理文件中的磁盘块。

③文件的存取

对具有某种结构的DB文件，如何去查找、插入、删除和修改其中的逻辑记录。文件的存取与文件的结构密切相关，每种文件结构都有与之对应的文件存取方法。

④索引技术

当数据库中关系表的数目及关系表中的元组数目非常多时，可以利用索引技术提高DB文件的存取速度。

【真题演练】

下列不属于数据库物理设计内容的是（ ）。

A．确定数据库文件在磁盘上的物理存储位置

B．确定数据库文件的结构和具体实现细节

C．确定索引字段和索引类型

D．在进行数据库物理设计时要考虑空间利用率、数据访问效率

【答案】B

### 考点3　索　引 ###

（1）概述

索引技术（Indexing）是一种快速数据访问技术，它将一个文件的每个记录在某个或某些域（或称为属性）上的取值与该记录的物理地址直接联系起来，提供了一种根据记录域的取值快速访问文件记录的机制。索引技术的关键是建立记录域取值到记录的物理地址间的映射关系，这种映射关系称为索引（Index）。

（2）索引的优缺点

①优点：提高数据库性能，加快访问速度。

②缺点：占用存储空间，维护需要时间。

（3）索引技术分类

根据索引的实现方式不同，索引技术被分成以下两类：

①有序索引技术（索引文件机制）

有序索引技术利用索引文件实现记录域取值到记录物理地址间的映射关系。

a．记录域

这里的记录域就是查找码（排序域），查找码可以是数据文件的主码或主属性，也可以是非主属性。

b．索引文件与索引项

索引文件由索引记录组成，每个记录中记载着一个索引项，索引项记录了某个特定的查找码值和具有该值的数据文件记录的物理地址。

c．使用

当需要访问数据文件中某个数据记录时，先根据记录域取值查阅索引文件，找到对应的索引项；从索引项中找出数据记录在数据文件中的物理地址，然后根据这个地址存取数据记录。

②散列技术（哈希索引机制）

散列技术利用一个散列函数实现记录域取值到记录物理地址间的直接映射关系。

a．记录域

这里的记录域就是查找码（散列函数的散列域或排序域）。

b．文件查找码

在一个文件中查找某个或某些特定文件记录时，需要给出记录应满足的查询条件，这些用于在数据文件中查找记录的属性或属性集合就是文件查找码。对于存储有关系表数据的数据库文件，该文件的查找码可以是关系表的主码或候选码，也可以是关系表的其他非主属性。

c．使用

当需要访问数据文件中查找码值为si的某个或某些目标记录时，将si作为散列函数h的输入，计算得出的散列函数输出值h（si）就是目标记录在数据文件中的物理地址。

（4）有序索引

①概述

数据库中的数据文件经常采用顺序文件结构（后续讨论的数据文件均假设采用此结构），文件的数据记录按照某个特定的查找码值的升序或降序顺序地存储在文件中。索引建立在查找码上。如果对一个数据文件需要从几个方面去查询文件记录，可以定义多个查找码，针对每个查找码建立相应的索引文件。一个数据文件可以有多个查找码和多个索引文件。

②主体

有序索引的两个主体：数据文件和索引文件。数据文件又称被索引文件或主文件。

③需要考虑的关键问题

a．如何组织索引文件中的索引记录；

b．如何从索引文件出发，访问数据文件中的数据记录。

④索引文件建立方法

a．选定数据文件中的某个或某些记录域作为查找码，然后建立起数据记录在查找码上的取值与该记录的物理地址间的映射关系，组成索引项。

b．所有索引项作为索引记录存储在索引文件中。

c．索引文件根据某个特定的查找码值的升序或降序存储索引记录，并且也组织为顺序文件。

对于存储有关系表数据的数据库文件，该文件的查找码可以是关系表的主码或候选码，也可以是关系表的其他非主属性。

⑤有序索引的分类及特点

a．聚集索引和非聚集索引

**第一，定义**

对数据文件和它的一个特定的索引文件，如果数据文件中**数据记录的排列顺序与索引文件中索引项的排列顺序相一致**，或者说索引文件按照其查找码指定的顺序与数据文件中数据记录的排列顺序相一致，则称该索引文件为聚集索引；否则，称该索引文件为非聚集索引。

**第二，建立**

**在一个数据文件上除了可以建立一个聚集索引外，还可以建立多个非聚集索引。**

例如：

索引文件中索引项按照“商品编号”排序，数据文件中的数据记录则按照“商品类别”排序，索引文件的排列顺序与数据文件的排列顺序不一致，因此该索引文件属于非聚集索引。

第三，索引顺序文件

如果一个数据文件按照某个查找码组织为顺序文件，同时在该数据文件上又建有聚集索引，则该数据文件称为索引顺序文件。对索引顺序文件而言，既可以对数据记录进行顺序访问，又可以根据数据文件上的聚集索引对数据记录进行直接访问。

b．稠密索引和稀疏索引

如果数据文件中的每个查找码值在索引文件中都对应一个索引记录，则该索引称为稠密索引，如果只是一部分查找码的值有对应的索引记录，则该索引称为稀疏索引。

第一，稠密索引

在带稠密索引的数据文件中，查找速度较快。

第二，稀疏索引

索引文件只对数据文件中查找码“类别”的3个取值“服装，酒类，鞋类”建立了索引项，因此该索引属于稀疏索引。

c．主索引和辅索引

在数据文件的主码属性集上建立的索引称为主索引。在数据文件的非主属性上建立的索引称为辅索引。

**第一，主索引**

**第二，辅索引**

两个索引文件均是建立在非主属性“类别”上，“类别”并不是数据文件“Goods”的主码，因此这两个索引都是辅索引。

在实际的关系数据库系统中，数据库管理系统通常按照主码值的顺序将元组有序存储在数据文件中，并且以主码作为查找码建立索引文件。该索引文件既是主索引，也是聚集索引。

d．唯一索引

唯一索引可以确保索引列不包含重复的值。在多列唯一索引的情况下，可以确保索引列中每个值的组合都是唯一的。例如，如果在last\_name、first\_name和middle\_initial列的组合上创建了唯一索引full\_name，则该表中任何两个人都不可以具有相同的全名。

e．单层索引和多层索引

第一，单层索引（线性索引）

特点是索引项根据键值在索引文件中顺序排列，组织成一维线性结构，每个索引项直接指向数据文件中的数据记录。

第二，多层索引

当数据文件很大时，可以对索引文件中的索引项本身再建立一级稀疏索引，组成二层索引结构，用于快速查找索引项，

如果有二层索引，则首先在外层索引中找到一个外层索引项，然后沿着外层索引项中的指针到达内层索引块；在内层索引块可用顺序查找或二分查找找到相应的内层索引项，这个索引项中的指针指向了需要访问的数据记录。

进一步地，可以建立多层树型索引结构来快速定位大数据量文件中的数据记录。多层索引的典型例子是数据库系统中广泛应用的B树和B+树索引。

需要注意的是，在现代关系型数据库系统中，很多数据库管理系统采用了基于成本的SQL优化器，这些优化器会根据数据的分布情况、数据块的多少等统计数据来判定查询中是否使用索引，所以，可能会出现建立索引后并未真正被使用的情况，一般需要数据库管理员使用数据库管理系统自带的工具查看执行计划，以确认索引是否被使用。

【真题演练】

下列关于索引的说法中，错误的是（ ）。

A．索引是典型的空间换取时间的方法，因此在设计索引时要在空间与时间两者之间进行权衡

B．建立聚集索引时，数据库管理系统会按照聚集索引键值对数据进行排序

C．聚集索引的键值不能重复

D．当经常进行范围查询时，在范围列上建立索引可以提高该类查询的效率

【答案】C

### 考点4　数据库物理设计 ###

（1）物理设计的内容

数据库物理设计包括以下环节:

①数据库逻辑模式描述

将与平台无关的描述数据库逻辑结构的关系模式及其视图转换为所选定的具体DBMS平台可支持的基本表和视图，并利用DBMS提供的完整性机制（如触发器）设计定义在基本表上的面向应用的业务规则。

②文件组织与存取设计

选择或配置基本表的文件组织形式，如堆文件、顺序文件、索引文件、散列文件等；根据实际情况，为基本关系表设计合适的存取方法和存取路径，如设计索引字段和索引，以提高数据查询速度、

③数据分布设计

a．根据数据类型、作用和使用频率的不同，将数据库中应用数据、索引、日志、备份数据等不同类型数据合理安排在磁盘、磁带等不同存储介质中；

b．根据实际需要，对分布式数据库系统中的应用数据设汁合理的数据副本，通过水平划分或垂直划分分割成不同的数据片断，然后分布存储在各局部数据库中，以提高系统的数据访问效率和数据可靠性；

c．考虑关系模式中派生属性的存储方式，合理调整关系模式的规范化程度，以便在数据存储代价和数据访问效率之间作合理的权衡折中。

④确定系统配置

根据应用环境和物理设计结果，合理设置和调整DBMS和操作系统的存储分配参数，提供系统软硬件平台的初始配置信息。

⑤物理模式评估

对数据库物理设计结果从时间、空间、维护代价等方面进行评估，从多种可行方案中选择合理的数据库物理结构。

（2）数据库逻辑模式描述

数据库物理设计需要根据数据库逻辑结构信息设计目标DBMS平台可支持的关系表（这里称为基本表）的模式信息，这些模式信息代表了所要开发的具体目标数据库的结构。这个过程称为数据库逻辑模式描述，主要包括以下设计内容。

①面向目标数据库描述基本表和视图。采用目标DBMS所支持的建表语法，描述基本表及满足应用要求的完整性约束。

②设计基本表业务规则。使用CREAT TABLE语句可以定义主码、外码、值域、空值等较为简单的、面向模型的完整性约束。

在数据库逻辑设计阶段，已经面向各关系模式设计了面向应用的完整性约束，也就是关系表业务规则。进一步地，在数据库物理设计阶段，可以依据这些关系表业务规则，利用目标DBMS提供的完整性控制机制设计基本表应遵守的面向应用的完整性约束，也就是基本表业务规则。

（3）DB文件组织步骤

一个好的数据库物理模式应当满足存储空间占用少、数据访问效率高和维护代价低的要求。

为了进行有效的数据库文件组织和存取路径设计，必须分析和理解数据库事务的数据访问特性。

事务分析可以按照如下步骤进行：

①使用事务—基本表交叉引用矩阵，分析系统内（部分重要的）数据库事务对各个基本表的访问情况，确定事务访问了哪些基本表，对这些基本表执行了何种操作，并进一步分析各操作涉及的基本表属性。

事务-基本表交叉引用矩阵的例子如表3-1所示。其中事务1对基本表1和基本表3执行了插入和更新操作，对基本表2执行了读操作。

表3-1　事务—基本表交叉引用矩阵

注：I—插入；R—读取；U—更新；D—删除：

②估计各事务的执行频率，即单位时间内事务的执行次数。在此基础上分析事务中的每个数据访问操作对各个基本表中的相关属性的操作频率。

例如事务1每天约运行100次，对基本表1的更新操作的频率为每天约40次，更新操作作用于基本表1中的属性A。

③对每张基本表，汇总所有作用于该表上的各事务的操作频率信息，得到如下数据访问估计信息：该表是否被频繁访问，该表中哪些属性列的访问频率较高和作用于这些属性上的操作类型和查询条件类型（等值查洵、范围查询）。

根据事务数据访问特性分析结果，可以对基本表设计成更为有效的文件组织和索引方式。每种DBMS平台都提供一种或若干种数据库文件结构（如堆文件、顺序文件、聚集文件、索引文件和散列文件）。数据库物理结构设计者应当了解目标DBMS提供的各种数据库物理结构机制，根据应用系统实际情况，为数据库和基本表选择合适的文件结构。

（4）为基本表选择合适的文件结构的原则

①如果数据库中的一个基本表中的数据量很少，并且插入、删除、更新等操作非常频繁，该基本表可以采用堆文件组织方式。因为堆文件无需建立索引，维护代价非常低。虽然堆文件的数据访问效率较低，但在数据量很少时，定位文件记录的时间非常短。

当需要向新创建的基本表批量加载数据时，可将表的文件结构先选为堆文件，向表中加载数据后再重新调整文件结构，如改为数据查询效率更高的B+树文件。

②顺序文件支持基于查找码的顺序访问，也支持快速的二分查找。如果用户的查询条件定义在查找码上，则顺序文件是比较合适的文件结构。

③如果用户查询是基于散列域值的等值匹配，特别是如果访问顺序是随机的，则散列文件比较合适。但散列文件组织不适合下述情况：

a．基于散列域值的非精确查询（如模糊查询、范围查询）。例如，在Goods散列文件中查找商品“类别”以“家”字开头的商品。

b．基于非散列域进行的查询。例如，在Goods散列文件中按商品“名称”进行查询。

④B-树和B+树文件是实际数据库系统中使用非常广泛的索引文件结构，适合于定义在大数据量基本表上、基于查找码的等值查询、范围查询、模糊查询和部分查询。B-树和B+树属于动态索引，可以随着数据文件的内容变化不断调整，保证数据查询的性能不会恶化。

⑤如某些频繁执行且需要进行多表连接操作的查询，可以考虑将这些基本表组织为聚集文件，以改善查询效率。

（5）DB文件存取设计的主要内容

对数据库中的基本表等数据库对象选择了合适的文件结构后还需要为其设计存取路径，设计内容包括：为数据库文件设计合理的物理存储位置和为基本表设计索引。在SQL Server中，可以利用CREATE DATABASE和CREATE TABLE创建数据库文件和基本表，并可将数据库文件分布到不同的磁盘上。

①索引设计的原则

a．对于经常需要进行查询、连接、统计操作，且数据量大的基本表可考虑建立索引；而对于经常执行插入、删除、更新操作或小数据量的基本表应尽量避免建立索引。

b．一个基本表上除了可以建立一个聚集索引外，还可以建立多个非聚集索引。多个索引为用户提供了根据多个查找码快速访问文件的手段。但是索引越多，对表内数据更新时为维护索引所需的开销就越大。因此，对于一个更新频繁的表应少建或不建索引。

c．索引可以由用户根据需要随时创建或删除，以提高数据查询性能。例如，对表进行大批量数据插入和更新时，可以先删除索引，以保证插入、更新操作的系统响应时间，因为在数据插入或更新过程中维护索引需要花费很大代价。数据插入或更新完成后再重建索引，以加快查询和统计等操作的系统响应时间。

②基本表可建立索引的属性

a．表的主码（大部分关系数据库管理系统会自动为主码建立唯一索引）。

b．在WHERE查询子句中引用率较高的属性。

c．参与连接操作的属性。

d．在Order By子句、Group By子句中出现的属性。

e．在某一范围内频繁搜索的属性，但只有当使用索引的查询其结果不超过记录总数的20％时索引才会有明显的效果。

f．如果在WHERE子句中同时包含一个表中的多个属性，则可以考虑在这些属性上建立多属性索引。此外，如果数据库文件需要频繁执行精确匹配查询（如等值查询），则可考虑建立散列索引。而B+树等有序索引更适合于范围查询。

g．当一个属性有相对较多的不同值时，使用索引有明显的作用；当一个属性的不同值很少时，使用索引没有好处。

h．对包含大量空值的属性建立索引时要仔细考虑，因为很多数据库管理系统中的索引不引用具有空值的行，对空值的查找需要使用全表扫描来实现。

（6）数据分布设计

①不同类型数据的物理分布

a．数据库系统中的各个类型的数据应根据实际使用情况存放在合适的物理介质上，以优化系统I/O性能。

b．数据库备份数据、日志文件备份数据用于故障恢复，使用频率低，而且数据量很大，可以存储在磁带中。而应用数据、索引和日志则使用频繁，要求的响应时间短，必须存放在支持直接存取的磁盘存储介质上。

c．当系统采用RAID等多磁盘存储系统时，可以将基本表和建立在表上的索引分别放在不同的磁盘上。这样在访问基本表时，存放数据和存放索引的磁盘驱动器并行工作，可以得到较快的文件读写速度；类似地，日志文件与数据库对象（表、索引等）也可分别存放在不同磁盘上以改善系统I/O性能。

②应用数据的划分与分布

实际数据库中有可能存在一些非常大的基本表。这些表的属性很多，表中的元组也非常多。为改善对这类大数据量基本表的访问性能，可将基本表划分为若干分区，各分区数据分别存储在不同位置的磁盘上，并可采用不同的物理组织方式。对基本表的划分可以依据以下不同原则：

a．根据数据的使用特征划分

例如，如果一个基本表中有部分数据被频繁查询，并且要求查询响应速度快，则可以将基本表分为频繁使用分区和非频繁使用分区，分别存储在不同磁盘上。对频繁使用分区中的数据可考虑建立B+树等多层索引，以提高数据访问速度；而对非频繁使用分区中的数据可以不建或只建立单层索引。从提高数据访问速度角度，可以将一个大的基本表划分为多个分区，每个分区作为一个数据文件分别存储在不同的磁盘上。对基本表的访问可以通过对分布在各磁盘上的数据文件的并行访问来实现。

b．根据时间、地点划分

例如，对商品可以按照商品的生产年份进行分区，生产年份相同的商品属于同一分区；或者按照商品生产厂商所在省份分区。

c．分布式数据库系统（DDBS）中的数据划分

DDBS采用水平划分或垂直划分两种方法，将基本表分为若干分区，并可根据需要为分区设计合适的副本。然后将各分区及其副本分别存储在不同的系统站点上，不同的分区可以有公共数据。数据划分和分布的原则是数据应靠近其使用者，以降低查询过程中的数据传输代价，提高数据访问响应速度，并且通过副本冗余机制提高数据的可靠性。

第一，水平划分

水平划分将一张基本表划分为多张具有相同属性、结构完全相同的子表，子表包含的元组是基本表中元组的子集。各子表可以有公共元组，也可以分别包含完全不同的元组。

**如对商品按照商品的生产年份进行划分就属于水平划分。**

第二，垂直划分

垂直划分则是将一张基本表划分为多张子表。每张子表包含的属性是原基本表的子集。例如，基本表Table\_Goods可以垂直划分为两张子表：

Table1\_Goods（**GoodsID,**GoodsClassID,GoodsName,ProductionDate,SaleUnitPrice）

Table2\_Goods（**GoodsID,T**otalStorage,Description）

相对于是将多个属性指标进行了拆分，总表的结构属性没有发生改变

③派生属性数据分布

a．概述

基本表中的派生属性是指该属性的取值可根据表中其他属性的取值唯一确定。

例如，如图3-18（a）所示，对“顾客”基本表增加属性“年龄”（Age），得到Table\_Customer（CustomerID,CardID,Name,Sex,Age,Birthdate,IdentityCard,Address,Postcode,

Tel），则Age即为派生属性，因为它的取值可以根据属性Birthdate的值推导出来。

b．实现方式

对带有派生属性的基本表可采用如下两种实现方式：

第一种方式将派生属性作为基本表中单独的一列，称为派生列。这种方式允许用户用select语句直接查询顾客的Age属性。

第二种方式是派生属性不出现在基本表中，如图3\-18（b）所示。这种方式节省了基本表的存储空间，并且当年份发生变化时无需更新派生属性Age的值。但当用户查询某个顾客的Age属性时必须用如下的查询语句：

<table> 
 <tbody> 
 <tr> 
 <td style="border-color:#000000;vertical-align:top;width:74.15pt;"> FcustomerID </td> 
 <td style="border-color:#000000;vertical-align:top;width:72pt;"> Name </td> 
 <td style="border-color:#000000;vertical-align:top;width:72.45pt;"> Sex </td> 
 <td style="border-color:#000000;vertical-align:top;width:72pt;"> … </td> 
 <td style="border-color:#000000;vertical-align:top;width:72pt;"> Birthdate </td> 
 <td style="border-color:#000000;vertical-align:top;width:68.65pt;"> Age </td> 
 </tr> 
 <tr> 
 <td style="border-color:#000000;vertical-align:top;width:74.15pt;"> 1072 </td> 
 <td style="vertical-align:top;width:72pt;"> John </td> 
 <td style="vertical-align:top;width:72.45pt;"> male </td> 
 <td style="vertical-align:top;width:72pt;"> … </td> 
 <td style="vertical-align:top;width:72pt;"> 1973/02/11 </td> 
 <td style="vertical-align:top;width:68.65pt;"> 35 </td> 
 </tr> 
 <tr> 
 <td style="border-color:#000000;vertical-align:top;width:74.15pt;"> 1546 </td> 
 <td style="vertical-align:top;width:72pt;"> Mary </td> 
 <td style="vertical-align:top;width:72.45pt;"> female </td> 
 <td style="vertical-align:top;width:72pt;"> … </td> 
 <td style="vertical-align:top;width:72pt;"> 2000/12/04 </td> 
 <td style="vertical-align:top;width:68.65pt;"> 7 </td> 
 </tr> 
 <tr> 
 <td style="border-color:#000000;vertical-align:top;width:74.15pt;"> 2039 </td> 
 <td style="vertical-align:top;width:72pt;"> Jones </td> 
 <td style="vertical-align:top;width:72.45pt;"> male </td> 
 <td style="vertical-align:top;width:72pt;"> … </td> 
 <td style="vertical-align:top;width:72pt;"> 1982/06/10 </td> 
 <td style="vertical-align:top;width:68.65pt;"> 25 </td> 
 </tr> 
 </tbody> 
</table>

（a）

<table> 
 <tbody> 
 <tr> 
 <td style="border-color:#000000;vertical-align:top;width:71.25pt;"> CustomerID </td> 
 <td style="border-color:#000000;vertical-align:top;width:72.5pt;"> Name </td> 
 <td style="border-color:#000000;vertical-align:top;width:72pt;"> Sex </td> 
 <td style="border-color:#000000;vertical-align:top;width:72.45pt;"> … </td> 
 <td style="border-color:#000000;vertical-align:top;width:71.55pt;"> Birthdate </td> 
 </tr> 
 <tr> 
 <td style="border-color:#000000;vertical-align:top;width:71.25pt;"> 1072 </td> 
 <td style="vertical-align:top;width:72.5pt;"> John </td> 
 <td style="vertical-align:top;width:72pt;"> male </td> 
 <td style="vertical-align:top;width:72.45pt;"> … </td> 
 <td style="vertical-align:top;width:71.55pt;"> 1973/02/11 </td> 
 </tr> 
 <tr> 
 <td style="border-color:#000000;vertical-align:top;width:71.25pt;"> 1546 </td> 
 <td style="vertical-align:top;width:72.5pt;"> Mary </td> 
 <td style="vertical-align:top;width:72pt;"> female </td> 
 <td style="vertical-align:top;width:72.45pt;"> … </td> 
 <td style="vertical-align:top;width:71.55pt;"> 2000/12/04 </td> 
 </tr> 
 <tr> 
 <td style="border-color:#000000;vertical-align:top;width:71.25pt;"> 2039 </td> 
 <td style="vertical-align:top;width:72.5pt;"> Jones </td> 
 <td style="vertical-align:top;width:72pt;"> male </td> 
 <td style="vertical-align:top;width:72.45pt;"> … </td> 
 <td style="vertical-align:top;width:71.55pt;"> 1982/06/10 </td> 
 </tr> 
 </tbody> 
</table>

（b）

当派生属性与它所依赖的属性间的计算关系较为复杂，或当用户经常需要对派生属性进行查询时，为提高查询效率，可以采用第一种方法，将派生属性的数据直接存储在关系表中，并且利用触发器等机制随时更新派生属性的值。

④关系模式的去规范化

在数据库逻辑设计阶段，由ER图转换得到的关系模式必须经过规范化处理，以避免关系表使用过程中出现插入异常、删除异常、更新异常和数据冗余等问题。经过规范化处理后，关系应达到一定的规范化程度，如满足第三范式。关系模式规范化过程实质上是将一个关系模式分解为满足更高一级的范式要求的一系列子模式。

在数据库物理设计阶段，可以根据实际需要对数据库中某些3NF、BCNF模式考虑是否可以降低其规范化程度，以提高查询效率，这称为关系模式的去规范化处理。但不满足3NF的关系模式有可能导致数据库访问异常。因此，在设计基本表时，需要在模式规范化与查询效率之间折中权衡。

【真题演练】

如果关系模式设计不当，则有可能引起数据删除异常。这种删除异常是指（ ）。

A．两个事务同时对同一个关系进行删除而造成数据库不一致

B．**由于删除关系中的元组而造成有用信息无法作为一个元组在数据库中存在**

C．未经授权的用户对关系进行了删除

D．如果删除操作违反了完整性约束条件则会被拒绝

【答案】B

### 考点5　其他物理设计环节 ###

（1）确定系统配置

①数据库系统配置参数的种类

数据库配置参数（如允许同时使用数据库的用户数、允许同时打开数据库对象数、数据库初始空间大小），磁盘块使用参数，内存缓冲区参数（如缓冲区个数和大小），时间片大小，装填因子，锁的数目等。

②配置合理参数的意义

合理的参数设置可以提高数据库的存储和查询效率，不合理的参数设置不仅会严重影响数据库的存储和查询效率，甚至可能导致系统运行时的数据库崩溃。存储分配参数的种类和合理的参数取值与具体的DBMS以及操作系统平台密切相关，同时依赖于具体的应用场景。数据库物理设计时设计人员对系统配置参数的设置和调整只是初步的。在系统运行时如果发现系统性能没有达到预期要求，而且原因与某些配置参数设置不当有关，那么需要DBA根据系统实际运行情况调整相关参数，以期改进系统性能：这属于数据库系统运行维护工作中的参数调整范畴。

（2）物理模式评估

前述各个步骤的设计结果定义了目标数据库的物理结构，组成了数据库内模式（或物理模式）。在设计过程中，通过对时间效率、空间效率、维护代价和各种用户要求权衡考虑，可能会产生多个设计备选方案，因此数据库设计人员必须对这些方案进行仔细评估，从中选择一个合理而且较优的方案作为数据库的物理结构。

评价物理数据库的方法完全依赖于所选用的DBMS，主要是从定量估算各种方案的存储空间、存取时间和维护代价入手，对估算结果进行权衡和比较，选择出一个较优的合理的物理结构。如果该结构不符合用户需求，则需要改进设计。

### 每文一语 ###

> 所谓只有，不是随心所欲，而是自我主宰