本體的概念最早起源於哲學領域， 指的是對客觀存在系統的解釋和說明。這句話出現在了幾乎所有系統介紹知識圖譜和本體的材料裡。在很長一段時間裡，以為這是一句廢話，現在對這句話有了更多的體驗。
一、前言
知識圖譜的本體涉及很多具體概念，如：實體、關係、對象節點（資源）、數據節點（字面量）等。
所以向別人解釋什麼是本體時需要耗費非常多的精力，巴拉巴拉拋出一大堆概念，最後對方可能沒聽懂，或者聽懂了但是人家根本就不關注這些細節。所以針對不同的聽眾可以有完全不同的說法。
當對方是市場人員或者客戶，和對方提到”本體“兩個字，僅僅是為了說明知識圖譜構建工程需要做哪些事情。
比如：我們需要三週時間進行業務梳理和本體構建。
那麼無論如何也繞不過什麼是本體，要解釋為什麼要耗費這麼長時間去構建本體。這種時候可以說的非常粗略：“本體是一個數據模型，這個模型用以約束知識圖譜數據的組織方式”。
當時對方是技術人員或者產品人員，可以說：“本體可以理解為關係型數據庫的ER模型”。
ER模型即“Entity-relationship model”，其實本體也是這兩個概念，實體和關係。本體把名詞概念稱作一個實體，一個實體是一個節點，各個概念之間的聯繫稱作關係，一條關係是兩個相關節點之間的連線。
本體就是定義哪些名詞概念成為實體節點和定義實體間關係的模型。如果對方是個Coder，也可以說本體模型類似類圖，表達類與類之間的關係。
本體的一個實體就是一種類，本體的實例節點就是類的實例對象。本體的關係就是表達類之間的關係，當然本體的關係類型比類圖的關係類型要多的多。
所以本體設計和傳統的數據庫或者數倉設計一樣，需要強依賴於業務流程和業務需求。剛剛接觸知識圖譜和本體的時候，我曾錯誤的將本體設計和ER設計等同起來，甚至為了簡便直接將ER模型當作本體模型使用。
本篇文章將會分享相關經驗，通過舉個小例子來討論下本體設計和關係型數據庫ER圖的區別。
本體和知識圖譜的構建流程可以查看本人在本站之前的文章進行交流：
二、場景舉例
拿私募基金業務為例，有如下簡化版的數據結構。
私募基金管理人和其相關的股東、聯繫人、實際控制人、員工。根據相關規定：基金管理人的法律主體被限定為公司或合夥企業，自然人被排除在外。
基金管理人通常都會設定為公司形式，尤其是有限責任公司形式。其中股東和實際控制人可以為自然人，也可以為法人。
員工和聯繫人為自然人，一傢俬募基金管理人對應一個聯繫人和實際控制人，對應多個股東和公司員工。一個法人或自然人可以同時為股東和實際控制人，一個自然人可以同時作為一傢俬募基金管理人的員工和聯繫人。
三、本體設計
如果我們直接把ER模型轉化成本體模型，再直接依據該本體進行數據映，可以得到相應的圖譜如下。
該圖譜最大的問題在於：同一個人或者同一家公司會有多個節點，換句話說沒有做節點融合。
如上圖所示：有兩個相同的自然人節點——”趙某“，兩個相同公司節點——“北京XX科技有限公司”。
這對於知識圖譜的大部分應用場景來說是不合理的，在同一個圖譜中，同一個實例不能屬於兩種類型，不能成為兩個節點。
所以上述的知識圖譜應該如下：
為什麼同一個實例不能有不同的節點呢？從應用的角度，在更加複雜從的關係中，很難發現關鍵節點和業務關注的關係結構。
將上述關係以未作節點融合的圖譜進行展示，仍舊很難發現多個節點之間存在的關係。
根據上述描述，如果採用進行實體融合後的圖譜，則可以非常容易的發現該圖譜中存在穿刺投資、持股方和被持股方擁有相同的聯繫人等結構。
所以由以上的圖譜倒推得到一個更加合理的本體模型如下：
總結
”本體的概念最早起源於哲學領域， 指的是對客觀存在系統的解釋和說明“——這句話出現在了幾乎所有系統介紹知識圖譜和本體的材料裡。
在很長一段時間裡，本人也以為這是一句廢話。現在對這句話有了更多的體驗：
什麼是客觀世界，就是一個實例就只有一個。我作為一個自然人只有一個，所以反應在圖譜裡也只能有一個節點。但是我是作為”人“存在，還是作為“男人”存在，還是作為“員工”存在，是依賴於特定範圍的業務需要。結合知識圖譜的發展史，
知識圖譜起源於語義網絡和網絡鏈接，本體的目標史對數據標準進行定義，使得圖譜支持數據融合以及便於機器理解和展示。
本體模型的設計和其他數據模型的設計類似，沒有一個絕對正確的設計，只能說哪個模型更加合理。
從以往經驗看來：一個合理的本體模型大概要滿足以下幾點要求：
- 有效地支撐業務的分析和決策。
- 正確一致地展示數據信息。
- 擁有廣泛的適用性，易於添加新的節點類型和關係
作者：Eric ，數據產品經理。金融大數據方向，知識圖譜工程化。
本文由 @Eric_Xie 原創發佈於人人都是產品經理。未經許可，禁止轉載。
題圖來自 Unsplash，基於 CC0 協議。