項目實施過程中的數(shù)據(jù)管理

項目實施過程中的數(shù)據(jù)管理項目實施過程中的數(shù)據(jù)管理數(shù)據(jù)管理的組織機構(gòu)的建立為了更好的進行軟件系統(tǒng)的數(shù)據(jù)管理，應(yīng)該從組織機構(gòu)角度來做考慮，建立單獨的組織機構(gòu)來管理數(shù)據(jù)相關(guān)工作，或者在實施小組里面專人總負責(zé)。軟件開發(fā)商和客戶核心的業(yè)務(wù)骨干一起制定數(shù)據(jù)規(guī)范，客戶提供符合規(guī)范的業(yè)務(wù)數(shù)據(jù)，只有符合規(guī)范的數(shù)據(jù)才能進入系統(tǒng)。數(shù)據(jù)管理的原則強調(diào)客戶和軟件開發(fā)商的2方項目組成員做到”不能有‘我以為的思想“，一旦有如此思想，很容易陷入閉門造車，項目需求很容易走樣，因為客戶d所有的客戶，也是在‘我以為'。項目組要想做到控制住需求，一定要拋開自己的設(shè)想。所以任何一個項目組成員，第一句話就告訴他，不要有”我以為“的想法。把‘我以為'變成‘客戶認為'（最好是客戶和軟件提供商一致認為），這才是最重要的。這又回到了項目管理上。我在這里實際上只是想從數(shù)據(jù)管理這個更具體的角度來闡述問題。數(shù)據(jù)入口的單一性同一數(shù)據(jù)必須一次、一處進入系統(tǒng)，保證其準確性，及時性和完整性和入口的單一性。管理控制一體化是系統(tǒng)的目的，如果一個數(shù)據(jù)在多個地方存儲，很容易造成數(shù)據(jù)的不一致。數(shù)據(jù)副本管理/數(shù)據(jù)版本管理雖然上面提到了數(shù)據(jù)存儲的單一性，但是有些時候也需要存儲副本數(shù)據(jù)。存儲這些副本數(shù)據(jù)的目的就是為了在使用數(shù)據(jù)副本的地方不受到數(shù)據(jù)源的變化的影響。例如：數(shù)據(jù)1在業(yè)務(wù)A進入系統(tǒng)，業(yè)務(wù)B使用到了數(shù)據(jù)1,但是為了避免在業(yè)務(wù)B使用了數(shù)據(jù)1后，業(yè)務(wù)A又把數(shù)據(jù)1的修改影響到業(yè)務(wù)B,那就需要業(yè)務(wù)B在使用數(shù)據(jù)1時候保存副本。比如：城市拆遷資源計劃系統(tǒng)的拆遷合同在使用房源業(yè)務(wù)錄入的房源房屋面積信息時，就使用了副本機制，在合同使用房屋面積時候，把面積信息存儲下來，當(dāng)合同構(gòu)筑完成時候，如果相應(yīng)的房屋面積信息發(fā)生了變動，就用另外的業(yè)務(wù)來處理這個數(shù)據(jù)變動的相應(yīng)處理（比如，使用房源的差價款合同來處理）。有朋友建議用配置管理系統(tǒng)，把數(shù)據(jù)版本機制引入了業(yè)務(wù)數(shù)據(jù)里面。做過J2EE的項目，都知道很多地方可以通過配置來進行管理。其實這個思想延伸到數(shù)據(jù)庫模型的設(shè)計時候，就體現(xiàn)出來了業(yè)務(wù)數(shù)據(jù)的配置管理的思想的使用。我們其實也有是用這個思想，但是主要體現(xiàn)在在基于數(shù)據(jù)表級別上用數(shù)據(jù)級別+歷史編號來識別有效的數(shù)據(jù)。1個很簡單的例子：一個員工的姓名原來是aa,后來改委bb，可以通過歷史編號找到原來的信息是bb通過數(shù)據(jù)級別識別現(xiàn)在的有效數(shù)據(jù)是aa,我們把數(shù)據(jù)版本控制更多的是采用‘?dāng)?shù)據(jù)級別'加‘歷史編號'另外還加上了一個‘生效日期'，‘截止日期'這2個時間戳另外，實際軟件系統(tǒng)的歷史業(yè)務(wù)數(shù)據(jù)進入系統(tǒng)就比較煩，可能需要使用版本管理機制來處理才行得通。建立數(shù)據(jù)等級制度軟件項目實施中業(yè)務(wù)規(guī)則經(jīng)常會陷入一個兩難的境地，如果業(yè)務(wù)規(guī)則加強，很多數(shù)據(jù)數(shù)據(jù)達不到規(guī)范化的要求，無法入機;如果放寬控制，很多垃圾數(shù)據(jù)就進入了，大家都明白一個道理，對于軟件系統(tǒng)，垃圾數(shù)據(jù)進去，肯定是垃圾數(shù)據(jù)出來，統(tǒng)計查詢結(jié)果肯定是這樣的?？梢越?shù)據(jù)的等級制度，制定數(shù)據(jù)進入系統(tǒng)的最低要求。達到最低要求才能進入系統(tǒng)，比如：業(yè)務(wù)A,需要數(shù)據(jù)al,數(shù)據(jù)a2,,數(shù)據(jù)a3,數(shù)據(jù)4。我們可以制定進入系統(tǒng)的關(guān)于業(yè)務(wù)A的條件是必須要有數(shù)據(jù)a1,a2才可以進入系統(tǒng)（也就是最低要求），如果提供的業(yè)務(wù)數(shù)據(jù)同時有數(shù)據(jù)a1,數(shù)據(jù)a2,,數(shù)據(jù)a3,那就是更高一級的數(shù)據(jù)（第二級數(shù)據(jù)），如果業(yè)務(wù)數(shù)據(jù)在滿足第二級數(shù)據(jù)的基礎(chǔ)上，提供了數(shù)據(jù)4，那就是第三級數(shù)據(jù)。如果用過J2EE平臺的同行理解起來就比較容易，這實際上就是JMS基于主題的消息管理思想用于軟件系統(tǒng)一個具體例子而已，這里不過是強調(diào)的是用于管理數(shù)據(jù)的信任等級而已。其實很多軟件項目開始制定的的數(shù)據(jù)規(guī)范，一般到后來都執(zhí)行不下去，主要是太理想化了，也許只有到系統(tǒng)真正用起來了，系統(tǒng)數(shù)據(jù)的信任等級才能上去。所以我覺得應(yīng)該在系統(tǒng)開始時候就把數(shù)據(jù)分等級，不同的等級，業(yè)務(wù)給與適當(dāng)不同的處理，這樣也便于后期的業(yè)務(wù)進行查詢統(tǒng)計分析或者數(shù)據(jù)挖掘。這種思想實際上就是將數(shù)據(jù)可以信任的程度進行分類;而一般的軟件系統(tǒng)是把數(shù)據(jù)定義為兩類，可以進入系統(tǒng)，不可以進入系統(tǒng);我在這里設(shè)想的是，從數(shù)據(jù)可以信任的角度出發(fā)，分成多種類別，使用了一個小數(shù)來描述信任程度，而不是一個二值邏輯變量來描述;這樣從建立軟件系統(tǒng)整體模型的時候，把數(shù)據(jù)信任管理納入考慮之內(nèi)在進一步作業(yè)務(wù)分析，決策支持或者數(shù)據(jù)挖掘時候是比較有好處的;當(dāng)然進一步延伸可能就需要從OLTP/OLAP混合建模來考慮，不過真要到那個高度，可能項目范圍就擴大了很多，具體怎樣操作，還要看項目具體情形。當(dāng)然，在軟件項目實際操作的時候，可能還會遇到另外一個問題很可能用戶會亂用這個數(shù)據(jù)信任程度的概念，我個人的建議是在項目實施中如果可能的話，優(yōu)先進入信任等級高的數(shù)據(jù)，然后才是信任程度低的數(shù)據(jù);當(dāng)然也可以從人員來角度作為切入點，信任等級越低的數(shù)據(jù)，進入系統(tǒng)就需要的業(yè)務(wù)更熟悉的人員來操作錄入，而且經(jīng)過的業(yè)務(wù)處理步驟就越多。一句話，數(shù)據(jù)信任程度越低，就應(yīng)該受到的審查/檢察越多。在現(xiàn)實中稍微規(guī)模大一點的軟件系統(tǒng)涉及到的組織機構(gòu)都是比較大的，有很多還可能是松散的組織管理模式。在這類組織機構(gòu)中，同樣的業(yè)務(wù)數(shù)據(jù)可能很多部門都會是數(shù)據(jù)錄入點和數(shù)據(jù)分析點，為此可以從數(shù)據(jù)采集/來源角度來描述數(shù)據(jù)本身。從當(dāng)前項目利益來說，數(shù)據(jù)來源管理方便數(shù)據(jù)查詢分類，長期來說可以建立起數(shù)據(jù)信任等級。對于數(shù)據(jù)來源的識別，一般需要有特定信息來記錄數(shù)據(jù)的來源，特別是一些大型企業(yè)當(dāng)然分支