本體資料庫

❶ 資料庫和本體構建的區別

資料庫和本體構建的區別：
1、資料庫按照數據結構來組織、存儲和管理數據的倉庫。
2、數據結構：是計算機存儲、組織數據的方式。

❷ 語義信息的存儲

無論是知識庫還是服務的語義描述都需要具有良好的組織和存儲，以支持高效推理和服務檢索發現。目前對於本體的存儲方法基本有三種(李勇等，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)的存儲結構

❸ 常用醫學中文資料庫有哪幾種，有何特點

醫學文獻常用資料庫：Pubmed
我常用很多跟遺傳病有關的資料庫，有：OMIM（人類孟德爾遺傳資料庫）、HGMD（人類基因突變資料庫）、Clinvar（NCBI臨床突變資料庫）、gnomAD（人群頻率資料庫）、dbSNP（人群頻率資料庫）、InterVar（位點致病性評判）、GeneReviews（疾病資料庫）、PharmGKB（葯物基因組資料庫）、常用預測軟體資料庫。
跟CNV分析有關的數據：DGV（基因組變異資料庫）、Decipher（拷貝數變異資料庫）、ClinGen資料庫（劑量敏感判斷資料庫）、UCSC Genome Browser（基因組瀏覽器）。
表型庫：HPO（人類本體表型庫）、CHPO
上面是我常用的資料庫，不知是不是您問的內容，當然查文獻最多還是在pubmed。

❹ 一文極速讀懂 Gene Ontology （GO）資料庫

官方：基因本體（GO）知識庫是有關基因功能的全球最大信息來源。 這些知識既是人類可讀的，也是機器可讀的，並且是生物醫學研究中大規模分子生物學和遺傳學實驗的計算分析的基礎。

在讀懂基因本體論（Gene Ontology）前，我們先看看什麼是本體論：

本體論（Ontology ）是探究世界的本原或基質的哲學理論 。

本體論通常處理的問題：存在哪些本質，如何將這些本質分組，在層次結構內關聯以及如何根據相似性和差異進行細分 。

基因本體論（Gene Ontology）包含生物學領域知識體系本質的表示形式，本體通常由一組類（或術語或概念）組成，它們之間具有關系。 基因本體論（GO）從三個方面（GO domains）描述了我們對生物學領域的了解：

理解了上述的概念，現在舉個例子，如果站在基因本體論GO的角度來解釋一個基因的話：

基因產物：細胞色素C（cytochrome c）

分子功能：氧化還原酶活性

細胞組分：線粒體基質

生物過程：氧化磷酸化

自定義同義詞類型也用於本體中。 例如，許多同義詞被指定為系統同義詞。 此類型的同義詞是術語名稱的確切同義詞。

GO以圖的形式構建，術語作為同種的節點，術語間的關系（對象屬性）作為連接。

GO圖中的節點與其他節點可以具有任意數量和類型的關系， 就像層次結構，例如，家譜或一個物種的分類法

一個節點可能與多個子節點（更特定的節點）具有連接，也可以具有多個父節點（較寬的節點）

利用關系與關系間的連接可以推斷相應的分組注釋，節點間關系的推斷，這個會在後面詳細研究：

上圖表示：A is a B，B is part of C，所以可以推斷 A is part of C

節點間總體與部分關系：

一個節點可能與一個節點有一部分關系。 下圖說明了這一點：

上圖： mitochondrion 是兩個節點的父節點：it is an organelle and it is part of the cytoplasm ； organelle 有兩個子節點: mitochondrion is an organelle, and organelle membrane is part of organelle

我們將上面的關系圖簡化表示為 箭頭導向性圖 ，這是圖中常見的關系表示：

接下我們詳細看看GO是怎樣來描述這幾種關系的：

如果我們說 A is a B ，則意味著節點A是節點B的子類型。例如，有絲分裂細胞周期是細胞周期，或者裂解酶活性是催化活性。

應該注意的是，a並不代表是實例。 從本體論上來說，一個實例是某個事物的具體示例。 例如 貓是哺乳動物，但加菲貓是貓的實例，而不是貓的亞型。 GO中的術語表示實體或現象的類別，而不是特定的表現形式（或實例）。 但是，如果我們知道貓是哺乳動物，則可以說貓的每個實例都是哺乳動物。

使用 is a 對批註進行分組是 安全的 。例如，如果將基因產物X注釋為具有酪氨酸激酶活性，並且本體論證明酪氨酸激酶活性是激酶活性的一種（類型），那麼我們可以安全地得出結論，基因產物X具有激酶活性。

利用上面得到結論，我們可以將 is a 關系和其他關系類型結合來推斷，下圖表示了可以推斷的關系：

關系的一部分用於表示整個部分的關系。 part of 只有當B一定是A的一部分時，才會在A和B之間部分關系：無論B存在於何處，它都是A的一部分，B的存在意味著A的存在。但是，考慮到A的出現，我們不能肯定地說B的存在。

使用的 part of 進行分組注釋是 安全的 。 例如，如果將基因產物X標注為位於線粒體內膜上，而本體論記錄了線粒體內膜與線粒體之間的關系的一部分，則可以安全地得出結論X位於線粒體內。

利用上面得到結論，我們可以將 part of 關系和其他關系類型結合來推斷，下圖表示了可以推斷的關系：

has part 是對關系部分的邏輯補充，它從父級的角度代表了「部分-整體」關系。

與 part of 一樣，GO關系 has part 僅在A始終將B作為一部分的情況下使用，即A必定具有B的部分。 但是，如果B存在，我們不能肯定地說A存在。 即所有A都有B部分，但是A只是B的一部分。

使用 has part 注釋進行分組是 不正確的 。 例如，我們可以在本體論中斷言受體酪氨酸激酶活性具有部分激酶活性。 然而，將所有注釋歸類到受體酪氨酸激酶活性下的激酶活性將是不正確的。

利用上面得到結論，我們可以將 has part 關系和其他關系類型結合來推斷，下圖表示了可以推斷的關系：

一種過程直接影響另一種過程或質量的表現，即前者調節後者。 調節的目標可以是另一種過程，例如調節途徑或酶促反應，或者可以是質量，例如細胞大小或pH。 與 part of 關系類似，該關系專門用於表示必定的調節：如果同時存在A和B，則B總是調節A，但是A可能不總是受B調節，即所有B都調節A; 一些A受B調節。

如果將基因產物X注釋為參與調節糖酵解的過程，則不能得出結論X參與糖酵解是 不正確的 。 但是，某些工具使用調節關系來對批註進行分組, 這可用於基因集富集, 所得的基因集包括與分組術語有因果關系的過程中涉及的基因。

利用上面得到結論，我們可以將 regulates 關系和其他關系類型結合來推斷，下圖表示了可以推斷的關系：

GO的結構可以用下圖來表示，這個圖也叫有向無環圖（Directed Acyclic Graph ，DAG）。

如上圖所示，三個GO域（細胞成分，生物學過程和分子功能）分別由一個單獨的根本體術語表示。

一個域中的所有術語都可以將其父源追溯到一個根術語，通過到本體根的中間術語可能存在許多不同的路徑。

這三個根節點是不相關的，並且沒有公共的父節點，這意味著來自不同本體的術語之間沒有任何關系。但是，GO本體之間也存在其他關系，例如，分子功能術語「細胞周期蛋白依賴性蛋白激酶活性」是生物過程「細胞周期」的一部分。GO本體間相關 http://geneontology.org/docs/ontology-relations/ 。

某些基於圖的軟體可能需要一個根節點。在這種情況下，可以將「假」術語添加為三個現有根節點的代。

GO只代表生物學的當前認知，因此隨著生物學知識的積累，它會不斷地被修訂和擴展。也就是說目前的GO術語不一定代表某個基因產物所有的功能，組分或參加的過程，只是現階段對它的認知。

每周更新一次，由GOC本體團隊與請求更新的科學家共同完成的。