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