資料庫設計中的敏捷方法 (轉)[@more@]

設計中的方法:namespace prefix = o ns = "urn:schemas--com::office" />

0引言

在過去幾年中，我們將敏捷方法應用於資料庫設計中。我們總結出一些技巧，使得當應用發展時，資料庫也能夠進化，這是敏捷方法的一個重要屬性。我們的方法是透過持續整合以及自動重構，透過資料庫管理人員（a）和應用開發人員的緊密合作。這些技巧在應用開發的各個時期都有效。

1敏捷方法學

近年來，出現了一種新的開發方法學—敏捷方法學。這給資料庫設計提出了一些新的、巨大的需求。這些需求的一箇中心就是進化設計。在一個敏捷專案中，需要假定我們並不能事先確定的需求。因此在專案的初期有一個詳細設計階段的想法是不現實的。系統的設計必須隨著軟體的變化而進化。敏捷方法，尤其是極限（XP），透過一些實踐使這種進化設計成為可能。在資料庫設計採用敏捷方法，反覆迭代。

許多人會懷疑敏捷方法能否用於有大型資料庫的系統。但我們的確使用了許多敏捷和XP技巧，用於解決基於大型資料庫的專案中的進化與迭代問題。

本文將介紹一些在資料庫設計採用敏捷方法的實踐。當然，這並不是說我們已經完全解決了資料庫進化的問題，但是我們想提供一些行之有效的方法。

2積極應對變化

敏捷程式設計的一個顯著特點就是它面對變化的態度。對軟體過程的一般解釋是儘早理解需求，停止需求的變動，將這些需求作為設計的基礎，停止設計的變動，然後開始構築體系。這就是瀑布方法--基於計劃的生命週期。

這種方法透過大量的前期工作來減少變化。一旦前期工作完成，需求變化會引起很大的問題。因此當需求變化時，這樣的方法就會有很大的問題，因此需求變動是這種過程的一個很大的問題。

而敏捷程式設計卻以另外一種方式來面對變化。擁抱變化，甚至允許在專案開發的後期發生變化。儘管變化會被控制，但是這種態度會允許儘可能多的變化。變化部分來自於專案需求的不穩定，部分來自於要支援變化的商業環境來面對競爭壓力。

為了做到這樣，必須採取不同的設計態度。設計不僅僅是一個階段—-在開始建築之前就大部分完成的一個階段；設計是一個持續的過程，與編碼、測試甚至釋出相關。這是計劃設計與進化設計的不同之處。敏捷方法的一個重要貢獻是提出了在可控制方式下的進化設計。因此不是由於設計沒有預先計劃好，產生了混亂。敏捷方法提供了控制進化設計和使其可行的技巧。

敏捷方法的一個重要特點就是迭代式開發，即整個專案生命週期中執行多個完整的軟體生命週期迴圈。敏捷過程在每次迭代中都會度過一個完整的生命週期。迭代可以完成最終產品的需求子集中編碼、測試以及整合程式碼。敏捷方法迭代時間較短，通常是一週到兩個月之間，而且我們更傾向於更短的迭代週期。

當使用敏捷方法時，最大的問題就是資料庫如何進行進化設計。許多人認為資料庫設計是前期計劃的工作，而在後期改變資料庫設計計劃會引起應用軟體的崩潰；在以後改變資料庫設計計劃會導致資料遷移問題。

在過去三年我們參加了一個大型的專案，其中用到了切實可行的進化設計的方法。該專案包括100人的專案組， 200多張表格，資料庫在一年半的最初開發中一直在進化，甚至在為多分發的過程中也在進化。一開始我們一個月迭代一次，過了幾個月之後變為2周迭代一次。

隨著我們將這些推廣到專案中越來越多的部分，從越來越多的案例中獲得經驗。同時，我們也從其他敏捷專案中吸收了一些經驗。

2.1限制條件

在講述實踐方法之前，必須指出我們並沒有解決所有的資料庫進化設計問題，特別是：

ü  我們是為單獨的應用設計一個應用資料庫，而不是試圖整合多個資料庫；

ü  我們沒有做到24*7的資料庫。

雖然很多人認為我們無法解決這個問題，但其實這些問題是可以解決的。當然這需要進一步的工作，光說是不能解決問題的。

3實踐

我們有關於資料庫進化設計的方法依賴於一些重要的實踐。

3.1資料庫管理人員與開發人員緊密合作

敏捷方法的一個重要原則就是擁有不同技能和背景的人能夠緊密合作。正式的會議和文件不能達到交流效果，因此他們需要一直一起工作，親密合作。所有的專案組成員都需要緊密合作：系統分析人員，專案經理，行業專家，開發人員以及資料庫管理人員（DBA）

開發人員的每項工作可能都需要DBA的幫助。開發人員和DBA需要考慮是否需要對資料庫計劃做很大的改變。開發人員向DBA諮詢如何應對變化：開發人員知道需要什麼新的功能，而DBA對應用中的資料有全域性的觀念。

為了達到親密合作的效果，DBA必須使自己易於接近。DBA需要留出幾分鐘的時間，讓開發人員來提問。必須確保DBA和開發人員坐在一起，這樣他們就很容易溝通。同時必須確保應用設計會議是公開的，這樣DBA可以隨時加入進來。在很多情況下我們發現人們在DBA和應用開發人員之間建立屏障，這些屏障必須去除，這樣進化資料庫設計才有可能。

3.2每個專案組成員都有自己的資料庫例項

進化設計認為人們透過嘗試來進行學習。在程式設計期間開發人員在如何實施某個特徵，應用某個首選的方案之前做一些試驗。資料庫設計也是如此。因此，每個開發人員都有自己用來試驗的例項，而不必影響其它人，這一點很重要。這樣每個人都可以根據自己的需要進行試驗。

許多DBA專家認為多個資料庫是一種麻煩，不易於實際應用，但我們發現操作一百個左右的資料庫是很容易的。當然其中很重要的是擁有便利的工具，使你像操作一樣運算元據庫。

3.3開發人員資料庫經常整合到共享主資料庫

儘管開發人員可以在他們自己的空間頻繁試驗，但是將不同的工作定期匯合也是很重要的。應用開發需要一個共享主資料庫，所有的工作都彙集於此。當開發人員開始工作時他們從主資料庫獲取複製到自己的工作空間，進行操作和修改，然後將變化反饋進入主資料庫。我們的規定是每個開發人員要每天提交匯合一次。

假設開發人員上午10點開始一項開發任務，這項任務的一部分是改變資料庫計劃。如果這種改變很簡單，如增加一個欄位，他就可以自己決定。透過資料字典的幫助，開發人員還必須確保他想增加的欄位資料庫中沒有。但是如果他與DBA討論這種可能的變化，那麼工作就要簡單的多。

當他準備開始時，先從主資料庫中獲取一份複製，這樣就可以自由地改變資料庫計劃和程式碼。因為他使用的是自己的資料庫例項，所以不會影響別人。在某個時候，如下午3點，他很清楚需要什麼樣的資料庫變化，甚至此時他還沒有完全做完他的編碼工作。這時他找到DBA，告訴他想要的變化。這時DBA可以提出開發人員沒有考慮到的問題。當然大多數時候都很好，DBA同意這種變化（透過一個或多個資料庫重構）。DBA使變化馬上發生（除非他們是破壞性的變化），這樣開發人員可以繼續他的工作，在任何時候提交程式碼，因為DBA已經將這些變化傳送給主資料庫。

可以將這個原則看作類似於持續整合，持續整合常用於原始碼管理。實際上這就是將資料庫看作是另一種。因為配置管理系統象控制原始碼一樣控制主資料庫。只要我們構建成功，資料庫和原始碼一起被送入配置管理系統，這樣我們就有兩者完整和同步的版本歷史。

對於原始碼來說，整合中的問題被原始碼控制系統處理。對於資料庫來說，要做的工作稍微多一些。所有資料庫的變化都需要妥善處理，如自動化資料庫重構。此外DBA需要審視任何資料庫變化，保證其符合整個資料庫的計劃。為了使這項工作做的比較平穩，在整合的過程中不應該出現大的變化--因此需要DBA與開發人員緊密合作。

我們強調經常性的小整合，因為它比非經常性的大整合容易得多。整合的複雜度會隨著整合的規模呈幾何級度增加。因此做許多小的變化在實踐中更易於實現，當然這看上去與直覺相牴觸。

3.4資料庫包含計劃和測試資料

當提到資料庫的時候，我們並不僅僅指資料庫計劃，而且還包括相當規模的資料。這些資料包括應用所需的標準資料，如全國所有的省份名，以及一些樣本客戶的樣本資料。

資料的作用：

1、  易於測試

使用大量的自動化測試可以幫助穩定應用的發展。這樣的測試在敏捷方法裡是常用的方法。為了使這些測試有效進行，很理智的方法是在一個有樣本測試資料的基礎上工作，這樣所有的測試可以在程式正式進行之前完成。

2、測試資料庫的遷移

除了測試程式碼之外，樣本測試資料允許我們測試資料庫的遷移，當改變了資料庫的計劃後，我們還必須保證所有的計劃變更也能夠處理樣本資料。

在大多數專案中這些樣本資料是虛構的。然而在某些專案中人們使用實際資料作為例子。在這些情況下，資料從先前由自動化資料遷移程式碼的系統中提取出來。很明顯不能馬上遷移所有的資料，因為在早期迭代中資料庫只有小部分建立起來。但是我們希望當應用和資料庫發展時，改變遷移程式碼。這樣不僅能夠儘早解決遷移問題，也使行業專家易於處理這個正在開發的系統。因為有他們熟悉的資料，所以他們會指出可能給資料庫和應用設計帶來問題的地方。因此我們建議在專案的早期迭代中引入實際資料。

3.5所有的變化應該資料庫重構

重構技術就是應用所有可控技術來改變現有的程式碼基礎。與此類似我們定義了資料庫重構也給資料庫的改變提供了類似的控制。

資料庫重構的不同之處在於它必須將三種不同的變化同時完成：

ü  改變資料庫計劃

ü  進行資料遷移

ü  改變資料庫存取程式碼

於是當描述資料庫重構時，我們必須描述變化的三個方面，並確保在應用另一個重構之前完成了這三種變化。

我們必須文件化不同的資料庫重構，因此我們還不能詳細描述他們。然而這裡有幾點需要指出：像程式碼重構一樣，資料庫重構非常微小。概念鏈一系列微小的變化，資料庫和程式碼很相似。變化的三個屬性使保持小的變化更加重要。

許多資料庫重構，如增加一個欄位，可以不必更新所有存取系統的程式碼來完成。但是如果在使用新計劃之前並不瞭解它，該欄位將會無用，因為新計劃不知道其變化之處。許多變化，沒有考慮整個系統計劃，我們稱之為破壞性變化，如將一個已經存在的空值列設定為非空。破壞性變化需要多加留心，留心的程度依賴於包含破壞性的程度。一個小破壞性的例子是將一個已經存在的空值列設定為非空，在這種情況下你可以蒙著頭做。

而重構將考慮資料庫中空值資料。開發人員將更新資料庫對映程式碼，因此更新不會破壞其它人的程式碼；如果偶然會破壞，開發人員將在建立和使用測試時發現問題。

將一個經常使用的表分成兩個是一種更復雜的破壞。在這種情況中提前讓所有人知道變化到來很重要，這樣他們可以有所準備。此外應該在一個更的時刻來實施變化。

這裡面很重要的一點是選擇適用於你做出的變化的過程。

3.6自動重構

在程式碼世界中許多語言能夠實現自動重構。在計劃變化和資料遷移過程中，這種自動化對於資料庫也非常重要。因此每個資料庫重構都可以透過編寫 DDL（對於計劃變化）和DML（對於資料遷移）來完成。這些變化不是透過手工實現，而是透過一些SQL語句來自動實現變化。

一旦完成程式碼，我們儲存這些程式碼檔案來產生資料庫變化的完整的變化記錄，作為資料庫重構的結果。我們於是可以更新任何例項到最新的主資料庫，透過執行在我們複製主資料庫來產生更早的資料庫例項的變化記錄。

自動化變化的序列化是對於持續整合和遷移產品資料庫的一個基本功能。

為了最後產品資料庫我們並不在常規迭代週期中實施變化。我們在每一個釋出之間建立完整的資料庫重構變化日誌。毫無疑問，這是一個巨大的變化，我們必須離線實施該變化。在實際應用之前先測試遷移計劃絕對是明智之舉。迄今為止，這項技術相當管用。透過將大變化分解為小的簡單的變化，我們可以對產品資料進行大的變化，同時又不會給我們太多的麻煩。套用兵法中的一句話，就是“化整為零”。

除了自動化向前的變化，我們也要考慮重構時向後的變化。如果能夠做到這樣就可以回到以前的資料庫狀態。在我們的專案中並沒有這樣做，因為沒有這個需求，但這同樣是很重要的基本原則。

3.7自動地更新所有開發人員的資料庫

人們變化和更新主資料庫，但是如何發現主資料庫已經發生變化？在傳統的持續整合有原始碼的環境中，開發人員在提交變化之前先更新主資料庫。這樣他們就可以在提交變化給共享主資料庫之前，解決他們自己的機器上的問題。

每次主資料庫發生改變時，我們都要更新開發人員的資料庫。當主資料庫發生變化時，我們自動化更新所有專案成員的資料庫。相同的重構程式碼更新主資料庫上的同時，自動更新成員資料庫。也許有人認為在開發人員不知情的情況下，更新開發人員資料庫會產生很多問題，但在實踐中我們沒發現什麼問題。當然，這隻在人們聯網時管用。所以當開發人員離線時，必須儘快與主資料庫重新保持同步。

3.8清晰地分離所有的資料庫獲取程式碼

為了理解資料庫重構的結果，瞭解應用程式如何使用資料庫也非常重要。如果SQL語句分佈在程式碼基礎周圍，則很難這樣去做。因此一個清晰的資料庫獲取層很重要，它用來顯示資料庫如何被使用，在哪裡被使用。

清晰的資料庫層有很多好處。它減少了開發人員操縱資料庫時需要使用SQL知識的地方，這樣使對SQL語句不太熟悉的開發人員更易開發。對於DBA來說，給他提供了清晰的程式碼，可以清楚地瞭解資料庫將如何使用。這也幫助準備、資料庫，最佳化SQL語句，使DBA更好地理解資料庫如何被使用。

4變化法則

如同任何實踐一樣，這些原則必須根據你特殊的環境變化。沒有一成不變的專案，我們必須要應對變化。

4.1保持多個資料庫在一個系統中

簡單專案也許只需要一個主資料庫。但是複雜專案需要有多個資料庫，即資料庫系。如果在投入生產之前資料庫必須分支，那麼我們可以建立新的資料庫系。資料庫系類似於程式碼的分支，需要不同測試資料集來進行測試。

當開發人員從主資料庫中獲取了一份複製，必須註冊他們在修改哪個資料庫系。當DBA更新主資料庫某個資料庫系時，同時更新了所有註冊這個資料庫系的開發人員的資料庫。

4.2不需要專職的DBA

所有這些聽上去好像需要大量的工作，但它並不需要大量的人力資源。在最大的專案中，我們有30個開發人員，專案組規模100人（包括質量評價、分析人員和管理人員），我們大概有100多個不同系列的產品分佈在各工作站上。但所有這些工作只需要一個專職DBA，只有兩個程式設計人員業餘幫忙。

在小專案中甚至不需要專職DBA。當我們將這些技巧用於更小的專案--12人左右的小專案時，發現該專案不需要一個專職的DBA。與此相反，我們依靠兩個對資料庫感興趣的開發人員業餘處理DBA任務。

這是自動化的功勞。如果對每項任務進行自動化處理，就可以用更少的人來完成更多的工作。

5輔助工具

資料庫進化需要大量的重複性工作，我們可以開發一些簡單工具來幫助我們解決大量的重複性工作。

自動化的最有價值的地方就是有一個通用資料庫任務簡單程式碼集。自動化的任務包括：

ü  使用者資料與現在管理員的資料一致

ü  建立新使用者

ü  複製資料庫計劃並協同修改

ü  移動併合成資料庫

ü  刪除使用者

ü  匯出使用者，這樣專案組成員可以分發離線資料庫。

ü  匯入使用者，這樣專案組成員可以擁有資料庫備份，匯入資料庫，建立新計劃。

ü  匯出基線，將主資料庫進行備份，這是匯出使用者的一個特例。

ü  建立不同計劃的報告，以便比較。

ü  將計劃與主計劃作比較，這樣開發人員就可以將他們本地複製與主資料庫作比較

ü  列出所有的使用者

分析人員和質量評價人員常常會去看測試資料，並且需要改變他們。因此我們用VBA語句開發一個應用程式，從資料庫裡面提取資料到Excel檔案中，允許使用者修改這個檔案，修改後又返回到資料庫中去。當然，也可以使用其他工具來瀏覽和編輯資料庫的內容，但是我們使用excel，因為很多人熟悉它。

專案組的所有成員應該很容易獲取資料庫設計的詳細內容，從而發現什麼表格可以獲得，以及如何使用這些表格。我們建立了基於HTML的工具，使用s來查詢資料庫後設資料。因此開發人員在新增欄位之前，可以先透過搜尋表和欄位的後設資料來看一看資料庫中有沒有這個欄位。我們使用Erwin建模，將資料從Erwin提取到我們的後設資料表中。

6結束語

當然，這並不是敏捷方法在資料庫設計中的全部應用，也不是資料庫進化設計的全部，還有整合資料庫和24*7小時實施以及其他一些沒有解決的問題，資料庫進化設計還需要進行進一步的研究工作。

更多資訊見中國軟考聯盟： 中國軟考聯盟