① 語義信息的存儲
無論是知識庫還是服務的語義描述都需要具有良好的組織和存儲，以支持高效推理和服務檢索發現。目前對於本體的存儲方法基本有三種(李勇等，2008):
(1)純文本，如 OWL 文件。由於 XML 的信息組織和存儲方式結構復雜，而且存在冗餘等，基於其上的查詢檢索效率通常會比較低。純文本的方式適合本體比較小的時候，不適合本體大規模應用的情況。
(2)資料庫: 是一種比較好的持久化存儲方式，最大好處是便於查找，可存放大本體，查詢效率高，特別在 I/O 效率上。但是資料庫方式存在本體查詢語言到 sql 的轉換問題，需要藉助於第三方中間件或自定義實現。
(3)專門的管理工具: 比如說 OMM(Ontology Middleware Mole)支持對 RDF、OWL 的存儲管理，還提供各種介面，可以使用查詢語言對 RDF 或者 OWL 進行查詢。綜合對比這三種本體存儲方式，由於關系資料庫存儲幾十年的技術積累，以及它的海量存儲特點而成為了許多研究者的首選。
5.4.3.1 本體的關系資料庫存儲模式
由於本體模型和關系模型的差異，目前存在多種在關系模型中存儲本體的方法，其主要可以分為以下四類(陶皖等，2007; 陳光儀，2009)。
5.4.3.1.1 水平模式
該模式只在資料庫中保留一張通用表，表中列為本體中的屬性。整個本體庫中定義了多少個屬性，這張表就有多少個列，具體如圖 5.28 所示。本體中的每個實例對應該表中的一條記錄。這種存儲模式結構簡單，執行查詢操作比較方便。但是該通用表包含了大量的列，而現有的資料庫系統對一張表中列的個數都是有限制的，所以該模式無法存儲規模較大的本體。而且表中的數據過於稀疏。由於每個實例對應關系表中的一行，如果其在某些屬性列上沒有值，那麼必須將對應的屬性值設置為空，這將導致大量空欄位的出現，不僅浪費存儲空間，而且增加了索引維護的代價。另外該通用表中一個實例的屬性和屬性值只能是一對一，而實際情況往往是一對多，因此無法存儲具有這種特徵的本體。隨著應用中本體的進化，還需要時常更新通用表中的列，重新組織表結構，這將耗費極大的系統代價。
圖 5.28 水平存儲模式
5.4.3.1.2 垂直模式
垂直模式包含一張三元組表，表中的每條記錄都對應一個 RDF 三元組(主語，謂詞，賓語)，具體如圖 5.29 所示。因此這種模式下，需要將本體中的所有信息都以 RDF 三元組的形式表示出來。Protege(2002)中便是使用了這種存儲模式將本體存儲於資料庫中。這種模式設計簡單，並且結構穩定。如果本體進行了更新，只需修改表中相應的元組即可。另外，該模式通用性好，因為現有的本體模型都可以轉換為 RDF 模型表示。但是這種模式的可讀性較差，若對本體信息進行查詢，那麼設計對應的 SQL 語句比較麻煩。除此之外，由於所有信息都存放在三元組表中，導致任何一個本體信息查詢都必須遍歷整個數據表，特別是那些需要進行表連接的查詢，使得查詢效率非常低，這是這種模式最大的不足之處。
圖 5.29 垂直存儲模式
5.4.3.1.3 分解模式
該模式與水平模式和垂直模式的一個顯著的區別是它使用了若干張表，其基本思想是將資料庫進行模式分解。根據分解的對象不同，現有的採用分解模式的方法有兩種。①基於類的分解模式，即為本體中的每個類都創建一張單獨的表，表名為類名，表的列為類的屬性，具體如圖 5.30 所示。這種模式結構清晰，但是很難適應本體動態變化的情況，因為隨著本體中類或者屬性的變化，表結構都要隨著變化。②基於屬性的分解模式，即為本體中的每個屬性創建一張單獨的表，表名為屬性名，每個表都包含兩個列，分別代表RDF 三元組中的主語和賓語，具體如圖 5.31 所示。在該模式中對類的隱含實例的查詢代價很大，而且在現有的這兩種分解模式的方法中，隨著本體的變化都要不斷的創建和刪除表，而在資料庫系統中創建和刪除表的效率很低。
圖 5.30 按類分解模式
圖 5.31 按屬性分解模式
5.4.3.1.4 混合模式
該模式通常將上述幾種模式進行混合使用。例如，Pan 等(2003)提出這樣一種將基於類的分解模式與基於屬性的分解模式混合的存儲模式，即在本體中定義一個類就為該類創建一個表(創建方法類似於基於類的分解模式)，在本體中定義一個屬性就為該屬性創建一個表(創建方法類似於基於屬性的分解模式)。然而，與基於類的分解模式不同的是，該混合模式在類對應的表中不記錄相應實例的所有信息，而只記錄實例的 ID。實例在各個屬性上的取值則分別記錄在各屬性對應的表中，所以和基於屬性的分解模式類似，該模式在屬性對應的表中仍然需要兩列: 主語和賓語。對於本體類數目不多的情況下，這種模式在簡單檢索的情況下，運行得很好。但是，如果本體的類比較多，這種方式就會存在一些問題，例如: 資料庫無法容納這么多表，或者效率低下。
針對上述四種模式，陳光儀(2009)從四個方面對適用場合、查詢和更新效率、結構清晰以及易理解性、可擴展性四個方面對他們進行了綜合對比(表 5.4):
表 5.4 不同存儲模式的綜合對比
(修改自陳光儀，2009)
通過上述對本體存儲模式的闡述及之間的綜合對比發現，本體存儲模式除了應該具有盡量高的規范化程度(例如滿足第三範式或 BCNF 范圍等)，還應該滿足以下三個原則。
(1)模式結構易於理解。該原則是為了便於本體查詢的實現。如果模式結構不直觀，會給查詢語句的設計帶來困難。例如，垂直模式不滿足該要求，它將所有的信息都採用三元組的形式存儲在一張表中，不容易理解表中元組的含義，加重了本體查詢設計的負擔。
(2)模式結構穩定。即本體的變化不會引起資料庫表結構的變化。因為本體是不斷進化的，如果設計的模式結構會隨著本體的變化而變化，資料庫系統對其維護代價太大。現有的水平模式、分解模式和混合模式都不滿足該要求。
(3)查詢效率高。該原則是評價各種存儲模式的一個重要指標。因為本體中不僅包含大量的數據，而且查詢中還經常需要進行表連接。例如在現有的垂直模式和基於屬性的分解模式中，那些涉及表連接的查詢效率非常低。
目前在基於資料庫的本體存儲的實踐上，一些學者開展了相關的研究工作:
燕雲鵬(2007)和陳光儀(2009)提出了類似的針對於針對 OWL 的本體資料庫的混合本體存儲模式(圖 5.32，5.33)。可以看出這種模式是以基於屬性的分解模式與垂直模式的混合體，具有較好的擴展性。但是存在的問題是效率不夠高，所有的類存儲在一個表中，所有的實例也存儲在一個表中，這種方式的檢索效率比較低。另外存儲實例的表(Instance，Proterty，Value)中欄位 Value 必須存儲許多種不同類型的數值，比如有的是文本型，而有的卻是數值型，使得數據不夠清晰。此外，在針對幾何體這種復雜的地理對象，這種欄位就比較難以存儲。
圖 5.32 本體的資料庫混合存儲模式(據燕雲鵬，2007)
ebRIM(ebXML Registry Information Model)是一個主流的信息注冊模型，已成為事實上的標准，得到了 OGC 等支持。OGC 已經實現了基於 ebRIM 的目錄服務，並推薦其作為目錄服務的實現規范。但是目前基於 ebRIM 的目錄服務只支持普通的基於關鍵字的檢索。為此，一些學者已經開始研究如何擴展 ebRIM 實現對語義信息特別是 OWL 的注冊。Dogac 等(2004)提出了如圖 5.34 所示的一種通過將 XML 形式存儲的 OWL 文件轉換為以資料庫形式存儲，使得查詢檢索更加快速，管理維護也更加方便。為了能在 ebRIM 存儲復雜的地理空間信息對象，一些學者開展了基於 ebRIM 的地理擴展方面的研究工作。樂鵬(2007)在其論文中提出了兩種擴展方式: ① 從類 「ExtrinsicObject」 派生了「CSWExtrinsicObject」來描述那些不是 ebRIM 自身定義的元數據對象。比如類 「Dataset」繼承了 「CSWExtrinsicObject」來描述空間數據集。②對 ebRIM 已有的類別增加 「Slot」。每一個從 「RegistryObject」繼承下來的類均允許添加 「Slot」。ebRIM 中的 「Service」類可以用來描述空間服務，但是已有的屬性不足以描述空間網路服務。因此，通過添加「Slot」到 「Service」類中以定義從 ISO 19119 派生的屬性。如圖 5.35 所示為經擴展後的ebRIM 高層模型圖，其中 灰 色 填 充 的 矩 形 框表示 擴 展 的對 象 類。該 模 式 與 前 面 燕 雲 鵬(2007)和陳光儀(2009)提出的模式相比，本質上差別不大，也是以基於屬性的分解模式與垂直模式的混合體，只不過是基於標準的 ebRIM 注冊模型，並且將其中的分類系統相關的類單獨以兩張表存儲。該模式也具有很好的擴展性，也存在同樣的一些問題。
圖 5.33 本體的資料庫混合存儲模式(據陳光儀，2009)
海洋信息網格技術與應用
續表
5.34 OWL 元素到 ebRIM 元素的映射(Dogac et al.，2004)
5.4.3.2 基於多分解策略的混合存儲模式實現
對知識庫以及服務語義注冊信息的存儲的實現上，本書在現有的研究成果的基礎上，結合本體組織構成及特點等實際需求，提出了一種基於多分解策略的混合關系資料庫存儲模式。
該方法的指導思想是: 先按類對其中的數據專題、數據模式、處理模型等進行類的分解，然後結合屬性的特性進行基於屬性的分解。其中基於類的分解中，可能粒度的大小不一，可能是一個類或者具有相關或相似的一些類劃分為一張表存儲; 而基於屬性的剖分，也並不是所有具有該屬性的類以一個表存儲，而可能是只針對一個類也單獨組織為一張表，其具體思路如下:
圖 5.35 經擴展的 ebRIM 高層模型圖(據樂鵬，2007)
(1)類的分解: 因為本研究的存儲模型不是為了實現一個通用的本體存儲模型，而是為了實現一個服務於海洋信息服務領域的本體存儲模型。海洋信息服務領域必然會牽涉到一些對象，比如對服務、模型、參數等對象，並且對這些對象的認識也基本上確定(也就是說這些對象類所具有的屬性及之間的關系基本明確)，所以沒必要像上面幾種實現方案那樣因為不能預知都有哪些類，各類都有哪些屬性而將所有的實例的組織按垂直方式進行存儲，也沒有必要有一些表(比如獨立的屬性表，屬性的作用域和值域表等); 而有必要針對海洋信息服務領域內的這些類的信息內容獨立出一些表: 對於海洋專題，地理名實體、處理模型、數據模式等海洋信息檢索發現中常用的對象，則有必要進行分開存儲，否則必然使得結構不清晰，且檢索查詢效率低。
(2)對於專題、空間形態以及模型功效等只是簡單的分類系統，所具有的屬性少，而且今後存在派生新的種類的可能，因此必須具備一定的擴展性。針對這類數據。它們的存儲方式是(ClassID，ParentClassID，ClassType)，其中 ClassType 標注本體類是屬於專題(比如 「海流」)或者其他。
(3)對於取值不唯一的屬性，且大部分類或實例都具有的屬性，則採用基於屬性的分解模式。比如對於別名屬性(hasAliasName)，有可能一個類實例具有多個別名，這種情況下，則採取基於屬性的組織方式。該表的形式是:(OntologyID，AliasName)，其中OntologyID 可以是本體類的 ID，也可以是本體實例的 ID，還可以是本體屬性的 ID，因為類、實例和屬性都可以有別名。
(4)對於復雜的屬性，採取大二進制存儲的方式。比如對於地名實例的空間覆蓋范圍，則不考慮其實際內部是包含多少個組成部分，統一按一個 shape 存儲在資料庫中。當然這里藉助了 ArcGIS 的 GDB 的 FeatureClass 矢量數據模型，並對於不同空間形態的則採用了多張表(點狀地名類、線狀地名類、面狀地名類)，其組織方式是(GeoNameObjec-tID，shape)。同樣，對於模型本體中的內部流程本體，也採用了大二進制方式存儲，將整個流程 XML 描述文件，作為一個整體存放於欄位中，其大體組織方式為(ModelID，FlowXML)。
(5)本研究採用 ArcGIS 的 GeoDatabase 作為存儲模型。本體類(ontClass)的存儲結構如圖 5.36 所示，資料庫的總體組織結構如圖 5.37 所示。
圖 5.36 本體類(onClass)的存儲結構
② 資料庫技術知識數據結構的演算法
資料庫技術知識數據結構的演算法
對於將要參加計算機等級考試的考生來說，計算機等級考試的知識點輔導是非常重要的復習資料。以下是我收集的資料庫技術知識數據結構的演算法，希望大家認真閱讀!
1、數據：數據的基本單位是數據元素。數據元素可由一個或多個數據項組成。數據項是數據的不可分割的最小單位
2、數據結構：數據的邏輯結構、數據的存儲結構、數據的運算
3、主要的數據存儲方式：順序存儲結構(邏輯和物理相鄰，存儲密度大)和鏈式存儲結構
順序存儲結構：
順序存儲計算公式 Li=L0+(i-1)×K 順序結構可以進行隨機存取;插人、刪除運算會引起相應節點的大量移動
鏈式存儲結構：a、指針域可以有多個，可以指向空，比比順序存儲結構的存儲密度小
b、邏輯上相鄰的節點物理上不一定相鄰。 c、插人、刪除等不需要大量移動節點
4、順序表：一般情況下，若長度為n的順序表，在任何位置插入或刪除的概率相等，元素移動的平均次數為n/2(插入)和(n-1)/2(刪除)。
5、鏈表：線性鏈表(單鏈表和雙向鏈表等等)和非線性鏈表
線性鏈表也稱為單鏈表，其每個一節點中只包含一個指針域，雙鏈表中，每個節點中設置有兩個指針域。(注意結點的插入和刪除操作)
6、棧：“後進先出”(LIFO)表。棧的應用：表達式求解、二叉樹對稱序周遊、快速排序演算法、遞歸過程的實現等
7、隊列：“先進先出”線性表。應用：樹的層次遍歷
8、串：由零個或多個字元組成的有限序列。
9、多維數組的順序存儲：
10、稀疏矩陣的存儲：下三角矩陣順序存儲
其他常見的存儲方法還有三元組法和十字鏈表法
11、廣義表：由零個或多個單元素或子表所組成的有限序列。廣義表的元素可以是子表，而子表的元素還可以是子表
12、樹型結構：非線性結構。常用的樹型結構有樹和二叉樹。
二叉樹與樹的區別：二叉樹不是樹的特殊情況，樹和二叉樹之間最主要的區別是：二叉樹的節點的子樹要區分左子樹和右子樹，即使在節點只有一棵子樹的情況下也要明確指出該子樹是左子樹還是右子樹。
13、樹(森林)與二叉樹之間的轉換(要會轉換)
14、二叉樹和樹的周遊(遍歷)
二叉樹的周遊主要有以下3種方式：前序法(NLR)、對稱序法(LNR)、後序法(LRN)
周遊樹和樹林：深度優先和按廣度優先兩種方式進行。深度優先方式又可分為按先根次序和按後根次序周遊
樹與二叉樹周遊之間的對應關系：按先根次序周遊樹正好與按前序法周遊樹對應的二叉樹等同，後根次序周遊樹正好與按對稱序法周遊對應的`二叉樹等同
按廣度優先方式就是層次次序周遊
15、二叉樹的存儲和線索
二叉樹的存儲結構：二叉樹的llink一rlink法存儲表示
線索二叉樹：在有n個節點的二叉樹的且llink - rlink法存儲表示中，必定有n+1個空指針域
16、哈夫曼樹：一類帶權路徑長度最短的樹。樹的帶權路徑長度為樹中所有葉子節點的帶權路徑長度之和WPL。
17、查找：
(1)順序查找：平均查找長度為(n +1 )/2次，時間復雜度為O(n)
(2)二分法查找：線性表節點必須按關鍵碼值排序，且線性表是以順序存儲方式存儲的。查找成功比較次數log2n，查找失敗比較次數log2n+1
(3)分塊查找：先是塊間查找，然後塊內查找。
(4)散列表(哈希表Hash)的存儲和查找：處理沖突的方法：開地址法(線性探測法)、拉鏈法等
負載因子(裝填因子)=表實際存儲的結點個數/表的最大能存儲結點個數(即表長)
二叉排序樹：每個結點左子樹的所有關鍵碼值都小於該結點關鍵碼值，右子樹所有結點關鍵碼值都大於該結點關鍵碼值。對稱周遊二叉排序樹，得到一個有序序列，時間復雜度O(log2n)
B樹和B+樹：M階樹，每個結點至多有M-1個關鍵碼，至少有M/2(取上界)-1個關鍵碼。B樹適合隨機查找，不適合順序查找。B+樹適合順序查找。
18、排序
直接插人排序、希爾排序、直接選擇排序、堆排序、起泡排序、快速排序等排序演算法要了解。
直接選擇排序、希爾排序、快速排序和堆排序是不穩定排序，其他排序為穩定排序
;③ 知識圖譜可以用python構建嗎
知識圖譜可以用python構建嗎？
答案當然是可以的！！！
那麼如何使用python構建
什麼是知識圖譜
從Google搜索，到聊天機器人、金融風控、物聯網場景、智能醫療、自適應教育、推薦系統，無一不跟知識圖譜相關。它在技術領域的熱度也在逐年上升。
互聯網的終極形態是萬物的互聯，而搜索的終極目標是對萬物的直接搜索。傳統搜索引擎依靠網頁之間的超鏈接實現網頁的搜索，而語義搜索是直接對事物進行搜索，如人物、機構、地點等。這些事物可能來自文本、圖片、視頻、音頻、IoT設備等各種信息資源。而知識圖譜和語義技術提供了關於這些事物的分類、屬性和關系的描述，使得搜索引擎可以直接對事物進行索引和搜索。
知識圖譜是由Google公司在2012年提出來的一個新的概念。從學術的角度，我們可以對知識圖譜給一個這樣的定義：「知識圖譜本質上是語義網路（Semantic Network）的知識庫」。但這有點抽象，所以換個角度，從實際應用的角度出發其實可以簡單地把知識圖譜理解成多關系圖（Multi-relational Graph）。
那什麼叫多關系圖呢？ 學過數據結構的都應該知道什麼是圖（Graph）。圖是由節點（Vertex）和邊（Edge）來構成，但這些圖通常只包含一種類型的節點和邊。但相反，多關系圖一般包含多種類型的節點和多種類型的邊。
本項目利用pandas將excel中數據抽取，以三元組形式載入到neo4j資料庫中構建相關知識圖譜。
運行環境
基於Neo4j能夠很容易構建知識圖譜，除了用neo4j自帶的cypher，也支持Python包py2neo創建節點和關系從而構建知識圖譜。本項目是基於發票信息，將發票數據中結構化數據抽象成三元組，分別創建節點和關系從而構建成知識圖譜。
具體包依賴可以參考文件requirements.txt
neo4j-driver==1.6.2numpy==1.15.3pandas==0.23.4parso==0.3.1pickleshare==0.7.5pluggy==0.8.0prompt-toolkit==1.0.15py==1.7.0py2neo==3Pygments==2.2.0pytest==3.9.3python-dateutil==2.7.5wcwidth==0.1.7wincertstore==0.2xlrd==1.1.0
將所需依賴安裝到pyton中：pip install -r requirements.txt
Pandas抽取excel數據
python中pandas非常適用於數據分析與處理，可以將excel文件轉換成dataframe格式，這種格式類似於Spark中的Dataframe結構，可以用類sql的形式對數據進行處理。
Excel數據結構如下
通過函數data_extraction和函數relation_extrantion分別抽取構建知識圖譜所需要的節點數據以及聯系數據，構建三元組。
數據提取主要採用pandas將excel數據轉換成dataframe類型
invoice_neo4j.py
建立知識圖譜所需節點和關系數據
DataToNeo4jClass.py
具體代碼請移步到GitHub上下載
詳細內容請到github下載，項目名neo4j-python-pandas-py2neo-v3
更多Python知識，請關註：Python自學網！！