（已有6条评价）基本信息
- 原书名：Agile Database Techniques : Effective Strategies for the Agile Software Developer
- 原出版社： Wiley Publishing
编辑推荐
这是一本真正的好书。购买它、阅读它、推广它。
“我真希望自己八年前就能有这样一本书。开发人员和数据库人员都应该有这本书。”
--Jon Kern，敏捷联盟的创始成员.
“你在这里能够找到实用的。有现实意义的建议。”
--Doug Barry，《The Object Database Handbook》的作者
内容简介
书籍
计算机书籍
本书作者在数据及对象技术方面都有很深造诣，多年的经验使他深刻地认识到：数据专业人员常常过于专注数据而忽视对象开发人员所面临的困难；而对象开发人员又没有或有很少的数据方面的经验。本书作者探索了有机结合数据和对象两个开发团队的方式，将敏捷方法拓展到了应用程序开发的一个关键领域——数据库，阐述了数据架构设计师、数据库管理员掌握敏捷方法进行面向数据开发的必要性。
本书分四部分。第一部分描述数据专业人员和对象专业人员所需的基本技能和方法，第二部分介绍进行渐进式数据库开发的方法，第三部分概述有效地结合使用对象技术、关系数据库技术和XML技术的方法，第四部分总结如何成功地采用本书所描述的技术方法。本书适合应用程序开发人员及数据处理人员阅读。...
主要内容：
敏捷数据库管理员(DBA)承担着专门解决面向数据问题的艰巨任务，包括传统意义上的数据库管理和所有涉及数据的应用程序开发。敏捷DBA还要与企业专业人员一起协作，以确保项目团队的工作能够反映企业的现实情况。本书从敏捷DBA的角度论述开发过程，通过本书能够学习敏捷DBA在渐进式(迭代和增量式)软件项目上有效进行工作所采用的方法。.
本书每章都涉及面向数据活动的核心方面，例如：
●面向对象、关系型数据库、数据建模，以及如何处理遗留数据问题的基本知识。
●数据库重构，这是一种以小步渐进的方式改善自己数据库设计的方法。
●对象—关系数据库映射、性能优化、数据库封装和辅助工具。..
●实现方法和策略，如并发控制、安全访问控制、在关系数据库中查找对象、引用完整性，以及有效使用XML。
●对那些想要成为敏捷开发人员和想要采纳敏捷方法的组织机构提供了策略和建议。
计算机书籍
本书作者在数据及对象技术方面都有很深造诣，多年的经验使他深刻地认识到：数据专业人员常常过于专注数据而忽视对象开发人员所面临的困难；而对象开发人员又没有或有很少的数据方面的经验。本书作者探索了有机结合数据和对象两个开发团队的方式，将敏捷方法拓展到了应用程序开发的一个关键领域——数据库，阐述了数据架构设计师、数据库管理员掌握敏捷方法进行面向数据开发的必要性。
本书分四部分。第一部分描述数据专业人员和对象专业人员所需的基本技能和方法，第二部分介绍进行渐进式数据库开发的方法，第三部分概述有效地结合使用对象技术、关系数据库技术和XML技术的方法，第四部分总结如何成功地采用本书所描述的技术方法。本书适合应用程序开发人员及数据处理人员阅读。...
主要内容：
敏捷数据库管理员(DBA)承担着专门解决面向数据问题的艰巨任务，包括传统意义上的数据库管理和所有涉及数据的应用程序开发。敏捷DBA还要与企业专业人员一起协作，以确保项目团队的工作能够反映企业的现实情况。本书从敏捷DBA的角度论述开发过程，通过本书能够学习敏捷DBA在渐进式(迭代和增量式)软件项目上有效进行工作所采用的方法。.
本书每章都涉及面向数据活动的核心方面，例如：
●面向对象、关系型数据库、数据建模，以及如何处理遗留数据问题的基本知识。
●数据库重构，这是一种以小步渐进的方式改善自己数据库设计的方法。
●对象—关系数据库映射、性能优化、数据库封装和辅助工具。..
●实现方法和策略，如并发控制、安全访问控制、在关系数据库中查找对象、引用完整性，以及有效使用XML。
●对那些想要成为敏捷开发人员和想要采纳敏捷方法的组织机构提供了策略和建议。
作译者
Scott W．Ambler是Ronin International公司(www．ronin-intl．com)的总裁和高级顾问，这是一家专门从事软件过程指导和基于对象／组件软件架构设计和开发的软件服务咨询公司。他还是《Software Development》杂志的特约编辑和《Computing Canada》杂志的专栏作家，他撰写或与他人合著过多部著作，包括《敏捷建模》、《The Object Primer中文版》等。他的个人网站是www．ambysoft．com。
目录
译者序
Jon Kern序
Douglas K．Barry序
致谢.
前言
第一部分基础背景
第1章 敏捷数据方法
1．1 缘何当前难以相互合作
1．2 发现问题
1．3 敏捷运动
1．3．1 敏捷软件开发宣言
1．3．2 敏捷软件开发原则
1．4 敏捷数据的基本原理
1．5 敏捷数据概述
1．5．1 敏捷DBA
1．5．2 应用程序开发者
1．5．3 企业管理员
1．5．4 企业架构设计师
1．6 敏捷软件开发者
1．7 敏捷数据能解决我们的问题吗
Jon Kern序
Douglas K．Barry序
致谢.
前言
第一部分基础背景
第1章 敏捷数据方法
1．1 缘何当前难以相互合作
1．2 发现问题
1．3 敏捷运动
1．3．1 敏捷软件开发宣言
1．3．2 敏捷软件开发原则
1．4 敏捷数据的基本原理
1．5 敏捷数据概述
1．5．1 敏捷DBA
1．5．2 应用程序开发者
1．5．3 企业管理员
1．5．4 企业架构设计师
1．6 敏捷软件开发者
1．7 敏捷数据能解决我们的问题吗
译者序
谁说数据不能跳舞
敏捷联盟、敏捷宣言、敏捷建模、敏捷文档、敏捷Web开发…….
敏捷，当今软件开发的又一个buzzword。作者这一次又将敏捷思想的触角伸及到数据领域。作为数据建模和对象建模专家以及敏捷方法的积极布道者，Ambler无疑是该领域最合适的人选。可是，这又是一本关于数据方面的书籍吗?
答案既“是”又“不是”。之所以说“是”，是因为本书涵盖了数据建模的方方面面，从最基本的数据规范化、关系—对象映射，到高级的数据库重构、并发控制与性能优化，一应俱全；而且本书的阅读门槛并不高，它沿袭了著者一贯的论述风格，即便对那些相对高级的主题也是娓娓道来、点到为止。如果你还嫌不够，作者还为你推荐了各个相关主题的经典著作并给出中肯的评价，足够你就某一主题掘地三尺。
之所以说“不是”，是因为这不是一本单单写给数据专业人员的书。作者强烈建议应用程序开发人员也应该读一读本书，因他深知对象和数据技术由于底层范型的不同而导致这两大阵营在观念上存在差异，甚至彼此对立、相互倾轧。因而本书开篇就着重探讨这两种技术之间的阻抗失配，同时恳请应用程序开发人员和数据专业人员能够真正地抛开成见，通力协作。
诚然，那些关于数据的章节或许是本书的主要论述内容，但著者更想与你分享如何敏捷地去做事情、去思考，以及如何建立有效的相互协作的敏捷团队，就像具体的技能或框架或许可以供你一时享用，而思维方式和行事之道则更有助于解决问题和拥抱变化。从这个意义上来说，敏捷更是一种做事态度：你必须首先选择这样去做，并且愿意尝试变化，而不是墨守成规，把自己框定在熟悉的领地不放。..
同那些顽固的数据专业人员一样，对象阵营中也有一部分人沉溺于“纯对象主义”的光环固步自封。作者在书中反复强调，这个世界色彩绚丽，你不只有黑和白两种选择，不要从一个极端走向另一个极端。作为敏捷思想的提倡者，作者建议那些想实践敏捷思想的开发人员致力于成为一名通用型的专家，而非传统意义上的专家。尝试以别人的思路去考量问题，开放思维，取长补短。关系数据库中的数据规范化，过程化设计中模块的耦合与内聚性，以及OO(面向对象)设计中的单一职责原则、依赖反转原则又何尝不昭示着思想上的共通性呢?
权衡的重要性在本书各章的论述中反复加以印证。无论是应用程序开发还是数据开发，都应该根据自己的切身情况做出权衡，找出适合自己情况的最佳点。想想数据建模中采用非规范化的手法改善性能，程序设计中以增加间接层获得灵活性的思想，也无处不体现了权衡的艺术。
建议读者仔细看看本书最后关于“有效成为一名敏捷数据开发人员”的建议，这同样适用
于应用程序开发人员。我想这两章会给读者带来一些震撼，试着以别人的方式看待问题，像敏捷宣言里提倡的那样拥抱变化、轻装前进。谁说数据开发不能敏捷呢?
最后，感谢UMLChina的潘加宇先生在翻译过程中所给予的鼓励和帮助。感谢我的妻子何晓梅为本译稿所做的大量的文字工作，你对译文的推敲质疑使我如履薄冰，而你在旁边的陪伴则使我安心和专注。
李巍，UMLChina...
2005年9月于北京
敏捷联盟、敏捷宣言、敏捷建模、敏捷文档、敏捷Web开发…….
敏捷，当今软件开发的又一个buzzword。作者这一次又将敏捷思想的触角伸及到数据领域。作为数据建模和对象建模专家以及敏捷方法的积极布道者，Ambler无疑是该领域最合适的人选。可是，这又是一本关于数据方面的书籍吗?
答案既“是”又“不是”。之所以说“是”，是因为本书涵盖了数据建模的方方面面，从最基本的数据规范化、关系—对象映射，到高级的数据库重构、并发控制与性能优化，一应俱全；而且本书的阅读门槛并不高，它沿袭了著者一贯的论述风格，即便对那些相对高级的主题也是娓娓道来、点到为止。如果你还嫌不够，作者还为你推荐了各个相关主题的经典著作并给出中肯的评价，足够你就某一主题掘地三尺。
之所以说“不是”，是因为这不是一本单单写给数据专业人员的书。作者强烈建议应用程序开发人员也应该读一读本书，因他深知对象和数据技术由于底层范型的不同而导致这两大阵营在观念上存在差异，甚至彼此对立、相互倾轧。因而本书开篇就着重探讨这两种技术之间的阻抗失配，同时恳请应用程序开发人员和数据专业人员能够真正地抛开成见，通力协作。
诚然，那些关于数据的章节或许是本书的主要论述内容，但著者更想与你分享如何敏捷地去做事情、去思考，以及如何建立有效的相互协作的敏捷团队，就像具体的技能或框架或许可以供你一时享用，而思维方式和行事之道则更有助于解决问题和拥抱变化。从这个意义上来说，敏捷更是一种做事态度：你必须首先选择这样去做，并且愿意尝试变化，而不是墨守成规，把自己框定在熟悉的领地不放。..
同那些顽固的数据专业人员一样，对象阵营中也有一部分人沉溺于“纯对象主义”的光环固步自封。作者在书中反复强调，这个世界色彩绚丽，你不只有黑和白两种选择，不要从一个极端走向另一个极端。作为敏捷思想的提倡者，作者建议那些想实践敏捷思想的开发人员致力于成为一名通用型的专家，而非传统意义上的专家。尝试以别人的思路去考量问题，开放思维，取长补短。关系数据库中的数据规范化，过程化设计中模块的耦合与内聚性，以及OO(面向对象)设计中的单一职责原则、依赖反转原则又何尝不昭示着思想上的共通性呢?
权衡的重要性在本书各章的论述中反复加以印证。无论是应用程序开发还是数据开发，都应该根据自己的切身情况做出权衡，找出适合自己情况的最佳点。想想数据建模中采用非规范化的手法改善性能，程序设计中以增加间接层获得灵活性的思想，也无处不体现了权衡的艺术。
建议读者仔细看看本书最后关于“有效成为一名敏捷数据开发人员”的建议，这同样适用
于应用程序开发人员。我想这两章会给读者带来一些震撼，试着以别人的方式看待问题，像敏捷宣言里提倡的那样拥抱变化、轻装前进。谁说数据开发不能敏捷呢?
最后，感谢UMLChina的潘加宇先生在翻译过程中所给予的鼓励和帮助。感谢我的妻子何晓梅为本译稿所做的大量的文字工作，你对译文的推敲质疑使我如履薄冰，而你在旁边的陪伴则使我安心和专注。
李巍，UMLChina...
2005年9月于北京
前言
敏捷的绪论：这是一本真正的好书。购买它、阅读它、推广它。.
从20世纪90年代初以来，我就一直在工作中使用对象和关系数据库(RDB)技术，来构建业务应用程序，并且从90年代中期开始，我在这个主题上已经撰写颇多文章。这些文章被发表在《Software Development》(WWW．sdmagazine．com)上、我的几本书籍(特别是《Building Object Applications That Work》和《The Object Primer》)中以及我的个人主页上。我站点上的两本白皮书非常受欢迎，一本是关于对象—RDB映射的，另一本则描述持久层的设计，这些年来它有成千上万的下载量。有关持久层的文章已被用作多个开源产品的基本原理。尽管对我来说，通过这些著作分享我的想法是非常值得的，但是我从未花时间把这些作品整理到一处，而且我也没有写完关于该主题我所有想说的内容。本书将扭转这种局面。
作为一名顾问，我会与对象和数据专业人员一起工作，并使用他们相关的技术，当然还有他们的方法。在这样做的过程中，无论是采用近似连续的方式开发的传统环境，还是使用一种敏捷和渐进式开发方式的更现代的环境，我都在其中工作过。随着时间推移，我在许多不同的项目团队上充当过各种角色。对于每个项目的成功而言，面向数据的问题很重要，有时候甚至是至关重要的。尽管传统的项目团队看起来能够处理如何解决数据的问题，但是更加敏捷的团队常常对此产生质疑——一部分原因是这些组织机构内的数据专业人员倾向于使用一种连续性的方式，一部分原因是对象开发人员没有意识到面向数据的问题的重要性。作为一名前数据专家(哦不，泄露了我可怕的秘密!)并拥有在对象技术方面的经验，我常常可以找到这两个团体相互合作的方式。我的经验是数据专业人员常常过于专注数据，而将对象开发人员所面对的各种挑战排除在外；同样对象开发人员有很少的或没有数据相关的经验。因此，我会帮助这两个团体寻找相互合作的方式，针对其他每种方法对他们进行指导，并且帮助他们克服被称做对象—关系阻抗失配的问题。这两个团体要想有效地一起工作，他们都需要理解和重视其他团体所专注的东西，而且我甚至质疑各个团体最初持有的判断力(wisdom)。本书描述了数据专业人员和对象专业人员在构建现代软件时所需的技能。
作为一名方法学者，我积极致力于寻找有效开发软件的方法，而且这些年来，已涵盖了从正规方法(例如，有关过程模式(process pattern，www．ambysofi．com／processPattemsPage．html)和企业统一过程(Enterprise UnifiedProcess，EUP，www．enterpriseunifiedprocess．info)的工作)到敏捷方法(如敏捷建模AM(www．agilemodeling．com)和现在的敏捷数据库方法)的方方面面。从某个方面来说，本书是AM的延续，有助于描述数据专业人员如何采用一种渐进(迭代和增量)的开发方式。尽管数据阵营内的许多人坚决反对渐进的方式，有趣的是我经常发现那些反对者从来都没有实际去尝试它；事实是敏捷软件开发是真实的，并且能够留存下来。数据专业人员要想与时俱进，他们必须做好以一种敏捷方式工作的准备，否则项目团队很有可能找到
绕开他们工作的方式(我猜想你总能在自己的组织机构中看到这种事情的发生)。在实际项目中我的经验是，对面向数据的活动采取一种敏捷的方式，你确实能够获得极大的成功，如果你选择这样去做的话。许多人将告诉你它没有用，但是他们真正所说的是他们可能无法让它运转，或者他们不想让它有用。本书描述了多种验证过的支持渐进式面向数据开发的方法。
在刚开始编写本书时，我想专注于敏捷数据(AD)方法(www．agiledata．org)。该方法(总结于第1章中)描述了数据专业人员和应用程序开发人员如何能够一起有效地在敏捷项目上工作。它还描述了企业专业人员(如企业架构设计师和数据管理员)如何能够有效地支持敏捷开发团队。由于我采用了一种迭代和增量的方式来书写本书，我便迅速意识到真正的价值在于具体的开发方法，而非另一种方法学。因此我重新调整自己的关注点。
本书的读者..
谁是本书的读者?简单的答案是任何敏捷软件开发团队成员，或至少与这个团队打交道的人。更为复杂的答案是：
敏捷／极限编程人员。如果你所构建的软件是对数据进行操作，那么机会难得：因此，你需要采纳本书中所描述的许多方法。
数据库管理员。本书描述了你如何在一个敏捷软件开发团队上取得成功。请从头至尾细细研读。
数据管理员。随着时间的推移，你需要支持越来越多的敏捷开发团队，因此你需要理解他们是如何工作的，以及他们为什么这样工作。本书提供了你帮助这些团队提高效率所需的见解。
架构设计师。敏捷、渐进式开发正快速成为大多数组织机构内的规范。本书描述了你可以在这些团队中有效工作而采取的方法。
团队领导者／指导员／经理。为了有效地领导敏捷软件开发团队，你必须了解你们团队所使用的方法，他们为什么要使用这些方法，以及这么做意味着什么。本书不但描述了这些方法，而且还论述了它们之间该如何权衡，使你能够帮助团队做出明智的决定。
为何把注意力放在敏捷DBA上面
尽管我在本书中描述的大多数技能都同时适用于应用程序开发人员和数据库管理员(DBA)，但是我选择从敏捷DBA的角度来表达它们。一个敏捷DBA会专注于面向数据的问题，包括传统的数据库管理和任何涉及数据的应用程序的开发。敏捷DBA还会与企业专业人员进行协作，以确保项目团队的工作能够反映企业的现实情况。更重要的是，他们需要以一种敏捷的方式做这项工作。敏捷DBA的角色可以由你们项目中的多个人来担任，由多个人共同轮流分担，或者由一个人单独担任。尽管敏捷DBA的技能集(skillset)看上去比较难以掌握，而且确实如此，但是你可以通过与其他具备你所缺少的技能的人一起工作，通过培训，或者通过自己实际地尝试，来不断地获取这些技能。
概述
本书由四个部分组成。第一部分为有效地进行面向数据的活动奠定了基础，描述了所有IT
专业人员所需的基本技能和原则。第二部分描述了进行渐进式数据库开发的方法，说明了采取一种迭代和增量式的面向数据的开发方式是可能的。第三部分概述了有效地结合使用对象技术、关系数据库技术和XML(Extensible Markup Language，可扩展标记语言)技术的详细实现方法。第四部分概括论述了如何成功地采用本书所描述的概念。
第一部分
IT业界一个显著的问题是，大多数数据书籍没有涉及到面向对象开发的问题，而大多数对象书籍看起来也忽略了数据问题。需要对这种局面喊停。第一部分描述了敏捷项目团队中的每个人应该具备的基本技能和知识。包括面向对象、关系数据库、对象—关系阻抗失配、数据建模，以及如何处理遗留数据问题的基础内容。如果没有这种通用的知识基础，应用程序开发人员和数据专业人员将很难有效地一起工作。
从20世纪90年代初以来，我就一直在工作中使用对象和关系数据库(RDB)技术，来构建业务应用程序，并且从90年代中期开始，我在这个主题上已经撰写颇多文章。这些文章被发表在《Software Development》(WWW．sdmagazine．com)上、我的几本书籍(特别是《Building Object Applications That Work》和《The Object Primer》)中以及我的个人主页上。我站点上的两本白皮书非常受欢迎，一本是关于对象—RDB映射的，另一本则描述持久层的设计，这些年来它有成千上万的下载量。有关持久层的文章已被用作多个开源产品的基本原理。尽管对我来说，通过这些著作分享我的想法是非常值得的，但是我从未花时间把这些作品整理到一处，而且我也没有写完关于该主题我所有想说的内容。本书将扭转这种局面。
作为一名顾问，我会与对象和数据专业人员一起工作，并使用他们相关的技术，当然还有他们的方法。在这样做的过程中，无论是采用近似连续的方式开发的传统环境，还是使用一种敏捷和渐进式开发方式的更现代的环境，我都在其中工作过。随着时间推移，我在许多不同的项目团队上充当过各种角色。对于每个项目的成功而言，面向数据的问题很重要，有时候甚至是至关重要的。尽管传统的项目团队看起来能够处理如何解决数据的问题，但是更加敏捷的团队常常对此产生质疑——一部分原因是这些组织机构内的数据专业人员倾向于使用一种连续性的方式，一部分原因是对象开发人员没有意识到面向数据的问题的重要性。作为一名前数据专家(哦不，泄露了我可怕的秘密!)并拥有在对象技术方面的经验，我常常可以找到这两个团体相互合作的方式。我的经验是数据专业人员常常过于专注数据，而将对象开发人员所面对的各种挑战排除在外；同样对象开发人员有很少的或没有数据相关的经验。因此，我会帮助这两个团体寻找相互合作的方式，针对其他每种方法对他们进行指导，并且帮助他们克服被称做对象—关系阻抗失配的问题。这两个团体要想有效地一起工作，他们都需要理解和重视其他团体所专注的东西，而且我甚至质疑各个团体最初持有的判断力(wisdom)。本书描述了数据专业人员和对象专业人员在构建现代软件时所需的技能。
作为一名方法学者，我积极致力于寻找有效开发软件的方法，而且这些年来，已涵盖了从正规方法(例如，有关过程模式(process pattern，www．ambysofi．com／processPattemsPage．html)和企业统一过程(Enterprise UnifiedProcess，EUP，www．enterpriseunifiedprocess．info)的工作)到敏捷方法(如敏捷建模AM(www．agilemodeling．com)和现在的敏捷数据库方法)的方方面面。从某个方面来说，本书是AM的延续，有助于描述数据专业人员如何采用一种渐进(迭代和增量)的开发方式。尽管数据阵营内的许多人坚决反对渐进的方式，有趣的是我经常发现那些反对者从来都没有实际去尝试它；事实是敏捷软件开发是真实的，并且能够留存下来。数据专业人员要想与时俱进，他们必须做好以一种敏捷方式工作的准备，否则项目团队很有可能找到
绕开他们工作的方式(我猜想你总能在自己的组织机构中看到这种事情的发生)。在实际项目中我的经验是，对面向数据的活动采取一种敏捷的方式，你确实能够获得极大的成功，如果你选择这样去做的话。许多人将告诉你它没有用，但是他们真正所说的是他们可能无法让它运转，或者他们不想让它有用。本书描述了多种验证过的支持渐进式面向数据开发的方法。
在刚开始编写本书时，我想专注于敏捷数据(AD)方法(www．agiledata．org)。该方法(总结于第1章中)描述了数据专业人员和应用程序开发人员如何能够一起有效地在敏捷项目上工作。它还描述了企业专业人员(如企业架构设计师和数据管理员)如何能够有效地支持敏捷开发团队。由于我采用了一种迭代和增量的方式来书写本书，我便迅速意识到真正的价值在于具体的开发方法，而非另一种方法学。因此我重新调整自己的关注点。
本书的读者..
谁是本书的读者?简单的答案是任何敏捷软件开发团队成员，或至少与这个团队打交道的人。更为复杂的答案是：
敏捷／极限编程人员。如果你所构建的软件是对数据进行操作，那么机会难得：因此，你需要采纳本书中所描述的许多方法。
数据库管理员。本书描述了你如何在一个敏捷软件开发团队上取得成功。请从头至尾细细研读。
数据管理员。随着时间的推移，你需要支持越来越多的敏捷开发团队，因此你需要理解他们是如何工作的，以及他们为什么这样工作。本书提供了你帮助这些团队提高效率所需的见解。
架构设计师。敏捷、渐进式开发正快速成为大多数组织机构内的规范。本书描述了你可以在这些团队中有效工作而采取的方法。
团队领导者／指导员／经理。为了有效地领导敏捷软件开发团队，你必须了解你们团队所使用的方法，他们为什么要使用这些方法，以及这么做意味着什么。本书不但描述了这些方法，而且还论述了它们之间该如何权衡，使你能够帮助团队做出明智的决定。
为何把注意力放在敏捷DBA上面
尽管我在本书中描述的大多数技能都同时适用于应用程序开发人员和数据库管理员(DBA)，但是我选择从敏捷DBA的角度来表达它们。一个敏捷DBA会专注于面向数据的问题，包括传统的数据库管理和任何涉及数据的应用程序的开发。敏捷DBA还会与企业专业人员进行协作，以确保项目团队的工作能够反映企业的现实情况。更重要的是，他们需要以一种敏捷的方式做这项工作。敏捷DBA的角色可以由你们项目中的多个人来担任，由多个人共同轮流分担，或者由一个人单独担任。尽管敏捷DBA的技能集(skillset)看上去比较难以掌握，而且确实如此，但是你可以通过与其他具备你所缺少的技能的人一起工作，通过培训，或者通过自己实际地尝试，来不断地获取这些技能。
概述
本书由四个部分组成。第一部分为有效地进行面向数据的活动奠定了基础，描述了所有IT
专业人员所需的基本技能和原则。第二部分描述了进行渐进式数据库开发的方法，说明了采取一种迭代和增量式的面向数据的开发方式是可能的。第三部分概述了有效地结合使用对象技术、关系数据库技术和XML(Extensible Markup Language，可扩展标记语言)技术的详细实现方法。第四部分概括论述了如何成功地采用本书所描述的概念。
第一部分
IT业界一个显著的问题是，大多数数据书籍没有涉及到面向对象开发的问题，而大多数对象书籍看起来也忽略了数据问题。需要对这种局面喊停。第一部分描述了敏捷项目团队中的每个人应该具备的基本技能和知识。包括面向对象、关系数据库、对象—关系阻抗失配、数据建模，以及如何处理遗留数据问题的基础内容。如果没有这种通用的知识基础，应用程序开发人员和数据专业人员将很难有效地一起工作。
序言
我希望每个阅读这篇序的人都能立刻翻到本书的第23章，看看关于如何变得更加敏捷的建议表。是不是这个表中的条目使你感到有些不舒服?很好。你是否认为这些建议没有什么必要?为什么会这样?听我的建议：你的确需要照Scott建议的去做。为了提高你们项目的成功几率，这些是你能够采取的第一步。而且它们做起来可能非常不舒服。.
某些精神上的不适，对那些想要有所改变的人来说是一件好事。毫无疑问，我们构建(或构建失败的)软件系统的方式需要改变。其中包括数据库。如果我们都在做自己能够找到的、舒服的事情，那么变化的可能性将很小。
对我来说，Scott在第23章中所建议的花一段时间从别人的角度考虑问题是一件好事情。确实需要坚持。能够与其他人进行交谈，并设身处地地关注和理解他们的处境，这一点很好，但还不够。实际去尝试其他人的工作是一段非常不同的经历。
我知道这一点是因为我经历过许多。在我职业生涯初期，我是一家大公司的数据建模的领头人。于是，我参与软件设计，并不得不处理其他人的数据库设计。之后，我成为一家刚成立的数据库公司的CIO。随后从事了许多年数据库相关标准的开发工作。-同时，我开始帮助人们理解什么才是满足他们需要的最佳架构——这正是我当前的工作。让我来告诉你，这已经成为一门教育，而且时常会让我感到不舒服，但现在我的状况在逐渐好转。从我的经历来说，Scott似乎为你展示了一条可以沿循的好路线。..
在整本书中，Scott囊括了使用敏捷方法进行数据库开发的实用建议。你可能不一定总是认同，但这很可能会挑战你的思维方式。这同样是一件好事情。
Scott还提出了一些常识性的设计建议，来开发数据库以及不同类型系统之间的数据映射。这些建议非常重要，而且在那些基础的建模文章中你并不是总能找到它们。
正是由于这些使你变得敏捷的不一般的建议和常识性的设计建议，注定了这是一本极为全面的好书，尤其是对那些想跨越基础的建模文章的人。你在这里能够找到实用的、有现实意义的建议。
Douglas K．Barry
Baby & Associates公司的创始人和总裁
(www．barryandassociates．com)...
某些精神上的不适，对那些想要有所改变的人来说是一件好事。毫无疑问，我们构建(或构建失败的)软件系统的方式需要改变。其中包括数据库。如果我们都在做自己能够找到的、舒服的事情，那么变化的可能性将很小。
对我来说，Scott在第23章中所建议的花一段时间从别人的角度考虑问题是一件好事情。确实需要坚持。能够与其他人进行交谈，并设身处地地关注和理解他们的处境，这一点很好，但还不够。实际去尝试其他人的工作是一段非常不同的经历。
我知道这一点是因为我经历过许多。在我职业生涯初期，我是一家大公司的数据建模的领头人。于是，我参与软件设计，并不得不处理其他人的数据库设计。之后，我成为一家刚成立的数据库公司的CIO。随后从事了许多年数据库相关标准的开发工作。-同时，我开始帮助人们理解什么才是满足他们需要的最佳架构——这正是我当前的工作。让我来告诉你，这已经成为一门教育，而且时常会让我感到不舒服，但现在我的状况在逐渐好转。从我的经历来说，Scott似乎为你展示了一条可以沿循的好路线。..
在整本书中，Scott囊括了使用敏捷方法进行数据库开发的实用建议。你可能不一定总是认同，但这很可能会挑战你的思维方式。这同样是一件好事情。
Scott还提出了一些常识性的设计建议，来开发数据库以及不同类型系统之间的数据映射。这些建议非常重要，而且在那些基础的建模文章中你并不是总能找到它们。
正是由于这些使你变得敏捷的不一般的建议和常识性的设计建议，注定了这是一本极为全面的好书，尤其是对那些想跨越基础的建模文章的人。你在这里能够找到实用的、有现实意义的建议。
Douglas K．Barry
Baby & Associates公司的创始人和总裁
(www．barryandassociates．com)...
