数据库重构(上)

时量Q 目一录库开发 对本书的赞誉 3.7重构外部访问程序...... 28 序 38运行回归测试......... 29 前言 3.9对工作进行版本控制............29 致谢 3.10宣布此次重构29 3.11本章小结...... 30 31 第1章演进式数据库开发 第4章部署到生产环境... 4.1在沙盒之间有效地部署... ............31 1.1数据库重构...... .........2 4.2采用数据库重构包 1.2演进式数据库建模...... 4.3制定部署时间窗口进度计划... 33 1.3数据库回归测试...... 1.4数据库工件的配置管理... 4.4部署系统...... 面4着DD重 1.5开发者沙盒............ 4.5移除已过时的 scherma......36 1.6演进式数据库开发技术的障碍... 4.6本章小结.....................36 1.7本章小结... ,,;;;a面面面““音 第5章数据库重构策略............37 第2章数据库重构 51小的变更更容易进行 37 2.1代码重构......... 5.2唯一地标识每一次重构... 2.2数据库重构... 5.3通过许多小变更实现一次大变更... 2.2.1单应用数据库环境...... 11 5.4建立数据库配置表... 2.2.2多应用数据库环境 12 5.5触发器优于视图或批量同步 2.2.3保持语义 5.6选择一个足够长的转换期... 2.3数据库重构的分类......... 5.7简化数据库变更控制委员会 2.4数据库味道 ........................14 策略............40 2.5数据库重构在开发中的位置... 16 5.8简化与其他团队的协商.....................41 2.6使数据库 schema的重构更容易.........179封装对数据库的访间 .........41 2.7本章小结...........................17 5.10能够容易地建立数据库环境 第3章数据库重构过程... 5.11不要复制SQL ·中垂· 3.1验证数据库重构是否合适 ,,, ......215.12将数据库资产置于变更控制之下......42 3.2选择最合适的数据库重构...... 22 5.13注意机构中的政治斗争......42 3.3让原来的数据库 schema过时 2 5.14本章小结... 42 3.4前测试、中测试和后测试... 5.15在线资源...42 3.4.1测试数据库 schema ·,,,普,,福,,,,辛 24第6章结构重构........................43 34,2检验数据迁移的有效性.........256.1实现结构重构时的常见问题......43 3.4.3测试外部访问程序............256.2删除列.........45 3.5修改数据库 schema............25 6.3删除表...... 垂2 48 3.6迁移源数据 276.4删除视图...49 XIIy 6.5引入计算列..............................51 9.3增加读取方法... ..................153 6.6引入替代键 ........................53 9.4用视图封装表 155 6.7合并列.................................57 9.5引入计算方法 156 68合并表........................ 9.6引入索引... 58 6.9移动列.......................................65 9.7引入只读表.....................160 6.10列改名 69 9.8从数据库中移出方法.....................16 6.11表改名 71 9.9将方法移至数据库......... 167 6.12视图改名 9.10用视图取代方法.....................169 6.13用表取代LOB 9.11用方法取代视图...... 171 6.14取代列.................................80 9.12使用正式数据源 173 6.15用关联表取代一对多关系.........83第10章方法重构... ...177 6.16用自然键取代替代键 ·8610.1接口变更重构...............177 6.17拆分列 89 10.1.1增加参数...... 177 6.18拆分表..............................92 10.1.2方法参数化 第7章数据质量重构 97 10.1.3删除参数........................177 7.1实现数据质量重构时的常见问题...97 10.1.4方法改名.................................178 7.2增加查找表 10.1.5参数重排序...........................179 7.3采用标准代码 .,...,,,,自,·,串非非 10.1.6用明确的方法取代参数............180 74采用标准类型.........10310.2内部重构..................181 7.5统一主键策略............ 107 10.2.1合并条件表达式... 181 7.6删除列约束...............1 10.2.2分解条件 182 7.7删除缺省值...........................110 10.2.3提取方法 18 7.8删除不可空约束............112 10.2.4引人变量 185 7.9引人列约束... ......11310.2.5删除控制标记8 7.10引入通用格式..................15 10.2.6消除中间人............ 187 7.11引入缺省值... 17 10.2.7参数改名... 187 7.12使列不可空 118 10.2.8用表查找取代文字常量.........187 7.13移动数据 120110.2.9用条件短语取代嵌套条件... 188 7.14用属性标识取代类型代码.........123 10.2.10拆分临时变量..................18 第8章参照完整性重构 10.2,11替换算法 190 8.1增加外键约束...... ∴...... 129 第11章转换 ,年,·,,,← 191 8.2为计算列增加触发器..................132 11.1插入数据......... 191 8.3删除外键约束 134 11.2引入新列... 194 8.4引人层叠删除 136 11.3引入新表...95 8.5引入硬删除...........................138 11.4引入视图..............................196 8.6引入软删除...............................140 11.5更新数据...........................199 8.7为历史数据引人触发器.........144附录UML数据建模表示法.........203 第9章架构重构............147词汇表...20 9.1增加(RUD方法.........147参考文献和推荐读物 211 9.2增加镜像表 ...............150重构和转换列表..................215 对本书的赞誉 “这本突破性的图书向我们揭示了为什么数据库 schema(模式)不一定难以改变,为什么 数据不一定难以迁移,以及为什么数据库专业人员不一定要被来自顾客和开发者的变更请求压 得喘不过气来。演进式设计是敏捷的核心。 Ambler和 Scalage向大家展示了如何演进敏捷的 效据库。漂亮!” Joshua Kerievsky, Industrial Logic公司的创始人, 《 Refactoring to Patterns》一书的作者 “本书不仅提供了演进式数据库开发的基础知识,还提供了许多实际的、详细的数据库重 构的例子。对于对敏捷开发感兴趣的数据库专业人员来说,这是一本必读的好书。” Doug Barry,Bary& Associates公司的总裁, Web Services and Service- Oriented Architectures: he Savvy manager' s Guide)一书的作者 Ambler和 Sadalage朝着别的作者觉得棘手的问题迈出了勇敢的一步。他们不仅关注数据 库重构背后的理论,还解释了一步一步的过程,以一种受控的、深思熟虑的方式来进行数据库 重构。但真正征服我的是超过200页的代码示例和深入的技术细节,展示了如何解决具体的数 据库重构问题。这不仅是一本介绍一种好思想的书—更是一本教程和技术参考书,开发人员 和DBA都会将它放在计算机旁。荣誉归于两位作者,他们成功地完成了其他人甚至都不敢尝 试的事情。” Kevin Aguanno,IBM加拿大公司高级项目经理 “任何承担真实项目的人都会认识到 Scott和 Pramod通过本书给软件开发生命周期带来的 价值。与原有数据库打交道是一件相当麻烦的事情。尽管许多挑战可能是文化上的,改进可能 被强势的DBA策略所忽略,但本书展示了重构和演进式数据库开发在技术上如何能够真正地 以敏捷的方式进行。我希望遇到下一位坏心情的DBA时,将这本书放在他的桌上。” on kern “这本书很出色。它很适合数据专业人士,这些人需要在敏捷开发和对象技术的世界中完 成他们的工作。通过精心组织,本书展示了什么是数据库重构,为什么要进行数据库重构以及 如何进行数据库重构,同时也展示了相关的代码。就像一本最好的菜谱,我会在开发和改进数 据库时经常用到它。” David r. Haertzen, First Place Software公司数据管理中心的编辑 “这本优秀的图书带来了在数据世界的重构敏捷实践。它提供了实际的指导,包括在机构 中重构数据库的方法学,以及如何实现单次重构的细节。这本书也阐述了开发者与DBA互相 协作的重要性;是开发者和DBA必备的一本参考图书。” 一 Per krol, BM RUP开发经理, Eclipse Process Framework项目负责人 “ Scott和 Pramod对数据库重构所做的事相当于 Martin Fowler对代码重构所做的事。他们 提供了一组一致的过程,你可以用这些过程来改进数据库的质量。如果你要与数据打交道,这 本书就是为你写的。” Ken Pugh,《 Refactoring》一书的作者 “现在是数据人员加入敏捷行列的时候了, Ambler和 Sadalage正是合适的领头人。数据建 模者、管理员以及软件团队都应该读这本书。长期以来我们在不同的技术世界里各行其事,本 书将有助于消除我们之间的隔阂。” GayK. Evans,敏捷过程传道者, Evanetics公司 “演进式设计和重构已经令人很兴奋了,有了重构数据库后就更妙了。在这本书中,作者 与我们分享了在数据库层面进行重构的技术与策略。通过这些重构,即使是数据库已经部署到 生产环境中,数据库 schema也可以安全地演进。通过本书,数据库就能被所有开发者访问。” Sven ( orts “数据库重构是一个重要的新课题,这本书率先对社区作出了贡献。” FloydMarinescu,Info.comandTheServerSide.com的创建者, 《 EJB Design Pattern)一书的作者 3参加本书翻译工作的有王海鹏、王海燕、李国安、黄丽红、蔡黄辉、谢伟奇、漆巧林、周建鸣、贾立群和范俊。 序 10年前,重构( refactoring)还是一个只有少数人知道的词,主要用在 Smalltalk社区。很 高兴看到越来越多的人开始学习通过重构以一种训练有素和有效的方式来修改工作代码。许多 人现在将代码重构视为软件开发的一个基本组成部分。 我的工作领域是企业应用开发,而企业应用开发的一个很大的部分就是与数据库打交道。 在我最初关于重构的书籍中,我就已经指出了数据库是重构的一个主要问题领域,因为重构数 据库会引入一些新的问题。在企业软件开发领域中,数据库专业人员与软件开发人员之间隔了 堵因互不理解和相互竞争所形成的墙,这个可悲的隔阂使得这些问题变得恶化。 我喜欢Sott和 Pramod的一个原因是,他们以不同的方式努力工作,试图打破这种隔阂。 Sot其关于数据库的著作中一贯地尝试跨越这一鸿沟,他在对象关系映射方面的工作极大 地影响了我关于企业应用架构的写作。 Pramod可能名气小一些,但他对我的影响同样很大。 当我们在 Thought Works一起做一个项目时,我们被告知重构数据库是不可能的。 Pramod不同 意这种看法,他产生了一些粗略的想法,并把这些想法变成了一种训练有素的计划,让数据库 schema(模式)保持在一种稳定但受控的变化中。这使得应用开发人员能够在代码中自由地进 行演进式设计。自那时起, Pramod将这些技术带给了我们的许多客户,并在 Thought Works的 同事中传播这些技术,至少对我们来说,使数据库不再成为持续设计的拦路石。 本书汇集了两个人的经验,他们工作于应用与数据之间的无人地带,提供了对数据库重构 的技术指导。如果你熟悉重构,你会注意到主要变化是你必须管理持续的数据迁移,而不只是 改变程序和数据的结构。本书告诉了你如何进行数据迁移,其背后是两位作者积累的项目经验 (和教训 尽管我很高兴看到本书出版,但我希望这只是第一步。在我的关于重构的书出版之后,我 很高兴地看到出现了一些成熟的工具,利用这些工具能自动完成许多重构任务。我希望同样的 情况也出现在数据库上,我们也看到一些供应商开始提供这方面的工具,使持续的 schema和 数据迁移变得更加容易。在这一切发生之前,本书将帮助你构建自己的过程和工具;以后,本 书作为成功使用这类工具的基础,仍将体现其价值 Martin fowler,丛书编辑, Thought Works首席科学家 自我开始软件开发生涯以来,行业和技术的许多方面都已发生了巨大的变化。但没有改变 的是软件开发的基础本质。创造软件从来都不难——只需要一台计算机并开始大量地产出代 码。但创造良好的软件却很难,而创建优秀的软件更是难上加难。这种情形直至今天也没有改 变。今天,我们可以更容易地创建更大、更复杂的软件系统,只需将不同来源的一些部件拼凑 在一起。软件开发工具得到了极大的发展,我们对创建软件的过程中哪些有效、哪些无效也有 VI 了更多的认识。然而大多数软件仍然是脆弱的,并努力想达到可接受的品质。或许是因为我们 正在创建更大、更复杂的系统,或许是因为我们使用的技术仍然存在某些基本的缺失。由于前 面两个因素,我相信今天的软件开发会像以前一样富有挑战性。幸运的是,新的技术不断出 现,为我们提供了帮助。在这些进展中,能够极大地影响我们在项目开始时认识其潜在能力的 却极少。重构所涉及的技术,以及相关的敏捷方法学,就是这些少有的进展之一。本书所包含 的工作在一个很重要的方向上扩展了这一基础。 重构是一种受控的技术,指安全地改进代码的设计而不改变它的行为语义。任合人都可能 有机会改进代码,但重构带来一种训练有素的方法,能安全地进行改动(通过测试),并利用 软件开发社区所积累的知识(通过重构)。自从 Fowler推出了这个领域的开创性书籍以来,重 构已经被广泛地应用,帮助检测重构的可能性和对代码进行重构的工具也已被广泛采用。然而 在应用的数据层,重构却被证实要困难得多。部分问题无疑是文化上的原因,正如这本书所展 示的;但是同时也缺少适用于数据层的清晰的过程和一组重构技术。这相当不幸,因为数据层 的糟糕设计几乎总是会带来更高层的问题,通常会引起一连串的坏设计,而这只是为了徒劳地 维护这个不可靠基础的稳定性。而且,不能演进数据层,不论是因为忽视了这一点或者是害怕 改变,都将妨碍所有依赖于它的工作,最终导致不能交付最好的软件。正是这些问题使得这项 工作变得很重要:我们现在有了一个过程和一组重构技术,使我们能在这个重要的领域进行迭 代式设计改进。 我很高兴看到这本书的出版,希望它能推动创造一些工具来支持书中描述的技术。软件行 业目前处于一个有趣的阶段,我们看到了开放源代码软件的兴起以及它所带来的协作工具。在 像 Eclipse Data Tools Platform这样的项目中,人们自然希望在工具中实现数据库重构。我希望 开源社区努力工作来实现这一愿景,因为潜在的回报是巨大的。如果数据库重构像一般的重构 那样得到广泛采用,软件开发将变得更加成熟。 John Graham, Eclipse Data Tools Platform项目管理委员会主席 Sbae公司高级工程师 数据社区在许多方面错过了整个敏捷软件开发革命。应用开发者已广泛应用重构、测试驱 动开发以及其他技术,使迭代成为有效的高级软件开发方式;而数据专业人土却在很大程度上 忽略了这些潮流,甚至把自己与潮流隔离开来。 当我还在一家大型金融服务机构做应用开发时,就清楚地看到了这一点。那时我的办公室 就在开发团队和数据库团队之间。我很快发现,尽管他们之间只有几步之遥,但两个团队的文 化、实践和过程是极为不同的。顾客的要求对开发团队来说就意味着一些重构,代码检入 ( check in),以及迅速的验收测试。对数据库团队而言,类似的请求就意味着正式的变更请求 要通过层层批准,最后才能开始修改 schema。这种繁杂的过程开销常常使开发人员和顾客变 得沮丧,但事情只能这样,因为数据库团队不知道能有什么其他办法 然而,如果他们的业务想在今天不断发生变化的竞争环境中得到发展,那么,他们就必须 学习其他的办法。数据社区必须像开发者那样采用一些敏捷技术。 本书是一本无价的资源,它向数据专业人士展示了怎样实现飞越,自信而安全地拥抱变 化。Sctt和 Pramod展示了小的、迭代式重构的设计改进如何使敏捷DBA避免大的前期设计 错误,以及如何随着对顾客需求理解的逐步加深与应用一起演进数据库 schema 不要弄错,重构数据库是很难的。即使是像列改名这样的简单变化,都会引起 schema 相关对象、持久层框架和应用层的相应改变,这令DBA觉得重构似乎是一种不可用的技术。 本书列出了一组实践说明,向专业DBA展示了如何将敏捷方法用于数据库的设计和开发。 Stt和 Pramod对实现每类数据库重构的详细描述证明了它是可行的,为数据库广泛采用重构 铺平了道路。 因此,我建议数据专业人士行动起来。阅读这本书,拥抱变化,广为宣传。数据库重构是 改进数据社区敏捷性的关键。 Sachin rekhi,微软公司项目经理 在系统开发的世界里,存在两种不同的文化:一种是由面向对象(OO)开发者主宰的, 他们在Java和敏捷软件开发中自由呼吸;另一种由关系数据库人员主宰,他们喜欢仔细的工 程方法和稳定的关系数据库设计。这两个阵营说着不同的语言,参加不同的会议,相互之间似 乎很少交谈。这种分裂在许多组织机构的IT部门中得到了反映。OO开发人员抱怨DBA们古 板而保守,不能跟上快速变化的节奏。数据库专业人士哀叹Java开发人员的愚蠢行为,因为 他们不知道怎样和数据库打交道。 Scott ambler和 Pramod Sadalage属于能够跨越两种文化的很少的一部分人。本书是从OO 架构师的角度来谈数据库设计的;因此,本书对于OO开发人员和关系数据库专业人员都有价 值。它帮助OO开发人员在数据库领域应用敏捷代码重构技术,并让关系数据库专业人员了解 00架构师的想法 这本书包含了许多提示和技巧,可用于改进数据库设计的质量。它明确关注如何解决真实 世界的问题,即数据库已经存在,但设计有问题,或者原来的数据库设计不能产生一种好的 模型 这本书在不同的层面上获得了成功。首先,它可以作为实战开发人员的战术指导。另外, 它也可以作为一本激发人思想的著作,让我们思考怎样融合OO和关系型思考方式。我希望更 多的系统架构师能响应 Ambler和 Sadalage的观点,认识到数据库不仅仅是存放类的持久拷贝 的地方。 Paul dorsey博士, Dulcian公司总裁, New York Oracle User Group总裁,J2 EE SIG主席 言 演进式开发以及敏捷软件开发方法学,如极限编程(XP)、Scrm、 Rational统一过程 (RUP)、敏捷统一过程(AUP)和特征驱动开发(FD),已经在过去几年中为信息技术 IT)产业带来了一场风暴。为了明确定义,演进式方法在本质上是迭代式和增量式的,敏捷 方法在本质上是演进式和高度协作的。而目,像重构、结对编程、测试驱动开发(TD)和敏 捷模型驱动开发(AMDD)等敏捷技术也正在进入IT组织机构中。这些方法和技术已经形成, 并在这些年里以草根的方式演进着,在实战中得到检验,而不是在象牙塔中形式化。简而言 之,这些演进式开发和敏捷方法学似乎在实践中非常有效。 在 Martin fowler的开创牲著作《 Refactoring》中,他将重构描述为对源代码的一些小改 动,这些改动会改进代码的设计,但不会改变其语义。换言之,你改进了工作的品质,但不会 破坏或增加任何东西。在那本书中 Martin提到,正如可以重构应用源代码一样,你也可能重 构数据库 schema(模式)。但是,他指出数据库重构相当困难,因为数据库中有相当程度的耦 合,因此他选择不在他的书中讨论这部分内容。 自1999年《 Refactoring》出版以来,我们俩发现了一些重构数据库 schema的方法。开始, 我们是独自工作的,在SoftwareDevelopment(www.sdexpo.comm)等一些会议上见面,并通过 邮件列表(www, agiledata org/ eedback htm)交流。我们讨论一些思想,参加对方的会议报 告,很快发现彼此的思想和技术有着共同之处,并且相互吻合。所以我们合作编写了本书,分 享我们在通过重构演进数据库 schema方面的经验和技术 本书中的示例代码是用Jaa、 Hibernate和 Oracle编写的。对于每一类数据库重构,描述 时基本上都包含了修改数据库 schema的代码;对于一些更有趣的重构,我们展示了它们对ava 应用代码所产生的影响。因为各种数据库并不一样,所以我们也讨论了当数据库产品之间存在 重要差别时一些替代的实现策略。有时候,我们讨论一类重构的替代穴现,这类重构使用了 Oracle专有的特征,如 SET UNUSED或 RENAME TO等命令;我们的许多代码示例也用到了 Oracle的 COMMENT ON特征。有些数据库包含另外一些使数据库重构变得容易的特征,好 的DEA会知道如何利用这些特征。更好的是,将来数据库重构工具会为我们完成这些事情。 而且,我们尽可能使Java代码保持简单,这样读者应该能够毫无困难地将这些代码转换成 C#、C+|或 Visual basic代码。 为何需要演进式数据库开发 演进式数据库开发是一个适时出现的概念。不是在项目的前期试图设计数据库 schema 而是在整个项目生命周期中逐步地形成它,以反映项目涉众确定的不断变化的需求。不论你是 否喜欢,需求会随着项目的推进而变化。传统的方式是忽略这个基本事实并试图以各种方式来