第七章 数据库设计
7.1数据库设计概述
- 数据库设计定义
数据库设计是指对于一个给定的应用环境，构造（设计）优化的数据库逻辑模式和物理结构，并据此建立数据库及其应用系统，使之能够有效地存储和管理数据，满足各种用户的应用需求，包括信息管理要求和数据操作要求。 - 信息管理要求
在数据库中应该存储和管理哪些数据对象。 - 数据操作要求
对数据对象需要进行哪些操作，如查询、增、删、改、统计等操作。 - 数据库设计的目标
为用户和各种应用系统提供一个信息基础设施和高效率的运行环境。 - 高效率的运行环境
①数据库数据的存取效率高；
②数据库存储空间的利用率高；
③数据库系统运行管理的效率高。
7.1.1数据库设计的特点
- 数据库建设的基本规律
三分技术，七分管理，十二分基础数据。
管理：数据库建设项目管理和企业（应用部门）的业务管理。
基础数据：数据的收集、整理、组织和不断更新。 - 结构（数据）设计和行为（处理）设计相结合
将数据库结构设计和数据库处理设计密切结合。
传统的软件工程：重行为设计。忽视对应用中数据语义的分析和抽象，只要有可能就尽量推迟数据结构设计的决策。
早起的数据库设计：重结构设计。致力于数据模型和数据库建模方法研究，忽视了行为设计对结构设计的影响。
7.1.2数据库设计方法
大型数据库设计是涉及多学科的综合性技术，又是一项庞大的工程项目。它要求多方面的知识和技术。主要包括：
- 计算机的基础知识；
- 软件工程的原理和方法；
- 程序设计的方法和技巧；
- 数据库的基本知识；
- 数据库设计技术；
- 应用领域的知识。
- 手工与经验结合的方法
存在的问题：
（1）设计质量与设计人员的经验和水平有直接关系。
（2）缺乏科学理论和工程方法的支持，工程的质量难以保证。
（3）数据库运行一段时间后常常又不同程度地发现各种问题，增加了维护代驾。 - 规范设计法
（1）基本思想：过程迭代和逐步求精
（2）典型方法
- 新奥尔良（New Orleans）方法
- 基于E-R模型的数据库设计方法
- 3NF（第三范式）的设计方法
- 面向对象的数据库设计方法
- 统一建模语言（UML）方法
7.1.3数据库设计的基本步骤
- 数据库设计分6个阶段
需求分析、概念结构设计、逻辑结构设计、物理结构设计、数据库实施、数据库运行和维护。
说明：
①需求分析和概念设计独立于任何数据库管理系统。
②逻辑设计和物理设计与选用的数据库管理系统密切相关。
- 参加数据库设计的人员
①系统分析人员和数据库设计人员：自始至终参与数据库设计，其水平决定了数据库系统的质量。
②数据库管理员和用户代表：要参加需求分析与数据库的运行和维护。
③应用开发人员：包括程序员和操作员，在实施阶段参与进来，分别负责编制程序和准备软硬件环境。 - 各阶段的主要任务
①需求分析阶段：了解用户需求，该阶段是否做得充分与准确，决定了构建数据库的速度和质量。
②概念结构设计阶段：对用户需求进行综合、归纳与抽象，形成一个独立于具体数据库管理系统的概念模型。
③逻辑结构设计阶段：将概念结构转换为数据库管理系统所支持的数据模型，并对其进行优化。
④物理结构设计阶段：逻辑数据结构选取一个最适合应用环境的物理结构，包括存储结构和存取方法。
⑤数据库实施阶段：根据逻辑设计和物理设计的结果构建数据库，编写与调试应用程序，组织数据入库并进行试运行。
⑥数据库运行和维护阶段：经过试运行之后即可投入正式运行，在运行过程中必须不断对其进行评估、调整与修改。
说明：
- 设计一个完善的数据库应用系统，往往是上述6个阶段的不断反复。
- 设计步骤既是数据库设计的过程，也包括了数据库应用系统的设计过程。
- 把数据库的设计和数据处理的设计紧密结合，将这两个方面的需求分析、抽象、设计、实现在各个阶段同时进行。
- 各个阶段的数据设计描述
①需求分析阶段
综合各个用户的应用需求。
②概念设计阶段
形成独立于机器特点，独立于各个数据库管理系统产品的概念模式（E-R图）。
③逻辑设计阶段
首先将E-R图转换成具体的数据库产品支持的数据模型，如关系模型，形成数据库逻辑模式。
然后根据用户处理的要求、安全性的考虑，在基本表的基础上再建立必要的视图，形成数据的外模式。
④物理设计阶段
根据数据库历系统特点和处理的需要，进行物理存储安排，建立索引，形成数据库内模式。
7.1.4数据库设计过程中的各级模式
7.2需求分析
7.2.1需求分析的任务
- 详细调查现实世界要处理的对象（组织、部门、企业等）。
- 充分了解原系统（手工系统或计算机系统）工作概况。
- 明确用户的各种需求。
- 确定新系统的功能，新系统必须充分考虑今后可能的扩充和改变。
说明：
调查的重点是“数据”和“处理”，获得用户对数据库在信息、处理、安全性与完整性的要求。
7.2.2需求分析的方法
需求分析的目的：调查清楚用户的实际需求并进行初步分析，最终与用户达成共识。
调查用户需求的步骤：
（1）调查组织机构情况。
（2）调查各部门的业务活动情况。
（3）协助用户明确对新系统的各种要求，包括信息要求、处理要求、安全性与完整性要求。
（4）确定新系统的边界。
常用的调查方法：
- 跟班作业。通过亲身参加业务工作了解业务活动的情况。
- 开调查会。通过与用户座谈来了解业务活动情况及用户需求。
- 请专人介绍。
- 询问：对某些调查中的问题，可以找专人询问。
- 设计调查表请用户填写。调查表设计合理，则很有效。
- 查阅记录。查阅与原系统有关的数据记录。
结构化分析方法（简称SA方法），SA方法从最上层的系统组织机构入手，采用自顶向下、逐层分解的方式分析系统。
7.2.3数据字典
数据字典是关于数据库中数据的描述，即元数据，不是数据本身。数据字典是在需求分析阶段建立，是进行详细大数据收集和数据分析所获得的，并在数据库设计过程中不断修改、充实、完善。
数据字典的内容：数据项、数据机构、数据流、数据存储、处理过程。
- 数据项：数据是不可再分的数据单位。
数据项描述={数据项名，数据项含义说明，别名，数据类型，长度，取值范围，取值含义，与其他数据项的逻辑关系，数据项之间的联系}
说明：
①“取值范围”、“与其他数据项的逻辑关系”定义了数据的完整性约束条件，是涉及数据检验功能的依据。
②可以用关系规范化理论为指导，用数据依赖的概念分析和表示数据项之间的联系。 - 数据结构：数据结构反映了数据之间的组合关系。
数据结构描述={数据结构名，含义说明，组成：{数据项或数据结构}}
说明：
一个数据结构可以由若干个数据项组成，也可以由若干个数据结构组成，或由若干个数据项和数据结构混合组成。 - 数据流：是数据结构在系统内传输的路径。
数据流描述={数据流名，说明，数据流来源，数据流去向，组成：{数据结构}，平均流量，高峰期流量}
说明：
①数据流来源：说明该数据流来自哪个过程。
②数据流去向：说明该数据流将到哪个过程去。
③平均流量：在单位时间（每天、每周、每月等）里的传输次数。
④高峰期流量：在高峰时期的数据流量。 - 数据存储：数据结构停留或保存的地方，也是数据流的来源和去向之一。
数据存储描述={数据存储名，说明，编号，输入的数据流，输出的数据流，组成：{数据结构}，数据量，存取频度，存取方式}
说明：
①存取频度：每小时、每天或每周存取次数，每次存取的数据量等信息。
②存取方法：批处理/联机处理；检索/更新；顺序检索/随机检索。
③输入的数据流：数据来源。
④输出的数据流：数据去向。 - 处理过程：处理过程的具体处理逻辑一般用判定表或判定树来描述。数据字典中只需要描述处理过程的说明性信息。
处理过程描述={处理过程名，说明，输入：{数据流}，输出：{数据流}，处理：{简要说明}}
说明：
“简要说明”说明该处理过程的功能及处理要求。其中功能是指该处理过程用来做什么。处理要求是指处理频度要求，如单位时间里处理多少事务，多少数据量、响应时间要求等。
需求分析小结： - 需求收集和分析作为数据库设计的第一阶段是十分重要的。
- 第一阶段收集的基础数据（用数据字典来表达）是下一步进行概念设计的基础。
- 强调两点：
- 设计人员应充分考虑到可能的扩充和改变，使设计易于更改，系统易于扩充。
- 必须强调用户的参与。
7.3概念结构设计
7.3.1概念模型
概念结构设计是将需求分析得到的用户需求抽象为信息结构（即概念模型）的过程。
概念模型的特点：
（1）能真实、充分地反映现实世界，是现实世界的一个真实模型。
（2）易于理解，可以用它和不熟悉计算机的用户交换意见。
（3）易于更改，当应用环境和应用要求改变时，容易对概念模型修改和扩充。
（4）易于向关系、网状、层次等各种数据模型转换。
概念模型的描述工具：E-R模型。
7.3.2 E-R模型
E-R模型是用E-R图来描述现实世界的概念模型。第一章1.2.2节已经简单介绍实体属性、实体之间的联系等。
- 实体之间的联系
（1）两个实体型之间的联系
一对一联系（1:1）、一对多联系（1：n）、多对多联系（m：n）。
①一对一联系（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个实体（n≥0）与之联系，反之，对于实体集B中的每一个实体，实体集A中也有m个实体（m≥0）与之联系，则称实体集A与实体集B具有多对多联系，记为m：n。
（2）两个以上的实体型之间的联系
一般地，两个以上的实体型之间也存在着一对一、一对多、多对多联系。
（3）单个实体型内的联系
同一个实体集内的各实体之间也可以存在一对一、一对多、多对多的联系。
联系的度：参与联系的实体型的数目。
2个实体型之间的联系度为2，也称为二元联系；
3个实体型之间的联系度为3，称为三元联系；
N个体型之间的联系度为N，也称为N元联系。 - E-R图
E-R图提供了表示实体型、属性和联系的方法。
实体型：用矩形表示，矩形框内写明实体名。
属性：用椭圆形表示，并用无向边将其与相应的实体型连接起来。
联系：用菱形4表示，菱形框内写明联系名，并用无向边分别与有关实体型连接起来，同时在无向边旁标上联系的类型（1:1,1:n或m:n）。联系也可以具有属性。
7.3.3扩展的E-R模型
E-R模型得到了广泛的应用，人们在基本E-R模型的基础上进行了某些方面的扩展，使其表达能力更强。
- ISA联系
用E-R方法构建一个项目的模型时，经常会遇到某些实体型是某个实体型的子集，ISA联系用三角形来表示。
说明：
ISA联系描述了一个实体型中实体的一种分类方法，其一个重要的性质是子类继承了父类的所有属性，同时子类也可有自己的属性。
（1）分类属性
根据分类属性的值把父实体型中的实体分派到子实体中。
（2）不相交约束与可重叠约束
不相交约束：父类中的一个实体不能同时属于多个子类中的实体集，即一个父类中的实体最多属于一个子类实体集。用ISA联系三角形符号内加一个“X”来表示。
可重叠约束：父类中的一个实体能同时属于多个子类中的实体集，三角形符号内没有“X”来表示。
（3）完备性约束
完备性约束：描述父类中的一个实体是否必须是某一个子类中的实体。如果是，则为完全特化，否则为部分特化。
完全特化用双线连接，部分特化用单线连接。 - 基数约束：是对实体之间一对一、一对多和多对多联系的细化。约束用一对数min…max表示，0≤min≤max。
- Part-of联系：即部分联系，表明某个实体型是另外一个实体型的一部分。
Part-of联系的分类：
（1）非独占的Part-of联系：整体实体如果被破坏，部分实体仍然可以独立存在。非独占的Part-of联系可以通过基数约束来表达。
（2）独占的Part-of联系：实体如果被破坏，部分实体不能存在。在E-R图中用弱实体类型和识别联系来表示独占联系。
如果一个实体型的存在依赖于其他实体型的存在，则这个实体型叫做弱实体型，否则叫做强实体型。
判断方法：如果不能从一个实体型属性中找出可以作为码的属性，这个实体型是弱实体型。
在E-R图中用双矩形表示弱实体型，用双菱形表示识别联系。
7.3.4 UML
UML是统一建模语言或标准建模语言，是始于1997年一个OMG标准，它是一个支持模型化和软件系统开发的图形化语言，为软件开发的所有阶段提供模型化和可视化支持，包括由需求分析到规格，到构造和配置。也可以作为表示E-R图的一种方法。
UML表示E-R图的说明：
①实体型：用类表示，矩形框上部写实体名，下面列出属性名。
②实体的码：在类图中属性后面加“PK”。
③联系：用类图之间的“关联”来表示。
7.3.5概念结构设计
概念设计的第一步就是对需求分析阶段手机到的数据进行分类、组织，确定实体、实体属性、实体间联系类型，形成E-R图。
- 实体与属性的划分原则
为了简化E-R图的处置，现实世界的事物能作为属性对待的，尽量作为属性对待。
两条准则：
（1）作为属性，不能再具有需要描述的性质。属性必须是不可分的数据项，不能包含其他属性。
（2）属性不能与其他实体具有联系，即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图中为不同的类型。
实体E1与E2在一个E-R图中是多对多联系，在另一个E-R图中是一对多联系。
解决方法：是根据应用的语义对实体联系的类型进行综合或调整。
（2）消除不必要的冗余，设计基本E-R图
所谓冗余的数据是指可由基本数据导出的数据，冗余的联系是指可由其他联系导出的联系。
消除冗余主要采用分析方法，即以数据字典和数据流图为依据，根据数据字典中关于数据项之间逻辑关系的说明来消除冗余。
消除冗余后的初步E-R图，称为基本E-R图。
说明：
并不是所有的冗余数据与冗余联系都必须加以消除，有时为了提高效率，不得不以冗余信息作为代价。
用规范化理论来消除冗余：
①确定分E-R图实体之间的数据依赖。
实体之间一对一、一对多、多对多的联系可以用实体码之间的函数依赖来表示。
②求FL的最小覆盖GL，差集为D=FL-GL。
逐一考察D中的函数依赖，确定是否是冗余的联系，若是，就把它去掉。
注意下面的问题：
一是冗余的联系一定在D中，而D中的联系不一定是冗余的；
二是当实体之间存在多种联系时，要将实体之间的联系在形式上加以区分。
7.4逻辑结构设计
逻辑结构设计的任务：把概念结构设计阶段设计好的基本E-R图转换为与选用数据库管理系统产品所支持的数据模型相符合的逻辑结构。
7.4.1 E-R图向关系模型的转换
E-R图由实体型、实体的属性和实体型之间的联系三个要素组成。E-R图向关系模型的转换就是将实体型、实体的属性和实体型之间的联系转化为关系模式。
- 转换规则：一个实体型转换为一个关系模式。关系的属性为实体的属性，关系的码为实体的码。
- 实体型间的联系有以下不同情况
（1）一个1:1联系可以转换为一个独立的关系模式，也可以与任意一端对应的关系模式合并。
- 转换为一个独立的关系模式
关系的属性：与该联系相连的各实体的码及联系本身的属性。
关系的候选码：每个实体的码均是该关系的候选码。 - 与某一端实体对应的关系模式合并
合并后关系的属性：加入对应关系的码和联系本身的属性。
合并后关系的码：不变。
（2）一个1：n联系可以转换为一个独立的关系模式，也可以与n端对应的关系模式合并。 - 转换为一个独立的关系模式
关系的属性：与该联系相连的各实体的码及联系本身的属性。
关系的候选码：n端实体的码。 - 与n端对应的关系模式合并
合并后关系的属性：在n端关系中加入1端关系的码和联系本身的属性。
合并后关系的码：不变。
该方法可以减少系统中的关系个数，一般情况下更倾向于采用这种方法。
（3）一个m:n联系转换为一个关系模式。
关系的属性：与该联系相连的各实体的码及联系本身的属性。
关系的候选码：各实体码的组合。
（4）三个或三个以上实体间的一个多元联系转换为一个关系模式。
关系的属性：与该联系相连的各实体的码及联系本身的属性。
关系的候选码：各实体码的组合。
（5）具有相同码的关系模式可合并。
目的：减少系统中的关系个数。
合并方法：
第一步：将其中一个关系模式的全部属性加入到另一个关系模式中。
第二步：去掉其中的同义属性（可能同名也可能不同名）。
第三步：适当调整属性的次序。
7.4.2数据模型的优化
数据库逻辑设计的结果不是唯一的。为了进一步提高数据库应用系统的性能，还应该适当地修改、调整数据模型的结构，这就是数据模型的优化。
优化数据模型的方法：
（1）确定数据依赖。按需求分析阶段所得到的语义，分别写出每个关系模式内部各属性之间的数据依赖以及不同关系模式属性之间的数据依赖。
（2）对于各个关系模式之间的数据依赖进行极小化处理，消除冗余的联系。
（3）按照数据依赖的理论对关系模式进行分析，考察是否存在部分函数依赖、传递函数依赖、多值依赖等，确定各关系模式分别属于第几范式。
（4）按照需求分析阶段得到的各种应用对数据处理的要求，分析对于这样的应用环境这些模式是否合适，确定是否要对它们进行合并或分解。
说明：并不是规范化程度越高的关系就越优。
例如当查询经常涉及两个或多个关系模式的属性时，系统就必须经常性地进行连接运算，代价相当高，因此在这种情况下，第二范式甚至第一范式也许是适合的。
（5）对关系模式进行必要分解，提高数据操作效率和存储空间的利用率。
常用分解方法有水平分解和垂直分解。
- 水平分解：把（基本）关系的元组分为若干子集合，定义每个子集合为一个子关系。
分解方法：
一是对符合80/20的，把经常使用的数据（约20%）水平分解出来，形成一个子关系。
二是每个事务存取的数据对应一个子关系。 - 垂直分解：把关系模式R的属性分解为若干子集合，形成若干子关系模式。
分解原则：经常在一起使用的属性从R中分解出来形成一个子关系模式。
分解优点：可以提高某些事务的效率。
分解缺点：可能使另一些事务不得不执行连接操作，降低了效率。
适用范围：取决于分解后R上的所有事务的总效率是否得到了提高。
分解方法：
简单情况直观分解。
复杂情况用第6章中的模式分解算法。
垂直分解必须不损失关系模式的语义（保持无损连接性和保持函数依赖）。
7.4.3设计用户子模式
定义数据库模式主要是从系统的时间效率、空间效率、易维护等角度出发。
定义用户外模式时应该更注重考虑用户的习惯与方便。包括三个方面：
（1）使用更符合用户习惯的别名
合并各分E-R图曾做了消除命名冲突的工作，以使数据库系统中同一关系和属性具有唯一的名字。用视图机制可以在设计用户视图时可以重新定义某些属性名，使其与用户习惯一致，方便使用。
（2）针对不同级别的用户定义不同的视图，以保证系统的安全性。
（3）简化用户对系统的使用
如果某些局部应用中经常要使用某些很复杂的查询，为了方便用户，可以将这些复杂查询定义为视图。
7.5物理结构设计
- 什么是数据库的物理设计
数据库在物理设备上的存储结构与存取方法称为数据库的物理结构，它依赖于选定的数据库管理系统。
为一个给定的逻辑数据模型选取一个最适合应用要求的物理结构的过程，就是数据库的物理设计。 - 数据库物理设计的步骤
（1）确定数据库的物理结构
在关系数据库中主要指存取方法和存储结构。
（2）对物理结构进行评价
评价的重点是时间和空间效率。若评价结果满足原设计要求，则可进入到物理实施阶段。否则，就要重新设计或修改物理结构，有时甚至要返回逻辑设计阶段修改数据模型。
7.5.1数据库物理设计的内容和方法
- 设计物理数据库结构的准备工作
（1）充分了解应用环境，详细分析要运行的事务，以获得选择物理数据库设计所需参数。
（2）充分了解所用关系型数据库管理系统的内部特征，特别是系统提供的存取方法和存储结构。 - 选择物理数据库设计所需参数
（1）对于数据库查询事务，需要得到以下信息：
- 查询的关系。
- 查询条件所涉及的属性。
- 连接条件所涉及的属性。
- 查询的投影属性。
（2）对于数据更新事务，需要得到以下信息： - 被更新的关系。
- 每个关系上的更新操作条件所涉及的属性。
- 修改操作要改变的属性值。
（3）每个事务在各关系上运行的频率和性能要求。
- 关系数据库物理设计的内容
为关系模式选择存取方法（建立存取路径）以及设计关系、索引等数据库文件的物理存储结构。
7.5.2关系模式存取方法选择
数据库系统是多用户共享的系统，对同一个关系要建立多条件存取路径才能满足多用户的多种应用要求。
物理结构设计的任务之一是根据关系数据库管理系统支持的存取方法确定选择哪些存取方法。
数据库管理系统常用存取方法：
- B+树索引存取方法。
- Hash索引存取方法。
- 聚簇存取方法。
- B+树索引存取方法的选择
选择索引存取方法实际上就是根据应用要求确定对哪些属性列建立索引、对哪些属性列建立组合索引、对哪些索引要设计为唯一索引等。
选择索引存取方法的一般规则：
（1）如果一个（或一组）属性经常在查询条件中出现，则考虑在这个（或这组）属性上建立索引（或组合索引）。
（2）如果一个属性经常作为最大值和最小值等聚集函数的参数，则考虑在这个属性上建立索引。
（3）如果一个（或一组）属性经常在连接操作的条件中出现，则考虑在这个（或这组）属性上建立索引。 - Hash存取方法的选择
选择Hash存取方法的规则：如果一个关系的属性主要出现在等值连接条件中或主要出现在等值比较选择条件中，而且满足下列两个条件之一：
①该关系的大小可预知，而且不变。
②该关系的大小动态改变，但所选用的数据库管理系统提供了动态Hash存取方法。 - 聚簇存取方法的选择
聚簇是为了提高谋而属性（或属性组）的查询速度，把这个或这些属性（称为聚簇码）上具有相同值的元组集中存放在连续的物理块中称为聚簇。
说明：
①聚簇对于某些类型的查询，可以提高查询效率。
②在一个基本表上最多只能建立一个聚簇索引。
③聚簇索引的适用条件，一是很少对基表进行增删操作，二是很少对其中的变长列进行修改操作。
选择聚簇存取方法：
（1）设计候选聚簇
①常在一起进行连接操作的关系可以建立组合聚簇。
②如果一个关系的一组属性经常出现在相等比较条件中，则该单个关系可建立聚簇。
③如果一个关系的一个（或一组）属性上的值重复率很高，则此单个关系可建立聚簇。
（2）检查候选聚簇中的关系，取消其中不必要的关系
①从聚簇中删除经常进行全表扫描的关系。
②从聚簇中删除更新操作远多于连接操作的关系。
③从聚簇中删除重复出现的关系。当一个关系同时加入多个聚簇时，必须从这多个聚簇方案（包括不建立聚簇）中选择一个较优的，即在这个聚簇上运行各种事务的总代价最小。
7.5.3确定数据库的存储结构
确定数据库物理结构主要指确定数据的存放位置和存储结构，包括：确定关系、索引、聚簇、日志、备份等的存储安排和存储结构，确定系统配置等。
确定数据的存放位置和存储结构要综合考虑存取时间、存储空间利用率和维护代价3个方面的因素。
- 确定数据的存放位置
根据应用情况将易变部分与稳定部分分开存放、经常存取部分与存取频率较低部分分开存放。 - 确定系统配置
数据库管理系统一般都提供了一些系统配置变量和存储 分配参数，初始情况下，系统都为这些变量赋予了合理的缺省值，在进行物理设计时需要根据应用环境确定这些参数值，使系统性能最优。
系统配置变量很多，例如：同时使用数据库的用户数、同时打开的数据库对象数、内存分配参数、缓冲区分配参数（使用的缓冲区长度、个数）、存储分配参数、物理块的大小、物理块装填因子、时间片大小、数据库的大小、锁的数目等。
7.5.4评价物理结构
对数据库物理设计过程中产生的多种方案进行评价，从中选择一个较优的方案作为数据库的物理结构。
评价方法主要是定量估算各种方案的存储空间、存取时间、维护代价，对估算结果进行权衡、比较，选择出一个较优的合理的物理结构。
7.6数据库的实施和维护
7.6.1数据的载入和应用程序的调试
- 数据的载入
数据库结构建立好后，就可以向数据库中装载数据了。组织数据入库是数据库实施阶段最主要的工作。
数据装载方法：人工方法、计算机辅助数据入库。 - 应用程序的调试
数据库应用程序的设计应该与数据设计并行进行，在组织数据入库的同时还要调试应用程序。
7.6.2数据库的试运行
应用程序调试完成，并且已有一小部分数据入库后，就可以开始对数据库系统进行联合测试，也称数据库的试运行。
主要工作包括：
功能测试：实际运行应用程序，执行对数据库的各种操作，测试应用程序的各种功能。
性能测试：测量系统的性能指标，分析是否符合设计目标。
说明：
①数据的分期入库。
②做好数据库的转储和恢复。
7.6.3数据库的运行和维护
在数据库运行阶段，对数据库经常性的维护工作主要是由数据库管理员完成。
主要工作包括：
- 数据库的转储和恢复
数据库管理员要针对不同的应用要求制定不同的转储计划，一旦发生介质故障，尽快将数据库恢复到某种一致性状态。 - 数据库的安全性、完整性机制
当应用环境发生变化，对安全性的要求也会发生变化，数据库管理员需要根据实际情况修改原有的安全性控制，同样数据库的完整性约束条件也会变化。 - 数据库性能的监督、分析和改进
在数据库运行过程中，数据库管理员必须监督系统运行，对检测数据进行分析，找出改进系统性能的方法。 - 数据库的重组织与重构造
（1）数据库的重组织
数据库运行一段时间后，由于记录的不断增、删、改，会使数据库的物理存储变坏，从而降低数据库存储空间的利用率和数据的存取效率，使数据库的性能下降。
数据库的重组织不会改变原设计的数据逻辑结构和物理结构。
重组织的方法：按原设计要求重新安排存储位置、回收垃圾、减少指针链。
（2）数据库的重构造
数据库应用环境发生变化，会导致实体及实体间的联系也发生相应的变化，使原有的数据库设计不能很好地满足新的需求。
数据库的重构造需根据新环境调整数据库的模式和内模式。
重构造的方法：增加或删除某些数据项、改变数据项的类型、增加或删除某个表、改变数据库的容量、增加或删除某些索引等。
若应用变化太大，已无法通过重构数据库来满足新的需求，或重构数据库的代价太大，则表明现有数据库应用系统的生命周期已经结束，应该重新设计新的数据库应用系统了。
7.7小结
- 数据库设计的方法和步骤
- 数据库设计6个阶段
重点是概念结构设计和逻辑结构的设计。 - 概念结构设计
概念结构的设计着重介绍了E-R模型的基本概念和图示方法。应重点掌握实体型、属性和联系的概念，理解实体型之间的一对一、一对多和多对多联系。掌握E-R模型的设计以及把E-R模型转换为关系模型的方法。 - 逻辑结构的设计
将概念结构转化为具体的数据模型。
973
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
