变更管理的原则是()和变更管理过程规范化。<br />

变更是指在信息系统项目的实施过程中，由于项目环境或者其他的各种原因对项目的部分或项目的全部功能、性能、体系结构、技术、指标、集成方法和项目进度等方面做出改变。项目变更是正常的、不可避免的。在项目实施过程中，变更越早，损失越小；变更越迟，难度越大，损失也越大。项目在失控的情况下，任何微小变化的积累，最终都会对项目的质量、成本和进度产生较大影响，这是一个从量变到质变的过程。

变更产生的原因主要有以下几个方面：

（1）项目外部环境发生变化，例如政府政策的变化。

（2）项目总体设计、项目需求分析不够周密详细，有一定的错误或遗漏。

（3）新技术的出现，设计人员提出了新的设计方案或新的实现手段。

（4）建设单位由于机构重组等原因造成业务流程的变化。

配置库

配置库也称为配置项库，是用来存放配置项的工具。配置库记录与配置相关的所有信息，其中存放受控的配置项是很重要的内容，利用库中的信息可评价变更的后果，这对变更控制有着重要的意义。

配置库有3类：

（1）开发库（development library）。存放开发过程中需要保留的各种信息，供开发人员个人专用。库中的信息可能有较为频繁的修改，只要开发库的使用者认为有必要，无须对其做任何限制。因为这通常不会影响到项目的其他部分。开发库对应配置管理系统中的动态系统（开发者系统、开发系统、工作空间）。

（2）受控库（controlled library）。在信息系统开发的某个阶段工作结束时，将工作产品存入或将有关的信息存入。存入的信息包括计算机可读的，以及人工可读的文档资料。应该对库内信息的读写和修改加以控制。受控库也称为主库，对应配置管理系统中的主系统（受控系统）。

（3）产品库（product library）。在开发的信息系统产品完成系统测试之后，作为最终产品存入库内，等待交付用户或现场安装。库内的信息也应加以控制。产品库也称为备份库，对应配置管理系统中的静态系统（受控系统）。

作为配置管理的重要手段，上述受控库和产品库的规范化运行能够实现对信息系统配置项的管理。

变更控制

变更控制系统是一套事先确定的修改项目文件或改变项目活动时应遵循的程序，其中包括必要的表格或其他书面文件，责任追踪，以及变更审批制度、人员和权限。变更控制系统应当明确规定变更控制委员会的责任和权力，并由所有的项目干系人认可。在审批变更时，要加强对变更风险和变更效果的评估，并选择对项目影响最小的变更方案，尽量防止增加项目投资。变更控制系统可细分为整体、范围、进度、费用和合同变更控制系统。变更控制系统应当同项目管理信息系统一起通盘考虑，形成整体。

变更控制委员会

变更控制委员会（Change Control Board, CCB）也称为配置控制委员会（Configuration Control BoarD），其任务是对建议的配置项变更做出评价、审批，以及监督已批准变更的实施。CCB的成员通常包括项目经理、用户代表、质量控制人员、配置控制人员。这个组织不必是常设机构，可以根据工作的需要组成，其中的人员可以是全职的，也可以是兼职的。

如果CCB不只是控制变更，而是承担更多的配置管理任务，那就应该包括基线的审定、标识的审定，以及产品的审定，并且可能实际的工作需分为项目层、系统层和组织层来组建，使其完成不同层面的配置管理任务。

变更控制的流程

变更管理的基本流程如下：

（1）变更申请。应记录变更的提出人、日期、申请变更的内容等信息。

（2）变更评估。对变更的影响范围、严重程度、经济和技术可行性进行系统分析。

（3）变更决策。由具有相应权限的人员或机构决定是否实施变更。

（4）变更实施。由管理者指定的工作人员在受控状态下实施变更。

（5）变更验证。由配置管理人员或受到变更影响的人对变更结果进行评价，确定变更结果和预期是否相符、相关内容是否进行了更新、工作产物是否符合版本管理的要求。

（6）沟通存档。将变更后的内容通知可能会受到影响的人员，并将变更记录汇总归档。如提出的变更在决策时被否决，其初始记录也应予以保存。

变更申请需要采用书面的形式提出，主要内容有如下3个方面：

（1）变更描述。包括变更理由、变更的影响、变更的优先级等，就是要申述做什么变更，为什么要做，以及打算怎么做的问题。

（2）对变更的审批。对变更的必要性、可行性的审批意见，主要是由配置管理员和CCB对此项变更把关。

（3）变更实施的信息。

利用配置库实现变更控制

配置项可以有3种状态，分别是工作状态、评审状态和受控状态。开发中的配置项尚未稳定下来，对于其他配置项来说是处于不处理工作状态下（自由状态），此时它并未受到配置管理的控制，开发人员的变更并未受到限制。但当开发人员认为工作已告完成，可供其他配置项使用时，它就开始稳定。把它交出评审，就开始进入评审状态；若通过评审，可作为基线进入配置库（实施检入），开始冻结，此时开发人员不允许对其做任意修改，因为它已处于受控状态。通过评审表明它确已达到质量要求；但若未能通过评审，则将其回归到工作状态，重新进行调整。配置项的状态变化过程如下图所示。

配置项的状态变化过程

处于受控状态下的配置项原则上不允许修改，但这不是绝对的，如果由于多种原因需要变更，就需要提出变更请求。在变更请求得到批准的情况下，允许配置项从库中检出，待变更完成，并经评审后，确认变更无误方可重新入库，使其恢复到受控状态。

规范化

关系数据库设计的方法之一就是设计满足适当范式的模式，通常可以通过判断分解后的模式达到几范式来评价模式规范化的程度。范式有：1NF、2NF、3NF、BCNF、4NF和5NF，其中1NF级别最低。这几种范式之间

成立。

通过分解，可以将一个低一级范式的关系模式转换成若干个高一级范式的关系模式，这种过程叫作规范化。下面将给出各个范式的定义。

1NF（第一范式）

【定义7.10】若关系模式R的每一个分量是不可再分的数据项，则关系模式R属于第一范式。记为R∈1NF。

例如，供应者和它所提供的零件信息，关系模式FIRST和函数依赖集F如下：

FIRST（Sno，Sname，Status，City，Pno，Qty）

F=｛Sno→Sname，Sno→Status，Status→City，（Sno，Pno）→Qty｝

对具体的关系FIRST如下表所示。从下表中可以看出，每一个分量都是不可再分的数据项，所以是1NF的。但是，1NF存在4个问题：

FIRST

（1）冗余度大。例如每个供应者的Sno、Sname、Status、City要与其供应的零件的种类一样多。

（2）引起修改操作的不一致性。例如供应者S1从“天津”搬到“上海”，若不注意，会使一些数据被修改，另一些数据未被修改，导致数据修改的不一致性。

（3）插入异常。关系模式FRIST的主码为Sno、Pno，按照关系模式实体完整性规定主码不能取空值或部分取空值。这样，当某个供应者的某些信息未提供时（如Pno），则不能进行插入操作，这就是所谓的插入异常。

（4）删除异常。若供应商S4的P2零件销售完了，并且以后不再销售P2零件，那么应删除该元组。这样，在基本关系FIRST找不到S4，可S4又是客观存在的。

正因为上述4个原因，所以要对模式进行分解，并引入了2NF。

2NF（第二范式）

【定义7.11】若关系模式R∈1NF，且每一个非主属性完全依赖于码，则关系模式R∈2NF。

换句话说，当1NF消除了非主属性对码的部分函数依赖，则称为2NF。

例如，FIRST关系中的码是Sno、Pno，而Sno→Status，因此非主属性Status部分函数依赖于码，故非2NF的。

若此时，将FIRST关系分解为：

FIRST₁（Sno，Sname，Status，City）∈ 2NF

FIRST₂（Sno，Pno，Qty）∈2NF

因为分解后的关系模式FIRST1的码为Sno，非主属性Sname、Status、City完全依赖于码Sno，所以属于2NF；关系模式FIRST₂的码为Sno、Pno，非主属性Qty完全依赖于码，所以也属于2NF。

3NF（第三范式）

【定义7.12】若关系模式R（U，F）中不存在这样的码X，属性组Y及非主属性

使得X→Y，

成立，则关系模式R∈3NF。

即当2NF消除了非主属性对码的传递函数依赖，则称为3NF。

例如，FIRST₁?3NF，因为在分解后的关系模式FIRST₁中有Sno→Status，Status→City，存在着非主属性City传递依赖于码Sno。若此时将FIRST₁继续分解为：

FIRST₁₁（Sno，Sname，Status）∈ 3NF

FIRST₁₂（Status，City）∈3NF

通过上述分解，数据库模式FIRST转换为FIRST₁₁（Sno，Sname，Status）、FIRST₁₂（Status，City）、FIRST₂（Sno，Pno，Qty）三个子模式。由于这三个子模式都达到了3NF，因此称分解后的数据库模式达到了3NF。

可以证明，3NF的模式必是2NF的模式。产生冗余和异常的两个重要原因是部分依赖和传递依赖。因为3NF模式中不存在非主属性对码的部分函数依赖和传递函数依赖，所以具有较好的性能。对于非3NF的1NF、2NF其性能弱，一般不宜作为数据库模式，通常要将它们变换成为3NF或更高级别的范式，这种变换过程称为“关系模式的规范化处理”。

BCNF（Boyce Codd Normal Form，巴克斯范式）

【定义7.13】关系模式R∈1NF，若X→Y且

时，X必含有码，则关系模式R∈BCNF。

也就是说，当3NF消除了主属性对码的部分函数依赖和传递函数依赖，则称为BCNF。

结论：一个满足BCNF的关系模式，应有如下性质。

（1）所有非主属性对每一个码都是完全函数依赖。

（2）所有非主属性对每一个不包含它的码，也是完全函数依赖。

（3）没有任何属性完全函数依赖于非码的任何一组属性。

例如，设R（Pno，Pname，Mname）的属性分别表示零件号、零件名和厂商名，如果约定，每种零件号只有一个零件名，但不同的零件号可以有相同的零件名；每种零件可以有多个厂商生产，但每家厂商生产的零件应有不同的零件名。这样我们可以得到如下一组函数依赖：

Pno→Pname，（Pname，Mname）→Pno

由于该关系模式R中的候选码为（Pname，Mname）或（Pno，Mname），因而关系模式R的属性都是主属性，不存在非主属性对码的传递依赖，所以R是3NF的。但是，主属性Pname传递依赖于码（Pname，Mname），因此R不是BCNF的。当一种零件由多个生产厂家生产时，零件名与零件号间的联系将多次重复，带来冗余和操作异常现象。若将R分解成：

R1（Pno，Pname）和R2（Pno，Mname）

就可以解决上述问题，并且分解后的关系模式R1、R2都属于BCNF。

4NF（第四范式）

【定义7.14】关系模式R∈1NF，若对于R的每个非平凡多值依赖X→→Y且

时，X必含有码，则关系模式R（U，F）∈4NF。

4NF是限制关系模式的属性间不允许有非平凡且非函数依赖的多值依赖。

注意：如果只考虑函数依赖，关系模式最高的规范化程度是BCNF；如果考虑多值依赖，关系模式最高的规范化程度是4NF。

连接依赖5NF

连接依赖：当关系模式无损分解为n个投影（n>2）会产生一些特殊的情况。下面考虑供应商数据库中SPJ关系的一个具体的值，如下图所示。

关系SPJ是三个二元投影的连接

第一次SP、PJ投影连接“

”起来的结果比原始SPJ关系多了一个元组“S2，P1，J2”，即上图中带下画线的元组。第二次连接的结果去掉了多余的元组，从而恢复了原始的关系SPJ。在这种情况下，原始的SPJ关系是可3分解的。注意，无论我们选择哪两个投影作为第一次连接，结果都是一样的，尽管在每种情况下中间结果不同。

SPJ的可3分解性是基本与时间无关的特性，是关系模式的所有合法值满足的特性，也就是说，这是关系模式满足一个特定的与时间无关的完整性约束。将这种约束简称为3D（3分解）约束。上述情况就是连接依赖要研究的问题。

连接依赖：如果给定一个关系模式R，R₁，R₂，R₃，…，R_n是R的分解，那么称R满足连接依赖JD^*｛R₁，R₂，R₃，…，R_n｝，当且仅当R的任何可能出现的合法值都与它在R₁，R₂，R₃，…，R_n上的投影等价。

形式化地说，若R=R₁∪R₂∪…∪R_n，且

，则称R满足连接依赖JD^*｛R₁，R₂，R₃，…，R_n｝。如果某个R_i，就是R本身，则连接依赖是平凡的。

为了进一步理解连接依赖的概念，我们考虑银行数据库中的子模式：贷款（L-no，Bname，C-name，amount）。其中：

.贷款号为L-no的贷款是由机构名为Bname贷出的。

.贷款号为L-no的贷款是贷给客户名为C-name的客户。

.贷款号为L-no的贷款的金额是amount。

我们可以看到这是一个非常直观的逻辑蕴涵连接依赖：

JD^*（（L-no，Bname），（L-no，C-name），（L-no，amount））

这个例子说明了连接依赖很直观，符合数据库设计的原则。

【定义7.15】一个关系模式R是第五范式（也称投影-连接范式PJNF），当且仅当R的每一个非平凡的连接依赖都被R的候选码所蕴涵，记作5NF。

“被R的候选码所蕴涵”的含义可通过SPJ关系来理解。关系模式SPJ并不是5NF的，因为它满足一个特定连接依赖，即3D约束。这显然没有被其唯一的候选码（该候选码是所有属性的组合）所蕴涵。其区别是，关系模式SPJ并不是5NF，因为它是可被3分解的，可3分解并没有为其（Sno，Pno，Jno）候选码所蕴涵。但是将SPJ3分解后，由于3个投影SP、PJ、JS不包括任何（非平凡的）连接依赖，因此它们都是5NF的。

更多复习资料
请登录电脑版软考在线 www.rkpass.cn

京B2-20210865 | 京ICP备2020040059号-5