引言 過(guò)去幾年中，我們將敏捷方法應用于
數據庫設計，總結出一些
技巧，使得當應用程序發(fā)展時(shí)，
數據庫也能夠進(jìn)化，這是敏捷方法的一個(gè)重要屬性。我們的方法是通過(guò)持續集成以及自動(dòng)重構，通過(guò)
數據庫管理人員（DBA）
和應用開(kāi)發(fā)人員的緊密合作來(lái)
設計數據庫。這些
技巧在應用開(kāi)發(fā)的各個(gè)時(shí)期都有效。
1 敏捷方法學(xué) 近年來(lái)，出現了一種新的軟件開(kāi)發(fā)方法學(xué)——敏捷方法學(xué)。這給
數據庫設計提出了一些新的、巨大的需求。這些需求的一個(gè)中心就是進(jìn)化
設計。在一個(gè)敏捷項目中，需要假定我們并不能事先確定系統的需求，因此在項目的初期有一個(gè)詳細
設計階段的想法是不現實(shí)的。系統的
設計必須隨著(zhù)軟件的變化而進(jìn)化。敏捷方法，尤其是極限編程（XP），通過(guò)一些實(shí)踐使這種進(jìn)化
設計成為可能。在
數據庫設計采用敏捷方法，反復迭代。
許多人會(huì )懷疑敏捷方法能否用于有大型
數據庫組件的系統，但我們的確使用了許多敏捷和XP
技巧，用于解決基于大型
數據庫的項目中的進(jìn)化與迭代問(wèn)題。
本文將介紹一些在
數據庫設計采用敏捷方法的實(shí)踐。當然，這并不是說(shuō)我們已經(jīng)完全解決了
數據庫進(jìn)化的問(wèn)題，但是我們想提供一些行之有效的方法。
2 積極應對變化 敏捷編程的一個(gè)顯著(zhù)特點(diǎn)就是它面對變化的態(tài)度。對軟件過(guò)程的一般解釋是盡早理解需求，停止需求的變動(dòng)，將這些需求作為
設計的基礎，停止
設計的變動(dòng)，然后開(kāi)始構筑體系，這就是瀑布方法——基于計劃的生命周期。
這種方法通過(guò)大量的前期工作來(lái)減少變化，一旦前期工作完成，需求變化會(huì )引起很大的問(wèn)題。當需求變化時(shí)，這樣的方法就會(huì )有很大的問(wèn)題，因此需求變動(dòng)是這種過(guò)程的一個(gè)很大的問(wèn)題。
而敏捷編程卻以另外一種方式來(lái)面對變化、擁抱變化，甚至允許在項目開(kāi)發(fā)的后期發(fā)生變化。盡管變化會(huì )被控制，但是這種態(tài)度會(huì )允許盡可能多的變化。變化部分來(lái)自于項目需求的不穩定，部分來(lái)自于要支持變化的商業(yè)環(huán)境來(lái)面對競爭壓力。
為了做到這樣，必須采取不同的
設計態(tài)度。
設計不僅僅是一個(gè)階段——在開(kāi)始建筑之前就大部分完成的一個(gè)階段，
設計是一個(gè)持續的過(guò)程，與編碼、測試甚至發(fā)布相關(guān)，這是計劃
設計與進(jìn)化
設計的不同之處。敏捷方法的一個(gè)重要貢獻是提出了在可控制方式下的進(jìn)化
設計，提供了控制進(jìn)化
設計和使其可行的
技巧。
敏捷方法的一個(gè)重要特點(diǎn)就是迭代式開(kāi)發(fā)，即整個(gè)項目生命周期中運行多個(gè)完整的軟件生命周期循環(huán)。敏捷過(guò)程在每次迭代中都會(huì )度過(guò)一個(gè)完整的生命周期，迭代可以完成最終產(chǎn)品的需求子集中編碼、測試以及集成代碼。敏捷方法迭代時(shí)間較短，通常是一周到兩個(gè)月之間，而且我們更傾向于更短的迭代周期。
當使用敏捷方法時(shí)，最大的問(wèn)題就是
數據庫如何進(jìn)行進(jìn)化
設計。許多人認為
數據庫設計是前期計劃的工作，而在后期改變
數據庫設計計劃會(huì )引起應用軟件的崩潰；在配置以后改變
數據庫設計計劃會(huì )導致數據遷移問(wèn)題。
在過(guò)去三年我們參加了一個(gè)大型的項目，其中用到了切實(shí)可行的進(jìn)化
設計的方法。該項目包括100人的項目組，200多張表格，
數據庫在一年半的最初開(kāi)發(fā)中一直在進(jìn)化，甚至在為多用戶(hù)分發(fā)的過(guò)程中也在進(jìn)化。一開(kāi)始我們一個(gè)月迭代一次，過(guò)了幾個(gè)月之后變?yōu)閮芍艿淮巍?
隨著(zhù)我們將這些經(jīng)驗推廣到項目中越來(lái)越多的部分，從越來(lái)越多的案例中獲得經(jīng)驗。同時(shí)，我們也從其他敏捷項目中吸收了一些經(jīng)驗。
2.1 限制條件
在講述實(shí)踐方法之前，必須指出我們并沒(méi)有解決所有的
數據庫進(jìn)化
設計問(wèn)題，特別是：
(1) 我們是為單獨的應用
設計一個(gè)應用
數據庫，而不是試圖集成多個(gè)
數據庫；
(2) 我們沒(méi)有做到24*7的
數據庫更新。
雖然很多人認為我們無(wú)法解決這個(gè)問(wèn)題，但其實(shí)這些問(wèn)題是可以解決的。當然這需要進(jìn)一步的工作，光說(shuō)是不能解決問(wèn)題的。
3 實(shí)踐 我們有關(guān)于
數據庫進(jìn)化
設計的方法依賴(lài)于一些重要的實(shí)踐。
3.1
數據庫管理人員與開(kāi)發(fā)人員緊密合作
敏捷方法的一個(gè)重要原則就是擁有不同技能和背景的人能夠緊密合作。正式的會(huì )議和文檔不能達到充分交流的效果，因此他們需要一直一起工作、親密合作。所有的項目組成員都需要緊密合作：系統分析人員、項目經(jīng)理、行業(yè)專(zhuān)家、開(kāi)發(fā)人員以及
數據庫管理人員（DBA）。
開(kāi)發(fā)人員的每項工作可能都需要DBA的幫助，開(kāi)發(fā)人員和DBA需要考慮是否需要對
數據庫計劃做很大的改變。開(kāi)發(fā)人員向DBA咨詢(xún)如何應對變化：開(kāi)發(fā)人員知道需要什么新的功能，而DBA對應用中的數據有全局的觀(guān)念。
為了達到親密合作的效果，DBA必須使自己易于接近。DBA需要留出幾分鐘的時(shí)間，讓開(kāi)發(fā)人員來(lái)提問(wèn)。必須確保DBA和開(kāi)發(fā)人員坐在一起，這樣他們就很容易溝通。同時(shí)必須確保應用
設計會(huì )議是公開(kāi)的，這樣DBA可以隨時(shí)加入進(jìn)來(lái)。在很多情況下我們發(fā)現人們在DBA和應用開(kāi)發(fā)人員之間建立屏障，這些屏障必須去除，這樣進(jìn)化
數據庫設計才有可能。
3.2 每個(gè)項目組成員都有自己的
數據庫實(shí)例
進(jìn)化
設計認為人們通過(guò)嘗試來(lái)進(jìn)行學(xué)習，在編程期間開(kāi)發(fā)人員在如何實(shí)施某個(gè)特征，應用某個(gè)首選的方案之前做一些試驗，
數據庫設計也是如此。因此，每個(gè)開(kāi)發(fā)人員都有自己用來(lái)試驗的實(shí)例，而不必影響其它人，這一點(diǎn)很重要，這樣每個(gè)人都可以根據自己的需要進(jìn)行試驗。
許多DBA專(zhuān)家認為多個(gè)
數據庫是一種麻煩，不易于實(shí)際應用，但我們發(fā)現操作一百個(gè)左右的
數據庫是很容易的。當然其中很重要的是擁有便利的工具，使你像操作文件一樣操作
數據庫。
3.3 開(kāi)發(fā)人員
數據庫經(jīng)常集成到共享主
數據庫 盡管開(kāi)發(fā)人員可以在他們自己的空間頻繁試驗，但是將不同的工作定期匯合也是很重要的。應用開(kāi)發(fā)需要一個(gè)共享主
數據庫，所有的工作都匯集于此。當開(kāi)發(fā)人員開(kāi)始工作時(shí)他們從主
數據庫獲取拷貝到自己的工作空間，進(jìn)行操作和修改，然后將變化反饋進(jìn)入主
數據庫。我們的規定是每個(gè)開(kāi)發(fā)人員要每天提交匯合一次。
假設開(kāi)發(fā)人員上午10點(diǎn)開(kāi)始一項開(kāi)發(fā)任務(wù)，這項任務(wù)的一部分是改變
數據庫計劃。如果這種改變很簡(jiǎn)單，如增加一個(gè)字段，他就可以自己決定。通過(guò)數據字典的幫助，開(kāi)發(fā)人員還必須確保他想增加的字段
數據庫中沒(méi)有，但是如果他與DBA討論這種可能的變化，那么工作就要簡(jiǎn)單的多。
當他準備開(kāi)始時(shí)，先從主
數據庫中獲取一份拷貝，這樣就可以自由地改變
數據庫計劃和代碼。因為他使用的是自己的
數據庫實(shí)例，所以不會(huì )影響別人。在某個(gè)時(shí)候，如下午3點(diǎn)，他很清楚需要什么樣的
數據庫變化，甚至此時(shí)他還沒(méi)有完全做完他的編碼工作。這時(shí)他找到DBA，告訴他想要的變化，這時(shí)DBA可以提出開(kāi)發(fā)人員沒(méi)有考慮到的問(wèn)題。當然大多數時(shí)候都很好，DBA同意這種變化（通過(guò)一個(gè)或多個(gè)
數據庫重構）。DBA使變化馬上發(fā)生（除非他們是破壞性的變化），這樣開(kāi)發(fā)人員可以繼續他的工作，在任何時(shí)候提交代碼，因為DBA已經(jīng)將這些變化發(fā)送給主
數據庫。
可以將這個(gè)原則看作類(lèi)似于持續集成，持續集成常用于源碼管理。實(shí)際上這就是將
數據庫看作是另一種源代碼，因為配置管理系統象控制源代碼一樣控制主
數據庫。只要我們構建成功，
數據庫和源代碼一起被送入配置管理系統，這樣我們就有兩者完整和同步的版本歷史。
對于源代碼來(lái)說(shuō)，集成中的問(wèn)題被源代碼控制系統處理。對于
數據庫來(lái)說(shuō)，要做的工作稍微多一些，所有
數據庫的變化都需要妥善處理，如自動(dòng)化
數據庫重構。此外DBA需要審視任何
數據庫變化，保證其符合整個(gè)
數據庫的計劃。為了使這項工作做的比較平穩，在集成的過(guò)程中不應該出現大的變化——因此需要DBA與開(kāi)發(fā)人員緊密合作。
我們強調經(jīng)常性的小集成，因為它比非經(jīng)常性的大集成容易得多。集成的復雜度會(huì )隨著(zhù)集成的規模呈幾何級度增加，因此做許多小的變化在實(shí)踐中更易于實(shí)現，當然這看上去與直覺(jué)相抵觸。
3.4
數據庫包含計劃和測試數據
當提到
數據庫的時(shí)候，我們并不僅僅指
數據庫計劃，而且還包括相當規模的數據。這些數據包括應用所需的標準數據，如全國所有的省份名，以及一些樣本客戶(hù)的樣本數據。
數據的作用：
(1) 易于測試
使用大量的自動(dòng)化測試可以幫助穩定應用的發(fā)展，這樣的測試在敏捷方法里是常用的方法。為了使這些測試有效進(jìn)行，很理智的方法是在一個(gè)有樣本測試數據的基礎上工作，這樣所有的測試可以在程序正式進(jìn)行之前完成。
(2) 測試
數據庫的遷移
除了測試代碼之外，樣本測試數據允許我們測試
數據庫的遷移，當改變了
數據庫的計劃后，我們還必須保證所有的計劃變更也能夠處理樣本數據。
在大多數項目中這些樣本數據是虛構的，然而在某些項目中人們使用實(shí)際數據作為例子，在這些情況下，數據從先前由自動(dòng)化數據遷移代碼的系統中提取出來(lái)。很明顯不能馬上遷移所有的數據，因為在早期迭代中
數據庫只有小部分建立起來(lái)。但是我們希望當應用和
數據庫發(fā)展時(shí)，改變遷移代碼。這樣不僅能夠盡早解決遷移問(wèn)題，也使行業(yè)專(zhuān)家易于處理這個(gè)正在開(kāi)發(fā)的系統。因為有他們熟悉的數據，所以他們會(huì )指出可能給
數據庫和應用
設計帶來(lái)問(wèn)題的地方，因此我們建議在項目的早期迭代中引入實(shí)際數據。
.5 所有的變化應該數據庫重構
重構技術(shù)就是應用所有可控技術(shù)來(lái)改變現有的代碼基礎，與此類(lèi)似我們定義了數據庫重構也給數據庫的改變提供了類(lèi)似的控制。
數據庫重構的不同之處在于它必須將三種不同的變化同時(shí)完成：
(1) 改變數據庫計劃
(2) 進(jìn)行數據遷移
(3) 改變數據庫存取代碼
于是當描述數據庫重構時(shí)，我們必須描述變化的三個(gè)方面，并確保在應用另一個(gè)重構之前完成了這三種變化。
我們必須文檔化不同的數據庫重構，因此我們還不能詳細描述他們。然而這里有幾點(diǎn)需要指出：像代碼重構一樣，數據庫重構非常微??；概念鏈一系列微小的變化，數據庫和代碼很相似；變化的三個(gè)屬性使保持小的變化更加重要。
許多數據庫重構，如增加一個(gè)字段，可以不必更新所有存取系統的代碼來(lái)完成。但是如果在使用新計劃之前并不了解它，該字段將會(huì )無(wú)用，因為新計劃不知道其變化之處。許多變化，沒(méi)有考慮整個(gè)系統計劃，我們稱(chēng)之為破壞性變化，如將一個(gè)已經(jīng)存在的空值列設置為非空。破壞性變化需要多加留心，留心的程度依賴(lài)于包含破壞性的程度。一個(gè)小破壞性的例子是將一個(gè)已經(jīng)存在的空值列設置為非空，在這種情況下你可以蒙著(zhù)頭做。
而重構將考慮數據庫中空值數據，開(kāi)發(fā)人員將更新數據庫映射代碼，因此更新不會(huì )破壞其它人的代碼；如果偶然會(huì )破壞，開(kāi)發(fā)人員將在建立和使用測試時(shí)發(fā)現問(wèn)題。
將一個(gè)經(jīng)常使用的表分成兩個(gè)是一種更復雜的破壞。在這種情況中提前讓所有人知道變化到來(lái)很重要，這樣他們可以有所準備。此外應該在一個(gè)更安全的時(shí)刻來(lái)實(shí)施變化。這里面很重要的一點(diǎn)是選擇適用于你做出的變化的過(guò)程。
3.6 自動(dòng)重構
在代碼世界中許多語(yǔ)言能夠實(shí)現自動(dòng)重構。在計劃變化和數據遷移過(guò)程中，這種自動(dòng)化對于數據庫也非常重要。因此每個(gè)數據庫重構都可以通過(guò)編寫(xiě)SQL DDL（對于計劃變化）和DML（對于數據遷移）來(lái)完成。這些變化不是通過(guò)手工實(shí)現，而是通過(guò)一些SQL語(yǔ)句來(lái)自動(dòng)實(shí)現變化。
一旦完成代碼，我們保存這些代碼文件來(lái)產(chǎn)生數據庫變化的完整的變化記錄，作為數據庫重構的結果。我們于是可以更新任何實(shí)例到最新的主數據庫，通過(guò)運行在我們拷貝主數據庫來(lái)產(chǎn)生更早的數據庫實(shí)例的變化記錄。
自動(dòng)化變化的序列化是對于持續集成和遷移產(chǎn)品數據庫的一個(gè)基本功能。
為了最后產(chǎn)品數據庫我們并不在常規迭代周期中實(shí)施變化，我們在每一個(gè)發(fā)布之間建立完整的數據庫重構變化日志。毫無(wú)疑問(wèn)，這是一個(gè)巨大的變化，我們必須離線(xiàn)實(shí)施該變化，在實(shí)際應用之前先測試遷移計劃絕對是明智之舉。迄今為止，這項技術(shù)相當管用，通過(guò)將大變化分解為小的簡(jiǎn)單的變化，我們可以對產(chǎn)品數據進(jìn)行大的變化，同時(shí)又不會(huì )給我們太多的麻煩。套用兵法中的一句話(huà)，就是“化整為零”。
除了自動(dòng)化向前的變化，我們也要考慮重構時(shí)向后的變化，如果能夠做到這樣就可以回到以前的數據庫狀態(tài)。在我們的項目中并沒(méi)有這樣做，因為沒(méi)有這個(gè)需求，但這同樣是很重要的基本原則。
3.7 自動(dòng)地更新所有開(kāi)發(fā)人員的數據庫
人們變化和更新主數據庫，但是如何發(fā)現主數據庫已經(jīng)發(fā)生變化？在傳統的持續集成有源代碼的環(huán)境中，開(kāi)發(fā)人員在提交變化之前先更新主數據庫。這樣他們就可以在提交變化給共享主數據庫之前，解決他們自己的機器上的問(wèn)題。
每次主數據庫發(fā)生改變時(shí)，我們都要更新開(kāi)發(fā)人員的數據庫。當主數據庫發(fā)生變化時(shí)，我們自動(dòng)化更新所有項目成員的數據庫。相同的重構代碼更新主數據庫上的同時(shí)，自動(dòng)更新成員數據庫。也許有人認為在開(kāi)發(fā)人員不知情的情況下，更新開(kāi)發(fā)人員數據庫會(huì )產(chǎn)生很多問(wèn)題，但在實(shí)踐中我們沒(méi)發(fā)現什么問(wèn)題。當然，這只在人們聯(lián)網(wǎng)時(shí)管用。所以當開(kāi)發(fā)人員離線(xiàn)時(shí)，必須盡快與主數據庫重新保持同步。
3.8 清晰地分離所有的數據庫獲取代碼
為了理解數據庫重構的結果，了解應用程序如何使用數據庫也非常重要。如果SQL語(yǔ)句分布在代碼基礎周?chē)?，則很難這樣去做。因此一個(gè)清晰的數據庫獲取層很重要，它用來(lái)顯示數據庫如何被使用，在哪里被使用。
清晰的數據庫層有很多好處。它減少了開(kāi)發(fā)人員操縱數據庫時(shí)需要使用SQL知識的地方，這樣使對SQL語(yǔ)句不太熟悉的開(kāi)發(fā)人員更易開(kāi)發(fā)。對于DBA來(lái)說(shuō)，給他提供了清晰的代碼，可以清楚地了解數據庫將如何使用。這也幫助準備索引、數據庫優(yōu)化，優(yōu)化SQL語(yǔ)句，使DBA更好地理解數據庫如何被使用。
4 變化法則
如同任何實(shí)踐一樣，這些原則必須根據你特殊的環(huán)境變化。沒(méi)有一成不變的項目，我們必須要應對變化。
4.1 保持多個(gè)數據庫在一個(gè)系統中
簡(jiǎn)單項目也許只需要一個(gè)主數據庫。但是復雜項目需要有多個(gè)數據庫，即數據庫系。如果在投入生產(chǎn)之前數據庫必須分支，那么我們可以創(chuàng )建新的數據庫系。數據庫系類(lèi)似于代碼的分支，需要不同測試數據集來(lái)進(jìn)行測試。
當開(kāi)發(fā)人員從主數據庫中獲取了一份拷貝，必須注冊他們在修改哪個(gè)數據庫系。當DBA更新主數據庫某個(gè)數據庫系時(shí)，同時(shí)更新了所有注冊這個(gè)數據庫系的開(kāi)發(fā)人員的數據庫。
4.2 不需要專(zhuān)職的DBA
所有這些聽(tīng)上去好像需要大量的工作，但它并不需要大量的人力資源。在最大的項目中，我們有30個(gè)開(kāi)發(fā)人員，項目組規模100人（包括質(zhì)量評價(jià)、分析人員和管理人員），我們大概有100多個(gè)不同系列的產(chǎn)品分布在各工作站上。但所有這些工作只需要一個(gè)專(zhuān)職DBA，只有兩個(gè)編程人員業(yè)余幫忙。
在小項目中甚至不需要專(zhuān)職DBA。當我們將這些技巧用于更小的項目--12人左右的小項目時(shí)，發(fā)現該項目不需要一個(gè)專(zhuān)職的DBA，與此相反，我們依靠?jì)蓚€(gè)對數據庫感興趣的開(kāi)發(fā)人員業(yè)余處理DBA任務(wù)。
這是自動(dòng)化的功勞，如果對每項任務(wù)進(jìn)行自動(dòng)化處理，就可以用更少的人來(lái)完成更多的工作。
5 輔助工具
數據庫進(jìn)化需要大量的重復性工作，我們可以開(kāi)發(fā)一些簡(jiǎn)單工具來(lái)幫助我們解決大量的重復性工作。
自動(dòng)化的最有價(jià)值的地方就是有一個(gè)通用數據庫任務(wù)簡(jiǎn)單代碼集。自動(dòng)化的任務(wù)包括：
(1) 用戶(hù)資料與現在管理員的資料一致
(2) 創(chuàng )建新用戶(hù)
(3) 復制數據庫計劃并協(xié)同修改
(4) 移動(dòng)并合成數據庫
(5) 刪除用戶(hù)
(6) 導出用戶(hù)，這樣項目組成員可以分發(fā)離線(xiàn)數據庫備份。
(7) 導入用戶(hù)，這樣項目組成員可以擁有數據庫備份，導入數據庫，創(chuàng )建新計劃。
(8) 導出基線(xiàn)，將主數據庫進(jìn)行備份，這是導出用戶(hù)的一個(gè)特例。
(9) 創(chuàng )建不同計劃的報告，以便比較。
(10) 將計劃與主計劃作比較，這樣開(kāi)發(fā)人員就可以將他們本地拷貝與主數據庫作比較
(11) 列出所有的用戶(hù)
分析人員和質(zhì)量評價(jià)人員常常會(huì )去看測試數據，并且需要改變他們，因此我們用VBA語(yǔ)句開(kāi)發(fā)一個(gè)Excel應用程序，從數據庫里面提取數據到Excel文件中，允許用戶(hù)修改這個(gè)文件，修改后又返回到數據庫中去。當然，也可以使用其他工具來(lái)瀏覽和編輯數據庫的內容，但是我們使用excel，因為很多人熟悉它。
項目組的所有成員應該很容易獲取數據庫設計的詳細內容，從而發(fā)現什么表格可以獲得，以及如何使用這些表格。我們建立了基于HTML的工具，使用servlets來(lái)查詢(xún)數據庫元數據。因此開(kāi)發(fā)人員在添加字段之前，可以先通過(guò)搜索表和字段的元數據來(lái)看一看數據庫中有沒(méi)有這個(gè)字段。我們使用Erwin建模，將數據從Erwin提取到我們的元數據表中。
6 結束語(yǔ)
當然，這并不是敏捷方法在數據庫設計中的全部應用，也不是數據庫進(jìn)化設計的全部，還有集成數據庫和24*7小時(shí)實(shí)施以及其他一些沒(méi)有解決的問(wèn)題，數據庫進(jìn)化設計還需要進(jìn)行進(jìn)一步的研究工作。
