1.前言

近幾年,隨著WEB的發展,大家意識到傳統關系數據庫的不足,于是各種適用于WEB應用的非關系型數據就應運而生了.如 Cassandra, MongoDB等.也就是所謂的NOSQL數據庫.

而另一方面程序員期望的面向對象型數據庫,卻還遠不成熟,遲遲未能出現一件像樣的產品,原因各種各樣,但***的問題可能是難度太大,其實面向對象型數據庫差不多伴隨面向對象語言的發展,在很早就已經出現了.但它有太多的晦澀和局限之處,有興趣大家可以去研究一下,但是它在第二輪數據庫大戰中輸給了關系數據庫。

傳統的關系型數據庫作為數據存儲的***工具地位在短期內無法撼動。以這種數據庫為基礎發展起來的工具非常之多，歷史也非常久遠。而且關系數據庫也嘗試加入一些面向對象的特性,如音頻、圖像等新數據類型、自定義數據類型以及重載運算符等等。而Postgresql在面向對象方面更進一步,加入了如繼承等特性, 一般稱之為ORDBMS。

在RDBMS的使用者也從另一面方嘗試解決RDBMS與應用之間的一些模式映射匹配問題，近幾年出現了ORM技術，為RDBMS與面向對象語言之間減少了一些隔壑，雖然并沒有從根本上解決問題,但作了一些很好的嘗試,也獲得了廣泛的應用.但使用ORM技術,通過 Hibernate（或其他 ORM 工具）訪問RDBMS，映射問題也無法徹底解決，它們只會轉移到配置文件。而且，有以下問題。

1. 如果您想要創建一個分層良好的繼承模型，將它映射到表或一組表無疑會是失敗之舉。若用違背常規形式的方式來換取查詢的性能，就會將 DBA 與開發人員在某種程度上對立起來。面向對象中的繼承也不能過于頻繁的使用,而且不易于使用.例如你不可能讓所有的實體類繼承于同一個類。

2. 關系不作為實體出現, 實體之間的關系簡化為依賴這一種.無法為實體之間的關系建立一個分層良好的繼承模型,而有時關系很重要,如網絡故障分析中網絡對象之間的關系顯得至關重要.

與此同時,還出現了一些專用某個領域的數據庫如CMDB和GeoDatabase。像CMDB，它將實體之間的關系提高到了與實體同等的地位，并提供了一個圖查詢的方法。可惜它并沒有作為一個通用的數據庫出現,它甚至不是真的作為一個數據庫存在,而只是對CMDB用戶來說像一個數據庫而已.

我在網絡中找到一種與CMDB很類似的數據庫,名為GraphDatabase,其中的代表是Neo4j，可惜它不是免費的。而只能用于java語言。更為重要的是它們都是自已實現了一個存儲系統，不能與RDBMS共存，可實際情況中，RDBMS是主流我們根本不可能拋棄它，因此我想基于RDBMS開發一個GraphDatabase數據庫。它作為一個RMDBS的前端運行。

2.設想

我設想的GraphDatabase數據庫并不想做成***的，僅僅處理已有的RDBMS+ORM遇到的一些問題，在此我對這個數據庫做了一些設想

1. 很好的支持繼承，讓面向對象語言更方便的映射。但它并不是面向對象數據庫。

2. 將關系提升至與實體同等的地位,并提供完整的圖查詢操作。

3. 鑒于RDBMS的壟斷地位，它應該能與RDBMS良好的集成，基于它開發，也就是說本數據庫的數據模型能夠簡單地映射到RDBMS，它們之間有一個簡單的映射機制。

4. 數據庫中的信息主要通過如下3個基本的構建塊表示：

a) 條目（Item, 又叫做vertex）——從概念上來說，這類似于對象實例，擁有唯一的ID，并包含0個或多個以上的屬性組(attributeGroup)。

b) 關系(relationship,又叫做edge）——它連接了兩個Item，此外還具有方向和類型（RelationshipType），它實際上是條目（Item）的一個子類。

c) 屬性組(attributeGroup) ——它是一組 key/Value對的集合。Item與Relationship都有零到多個attributeGroup。

鑒于第3個需求，我們必須基于RDBMS 上來開發，做一個數據庫的前端,它可以嵌入在其他應用程序中，也可以獨立運行。

此外,我們還應加上一些額外的可選功能,如

1. 數據的版本信息

2. 數據的狀態管理

3. 數據的變更記錄

4. 數據的基線功能

5. 自動的全文搜索

#p#

3.需求

在做這個數據庫前我們還是先確定一下上述的第2種情況主要有那些需求.

3.1數據的定義

本數據庫是用條目(item)、關系(relationship)和屬性組(attributeGroup)三個概念來組織數據的,用戶可以按自已的需求定義這三種對象，將數據庫的數據看成一個有屬性的有向圖,如下

條目(item)就是圖中的節點, 關系(relationship)就是圖中的邊。節點和邊都具有屬性，它們用屬性組(attributeGroup)來組織。這三個對象的UML類圖如下

所有用戶自定義的條目(item)、關系(relationship)和屬性組(attributeGroup)都必須從它們繼承。

3.1.1條目(item)

一個條目(item)代表一個對象實例(如計算機,應用軟件,或其它)，

<!--[if !supportLists]-->1.       <!--[endif]-->每一個條目(item)將至少有一個唯一的Id，并充當一個Key  
<!--[if !supportLists]-->2.       <!--[endif]-->為一個條目(item)指定一個Id.后，它可能用在任何需要Id的場合  
<!--[if !supportLists]-->3.       <!--[endif]-->一個條目(item)具有0個或多個屬性組(attributeGroup)。注意它自己不能直接包含屬性。 

3.1.2關系(relationship)

一個關系(relationship)表示源條目(item)與目標條目(item)之間的連接。如一個軟件“運行(runs)”在一個操作系統上、一個操作系統“安裝(installed)”在一個計算機上、一個故障(incident)記錄“影響(affects)”一個計算機、以及一個服務使用另一個服務。關系(relationship)有下列特征

<!--[if !supportLists]-->1.         <!--[endif]-->一個關系(relationship)嚴格的連接兩個條目(item)，一個是源,一個是目標，并提供關于這個關系(relationship)的信息。  
<!--[if !supportLists]-->2.   <!--[endif]-->一個關系(relationship)是一個條目(item)的子類,并具有一個條目(item)的所有特征。如每個關系(relationship)都將有一個唯一的ID，并作為key。  
<!--[if !supportLists]-->3.         <!--[endif]-->一個關系是有方向的,但本系統并沒有為這個方向賦予什么特殊的意義。但刪除是依賴于方向的，具體請見刪除條目。   
<!--[if !supportLists]-->4.         <!--[endif]-->一個關系(relationship)具有0個或多個屬性組(attributeGroup)。注意它自己不能直接包含屬性。 

3.1.3屬性組(attributeGroup)

屬性組(attributeGroup)表示一個含有描述條目(item)或關系的屬性（注意這里的屬性是類似于數據庫表中的字段,而不是像C#語言中的屬性）的集合。屬性組(attributeGroup)有下列特征：

<!--[if !supportLists]-->1.       <!--[endif]-->一個屬性組(attributeGroup)必須關聯于一個條目(item)或關系(relationship)

<!--[if !supportLists]-->2.       <!--[endif]-->一個屬性組(attributeGroup)可能含有用于標識條目(item)或關系(relationship)的屬性，或它可能含有描述條目(item)或關系(relationship)的屬性

<!--[if !supportLists]-->3.       <!--[endif]-->不同類型的幾條屬性組(attributeGroup)可能關聯相同的條目(item)或關系(relationship)

<!--[if !supportLists]-->4.       <!--[endif]-->一個屬性組(attributeGroup)可能含有多個屬性，也有可以不含屬性，這時它充當一個標記。

一個屬性組(attributeGroup)類似于SQL視圖中的一行。它是一個屬性的投影。相同的屬性可能出現在同一個條目(item)或關系的多個屬性組(attributeGroup)中。屬性組(attributeGroup)可能沒有屬性，這種情況下它用于充當一個標記。

每個屬性組(attributeGroup)可能有下列描述屬性組(attributeGroup)自身的元屬性

<!--[if !supportLists]-->1.       <!--[endif]-->有一個Id在它所關聯的條目(item)或關系(relationship)的范圍內中唯一的，并充當key（如果條目(item)或關系(relationship)只有一個記錄時是可選地）

<!--[if !supportLists]-->2.       <!--[endif]-->記錄的日期/時間是***修改時間(可選的)

為什么提供屬性組(attributeGroup)這樣一個東西，而不是直接讓條目(item)或關系(relationship)擁有屬性呢?

因為真實世界中一個對象從不同角度來看它可能有不同的屬性,如一個計算機,從網管員的角度看,它有主機名,IP地址,MAC址址,CPU型號,MEM大小, 硬盤容量等屬性,而對財務部門的角度來看,它有訂單號,單價,購買日期,使用年限,維護人等信息,

如果我們提供屬性組(attributeGroup)這個概念后,用戶在建立模型時可以從不同角度對實物建模,一個條目(item)可以有一到多個屬性組(attributeGroup),每個屬性組(attributeGroup)針對一個或多個使用者.

3.1.4繼承

以上三個對象都像類一樣可以繼承,用戶可以用它們來對自已的領域建模,它們繼承的行為如下:

屬性組(attributeGroup)的繼承非常類似于普通的類,當一個屬性組(attributeGroup)繼承另一個屬性組(attributeGroup)時,就具有它的所有屬性，但它沒有方法。屬性不能重載。

條目(item)的繼承則表示: 當一個條目(item)繼承另一個條目(item)時,就具有它的所有屬性組(attributeGroup).此外它還有二個特殊的地方

1. 當一個條目(item)繼承另一個條目(item)時,子條目(item)中有一個屬性組(attributeGroup), 該屬性組在子條目(item)重復申明了, 或該屬性組(attributeGroup)也有一個父屬性組(attributeGroup),它的父屬性組(attributeGroup)已經存在于父條目(item)中,那么子條目(item)中的該屬性組(attributeGroup)覆蓋父條目(item)中的父屬性組(attributeGroup),

2. 當出現上述情況,同時子條目(item)的約束與父條目(item)不一致時,需要注意, 父條目(item)中的約束必須比子條目(item)中的約束更嚴格 .

這里說約束是指條目與屬性組的約束.

關系(relationship)是條目(item)的一個子類,因此它的繼承行為與條目(item)的繼承行為完全一致。

3.1.5數據類型

Integer 通過指定范圍來確定是int8, int16, int32,int64  
         Numeric 用戶指定精度  
         Money 專用于存儲貨幣類型的數據  
         String, 用戶指定長度來確是是 char, varchar還是text  
         date/timestamp/duration  
         boolean  
         ipAddress ip地址,包括ipv4和ipv6  
         physicalAddress MAC地址  
         GUID類型  
         XML 數據  
數組 

在這里我就不詳細說了,將會在概要設計中說明.

3.1.6約束

在描述約束之前我們說明一下約束更嚴格的含義: 約束a比約束b更嚴格,意味著假如一個實例滿足約束a，那么該實例一定滿足約束b，反之不一定成立。

約束分為三種：一種是針對屬性的值約束，一種是條目與屬性組的約束，一種是針對條目與條目的關系約束。

3.1.6.1屬性的值約束

它主要是針對單個值的限定,它是我從xml的限定學過來的

限定	描述
enumeration	定義可接受值的一個列表
fractionDigits	定義所允許的***的小數位數。必須大于等于0。
totalDigits	定義所允許的阿拉伯數字的精確位數。必須大于0。
length	定義所允許的字符或者列表項目的精確數目。必須大于或等于0。
maxExclusive	定義數值的上限。所允許的值必須小于此值。
maxInclusive	定義數值的上限。所允許的值必須小于或等于此值。
maxLength	定義所允許的字符或者列表項目的***數目。必須大于或等于0。
minExclusive	定義數值的下限。所允許的值必需大于此值。
minInclusive	定義數值的下限。所允許的值必需大于或等于此值。
minLength	定義所允許的字符或者列表項目的最小數目。必須大于或等于0。
pattern	定義可接受的字符的精確序列。

這些限定都與類型相關,具體不再敘述了,將會在概要設計中說明.

3.1.6.2條目與屬性組之間的約束

它主要是描述一種條目可以包含的那些屬性組可以出現的次數，可以用以下兩個限定符來修飾屬性：

    maxOccurs 表示***出現次數,默認值為1

minOccurs   表示最小出現次數,當為0時,表示可選,默認值為0

這兩個修飾屬性的值必須是一個正整數或"unbounded"，"unbounded"表示不限制。

注意，關系是條目的一個子類，因此它一樣也有此約束。

3.1.6.3條目與條目之間的關系約束

它主要是描述一種關系中源條目或目標條目可以出現的次數。出現次數可以用上面的兩個限定符。

    maxOccurs 表示***出現次數,默認值為unbounded

minOccurs   表示最小出現次數,當為0時,表示可選,默認值為0.

這兩個修飾屬性的值必須是一個正整數或"unbounded"，"unbounded"表示不限制。需要注意的是一個關系有兩個端點，需要分別對這兩個節點分別用這兩個限定符進行修飾。

3.2數據操作

3.2.1一般功能

對數據庫的操作無非就是插入,更新,刪除和查詢, 其中最重要的就是查詢了.

3.2.1.1查詢

3.2.1.1.1普通查詢

基本上與常見的ORM工具提供的查詢語言(hibernate的HQL或)沒有什么區別，一般Select 語句能支持的都支持，在這里我就不再說了。具體的設計將在概要設計中定義.

注意我們不要開發一個像HQL那樣的查詢語言，而是應該用一個SQL語句的抽象類庫來生成數據庫的原生SQL語句。

3.2.1.1.2圖查詢

這里就是與其他ORM工具提供的查詢語言(hibernate的HQL)不同的地方了，它提供了完整的圖查詢操作。

在設計一個圖查詢之前我們想象一下我們對一個圖進行查詢對有什么樣子的需求呢

1.從一點或n點出發，走指定的條件的線路，找出所有可到達的所有端點和線路

2.從一點或n點出發，走任意線路，找出所有可到達的所有端點和線路，但這些端點必須符合指定的條件。

3.從一點或n點出發，走指定的條件的線路，找出所有可到達的所有端點和線路，但這些端點必須符合指定的條件。

4.以上三個反過來，反過來查起始端點

因此我們將圖查詢設計為由三部分組成，源條目過濾表達式，目標條目過濾表達式和關系過濾表達式。其中源條目過濾表達式和目標條目過濾表達式在格式上完全相同，我們稱之為條目過濾表達式（itemFilter），而關系過濾表達式（relationshipFilter）則稍有不同，它是在條目過濾表達式的基礎上增加了一個遍歷深度參數，你可以認為關系過濾表達式（relationshipFilter）是條目過濾表達式（itemFilter）的派生類。

其中源條目過濾表達式，目標條目過濾表達式是可選的，但不能相同兩個都沒有。

條目過濾表達式(itemFilter)

一個條目(item)匹配一個itemFilter當且僅當下列規定所有都為真時：

     1.該條目符合定義在itemFilter中的約束。

     2.當它作為源條目過濾表達式時，都有一個匹配 relationshipFilter 并將此條目(item)作為源的關系。

     3.當它作為目標條目過濾表達式時，都有一個匹配 relationshipFilter 并將此條目(item)作為目標的關系。

雖然關系也是一個條目，但條目過濾表達式(itemFilter)不會返回關系實例。

關系過濾表達式（relationshipFilter）

一個關系匹配relationshipFilter當且僅當下列規定所有都為真：

1.  符合 relationshipFilter中的約束的關系。如果源條目到目標條目之間要經過多個端點時，我們可能需要增加一個針對中間端點的itemFilter。
2.  關系的源條目(item)匹配源條目過濾表達式。
3.  關系的目標條目(item)匹配目標條目過濾表達式。
4.  圖中源條目和目標條目之間的邊的數量滿足指定的條件。

沒有一個源或目標的關系，不能匹配relationshipFilter。

通過這三個部分的組合，基本上可以達到上面提到的要求了，便幾點需要注意：

1.一個圖中可能會有一個環，用戶無需關心，實現本文的實現應該自己處理

2.因為圖查詢其實是一個遞歸操作，因此需要對遞歸的深度進行限制。

3.一個端點可能會有多個到達另一個端點的路徑，只要這些路徑符合relationshipFilter，那么它們就應該出現在結果中。

3.2.1.2插入

屬性組的插入, 可以將它當作表一樣,基本上與常見的Insert支持的都支持，在這里我就不再說了。但需要注意滿足條目與屬性組的約束。

條目的插入，它有點特殊，因為有條目與屬性組的約束和條目與條目的關系約束，因此你必須一次性地將條目和條目的必選屬性組以及條目與其它條目的必選關系一起建起來，否則無法創建成功。可能還要一同創建必要的子條目。

關系的插入，它也有點特殊，因為有條目與屬性組的約束，因此一次性的將關系與它的必選屬性組一起建起來，否則無法創建成功。

3.2.1.3刪除

這個就是與一般的數據庫相差甚遠，因此重點說明一下。

3.2.1.3.1刪除屬性組

基本上與常見的ORM工具提供的刪除沒有什么區別，一般Delete 語句能支持的都支持，在這里我就不再說了。當然刪除它不能違反條目與屬性組的約束。

3.2.1.3.2刪除條目

刪除一個條目時必須同時刪除該條目的所有屬性組，但在刪除它之前，需要同時刪除與它相連的關系。但刪除關系時需要滿足下面的條件：

<!--[if !supportLists]-->l <!--[endif]-->不能違反條目與條目之間的關系約束

在實際情況中，僅僅這樣子是不夠，你可能希望在刪除一個條目時，將其相鄰的條目刪除(相鄰是指兩者之間有一個關系存在)，但這需要清楚該條目能否安全的刪除。所以我們需要用戶來指定一下:

在定義關系時,在定義關系的源和目標時各增加一個onDelete字段,用來表示刪除這個關系時,是否連帶刪除該條目.

呵呵,這個就是數據庫的級聯刪除了.

3.2.1.3.3刪除關系

同樣，刪除一個關系時必須同時刪除該關系的所有屬性組。注意同樣地刪除時不能違反條目與條目的關系約束。

3.2.1.4更新

屬性組的更新,可以將它當作表一樣,基本上與常見的Update支持的都支持，在這里我就不再說了。

條目的更新，它有點特殊，因為它的屬性都歸類在屬性組中,自身沒有屬性，那么唯一可以更改的就是改變類型了。但改變類型需要注意，兩個類型可以擁有的屬性組是不一樣的，你可能在更改它的類型時，需要刪除和添加一些屬性組。

關系的更新，因為它是條目的子類，因此它的更新與條目的更新差不多，但它比條目多兩個屬性，即源條目和目標條目的引用。源條目是不可更改的，但目標條目的引用是可以更改的。用戶可以修改它，但要注意不能違反條目與條目的關系約束

3.2.2可選功能

3.2.2.1對象的狀態管理

一個對象在它的生命周期中可能會經過幾個階段, 而對不同的用戶來說在對象處于某些階段時他并不想看到它，如一個PC可能會分為購入待處理、試用、正式運行、停用、作廢。對財務人員來說，從它生命周期開始到結束之前都能看到。而對網絡管理的值班人員來說只希望看到處于“試用”和“正式運行”階段的PC。

針對這種情況本數據庫引入一個環境的概念，即管理員可以為系統定義幾個環境，并定義這些環境可以訪問到處于哪幾個狀態的對象，并且為用戶設置一個默認環境。用戶可以在運行中更改自己所處的環境。

3.2.2.2數據的版本管理

每一個數據我們都給它一個版本，初始值為0，以后對數據的每次變化時，都給它一個新的版本號，以便用戶進行調試或查詢。

3.2.2.3數據的變更記錄

對數據的每次變更都記錄下來，形成一個歷史記錄，以便用戶進行調試或查詢。它可以與基線管理配合使用。

3.2.2.4數據的基線管理

將數據的某個版本作為一個基線，以后每次的變更都是針對這個基線的增量。

3.2.2.5數據的全文搜索

3.3非功能性需求

3.3.1分布式的需求

本數據庫暫時對分布式方面的要求不高,或者說暫時不需要,在***個實現中不與考慮.

3.3.2數據庫事務的要求

雖然本數據庫對分布式要求不高，但對事務時要求卻很高，必須有完整ACID支持，幸運的是我們有下層的RDBMS來保證，我們只要提供封裝就可以了。

3.3.3移植的要求

這個分為兩個方面

一、對RDBMS數據庫的移植要求，暫時不要求支持多種數據庫，僅支持PostgreSQL.

二、對操作系統方面的移植要求，暫時要求支持windows和redhat。

#p#

4.設計思路

本數據庫的架構大致如下

 

<!--[if !mso]-->

整個數據庫分為兩大部分：Model generator負責將用戶創建的數據類圖生成為多個RDBMS表或視圖的創建或修改語句。而DB front-end 則負責將客戶端的請求轉化為一個或多個SQL語句。總之盡量讓RDBMS來完成工作.

那么本數據庫的對象模型如何映射到RDBMS上呢？在說明這個之前我們先來介紹一下PostgreSQL數據庫的兩個功能：

<!--[if !supportLists]-->

<!--[if !supportLists]-->    一、<!--[endif]-->表的繼承

二、遞歸查詢,或者叫公共表表達式 <!--[endif]-->（Common Table Expression，CTE）

<!--[endif]-->

現在聰明的你差不多應該明白我的想法了, 我們按數據的定義中的UML類圖中定義的那樣子在RDBMS中定義5個基本的表，其它用戶定義的派生條目(item) 、派生關系(relationship)和派生屬性組(attributeGroup)則各對應一個表，所有的這些表的繼承均與類的繼承關系完全一致。

4.1模型的映射

我將它簡化一下僅保留item、attributeGroup和relationship, 如下

<!--[endif]-->  
 
CREATE TABLE identifierObject(id INTEGER PRIMARY KEY ) ;  
CREATE TABLE itemObject ( ) INHERITS (identifierObject);  
CREATE TABLE item( ) INHERITS (itemObject);  
CREATE TABLE relationship (  
 id INTEGER PRIMARY KEY,  
 source INTEGER NOT NULL REFERENCES item (id) ON UPDATE CASCADE ON DELETE CASCADE,  
 destination INTEGER NOT NULL REFERENCES item (id) ON UPDATE CASCADE ON DELETE CASCADE,  
UNIQUE(source, destination)  
) INHERITS (itemObject);  
   
CREATE TABLE attributeGroup (  
 id INTEGER PRIMARY KEY,  
 ownerid INTEGER NOT NULL REFERENCES item (id) ON UPDATE CASCADE ON DELETE CASCADE 
) INHERITS (identifierObject);  
   
CREATE INDEX a_idx ON relationship (source);  
CREATE INDEX b_idx ON relationship (destination);   
CREATE INDEX c_idx ON attributeGroup (ownerid);  
   
-–確保它不與自己發生關系  
   
ALTER TABLE relationship ADD CHECK (source <> destination) ; 

現在模型建立好了,我們可以開始對它進行操作了.

4.1.1創建

這個不用說了吧

4.1.2刪除

刪除一個條目

DELETE FROM item WHERE id = 2;    

--因為相關的relationship和attributeGroup有CASCADE選項,與之相關的關系和屬性組會自動刪除

刪除一個關系

DELETE FROM relationship WHERE id = 3;  

刪除一個屬性組

DELETE FROM attributeGroupWHERE id = 6;  

4.1.3更新

這個不用說了吧

4.1.4查詢

呵呵,普通查詢我就不說了,我們說說圖查詢吧.

4.1.4.1簡單一級的查詢

查詢id為1的條目相鄰的條目

<!--[endif]-->  
SELECT *  
 FROM item n  
 LEFT relationship e ON n.id = e.source JOIN 
 WHERE e.id = 1; -- 查詢id為1的條目相鄰的條目 

 

4.1.4.2復雜一點的遞歸查詢

從id為1的條目出發,詢它沿關系能到達的條目,并返回路過的中間節點的個數和路徑

<!--[endif]-->  
WITH RECURSIVE transitive_closure(source, b, distance, path_string) AS 
(   
SELECT source, destination, 1 AS distance,  
         source || '.' || destination || '.' AS path_string  
   FROM relationship  
WHERE source = 1 -- source  
       UNION ALL 
  SELECT tc.source, e.destination, tc.distance + 1,  
         tc.path_string || e.destination || '.' AS path_string  
   FROM relationship AS e  
   JOIN transitive_closure AS tc ON e.source = tc.destination  
    WHERE tc.path_string NOT LIKE '%' || e.destination || '.%' 
)  
SELECT * FROM transitive_closure 

4.2討論

我對postgresql進行過測試，在這種繼承結構下，它是很低效的，一般來說你對一個父表進行查詢時，它會依次對派生表進行查詢的，當派生表太多時，它的查詢時候基本上變成了你查詢每一個表的時間總和的三分之一(這好像是依賴于查詢的并發數)。此外繼承還有一定的局限性。

因此我想既然item表中沒有用戶定義的屬性，那么父條目與子條目的屬性是相同的（有一些系統定義的屬性），那么條目(item)的繼承我們可以不用表繼承的方式實現，而是加入一個表示它的類型的字段。當你查詢指定類型的條目時，可以在where中加上一個 type = x的過濾表過式，而這個表示類型的字段的設計請參見層次型枚舉。

將對象的類型改成一個字段來表示，還有一個好處就是用戶可以更改對象的類型，而這樣子更符合面向對象的思想。

 5.后記 

呵呵，這個數據庫是我為公司設計一個CMDB原型時開始構思的，花了8天完成了本文。其間對數據庫了解從僅知道簡單的Select到了解分區、物化視圖、自定義操作符、公共表表達式（Common Table Expression，CTE）。感謝Google，讓我可以查到大量的資料。

原文標題：GraphDatabase在關系數據庫中的實現

鏈接：http://www.cnblogs.com/runner-mei/archive/2010/09/15/1826219.html

【編輯推薦】

1. MongoDB CEO談NoSQL的大數據量處理能力
2. 拋棄關系數據庫 PHP程序員應了解MongoDB的五件事
3. MongoDB，無模式文檔型數據庫簡介
4. 關系數據庫的末日是否已經來臨
5. 扔掉沉沒成本 嘗試關系數據庫替代品OODBMS