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

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

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

正確完成建模

在過去的幾十年里，數據建模的努力通常集中在關系數據建?；蚩蓴U展標記語言（XML）的建模上。只要數據存儲在關系數據庫中，關系數據建模就會很好，但除此之外，它很少會有其他的用途。而且XML也不能被可靠地稱為建模語言。XML是序列化數據的規范--即定義了如何將數據寫入文件。XML為構造數據的序列化提供了一種格式，但它不是一個真正的模型。

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

無論是計算機還是人，如果不同時理解數據的語法（結構）和語義（含義），就無法理解數據。XML可以捕獲語法，但它不能天生捕獲語義。語義可以用XML格式編寫，但是這些語義必須首先在一些更正式的建模方案中被捕獲。換句話說，企業需要一個正式的本體。這種建模方案大多基于形式邏輯，通常是公共邏輯或描述邏輯。

迄今為止，最常用的語義建模語言是基于描述邏輯的網絡本體語言（OWL）。這意味著我們不僅可以正式驗證模型及其包含的數據，還可以通過對數據的推理來推斷新的事實，并且我們可以證明這些推斷的正確性。因為OWL是本體建模的事實上的標準，所以我將把剩下的內容限制在OWL上。

但是等等！所有這些都不意味著你需要將你的數據存儲為OWL。在你過于擔心如何將存儲格式強加給不情愿的開發人員之前，先聽我說完。

數據模型和數據存儲

軍事策劃者有一句格言：“業余愛好者擔心戰術，而專業人士擔心后勤。”他們試圖達到的核心思想是，如果你只是制定了一個壓倒敵人防御的戰斗計劃，那并沒有什么用處，但是，你也不能只讓你自己的部隊獲得執行計劃所需的燃料和彈藥。同樣的，我們也可以說實現者通常會擔心存儲，而架構師會擔心模型。沒有理由必須認為數據模型是應該由特定系統使用的存儲技術來決定的。一個定義良好的模型可以通過無損過程轉換成任何需要的存儲格式。

通常，我們會從存儲解決方案開始，然后回到數據格式。或者多種格式。大約20年前，當XML首次被引入時，它被譽為了通用的數據交換格式。在這種情況下，需要交換數據的各種系統可以采用它們當前的存儲模式（通常是關系數據庫），并將數據轉換成可擴展標記語言，以便與其他系統進行交換。其結果是企業和系統架構師會過度關注于XML格式，而幾乎忽略了系統的預期功能或企業的整體互操作性。

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

與其從存儲格式開始，然后確定如何為信息交換來表示它，還不如從與存儲無關的數據模型（如OWL）開始，然后將其用作生成數據庫模式和數據交換格式的基礎。這不僅可以讓您專注于理解現有的數據（而不是一些開發人員想的如何將它塞進數據庫），通過從基于模型來創建的多個數據表示，可以最小化維護尾部。因為對企業數據的任何更改都只需要在主模型中手動更改，因而從該模型生成其他存儲和交換模式時也可以確保這些模式之間的一致性。

企業數據建模

如果你關注的只是企業，那么很明顯，你對數據的關注已經跨越了整個企業，現在你可能會認為對企業中的所有數據進行建模的前景是相當令人望而生畏的。但不要害怕，如果你足夠小心的話，這也可以成為一項你可以安全地委托給許多人的任務。

創建一個單一的企業數據模型通常是徒勞的。對于一個群體來說，有太多的數據需要建模，有太多相互競爭的利益集團試圖將模型推向他們喜歡的方向，并堅持認為并沒有其他方法能夠適合他們。但是使用OWL開發的本體是模塊化的，這意味著你可以集成來自不同來源的多個模型。不是創建一個覆蓋整個企業的單一模型，而是針對每個不同的利益集團（業務領域、開發團隊等）?？梢詾樗P心的數據定義自己的本體。

不幸的是，這幾乎肯定會導致數據模型的重疊，但對不同對象會有不同的建模。這個問題的解決方案是采用一個通用的上層本體，企業中的每個本體都應該從這個本體中派生出來。一個通用的上層本體不會阻止所有的互操作性問題，但是有了一個好的上層本體，它會通過阻止完全荒謬的構造來約束這些問題，比如將“位置”變成一種“事件”（不，說真的，我已經看到這種情況了）。

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

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

作者：John McDowall