如何高效地進行數據建模

理解數據是控制任何企業的先決條件。但只有當這些知識可以被分享和傳播時，理解纔是有用的。有效的數據建模應該是任何企業架構師的首要關注點。

在個人上一篇文章中，我認爲理解一個企業的數據是指導一個企業的核心。但理解只是問題的一半。另外一半是可以記錄這種理解並與他人分享。

若是沒有對數據的共同理解，就談不上跨系統或組織的共享數據。傳統上，這是經過使用數據字典來完成的--這些文件旨在解釋數據結構中每一個字段的內容和格式。可悲的現實是，這些文檔必須手動建立和更新，所以不多會進行更新。其結果是每每會出現過期的、無用的文檔和沮喪的架構師和開發人員。但其實還有更好的辦法。

正確完成建模

在過去的幾十年裏，數據建模的努力一般集中在關係數據建模或可擴展標記語言(XML)的建模上。只要數據存儲在關係數據庫中，關係數據建模就會很好，但除此以外，它不多會有其餘的用途。並且XML也不能被可靠地稱爲建模語言。XML是序列化數據的規範--即定義瞭如何將數據寫入文件。XML爲構造數據的序列化提供了一種格式，但它不是一個真正的模型。

我所說的「模型」指的是以數學爲基礎的形式規範。實際上，這意味着是可使用形式化方法進行驗證的東西。通俗地說，這意味着咱們能夠用數學運算來證實它是正確的，而且咱們可使驗證過程自動化。而在XML模式中捕獲數據不符合此定義下的模型。但能夠確定的是，咱們可使用軟件來驗證該XML格式是否良好，是否符合一些XML模式的文檔。但這還不足以真正地對數據進行建模。

不管是計算機仍是人，若是不一樣時理解數據的語法(結構)和語義(含義)，就沒法理解數據。XML能夠捕獲語法，但它不能天生捕獲語義。語義能夠用XML格式編寫，可是這些語義必須首先在一些更正式的建模方案中被捕獲。換句話說，企業須要一個正式的本體。這種建模方案大多基於形式邏輯，一般是公共邏輯或描述邏輯。

迄今爲止，最經常使用的語義建模語言是基於描述邏輯的網絡本體語言(OWL)。這意味着咱們不只能夠正式驗證模型及其包含的數據，還能夠經過對數據的推理來推斷新的事實，而且咱們能夠證實這些推斷的正確性。由於OWL是本體建模的事實上的標準，因此我將把剩下的內容限制在OWL上。

可是等等!全部這些都不意味着你須要將你的數據存儲爲OWL。在你過於擔憂如何將存儲格式強加給不情願的開發人員以前，先聽我說完。

數據模型和數據存儲

軍事策劃者有一句格言：「業餘愛好者擔憂戰術，而專業人士擔憂後勤。」他們試圖達到的核心思想是，若是你只是制定了一個壓倒敵人防護的戰鬥計劃，那並無什麼用處，可是，你也不能只讓你本身的部隊得到執行計劃所需的燃料和彈藥。一樣的，咱們也能夠說實現者一般會擔憂存儲，而架構師會擔憂模型。沒有理由必須認爲數據模型是應該由特定系統使用的存儲技術來決定的。一個定義良好的模型能夠經過無損過程轉換成任何須要的存儲格式。

一般，咱們會從存儲解決方案開始，而後回到數據格式。或者多種格式。大約20年前，當XML首次被引入時，它被譽爲了通用的數據交換格式。在這種狀況下，須要交換數據的各類系統能夠採用它們當前的存儲模式(一般是關係數據庫)，並將數據轉換成可擴展標記語言，以便與其餘系統進行交換。其結果是企業和系統架構師會過分關注於XML格式，而幾乎忽略了系統的預期功能或企業的總體互操做性。

這個問題在國防部尤其嚴重。該部門支持着一個名副其實的須要手工建立和維護的XML規範。每個XML模式都是單獨維護的，每次更新時，都必須檢查每一個相關的規範是否有潛在的影響(一般是手動的)。除此以外，還必須在XML模式中爲沒法更新以符合新模式的系統進行設置。其結果是產生了一個混亂的規範混合體，迫令人們必須把注意力集中在使XML協同工做上，而不是集中在XML應該促進的任務上。

與其從存儲格式開始，而後肯定如何爲信息交換來表示它，還不如從與存儲無關的數據模型(如OWL)開始，而後將其用做生成數據庫模式和數據交換格式的基礎。這不只可讓您專一於理解現有的數據(而不是一些開發人員想的如何將它塞進數據庫)，經過從基於模型來建立的多個數據表示，能夠最小化維護尾部。由於對企業數據的任何更改都只須要在主模型中手動更改，於是從該模型生成其餘存儲和交換模式時也能夠確保這些模式之間的一致性。

企業數據建模

若是你關注的只是企業，那麼很明顯，你對數據的關注已經跨越了整個企業，如今你可能會認爲對企業中的全部數據進行建模的前景是至關使人望而生畏的。但不要懼怕，若是你足夠當心的話，這也能夠成爲一項你能夠安全地委託給許多人的任務。

建立一個單一的企業數據模型一般是徒勞的。對於一個羣體來講，有太多的數據須要建模，有太多相互競爭的利益集團試圖將模型推向他們喜歡的方向，並堅持認爲並無其餘方法可以適合他們。可是使用OWL開發的本體是模塊化的，這意味着你能夠集成來自不一樣來源的多個模型。不是建立一個覆蓋整個企業的單一模型，而是針對每一個不一樣的利益集團(業務領域、開發團隊等)。能夠爲它關心的數據定義本身的本體。

不幸的是，這幾乎確定會致使數據模型的重疊，但對不一樣對象會有不一樣的建模。這個問題的解決方案是採用一個通用的上層本體，企業中的每一個本體都應該從這個本體中派生出來。一個通用的上層本體不會阻止全部的互操做性問題，可是有了一個好的上層本體，它會經過阻止徹底荒謬的構造來約束這些問題，好比將「位置」變成一種「事件」(不，說真的，我已經看到這種狀況了)。

有許多候選的上層本體可用，它們中的大多數會試圖將全部信息分紅五到六個頂級類別。可是，這些本體中的大多數都會遇到這樣的問題：有些本體所擁有的數據類並不適合他們的基本類，結果就會產生像將位置做爲事件類型這樣的錯誤。在個人經驗中，基本形式本體論(BFO)應該是其中最深思熟慮的。在我使用BFO的幾年中，我幾乎沒有發現一個案例，其中所考慮的數據會不符合BFO的類層次結構。

不管如何，企業架構師必須在其特定環境中選擇一個最有效的數據建模理念。無論你選擇什麼樣的數據建模理念，請記住，你有義務捕獲企業中全部數據的語法和語義。