数据库重构

瀑布是美妙的旅游景点。但用来组织软件开发项目，瀑布式却是一种特别差劲的策略。

——Scott Ambler现代软件过程，也称为方法学，在本质上都是演进式的，要求你以迭代和增量的方式工作。这些过程的例子包括Rational统一过程 （RUP）、极限编程（XP）、Scrum、动态系统开发方法（DSDM）、水晶方法系列、团队软件过程（TSP）、敏捷统一过程（AUP）、企业统一过 程（EUP）、特征驱动开发（FDD）和快速应用开发（RAD），等等。工作以迭代的方式进行，你在一段时间内，每项活动做一点，例如建模、测试、编码或 部署，然后是下一个迭代，再下一个迭代。这种过程有别于串行的方式，在串行方式中，你首先确定所有打算实现的需求，然后创建详细的设计，实现该设计并进行 测试，最后部署你的系统。在增量式的开发方式中，你会把系统组织成一系列的发布版本，而不是一个大的发布版本。

而且，许多现代过程是敏捷的，为简单起见，我们把这些过程的特点归结?局噬系难萁揭约案叨刃鳌５蓖哦硬扇∫恢中鞯姆绞绞保腔嶂鞫匮扒笥 行ぷ鞯姆椒ǎ荒闵踔劣Ω贸⑹匀靡滴窆丝驼庋南钅可嬷冢╯takeholder）也成为积极的团队成员。Cockburn（2002）建议，你应该 追求采用适合你情况的“最热”的沟通技巧：面对面围绕一块白板的对话要优于打电话，打电话要优于发送Email，发送Email要优于发送一份详细的 文档。软件开发团队内部的沟通和协作越好，你成功的机会就越大。

尽管演进式和敏捷的工作方式已经在开发社区中得到了采用，但在数据社区中，情况却还不是这样。大多数面向数据的技术在本质上是串行式的，要求先创建 相当详细的模型，然后才“允许”开始实现。更糟糕的是，这些模型常常被基线化，并纳入变更管理控制之下，以期尽量减少变化（如果你考虑到最终效果，这应该 被称为一个变更防止过程）。这其中出现了摩擦：一般的数据库开发技术没有反映出现代软件开发过程的实际情况。事情并非一定如此。

我们的前提是，数据专家需要像开发人员一样，采用演进式技术。虽然你可以争辩说，在数据社区中开发人员应该回到“经检验正确”的传统开发方式，但是 传统的方式不能很好地工作，这一点正变得越来越明显。Craig Larman在他的著作（Larman，2004）的第5章Agile & Iterative Development中总结了支持演进式开发的研究证据，以及信息技术（IT）社区中的领导者对演进式开发的压倒性支持。简单地说，与在数据社区中流行 的传统技术相比，在开发社区中流行的演进式和敏捷技术工作得更好。

数据专家也可以在他们工作的各个方面采用演进式技术，如果他们愿意的话。第一步是重新考虑你的IT组织中的“数据文化”，以反映现代IT项目团队的 需要。敏捷数据（AD）方法（Ambler 2003）正是这样做的，它描述了现代面向数据的活动中的一些原则和角色。这些原则反映出数据如何成为商业软件的诸多重要方面之一，暗示开发人员需要更擅 长数据技术，数据专家需要学习现代的开发技术与技能。AD方法意识到每个项目团队都是独特的，需要遵守一个按照他们的情况进行剪裁的过程。超越你当前的项 目而考虑整个企业的问题，这一点也得到了强调。因为像操作型数据库管理员和数据架构师这样的企业专家需要这样做，才能灵活地与采用敏捷方式的项目团队共同 工作。

第二步是针对数据专家的，特别是数据管理人员。他们要采用新的技术，确保他们能以一种演进式的方式工作。在本章中，我们简单地介绍了这些关键的技术。在我们看来，最重要的技术就是数据库重构，这就是本书关注的重点。演进式数据库开发技术包括：

1. 数据库重构。让现有的数据库schema每次演进一点，在不改变语义的情况下改善其设计质量。

2. 演进式数据建模。以迭代和增量的方式对系统的数据进行建模，就像对系统的其他方面进行建模时一样，从而确保数据库schema与应用的代码一起演进。

3. 数据库回归测试。确保数据库schema确实能工作。

4. 数据库工件的配置管理。你的数据模型、数据库测试、测试数据等都是重要的项目工件（artifact），应该像其他工件那样管理起来。

5. 开发者沙盒。开发者需要属于他们自己的工作环境，他们可以在其中修改正在构建的系统的一部分，使这部分修改能工作，然后再将他们的工作与其他团队成员的工作集成起来。

让我们来仔细考虑一下每一种演进式数据库技术。

1.1 数据库重构

重构（Fowler 1999）是一种训练有素的方式，对源代码进行小的改动以改进其设计，使代码处理起来变得更容易。重构的一个关键方面是，它保持了代码的行为语义——你在 重构时既不添加东西也不减少东西，你只是改进代码的质量。重构的一个例子可以是将getPersons()操作改名为getPeople()。为了实现这 一重构，你必须改变操作定义，然后改变应用代码中所有对这个操作的调用。直到所有的代码重新运行之后，重构才算完成。

类似地，数据库重构是对数据库schema进行的简单改动，在保持其行为和信息语义的前提下改进其设计。你既可以重构数据库schema的结构部 分，如表和视图的定义，也可以重构其功能部分，如存储过程和触发器。当你重构数据库schema时，不仅需要改变schema本身，也需要修改与你的 schema耦合在一起的外部系统，如业务应用或数据extract。数据库重构明显地要代码重构更难以实现，因此你需要小心。数据库重构将在第2章中详 细描述，执行数据库重构的过程将在第3章中描述。