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

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

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

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

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

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

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

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

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

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

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

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