基於SOA架構的企業內容管理方案的資料建模

http://hi.baidu.com/chenrui9814/blog/item/e6fc864674d1210a6a63e56e.html

http://www.builder.com.cn/2007/1215/683339.shtml

資料庫模型設計概述

 

　　在開始我們的資料建模之前，首先讓我們簡單地回顧一下資料庫模型設計的基本步驟，資料建模主要由邏輯模型設計和物理模型設計構成，其中邏輯模型設計主要完成以下三個任務：

• 　　標識邏輯實體
• 　　標識邏輯實體間關係
• 　　標識邏輯實體的屬性

　　物理模型是由邏輯模型轉化而來的，要根據具體的資料庫產品，為已經設計好的邏輯模型實體選擇合適的資料類型和長度(字串，整形)或精度(浮點數，金額型)，將其轉化為物理資料庫模型，為物理資料庫模型設計資料表空間，bufferpool，表，索引，外鍵，序列等等，最後得到資料庫建庫指令碼。

　　有了邏輯模型後，物理模型就是水到渠成的事情了，所以本文重點在邏輯建模內容，物理模型不做贅述。

　　標識邏輯實體

　　邏輯模型設計的實體標識階段，是要根據業務的分析結果，將業務對象抽象出來。

　　從前面描述的業務和 IT 要素中，我們可以分析得到邏輯實體有 :

• 　　參與人——業務人員
• 　　事件——掃描，傳輸，擷取
• 　　事物——金融單證的映像，也可以叫做資源
• 　　時間——隱含在事件要素中
• 　　地點——各業務部門

　　圖 3. 組成世界的邏輯對象

　　

　　其實上述的五大要素構成了現實世界，所以從中我們可以抽象出所需要的邏輯實體：

• 　　Event
• 　　Business Info
• 　　Resource Item
• 　　Resource Item Component
• 　　Party

　　通過上述思路，可以有效從具體業務中抽象出邏輯實體，這樣即使將來增加其他的內容儲存業務，也可以很好的對應進來，不過還需要類型配置來表明是何種業務何種資料，即再增加一個資料字典實體：

• 　　Classification

　　這樣，我們就標識出了邏輯模型的基礎實體。下面再標識實體的屬性以及實體間的關係。

　　標識邏輯實體的屬性和關係

　　EVENT

　　EVENT 代表了業務事件，其基本要素要求有時間，人員，事件類型，可以得出邏輯實體的屬性如：

　　圖 4. EVENT

　　

　　Resource Item

　　Resource Item 代表了資源項，主要內容包括資源項類型，對應的事件，序號等資訊，其實體屬性如：

　　圖 5. Resource Item

　　

　　Resource Item Component

　　Resource Item Component 代表了資源項的組件，主要內容包括資源項組件的類型，對應的事件，組件在資源項中的序號，對之進行改動的人員及時間，其實體屬性如：

　　圖 6. Resource Item Component

　　 

Business Info

 

　　Business Info 代表了商務資訊，由於金融商務資訊千差萬別，這裡無法做到用模型概括，所以這裡的 Business Info 只是定義了非常通用的業務屬性，即業務類型屬性。具體的業務可以繼承 Business Info 的屬性，在其基礎之上進行擴充和自訂。詳細擴充方式參見模型的可擴充 -BusinessInfo 的繼承。

　　將以上各個實體的屬性豐滿起來之後，再標識實體間關係，如一對多，一對一，多對多等關係。從而得出實體關聯 7:

　　圖 7. 實體關聯圖

　　

　　 7 中黃色部分是基礎實體，代表了我們的業務對象，綠色部分是主要實體間關係衍生而來的關係型實體，灰色部分是分類的定義，其中灰色部分的實體全部繼承自 Classification 實體，其繼承關係如 8 所示：

　　圖 8. 分類繼承關係圖

　　

　　 8 中的灰色實體全部為邏輯化實體，在邏輯模型轉為物理模型時將其內容合并上升到 Classification 實體中。

　　模型的可擴充性 - Business Info 的繼承

　　模型為新業務提供了擴充點，Business Info 實體是所有業務的父親，新增添的業務可以在它基礎上加以繼承， 9：

　　圖 9. Business Info 擴充

　　

　　中 XXX Business Info 為新增的某業務樣本，它的 ID 繼承自 Business Info 實體，其它部分為 XXX 業務特定的商務資訊，是擴充時根據具體業務需要自行定義的。

　　這樣就提供了一個擴充架構，可以在此架構之上任意添加新的業務實體。在添加新的業務時，應用程式主程式幾乎不需要變動，只需要添加一個新的業務處理類，主程式從 Business Info 中可以得到新業務的 ID 和業務類型 Business Type，然後將 ID 和 Business Type 交給業務處理單元處理，業務處理單元根據業務類型 Business Type 調用相應的業務處理類就可以了，如此擴充帶來的成本很低，效率卻很高。

　　模型的松耦合性 - Classification 的使用

　　模型不僅提供了良好的擴充性，還具備了與業務無關的松耦合性，這個特性是通過 Classification 實體來實現的。在 Classification 實體中，可以定義任意的業務含義，這些業務含義和那些抽象實體(如 Event，Resource Item，Resource Item Component)相結合，就可以處理各種業務情況。

　　可以把 Classification 理解為字典資料，只不過這個字典資料是需要系統自訂的，而且可以定義成任何含義，從而達到脫離具體的業務用語，實現模型與業務的鬆散耦合。

　　事務控制

　　在基於 SOA 架構的 ECM 應用中，資料交換的內容包括兩部分：

• 　　XML 格式的中繼資料
• 　　媒體檔案

　　兩者可以作為一個包傳輸，也可以分開傳輸，由於兩者在內容，用途和大小上差異很大，分開並行傳輸是一個好的選擇，這就引出了同步和事務控制的問題，這在資料模型中也是需要考慮的，但因為它已經和業務無關了，是純粹的 IT 技術問題，所以在這裡不做深入探討，下面只是簡單介紹思路和要點，有興趣的讀者可以自己嘗試完成。

　　在模型中建立 APP 的主題域，在該域中下定義兩個實體：sync list 和 transaction control。

　　sync list 用於同步中繼資料和媒體資料，當兩者成對收到後即可進行下一步處理。

　　transaction control 用於控制 DBM 與 CM 儲存時多階段提交的事務完整性，邏輯表示如：

　　圖 10. 事務控制時序圖

　　

　　從圖 10 中可以看到，事務的每一步執行都預先登記在 Transaction Control 中，即時任何一刻失敗了，例如遇到宕機，應用崩潰等，將系統重啟後，應用重新掃描 Transaction Control，即可從上次失敗處繼續處理，從而實現了事務的邏輯完整性。

　　另外，當用戶端提交資料後，由於傳輸中包括了媒體資訊，所以背景非同步傳輸是需要一些時間的，使用者可能在這個時間段內要求查詢處理狀況，從上面的設計可以看到，可以從以下地方查詢到處理情況：

• 　　資料在 Sync List 中，說明還在傳輸途中。
• 　　資料在 Transaction control 中，說明還在儲存中。

　　資料不在上述兩項中，但在資料庫中可以查到對應的記錄，說明處理已完成。

　　結束語

　　本文針對金融業的 ECM 方案，從資料建模的角度論述了如何設計資料模型，可以實現與業務的松耦合，保持良好的擴充，從而做到平台層級的設計。文中包含了典型的資料模型設計方法，和已經驗證多年的成熟的設計技巧，希望能給資料建模人員帶來協助。

　　從資料建模的角度，文章到這裡就可以結束了，但從 ECM 資料平台的角度，則還有很多工作要做，比如如果能在資料庫之上設計一層資料存取層，提供標準的 API，從而屏蔽掉資料庫和 CM 產品的差異，則就是一個強有力的中介層產品了，這就需要更多的設計與開發工作了。

查看本文來源