详写数据库需求分析

本篇文章通过上课讲解，网上资料总结而成

需求分析 一、数据库系统设计概述  1.数据库系统设计的内容1>数据库的结构特性设计2>数据库的行为特性设计3>数据库的物理模式设计    2.应注意的问题  3.基本方法  4.基本步骤 二、系统需求分析  1.概述   2.基本步骤   3.主要任务  4.抽象系统概貌  5.常用的数据建模方法1>DFD方法2>IDEF0方法3>UML方法   6.数据字典1>数据项2> 数据结构3>数据流4> 数据存储5>处理过程6>小结 三、数据库概念结构的设计  1.概述  2.基本步骤  3.特点  4.步骤   5.数据抽象与局部视图设计1．三种数据抽象方法   6.E-R图  7.视图1．合并分E-R图，生成初步E-R图2．消除不必要的冗余，设计基本E-R图 四、数据库逻辑结构的设计  1.概述  2.基本步骤   3.范式1>第一范式2>第二范式3>第三范式4>BC范式5>范式之间的关系    4.E-R图向关系模型的转换   5.数据模型的优化   6.设计用户子模式 五、数据库物理结构的设计  1.概述  2.基本步骤  3、关系模式存取方法选择1.B+树索引和hash索引2. 聚簇存取方法的选择   4、确定数据库的存储结构  5、评价物理结构 六、数据库实施  1.概述  2.步骤以及详细描述1>定义数据库结构2>数据的载人3>应用程序的编码与调试4>数据库的试运行 七、数据库运行维护   1.概述   2、数据库运行维护基本工作   3、运行状态监控与分析   4、 数据库存储空间管理   5、 数据库运行环境与参数调整1）外部调整:2） 调整内存分配3）调整磁盘I/O:响应时间的最大组成部分。4）调整竞争:

Date date = new Date(); System.out.println(date); //当前时间为2023-4-4 19:00;

一、数据库系统设计概述   1.数据库系统设计的内容

  数据库系统设计的目标是：对于给定的应用环境，建立一个性能良好的、能满足不同用户使用要求的、又能被选定的DBMS所接受的数据库系统模式。按照该数据库系统模式建立的数据库系统，应当能够完整地反映现实世界中信息及信息之间的联系；能够有效地进行数据存储；能够方便地执行各种数据检索和处理操作；并且有利于进行数据维护和数据控制管理的工作。   数据库系统设计的内容主要有：数据库的结构特性设计、数据库的行为特性设计、数据库的物理模式设计。   在数据库系统设计过程中，数据库结构特性的设计起着关键作用，行为特性设计起着辅助作用。将数据库的结构特性设计和行为特性设计结合起来，相互参照，同步进行，才能较好地达到设计目标。

1>数据库的结构特性设计

  数据库的结构特性是指数据库的逻辑结构特征。由于数据库的结构特性是静态的，一般情况下不会轻易变动，因此数据库的结构特性设计又称为数据库的静态结构设计。   数据库的结构特性设计过程是：先将现实世界中的事物、事物间的联系用E-R图表示，再将各个分E-R图汇总，得出数据库的概念结构模型，最后将概念结构模型转化为数据库的逻辑结构模型表示。

2>数据库的行为特性设计

  数据库的行为特性设计是指确定数据库用户的行为和动作，并设计出数据库应用系统的系统层次结构、功能结构和系统数据流程图，确定数据库的子模式。数据库用户的行为和动作是指数据查询和统计、事物处理及报表处理等操作，这些都要通过应用程序表达和执行。由于用户行为总是更新数据库内容的存取数据操作，用户行为特性是动态的，所以数据库的行为特性设计也称为数据库的动态特性设计。   数据库行为特性的设计步骤是：将现实世界中的数据及应用情况用数据流程图和数据字典表示，并详细描述其中的数据操作要求（即操作对象、方法、频度和实时性要求）；确定选和系统层次结构；确定系统的功能模块结构；确定数据库的子模式；确定系统数据流程图。

3>数据库的物理模式设计

  数据库的物理模式设计要求：根据库结构的动态特性（即数据库应用处理要求），在定的DBMS环境下，把数据库的逻辑结构模型加以物理实现，从而得出数据库的存储模式存取方法。

   2.应注意的问题

  数据库系统设计时应使结构特性设计和行为特性设计紧密结合。数据库设计过程是一种自上而下的、逐步逼近设计目标的过程。数据库设计过程是结构设计和行为设计分离设计、相互参照、反复探寻的过程。

  3.基本方法

  数据库设计应分6个阶段进行：     需求分析     概念结构设计     逻辑结构设计     物理结构设计     数据库实施     数据库运行与维护   在数据库设计的不同阶段上，实现的具体方法有基于E-R模型的数据库设计方法、基于3NF（第3范式）的设计方法、基于抽象语法规范的设计方法等。

  4.基本步骤

二、系统需求分析   1.概述

  需求分析是数据库设计的第一步，也是最困难、最耗时间的一步。需求分析的任务是准确了解并分析用户对系统的需要和要求，弄清系统要达到的目标和实现的功能。需求分析是否做得充分与准确，决定着在其上构建数据库大厦的速度与质量。如果需求分析做不好，会影响整个系统的性能，甚至会导致整个数据库设计返工。   数据库应用系统的需求分析包括数据需求分析、功能需求分析(数据处理需求分析、业务规则需求分析)、性能需求分析(数据操作响应时间或数据访问响应时间、系统吞吐量、允许并发访问的最大用户数、每秒TPS代价值)、其他需求分析(存储需求分析、安全性需求分析、备份和恢复需求分析)。   ①数据处理需求分析:从对数据组织与存储的设计角度，辨识应用领域所管理的各类数据项和数据结构，与数据处理需求分析结果一 起，组成数据字典，形成数据规范说明书”。   ②功能需求分析:功能需求分析主要针对DBAS应具有的功能进行分析，是DBAS需求分析的核心环节，总体上可分为数据处理需求分析与业务规则需求分析。数据处理需求分析从数据访问和处理的角度,明确对各数据项所需要进行的数据访问操作。在系统规划与分析阶段，DBAS开发者已经明确了各类用户视图。因此数据处理需求分析阶段可以从这些视图出发，   ③性能需求分析:性能需求则描述了系统应当做到什么程度，分析DBAS应具有的性能指标。   ④其他需求分析包括:存储需求、安全性需求等。     a.存储需求分析:存储需求分析是指估计DBAS系统需要的数据存储量，如DB所存储的数据总量。     b.安全需求分析:主要用于数据库安全设计，避免被非法使用和攻击。

   2.基本步骤

  设计者的中心工作是弄清并综合各个用户的应用需求；

   3.主要任务

  详细调查现实世界要处理的对象（组织、部门、企业等）；充分了解原系统（手工系统或计算机系统）的概况和发展前景；明确用户的各种需求；收集支持系统目标的基础数据及其处理方法；确定新系统的功能和边界。

  4.抽象系统概貌

  5.常用的数据建模方法 1>DFD方法

  数据流图(Data Flow Diagram,简称DFD)是便于用户理解系统数据流程的图形表示。DFD建模方法的核心是数据流，它能精确地在逻辑上描述系统的功能、输入、输出和数据存储等，从而摆脱了其物理内容。数据流图是系统逻辑模型的重要组成部分。   DFD的主要组成包括外部实体(外部项)、处理过程、数据存储和数据流。外部实体指系统之外又和系统有联系的人或者事物，说明了数据的外部来源和去处。处理指对数据逻辑处理，也就是数据变换，它用来改变数据值。数据流是指处理功能的输入输出数据存储表示数据保存的地方，它用来存储数据。   在DFD建模方法中，数据流用箭头表示，处理用矩形框表示，数据存储用圆角矩形框表示，外部项用圆角框或 者平行四边形框表示。   数据流程图表达了数据和处理过程之间的关系。在结构化分析方法中，处理过程的处理逻辑常常用判定表或判定树来描述。   DFD特性:   ①抽象性:在DFD中具体的组织机构、工作场所、物质流等都已经去掉，只剩下信息和数据存储、流动、使用以及加工的情 况。所以描述的是抽象出来的数据。

  ②概括性:它把系统对各种业务的处理过程联系起来考虑，形成一个总体，可反映出数据流之间的概括情况。

2>IDEF0方法

1.IDEF方法   是70年代提出的结构化分析方法基础上发展起来的   IDEF0:描述系统的功能活动及其联系   IDEF1:描述系统信息及其联系，建立信息模型作为数据库设计的依据   IDEF2:用于系统模拟，建立动态模型 2.IDEF大家族 3.IDEF0详解   用于系统的需求处理和结构关系的功能定义，IDEF0能同时表达系统的活动（用盒子表述）和数据流（用箭头表示）以及它们之间的联系，IDEF0被称为“Static Model”，是一种图形化方法，采用的是层次分解，逐步细化的结构树描述系统。 4.IDEF0控制图 IDEF0是活动模型(ICAM DEF inition Method)的缩写，来源于结构化分析与设计技术的一套标准,这些标准包含多种层次的图形语言。输入(Input)箭头表示完成特定活动所需的数据，置于矩形框的左侧;输出(Output)箭头说明由活动产生的结果及信息，置于矩形框的右侧;控制(Control) 箭头描述了影响这个活动执行的事件或约束条件，置于矩形框的上方;机制(Mechanisms) 箭头表示实施该活动的物理手段或完成活动需要的资源(计算机系统、人或组织)，置于矩形框的下方。

3>UML方法

  UML-Unified Modeling Language 统一建模语言，又称标准建模语言。是用来对软件密集系统进行可视化建模的一种语言。UML的定义包括UML语义和UML表示法两个元素。   UML是在开发阶段，说明、可视化、构建和书写一个面向对象软件密集系统的制品的开放方法。最佳的应用是工程实践，对大规模，复杂系统进行建模方面，特别是在软件架构层次，已经被验证有效。统一建模语言（UML）是一种模型化语言。模型大多以图表的方式表现出来。一份典型的建模图表通常包含几个块或框，连接线和作为模型附加信息之用的文本。这些虽简单却非常重要，在UML规则中相互联系和扩展。

参考软件工程导论这里不做细

  6.数据字典

  数据字典是各类数据描述的集合，它是进行详细的数据收集和数据分析后所获得的主要成果。数据字典在数据库设计中占有很重要的地位。数据字典通常包括以下5个部分。

1>数据项

  数据项是不可再分的数据单位。它的描述为：   数据项＝{数据项名，含义说明，别名，类型，长度，取值范围，与其他数据项的逻辑关系}。   其中：“取值范围”和“与其他数据项的逻辑关系”两项定义了数据的完整性约束条件，它们是设计数据完整性检验功能的依据。

2> 数据结构

  数据结构的描述为：   数据结构＝{数据结构名，含义说明，组成，{数据项或数据结构}}。   数据结构反映了数据之间的组合关系。一个数据结构可以由若干个数据项组成，也可以由若干个数据结构组成，或由若干数据项和数据结构混合组成。

3>数据流

  数据流是数据结构在系统内传输的路径。数据流的描述通常为：   数据流 ={数据流名，说明，流出过程，流入过程，组成：{数据结构}，平均流量，高峰期流量}。   其中，“流出过程”说明该数据流来自哪个过程；“流入过程”说明该数据流将到哪个过程去；“平均流量”是指在单位时间（每天、每周、每月等）里传输的次数；“高峰期流量”则是指在高峰时期的数据流量。   数据流是数据结构在系统内传输的路径。数据流的描述通常为：   数据流 ={数据流名，说明，流出过程，流入过程，组成：{数据结构}，平均流量，高峰期流量}。   其中，“流出过程”说明该数据流来自哪个过程；“流入过程”说明该数据流将到哪个过程去；“平均流量”是指在单位时间（每天、每周、每月等）里传输的次数；“高峰期流量”则是指在高峰时期的数据流量。

4> 数据存储

  数据存储是数据及其结构停留或保存的地方，也是数据流的来源和去向之一。数据存储可以是手工文档、手工凭单或计算机文档。数据存储的描述通常为：   数据存储 ＝{数据存储名，说明，编号，输入的数据流，输出的数据流，组成：{数据结构}，数据量，存取频度，存取方式}。   其中：“数据量”说明每次存取多少数据；“存取频度”指每小时或每天或每周存取几次、每次存取多少数据等信息；“存取方式”指是批处理还是联机处理，是检索还是更新，是顺序检索还是随机检索等；“输入的数据流”要指出其数据的来源处；“输出的数据流”要指出其数据去向处。

5>处理过程

  处理过程的具体处理逻辑一般用判定表或判定树来描述。数据字典中只需要描述处理过程的说明性信息，通常包括以下内容：   处理过程＝{处理过程名，说明，输入：{数据流}，输出：{数据流}，处理：{简要说明}}。   其中：“简要说明”中主要说明该处理过程用来做什么（不是怎么做）及处理频度要求，如单位时间里处理多少事务、多少数据量、响应时间要求等。

6>小结

  数据字典是关于数据库中数据的描述，即对元数据的描述。数据字典是在需求分析阶段建立，在数据库设计过程中不断修改、充实、完善的。   需求和分析阶段收集到的基础数据用数据字典和一组数据流程图（Data Flow Diagram , 简称DFD）表达，它们是下一步进行概念设计的基础。数据字典能够对系统数据的各个层次和各个方面进行精确和详尽的描述，并且把数据和处理有机地结合起来，可以使概念结构的设计变得相对容易。

三、数据库概念结构的设计   1.概述

 &emsp概念结构设计是整个数据库设计的关键。在概念结构的设计过程中，设计者要对用户需求进行综合、归纳和抽象，形成一个独立于具体计算机和DBMS的概念模型。

  2.基本步骤

  设计者要将应用需求转换为与计算机硬件无关的、与各个数据库管理系统产品无关的概念模型（即E-R图）；

  3.特点

  概念结构独立于数据库逻辑结构和支持数据库的DBMS，其主要特点如下。

1）概念模型是现实世界的一个真实模型：概念模型应能真实、充分地反映现实世界，能满足用户对数据的处理要求。2）概念模型应当易于理解：概念模型只有被用户理解后，才可以与设计者交换意见，参与数据库的设计。3）概念模型应当易于更改：由于现实世界（应用环境和应用要求）会发生变化，这就需要改变概念模型，易于更改的概念模型有利于修改和扩充。4）概念模型应易于向数据模型转换：概念模型最终要转换为数据模型。设计概念模型时应当注意，使其有利于向特定的数据模型转换。   4.步骤

  概念结构的设计可分为两步：

第一步是抽象数据，并设计局部视图；第二步是集成局部视图，得到全局的概念结构。    5.数据抽象与局部视图设计

  概念结构是对现实世界的一种抽象。所谓抽象是对实际的人、物、事和概念进行人为处理，抽取所关心的共同特性，忽略非本质的细节，并把这些特性用各种概念精确地加以描述，这些概念组成了某种模型。

1．三种数据抽象方法

⑴ 分类 (Classification)   定义某一类概念作为现实世界中一组对象的类型，这些对象具有某些共同的特性和行为。分类抽象了对象值和型之间的“成员”的语义。在E-R模型中，实体集就是这种抽象。 ⑵ 聚集 (Aggregation)   定义某一类型的组成部分，它抽象了对象内部类型和对象内部“组成部分”的语义。若干属性的聚集组成了实体型。 ⑶ 概括 (Generalization)   定义了类型之间的一种子集联系，它抽象了类型之间的“所属”的语义。例如，学生是一个实体型，本科生、研究生也是实体型。本科生、研究生均是学生的子集。把学生超类( Superclass )，本科生、研究生称为学生的子类( Subclass)。   在E-R模型中用双竖边的矩形框表示子类，用直线加小圆圈表示超类­-子类的联系。    概括的一个重要性质是继承性。继承性指子类继承超类中定义的所有抽象。

  6.E-R图

概念结构设计是利用抽象机制对需求分析阶段收集到的数据进行分类、组织（聚集），形成实体集、属性和码，确定实体集之间的联系类型（一对一、一对多或多对多的联系），进而设计分E-R图。 ⑴ 设计分E-R图的具体做法

1）选择局部应用。选择局部应用是根据系统的具体情况，在多层的数据流程图中选择一个适当层次的数据流程图，作为设计分E-R图的出发点，并让数据流程图中的每一部分都对应一个局部应用。选择好局部应用之后，就可以对每个局部应用逐一设计分E-R图了。2）设计分E-R图。在设计分E-R图前，局部应用的数据流程图应已经设计好，局部应用所涉及的数据应当也已经收集在相应的数据字典中了。在设计分E-R图时，要根据局部应用的数据流程图中标定的实体集、属性和码，并结合数据字典中的相关描述内容，确定E-R图中的实体、实体之间的联系。   7.视图

  各子系统的局部E-R图设计好以后，下一步就是要将所有的局部E-R图综合成一个系统的总E-R图。一般说来，视图集成可以有两种方式：

多个局部E-R图一次集成。逐步集成，用累加的方式一次集成两个局部E-R图。

  第一种方法比较复杂，做起来难度较大。   第二种方法每次只集成两个局部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图的冲突是合并局部E-R图的主要工作与关键所在。   ⑴ 属性冲突   ① 属性域冲突，即属性值的类型、取值范围或取值集合不同。例如零件号，有的部门把它定义为整数，有的部门把它定义为字符型。不同的部门对零件号的编码也不同。又如年龄，某些部门以出生日期形式表示职工的年龄，而另一些部门用整数表示职工的年龄。   ② 属性取值单位冲突。例如，零件的重量有的以公斤为单位，有的以斤为单位，有的以克为单位。   ③ 属性冲突理论上好解决，但实际上需要各部门讨论协商，解决起来并非易事。   ⑵ 命名冲突   ① 同名异义，即不同意义的对象在不同的局部应用中具有相同的名字。   ② 异名同义（一义多名），即同一意义的对象在不同的局部应用中具有不同的名字。如对科研项目，财务科称为项目，科研处称为课题，生产管理处称为工程。   命名冲突可能发生在实体、联系一级上，也可能发生在属性一级上。其中属性的命名冲突更为常见。处理命名冲突通常也像处理属性冲突一样，需要通过讨论、协商等行政手段加以解决。   ⑶ 结构冲突   ① 同一对象在不同应用中具有不同的抽象。例如，职工在某一局部应用中被当作实体，而在另一局部应用中则被当作属性。   解决方法通常是把属性变换为实体或把实体变换为属性，使同一对象具有相同的抽象。   ② 同一实体在不同局部E-R图中所包含的属性个数和属性排列次序不完全相同。   解决方法是根据应用的语义对实体联系的类型进行综合或调整。

2．消除不必要的冗余，设计基本E-R图

  在初步E-R图中，可能存在一些冗余的数据和实体间冗余的联系。所谓冗余的数据是指可由基本数据导出的数据，冗余的联系是指可由其他联系导出的联系。冗余数据和冗余联系容易破坏数据库的完整性，给数据库维护增加困难，应当予以消除。消除了冗余后的初步 E-R图称为基本E-R图。   消除冗余主要采用分析方法，即以数据字典和数据流图为依据，根据数据字典中关于数据项之间逻辑关系的说明来消除冗余。   但并不是所有的冗余数据与冗余联系都必须加以消除，有时为了提高效率，不得不以冗余信息作为代价。因此在设计数据库概念结构时，哪些冗余信息必须消除，哪些冗余信息允许存在，需要根据用户的整体需求来确定。如果人为地保留了一些冗余数据，则应把数据字典中数据关联的说明作为完整性约束条件。

四、数据库逻辑结构的设计   1.概述

  数据逻辑结构设计的主要任务是将概念结构转换为某个DBMS所支持的数据模型，并将其性能进行优化。

  2.基本步骤

  要完成数据库的逻辑模式和外模式的设计工作，即系统设计者要先将E-R图转换成具体的数据库产品支持的数据模型，形成数据库逻辑模式，然后根据用户处理的要求、安全性的考虑建立必要的数据视图，形成数据的外模式； ( 1 ) 将概念结构转换为一般的关系、网状、层次模型； ( 2 ) 将转换来的关系、网状、层次模型向指定数据库管理系统支持的数据模型转换； ( 3 ) 对数据模型进行优化。

   3.范式 1>第一范式

  定义：数据库表中的所有字段都是单一属性，不可再分的。这个单一属性是由基本的数据类型所构成的，如整数，浮点数，字符串等，换句话说，第一范式要求数据库中的表都是二维表。(二维表就是由行和列组成的表)

2>第二范式

  定义：数据库的表中不存在非关键字段对任一候选关键字段的部分函数依赖。   部分函数依赖是指存在着组合关键字中的某一关键字决定非关键字的情况。   换句话说：所有单关键字的表都符合第二范式。

3>第三范式

  定义：第三范式是在第二范式的基础上定义的，如果数据表中不存在非关键字段，对任意候选关键字段的传递函数依赖则符合第三范式。

4>BC范式

  定义：在第三范式的基础上，数据库表中如果不存在任何字段对任一候选关键字段的传递函数依赖则符合BC范式。也就是说如果是复合关键字，则复合关键字之间也不能存在函数依赖关系

5>范式之间的关系

   4.E-R图向关系模型的转换

  转换规则  1) 一个实体型转换为一个关系模式  一般E-R图中的一个实体转换为一个关系模式，实体的属性就是关系的属性，实体的码就是关系的码。 2) 一个1:1联系可以转换为一个独立的关系模式，也可以与任意一端对应的关系模式合并。 3) 一个1:n联系可以转换为一个独立的关系模式，也可以与n端对应的关系模式合并。 4) 一个m:n联系可以转换为一个独立的关系模式。  5) 一个多元联系可以转换为一个独立的关系模式。 6) 具有相同码的关系模式可以合并。 7) 有些1：n的联系，将属性合并到n端后，该属性也作为主码的一部分

   5.数据模型的优化

   有了关系模型，可以进一步优化，方法为： 1).确定数据依赖。 2).对数据依赖进行极小化处理，消除冗余联系（参看范式理论）。 3).确定范式级别，根据应用环境，对某些模式进行合并或分解。 4).对关系模式进行必要的分解。 1.2.3.工作理论性比较强，主要目的是设计一个数据冗余尽量少的关系模式。 4.考虑效率问题了。   对关系模式进行必要的分解。如果一个关系模式的属性特别多，就应该考虑是否可以对这个关系进行垂直分解。如果有些属性是经常访问的，而有些属性是很少访问的，则应该把它们分解为两个关系模式。   如果一个关系的数据量特别大，就应该考虑是否可以进行水平分解。

   6.设计用户子模式

  这部分主要是考虑使用方便性和效率问题，主要借助视图手段实现 1)建立视图，使用更符合用户习惯的别名。 2)对不同级别的用户定义不同的视图，以保证系统的安全性。 3)对复杂的查询操作，可以定义视图，简化用户对系统的使用。

五、数据库物理结构的设计   1.概述

  数据库物理结构设计的主要任务是为逻辑数据模型选取一个最适合应用环境的物理结构，包括数据存储位置、数据存储结构和存取方法。

  2.基本步骤

  数据库上运行的各种事务响应时间小、存储空间利用率高、事务吞吐率大，首先对要进行的事务进行详细分析，获得选择物理数据库设计所需要的参数；其次，要充分了解所用关系数据库管理系统的内部特征，特别是系统所提供的存取方法和存取结构。   以下是确定关系的存取方法的依据：

对于数据库查询事务，需要得到：查询的关系，查询条件所涉及的属性，连接条件所涉及的属性，查询的投影属性。对于数据更新事务，需要得到：被更新的关系，每个关系上的更新操作条件所涉及的属性，修改操作要改变的属性值。除此之外，还需要制定每个事务在各关系上运行的频率和性能要求。

  通常关系数据库物理设计的内容主要包括为关系模式选择存取方法，以及设计关系、索引等数据库文件的物理存储结构。

  3、关系模式存取方法选择

  数据库系统是多用户共享的系统，对同一个关系要简历多条存取路径才能满足多用户的多种应用要求。物理结构设计的任务之一是根据关系数据库管理系统支持的存取方法确定选择哪些存取方法。   存取方法是快速存取数据库中数据的技术。数据库管理系统一般提供索引方法和聚簇方法。

1.B+树索引和hash索引

B+树索引存取方法的选择 所谓选择索引存取方法，实际上就是根据应用要求确定对关系的那些属性列建立索引、哪些属性列建立组合索引、哪些索引要设计唯一索引。

1）如果一个（或一组）属性经常在查询条件中出现，则考虑在这个（或这组）属性上建立索引（或组合索引）。2）如果一个属性经常作为最大值和最小值等聚集函数的参数，则考虑在这个属性上建立索引。3）如果一个（或一组）属性经常在连接操作的连接条件中出现，则考虑在这个（或这组）属性上建立索引。

hash索引存取方法的选择   选择hash存取方法的规则：如果一个关系的属性主要出现在等值连接条件中或主要出现在等值比较选择条件中，而且满足下列两个条件之一，则此关系可以选择hash存取方法。 1）一个关系的大小可预知，而且不变。 2）关系的大小动态改变，但数据库管理系统提供了动态hash存取方法。

2. 聚簇存取方法的选择

  为了提高某个属性（或属性组）的查询速度，把这个或这些属性上具有相同值的元组集中存放在连续的物理块中称为聚簇。该属性（或属性组）称为聚簇码。   聚簇功能可以大大提高按聚簇码进行查询的效率。   聚簇功能不单适用于单个关系，也适用于经常进行连接操作的多个关系。即把多个连接关系的元组按连接属性值聚集存放。这就相当于把多个关系按“预连接”的形式存放，从而大大提高连接操作的效率。 一个数据库可以连接多个聚簇，一个关系只能加入一个聚簇。这样聚簇存取方法，即确定要建立多少个聚簇，每个聚簇中包括哪些关系。 首先设计候选聚簇，一般来说：

对经常在一起进行连接操作的关系可以建立聚簇。如果一个关系的一组属性经常出现在相等比较条件中，则该单个关系可建立聚簇。如果一个关系的一个（或一组）属性上的值重复率很高，则此单个关系可建立聚簇。即对应每个聚簇码值的平均元组数不能太少，太少则聚簇的效果不明显。

然后检查候选聚簇中的关系，取消其中不必要的关系

从聚簇中删除经常进行全表扫描的关系。从聚簇中删除更新操作远多于连接操作的关系。不同的聚簇中可能包含相同的关系，一个关系可以在某一个聚簇中，但不能同时加入多个聚簇。要从这多个聚簇方案（包括不建立聚簇）中选择一个较优的，即在这个聚簇上运行各种事务的总代价最小。

  聚簇只能提高某些应用的性能，而且能建立与维护聚簇的开销是相当大的。对已有关系简历聚簇将导致关系中元组移动其物理存储位置，并使此关系上原来建立的所有索引无效，必须重建。当一个元组的聚簇码值改变时，该元组的存储位置也要做相应的移动，聚簇码值要相对稳定，以减少修改聚簇码值所引起的维护开销。   当通过聚簇码进行访问或连接是该关系的主要应用，与聚簇码无关的其他访问很少或者是西药的，这时可以使用聚簇。尤其当SQL语句中包含有与聚簇码有关的ORDER BY、GROUP BY、UNION、DISTINCT等子句或短语时，使用聚簇特别有利，可以省去对结果集的排序操作。

  4、确定数据库的存储结构

  确定数据库物理结构主要指确定数据的存放位置和存储结构，包括确定关系、索引、聚簇、日志、备份等的存储安排和存储结构，确定系统配置等。   确定数据的存放位置和存储结构要综合考虑存取时间、存储空间利用率和维护代价三方面的因素。这三个方面常常是相互矛盾的，因此需要进行权衡选择一个折中方案。

确定数据的存放位置 为了提高系统性能，应根据应用情况将数据的易变部分与稳定部分、经常存取部分和存取频率较低部分分开存放。

确定系统配置 关系数据库管理系统产品一般都提供了一些系统配置变量和存储分配参数，供设计人员和数据库管理员对数据库进行物理优化。

  5、评价物理结构

数据库物理设计过程中需要对时间效、空间效率、维护代价和各种用户要求进行权衡，其结果可以产生多种方案。评价物理数据库的方法完全依赖于所选用的关系数据库管理系统，主要是从定量估算各种方案的存储空间、存取时间和维护代价入手，对估算结果进行权衡、比较，选择出一个较优的、合理的物理结构

版权