2020-11-16-数据库数据库设计需求,设计,运行,维护
数据库：数据库设计（需求，设计，运行，维护）
1，数据库设计概述
1.1，数据库设计的基本概念
数据库设计
是指对于一个给定的应用环境，构造（设计）优化的数据库逻辑模式和物理结构，并据此建立数据库及其应用系统，使之能够有效地存储和管理数据，满足各种用户的应用需求，包括信息管理要求和数据操作
要求。
数据库设计的目标：
是为用户和各种应用系统提供一个信息基础设施和高效率的运行环境
。
数据库设计的基本任务：
是根据用户的信息需求、处理需求和数据库的支持环境
(
包括硬件、操作系统和
DBMS)
，设计出数据库模式
(
包括外模式、逻辑模式和内模式
)
及其典型的应用程序
。
1.2，数据库设计的方法
直观设计法（手工试凑发）：
数据库
设计只是一种经验的反复实施，而不能称为是一门科学，缺乏科学分析理论基础和工程手段的支持，因为设计质量与设计人员的经验和水平有直接
关系，所以设计质量
很难保证
。具有
周期短、效率高、操作简便、易于实现等优点
。主要
是用于
简单小型
系统。
规范设计法：
将
数据库设计分为若干阶段，明确规定各阶段的任务，采用“自顶向下、分层实现、逐步求精”的设计原则，结合数据库理论和软件工程设计方法，实现设计过程的每一细节，最终完成整个设计任务。（新奥尔良
方法、基于E-R
模型的数据库设计方法、基于3NF
（第三范式）的设计方法、面向对象的数据库设计方法、统一建模语言（UML
）
方法）。
计算机辅助设计法：
在数据库设计的某些过程中，利用计算机和一些辅助设计工具，模拟某一规范设计方法，并以人的知识或经验为主导，通过人机交互方式实现设计中的某些部分。 （Oracle 公司开发的
Designer、Sybase公司开发的
PowerDesigner）。
1.3，数据库设计的基本步骤
需求分析：
通过
详细调查现实世界要处理的对象（组织、部门、企业等），充分了解原系统（手工系统或计算机系统）工作概况，明确用户的各种需求。
概念结构设计：
通过
对用户需求进行综合、归纳与抽象，形成一个独立于具体数据库管理系统的概念模型。
逻辑结构设计：
将
概念结构转换为某个数据库管理系统所支持的数据模型，并对其进行优化。
物理结构设计：
为
逻辑数据结构选取一个最适合应用环境的物理
结构
,
包括
存储结构和存取方法。
数据库实施：
根据
逻辑设计和物理设计的结果构建
数据库
,
编写
与调试
应用程序
,
组织
数据入库并进行试运行。
数据库运行和维护：
经过
试运行后即可投入正式
运行
,
在
运行过程中必须不断对其进行评估、调整与修改。
★需求分析和概念设计独立于任何数据库管理系统
★逻辑设计和物理设计与选用的数据库管理系统密切相关
| 设计阶段 | 设计描述 | |
| 数据 | 处理 | |
| 需求分析 | 数据字典、数据项、数据流、数据存储的描述 | 数据流图和判定树、数据字典中处理过程的描述 |
| 概念结构设计 | 概念模型 (ER 图 ) 、数据字典 | 系统说明书 ( 系统要求、方案、概图、数据流图 ) |
| 逻辑结构设计 | 某种数据模型 ( 如关系 ) | 系统结构图 ( 模块结构 ) |
| 物理设计 | 存储安排、方法选择、存取路径建立 | 模块设计 |
| 实施阶段 | 编写模式、装入数据、数据库试运行 | 程序编码、编译联结、测试 |
| 运行维护 | 性能监测、转储 / 恢复、数据库重组和重构 | 新旧系统转换、运行、维护 |
2，需求分析
2.1，需求分析及其任务
需求分析就是分析用户的需求：
是
设计数据库的
起点，结果
是否准确地反映了用户的实际要求，将直接影响到后面各个阶段的设计，并影响到设计结果是否合理和实用。
需求分析的任务：
由
数据库设计人员和用户双方共同收集信息需求和处理需求；通过仔细分析；将这些需求按一定的规范要求以用户和设计人员都能理解接受的文档形式确定下来。
2.2，需求分析的方法
需求分析的三个步骤：
① 需求调查:
收集需求信息
,
调查清楚用户的实际要求
,
与用户达成共识。
② 分析、整理和表达这些需求信息，形成需求说明书（例如，包括DFD和DD等）。
③ 评审：
由主管部门和专家评价、审批。
需求调查
需求调查的目的：
主要
是了解企业的组织机构设置
,
各个组织机构的职能、工作目标、职责范围，主要业务活动及大致工作流程，获得各个组织机构的业务数据及其相互联系的信息，为分析整理工作做好前期基础工作
。
需求调查的内容： ① 组织
机构的情况
:
组成
,
职责
,
作用
,
现状
,
问题，哪些业务适合计算机管理
,
哪些不适合
。 ② 各个部门的业务活动现状
(
调查的重点
):
输入和使用的数据
,
加工处理方法
,
数据的流程
,
输出的数据及格式
,
注意收集原始数据资料
,
如台帐、单据、发票、收据、统计报表、文档、档案等。 ③ 外部
要求：调查数据处理的响应时间、频度和如何发生的规则，以及经济效益的要求，安全性和完整性的要求。 ④ 协助
用户明确对新系统的各种要求
(
调查的又一个重点
):
信息要求
,
处理要求
,
安全性要求
,
完整性要求
,
未来规划中对数据的应用
需求等。 ⑤ 确定
新系统的边界
:
哪些由计算机完成
,
哪些由人工完成。
需求调查的步骤： ① 调查组
织机构
情况 。② 调查
各部门的业务活动
情况 。③ 协助
用户明确对新系统的各种要求，包括
信息
要求、处理要求、完全性与完整性
要求 。④ 确定
新系统的边界。
需求调查的方式： ① 跟班作业：
通过
亲身参加业务工作了解业务活动的情况。 ② 开调查会：
通过
与用户座谈来了解业务活动情况及用户需求。 ③ 请
专人
介绍。 ④ 询问：
对
某些调查中的问题，可以找专人询问。 ⑤ 设计
调查表请用户
填写：
调查表
设计合理，则很有效。 ⑥ 查阅记录：
查阅
与原系统有关的数据记录。
需求调查策略：
对高层负责人的调查
:
一般采用个别交谈方式
,
先给一份详细的调查提纲
,
以便有所准备。
对中层管理人员的调查
:
可采用开座谈会
,
个别交谈
,
发调查表
,
查阅记录的调查方式。
对基层业务人员的调查
:
主要采用发调查表
,
个别交谈或跟班作业的调查方式。
分析整理
分析整理的工作：
① 业务
流程分析和
表示
目的是获得业务流程及业务与数据联系的形式描述。
采用数据流层次结构分析法(SA
法
)
。
分析结果以数据流图
(DFD
图
)
表示
,
再辅以数据字典
(DD)
作补充描述
。
② 需求
信息的补充描述
数据字典:
主要用于概念结构
设计。
业务活动清单:
列出每一部门中最基本的工作任务。
其他需求清单:
如完整性、安全性、一致性要求
。
③ 撰写需求分析说明书
分析整理的方法：
结构化分析方法（SA方法）
SA
方法从最上层的系统组织机构
入手，采用
自顶向下、逐层分解的方式分析
系统。
SA步骤： a) 先把任何一个系统都抽象为
DFD
图形式。 b) 然后从最上层的系统组织机构入手，采用自顶向下，逐步分解，逐步求精的方式分析系统，获得多层
DFD
图。
数据流图（DFD）
数据字典（DD）
3，概念结构设计
3.1，概念模型
概念结构设计：
将
需求分析得到的用户需求抽象为信息结构（即概念模型）的
过程。
目前应用最普遍的是实体
关系（
E-R
）模型
，它将现实世界的信息结构统一用属性、实体以及它们之间的联系来描述
。
3.2，E-R概念模型
3.3，概念结构设计
实体与属性的划分
为了简化
E-R
图的处置，现实世界的事物能作为属性对待的，尽量作为属性对待
。
两条准则： ① 作为
属性，不能再具有需要描述的性质。属性必须是不可分的数据项，不能包含其他属性。 ② 属性
不能与其他实体具有联系，即
E-R
图中所表示的联系是实体之间的联系。
4，逻辑结构设计
4.1，逻辑结构设计概述
逻辑结构设计的任务：
将
概念结构转换成特定
DBMS
所支持的数据模型的过程。关系数据库逻辑设计的结果是一组关系模式的定义
。
逻辑结构设计的步骤：
**① 将
概念结构转换为一般的关系、网状、层次模型；**
**② 将
转换来的关系、网状、层次模型向特定
DBMS
支持下的数据模型转换；**
**③ 对
数据模型进行优化
。**
关系数据库逻辑设计的步骤
① 将
概念模型
(
例如基本
E-R
图
)
转换为关系模式的集合
得到关系数据库模式；
② 运用
关系数据理论对关系数据库模式进行规范化处理；
③ 对
关系数据库模式进行评价；
④ 对
关系数据库模式进行修正；
⑤ 设计
关系子模式
视图
。
4.2，ER图向关系模型的转换
一个实体转换为一个关系模式
原则：
关系的
属性
=
实体
型的属性；关系的码
=
实体
型的
码；关系模式的码
(
用下横线标出
) =
实体型的码
；
转换为： 学生( 学号 ，姓名，系别)
每个联系类型转换为独立的关系模式
原则：
关系模式的属性 =
与该联系相连的各实体型的
码
该联系自身的属性；关系模式的码(
用下划线标出
) =
各实体型的
码；
① 一个
1:1
联系可以转换为一个独立的关系模式，也可以与任意一端对应的关系模式合并
转换为一个独立的关系模式，原则 ：
关系模式的属性
=
与该联系相连的各实体型的
码
该
联系自身的属性；关系模式的码
(
用下划线标出
) =
各实体型的
码；
与某一端实体对应的关系模式合并， 原则：
合并后关系的
属性
=
加入
对应关系的码和联系本身的属性；合并后关系的码不变；
**②一个
1:n
联系可以转换为一个独立的关系模式，也可以与n端对应的关系模式合并。**
转换为一个独立的关系模式， 原则 ：
关系模式的属性
=
与该联系相连的各实体型的
码
该
联系自身的属性；关系模式的码
(
用下划线标出
) = n
端实体的
码；
与某一端实体对应的关系模式合并，原则：
合并后关系的
属性
=
在
n
端关系中加入
1
端关系的码和联系本身的属性；合并后关系的
码不变；
③一个
m:n
联系必须转换为一个独立的关系模式
转换为一个独立的关系模式，原则 ：
关系模式的属性
=
与该联系相连的各实体型的
码
该
联系自身的属性；关系模式的码
(
用下划线标出
)
=
各实体码的
组合；
④ 三个或三个以上实体间的一个多元联系转换为一个关系模式，原则 ：
关系模式的属性
=
与该联系相连的各实体型的
码
该
联系自身的属性；关系模式的码
(
用下划线标出
)
=
各实体码的
组合；
⑤ 具有相同码的关系模式可合并
目的：
减少系统中的关系个数
合并方法：
- 将其中一个关系模式的全部属性加入到另一个关系模式中
- 然后去掉其中的同义属性（可能同名也可能不同名）
- 适当调整属性的次序
把每一个实体装换为一个关系
首先
分析各实体的属性，从中确定其主键，然后分别用关系模式表示。
实体：学生 对应的关系：学生（学号，姓名，性别，年龄） 实体：课程 对应的关系：课程（课程号，课程名） 实体：教师 对应的关系：教师（教师号，姓名，性别，职称） 实体：系 对应的关系：系（系名，电话）把每一个联系装换为关系模式
将
4
个联系转换为关系模式，其中
2
个多对多类型的联系转换为独立关系模式，
2
个一对多的联系也转换为独立的关系模式。
联系：属于 对应的关系：属于（教师号，系名） 联系：讲授 对应的关系：讲授（教师号，课程号） 联系：选修 对应的关系：选修（学号，课程号，成绩） 联系：拥有 对应的关系：拥有（学号，系名）
画出关系图
4.3，数据模型的优化
数据库
逻辑设计的结果不是唯一
的，得到
初步数据模型后，还应该适当地修改、调整数据模型的结构，以进一步提高数据库应用系统的性能，这就是数据模型的优化。
★ 规范化过程可分为两个步骤：确定范式级别，实施规范化处理
① 确定数据依赖 ：
写出每个关系模式内部各属性之间的数据依赖；写出不同关系模式的属性
(
外码和主码
)之间的数据依赖；
② 对于各个关系模式之间的数据依赖进行极小化处理，消除冗余的联系。
③ 按照数据依赖的理论对关系模式进行分析，考察是否存在部分函数依赖、传递函数依赖、多值依赖等，确定各关系模式分别属于第几范式。
④ 按照需求分析阶段得到的各种应用对数据处理的要求，分析对于这样的应用环境这些模式是否合适，确定是否要对它们进行合并或分解。（
并不是规范化程度越高的关系就越优。当一个应用的查询中经常涉及到两个或多个关系模式的属性时，系统必须经常地进行连接运算，而连接运算的代价是相当高的，可以说关系模型低效的主要原因就是做连接运算引起的，因此在这种情况下，第二范式甚至第一范式也许是最好的。
）
⑤ 对关系模式进行必要的分解，提高数据操作的效率和存储空间的利用率。常用的两种分解方法是
水平分解
和
垂直分解
。
水平分解：
把
(
基本
)
关系的元组分为若干子集合，定义每个子集合为一个子关系，以提高系统的效率。
垂直分解：
把关系模式
R
的属性分解为若干子集合，形成若干子关系模式。
4.4，设计用户子模式（外模式）
将
概念模型转换为逻辑模型
(
数据库模式
)
后
,
还应根据局部应用的需求
,
结合具体
DBMS
的特点
,
设计用户的外
(
子
)
模式 。利用
RDBMS
提供的视图
(View)
功能设计
。
定义用户外模式时应该更注重考虑用户的习惯与方便。包括三个方面： ① 使用更符合用户习惯的别名。 ② 针对不同级别的用户定义不同的视图，以保证系统的安全性。 ③ 简化
用户对系统的使用。
视图：
5，物理结构设计
数据库的物理结构： 数据库
在物理设备上的存储结构与存取方法称为数据库的物理结构，它依赖于选定的数据库管理系统。
数据库的物理
设计：
为
一个给定的逻辑数据模型选取一个最适合应用要求的物理结构的过程，就是数据库的物理设计。
数据库物理设计的步骤： ① 确定数据库的物理
结构，在
关系数据库中主要指存取方法和存储结构
; ② 对
物理结构进行
评价，评价
的重点是时间和空间
效率；若评价
结果满足原设计要求，则可进入到物理
实施阶段
。否则，就需要重新设计或修改物理结构，
有时甚至
要返回逻辑设计阶段修改数据模型
。
5.1，数据库物理设计的内容和方法
准备工作： ① 要充分了解应用环境，详细分析要运行的事务。以获得选择物理数据库设计所需要的参数。分析数据库查询事务需要的信息、数据更新事务需要的信息、每个事务在各关系上运行的频率和性能要求等。 ② 要充分了解所用的
DBMS
的内部特征
,
特别是系统提供的存取方法和存储结构。
内容： ① 为关系模式选择存取方法，即要确定选择哪些存取方法，建立哪些存取路径。 ② 设计关系(
表
)
、聚簇、索引、日志、备份等数据的物理存储结构。
5.2，关系模式存取方法选择
数据库系统是多用户共享的系统，对同一个关系要建立多条存取路径才能满足多用户的多种应用要求。
数据库关系系统： ① B
+
树索引存取方法 ；② Hash
索引存取方法 ；③ 聚簇
存取方法；
B+树索引
选择索引存取方法 就是根据应用要求
确定
：
对哪些属性列建立索引、对哪些属性列建立组合索引、对哪些索引要设计为唯一索引。
选择索引存取方法的一般规则：
如果一个（或一组）属性经常在查询条件中出现，则
考虑在这个（或这组）属性上建立索引（或
组合索引
）。
如果一个属性经常作为最大值和最小值等聚集函数的
参数，则考虑在这个属性上建立
索引。
如果一个（或一组）属性经常在连接操作的连接
条件
中 出现，则考虑在这个（或这组）属性上建立
索引。
关系上定义的索引数过多会带来较多的额外开销，无论是维护还是
查找
HASH存取方法
选择
Hash
存取方法的
规则：
如果
一个关系的属性主要出现在等值连接条件中或主要出现在等值比较选择条件中，而且满足下列两个条件之一
该关系的大小可预知，而且不变；
该关系的大小动态改变，但所选用的数据库管理系统提供了动态Hash
存取方法。
聚簇存取方法
为了提高某个属性（或属性组）的查询速度，把这个或这些属性（称为聚簇码）上具有相同值的元组集中存放在连续的物理块上，称为
聚簇
。该
属性（或属性组）称为聚簇码
。许多
关系型数据库管理系统都提供了聚簇
功能。
聚簇索引：
建立
聚簇索引后，基表中数据也需要按指定的聚簇属性值的升序或降序存放。也即 聚簇索引的索引项顺序与表中元组的物理顺序一致。
一个数据库可以建立多个聚簇，一个关系只能加入一个聚簇。
聚簇索引的适用条件：
很少对基表进行增删操作；很少对其中的变长列进行修改操作；
聚簇索引的用图：
大大
提高按聚簇属性进行查询的
效率
节省存储空间 ：聚簇以后，聚簇码相同的元组集中在一起了，因而聚簇码值不必在每个元组中重复存储，只要在一组中存一次就行了。
聚簇索引的局限性：
聚簇
只能提高某些特定应用的性能
建立
与维护聚簇的开销相当
大；
对
已有关系建立聚簇，将导致关系中元组的物理存储位置移动，并使此关系上原有的索引无效，必须重建
。当
一个元组的聚簇码改变时，该元组的存储位置也要做相应改变
。
聚簇索引的适用范围：
既适用于单个关系独立聚簇，也适用于多个关系组合聚簇
当
通过聚簇码进行访问或连接是该关系的主要应用，与
聚簇
码无关的其他访问很少或者是次要的时，可以使用
聚簇。
尤其
当
SQL
语句中包含有与聚簇码有关的
ORDER BY, GROUP BY, UNION, DISTINCT
等子句或短语时，使用聚簇特别有利，可以省去或减化对结果集的排序操作
设计候选聚簇： ① 常
在一起进行连接操作的关系可以建立组合聚簇；
② 如果
一个关系的一组属性经常出现在相等比较
条件
中，则该单个关系可建立聚簇；
③ 如果
一个关系的一个（或一组）属性上的值
重复率
很高，则此单个关系可建立聚簇
。
检查候选聚簇索引中的关系，取消不必要的关系
① 从
聚簇中删除经常进行全表扫描的关系
② 从聚簇
中删除更新操作远多于连接操作的关系
③ 从
聚簇中删除重复出现的
关系
5.3，确定数据库的存储结构
确定数据库物理结构主要指确定数据的存放位置和存储结构，包括：确定关
系、索引、聚簇、日志、备份等的存储安排和存储结构，确定系统配置等。
影响数据存放位置和存储结构的因素：
硬件环境和应用需求；要综合考虑存取时间、存储空间利用率和维护代价（
这三个方面常常是相互矛盾的。比如：消除一切冗余数据虽能够节约存储空间和减少维护代价，但往往会导致检索代价的增加。必须进行权衡，选择一个折中方案。
）
确定数据的存放位置
原则：
根据应用情况
将易变
部分与稳定部分分开
存放，经常
存取部分与存取频率较低部分分开
存放。
① 可以将日志文件与数据库对象（表、索引等）放在不同的磁盘以改进系统的性能。
② 可以将比较大的表分别放在两个磁盘上，以加快存取速度，这在多用户环境下特别有效。
③ 数据库数据备份、日志文件备份等由于只在故障恢复时才使用，而且数据量很大，可以考虑存放在磁带上。
确定系统配置
①系统都为这些变量（ 同时使用数据库的用户数、同时打开的数据库对象数、内存分配参数、缓冲区分配参数（使用的缓冲区长度、个数）、存储分配参数 、物理块的大小、物理块装填因子、时间片大小、数据库的大小、锁的数目等 ）赋予了合理的缺省值。在进行物理设计时需要根据应用环境确定这些参数值，以使系统性能最优。
②在物理设计时对系统配置变量的调整只是初步的，要根据系统实际运行情况做进一步的调整，以切实改进系统性能。
5.4，评价物理结构
评价物理数据库的方法完全依赖于所选用的
DBMS
。
评价内容：
- 对数据库物理设计过程中产生的多种方案进行细致的评价；
- 定量估算各种方案的存储空间、存取时间、维护代价；
- 对估算结果进行权衡、比较，从中选择一个较优的合理的方案作为数据库的物理结构。
6，数据库的实施和维护
6.1，数据的载入和应用程序的调试
数据库实施阶段主要
工作：
①建立实际的数据库结构。
用
DDL
定义数据库：定义基本表、索引、约束、视图等；
②装入数据
，组织数据入库
(
又称数据库加载
)
，组织数据入库是数据库实施阶段最主要的工作。
数据装载方法：人工方法；计算机辅助方法
数据筛选、输入、转换(
工具
)
、校验，确保正确
③编制和调试数据库应用程序。
数据库应用程序的设计应该与数据库设计并行进行。数据库结构建立好后，就可以开始编制与调试数据库的应用程序。
6.2，数据库的试运行
数据库的试运行：
应用程序
调试完成，并且已有一小部分数据入库后，就可以开始对数据库系统进行联合调试，也称数据库的试运行。
主要工作包括 ：
① 功能测试：
实际运行应用程序，执行对数据库的各种操作，测试应用程序的各种功能。
② 性能测试：
测量系统的性能指标，分析是否符合设计目标。
★ 数据库性能指标的测量
① 数据库物理设计阶段在评价数据库结构估算时间、空间指标时，作了许多简化和假设，忽略了许多次要因素，因此结果必然很粗糙。
② 数据库试运行则是要实际测量系统的各种性能指标（不仅是时间、空间指标），如果结果不符合设计目标，则需要返回物理设计阶段，调整物理结构，修改参数；有时甚至需要返回逻辑设计阶段，调整逻辑结构。
★ 数据的分期入库
① 重新设计物理结构甚至逻辑结构，会导致数据重新入库
② 由于数据入库工作量实在太大，所以可以采用分期输入数据的方法
- 先输入小批量数据供先期联合调试使用
- 待试运行基本合格后再输入大批量数据
- 逐步增加数据量，逐步完成运行评价
★ 数据库的转储和恢复
① 在数据库试运行阶段，系统还不稳定，硬、软件故障随时都可能发生
② 系统的操作人员对新系统还不熟悉，误操作也不可避免
③ 因此必须做好数据库的转储和恢复工作，尽量减少对数据库的破坏
6.3，数据库的运行和维护
在数据库运行阶段，对数据库经常性的维护工作主要是由数据库管理员完成的，包括：
① 数据库的转储和恢复
- 数据库管理员要针对不同的应用要求制定不同的转储计划，定期对数据库和日志文件进行备份。
- 一旦发生介质故障，即利用数据库备份及日志文件备份，尽快将数据库恢复到某种一致性状态
② 数据库 的安全性、完整性控制
初始定义
- 数据库管理员根据用户的实际需要授予不同的操作权限
- 根据应用环境定义不同的完整性约束条件
修改定义
- 当应用环境发生变化，对安全性的要求也会发生变化，数据库管理员需要根据实际情况修改原有的安全性控制
- 由于应用环境发生变化，数据库的完整性约束条件也会变化，也需要数据库管理员不断修正，以满足用户要求
③ 数据库性能的监督、分析和改进
在数据库运行过程中，数据库管理员必须监督系统运行，对监测数据进行分析，找出改进系统性能的方法。
- 利用监测工具获取系统运行过程中一系列性能参数的值
- 通过仔细分析这些数据，判断当前系统是否处于最佳运行状态
- 如果不是，则需要通过调整某些参数来进一步改进数据库性能
④ 数据库的重组织与重构造
**数据库
的重组织**
为什么要重组织
数据库
数据库
运行一段时间后，由于记录的不断增、删、改，会使数据库的物理存储变坏，
从而
降低数据库存储空间的利用率和数据的存取效率，使数据库的性能下降
。
重组织的
形式：
全部
重
组织和部分
重
组织，只
对频繁增、删的表进行重组织
重组织的
目标：
提高
系统性能
数据库的重构造
为什么要
重构造数据库
数据库
应用环境发生变化，会导致实体及实体间的联系也发生相应的变化，使原有的
数据库
设计不能很好地满足新的
需求。
重构造的主要工作
根据新环境调整数据库的模式和
内模式增加
或删除某些
数据项
、
改变
数据项的
类型、增加
或删除某个
表、改变
数据库的
容量、增加
或删除某些索引。
重构造数据库的程度是
有限的
若
应用变化太大，已无法通过重构数据库来满足新的需求，或重构数据库的代价太大
，
则
表明现有数据库应用系统的生命周期已经结束，应该重新设计新的数据库应用系统了。
68747470733a2f2f62:6c6f672e6373646e2e6e65742f71715f34323139323639332f:61727469636c652f64657461696c732f313039373230393430