在我的上一篇文章中，我認為理解一個企業(yè)的數(shù)據(jù)是指導(dǎo)一個企業(yè)的核心。但理解只是問題的一半。另一半是能夠記錄這種理解并與他人分享。
如果沒有對數(shù)據(jù)的共同理解，就談不上跨系統(tǒng)或組織的共享數(shù)據(jù)。傳統(tǒng)上，這是通過使用數(shù)據(jù)字典來完成的--這些文件旨在解釋數(shù)據(jù)結(jié)構(gòu)中每個字段的內(nèi)容和格式?？杀默F(xiàn)實是，這些文檔必須手動創(chuàng)建和更新，因此很少會進行更新。其結(jié)果是往往會出現(xiàn)過時的、無用的文檔和沮喪的架構(gòu)師和開發(fā)人員。但其實還有更好的辦法。
正確完成建模
在過去的幾十年里，數(shù)據(jù)建模的努力通常集中在關(guān)系數(shù)據(jù)建?；蚩蓴U展標記語言(XML)的建模上。只要數(shù)據(jù)存儲在關(guān)系數(shù)據(jù)庫中，關(guān)系數(shù)據(jù)建模就會很好，但除此之外，它很少會有其他的用途。而且XML也不能被可靠地稱為建模語言。XML是序列化數(shù)據(jù)的規(guī)范--即定義了如何將數(shù)據(jù)寫入文件。XML為構(gòu)造數(shù)據(jù)的序列化提供了一種格式，但它不是一個真正的模型。
我所說的“模型”指的是以數(shù)學為基礎(chǔ)的形式規(guī)范。實際上，這意味著是可以使用形式化方法進行驗證的東西。通俗地說，這意味著我們可以用數(shù)學運算來證明它是正確的，并且我們可以使驗證過程自動化。而在XML模式中捕獲數(shù)據(jù)不符合此定義下的模型。但可以肯定的是，我們可以使用軟件來驗證該XML格式是否良好，是否符合一些XML模式的文檔。但這還不足以真正地對數(shù)據(jù)進行建模。
無論是計算機還是人，如果不同時理解數(shù)據(jù)的語法(結(jié)構(gòu))和語義(含義)，就無法理解數(shù)據(jù)。XML可以捕獲語法，但它不能天生捕獲語義。語義可以用XML格式編寫，但是這些語義必須首先在一些更正式的建模方案中被捕獲。換句話說，企業(yè)需要一個正式的本體。這種建模方案大多基于形式邏輯，通常是公共邏輯或描述邏輯。
迄今為止，最常用的語義建模語言是基于描述邏輯的網(wǎng)絡(luò)本體語言(OWL)。這意味著我們不僅可以正式驗證模型及其包含的數(shù)據(jù)，還可以通過對數(shù)據(jù)的推理來推斷新的事實，并且我們可以證明這些推斷的正確性。因為OWL是本體建模的事實上的標準，所以我將把剩下的內(nèi)容限制在OWL上。
但是等等!所有這些都不意味著你需要將你的數(shù)據(jù)存儲為OWL。在你過于擔心如何將存儲格式強加給不情愿的開發(fā)人員之前，先聽我說完。
數(shù)據(jù)模型和數(shù)據(jù)存儲
軍事策劃者有一句格言：“業(yè)余愛好者擔心戰(zhàn)術(shù)，而專業(yè)人士擔心后勤。”他們試圖達到的核心思想是，如果你只是制定了一個壓倒敵人防御的戰(zhàn)斗計劃，那并沒有什么用處，但是，你也不能只讓你自己的部隊獲得執(zhí)行計劃所需的燃料和彈藥。同樣的，我們也可以說實現(xiàn)者通常會擔心存儲，而架構(gòu)師會擔心模型。沒有理由必須認為數(shù)據(jù)模型是應(yīng)該由特定系統(tǒng)使用的存儲技術(shù)來決定的。一個定義良好的模型可以通過無損過程轉(zhuǎn)換成任何需要的存儲格式。
通常，我們會從存儲解決方案開始，然后回到數(shù)據(jù)格式。或者多種格式。大約20年前，當XML首次被引入時，它被譽為了通用的數(shù)據(jù)交換格式。在這種情況下，需要交換數(shù)據(jù)的各種系統(tǒng)可以采用它們當前的存儲模式(通常是關(guān)系數(shù)據(jù)庫)，并將數(shù)據(jù)轉(zhuǎn)換成可擴展標記語言，以便與其他系統(tǒng)進行交換。其結(jié)果是企業(yè)和系統(tǒng)架構(gòu)師會過度關(guān)注于XML格式，而幾乎忽略了系統(tǒng)的預(yù)期功能或企業(yè)的整體互操作性。
這個問題在國防部尤為嚴重。該部門支持著一個名副其實的需要手工創(chuàng)建和維護的XML規(guī)范。每一個XML模式都是單獨維護的，每次更新時，都必須檢查每個相關(guān)的規(guī)范是否有潛在的影響(通常是手動的)。除此之外，還必須在XML模式中為無法更新以符合新模式的系統(tǒng)進行設(shè)置。其結(jié)果是產(chǎn)生了一個混亂的規(guī)范混合體，迫使人們必須把注意力集中在使XML協(xié)同工作上，而不是集中在XML應(yīng)該促進的任務(wù)上。
與其從存儲格式開始，然后確定如何為信息交換來表示它，還不如從與存儲無關(guān)的數(shù)據(jù)模型(如OWL)開始，然后將其用作生成數(shù)據(jù)庫模式和數(shù)據(jù)交換格式的基礎(chǔ)。這不僅可以讓您專注于理解現(xiàn)有的數(shù)據(jù)(而不是一些開發(fā)人員想的如何將它塞進數(shù)據(jù)庫)，通過從基于模型來創(chuàng)建的多個數(shù)據(jù)表示，可以最小化維護尾部。因為對企業(yè)數(shù)據(jù)的任何更改都只需要在主模型中手動更改，因而從該模型生成其他存儲和交換模式時也可以確保這些模式之間的一致性。
企業(yè)數(shù)據(jù)建模
如果你關(guān)注的只是企業(yè)，那么很明顯，你對數(shù)據(jù)的關(guān)注已經(jīng)跨越了整個企業(yè)，現(xiàn)在你可能會認為對企業(yè)中的所有數(shù)據(jù)進行建模的前景是相當令人望而生畏的。但不要害怕，如果你足夠小心的話，這也可以成為一項你可以安全地委托給許多人的任務(wù)。
創(chuàng)建一個單一的企業(yè)數(shù)據(jù)模型通常是徒勞的。對于一個群體來說，有太多的數(shù)據(jù)需要建模，有太多相互競爭的利益集團試圖將模型推向他們喜歡的方向，并堅持認為并沒有其他方法能夠適合他們。但是使用OWL開發(fā)的本體是模塊化的，這意味著你可以集成來自不同來源的多個模型。不是創(chuàng)建一個覆蓋整個企業(yè)的單一模型，而是針對每個不同的利益集團(業(yè)務(wù)領(lǐng)域、開發(fā)團隊等)?？梢詾樗P(guān)心的數(shù)據(jù)定義自己的本體。
不幸的是，這幾乎肯定會導(dǎo)致數(shù)據(jù)模型的重疊，但對不同對象會有不同的建模。這個問題的解決方案是采用一個通用的上層本體，企業(yè)中的每個本體都應(yīng)該從這個本體中派生出來。一個通用的上層本體不會阻止所有的互操作性問題，但是有了一個好的上層本體，它會通過阻止完全荒謬的構(gòu)造來約束這些問題，比如將“位置”變成一種“事件”(不，說真的，我已經(jīng)看到這種情況了)。
有許多候選的上層本體可用，它們中的大多數(shù)會試圖將所有信息分成五到六個頂級類別。但是，這些本體中的大多數(shù)都會遇到這樣的問題：有些本體所擁有的數(shù)據(jù)類并不適合他們的基本類，結(jié)果就會產(chǎn)生像將位置作為事件類型這樣的錯誤。在我的經(jīng)驗中，基本形式本體論(BFO)應(yīng)該是其中最深思熟慮的。在我使用BFO的幾年中，我?guī)缀鯖]有發(fā)現(xiàn)一個案例，其中所考慮的數(shù)據(jù)會不符合BFO的類層次結(jié)構(gòu)。
無論如何，企業(yè)架構(gòu)師必須在其特定環(huán)境中選擇一個最有效的數(shù)據(jù)建模理念。不管你選擇什么樣的數(shù)據(jù)建模理念，請記住，你有義務(wù)捕獲企業(yè)中所有數(shù)據(jù)的語法和語義。
京公網(wǎng)安備 11010502049343號