如何用好圖資料庫

導讀	本文指導讀者在使用圖資料庫時需要考慮的問題。你將瞭解到使用圖資料庫的益處、面對的挑戰，以及使用資料庫時需要考慮的問題。

近年來，圖資料庫有了大規模的發展，它們被應用到很多領域並參與優秀的解決方案。它們的靈活性使其更容易以傳統關係型資料庫無法做到的方式利用資料之間的關係和連線。但是，你真的知道何時使用圖資料庫嗎？在這篇文章中，我們探討了在使用圖資料庫之前需要考慮什麼，甚至在思考之後得出不使用圖資料庫的結論。

圖資料庫是一種使用圖理論作為資料模型基礎的資料庫。圖資料庫將連線性視為“一等公民”，使其比傳統的關係型資料庫更適合表示資料之間的連線。

有兩種型別的圖技術。RDF/語義網和屬性圖。雖然語義網標準已經存在了很長時間，但屬性圖已經成為主導技術，其中Cypher採用了大量的圖查詢語言。

從本質上講，屬性圖資料庫中的資料模型由以下屬性組成：節點、邊、屬性和標籤。

• 節點有屬性。
• 節點帶有一個或多個標籤。
• 邊是有方的向，連線節點以建立圖中的結構。
• 邊緣可以有屬性。

圖資料庫應用於具有相互連線的資料。幾個常見的用例包括：

• 推薦引擎
• 語義搜尋
• 反洗錢
• 欺詐檢測
• 360度客戶檢視

除了這些應用之外，對於那些不僅要管理大量資料而且需要產生業務見解的組織來說，圖資料庫已經成為推薦的解決方案。圖資料庫有望成為獲得這種洞察力的最簡單方法，因為它使我們很容易理解資料中的關係和背景。

二、圖資料庫的挑戰

儘管有這些承諾，圖資料庫並沒有征服世界。根據DB-Engines的資料，截至2022年10月，它們僅佔資料庫份額的1.8%，與實現這些承諾相去甚遠。有幾個原因可以解釋採用圖資料庫所遇到的困難。它們可以總結為以下幾點：

1、對高度關聯的資料進行建模

由於圖資料庫的高度表達性和相關的複雜性，在圖中建模資料並不容易。它類似於知識建模，也被稱為知識工程--一種需要高度專業化工程師的高階技能。這使得圖很難被普通開發者採用，設定了很高的進入門檻。

2、保持資料的連貫性

圖資料庫的另一個大問題是缺乏一個強制的模式。圖形資料庫大多將模式驗證委託給應用層，無論是隱式的還是顯式的。這使得建立複雜資料的應用變得更加困難，因為資料一致性是至關重要的。圖資料庫中缺乏明確執行的模式，這也是其難以被廣泛應用的主要原因。

3、查詢資料

審問圖也遇到了挑戰，由於（隱含的）資料模型會制約表達的路徑，因此需要對查詢進行設計，使之與隱含的資料模型相匹配。這一點非常具有挑戰性，你需要以最理想的方式對資料進行建模。此外，大多數圖資料庫缺乏重要的建模結構，如巢狀或n-ary關係，這導致了建模決策的不一致。有時可能會把關係定義為節點，有時則定義為邊。這樣一來，查詢可能就不一定能獲取到正確的資料。

三、強型別資料庫

克服上述挑戰對於幫助實現圖資料庫至關重要。這就是為什麼要開發一種新型的資料庫：強型別資料庫：TypeDB。開源的TypeDB透過提供一個更高階別的型別系統來抽象出圖資料庫的低階實現，使開發者更容易處理複雜的資料。TypeDB的型別系統基於以下的核心概念。

1、實體-關係模型

TypeDB使用實體-關係模型進行資料建模。與圖資料庫不同，這意味著可以將任何ER圖直接對映到TypeQL（TypeDB的查詢語言）中，以避免規範化的過程。這意味著在概念上認為模型是以人類熟悉的方式來建立的。

TypeDB的模型是由實體型別、關係型別和屬性型別組成，並引入了角色型別。

下面的例子顯示了TypeQL中的基本模型是如何寫的。

define

person sub entity,
owns name,
plays employment:employee;
company sub entity,
owns name,
plays employment:employer;
employment sub relation,
relates employee,
relates employer;
name sub attribute,
  value string;

在這個命名法中，方塊表示實體；鑽石表示關係；橢圓表示屬性。圖中概述了兩個實體的模型——人和公司，兩個實體都擁有名稱屬性。人在僱傭關係中扮演僱員的角色，而公司則扮演僱主的角色。

TypeDB提供了開箱即用的型別層次模型，這是圖資料庫不支援的一個特性。遵循物件導向的型別系統的原則，TypeDB確保所有型別繼承他們的超型別的行為和屬性。這使得複雜的資料結構可以重複使用，並且透過多型性使資料解釋更加豐富。

在下面的例子中，三層實體人的層次結構被建模。它的所有子型別將繼承屬性的名字和姓氏，而不需要逐一重新宣告這些。

define

person sub entity,
owns first-name,
owns last-name;
student sub person;
undergrad sub student;
postgrad sub student;
teacher sub person;
supervisor sub teacher;
    professor sub teacher;

型別層次描述了由學生和教師型別組成的實體的子型別。有兩種型別的學生，本科生和研究生，有兩種型別的教師，監督員和教授。

關係是用來描述兩個或多個事物之間關聯的。有時事物本身就是關係，這意味著對需要指向另一個關係的關係進行建模--巢狀。圖資料庫不允許對巢狀關係進行建模，因為這樣就需要讓一個二元邊指向另一個二元邊。實現這一點的唯一可能方式是透過“reification”（具體化，將關係-邊轉化為點-實體節點），也就是將一條邊轉化為一個節點，以便另一條邊可以指向它。

然而，TypeDB支援巢狀關係，使其以最自然的形式進行資料建模。在下面的例子中，婚姻型別的關係被分配給變數$mar，然後透過關係將其與一個城市進行關聯。

match

$alice isa person, has name "Alice";
$bob isa person, has name "Bob";
$mar ($alice, $bob) isa marriage;
$city isa city;
($mar, $city) isa location;

圖中，"Alice "扮演妻子的角色，而 "Bob "扮演丈夫的角色。婚姻是一個巢狀關係，因為它也在位置關係中扮演定位的角色，而城市 "倫敦 "在關係中扮演定位的角色。

在現實世界中，關係並不只是指事物之間的二元聯絡。我們經常需要同時捕捉三個或更多相互關聯的事物。如果將它們表示二元關係會導致資訊損失，這種情況常常會在圖資料庫中發生。另一方面，TypeDB可以很自然地將多個事物表示為一種關係。

在這個例子中，n-ary關係cast連線了三個不同的實體：人的實體，角色的實體和電影的實體。

match

$person isa person, has name "Leonardo";
$character isa character, has name "Jack";
$movie isa movie, has name $movie-name;
(actor: $person, character: $character, movie: $movie) isa cast;
get $movie-name;

這是n-ary關係的例子，具體來說是三元關係，關係型別是cast。關係與三個實體相關：電影 "泰坦尼克號 扮演電影中角色“傑克”的演員是"萊昂納多 "。

與圖資料庫不同，TypeDB提供了一種方法來描述資料的邏輯結構，允許TypeDB驗證程式碼是否正確插入和資料的查詢。查詢驗證超越了靜態型別檢查，包括對無意義的查詢進行邏輯驗證。透過嚴格的型別檢查錯誤，你將獲得一個可以信任的資料集。

下面的插入查詢例子中，Charlie和DataCo之間的關係將被系統拒絕，因為一個人不能和一個公司結婚（假設模式遵循真實世界一般規律）。

insert

$charlie isa person, has name "Charlie";
$dataCo isa company, has name "DataCo";
(husband: $charlie, wife: $dataCo) isa marriage; # invalid relation
commit>>
ERROR: invalid data detected during type validation

最後，TypeDB提供了一個內建的推理引擎，這使得TypeDB能夠推匯出新見解，並提供對應的解釋。另一方面，屬性圖並不提供原生的推理能力。

TypeDB的推斷是基於模式中的規則。在查詢執行期間，如果資料集中的某個邏輯形式被滿足（如規則中定義的），系統將得出新的結論。就像程式設計中的函式一樣，規則可以相互連鎖，在資料層面建立行為的抽象。

透過下面的規則，TypeDB將能夠推斷出一個城市位於一個大陸，儘管兩者之間不存在明確的關係。

define

rule transitive-location:
when {
(located: $city, locating: $country) isa location;
(located: $country, locating: $continent) isa location;
} then {
(located: $city, locating: $continent) isa location;
};

使用自動推理，TypeDB可以推斷出 "卡姆登 "區和 "英國 "之間的關係（虛線），儘管它們沒有直接聯絡。

回到我們的主題，什麼時候使用圖資料庫呢？圖是為那些依賴複雜和相互連線的資料應用而準備。正如我們所看到的，他們缺乏廣泛的應用，這也是圖資料庫失敗的原因和麵臨的挑戰。為了面對挑戰並實現圖形資料庫的最初承諾，我們建立了TypeDB。

原文來自：