*** 改变数据库计划
*** 进行数据迁移
*** 改变数据库存取代码
于是当描述数据库重构时，我们必须描述变化的三个方面，并确保在应用另一个重构之前完成了这三种变化。
我们必须文档化不同的数据库重构，因此我们还不能详细描述他们。然而这里有几点需要指出：像代码重构一样，数据库重构非常微小。概念链一系列微小的变化，数据库和代码很相似。变化的三个属性使保持小的变化更加重要。
许多数据库重构，如增加一个字段，可以不必更新所有存取系统的代码来完成。但是如果在使用新计划之前并不了解它，该字段将会无用，因为新计划不知道其变化之处。许多变化，没有考虑整个系统计划，我们称之为破坏性变化，如将一个已经存在的空值列设置为非空。破坏性变化需要多加留心，留心的程度依赖于包含破坏性的程度。一个小破坏性的例子是将一个已经存在的空值列设置为非空，在这种情况下你可以蒙着头做。
而重构将考虑数据库中空值数据。开发人员将更新数据库映射代码，因此更新不会破坏其它人的代码；如果偶然会破坏，开发人员将在建立和使用测试时发现问题。
将一个经常使用的表分成两个是一种更复杂的破坏。在这种情况中提前让所有人知道变化到来很重要，这样他们可以有所准备。此外应该在一个更安全的时刻来实施变化。
这里面很重要的一点是选择适用于你做出的变化的过程。
3.6自动重构
在代码世界中许多语言能够实现自动重构。在计划变化和数据迁移过程中，这种自动化对于数据库也非常重要。因此每个数据库重构都可以通过编写SQL DDL（对于计划变化）和DML（对于数据迁移）来完成。这些变化不是通过手工实现，而是通过一些SQL语句来自动实现变化。
一旦完成代码，我们保存这些代码文件来产生数据库变化的完整的变化记录，作为数据库重构的结果。我们于是可以更新任何实例到最新的主数据库，通过运行在我们拷贝主数据库来产生更早的数据库实例的变化记录。
自动化变化的序列化是对于持续集成和迁移产品数据库的一个基本功能。
为了最后产品数据库我们并不在常规迭代周期中实施变化。我们在每一个发布之间建立完整的数据库重构变化日志。毫无疑问，这是一个巨大的变化，我们必须离线实施该变化。在实际应用之前先测试迁移计划绝对是明智之举。迄今为止，这项技术相当管用。通过将大变化分解为小的简单的变化，我们可以对产品数据进行大的变化，同时又不会给我们太多的麻烦。套用兵法中的一句话，就是“化整为零”。
除了自动化向前的变化，我们也要考虑重构时向后的变化。如果能够做到这样就可以回到以前的数据库状态。在我们的项目中并没有这样做，因为没有这个需求，但这同样是很重要的基本原则。
3.7自动地更新所有开发人员的数据库
人们变化和更新主数据库，但是如何发现主数据库已经发生变化？在传统的持续集成有源代码的环境中，开发人员在提交变化之前先更新主数据库。这样他们就可以在提交变化给共享主数据库之前，解决他们自己的机器上的问题。
每次主数据库发生改变时，我们都要更新开发人员的数据库。当主数据库发生变化时，我们自动化更新所有项目成员的数据库。相同的重构代码更新主数据库上的同时，自动更新成员数据库。也许有人认为在开发人员不知情的情况下，更新开发人员数据库会产生很多问题，但在实践中我们没发现什么问题。当然，这只在人们联网时管用。所以当开发人员离线时，必须尽快与主数据库重新保持同步。
3.8清晰地分离所有的数据库获取代码
为了理解数据库重构的结果，了解应用程序如何使用数据库也非常重要。如果SQL语句分布在代码基础周围，则很难这样去做。因此一个清晰的数据库获取层很重要，它用来显示数据库如何被使用，在哪里被使用。
清晰的数据库层有很多好处。它减少了开发人员操纵数据库时需要使用SQL知识的地方，这样使对SQL语句不太熟悉的开发人员更易开发。对于DBA来说，给他提供了清晰的代码，可以清楚地了解数据库将如何使用。这也帮助准备索引、数据库优化，优化SQL语句，使DBA更好地理解数据库如何被使用。
4变化法则
如同任何实践一样，这些原则必须根据你特殊的环境变化。没有一成不变的项目，我们必须要应对变化。
4.1保持多个数据库在一个系统中
简单项目也许只需要一个主数据库。但是复杂项目需要有多个数据库，即数据库系。如果在投入生产之前数据库必须分支，那么我们可以创建新的数据库系。数据库系类似于代码的分支，需要不同测试数据集来进行测试。
当开发人员从主数据库中获取了一份拷贝，必须注册他们在修改哪个数据库系。当DBA更新主数据库某个数据库系时，同时更新了所有注册这个数据库系的开发人员的数据库。
4.2不需要专职的DBA
所有这些听上去好像需要大量的工作，但它并不需要大量的人力资源。在最大的项目中，我们有30个开发人员，项目组规模100人（包括质量评价、分析人员和管理人员），我们大概有100多个不同系列的产品分布在各工作站上。但所有这些工作只需要一个专职DBA，只有两个编程人员业余帮忙。
在小项目中甚至不需要专职DBA。当我们将这些技巧用于更小的项目--12人左右的小项目时，发现该项目不需要一个专职的DBA。与此相反，我们依靠两个对数据库感兴趣的开发人员业余处理DBA任务。
这是自动化的功劳。如果对每项任务进行自动化处理，就可以用更少的人来完成更多的工作。
5辅助工具
数据库进化需要大量的重复性工作，我们可以开发一些简单工具来帮助我们解决大量的重复性工作。
自动化的最有价值的地方就是有一个通用数据库任务简单代码集。自动化的任务包括：
*** 用户资料与现在管理员的资料一致
*** 创建新用户
*** 复制数据库计划并协同修改
*** 移动并合成数据库
*** 删除用户
*** 导出用户，这样项目组成员可以分发离线数据库备份。
*** 导入用户，这样项目组成员可以拥有数据库备份，导入数据库，创建新计划。
*** 导出基线，将主数据库进行备份，这是导出用户的一个特例。
*** 创建不同计划的报告，以便比较。
*** 将计划与主计划作比较，这样开发人员就可以将他们本地拷贝与主数据库作比较
*** 列出所有的用户
分析人员和质量评价人员常常会去看测试数据，并且需要改变他们。因此我们用VBA语句开发一个Excel应用程序，从数据库里面提取数据到Excel文件中，允许用户修改这个文件，修改后又返回到数据库中去。当然，也可以使用其他工具来浏览和编辑数据库的内容，但是我们使用excel，因为很多人熟悉它。
项目组的所有成员应该很容易获取数据库设计的详细内容，从而发现什么表格可以获得，以及如何使用这些表格。我们建立了基于HTML的工具，使用servlets来查询数据库元数据。因此开发人员在添加字段之前，可以先通过搜索表和字段的元数据来看一看数据库中有没有这个字段。我们使用Erwin建模，将数据从Erwin提取到我们的元数据表中。
6结束语
当然，这并不是敏捷方法在数据库设计中的全部应用，也不是数据库进化设计的全部，还有集成数据库和24*7小时实施以及其他一些没有解决的问题，数据库进化设计还需要进行进一步的研究工作。
文章来源于领测软件测试网 https://www.ltesting.net/