数据库重构 （2007年第17届Jolt生产效率大奖图书）

　　本书首次专门讨论数据库重构，向数据专业人员展示了如何运用重构、测试驱动及其他敏捷技术进行演进式数据库开发。书中通过许多实际例子，详细说明了数据库重构的过程、策略以及部署。.
　　 本书前5章介绍了演进式数据库开发的基本思想和技术，后6章详细描述了每一类重构，包括结构、数据质量、参照完整性、架构、方法的重构；另外还描述了不属于重构范畴的转换技术。
　　 书中的示例代码是用java、hibernate和oracle代码编写的，代码都很简单，读者可以毫无困难地将它们转换成c#、c++或visual basic代码。 重构的价值是毋庸置疑的，这已在许多项目中证明了。重构能帮助软件专业人士改进系统设计及其可维护性、可扩展性和性能。本书首次介绍了专门针对数据库系统设计的强大的重构技术。
　　 作者向读者充分展示了：对表结构、数据、存储过程和触发器的小小改动就能在很大程度上改进数据库的设计，同时又不改变语义。读者还将学到分步演进数据库模式以及源代码的方法，使依赖迭代、敏捷方法开发的项目变得更高效。..
　　 本书为数据库重构提供了全面的指导和参考，介绍了数据库重构的基本概念，帮助读者克服重构真实数据库系统时的实践障碍。通过完整的例子，作者展示了重构简单的单个数据库应用和复杂的多个应用的情况。通过本书，读者可以掌握重构数据库模式所涉及的各项任务，学习在最复杂的产品环境中部署重构的最佳实践。
　　 本书系统介绍了5类主要的数据库重构技术。读者将看到如何利用重构来增强数据库结构、数据质量和参照完整性，以及如何对架构和方法进行重构。本书提供了大量的基于oracle和java的例子，读者可以很方便地调整到其他语言，如c#、c++或vb．net，或其他数据库，如db2、sqlserver、mysql和sybase。
　　 利用本书提供的技术和例子，读者在进行数据库重构时可以减少浪费和风险，避免返工并节约成本，可以平滑地演进数据库系统，延长数据库的使用寿命。...

对本书的赞誉.
序
前言
致谢
第1章 演进式数据库开发
1．1 数据库重构
1．2 演进式数据库建模
1．3 数据库回归测试
1．4 数据库工件的配置管理
1．5 开发者沙盒
1．6 演进式数据库开发技术的障碍
1．7 本章小结
第2章 数据库重构
2．1 代码重构
2．2 数据库重构
2．3 数据库重构的分类
2．4 数据库味道
2．5 数据库重构在开发中的位置
2．6 使数据库schema的重构更容易
2．7 本章小结

　　演进式开发以及敏捷软件开发方法学，如极限编程(XP)、Scrum、Rational统一过程(RUP)、敏捷统一过程(AUP)和特征驱动开发(FDD)，已经在过去几年中为信息技术(汀)产业带来了一场风暴。为了明确定义，演进式方法在本质上是迭代式和增量式的，敏捷方法在本质上是演进式和高度协作的。而且，像重构、结对编程、测试驱动开发(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专有的特征，如SETUNUSED或RENAMETO等命令；我们的许多代码示例也用到了Oracle的COMMENTON特征。有些数据库包含另外一些使数据库重构变得容易的特征，好的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种敏捷价值观如下：

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