数据库设计中的敏捷方法--.doc

  1. 1、本文档共8页,可阅读全部内容。
  2. 2、原创力文档(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。
  3. 3、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载
  4. 4、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
查看更多
数据库设计中的敏捷方法--.doc

  数据库设计中的敏捷方法   0引言在过去几年中,我们将敏捷方法应用于数据库设计中。我们总结出一些技巧,使得当应用程序发展时,数据库也能够进化,这是敏捷方法的一个重要属性。我们的方法是通过持续集成以及自动重构,通过数据库管理人员(DBA)和应用开发人员的紧密合作。这些技巧在应用开发的各个时期都有效。1敏捷方法学   近年来,出现了一种新的软件开发方法学敏捷方法学。这给数据库设计提出了一些新的、巨大的需求。这些需求的一个中心就是进化设计。在一个敏捷项目中,需要假定我们并不能事先确定系统的需求。因此在项目的初期有一个详细设计阶段的想法是不现实的。系统的设计必须随着软件的变化而进化。敏捷方法,尤其是极限编程(XP),通过一些实践使这种进化设计成为可能。在数据库设计采用敏捷方法,反复迭代。   许多人会怀疑敏捷方法能否用于有大型数据库组件的系统。但我们的确使用了许多敏捷和XP技巧,用于解决基于大型数据库的项目中的进化与迭代问题。   本文将介绍一些在数据库设计采用敏捷方法的实践。当然,这并不是说我们已经完全解决了数据库进化的问题,但是我们想提供一些行之有效的方法。   2积极应对变化敏捷编程的一个显著特点就是它面对变化的态度。   对软件过程的一般解释是尽早理解需求,停止需求的变动,将这些需求作为设计的基础,停止设计的变动,然后开始构筑体系。这就是瀑布方法--基于计划的生命周期。   这种方法通过大量的前期工作来减少变化。一旦前期工作完成,需求变化会引起很大的问题。因此当需求变化时,这样的方法就会有很大的问题,因此需求变动是这种过程的一个很大的问题。   而敏捷编程却以另外一种方式来面对变化。拥抱变化,甚至允许在项目开发的后期发生变化。尽管变化会被控制,但是这种态度会允许尽可能多的变化。变化部分来自于项目需求的不稳定,部分来自于要支持变化的商业环境来面对竞争压力。   为了做到这样,必须采取不同的设计态度。设计不仅仅是一个阶段-在开始建筑之前就大部分完成的一个阶段;设计是一个持续的过程,与编码、测试甚至发布相关。这是计划设计与进化设计的不同之处。敏捷方法的一个重要贡献是提出了在可控制方式下的进化设计。因此不是由于设计没有预先计划好,产生了混乱。   敏捷方法提供了控制进化设计和使其可行的技巧。敏捷方法的一个重要特点就是迭代式开发,即整个项目生命周期中运行多个完整的软件生命周期循环。敏捷过程在每次迭代中都会度过一个完整的生命周期。迭代可以完成最终产品的需求子集中编码、测试以及集成代码。敏捷方法迭代时间较短,通常是一周到两个月之间,而且我们更倾向于更短的迭代周期。   当使用敏捷方法时,最大的问题就是数据库如何进行进化设计。许多人认为数据库设计是前期计划的工作,而在后期改变数据库设计计划会引起应用软件的崩溃;在配置以后改变数据库设计计划会导致数据迁移问题。   在过去三年我们参加了一个大型的项目,其中用到了切实可行的进化设计的方法。该项目包括100人的项目组, 200多张表格,数据库在一年半的最初开发中一直在进化,甚至在为多用户分发的过程中也在进化。一开始我们一个月迭代一次,过了几个月之后变为2周迭代一次。   随着我们将这些经验推广到项目中越来越多的部分,从越来越多的案例中获得经验。同时,我们也从其他敏捷项目中吸收了一些经验。   2.1限制条件在讲述实践方法之前,必须指出我们并没有解决所有的数据库进化设计问题,特别是:   uuml;     我们是为单独的应用设计一个应用数据库,而不是试图集成多个数据库;   uuml;     我们没有做到24*7的数据库更新。   虽然很多人认为我们无法解决这个问题,但其实这些问题是可以解决的。当然这需要进一步的工作,光说是不能解决问题的。   3实践   我们有关于数据库进化设计的方法依赖于一些重要的实践。   3.1数据库管理人员与开发人员紧密合作   敏捷方法的一个重要原则就是拥有不同技能和背景的人能够紧密合作。正式的会议和文档不能达到交流效果,因此他们需要一直一起工作,亲密合作。所有的项目组成员都需要紧密合作:系统分析人员,项目经理,行业专家,开发人员以及数据库管理人员(DBA)开发人员的每项工作可能都需要DBA的帮助。   开发人员和DBA需要考虑是否需要对数据库计划做很大的改变。开发人员向DBA咨询如何应对变化:开发人员知道需要什么新的功能,而DBA对应用中的数据有全局的观念。   为了达到亲密合作的效果,DBA必须使自己易于接近。DBA需要留出几分钟的时间,让开发人员来提问。必须确保DBA和开发人员坐在一起,这样他们就很容易沟通。同时必须确保应用设计会议是公开的

文档评论(0)

ggkkppp + 关注
实名认证
内容提供者

该用户很懒,什么也没介绍

1亿VIP精品文档

相关文档