数据库设计概念
- 数据库设计是指对于一个给定的应用环境，构造（设计）优化的数据库逻辑模式和物理结构， 并据此建立数据库及其应用系统，使之能够有效地存储和管理数据，满足各种用户的应用需求，包括信息管理要求和数据操作要求。
- 目标：为用户和各种应用系统提供一个信息基础设施和高效率的运行环境。
一、数据库设计的特点 数据库建设的基本规律 三分技术，七分管理，十二分基础数据 管理
- 数据库建设项目管理
- 企业（即应用部门）的业务管理
基础数据
- 收集、入库
- 更新新的数据
结构（数据）设计和行为（处理）设计相结合。将数据库结构设计和数据处理设计密切结合
二、数据库设计方法
- 手工与经验相结合方法 设计质量与设计人员的经验和水平有直接关系 数据库运行一段时间后常常不同程度地发现各种问 题，增加了维护代价
- 规范设计法 基本思想：过程迭代和逐步求精
- 新奥尔良（New Orleans）方法 将数据库设计分为若干阶段和步骤
- 基于E-R模型的数据库设计方法 概念设计阶段广泛采用
- 3NF（第三范式）的设计方法 逻辑阶段可采用的有效方法
- CASE即Computer Aided Software Engineering， 中文意思是计算机辅助软件工程。CASE是一组 工具和方法的集合，可以辅助软件开发生命周期 各阶段进行软件开发。 ORACLE Designer SYBASE PowerDesigner
三、数据库设计的基本步骤 （一）数据库设计的准备工作：选定参加设计的人 1.系统分析人员、数据库设计人员（核心人员） 自始至终参与数据库设计，其水平决定了数据库系统的质量
- 用户和数据库管理员 主要参加需求分析和数据库的运行维护 3.应用开发人员（程序员和操作员） 在系统实施阶段参与进来，负责编制程序和准备软硬件环境 （二）数据库设计的过程 1.需求分析阶段
- 准确了解与分析用户需求（包括数据与处理）
- 最困难、最耗费时间的一步 2.概念结构设计阶段
- 整个数据库设计的关键
- 通过对用户需求进行综合、归纳与抽象，形 成一个独立于具体DBMS的概念模型
需求分析和概念设计独立于任何数据库管理系统
3.逻辑结构设计阶段
- 将概念结构转换为某个DBMS所支持的数据模型
- 对其进行优化
4.数据库物理设计阶段
- 为逻辑数据模型选取一个最适合应用环境的物理结构（包括存储结构和存取方法）
逻辑设计和物理设计与选用的DBMS密切相关 5.数据库实施阶段 运用DBMS提供的数据库语言（如SQL）及 宿主语言，根据逻辑设计和物理设计的结果
- 建立数据库
- 编制与调试应用程序
- 组织数据入库
- 进行试运行
6.数据库运行和维护阶段
- 数据库应用系统经过试运行后即可投入正式运行
- 在数据库系统运行过程中必须不断地对其进行评价、调整与修改
设计特点
- 把数据库设计和对数据库中数据处理的设计紧密结合起来
- 将这两个方面的需求分析、抽象、设计、实现在各个阶段同时进行，相互参照，相互补充，以完善两方面的设计
数据库设计过程中的各级模式的形成过程
- 需求分析阶段 综合各个用户的应用需求
- 概念设计阶段 形成独立于机器特点，独立于各个 DBMS产品的概念模式(E-R图)
- 逻辑设计阶段 首先将E-R图转换成具体的数据库产品支 持的数据模型，如关系模型，形成数据库 逻辑模式 然后根据用户处理的要求、安全性的考虑， 在基本表的基础上再建立必要的视图 (View)，形成数据的外模式
- 物理设计阶段 根据DBMS特点和处理的需要，进行物理 存储安排，建立索引，形成数据库内模式
需求分析
一、需求分析的任务
- 详细调查现实世界要处理的对象（组织、部门、企业等）
- 充分了解原系统（手工系统或计算机系统）
- 明确用户的各种需求
- 确定新系统的功能
- 充分考虑今后可能的扩充和改变(不能仅仅按当前应用 需求来设计数据库)
调查的重点是“数据”和“处理”，获得用户对数据库要求。
需求分析的重点：
- 信息要求 用户需要从数据库中获得信息的内容与性质 由用户的信息要求可以导出数据要求，即在数据 库中需要存储哪些数据
- 处理要求 对处理功能的要求 对处理的响应时间的要求 对处理方式的要求(批处理 / 联机处理)
- 新系统的功能必须能够满足用户的信息要求、处理 要求、安全性与完整性要求
需求分析难点：
- 确定用户最终需求 用户缺少计算机知识 设计人员缺少用户的专业知识
- 解决方法 设计人员必须不断深入地与用户进行交流
二、需求分析的方法
1. 调查与初步分析用户需求 ⑴ 调查组织机构情况
- 组织部门的组成情况
- 各部门的职责等
⑵ 调查各部门的业务活动情况。调查重点之一。
- 各个部门输入和使用什么数据
- 如何加工处理这些数据
- 输出什么信息
- 输出到什么部门
- 输出结果的格式是什么 ⑶ 在熟悉业务活动的基础上，协助用户明确对新系统 的各种要求。调查重点之二。
- 信息要求
- 处理要求
- 完全性与完整性要求 ⑷ 对前面调查的结果进行初步分析 确定新系统的边界
- 确定哪些功能由计算机完成或将来准备让计算机完成
- 确定哪些活动由人工完成 由计算机完成的功能就是新系统应该实现的功能。
2.常用调查方法 ⑴跟班作业
- 通过亲身参加业务工作了解业务活动的情况
- 能比较准确地理解用户的需求，但比较耗时
⑵开调查会
- 通过与用户座谈来了解业务活动情况及用户需求
⑶请专人介绍
⑷询问
- 对某些调查中的问题，可以找专人询问
⑸设计调查表请用户填写
- 如果调查表设计合理，则很有效，且易于为用户接受
⑹查阅记录
- 查阅与原系统有关的数据记录
3.进一步分析和表达用户需求 结构化分析方法（Structured Analysis，简 称SA方法）
- 从最上层的系统组织机构入手
- 自顶向下、逐层分解分析系统
- 数据流图和数据字典描述系统
1）首先把任何一个系统都抽象为：
2．分解处理功能和数据 (1)分解处理功能 将处理功能的具体内容分解为若干子功能 (2)分解数据 处理功能逐步分解同时，逐级分解所用数据， 形成若干层次的数据流图 (3)表达方法 处理逻辑：用判定表或判定树来描述 数据：用数据字典来描述 3.将分析结果再次提交给用户，征得用户的认可
三、数据字典 数据字典的用途是各类数据描述的集合 进行详细的数据收集和数据分析所获得的主要结果 数据字典的内容 1.数据项 数据项是不可再分的数据单位 对数据项的描述
代码语言：javascript复制数据项描述＝
｛数据项名，数据项含义说明，别名，
数据类型，长度，取值范围，取值含义，
与其他数据项的逻辑关系，
数据项之间的联系 ｝2.数据结构 数据结构反映了数据之间的组合关系。 一个数据结构可以由若干个数据项组成，也可以由若 干个数据结构组成，或由若干个数据项和数据结构混 合组成。 对数据结构的描述
代码语言：javascript复制数据结构描述＝
｛数据结构名，含义说明，
组成:｛数据项或数据结构｝｝3.数据流
- 数据流是数据结构在系统内传输的路径。
- 对数据流的描述
数据流描述＝
｛ 数据流名，说明，数据流来源，
数据流去向，组成:｛数据结构｝，
平均流量，高峰期流量｝4.数据存储
- 数据存储是数据结构停留或保存的地方，也是数 据流的来源和去向之一。
- 对数据存储的描述
数据存储描述＝
｛数据存储名，说明，编号，
输入的数据流 ，输出的数据流 ，
组成:｛数据结构｝，数据量，
存取频度， 存取方式｝5.处理过程
- 具体处理逻辑一般用判定表或判定树来描述
- 处理过程说明性信息的描述
处理过程描述＝
｛处理过程名，说明，输入:｛数据流｝，
输出:｛数据流｝，处理:｛简要说明｝｝数据字典
- 数据字典是关于数据库中数据的描述，是元数据， 而不是数据本身
- 数据字典在需求分析阶段建立，在数据库设计过程 中不断修改、充实、完善
概念结构设计
一、概念结构
- 将需求分析得到的用户需求抽象为信息结构即概念模型的过程就是概念结构设计
- 概念结构是各种数据模型的共同基础，它比数据模型更独立于机器、更抽象，从而更加稳定
- 概念结构设计是整个数据库设计的关键
描述概念模型的工具：E-R模型 二、概念结构设计的方法与步骤 设计概念结构的四类方法
- 自顶向下 首先定义全局概念结构的框架，然后逐步细化
- 自底向上 首先定义各局部应用的概念结构，然后将它们集成 起来，得到全局概念结构
- 逐步扩张 首先定义最重要的核心概念结构，然后向外扩充，以滚雪球的方式逐步生成其他概念结构，直至总体概念结构
- 混合策略 将自顶向下和自底向上相结合，用自顶 向下策略设计一个全局概念结构的框架， 以它为骨架集成由自底向上策略中设计的各局部概念结构。 自顶向下地进行需求分析 自底向上地设计概念结构
自底向上设计概念结构的步骤 第1步：抽象数据并设计局部视图 第2步：集成局部视图，得到全局概念结构
三、数据抽象与局部视图设计 1.数据抽象 抽象是对实际的人、物、事和概念中抽取 所关心的共同特性，忽略非本质的细节， 并把这些特性用各种概念精确地加以描述。 概念结构是对现实世界的一种抽象 三种常用抽象：
- 分类（Classification） 定义某一类概念作为现实世界中一组对象的类型 抽象了对象值和型之间的“is member of”的语义
- 聚集（Aggregation） 定义某一类型的组成成分 抽象了对象内部类型和成分之间“is part of”的语义 复杂的聚集，某一类型的成分仍是一个聚集
- 概括（Generalization） 定义类型之间的一种子集联系 抽象了类型之间的“is subset of”的语义 继承性
2.局部视图设计 设计分E-R图的步骤: 1）选择局部应用
- 在多层的数据流图中选择一个适当层次的数据流图，作为设计分E-R图的出发点
- 通常以中层数据流图作为设计分E-R图的依据
2）逐一设计分E-R图
- 将各局部应用涉及的数据分别从数据字典中 抽取出来 参照数据流图，标定各局部应用中的实体、 实体的属性、标识实体的码
- 确定实体之间的联系及其类型（1:1，1:n， m:n） 两条准则：
- 属性不能再具有需要描述的性质。即 属性必须是不可分的数据项，不能再由另一 些属性组成
- 属性不能与其他实体具有联系。联系 只发生在实体之间
四、视图的集成 各个局部视图即分E-R图建立好后，还需要对它们进行合并，集成为一个整体的数据概念结构即总E-R图。
- 多个分E-R图一次集成 一次集成多个分E-R图 通常用于局部视图比较简单时
- 逐步集成 用累加的方式一次集成两个分E-R图（通常是比较关键的两个局 部视图）
集成局部E-R图的步骤 ：合并；修改与重构
- 各分E-R图存在冲突 各个分E-R图之间必定会存在许多不一致的地方
- 合并分E-R图的主要工作与关键 合理消除各分E-R图的冲突
冲突 1.属性冲突
- 属性域冲突 属性值的类型 取值范围 取值集合不同
- 属性取值单位冲突
2.命名冲突
- 同名异义：不同意义的对象在不同的局部应用中 具有相同的名字
- 异名同义（一义多名）：同一意义的对象在不同 的局部应用中具有不同的名字
3.结构冲突
- 同一对象在不同应用中具有不同的抽象
- 同一实体在不同局部视图中所包含的属性不 完全相同，或者属性的排列次序不完全相同。 产生原因：不同的局部应用关心的是该实 体的不同侧面。 解决方法：使该实体的属性取各分E-R图 中属性的并集，再适当设计属性的次序。
- 实体之间的联系在不同局部视图中呈现不同的类型 解决方法：根据应用语义对实体联系的类型 进行综合或调整。
消除不必要的冗余，设计基本E-R图 1.冗余
- 冗余的数据是指可由基本数据导出的数据； 冗余的联系是指可由其他联系导出的联系
- 冗余数据和冗余联系容易破坏数据库的完整性，给 数据库维护增加困难
- 并不是所有的冗余数据与冗余联系都必须加以消除， 有时为了提高某些应用的效率，不得不以冗余信息作为代价。
- 设计数据库概念结构时，哪些冗余信息必须消除，哪些冗余信息允许存在，需要根据用户的整体需求来确定。
- 消除不必要的冗余后的初步E-R图称为基本E- R图。
2.消除冗余的方法
- 分析方法 以数据字典和数据流图为依据 根据数据字典中关于数据项之间的逻辑关系 的说明来消除冗余。 如果是为了提高效率，人为地保留了一些冗 余数据，则应把数据字典中数据关联的说明 作为完整性约束条件。 一种更好的方法是把冗余数据定义在视图中
- 规范化理论 函数依赖的概念提供了消除冗余联系的形式 化工具
方法：
- 确定分E-R图实体之间的数据依赖 ，并用实体码之间的函数依赖表示。
- 求FL的最小覆盖GL ，差集为D = FL-GL。逐一考察D中的函数依赖，确定是否是冗余的联系，若 是，就把它去掉 (1) 冗余的联系一定在D中，而D中的联系不一定是冗余的； (2) 当实体之间存在多种联系时要将实体之间的联系在形式上加以区分。
验证整体概念结构： 视图集成后形成一个整体的数据库概念结构，对该 整体概念结构还必须进行进一步验证，确保它能够 满足下列条件：
- 整体概念结构内部必须具有一致性，不存在互相矛盾的表达
- 整体概念结构能准确地反映原来的每个视图结构，包括属性、实体及实体间的联系
- 整体概念结构能满足需求分析阶段所确定的所有要求
- 整体概念结构最终还应该提交给用户，征求用户和有关人员的意见，进行评审、修改和优化，然后把它确定下来，作为数据库的概念结构，作为进一步设计数据库的依据
逻辑结构设计
逻辑结构设计的任务
- 把概念结构设计阶段设计好的基本E-R图转换为与选 用DBMS产品所支持的数据模型相符合的逻辑结构
逻辑结构设计的步骤
- 将概念结构转化为一般的关系、网状、层次模型
- 将转换来的关系、网状、层次模型向特定DBMS支持 下的数据模型转换
- 对数据模型进行优化
逻辑结构设计时的3个步骤
一、E-R图向关系模型的转换 1.转换内容
- E-R图向关系模型的转换要解决的问题 如何将实体型和实体间的联系转换为关系模式 如何确定这些关系模式的属性和码
- 转换内容 将E-R图转换为关系模型：将实体、实体的属性和 实体之间的联系转换为关系模式。
- 实体型间的联系有以下不同情况 ： (1)一个1:1联系可以转换为一个独立的关系模式， 也可以与任意一端对应的关系模式合并。 转换为一个独立的关系模式； 与某一端实体对应的关系模式合并。 (2)一个1:n联系可以转换为一个独立的关系模式， 也可以与n端对应的关系模式合并。 转换为一个独立的关系模式； 与n端对应的关系模式合并。 (3) 一个m:n联系转换为一个关系模式。 (4)三个或三个以上实体间的一个多元联系转换为一个关系模式。 (5)具有相同码的关系模式可合并 目的：减少系统中的关系个数 合并方法：将其中一个关系模式的全部属性加入到另一个关系模式中，然后去掉其中的同义属性（可能同名也可能 不同名），并适当调整属性的次序
注意：
- 从理论上讲，1:1联系可以与任意一端对应的关系模式合并
- 但在一些情况下，与不同的关系模式合并效率会大不 一样。因此究竟应该与哪端的关系模式合并需要依应 用的具体情况而定。
- 由于连接操作是最费时的操作，所以一般应以尽量减少连接操作为目标。
二、数据模型的优化
- 得到初步数据模型后，还应该适当地修改、调 整数据模型的结构，以进一步提高数据库应用 系统的性能，这就是数据模型的优化
- 关系数据模型的优化通常以规范化理论为指导
1.优化模型方法
- 确定数据依赖 按需求分析阶段所得到的语义，分别写出每个关系模式内 部各属性之间的数据依赖以及不同关系模式属性之间数据 依赖
- 消除冗余的联系 对于各个关系模式之间的数据依赖进行极小化处理，消除 冗余的联系。
- 确定所属范式 按照数据依赖的理论对关系模式逐一进行分析 考查是否存在部分函数依赖、传递函数依赖、多值依赖等 确定各关系模式分别属于第几范式
- 按照需求分析阶段得到的各种应用对数据处理的要求，分析对于这样的应用环境这些模式是否合适，确定是否要对它们进行合并或分解。 并不是规范化程度越高的关系就越优，一般说来，第三范式就足够了
- 按照需求分析阶段得到的各种应用对数据处理的要求， 对关系模式进行必要的分解，以提高数据操作的效率和存储空间的利用率。常用分解方法： 水平分解：把(基本)关系的元组分为若干子集合，定义每个子集合为一个子关系，以提高系统的效率。 适用范围：满足“80/20原则”的应用；并发事务经常存取不相交的数据 垂直分解：把关系模式R的属性分解为若干子集合，形成若干子关系模式。 使用范围：取决于分解后R上的所有事务的总效率是否得到了提高
三、设计用户子模式 注重的问题 (1) 使用更符合用户习惯的别名 (2) 针对不同级别的用户定义不同的View，以满足系统对安全性的要求。 (3) 简化用户对系统的使用
数据库的物理设计
数据库的物理设计
- 数据库在物理设备上的存储结构与存取方法称为数据 库的物理结构，它依赖于选定的数据库管理系统
- 为一个给定的逻辑数据模型选取一个最适合应用环境 的物理结构的过程，就是数据库的物理设计
数据库物理设计的步骤
- 确定数据库的物理结构，在关系数据库中主要指存取方法 和存储结构
- 对物理结构进行评价，评价的重点是时间和空间效率 如果评价结果满足原设计要求，则可进入到物理实施阶段， 否则，就需要重新设计或修改物理结构，有时甚至要返回 逻辑设计阶段修改数据模型
一、数据库物理设计的内容和方法 设计物理数据库结构的准备工作
- 对要运行的事务进行详细分析，获得选择物理数据库设计所需参数
- 充分了解所用RDBMS的内部特征，特别是系统提 的存取方法和存储结构
选择物理数据库设计所需参数
- 数据库查询事务 查询的关系 查询条件所涉及的属性 连接条件所涉及的属性 查询的投影属性
- 数据更新事务 被更新的关系 每个关系上的更新操作条件所涉及的属性 修改操作要改变的属性值
- 每个事务在各关系上运行的频率和性能要求
关系数据库物理设计的内容
- 为关系模式选择存取方法(建立存取路径)
- 设计关系、索引等数据库文件的物理存储结构
1.关系模式存取方法选择
- 数据库系统是多用户共享的系统，对同一个关系要建立多条存取路径才能满足多用户的多种应用要求
- 物理设计的任务之一就是要确定选择哪些存取方法，即建立哪些存取路径
DBMS常用存取方法
- 索引方法 目前主要是B 树索引方法 经典存取方法，使用最普遍
- 聚簇（Cluster）方法
- HASH方法
根据应用要求确定
- 对哪些属性列建立索引
- 对哪些属性列建立组合索引
- 对哪些索引要设计为唯一索引
选择索引存取方法的一般规则
- 如果一个(或一组)属性经常在查询条件中出现，则考虑在 这个(或这组)属性上建立索引(或组合索引)
- 如果一个属性经常作为最大值和最小值等聚集函数的参 数，则考虑在这个属性上建立索引
- 如果一个(或一组)属性经常在连接操作的连接条件中出现， 则考虑在这个(或这组)属性上建立索引
关系上定义的索引数过多会带来较多的额外开销
- 维护索引的开销
- 查找索引的开销
2.聚簇存取方法的选择 聚簇 为了提高某个属性（或属性组）的查询速度，把这个或这些属性（称为聚簇码）上具有相同值的元组集中存放在连续的物理块称为聚簇 聚簇的用途
- 大大提高按聚簇码进行查询的效率
- 节省存储空间 聚簇以后，聚簇码相同的元组集中在一起了，因而 聚簇码值不必在每个元组中重复存储，只要在一组 中存一次就行了
聚簇的局限性
- 聚簇只能提高某些特定应用的性能
- 建立与维护聚簇的开销相当大 对已有关系建立聚簇，将导致关系中元组移动其物理存储位置，并使此关系上原有的索引无效，必须重建 当一个元组的聚簇码改变时，该元组的存储位置也要做相应移动
聚簇的适用范围
- 既适用于单个关系独立聚簇，也适用于多个关系组合聚簇。
- 当通过聚簇码进行访问或连接是该关系的主要应用， 与聚簇码无关的其他访问很少或者是次要的时候，可 以使用聚簇。
设计候选聚簇
- 对经常在一起进行连接操作的关系可以建立聚簇
- 如果一个关系的一组属性经常出现在相等比较条件中，则 该单个关系可建立聚簇
- 如果一个关系的一个(或一组)属性上的值重复率很高，则 此单个关系可建立聚簇。即对应每个聚簇码值的平均元组 数不太少。太少了，聚簇的效果不明显
优化聚簇设计
- 从聚簇中删除经常进行全表扫描的关系；
- 从聚簇中删除更新操作远多于连接操作的关系；
- 不同的聚簇中可能包含相同的关系，一个关系可以 在某一个聚簇中，但不能同时加入多个聚簇 从这多个聚簇方案(包括不建立聚簇)中选择一个较优的，即 在这个聚簇上运行各种事务的总代价最小
3.HASH存取方法的选择 选择HASH存取方法的规则 当一个关系满足下列两个条件时，可以选择HASH存 取方法
- 该关系的属性主要出现在等值连接条件中或主要 出现在相等比较选择条件中
- 该关系的大小可预知，而且不变； 或该关系的大小动态改变，但所选用的DBMS提供了 动态HASH存取方法
三、确定数据库的存储结构 确定数据库物理结构的内容 1. 确定数据的存放位置和存储结构
- 关系
- 索引
- 聚簇
- 日志
- 备份
确定数据存放位置和存储结构的因素
- 存取时间
- 存储空间利用率
- 维护代价
基本原则： 根据应用情况将
- 易变部分与稳定部分分开存放
- 存取频率较高部分与存取频率较低部分，分开存放
2. 确定系统配置 DBMS产品一般都提供了一些存储分配参数
- 同时使用数据库的用户数
- 同时打开的数据库对象数
- 内存分配参数
- 使用的缓冲区长度、个数
- 存储分配参数
四、评价物理结构
- 评价内容 对数据库物理设计过程中产生的多种方案进行细致的评价，从中选择一个较优的方案作为数据库的物理结构
- 评价方法（完全依赖于所选用的DBMS ） 定量估算各种方案：存储空间；存取时间；维护代价 对估算结果进行权衡、比较，选择出一个较优的合 理的物理结构 如果该结构不符合用户需求，则需要修改设计
数据库的实施和维护
一、数据的载入和应用程序的调试 数据的载入
- 数据库结构建立好后，就可以向数据库中装载数据了。 组织数据入库是数据库实施阶段最主要的工作。
- 数据装载方法 人工方法 计算机辅助数据入库
应用程序的编码和调试
- 数据库应用程序的设计应该与数据设计并行进行
- 在组织数据入库的同时还要调试应用程序
二、数据库的试运行 在原有系统的数据有一小部分已输入数据库后，就可以开始 对数据库系统进行联合调试，称为数据库的试运行 数据库试运行主要工作包括： 1）功能测试
- 实际运行数据库应用程序，执行对数据库的各种操作，测试应 用程序的功能是否满足设计要求
- 如果不满足，对应用程序部分则要修改、调整，直到达到设计 要求
2）性能测试
- 测量系统的性能指标，分析是否达到设计目标
- 如果测试的结果与设计目标不符，则要返回物理设计阶段，重 新调整物理结构，修改系统参数，某些情况下甚至要返回逻辑 设计阶段，修改逻辑结构
分期分批组织数据入库
- 重新设计物理结构甚至逻辑结构，会导致数据重 新入库。
- 由于数据入库工作量实在太大，费时、费力，所 以应分期分批地组织数据入库
- 先输入小批量数据供调试用 待试运行基本合格后再大批量输入数据 逐步增加数据量，逐步完成运行评价
数据库的转储和恢复
- 在数据库试运行阶段，系统还不稳定，硬、软件故障随时都可能发生
- 系统的操作人员对新系统还不熟悉，误操作也不可避免
- 因此必须做好数据库的转储和恢复工作，尽量减少对数据库的破坏。
三、数据库的运行和维护
- 数据库试运行合格后，数据库即可投入正式运行。
- 数据库投入运行标志着开发任务的基本完成和维护工 作的开始
- 对数据库设计进行评价、调整、修改等维护工作是一 个长期的任务，也是设计工作的继续和提高 应用环境在不断变化 数据库运行过程中物理存储会不断变化
在数据库运行阶段，对数据库经常性的维护 工作主要是由DBA完成的，包括： 1 . 数据库的转储和恢复 2 . 数据库的安全性、完整性控制 3 . 数据库性能的监督、分析和改进 4 . 数据库的重组织和重构造
重组织的形式：
- 全部重组织；
- 部分重组织——只对频繁增、删的表进行重组织。
重组织的目标：
- 提高系统性能
重组织的工作：
- 按原设计要求 – 重新安排存储位置 – 回收垃圾 – 减少指针链
- 数据库的重组织不会改变原设计的数据逻辑结构和物理结构
数据库重构造： 根据新环境调整数据库的模式和内模式
- 增加新的数据项
- 改变数据项的类型
- 改变数据库的容量
- 增加或删除索引
- 修改完整性约束条件
