數據標準化

05-02

雖然數據基本上都不是標準的，但是根據諾蘭模型信息化建設一定是要走到集成階段的，「信息孤島」的問題必須要解決，也就是要盡量讓數據變成標準的。

最早用來解決問題的方法就是API調用和業務組件調用，或者稱之為數據結構轉換，也就是程序員常說的開發介面。舉一個常見的的例子：某應用單位的人員管理系統按照員工檔案構建資料庫，員工顧某在人員管理系統中的編號是CY05038。該應用單位的OA系統按照組織機構構建資料庫，顧某的在OA系統中的編號是YU00870。OA系統要獲得顧某在人員管理系統中的的組織機構和職位，需要做介面程序將YU00870轉換成CY05038才能正確地檢索；反之，人員管理系統要獲得OA系統的數據，需要做介面程序將CY05038轉換成YU00870。這樣，2個業務系統交互數據最少要2個介面程序。如果再加上銷售系統和財務系統，4個業務系統交互數據，最少也要12個介面程序。假如有10個相互獨立的業務系統交互數據，則最少要90個介面，這應該還在人力可以承受的範圍以內，但假如有20個那麼最少就要380個介面了，30個的話就是870個。如此多的介面程序是做不完的，即使做完這些介面程序，業務系統運行起來也會效率低，並極其脆弱。所以，企圖通過做介面實現系統集成，是可望而不可及的。

ESB解決了介面代碼的生成，只需要生成訪問ESB的統一介面，但是因為數據沒有標準化，所以對不同數據的處理次數依然少不了，協調對接的工作量也少不了，此外，ESB為了兼容那麼多協議，自身的複雜度和維護難度都不小，因此，在解決「信息孤島」這個問題上與API調用和業務組件調用只是五十步笑百步的區別。

數據集成、數據融合的第一解決方案是：在數據共享的基礎上，完成數據遷移及數據同步，並在數據遷移及數據同步過程中完成數據清洗，最終將清洗後的數據集中存放到指定的地方，使之成為標準數據，供各個需求方使用。這個解決方案對應的應用場景之一：當前業務系統沒有替代品，甚至業務數據分散在多個相似系統里，並且不同業務系統里的數據有差異，而此時又需要將業務數據以標準數據提供查詢服務，這種場景在傳統行業的互聯網+中會非常常見；應用場景之二：當前業務系統就是要升級換代了，最後存放的地方就是新系統的資料庫，通常在這個時候，新系統和老系統之間的數據格式肯定不一樣，而且新系統和老系統還會並行運行一段時間；應用場景之三：大數據分析需要將分散在不同業務系統里的數據集中存放到數據倉庫里；應用場景之四：兩個系統分別開展業務，面對的是不同客戶群，但要在對方系統中分別保存自己生成的業務數據，類似於災備應用場景；應用場景五：出現業務瓶頸，需要做讀寫分離。

數據集成、數據融合的第二解決方案是：在數據標準化（這裡的標準化是指將所有數據按照最新的標準格式化後提供訪問，這樣做可以讓數據及時滿足標準的變化）的基礎上形成數據虛擬層（數據虛擬化），這樣不需要將數據在物理上集中存儲到一個地方，對各個需求方來說，數據是透明的，它們都是存儲在一個標準協議里的，這樣做可以避免因為數據重複存儲造成的資源浪費，還避免了數據訪問的延遲問題。這個解決方案對應的應用場景之一：當應用單位有幾十甚至上百個信息系統，不同信息系統之間需要相互使用對方的數據時（這是肯定的），這種應用場景和ESB要解決的問題一模一樣，同樣是只需要開發一次介面，不同的是這裡的數據是標準的（欄位是標準的、格式是標準），因此，處理方法也是標準的；應用場景二：需要開發部署新系統，為新系統供應商提供各種標準數據，避免多次協調各方商討數據如何使用；應用場景三：在數據虛擬化以後，可以作為數據遷移、數據同步和軟體開發的數據源，開發時不再需要關心數據存儲在哪兒的，應該用什麼方式讀取、寫入，為機器編程打下堅實的基礎。