重构的价值是毋庸置疑的，这已在许多项目中证明了。重构能帮助软件专业人士改进系统设计及其可维护性、可扩展性和性能。本书首次介绍了专门针对数据库系统设计的强大的重构技术。
　　作者向读者充分展示了：对表结构、数据、存储过程和触发器的小小改动就能在很大程度上改进数据库的设计，同时又不改变语义。读者还将学到分步演进数据库模式以及源代码的方法，使依赖迭代、敏捷方法开发的项目变得更高效。
　　本书为数据库重构提供了全面的指导和参考，介绍了数据库重构的基本概念，帮助读者克服重构真实数据库系统时的实践障碍。通过完整的例子，作者展示了重构简单的单个数据库应用和复杂的多个应用的情况。通过本书，读者可以掌握重构数据库模式所涉及的各项任务，学习在最复杂的产品环境中部署重构的最佳实践。
　　本书系统介绍了5类主要的数据库重构技术。读者将看到如何利用重构来增强数据库结构、数据质量和参照完整性，以及如何对架构和方法进行重构。本书提供了大量的基于Oracle和Java的例子，读者可以很方便地调整到其他语言，如C#、C++或VB.NET，或其他数据库，如DB2、SQL Server、MySQL和Sybase。
　　利用本书提供的技术和例子，读者在进行数据库重构时可以减少浪费和风险，避免返工并节约成本，可以平滑地演进数据库系统，延长数据库的使用寿命。

无

演进式开发以及敏捷软件开发方法学，如极限编程（XP）、Scrum、Rational统一过程（RUP）、敏捷统一过程（AUP）和特征驱动开发（FDD），已经在过去几年中为信息技术（IT）产业带来了一场风暴。为了明确定义，演进式方法在本质上是迭代式和增量式的，敏捷方法在本质上是演进式和高度协作的。而且，像重构、结对编程、测试驱动开发（TDD）和敏捷模型驱动开发（AMDD）等敏捷技术也正在进入IT组织机构中。这些方法和技术已经形成，并在这些年里以草根的方式演进着，在实战中得到检验，而不是在象牙塔中形式化。简而言之，这些演进式开发和敏捷方法学似乎在实践中非常有效。
　　在Martin Fowler的开创性著作《Refactoring》中，他将重构描述为对源代码的一些小改动，这些改动会改进代码的设计，但不会改变其语义。换言之，你改进了工作的品质，但不会破坏或增加任何东西。在那本书中Martin提到，正如可以重构应用源代码一样，你也可能重构数据库schema(模式)。但是，他指出数据库重构相当困难，因为数据库中有相当程度的耦合，因此他选择不在他的书中讨论这部分内容。
　　自1999年《Refactoring》出版以来，我们俩发现了一些重构数据库schema的方法。开始，我们是独自工作的，在Software Development（wwwsdexpocom）等一些会议上见面，并通过邮件列表（wwwagiledataorg/feedbackhtml）交流。我们讨论一些思想，参加对方的会议报告，很快发现彼此的思想和技术有着共同之处，并且相互吻合。所以我们合作编写了本书，分享我们在通过重构演进数据库schema方面的经验和技术。
　　本书中的示例代码是用Java、Hibernate和Oracle编写的。对于每一类数据库重构，描述时基本上都包含了修改数据库schema的代码；对于一些更有趣的重构，我们展示了它们对Java 应用代码所产生的影响。因为各种数据库并不一样，所以我们也讨论了当数据库产品之间存在重要差别时一些替代的实现策略。有时候，我们讨论一类重构的替代实现，这类重构使用了Oracle专有的特征，如SET UNUSED或RENAME TO等命令；我们的许多代码示例也用到了Oracle 的COMMENT ON特征。有些数据库包含另外一些使数据库重构变得容易的特征，好的DBA会知道如何利用这些特征。更好的是，将来数据库重构工具会为我们完成这些事情。而且，我们尽可能使Java代码保持简单，这样读者应该能够毫无困难地将这些代码转换成C#、C++或Visual Basic代码。
　　为何需要演进式数据库开发
　　演进式数据库开发是一个适时出现的概念。不是在项目的前期试图设计数据库schema，而是在整个项目生命周期中逐步地形成它，以反映项目涉众确定的不断变化的需求。不论你是否喜欢，需求会随着项目的推进而变化。传统的方式是忽略这个基本事实并试图以各种方式来“管理变更”，这实际上是对阻止变更的一种委婉的说法。现代开发技术的实践者们选择拥抱变化，并使用一些技术，从而能够随着需求的变化演进他们的工作。程序员们采用了TDD、重构和AMDD等技术，创建了新的开发工具使这些技术变得更容易。我们实现了这些之后，意识到还需要一些技术和工具来支持演进式数据库开发。
　　以演进的方式进行数据库开发有以下好处：
　　1 将浪费减至最少。演进的、即时（JIT）的生产方式能够避免一些浪费，
在串行式开发方式中，如果需求发生变化，这些浪费是不可避免的。如果后来发现某项需求不再需要，所有对详细需求、架构和设计工件方面的早期投资都会损失掉。如果有能力事先完成这部分工作，那肯定也有能力以JIT的方式来完成同样的工作。
　　2 避免了很多返工。在第1章将会看到，仍需要进行一些初始的建模工作，
将主要问题前期想清楚，如果在项目后期才确定这些问题，可能会导致大量返工。你只是不需要很早涉及其中的细节。
　　3 总是知道系统可以工作。通过演进的方式，定期产生能够工作的软件，
即使只是部署到一个演示环境中，它也能工作。如果每一两周就得到一个系统的可工作版本，就会大大地降低项目的风险。
　　4 总是知道数据库设计具有最高的品质。这就是数据库重构所关注的：每
次改进一点schema设计。
　　5 与开发人员的工作方式一致。开发人员以演进的方式工作，如果数据专
业人员希望成为现代开发团队中的有效成员，他们也需要以演进的方式工作。
　　6 减少了总工作量。以演进的方式工作，只需要完成今天真正需要完成的
工作，没有其他工作。
　　演进式数据库开发也有一些不足之处：
　　1 存在文化上的阻碍。许多数据专业人员喜欢按串行式的方式进行软件开
发，他们常持这样的观点：在编程开始之前，必须创建某种形式的详细逻辑和物理数据模型。现代方法学已经放弃了这种方式，因为它效率不高，风险较大，因此许多数据专业人员受到了冷遇。更糟糕的是，数据社区中的许多“思想领袖”是在20世纪70年代和80年代获得他们的初步经验的，但却错过了90年代的对象革命，因此没有取得演进式开发方面的经验。世界已经改变，而他们似乎没有跟着改变。读者会在本书中看到，数据专业人员不仅可能以演进的方式工作，实际上这也是比较可取的工作方式。
　　2 学习曲线。需要花时间来学习这些新技术，甚至需要花更多的时间将串
行式的思维方式转变成演进式的思维方式。
　　3 工具支持还在发展之中。当《Refactoring》在1999年出版时，没有支持这一技术的工具。短短几年之后，每种集成开发环境（IDE）都内建支持代码重构的特征。在本书写作时，还没有数据库重构的工具，尽管我们在书中包含了手工实现重构所需的全部代码。幸运的是，Eclipse Data Tools Project（DTP）已经在他们的项目计划书中说明需要在Eclipse中开发数据库重构功能，所以工具厂商赶上来只是时间问题。
　　敏捷简介
　　虽然这不是一本专门讲述敏捷软件开发的图书，但实际上数据库重构是为敏捷开发者准备的主要技术。如果一个过程满足敏捷联盟（wwwagileallianceorg）的4种价值观，它就被认为是敏捷的。这些价值观定义了一些偏好，而不是以某种方式取代另一种方式；鼓励关注特定领域，但并不排除其他领域。例如，过程和工具是重要的，但个人和他们之间的互动更重要。这4种敏捷价值观如下：
　　1 个人和他们之间的互动胜过过程和工具。需要考虑的最重要的因素是人
以及他们如何一起工作；如果没有找对人，最好的工具和过程都会毫无用处。
　　2 工作的软件胜过面面俱到的文档。软件开发的主要目标是创建能工作的
软件，满足项目涉众的要求。当然文档也有它的位置，编写得当的话，它能描述系统如何构建，为什么构建，以及如何利用系统工作。
　　3 顾客协作胜过合同谈判。只有顾客能告诉你他们想要什么。不幸的是，
他们不擅长此道：他们可能缺少准确描述系统所需的技能，也可能一开始就没弄对，更糟的是，他们可能随着时间的推移而改变想法。与顾客签订合同是重要的，但合同不能代替有效的沟通。成功的IT专业人员会与他们的顾客密切协作，他们会投入一定的精力来发现顾客想要的东西，并一直教育他们的顾客。
　　4 响应变化胜过遵循计划。随着系统工作的推进，项目涉众对他们想要的
东西的理解发生了变化，业务环境发生了变化，底层技术也发生了变化。变化是软件开发的现实，因此，你的项目计划和整体方式必须反映变化的环境，才能是有效的。
　　如何阅读本书
　　本书的大部分内容(从第6章到第11章)包含了详细描述每一类重构的参考材料。前面5章描述了演进式数据库开发的基本思想和技术，特别介绍了数据库重构。读者应该依次阅读下面的章节：
 第1章“演进式数据库开发”，概述了演进式开发的基本思想和支持它的技术。
综述了重构、数据库重构、数据库回归测试、通过AMDD方法进行演进式数据建模、数据库资产的配置管理，以及对独立的开发者沙盒的需求。
 第2章“数据库重构”，详细地探讨了数据库重构背后的概念，以及为什么它在
实践中如此困难。展示了在“简单的”单应用环境下和复杂的多应用环境下数据库重构的例子。
 第3章“数据库重构过程”，描述了在简单和复杂的环境下，重构数据库schem
a所需的详细步骤。对于单应用数据库来说，你对环境拥有更大的控制力，因此重构schema所需的工作也要少得多。在多应用环境中，你需要支持一个转换期，在这段时间内数据库同时支持原来的schema和新的schema，让应用团队能更新他们的代码并将代码部署到生产环境中去。
 第4章“部署到生产环境”，描述了将数据库重构部署到生产环境中去的过程。
这在多应用环境下特别富有挑战性，因为多个团队所做的改动必须合并和测试。
 第5章“数据库重构策略”，汇集了我们在这些年来发现的一些关于重构数据
库schema的“最佳实践”。我们也提出了一些打算尝试但还没有机会尝试的想法。
　　关于封面
　　Martin Fowler签名丛书中，每本书的封面都有一座桥梁的图片。这个惯例是因为Martin的妻子是一名土建工程师，在丛书开始时，她正在为桥梁和隧道类的项目设计水平投影图。这座桥是南安大略的Burlington Bay James N Allan Skyway，它穿越了Hamilton港。这里有3座桥：图中的两座以及没有显示出来的Eastport Drive吊桥。桥的重要性有两个原因。最重要的是它体现了增量式的交付方式。吊桥最初承担了这一地区的交通，原来承担交通的桥在1952年因轮船撞击而倒塌。Skyway的第一跨——前部在道路上方有金属支撑的部分，在1958年开
发，以取代倒塌的桥。因为Skyway是多伦多向北和尼亚加拉瀑布向南的主要交通要道，所以交通量很快就超过了设计能力。第二跨是没有金属支撑的部分，它在1985年开放，以支持新的负载。增量式交付不论是在土木工程领域还是在软件开发领域，在经济上都很有意义。我们使用这张图的第二个原因是，Scott是在安大略的Burlington长大的，他出生于Joseph Brant医院，靠近Skyway的北部出口。Scott用Nikon D70S拍下了封面的照片。

致　　谢

　　我们想感谢这些人，他们为本书的编写提供了信息：Doug Barry、Gary Evans、Martin Fowler、Bernard Goodwin、Joshua Graham、Sven Gorts、David Hay、David Haertzen、Michelle Housely、Sriram Narayan、Paul Petralia、Sachin Rekhi、Andy Slocum、Brian Sm
ith、Michael Thurston、Michael Vizdos和Greg Warren。
　　另外，Pramod想感谢Irfan Shah、Narayan Raman、Anishek Agarwal和其他团队成员，是他们经常对我的观点提出挑战，教给我许多软件开发的知识。我也感谢Martin给予我写作的机会，让我去演讲，积极参加ThoughtWorks之外的活动；感谢Kent Beck的鼓励，感谢我在ThoughtWorks的同事，他们在许多方面给予我帮助，让工作变得有趣；感谢我的父母Jinappa和Shobha，他们花了许多精力将我养育成人；感谢我的哥哥，从我小时候起，他就批评并帮助我改进写作方式。

重构的价值是毋庸置疑的，这已在许多项目中证明了。重构能帮助软件专业人士改进系统设计及其可维护性、可扩展性和性能。本书首次介绍了专门针对数据库系统设计的强大的重构技术。 作者向读者充分展示了：对表结构、数据、存储过程和触发器的小小改动就能在很大程度上改进数据库的设计，同时又不改变语义。读者还将学到分步演进数据库模式以及源代码的方法，使依赖迭代、敏捷方法开发的项目变得更高效。 本书为数据库重构提供了全面的指导和参考，介绍了数据库重构的基本概念，帮助读者克服重构真实数据库系统时的实践障碍。通过完整的例子，作者展示了重构简单的单个数据库应用和复杂的多个应用的情况。通过本书，读者可以掌握重构数据库模式所涉及的各项任务，学习在最复杂的产品环境中部署重构的最佳实践。 本书系统介绍了5类主要的数据库重构技术。读者将看到如何利用重构来增强数据库结构、数据质量和参照完整性，以及如何对架构和方法进行重构。本书提供了大量的基于Oracle和Java的例子，读者可以很方便地调整到其他语言，如C#、C++或VB.NET，或其他数据库，如DB2、SQL Server、MySQL和Sybase。 利用本书提供的技术和例子，读者在进行数据库重构时可以减少浪费和风险，避免返工并节约成本，可以平滑地演进数据库系统，延长数据库的使用寿命。

对本书的赞誉

　　“这本突破性的图书向我们揭示了为什么数据库schema(模式)不一定难以改变，为什么数据不一定难以迁移，以及为什么数据库专业人员不一定要被来自顾客和开发者的变更请求压得喘不过气来。演进式设计是敏捷的核心。Ambler和Sadalage向大家展示了如何演进敏捷的数据库。漂亮！”
　　——Joshua Kerievsky，Industrial Logic公司的创始人，
　　《Refactoring to Patterns》一书的作者
　　“本书不仅提供了演进式数据库开发的基础知识，还提供了许多实际的、详细的数据库重构的例子。对于对敏捷开发感兴趣的数据库专业人员来说，这是一本必读的好书。”
　　——Doug Barry，Barry & Associates公司的总裁，
　　《Web Services and ServiceOriented Architectures: The Savvy Managers Guide》一书的作者
　　“Ambler和Sadalage朝着别的作者觉得棘手的问题迈出了勇敢的一步。他们不仅关注数据库重构背后的理论，还解释了一步一步的过程，以一种受控的、深思熟虑的方式来进行数据库重构。但真正征服我的是超过200页的代码示例和深入的技术细节，展示了如何解决具体的数据库重构问题。这不仅是一本介绍一种好思想的书——更是一本教程和技术参考书，开发人员和DBA都会将它放在计算机旁。荣誉归于两位作者，他们成功地完成了其他人甚至都不敢尝试的事情。”
　　——Kevin Aguanno，IBM加拿大公司高级项目经理
　　“任何承担真实项目的人都会认识到Scott和Pramod通过本书给软件开发生命周期带来的价值。与原有数据库打交道是一件相当麻烦的事情。尽管许多挑战可能是文化上的，改进可能被强势的DBA策略所忽略，但本书展示了重构和演进式数据库开发在技术上如何能够真正地以敏捷的方式进行。我希望遇到下一位坏心情的DBA时，将这本书放在他的桌上。”
　　——Jon Kern
　　“这本书很出色。它很适合数据专业人士，这些人需要在敏捷开发和对象技术的世界中完成他们的工作。通过精心组织，本书展示了什么是数据库重构，为什么要进行数据库重构以及如何进行数据库重构，同时也展示了相关的代码。就像一本最好的菜谱，我会在开发和改进数据库时经常用到它。”
　　——David R Haertzen，First Place Software公司数据管理中心的编辑
　　“这本优秀的图书带来了在数据世界的重构敏捷实践。它提供了实际的指导，包括在机构中重构数据库的方法学，以及如何实现单次重构的细节。这本书也阐述了开发者与DBA互相协作的重要性；是开发者和DBA必备的一本参考图书。”
　　——Per Kroll，IBM RUP开发经理，
　　Eclipse Process Framework项目负责人
“Scott和Pramod对数据库重构所做的事相当于Martin Fowler对代码重构所做的事。他们提供了一组一致的过程，你可以用这些过程来改进数据库的质量。如果你要与数据打交道，这本书就是为你写的。”
　　——Ken Pugh，《Prefactoring》一书的作者
　　“现在是数据人员加入敏捷行列的时候了，Ambler和Sadalage正是合适的领头人。数据建模者、管理员以及软件团队都应该读这本书。长期以来我们在不同的技术世界里各行其事，本书将有助于消除我们之间的隔阂。”
　　——Gary K Evans，敏捷过程传道者，Evanetics公司
　　“演进式设计和重构已经令人很兴奋了，有了重构数据库后就更妙了。在这本书中，作者与我们分享了在数据库层面进行重构的技术与策略。通过这些重构，即使是数据库已经部署到生产环境中，数据库schema也可以安全地演进。通过本书，数据库就能被所有开发者访问。”
　　——Sven Gorts
　　“数据库重构是一个重要的新课题，这本书率先对社区作出了贡献。”
　　——Floyd Marinescu，InfoQcom and TheServerSidecom的创建者，
　　《EJB Design Pattern》一书的作者


　参加本书翻译工作的有王海鹏、王海燕、李国安、黄丽红、蔡黄辉、谢伟奇、漆巧林、周建鸣、贾立群和范俊。


序

　　10年前，重构(refactoring)还是一个只有少数人知道的词，主要用在Smalltalk社区。很高兴看到越来越多的人开始学习通过重构以一种训练有素和有效的方式来修改工作代码。许多人现在将代码重构视为软件开发的一个基本组成部分。
　　我的工作领域是企业应用开发，而企业应用开发的一个很大的部分就是与数据库打交道。在我最初关于重构的书籍中，我就已经指出了数据库是重构的一个主要问题领域，因为重构数据库会引入一些新的问题。在企业软件开发领域中，数据库专业人员与软件开发人员之间隔了一堵因互不理解和相互竞争所形成的墙，这个可悲的隔阂使得这些问题变得恶化。
　　我喜欢Scott和Pramod的一个原因是，他们以不同的方式努力工作，试图打破这种隔阂。Scott在其关于数据库的著作中一贯地尝试跨越这一鸿沟，他在对象关系映射方面的工作极大地影响了我关于企业应用架构的写作。Pramod可能名气小一些，但他对我的影响同样很大。当我们在ThoughtWorks一起做一个项目时，我们被告知重构数据库是不可能的。Pramod不同意这种看法，他产生了一些粗略的想法，并把这些想法变成了一种训练有素的计划，让数据库schema(模式)保持在一种稳定但受控的变化中。这使得应用开发人员能够在代码中自由地进行演进式设计。自那时起，Pramod将这些技术带给了我们的许多客户，并在ThoughtWorks的同事中传播这些技术，至少对我们来说，使数据库不再成为持续设计的拦路石。
　　本书汇集了两个人的经验，他们工作于应用与数据之间的无人地带，提供了对数据库重构的技术指导。如果你熟悉重构，你会注意到主要变化是你必须管理持续的数据迁移，而不只是改变程序和数据的结构。本书告诉了你如何进行数据迁移，其背后是两位作者积累的项目经验（和教训）。
　　尽管我很高兴看到本书出版，但我希望这只是第一步。在我的关于重构的书出版之后，我很高兴地看到出现了一些成熟的工具，利用这些工具能自动完成许多重构任务。我希望同样的情况也出现在数据库上，我们也看到一些供应商开始提供这方面的工具，使持续的schema和数据迁移变得更加容易。在这一切发生之前，本书将帮助你构建自己的过程和工具；以后，本书作为成功使用这类工具的基础，仍将体现其价值。
　　——Martin Fowler，丛书编辑，ThoughtWorks首席科学家
　　自我开始软件开发生涯以来，行业和技术的许多方面都已发生了巨大的变化。但没有改变的是软件开发的基础本质。创造软件从来都不难——只需要一台计算机并开始大量地产出代码。但创造良好的软件却很难，而创建优秀的软件更是难上加难。这种情形直至今天也没有改变。今天，我们可以更容易地创建更大、更复杂的软件系统，只需将不同来源的一些部件拼凑在一起。软件开发工具得到了极大的发展，我们对创建软件的过程中哪些有效、哪些无效也有了更多的认识。然而大多数软件仍然是脆弱的，并努力想达到可接受的品质。或许是因为我们正在创建更大、更复杂的系统，或许是因为我们使用的技术仍然存在某些基本的缺失。由于前面两个因素，我相信今天的软件开发会像以前一样富有挑战性。幸运的是，新的技术不断出现，为我们提供了帮助。在这些进展中，能够极大地影响我们在项目开始时认识其潜在能力的却极少。重构所涉及的技术，以及相关的敏捷方法学，就是这些少有的进展之一。本书所包含的工作在一个很重要的方向上扩展了这一基础。
　　重构是一种受控的技术，指安全地改进代码的设计而不改变它的行为语义。任合人都可能有机会改进代码，但重构带来一种训练有素的方法，能安全地进行改动（通过测试），并利用软件开发社区所积累的知识（通过重构）。自从Fowler推出了这个领域的开创性书籍以来，重构已经被广泛地应用，帮助检测重构的可能性和对代码进行重构的工具也已被广泛采用。然而在应用的数据层，重构却被证实要困难得多。部分问题无疑是文化上的原因，正如这本书所展示的；但是同时也缺少适用于数据层的清晰的过程和一组重构技术。这相当不幸，因为数据层的糟糕设计几乎总是会带来更高层的问题，通常会引起一连串的坏设计，而这只是为了徒劳地维护这个不可靠基础的稳定性。而且，不能演进数据层，不论是因为忽视了这一点或者是害怕改变，都将妨碍所有依赖于它的工作，最终导致不能交付最好的软件。正是这些问题使得这项工作变得很重要：我们现在有了一个过程和一组重构技术，使我们能在这个重要的领域进行迭代式设计改进。
　　我很高兴看到这本书的出版，希望它能推动创造一些工具来支持书中描述的技术。软件行业目前处于一个有趣的阶段，我们看到了开放源代码软件的兴起以及它所带来的协作工具。在像Eclipse Data Tools Platform这样的项目中，人们自然希望在工具中实现数据库重构。我希望开源社区努力工作来实现这一愿景，因为潜在的回报是巨大的。如果数据库重构像一般的重构那样得到广泛采用，软件开发将变得更加成熟。
　　——John Graham，Eclipse Data Tools Platform项目管理委员会主席，
　　Sybase公司高级工程师
　　数据社区在许多方面错过了整个敏捷软件开发革命。应用开发者已广泛应用重构、测试驱动开发以及其他技术，使迭代成为有效的高级软件开发方式；而数据专业人士却在很大程度上忽略了这些潮流，甚至把自己与潮流隔离开来。
　　当我还在一家大型金融服务机构做应用开发时，就清楚地看到了这一点。那时我的办公室就在开发团队和数据库团队之间。我很快发现，尽管他们之间只有几步之遥，但两个团队的文化、实践和过程是极为不同的。顾客的要求对开发团队来说就意味着一些重构，代码检入(check in)，以及迅速的验收测试。对数据库团队而言，类似的请求就意味着正式的变更请求，要通过层层批准，最后才能开始修改schema。这种繁杂的过程开销常常使开发人员和顾客变得沮丧，但事情只能这样，因为数据库团队不知道能有什么其他办法。
　　然而，如果他们的业务想在今天不断发生变化的竞争环境中得到发展，那么，他们就必须学习其他的办法。数据社区必须像开发者那样采用一些敏捷技术。
　　本书是一本无价的资源，它向数据专业人士展示了怎样实现飞越，自信而安全地拥抱变化。Scott和Pramod展示了小的、迭代式重构的设计改进如何使敏捷DBA避免大的前期设计错误，以及如何随着对顾客需求理解的逐步加深与应用一起演进数据库schema。
　　不要弄错，重构数据库是很难的。即使是像列改名这样的简单变化，都会引起schema、相关对象、持久层框架和应用层的相应改变，这令DBA觉得重构似乎是一种不可用的技术。
　　本书列出了一组实践说明，向专业DBA展示了如何将敏捷方法用于数据库的设计和开发。Scott和Pramod对实现每类数据库重构的详细描述证明了它是可行的，为数据库广泛采用重构铺平了道路。
　　因此，我建议数据专业人士行动起来。阅读这本书，拥抱变化，广为宣传。数据库重构是改进数据社区敏捷性的关键。
　　——Sachin Rekhi，微软公司项目经理
　　在系统开发的世界里，存在两种不同的文化：一种是由面向对象（OO）开发者主宰的，他们在Java和敏捷软件开发中自由呼吸；另一种由关系数据库人员主宰，他们喜欢仔细的工程方法和稳定的关系数据库设计。这两个阵营说着不同的语言，参加不同的会议，相互之间似乎很少交谈。这种分裂在许多组织机构的IT部门中得到了反映。OO开发人员抱怨DBA们古板而保守，不能跟上快速变化的节奏。数据库专业人士哀叹Java开发人员的愚蠢行为，因为他们不知道怎样和数据库打交道。
　　Scott Ambler和Pramod Sadalage属于能够跨越两种文化的很少的一部分人。本书是从OO架构师的角度来谈数据库设计的；因此，本书对于OO开发人员和关系数据库专业人员都有价值。它帮助OO开发人员在数据库领域应用敏捷代码重构技术，并让关系数据库专业人员了解OO架构师的想法。
　　这本书包含了许多提示和技巧，可用于改进数据库设计的质量。它明确关注如何解决真实世界的问题，即数据库已经存在，但设计有问题，或者原来的数据库设计不能产生一种好的模型。
　　这本书在不同的层面上获得了成功。首先，它可以作为实战开发人员的战术指导。另外，它也可以作为一本激发人思想的著作，让我们思考怎样融合OO和关系型思考方式。我希望更多的系统架构师能响应Ambler和Sadalage的观点，认识到数据库不仅仅是存放类的持久拷贝的地方。
　　——Paul Dorsey博士，Dulcian公司总裁，
　　New York Oracle User Group总裁，J2EE SIG主席

Scott W. Ambler Pramod J. Sadalage：Scott W. Ambler: Scott W. Ambler是软件开发方法年轻一代的领军人物之一，在理论和实践上的造诣都很深厚。作为一位高级咨询师，他一直积极参与全球各种大型软件开发和过程改进项目。同时，他还是一位视野广阔的方法学者，是《Software Development》杂志的专栏作家，撰写了多部颇受推崇的著作，其中包括《The Object Primer》、《Agile Modeling》、《The Elements of UML Style》、《More Process Patterns》等。
Pramod J. Sadalage: ThoughtWorks公司的顾问。在1999年用XP方法开发一个大型J2EE应用时，他就率先实践了演进式数据库设计和数据库重构的过程。他目前正在进行有关演进式项目中的数据库管理以及在数据库设计和管理中使用演进式过程等主题的写作和演讲。

王海鹏：暂无简介

第1章　演进式数据库开发
11　数据库重构
12　演进式数据库建模
13　数据库回归测试
14　数据库工件的配置管理
15　开发者沙盒
16　演进式数据库开发技术的障碍
17　本章小结
第2章　数据库重构
21　代码重构
22　数据库重构
221　单应用数据库环境
222　多应用数据库环境
223　保持语义
23　数据库重构的分类
24　数据库味道
25　数据库重构在开发中的位置
26　使数据库schema的重构更容易
27　本章小结
第3章　数据库重构过程
31　验证数据库重构是否合适
32　选择最合适的数据库重构
33　让原来的数据库schema过时
34　前测试、中测试和后测试
341　测试数据库schema
342　检验数据迁移的有效性
343　测试外部访问程序
35　修改数据库schema
36　迁移源数据
37　重构外部访问程序
38　运行回归测试
39　对工作进行版本控制
310　宣布此次重构
311　本章小结
第4章　部署到生产环境
41　在沙盒之间有效地部署
42　采用数据库重构包
43　制定部署时间窗口进度计划
44　部署系统
45　移除已过时的schema
46　本章小结
第5章　数据库重构策略
51　小的变更更容易进行
52　唯一地标识每一次重构
53　通过许多小变更实现一次大变更
54　建立数据库配置表
55　触发器优于视图或批量同步
56　选择一个足够长的转换期
57　简化数据库变更控制委员会策略
58　简化与其他团队的协商
59　封装对数据库的访问
510　能够容易地建立数据库环境
511　不要复制SQL
512　将数据库资产置于变更控制之下
513　注意机构中的政治斗争
514　本章小结
515　在线资源
第6章　结构重构
61　实现结构重构时的常见问题
62　删除列
63　删除表
64　删除视图
65　引入计算列
66　引入替代键
67　合并列
68　合并表
69　移动列
610　列改名
611　表改名
612　视图改名
613　用表取代LOB
614　取代列
615　用关联表取代一对多关系
616　用自然键取代替代键
617　拆分列
618　拆分表
第7章　数据质量重构
71　实现数据质量重构时的常见问题
72　增加查找表
73　采用标准代码
74　采用标准类型
75　统一主键策略
76　删除列约束
77　删除缺省值
78　删除不可空约束
79　引入列约束
710　引入通用格式
711　引入缺省值
712　使列不可空
713　移动数据
714　用属性标识取代类型代码
第8章　参照完整性重构
81　增加外键约束
82　为计算列增加触发器
83　删除外键约束
84　引入层叠删除
85　引入硬删除
86　引入软删除
87　为历史数据引入触发器
第9章　架构重构
91　增加CRUD方法
92　增加镜像表
93　增加读取方法
94　用视图封装表
95　引入计算方法
96　引入索引
97　引入只读表
98　从数据库中移出方法
99　将方法移至数据库
910　用视图取代方法
911　用方法取代视图
912　使用正式数据源
第10章　方法重构
101　接口变更重构
1011　增加参数
1012　方法参数化
1013　删除参数
1014　方法改名
1015　参数重排序
1016　用明确的方法取代参数
102　内部重构
1021　合并条件表达式
1022　分解条件
1023　提取方法
1024　引入变量
1025　删除控制标记
1026　消除中间人
1027　参数改名
1028　用表查找取代文字常量
1029　用条件短语取代嵌套条件
10210　拆分临时变量
10211　替换算法
第11章　转换
111　插入数据
112　引入新列
113　引入新表
114　引入视图
115　更新数据
附录　UML数据建模表示法
词汇表
参考文献和推荐读物
重构和转换列表