當(dāng)前位置：首頁 > 编程资源 > 编程问答 >内容正文

编程问答

Neo4j【有与无】【N3】使用图进行数据建模

發(fā)布時間：2024/1/1 编程问答 25 豆豆

生活随笔收集整理的這篇文章主要介紹了 Neo4j【有与无】【N3】使用图进行数据建模小編覺得挺不錯的,現(xiàn)在分享給大家,幫大家做個參考.

1.模式與目標(biāo)(Models and Goals)

2.標(biāo)記的屬性圖模型

3.查詢圖：Cypher簡介

3.1.Cypher Philosophy

3.2.MATCH

3.3.RETURN

3.4.其他Cypher語法

4.關(guān)系和圖建模的比較

4.1.系統(tǒng)管理領(lǐng)域中的關(guān)系建模

4.2.系統(tǒng)管理域中的圖形建模

4.3.測試模型

5.跨域模型

5.1.創(chuàng)建莎士比亞圖

5.2.開始查詢

5.3.聲明要查找的信息模式

5.4.約束匹配

5.5.處理結(jié)果

5.6.查詢鏈接

5.7.常見的建模陷阱

5.7.1.電子郵件出處問題域

5.7.2.明智的第一次迭代？

5.7.3.第二次的魅力

5.7.4.不斷發(fā)展的領(lǐng)域

6.識別節(jié)點(diǎn)和關(guān)系

7.避免反模式

8.摘要

在前面的章節(jié)中，我們描述了圖數(shù)據(jù)庫與其他NOSQL存儲和傳統(tǒng)關(guān)系數(shù)據(jù)庫相比的巨大優(yōu)勢。但是選擇采用圖形數(shù)據(jù)庫后，出現(xiàn)了一個問題：如何在圖形中建模？

本章重點(diǎn)介紹圖建模。首先從標(biāo)簽化的屬性圖模型（最廣泛使用的圖數(shù)據(jù)模型）的概述開始，然后概述本書中大多數(shù)代碼示例所使用的圖查詢語言：Cypher。盡管存在幾種圖形查詢語言，但是Cypher部署最廣泛，使其成為事實(shí)上的標(biāo)準(zhǔn)。它也很容易學(xué)習(xí)和理解，特別是對于那些來自SQL背景的人。有了這些基礎(chǔ)知識之后，我們將直接研究一些圖形建模的示例。在基于系統(tǒng)管理域的第一個示例中，我們比較了關(guān)系和圖形建模技術(shù)。在第二個例子（莎士比亞文學(xué)的生產(chǎn)和消費(fèi)）中，我們使用圖來連接和查詢幾個不同的領(lǐng)域。在本章的結(jié)尾，我們介紹了使用圖形建模時的一些常見陷阱，并重點(diǎn)介紹了一些好的做法。

1.模式與目標(biāo)(Models and Goals)

在深入研究圖形建模之前，請先對模型進(jìn)行概括。 建模是受特定需求或目標(biāo)推動的抽象活動。 我們進(jìn)行建模是為了將不守法域的特定方面帶入可以對其進(jìn)行結(jié)構(gòu)化和處理的空間。世界沒有“really is,”的自然表現(xiàn)，只有許多有目的的選擇，抽象和簡化，其中一些在滿足特定目標(biāo)方面比其他更為有用。

在這方面，圖形表示形式?jīng)]有什么不同。但是，它們與許多其他數(shù)據(jù)建模技術(shù)的不同之處可能在于邏輯模型與物理模型之間的緊密聯(lián)系。關(guān)系數(shù)據(jù)管理技術(shù)要求我們偏離域的自然語言表示形式：首先通過將表示形式組合成邏輯模型，然后將其強(qiáng)制為物理模型。這些轉(zhuǎn)換在我們對世界的概念化與該模型的數(shù)據(jù)庫實(shí)例化之間引入了語義上的矛盾。使用圖形數(shù)據(jù)庫，這個差距大大縮小了。

我們已經(jīng)在圖形中進(jìn)行交流

圖形建模自然符合我們傾向于使用圓和框從域中提取細(xì)節(jié)，然后通過用箭頭和線將它們連接起來來描述這些事物之間的聯(lián)系的方式。當(dāng)今的圖形數(shù)據(jù)庫比其他任何數(shù)據(jù)庫技術(shù)都更“whiteboard friendly”。問題的典型白板視圖是圖形。我們在創(chuàng)意和分析模式下繪制的內(nèi)容與我們在數(shù)據(jù)庫內(nèi)部實(shí)現(xiàn)的數(shù)據(jù)模型緊密對應(yīng)。

在表達(dá)性方面，圖形數(shù)據(jù)庫減少了困擾關(guān)系數(shù)據(jù)庫實(shí)現(xiàn)多年的分析和實(shí)現(xiàn)之間的阻抗失配。這種圖模型特別有趣的是，它們不僅傳達(dá)了我們認(rèn)為事物之間的關(guān)系，而且還清楚地傳達(dá)了我們想問的領(lǐng)域內(nèi)的各種問題。

我們將在本章中看到，圖模型和圖查詢實(shí)際上只是同一枚硬幣的兩個方面。

2.標(biāo)記的屬性圖模型

我們在第1章中介紹了標(biāo)記的屬性圖模型?？偠灾?#xff0c;這些是其顯著的特征：

帶標(biāo)簽的屬性圖由節(jié)點(diǎn)，關(guān)系，屬性和標(biāo)簽組成。
節(jié)點(diǎn)包含屬性。將節(jié)點(diǎn)視為以任意鍵值對形式存儲屬性的文檔。在Neo4j中，鍵是字符串，值是Java字符串和原始數(shù)據(jù)類型，以及這些類型的數(shù)組。
節(jié)點(diǎn)可以用一個或多個標(biāo)簽標(biāo)記。標(biāo)簽將節(jié)點(diǎn)分組在一起，并指示它們在數(shù)據(jù)集中扮演的角色。
關(guān)系連接節(jié)點(diǎn)并構(gòu)造圖。關(guān)系始終具有一個方向，一個名稱以及一個開始節(jié)點(diǎn)和一個結(jié)束節(jié)點(diǎn)，沒有懸空的關(guān)系。關(guān)系的方向和名稱共同為節(jié)點(diǎn)的結(jié)構(gòu)增加了語義的清晰度。
像節(jié)點(diǎn)一樣，關(guān)系也可以具有屬性。向關(guān)系添加屬性的功能對于為圖形算法提供其他元數(shù)據(jù)，為關(guān)系添加其他語義（包括質(zhì)量和權(quán)重）以及在運(yùn)行時約束查詢特別有用。

這些簡單的原語是我們創(chuàng)建復(fù)雜且語義豐富的模型所需要的。到目前為止，我們所有的模型都是以圖表的形式。圖表非常適合在任何技術(shù)環(huán)境之外描述圖表，但是在使用數(shù)據(jù)庫時，我們需要其他一些機(jī)制來創(chuàng)建，處理和查詢數(shù)據(jù)。我們需要一種查詢語言。

3.查詢圖：Cypher簡介

Cypher是一種表現(xiàn)力強(qiáng)（但很緊湊）的圖形數(shù)據(jù)庫查詢語言。盡管當(dāng)前特定于Neo4j，但它與我們將圖形表示為圖形的習(xí)慣緊密相關(guān)，這使其非常適合以編程方式描述圖形。因此，在本書的其余部分中，我們將使用Cypher來說明圖形查詢和圖形構(gòu)造。 Cypher可以說是最容易學(xué)習(xí)的圖形查詢語言，并且是學(xué)習(xí)圖形的重要基礎(chǔ)。一旦了解了Cypher，就可以很容易地進(jìn)行分支和學(xué)習(xí)其他圖形查詢語言。

在以下各節(jié)中，我們將簡要介紹Cypher。但是，這不是Cypher的參考文檔，它只是一個友好的介紹，因此以后我們可以探索更有趣的圖形查詢方案。

其他查詢語言

其他圖形數(shù)據(jù)庫具有其他查詢數(shù)據(jù)的方式。許多人，包括的Neo4j，支持RDF查詢語言SPARQL和勢在必行，基于路徑的查詢語言?Gremlin。但是，我們的興趣在于將屬性圖的表達(dá)能力與聲明性查詢語言結(jié)合使用，因此在本書中，我們幾乎只關(guān)注Cypher。

3.1.Cypher Philosophy

Cypher旨在使開發(fā)人員，數(shù)據(jù)庫專業(yè)人員和業(yè)務(wù)利益相關(guān)者易于閱讀和理解。它更容易從一個事實(shí)，即它是在與雅閣的方式導(dǎo)出使用我們直觀地描述使用圖圖表。

Cypher使用戶（或代表用戶運(yùn)行的應(yīng)用程序）能夠要求數(shù)據(jù)庫查找與特定模式匹配的數(shù)據(jù)。通俗地說，我們要求數(shù)據(jù)庫“查找類似的東西”。我們描述“類似的東西”外觀的方式是使用ASCII藝術(shù)畫它們。圖3-1顯示了一個簡單模式的示例。

此模式描述了三個共同的朋友。這是Cypher中等效的ASCII藝術(shù)作品表示形式：

(emil)<-[:KNOWS]-(jim)-[:KNOWS]->(ian)-[:KNOWS]->(emil)

此模式描述了一條路徑，該路徑將一個稱為jim的節(jié)點(diǎn)連接到兩個稱為ian和emil的節(jié)點(diǎn)，還將ian節(jié)點(diǎn)連接到emil節(jié)點(diǎn)。 ian，jim和emil是標(biāo)識符。標(biāo)識符使我們在描述模式時可以多次引用同一個節(jié)點(diǎn)—一種技巧，可以幫助我們繞過以下事實(shí)：查詢語言只有一個維度（文本從左到右），而可以放置圖形圖二維化。盡管偶爾需要以這種方式重復(fù)標(biāo)識符，但意圖仍然很明確。 Cypher?模式非常自然地遵循我們在白板上繪制圖形的方式。

先前的Cypher模式描述了一種簡單的圖形結(jié)構(gòu)，但尚未引用數(shù)據(jù)庫中的任何特定數(shù)據(jù)。要將模式綁定到現(xiàn)有數(shù)據(jù)集中的特定節(jié)點(diǎn)和關(guān)系，我們必須指定一些屬性值和節(jié)點(diǎn)標(biāo)簽，以幫助在數(shù)據(jù)集中定位相關(guān)元素。例如：

(emil:Person {name:'Emil'}) <-[:KNOWS]-(jim:Person {name:'Jim'})-[:KNOWS]->(ian:Person {name:'Ian'})-[:KNOWS]->(emil)

在這里，我們使用其name屬性和Person標(biāo)簽將每個節(jié)點(diǎn)綁定到其標(biāo)識符。例如，emil identifer綁定到數(shù)據(jù)集中的一個節(jié)點(diǎn)，該節(jié)點(diǎn)的標(biāo)簽為Person，名稱屬性為Emil。以這種方式將模式的某些部分固定到實(shí)際數(shù)據(jù)是Cypher的常規(guī)做法，我們將在以下各節(jié)中看到。

舉例說明

關(guān)于圖的有趣之處在于，它們傾向于包含節(jié)點(diǎn)和關(guān)系的特定實(shí)例，而不是類或原型。通常甚至?xí)褂糜蓪?shí)節(jié)點(diǎn)和關(guān)系構(gòu)成的較小子圖來說明甚至非常大的圖。換句話說，我們傾向于通過示例來描述圖形。

ASCII藝術(shù)圖形模式是Cypher的基礎(chǔ)。 Cypher查詢使用謂詞將模式的一個或多個部分錨定到圖形中的特定位置，然后彎曲未錨定的部分以查找局部匹配項(xiàng)。

Cypher根據(jù)查詢中的標(biāo)簽和屬性謂詞確定實(shí)際圖形中與模式的某些部分綁定到的錨點(diǎn)。在大多數(shù)情況下，Cypher使用有關(guān)現(xiàn)有索引，約束和謂詞的元信息來自動找出問題。但是，有時它有助于指定一些其他提示。

像大多數(shù)查詢語言一樣，Cypher由子句組成。最簡單的查詢由一個MATCH子句和一個RETURN子句組成（我們將在本章稍后介紹在Cypher查詢中可以使用的其他子句）。這是一個使用以下三個子句來查找名為Jim的用戶的共同朋友的Cypher查詢示例:

MATCH (a:Person {name:'Jim'})-[:KNOWS]->(b)-[:KNOWS]->(c), (a)-[:KNOWS]->(c) RETURN b, c

讓我們更詳細(xì)地查看每個子句。

3.2.MATCH

MATCH子句是大多數(shù)Cypher查詢的核心。這是示例說明部分。使用ASCII字符表示節(jié)點(diǎn)和關(guān)系，我們繪制感興趣的數(shù)據(jù)。我們用括號繪制節(jié)點(diǎn)，并使用帶有大于或小于號（->和<-）的破折號對繪制關(guān)系。 <和>符號指示關(guān)系方向。在短劃線之間，用方括號括起來，并用冒號作為前綴，我們放置了關(guān)系名稱。節(jié)點(diǎn)標(biāo)簽類似地以冒號作為前綴。然后，在花括號（非常像Javascript對象）中指定節(jié)點(diǎn)（和關(guān)系）屬性鍵值對。

在示例查詢中，我們正在尋找一個名為Person的節(jié)點(diǎn)，其名稱屬性為Jim。該查詢的返回值綁定到標(biāo)識符a。該標(biāo)識符使我們可以在整個查詢的其余部分中引用表示Jim的節(jié)點(diǎn)。

此起始節(jié)點(diǎn)是簡單模式?(a)-[:KNOWS]->(b)-[:KNOWS]->(c), (a)-[:KNOWS]->(c)?描述了一個包含三個節(jié)點(diǎn)的路徑，其中一個是
綁定到標(biāo)識符a，其他綁定到b和c。這些節(jié)點(diǎn)通過以下方式連接多個KNOWS關(guān)系，如圖3-1所示。

從理論上講，這種模式可能會在整個圖形數(shù)據(jù)中多次出現(xiàn)。對于較大的用戶集，可能存在許多與此模式相對應(yīng)的相互關(guān)系。要本地化查詢，我們需要它的某些部分錨定到圖中的一個或多個地點(diǎn)。在指定我們要尋找一個標(biāo)記為Person且名稱屬性值為Jim的節(jié)點(diǎn)時，我們已將模式綁定到圖中的特定節(jié)點(diǎn)，即代表Jim的節(jié)點(diǎn)。然后，Cypher將模式的其余部分與緊靠該錨點(diǎn)的圖形進(jìn)行匹配。這樣，它將發(fā)現(xiàn)要綁定到其他標(biāo)識符的節(jié)點(diǎn)。盡管a將始終固定在Jim上，但是b和c將在查詢執(zhí)行時綁定到一系列節(jié)點(diǎn)上。

另外，我們可以在WHERE子句中將錨表示為謂詞。

MATCH (a:Person)-[:KNOWS]->(b)-[:KNOWS]->(c), (a)-[:KNOWS]->(c) WHERE a.name = 'Jim' RETURN b, c

在這里，我們已將屬性查找從MATCH子句移到WHERE子句。結(jié)果與之前的查詢相同。

3.3.RETURN

此子句指定應(yīng)將匹配數(shù)據(jù)中的哪些節(jié)點(diǎn)，關(guān)系和屬性返回給客戶端。在示例查詢中，我們有興趣返回綁定到b和c標(biāo)識符的節(jié)點(diǎn)。當(dāng)客戶端迭代結(jié)果時，每個匹配節(jié)點(diǎn)都被延遲綁定到其標(biāo)識符。

3.4.其他Cypher語法

我們可以在Cypher查詢中使用的其他子句包括：

WHERE?
- 提供用于過濾模式匹配結(jié)果的條件。
CREATE and ?CREATE UNIQUE
- 創(chuàng)建節(jié)點(diǎn)和關(guān)系。
MERGE
- 通過重用與提供的謂詞匹配的現(xiàn)有節(jié)點(diǎn)和關(guān)系，或通過創(chuàng)建新的節(jié)點(diǎn)和關(guān)系，確保圖中存在提供的模式。
DELETE
- 刪除節(jié)點(diǎn)，關(guān)系和屬性。
SET
- 設(shè)置屬性值。
FOREACH
- 對列表中的每個元素執(zhí)行更新操作。
UNION
- 合并兩個或多個查詢的結(jié)果。
WITH
- 鏈接后續(xù)查詢部分并將結(jié)果從一個查詢轉(zhuǎn)發(fā)到下一個查詢。類似于Unix中的管道命令。
START
- 在圖中指定一個或多個明確的起點(diǎn)-節(jié)點(diǎn)或關(guān)系。（不建議使用START，而應(yīng)在MATCH子句中指定錨點(diǎn)。）

如果這些條款看起來很熟悉（尤其是您是SQL開發(fā)人員），那就太好了！ Cypher旨在使您足夠熟悉，以幫助您沿著學(xué)習(xí)曲線快速移動。同時，它的區(qū)別足以強(qiáng)調(diào)我們是在處理圖形，而不是關(guān)系集。

我們將在本章后面看到這些條款的一些示例。在它們發(fā)生的地方，我們將更詳細(xì)地描述它們?nèi)绾喂ぷ鳌?/p>

現(xiàn)在，我們已經(jīng)了解了如何使用Cypher來描述和查詢圖形，下面我們來看一些圖形建模的示例。

4.關(guān)系和圖建模的比較

為了介紹圖形建模，我們將研究如何使用基于關(guān)系和基于圖形的技術(shù)對域進(jìn)行建模。大多數(shù)開發(fā)人員和數(shù)據(jù)專業(yè)人員都熟悉RDBMS（關(guān)系數(shù)據(jù)庫管理系統(tǒng)）和相關(guān)的數(shù)據(jù)建模技術(shù)。結(jié)果，比較將突出一些相似之處和許多差異。特別是，我們將看到從概念圖模型轉(zhuǎn)換為物理圖模型有多么容易，并且相對于關(guān)系模型，圖模型扭曲了我們要表示的內(nèi)容。

為了便于進(jìn)行比較，我們將研究一個簡單的數(shù)據(jù)中心管理域。在此領(lǐng)域中，數(shù)個數(shù)據(jù)中心代表使用不同基礎(chǔ)架構(gòu)（從虛擬機(jī)到物理負(fù)載平衡器）的許多客戶，支持許多應(yīng)用程序。此域的示例如圖3-2所示。

在圖3-2中，我們看到了一些應(yīng)用程序以及支持它們的必要數(shù)據(jù)中心基礎(chǔ)結(jié)構(gòu)的簡化視圖。由節(jié)點(diǎn)App 1，App 2和App 3表示的應(yīng)用程序依賴于標(biāo)記為Database Server 1、2、3的數(shù)據(jù)庫集群。盡管用戶在邏輯上取決于應(yīng)用程序及其數(shù)據(jù)的可用性，但用戶與應(yīng)用程序之間存在其他物理基礎(chǔ)架構(gòu)；此基礎(chǔ)結(jié)構(gòu)包括虛擬客戶端（VM10、11、20、30、31），真實(shí)服務(wù)器（Service1、2、3），服務(wù)器機(jī)架（Rack1、2）和負(fù)載均衡器（Balance 1、2）），位于應(yīng)用程序的前面。當(dāng)然，在每個組件之間都有許多網(wǎng)絡(luò)元素：電纜，交換機(jī)，配線架，NIC（網(wǎng)絡(luò)接口控制器），電源，空調(diào)等，所有這些元素在不方便的時候都會發(fā)生故障。為了完成圖片，我們有一個應(yīng)用程序3的單一用戶，由用戶3表示。

作為此類系統(tǒng)的運(yùn)營商，我們有兩個主要關(guān)注點(diǎn)：

持續(xù)提供滿足（或超過）服務(wù)水平協(xié)議的功能，包括執(zhí)行前瞻性分析以確定單點(diǎn)故障的能力以及追溯分析以快速確定引起客戶對服務(wù)可用性投訴的原因的能力。
為消耗的資源開賬單，包括硬件，虛擬化，網(wǎng)絡(luò)配置的成本，甚至軟件開發(fā)和運(yùn)營的成本（因?yàn)檫@些只是我們在此處看到的系統(tǒng)的邏輯擴(kuò)展）。

如果我們要構(gòu)建數(shù)據(jù)中心管理解決方案，則需要確?；A(chǔ)數(shù)據(jù)模型允許我們以有效解決這些主要問題的方式來存儲和查詢數(shù)據(jù)。我們還將希望能夠隨著應(yīng)用程序產(chǎn)品組合的變化，數(shù)據(jù)中心的物理布局的發(fā)展以及虛擬機(jī)實(shí)例的遷移而更新基礎(chǔ)模型。考慮到這些需求和約束，讓我們看看關(guān)系模型和圖形模型的比較。

4.1.系統(tǒng)管理領(lǐng)域中的關(guān)系建模

關(guān)系世界中建模的初始階段與許多其他數(shù)據(jù)建模技術(shù)的初始階段相似：也就是說，我們試圖理解并同意域中的實(shí)體，它們之間的相互關(guān)系以及控制其狀態(tài)轉(zhuǎn)換的規(guī)則。其中大多數(shù)傾向于非正式地完成，通常是通過白板草圖以及主題專家，系統(tǒng)與數(shù)據(jù)架構(gòu)師之間的討論來完成。為了表達(dá)我們的共同理解和共識，我們通常創(chuàng)建一個如圖3-2所示的圖表。

下一階段以更嚴(yán)格的形式捕獲此協(xié)議，例如實(shí)體關(guān)系（E-R）圖-另一個圖。使用更嚴(yán)格的表示法將概念模型轉(zhuǎn)換為邏輯模型，為我們提供了第二次機(jī)會來完善我們的領(lǐng)域詞匯，以便可以與關(guān)系數(shù)據(jù)庫專家共享。（這種方法并非總是必要的：熟練的關(guān)系用戶經(jīng)常直接進(jìn)行表設(shè)計和規(guī)范化操作，而無需先描述中間的E-R圖。）在我們的示例中，我們已在圖3-3所示的E-R圖中捕獲了域。

盡管是圖，但ER圖立即證明了關(guān)系模型捕獲富域的缺點(diǎn)。盡管它們允許命名關(guān)系（圖數(shù)據(jù)庫完全包含了某種東西，但關(guān)系存儲卻沒有），但ER圖僅允許單個，無向，實(shí)體之間的命名關(guān)系。在這方面，關(guān)系模型不適用于實(shí)體域之間的關(guān)系既豐富又語義豐富多樣的現(xiàn)實(shí)世界域。

找到合適的邏輯模型后，我們將其映射到表和關(guān)系中，對它們進(jìn)行規(guī)范化以消除數(shù)據(jù)冗余。在許多情況下，此步驟很簡單，例如將E-R圖轉(zhuǎn)錄為表格形式，然后通過SQL命令將這些表加載到數(shù)據(jù)庫中。但是，即使是最簡單的情況也可以用來突出關(guān)系模型的特質(zhì)。例如，在圖3-4中，我們看到大量意外復(fù)雜性以外鍵約束（所有帶注釋[FK]）的形式進(jìn)入了模型，該約束支持一對多關(guān)系以及聯(lián)接表（例如AppDatabase），它支持多對多關(guān)系-在添加一行實(shí)際用戶數(shù)據(jù)之前，所有這些都需要支持。這些約束是簡單存在的模型級元數(shù)據(jù)，因此我們可以在查詢時具體化表之間的關(guān)系。但是，人們還是敏銳地感覺到這種結(jié)構(gòu)性數(shù)據(jù)的存在，因?yàn)樗鼤狗?wù)于數(shù)據(jù)庫而不是用戶的數(shù)據(jù)變得混亂和模糊。

現(xiàn)在，我們有了一個相對于該領(lǐng)域相對忠誠的規(guī)范化模型。盡管該模型以外鍵和聯(lián)接表的形式帶來了相當(dāng)大的意外復(fù)雜性，但其中沒有重復(fù)的數(shù)據(jù)。但是我們的設(shè)計工作尚未完成。關(guān)系范式的挑戰(zhàn)之一是規(guī)范化模型通常不夠快，無法滿足實(shí)際需求。對于許多生產(chǎn)系統(tǒng)，規(guī)范化的模式在理論上適合于回答我們可能希望對域提出的任何特殊問題，在實(shí)踐中必須對其進(jìn)行進(jìn)一步調(diào)整并使其專門用于特定的訪問模式。換句話說，為了使關(guān)系存儲能夠很好地滿足常規(guī)應(yīng)用程序的需求，我們必須放棄任何具有真實(shí)域親和力的痕跡，并接受必須更改用戶的數(shù)據(jù)模型以適合數(shù)據(jù)庫引擎（而不是用戶）的觀點(diǎn)。這種技術(shù)稱為非規(guī)范化。

為了獲得查詢性能，非規(guī)范化涉及復(fù)制數(shù)據(jù)（在某些情況下，實(shí)質(zhì)上是重復(fù)的）。以用戶及其聯(lián)系方式為例。典型的用戶通常有幾個電子郵件地址，在完全規(guī)范化的模型中，我們會將其存儲在單獨(dú)的EMAIL表中。但是，為了減少聯(lián)接和兩個表之間的聯(lián)接帶來的性能損失，在USER表中內(nèi)聯(lián)此數(shù)據(jù)，添加一個或多個列來存儲用戶最重要的電子郵件地址是很常見的。

盡管進(jìn)行非規(guī)范化可能是安全的事情（假設(shè)開發(fā)人員了解非規(guī)范化模型及其如何映射到以域?yàn)橹行牡拇a，并從數(shù)據(jù)庫獲得強(qiáng)大的事務(wù)支持），但這通常不是一項(xiàng)瑣碎的任務(wù)。為了獲得最佳結(jié)果，我們通常會請一位真正的RDBMS專家來將我們的規(guī)范化模型改成與基礎(chǔ)RDBMS和物理存儲層的特征一致的非規(guī)范化模型。為此，我們接受可能存在大量的數(shù)據(jù)冗余。

我們可能會認(rèn)為所有這些設(shè)計規(guī)范化非規(guī)范化工作都是可以接受的，因?yàn)檫@是一項(xiàng)一次性的任務(wù)。這種學(xué)派認(rèn)為，工作成本在系統(tǒng)的整個生命周期（包括開發(fā)和生產(chǎn)）中攤銷，因此與項(xiàng)目的總成本相比，生成高效的關(guān)系模型的工作量相對較小。這是一個吸引人的概念，但是在許多情況下，它與現(xiàn)實(shí)不符，因?yàn)橄到y(tǒng)不僅在開發(fā)過程中會發(fā)生變化，而且在產(chǎn)品生命周期中也會發(fā)生變化。

數(shù)據(jù)模型更改的攤銷視圖（在模型中，開發(fā)過程中代價高昂的更改被生產(chǎn)中穩(wěn)定模型的長期利益所掩蓋）假定系統(tǒng)在生產(chǎn)環(huán)境中花費(fèi)了大部分時間，并且這些生產(chǎn)環(huán)境是穩(wěn)定的。盡管大多數(shù)系統(tǒng)可能會在生產(chǎn)環(huán)境中花費(fèi)大部分時間，但這些環(huán)境很少穩(wěn)定。隨著業(yè)務(wù)需求的變化或法規(guī)要求的發(fā)展，我們的系統(tǒng)和基于它們的數(shù)據(jù)結(jié)構(gòu)也必須隨之變化。

在項(xiàng)目的設(shè)計和開發(fā)階段，數(shù)據(jù)模型總是會經(jīng)過實(shí)質(zhì)性的修訂，并且在幾乎每種情況下，這些修訂都旨在滿足模型的需求，以適應(yīng)將要在生產(chǎn)中使用它的應(yīng)用程序的需求。這些最初的設(shè)計影響力如此之大，以至于在生產(chǎn)后就無法修改應(yīng)用程序和模型以適應(yīng)最初設(shè)計時無法做的事情。

我們將結(jié)構(gòu)更改引入數(shù)據(jù)庫的技術(shù)機(jī)制稱為遷移(Migrations)，這種遷移已被Rails等應(yīng)用程序開發(fā)框架所普及。遷移提供了一種結(jié)構(gòu)化的，逐步的方法，可以將一組數(shù)據(jù)庫重構(gòu)應(yīng)用到數(shù)據(jù)庫，以便可以負(fù)責(zé)任地發(fā)展它以滿足使用它的應(yīng)用程序不斷變化的需求。但是，與我們通常在幾秒鐘或幾分鐘內(nèi)完成的代碼重構(gòu)不同，數(shù)據(jù)庫重構(gòu)可能需要數(shù)周或數(shù)月的時間才能完成，而架構(gòu)更改則需要停機(jī)時間。數(shù)據(jù)庫重構(gòu)速度慢，風(fēng)險大且昂貴。

因此，非規(guī)范化模型的問題在于其對系統(tǒng)業(yè)務(wù)需求的快速發(fā)展的抵制。正如我們在數(shù)據(jù)中心示例中看到的那樣，在實(shí)施關(guān)系解決方案的過程中對白板模型施加的更改，在概念世界和數(shù)據(jù)物理布局方式之間產(chǎn)生了鴻溝。這種概念上的關(guān)系失調(diào)幾乎阻止了業(yè)務(wù)利益相關(guān)者在系統(tǒng)的進(jìn)一步發(fā)展中進(jìn)行積極的協(xié)作。利益相關(guān)者的參與停止在關(guān)系大廈的門檻上。在開發(fā)方面，將已更改的業(yè)務(wù)需求轉(zhuǎn)換為基礎(chǔ)和根深蒂固的關(guān)系結(jié)構(gòu)的困難使系統(tǒng)的發(fā)展滯后于業(yè)務(wù)的發(fā)展。沒有專家的幫助和嚴(yán)格的計劃，遷移非規(guī)范化的數(shù)據(jù)庫會帶來很多風(fēng)險。如果遷移無法維持存儲親和性，則性能可能會受到影響。同樣嚴(yán)重的是，如果在遷移后將故意重復(fù)的數(shù)據(jù)留為孤立，我們有可能危及整個數(shù)據(jù)的完整性。

4.2.系統(tǒng)管理域中的圖形建模

我們已經(jīng)看到了關(guān)系建模及其伴隨的實(shí)現(xiàn)活動，如何使我們沿著將應(yīng)用程序的基礎(chǔ)存儲模型與利益相關(guān)者的概念世界觀分離開來的道路。具有剛性模式和復(fù)雜建模特性的關(guān)系數(shù)據(jù)庫并不是支持快速變化的特別好的工具。我們需要一個與領(lǐng)域緊密相關(guān)的模型，但它不會犧牲性能，并且在數(shù)據(jù)進(jìn)行快速更改和增長時，既支持演化又保持?jǐn)?shù)據(jù)的完整性。該模型是圖模型。那么，使用圖形數(shù)據(jù)模型實(shí)現(xiàn)時，此過程有何不同？

在分析的早期階段，我們所需的工作類似于關(guān)系方法：使用lo-fi方法（例如白板草圖），我們描述并同意了該領(lǐng)域。但是，此后方法有所不同。我們沒有豐富領(lǐng)域模型的圖形表示形式，而是將其豐富化，目的是對領(lǐng)域中與我們的應(yīng)用目標(biāo)相關(guān)的部分進(jìn)行準(zhǔn)確的表示。也就是說，對于我們域中的每個實(shí)體，我們都確保已捕獲其相關(guān)角色（作為標(biāo)簽），其屬性（作為屬性）以及與相鄰實(shí)體的關(guān)系（作為關(guān)系）。

記住，領(lǐng)域模型不是通向現(xiàn)實(shí)的透明，無上下文的窗口：相反，它是對領(lǐng)域中與我們的應(yīng)用程序目標(biāo)有關(guān)的那些方面的有目的抽象。建立模型總是有動力。通過使用其他屬性和關(guān)聯(lián)性來豐富我們的第一手域圖，我們可以有效地生成與應(yīng)用程序的數(shù)據(jù)需求相匹配的圖模型。也就是說，我們提供了回答我們的應(yīng)用程序?qū)⒃儐柶鋽?shù)據(jù)的各種問題。

有用的是，領(lǐng)域建模與圖建模完全同構(gòu)。通過確保域模型的正確性，我們隱式改進(jìn)了圖形模型，因?yàn)樵趫D形數(shù)據(jù)庫中，您在白板上繪制的內(nèi)容通常是您在數(shù)據(jù)庫中存儲的內(nèi)容。

用圖形表示，我們正在做的是確保每個節(jié)點(diǎn)具有適當(dāng)?shù)慕巧囟ǖ臉?biāo)簽和屬性，以便其能夠履行其以數(shù)據(jù)為中心的專用域職責(zé)。但是，我們還要確保每個節(jié)點(diǎn)都位于正確的語義上下文中；為此，我們通過在節(jié)點(diǎn)之間創(chuàng)建命名和定向（通常是屬性）關(guān)系來捕獲域的結(jié)構(gòu)方面。對于我們的數(shù)據(jù)中心場景，生成的圖形模型如圖3-5所示。

從邏輯上講，這就是我們需要做的。沒有表，沒有規(guī)范化，沒有非規(guī)范化。一旦我們有了域模型的準(zhǔn)確表示，將其移到數(shù)據(jù)庫中就變得微不足道了，我們很快就會看到。

請注意，這里的大多數(shù)節(jié)點(diǎn)都有兩個標(biāo)簽：特定類型的標(biāo)簽（例如Database，App或Server）和更通用的Asset標(biāo)簽。這使我們能夠通過某些查詢來定位特定類型的資產(chǎn)，并通過其他查詢來定位所有資產(chǎn)，而不論類型如何。

4.3.測試模型

完善域模型后，下一步就是測試它是否適合回答實(shí)際查詢。盡管圖形非常適合于支持不斷發(fā)展的結(jié)構(gòu)（因此可以糾正任何錯誤的早期設(shè)計決策），但是有許多設(shè)計決策一旦被應(yīng)用到我們的應(yīng)用程序中，便會進(jìn)一步阻礙我們前進(jìn)。通過在此早期階段回顧域模型和結(jié)果圖模型，我們可以避免這些陷阱。圖結(jié)構(gòu)的后續(xù)更改將僅由業(yè)務(wù)更改驅(qū)動，而不是由減輕不良設(shè)計決策的需求驅(qū)動。

實(shí)際上，我們可以在此處應(yīng)用兩種技術(shù)。第一個，也是最簡單的，只是檢查圖是否讀得好。我們選擇一個開始節(jié)點(diǎn)，然后關(guān)注與其他節(jié)點(diǎn)的關(guān)系，并在進(jìn)行過程中讀取每個節(jié)點(diǎn)的標(biāo)簽和每個關(guān)系的名稱。這樣做應(yīng)該創(chuàng)造出明智的句子。對于我們的數(shù)據(jù)中心示例，我們可以讀取如下語句：“由應(yīng)用程序?qū)嵗?、2和3組成的應(yīng)用程序使用駐留在數(shù)據(jù)庫服務(wù)器1、2和3上的數(shù)據(jù)庫，”和“服務(wù)器3運(yùn)行承載應(yīng)用程序?qū)嵗?的VM31?！比绻赃@種方式讀取圖形是有意義的，那么我們可以合理地確信它對域是忠實(shí)的。

為了進(jìn)一步提高信心，我們還需要考慮將在圖（graph）上運(yùn)行的查詢。在這里，我們采用可查詢性思維方式的設(shè)計。為了驗(yàn)證圖是否支持我們期望在其上運(yùn)行的查詢，我們必須描述這些查詢。這要求我們了解最終用戶的目標(biāo)；也就是說，將要應(yīng)用圖形的用例。例如，在我們的數(shù)據(jù)中心場景中，我們的一個使用案例涉及最終用戶報告應(yīng)用程序或服務(wù)無響應(yīng)。為了幫助這些用戶，我們必須找出無響應(yīng)的原因，然后加以解決。為了確定可能出了什么問題，我們需要確定用戶與應(yīng)用程序之間路徑上的內(nèi)容，以及應(yīng)用程序向用戶交付功能所依賴的內(nèi)容。給定數(shù)據(jù)中心域的特定圖形表示形式，如果我們可以設(shè)計一個解決該用例的Cypher查詢，則我們甚至可以確定該圖形滿足我們域的需求。

繼續(xù)我們的示例用例，假設(shè)我們可以從常規(guī)的網(wǎng)絡(luò)監(jiān)控工具中更新圖表，從而為我們提供網(wǎng)絡(luò)狀態(tài)的近實(shí)時視圖。對于大型物理網(wǎng)絡(luò)，我們可能會使用復(fù)雜事件處理（CEP）處理低級網(wǎng)絡(luò)事件流，僅在CEP解決方案引發(fā)重大領(lǐng)域事件時才更新圖形。當(dāng)用戶報告問題時，我們可以將物理故障查找限制在用戶與應(yīng)用程序之間以及應(yīng)用程序及其依存關(guān)系之間的有問題的網(wǎng)絡(luò)元素上。在我們的圖形中，可以通過以下查詢找到有故障的設(shè)備：

MATCH (user:User)-[*1..5]-(asset:Asset) WHERE user.name = 'User 3' AND asset.status = 'down' RETURN DISTINCT asset

這里的MATCH子句描述了一個長度介于一到五個關(guān)系之間的可變長度路徑。關(guān)系是未命名和無方向的（方括號之間沒有冒號或關(guān)系名稱，也沒有箭頭指示方向）。這使我們可以匹配以下路徑：

(user)-[:USER_OF]->(app) (user)-[:USER_OF]->(app)-[:USES]->(database) (user)-[:USER_OF]->(app)-[:USES]->(database)-[:SLAVE_OF]->(another-database) (user)-[:USER_OF]->(app)-[:RUNS_ON]->(vm) (user)-[:USER_OF]->(app)-[:RUNS_ON]->(vm)-[:HOSTED_BY]->(server) (user)-[:USER_OF]->(app)-[:RUNS_ON]->(vm)-[:HOSTED_BY]->(server)-[:IN]->(rack) (user)-[:USER_OF]->(app)-[:RUNS_ON]->(vm)-[:HOSTED_BY]->(server)-[:IN]->(rack) <-[:IN]-(load-balancer)

就是說，從報告問題的用戶開始，我們沿著長度為1到5的無向路徑匹配圖中的所有資產(chǎn)。我們添加了資產(chǎn)節(jié)點(diǎn)，這些資產(chǎn)節(jié)點(diǎn)的status屬性的值小于我們的結(jié)果。如果節(jié)點(diǎn)沒有狀態(tài)屬性，則該節(jié)點(diǎn)不會包含在結(jié)果中。 RETURN DISTINCT資產(chǎn)可確保無論匹配多少次，結(jié)果中都將返回唯一有價值的事物。

鑒于我們的圖形很容易支持這樣的查詢，因此我們可以確信該設(shè)計適合目標(biāo)。

5.跨域模型

業(yè)務(wù)洞察力通常取決于我們了解復(fù)雜價值鏈中隱藏的網(wǎng)絡(luò)效應(yīng)。為了產(chǎn)生這種理解，我們需要將域合并在一起，而不會扭曲或犧牲每個域特有的細(xì)節(jié)。屬性圖在此處提供了解決方案。使用屬性圖，我們可以將價值鏈建模為圖的圖，其中特定的關(guān)系連接并區(qū)分組成子域。

在圖3-6中，我們看到了圍繞莎士比亞文學(xué)的生產(chǎn)和消費(fèi)的價值鏈的圖形表示。在這里，我們可以獲得有關(guān)莎士比亞和他的一些戲劇的高質(zhì)量信息，以及最近進(jìn)行過戲劇表演的公司之一的詳細(xì)信息，以及劇院場地和一些地理空間數(shù)據(jù)。我們甚至添加了評論。總之，該圖描述并連接了三個不同的域。在圖表中，我們區(qū)分了這三種具有不同格式關(guān)系的域：點(diǎn)號代表文學(xué)領(lǐng)域，實(shí)線代表戲劇領(lǐng)域，點(diǎn)劃線代表地理空間領(lǐng)域。

首先看一下文學(xué)領(lǐng)域，我們有一個代表莎士比亞本人的節(jié)點(diǎn)，帶有一個標(biāo)簽Author和屬性firstname:'William'和?lastname:'Shakespeare'。該節(jié)點(diǎn)通過名為WROTE_PLAY的關(guān)系連接到一對節(jié)點(diǎn)，每個節(jié)點(diǎn)都標(biāo)記為Play，分別代表戲劇Julius Caesar（?title:'Julius Caesar'）和The Tempest（?title:'The Tempest'）。

按照關(guān)系箭頭的方向從左到右閱讀該子圖，告訴我們作家威廉·莎士比亞（William Shakespeare）創(chuàng)作了戲劇《凱撒大帝》和《暴風(fēng)雨》。如果我們對出處感興趣，那么每個WROTE_PLAY關(guān)系都有一個date屬性，它告訴我們Julius Caesar于1599年編寫，而Tempest于1610年編寫。了解如何添加莎士比亞的其他作品（戲劇）是一件微不足道的事情。只需添加更多代表每個作品的節(jié)點(diǎn)，然后通過WROTE_PLAY和WROTE_POEM關(guān)系將它們加入莎士比亞節(jié)點(diǎn)，就可以將詩和詩歌插入圖表中。

通過用手指跟蹤WROTE_PLAY關(guān)系箭頭，我們可以有效地完成圖形數(shù)據(jù)庫執(zhí)行的工作，盡管是以人的速度而不是計算機(jī)的速度進(jìn)行的。稍后我們將看到，此簡單的遍歷操作是任意復(fù)雜的圖形查詢的基礎(chǔ)。

接下來轉(zhuǎn)到戲劇領(lǐng)域，我們添加了有關(guān)皇家莎士比亞劇團(tuán)（通常簡稱為RSC）的一些信息，其形式為帶有標(biāo)簽Company和屬性鍵名稱（其值為RSC）的節(jié)點(diǎn)。毫無疑問，戲劇領(lǐng)域與文學(xué)領(lǐng)域息息相關(guān)。在我們的圖表中，RSC具有Julius Caesar和The Tempest的PRODUCED版本。反過來，這些戲劇作品通過PRODUCTION_OF關(guān)系與文學(xué)領(lǐng)域的戲劇聯(lián)系起來。

該圖還捕獲了特定性能的詳細(xì)信息。例如，作為RSC夏季巡回演出的一部分，RSC在2012年7月29日進(jìn)行了Julius Caesar的制作。如果我們對表演場地感興趣，我們只需遵循表演節(jié)點(diǎn)的傳出VENUE關(guān)系，即可發(fā)現(xiàn)該表演是在皇家劇院進(jìn)行的，由一個標(biāo)有Venue的節(jié)點(diǎn)表示。

該圖還允許我們捕獲對特定性能的評論。在我們的示例圖中，我們僅包含了用戶Billy撰寫的7月29日效果的評論。我們可以在性能，評級和用戶節(jié)點(diǎn)的相互作用中看到這一點(diǎn)。在這種情況下，我們有一個標(biāo)記為User的節(jié)點(diǎn)，表示Billy（屬性name:'Billy'），其傳出的WROTE_REVIEW關(guān)系連接到表示其評論的節(jié)點(diǎn)。 “Review”節(jié)點(diǎn)包含一個數(shù)字評級屬性和一個自由文本審閱屬性。該評論通過傳出的REVIEW_OF關(guān)系鏈接到特定的效果。為了將其擴(kuò)展到許多用戶，許多評論和許多性能，我們只需向圖添加更多帶有適當(dāng)標(biāo)簽和更同名關(guān)系的節(jié)點(diǎn)。

第三個域是地理空間數(shù)據(jù)域，它包含一個簡單的位置層次樹。該地理空間域在圖中的幾個點(diǎn)連接到其他兩個域。雅芳的斯特拉特福市（財產(chǎn)名稱：“雅芳河畔的斯特拉福德福特”）由于是莎士比亞的發(fā)源地而與文學(xué)領(lǐng)域息息相關(guān)（莎士比亞的名字是BORN_IN斯特拉特福德）。只要它是RSC的所在地（RSC是BASED_IN Stratford），它就連接到戲劇域。要根據(jù)雅芳的地理?xiàng)l件進(jìn)一步了解斯特拉特福，我們可以通過與COUNTRY的往來COUNTRY關(guān)系來了解它是否位于名為England的國家/地區(qū)。

注意圖如何減少跨域重復(fù)數(shù)據(jù)的實(shí)例。例如，埃文河畔的斯特拉特福就參與了這三個領(lǐng)域。

該圖可以捕獲更復(fù)雜的地理空間數(shù)據(jù)。例如，查看與Theatre Royal相連的節(jié)點(diǎn)上的標(biāo)簽，我們發(fā)現(xiàn)它位于Gray Street上，該大街位于Newcastle市中，該市位于Tyne and Wear縣，而該市最終位于英格蘭國家-就像埃文河畔的斯特拉特福一樣。

關(guān)系和標(biāo)簽

我們在這里使用關(guān)系名稱和節(jié)點(diǎn)標(biāo)簽來構(gòu)造圖并為每個節(jié)點(diǎn)建立語義上下文。

關(guān)系的名稱和方向通過以有意義的方式連接兩個節(jié)點(diǎn)來幫助建立語義上下文。例如，通過遵循傳出的WROTE_REVIEW關(guān)系，我們了解到該關(guān)系末尾的節(jié)點(diǎn)表示評論。

關(guān)系有助于將圖形劃分到單獨(dú)的域中并連接這些域。從莎士比亞的例子中可以看出，通過屬性圖模型，可以輕松組合不同的域（每個域都具有自己的特定實(shí)體，標(biāo)簽，屬性和關(guān)系），這種方式不僅使每個域都可以訪問，而且可以產(chǎn)生洞察力從域之間的連接。

標(biāo)簽代表每個節(jié)點(diǎn)在我們的域中扮演的角色。因?yàn)橐粋€節(jié)點(diǎn)可以連接到許多其他節(jié)點(diǎn)，其中一些節(jié)點(diǎn)可能來自非常不同的域，所以一個節(jié)點(diǎn)可以潛在地履行幾個不同的角色。

標(biāo)簽是屬性圖模型的一等公民。標(biāo)簽除了表明不同節(jié)點(diǎn)在我們的域中扮演的角色外，還允許我們將元數(shù)據(jù)與那些標(biāo)簽所附加的節(jié)點(diǎn)相關(guān)聯(lián)。例如，我們可以為所有帶有用戶標(biāo)簽的節(jié)點(diǎn)建立索引，或者要求所有帶有客戶標(biāo)簽的節(jié)點(diǎn)具有唯一的電子郵件屬性值。

5.1.創(chuàng)建莎士比亞圖

要創(chuàng)建如圖3-6所示的莎士比亞圖，我們使用CREATE來構(gòu)建整體結(jié)構(gòu)。該語句由Cypher運(yùn)行時在單個事務(wù)中執(zhí)行，因此一旦執(zhí)行了該語句，我們就可以確信該圖完整地存在于數(shù)據(jù)庫中。如果事務(wù)失敗，則數(shù)據(jù)庫中將不包含任何圖形。如我們所料，Cypher具有人性化和可視化的圖形生成方式：

CREATE (shakespeare:Author {firstname:'William', lastname:'Shakespeare'}), (juliusCaesar:Play {title:'Julius Caesar'}), (shakespeare)-[:WROTE_PLAY {year:1599}]->(juliusCaesar), (theTempest:Play {title:'The Tempest'}), (shakespeare)-[:WROTE_PLAY {year:1610}]->(theTempest), (rsc:Company {name:'RSC'}), (production1:Production {name:'Julius Caesar'}), (rsc)-[:PRODUCED]->(production1), (production1)-[:PRODUCTION_OF]->(juliusCaesar), (performance1:Performance {date:20120729}), (performance1)-[:PERFORMANCE_OF]->(production1), (production2:Production {name:'The Tempest'}), (rsc)-[:PRODUCED]->(production2), (production2)-[:PRODUCTION_OF]->(theTempest), (performance2:Performance {date:20061121}), (performance2)-[:PERFORMANCE_OF]->(production2), (performance3:Performance {date:20120730}), (performance3)-[:PERFORMANCE_OF]->(production1), (billy:User {name:'Billy'}), (review:Review {rating:5, review:'This was awesome!'}), (billy)-[:WROTE_REVIEW]->(review), (review)-[:RATED]->(performance1), (theatreRoyal:Venue {name:'Theatre Royal'}), (performance1)-[:VENUE]->(theatreRoyal), (performance2)-[:VENUE]->(theatreRoyal), (performance3)-[:VENUE]->(theatreRoyal), (greyStreet:Street {name:'Grey Street'}), (theatreRoyal)-[:STREET]->(greyStreet), (newcastle:City {name:'Newcastle'}), (greyStreet)-[:CITY]->(newcastle), (tyneAndWear:County {name:'Tyne and Wear'}), (newcastle)-[:COUNTY]->(tyneAndWear), (england:Country {name:'England'}), (tyneAndWear)-[:COUNTRY]->(england), (stratford:City {name:'Stratford upon Avon'}), (stratford)-[:COUNTRY]->(england), (rsc)-[:BASED_IN]->(stratford), (shakespeare)-[:BORN_IN]->stratford

前面的Cypher代碼有兩個不同的作用。它創(chuàng)建帶標(biāo)簽的節(jié)點(diǎn)（及其屬性），然后將它們與關(guān)系（必要時及其關(guān)系屬性）連接起來。

例如，?CREATE (shakespeare:Author {firstname:'William', lastname:'Shakespeare'})??創(chuàng)建一個Author節(jié)點(diǎn)，表示威廉·莎士比亞。

新創(chuàng)建的節(jié)點(diǎn)被分配給標(biāo)識符shakespeare。該shakespeare標(biāo)識符稍后在代碼中用于將關(guān)系附加到基礎(chǔ)節(jié)點(diǎn)。

例如，(shakespeare)-[:WROTE_PLAY {year:1599}]->(juliusCaesar)?創(chuàng)建了從莎士比亞到劇本Julius Caesar的WROTE關(guān)系。

該關(guān)系的?year屬性值為1599。

標(biāo)識符在當(dāng)前查詢范圍內(nèi)一直可用，但不再可用。如果我們希望為節(jié)點(diǎn)提供長久的名稱，我們只需為特定標(biāo)簽和鍵屬性組合創(chuàng)建索引。我們在“索引和約束”中討論索引。

與關(guān)系模型不同，這些命令不會在圖表中引入任何意外的復(fù)雜性。信息元模型（即通過標(biāo)簽和關(guān)系建立節(jié)點(diǎn)的結(jié)構(gòu)）與業(yè)務(wù)數(shù)據(jù)保持分離，業(yè)務(wù)數(shù)據(jù)僅作為屬性存在。我們再也不必?fù)?dān)心外鍵和基數(shù)約束會污染我們的真實(shí)數(shù)據(jù)，因?yàn)樵趫D模型中，這兩者都是節(jié)點(diǎn)形式以及將它們互連的語義豐富的關(guān)系，是顯式的。

我們可以在以后的某個時間以兩種不同的方式修改圖形。當(dāng)然，我們可以繼續(xù)使用CREATE語句簡單地添加到圖形中。但是我們也可以使用MERGE，它的語義是確保一旦執(zhí)行命令，節(jié)點(diǎn)和關(guān)系的特定子圖結(jié)構(gòu)（其中一些可能已經(jīng)存在，其中一些可能會丟失）已經(jīng)存在。在實(shí)踐中，當(dāng)我們添加到圖表中時，我們傾向于使用CREATE，并且不介意重復(fù)；而在域中不允許重復(fù)時，我們傾向于使用MERGE。

5.2.開始查詢

現(xiàn)在我們有了一個圖，我們可以開始查詢它了。在Cypher中，我們總是從圖中一個或多個眾所周知的起點(diǎn)（稱為綁定節(jié)點(diǎn)）開始查詢。 Cypher使用MATCH和WHERE子句中提供的任何標(biāo)簽和屬性謂詞，以及索引和約束提供的元數(shù)據(jù)，來找到錨定我們的圖形模式的起點(diǎn)。

例如，如果我們想了解有關(guān)皇家劇院表演的更多信息，我們將從皇家劇院節(jié)點(diǎn)開始查詢，我們可以通過指定其Venue標(biāo)簽和name屬性來查找。但是，如果我們對某個人的評論更感興趣，則可以使用該人的節(jié)點(diǎn)作為查詢的起點(diǎn)，并在“User”標(biāo)簽和名稱屬性組合上進(jìn)行匹配。

假設(shè)我們想了解在紐卡斯?fàn)柣始覄≡喊l(fā)生的所有莎士比亞活動。這三件事—名為莎士比亞的作者，名為皇家劇院的場所和名為紐卡斯?fàn)柕某鞘小獮槲覀兊男虏樵兲峁┝似瘘c(diǎn)：

MATCH (theater:Venue {name:'Theatre Royal'}), (newcastle:City {name:'Newcastle'}), (bard:Author {lastname:'Shakespeare'})

該MATCH子句使用屬性key名稱和屬性值Theatre Royal標(biāo)識所有Venue節(jié)點(diǎn)，并將它們綁定到標(biāo)識符Theater。（如果該圖中有許多Theatre Royal節(jié)點(diǎn)，該怎么辦？我們將盡快處理。）下一步，我們找到代表紐卡斯?fàn)柺械墓?jié)點(diǎn)；我們將此節(jié)點(diǎn)綁定到標(biāo)識符newcastle。最后，與先前的莎士比亞查詢一樣，要查找莎士比亞節(jié)點(diǎn)本身，我們將查找標(biāo)簽為Author且姓氏屬性為Shakespeare的節(jié)點(diǎn)。我們將此查詢的結(jié)果綁定到bard。

從現(xiàn)在開始，在我們的查詢中，無論我們在模式中使用標(biāo)識符Theater，Newcastle和Bard的哪個位置，該模式都將錨定到與這三個標(biāo)識符關(guān)聯(lián)的實(shí)際節(jié)點(diǎn)上。實(shí)際上，此信息將查詢綁定到圖形的特定部分，從而為我們提供了起點(diǎn)，以匹配緊鄰的節(jié)點(diǎn)和關(guān)系中的模式。

索引與約束

索引有助于優(yōu)化查找特定節(jié)點(diǎn)的過程。

在大多數(shù)情況下，查詢圖表時，我們很樂意讓遍歷過程發(fā)現(xiàn)滿足我們信息目標(biāo)的節(jié)點(diǎn)和關(guān)系。通過遵循與特定圖形模式匹配的關(guān)系，我們會遇到有助于查詢結(jié)果的元素。但是，在某些情況下，我們需要選擇特定的節(jié)點(diǎn)，而不是遍歷整個過程發(fā)現(xiàn)它們。例如，確定遍歷的起始節(jié)點(diǎn)需要我們根據(jù)標(biāo)簽和屬性值的某種組合來找到一個或多個特定節(jié)點(diǎn)。

為了支持有效的節(jié)點(diǎn)查找，Cypher允許我們?yōu)槊總€標(biāo)簽和屬性組合創(chuàng)建索引。對于唯一屬性值，我們還可以指定確保唯一性的約束。在我們需要直接查找場所的莎士比亞圖表中，我們可以選擇基于標(biāo)記為Venue的所有節(jié)點(diǎn)的名稱屬性值來為其編制索引。為此的命令是：

CREATE INDEX ON :Venue(name)

為了確保所有國家/地區(qū)名稱都是唯一的，我們可以添加唯一性約束：

CREATE CONSTRAINT ON (c:Country) ASSERT c.name IS UNIQUE

在現(xiàn)有數(shù)據(jù)庫上，索引將在后臺填充，并且在建立索引后即可使用。

查找不需要索引，但是可以通過添加索引來提高其性能。??MATCH (theater:Venue {name:'Theatre Royal'})無論有沒有索引都可以使用。但是在擁有數(shù)千個場所的大型數(shù)據(jù)集中，索引將有助于提高性能。如果沒有索引，則選擇Theatre Royal作為查詢的起點(diǎn)，將使Neo4j掃描并過濾所有標(biāo)記為Venue的節(jié)點(diǎn)。

5.3.聲明要查找的信息模式

Cypher中的MATCH子句是神奇的地方。由于CREATE子句試圖使用ASCII藝術(shù)來傳達(dá)意圖以描述圖的所需狀態(tài)，因此MATCH子句使用相同的語法來描述要在數(shù)據(jù)庫中發(fā)現(xiàn)的模式。我們已經(jīng)研究了一個非常簡單的MATCH子句；現(xiàn)在我們來看一個更復(fù)雜的模式，它可以找到紐卡斯?fàn)柣始覄≡核猩勘葋喌谋硌?#xff1a;

MATCH (theater:Venue {name:'Theatre Royal'}),(newcastle:City {name:'Newcastle'}),(bard:Author {lastname:'Shakespeare'}),(newcastle)<-[:STREET|CITY*1..2]-(theater)<-[:VENUE]-()-[:PERFORMANCE_OF]->()-[:PRODUCTION_OF]->(play)<-[:WROTE_PLAY]-(bard) RETURN DISTINCT play.title AS play

這種MATCH模式使用了一些我們尚未遇到的語法元素。除了我們前面討論的錨定節(jié)點(diǎn)之外，它還使用模式節(jié)點(diǎn)，任意深度路徑和匿名節(jié)點(diǎn)。讓我們依次看一下其中的每個：

根據(jù)指定的標(biāo)簽和屬性值，將標(biāo)識符newcastle，Theater和bard錨定到圖中的實(shí)際節(jié)點(diǎn)。
如果我們的數(shù)據(jù)庫中有幾個皇家劇院(Theatre Royal)（例如，英國的普利茅斯，巴斯，溫徹斯特和諾里奇等城市都擁有皇家劇院），那么劇院將綁定到所有這些節(jié)點(diǎn)。為了將我們的模式限制為紐卡斯?fàn)柕幕始覄≡?Theatre Royal)，我們使用語法?<-[:STREET|CITY*1..2]-，這意味著劇院節(jié)點(diǎn)最多只能有兩個傳出的STREET and/or CITY關(guān)系從代表泰恩河畔紐卡斯?fàn)柺?#xff08;Newcastle-upon-Tyne）的節(jié)點(diǎn)出發(fā)。通過提供可變的深度路徑，我們允許使用相對較細(xì)粒度的地址層次結(jié)構(gòu)（例如，包括街道，地區(qū)或自治市鎮(zhèn)和城市）。
語法??(theater)<-[:VENUE]-() 使用匿名節(jié)點(diǎn)，因此括號為空。在了解數(shù)據(jù)的同時，我們希望匿名節(jié)點(diǎn)與性能匹配，但是由于我們對查詢或結(jié)果中其他位置的各個性能的詳細(xì)信息不感興趣，因此我們不會命名該節(jié)點(diǎn)或?qū)⑵浣壎ǖ?標(biāo)識符。
我們再次使用匿名節(jié)點(diǎn)將性能鏈接到生產(chǎn) ( ()-[:PERFORMANCE_OF]->() ) 。如果我們有興趣返回表演和作品的詳細(xì)信息，則可以將這些出現(xiàn)的匿名節(jié)點(diǎn)替換為標(biāo)識符：(performance)-[:PERFORMANCE_OF]->(production)
MATCH的其余部分是簡單的 (play)<-[:WROTE_PLAY]-(bard)? 節(jié)點(diǎn)到關(guān)系到節(jié)點(diǎn)模式匹配。這種模式確保我們只返回莎士比亞寫的戲劇。由于（play）已加入到匿名制作節(jié)點(diǎn)，并且通過該節(jié)點(diǎn)又加入了表演節(jié)點(diǎn)，因此我們可以安全地推斷它已經(jīng)在紐卡斯?fàn)柕幕始覄≡哼M(jìn)行了表演。在命名播放節(jié)點(diǎn)時，我們將其帶入范圍，以便稍后在查詢中使用它。

運(yùn)行此查詢將返回在紐卡斯?fàn)柣始覄≡哼M(jìn)行的所有莎士比亞戲劇：

如果我們對莎士比亞在皇家劇院的整個歷史感興趣，那很好，但是如果我們僅對特定的戲劇，作品或表演感興趣，我們就需要以某種方式來限制結(jié)果。

5.4.約束匹配

我們使用WHERE子句約束圖匹配。通過指定以下一項(xiàng)或多項(xiàng)，WHERE允許我們從結(jié)果中消除匹配的子圖：

在匹配的子圖中必須存在（或不存在）某些路徑。
該節(jié)點(diǎn)必須具有某些標(biāo)簽或與某些名稱的關(guān)系。
無論值如何，匹配節(jié)點(diǎn)和關(guān)系上的特定屬性都必須存在（或不存在）。
匹配的節(jié)點(diǎn)和關(guān)系上的某些屬性必須具有特定的值。
必須滿足其他謂詞的要求（例如，表演必須在特定日期或之前進(jìn)行）。

與描述結(jié)構(gòu)關(guān)系并為模式的各個部分分配標(biāo)識符的MATCH子句相比，WHERE約束了當(dāng)前的模式匹配。例如，讓我們想象一下，我們希望將結(jié)果的播放范圍限制在莎士比亞最后一個時期（通常被認(rèn)為始于1608年）。我們通過過濾匹配的WROTE_PLAY關(guān)系的year屬性來做到這一點(diǎn)。為了啟用此過濾，我們調(diào)整了MATCH子句，將WROTE_PLAY關(guān)系綁定到一個標(biāo)識符，我們將其稱為w（關(guān)系標(biāo)識符在冒號之前加一個關(guān)系名稱）。然后，我們添加WHERE子句，以對該關(guān)系的year屬性進(jìn)行過濾：

MATCH (theater:Venue {name:'Theatre Royal'}),(newcastle:City {name:'Newcastle'}),(bard:Author {lastname:'Shakespeare'}),(newcastle)<-[:STREET|CITY*1..2]-(theater)<-[:VENUE]-()-[:PERFORMANCE_OF]->()-[:PRODUCTION_OF]->(play)<-[w:WROTE_PLAY]-(bard) WHERE w.year > 1608 RETURN DISTINCT play.title AS play

添加此WHERE子句意味著，對于每個成功的匹配，數(shù)據(jù)庫都會檢查莎士比亞節(jié)點(diǎn)和匹配的劇本之間的WROTE_PLAY關(guān)系是否具有Year屬性，其年份值大于1608。與WROTE_PLAY關(guān)系的匹配如果年份值大于1608，則將通過測試; 這些戲劇將被包括在結(jié)果中。未通過測試的比賽將不包括在結(jié)果中。通過添加此子句，我們確保僅返回莎士比亞后期的演出：

+---------------+ | play | +---------------+ | "The Tempest" | +---------------+ 1 row

5.5.處理結(jié)果

借助Cypher的RETURN子句，我們可以對匹配的圖形數(shù)據(jù)執(zhí)行一些處理，然后再將其返回給執(zhí)行查詢的用戶（或應(yīng)用程序）。

正如我們在之前的查詢中所看到的，我們最簡單的方法就是返回找到的劇本：

RETURN DISTINCT play.title AS play

DISTINCT確保我們返回獨(dú)特的結(jié)果。由于每個劇本可以在同一個劇院中多次執(zhí)行，有時甚至在不同的作品中進(jìn)行，因此我們可以得到重復(fù)的劇本標(biāo)題。 DISTINCT過濾掉這些。

我們可以通過幾種方式來豐富此結(jié)果，包括聚合，排序，過濾和限制返回的數(shù)據(jù)。例如，如果我們只對符合條件的打法數(shù)量感興趣，則可以應(yīng)用count函數(shù)：

RETURN count(play)

如果要按演出次數(shù)對戲劇進(jìn)行排名，首先需要將MATCH子句中的PERFORMANCE_OF關(guān)系綁定到一個名為p的標(biāo)識符，然后我們可以對其進(jìn)行計數(shù)和排序：

MATCH (theater:Venue {name:'Theatre Royal'}),(newcastle:City {name:'Newcastle'}),(bard:Author {lastname:'Shakespeare'}),(newcastle)<-[:STREET|CITY*1..2]-(theater)<-[:VENUE]-()-[p:PERFORMANCE_OF]->()-[:PRODUCTION_OF]->(play)<-[:WROTE_PLAY]-(bard) RETURN play.title AS play, count(p) AS performance_count ORDER BY performance_count DESC

這里的RETURN子句使用標(biāo)識符p（綁定到MATCH子句中的PERFORMANCE_OF關(guān)系）對PERFORMANCE_OF關(guān)系的數(shù)量進(jìn)行計數(shù)，并將結(jié)果別名為performance_count。然后，它根據(jù)performance_count排序結(jié)果，并首先列出執(zhí)行最頻繁的播放：

+-------------------------------------+ | play | performance_count | +-------------------------------------+ | "Julius Caesar" | 2 | | "The Tempest" | 1 | +-------------------------------------+ 2 rows

5.6.查詢鏈接

在結(jié)束對Cypher的簡要介紹之前，需要了解另外一個有用的功能-WITH子句。有時候，一次MATCH做所有您想做的事是不切實(shí)際（或不可能）的。 WITH子句允許我們將多個匹配項(xiàng)鏈接在一起，并將上一個查詢部分的結(jié)果傳遞到下一個查詢中。在以下示例中，我們找到了莎士比亞寫的劇本，并根據(jù)寫劇的年份對它們進(jìn)行排序，最新的優(yōu)先。然后使用WITH，將結(jié)果通過管道傳遞到RETURN子句，該子句使用collect函數(shù)生成有限的播放標(biāo)題列表：

MATCH (bard:Author {lastname:'Shakespeare'})-[w:WROTE_PLAY]->(play) WITH play ORDER BY w.year DESC RETURN collect(play.title) AS plays

對我們的樣本圖執(zhí)行此查詢將產(chǎn)生以下結(jié)果：

+---------------------------------+ | plays | +---------------------------------+ | ["The Tempest","Julius Caesar"] | +---------------------------------+ 1 row

WITH可以用于將只讀子句與以寫為中心的SET操作分開。更普遍的是，WITH通過允許我們將單個復(fù)雜查詢分解為幾個更簡單的模式來幫助劃分和解決復(fù)雜查詢。

5.7.常見的建模陷阱

盡管圖建模是掌握問題域中復(fù)雜性的一種非常有表現(xiàn)力的方式，但是僅憑表現(xiàn)力并不能保證特定的圖適合目的。實(shí)際上，在有些情況下，甚至我們每天使用圖形的人都會犯錯。在本部分中，我們將研究出現(xiàn)問題的模型。這樣，我們將學(xué)習(xí)如何在建模工作中及早發(fā)現(xiàn)問題，以及如何解決這些問題。

5.7.1.電子郵件出處問題域

本示例涉及電子郵件通信的分析。溝通模式分析是一個經(jīng)典的圖形問題，涉及到查詢圖形以發(fā)現(xiàn)主題專家，關(guān)鍵影響者以及傳播信息的通信渠道。但是，在這種情況下，我們不是在尋找積極的榜樣（以專家的形式），而是在尋找流氓：也就是說，可疑的電子郵件通信模式會違反公司治理，甚至?xí)|犯法律。

5.7.2.明智的第一次迭代？

在分析領(lǐng)域時，我們了解了潛在的不法行為者用來掩蓋其足跡的所有聰明模式：使用盲目復(fù)制（BCC），使用別名-甚至與這些別名進(jìn)行對話以模仿實(shí)際業(yè)務(wù)涉眾之間的合法交互。基于此分析，我們生成了一個具有代表性的圖形模型，該模型似乎捕獲了所有相關(guān)實(shí)體及其活動。

為了說明這個早期模型，我們將使用Cypher的CREATE子句生成一些表示用戶和別名的節(jié)點(diǎn)。我們還將生成一個關(guān)系，該關(guān)系表明Alice是Bob的已知別名之一。（我們假設(shè)底層圖形數(shù)據(jù)庫正在為這些節(jié)點(diǎn)建立索引，以便我們以后可以查找它們并將它們用作查詢的起點(diǎn)。）以下是Cypher查詢，用于創(chuàng)建我們的第一個圖形：

CREATE (alice:User {username:'Alice'}),(bob:User {username:'Bob'}),(charlie:User {username:'Charlie'}),(davina:User {username:'Davina'}),(edward:User {username:'Edward'}),(alice)-[:ALIAS_OF]->(bob)

生成的圖形模型使我們很容易觀察到Alice是Bob的別名，如圖3-7所示。

現(xiàn)在，我們通過用戶交換的電子郵件將他們聚集在一起：

MATCH (bob:User {username:'Bob'}),(charlie:User {username:'Charlie'}),(davina:User {username:'Davina'}),(edward:User {username:'Edward'}) CREATE (bob)-[:EMAILED]->(charlie),(bob)-[:CC]->(davina),(bob)-[:BCC]->(edward)

乍一看，這似乎是對該域的合理忠實(shí)表示。每個子句都易于從左到右閱讀，從而通過了我們的一項(xiàng)非正式測試，以確保準(zhǔn)確性。例如，我們從圖表中可以看到“Bob通過電子郵件發(fā)送給Charlie”。只有在有必要確切確定潛在的不法行為Bob（以及他的另一個自我是Alice）交換的內(nèi)容時，該模型的局限性才會出現(xiàn)。我們可以看到Bob CC’d或?BCC’d有一些人，但我們看不到最重要的東西：電子郵件本身。

第一次建模嘗試產(chǎn)生了一個以Bob為中心的星形圖形。他的電子郵件，復(fù)制和盲目復(fù)制行為由從Bob延伸到代表他的郵件收件人的節(jié)點(diǎn)的關(guān)系表示。但是，如圖3-8所示，數(shù)據(jù)中最關(guān)鍵的元素，即實(shí)際的電子郵件，丟失了。

這種圖結(jié)構(gòu)是有損的，當(dāng)我們提出以下內(nèi)容時，這一事實(shí)變得明顯查詢：

MATCH (bob:User {username:'Bob'})-[e:EMAILED]->(charlie:User {username:'Charlie'}) RETURN e

此查詢返回Bob和Charlie之間的EMAILED關(guān)系（Bob發(fā)送給Charlie的每封電子郵件可能都有一個）。這告訴我們電子郵件已經(jīng)交換過，但是卻沒有告訴我們有關(guān)電子郵件本身的信息：

+----------------+ | e | +----------------+ | :EMAILED[1] {} | +----------------+ 1 row

我們可能認(rèn)為可以通過在EMAILED關(guān)系中添加屬性以表示電子郵件的屬性來糾正這種情況，但這只是時間的作用。即使將屬性附加到每個EMAILED關(guān)系中，我們?nèi)詫o法在EMAILED，CC和BCC關(guān)系之間建立關(guān)聯(lián)。也就是說，我們將無法說出復(fù)制了哪些電子郵件，復(fù)制了哪些電子郵件以及復(fù)制給了誰。

事實(shí)是，我們不經(jīng)意間犯了一個簡單的建模錯誤，這主要是由于英語使用不多而不是圖論的任何缺點(diǎn)造成的。我們?nèi)粘Ｊ褂玫恼Z言使我們專注于動詞“電子郵件”而不是電子郵件本身，因此，我們制作的模型缺乏真正的領(lǐng)域洞察力。

用英語，將短語“Bob sent an email to Charlie”縮寫為“Bob emailed Charlie.”很容易和方便。在大多數(shù)情況下，名詞（實(shí)際電子郵件）的丟失并不重要，因?yàn)橐鈭D仍然很清楚。但是，在我們的法證場景中，這些被遺忘的陳述是有問題的。意圖保持不變，但是Bob所發(fā)送的電子郵件的數(shù)量，內(nèi)容和收件人的詳細(xì)信息由于被折疊成EMAILED關(guān)系而丟失了，而不是被明確地建模為自身的節(jié)點(diǎn)。

5.7.3.第二次的魅力

要修復(fù)我們的有損模型，我們需要插入電子郵件節(jié)點(diǎn)以表示業(yè)務(wù)中交換的真實(shí)電子郵件，并擴(kuò)展我們的關(guān)系名稱集以涵蓋電子郵件支持的整個尋址字段。現(xiàn)在，而不是創(chuàng)建像這樣的有損結(jié)構(gòu)：

CREATE (bob)-[:EMAILED]->(charlie)

我們將改為創(chuàng)建更詳細(xì)的結(jié)構(gòu)，如下所示：

CREATE (email_1:Email {id:'1', content:'Hi Charlie, ... Kind regards, Bob'}),(bob)-[:SENT]->(email_1),(email_1)-[:TO]->(charlie),(email_1)-[:CC]->(davina),(email_1)-[:CC]->(alice),(email_1)-[:BCC]->(edward)

這導(dǎo)致了另一個星形圖形結(jié)構(gòu)，但是這次電子郵件處于中心位置，如圖3-9所示。

當(dāng)然，在真實(shí)的系統(tǒng)中，會有更多這樣的電子郵件，每個電子郵件都有自己復(fù)雜的交互網(wǎng)絡(luò)供我們探索。很容易想象，隨著時間的推移，隨著電子郵件服務(wù)器記錄交互，還會執(zhí)行更多的CREATE語句，就像這樣（為簡潔起見，我們省略了錨節(jié)點(diǎn)）：

CREATE (email_1:Email {id:'1', content:'email contents'}),(bob)-[:SENT]->(email_1),(email_1)-[:TO]->(charlie),(email_1)-[:CC]->(davina),(email_1)-[:CC]->(alice),(email_1)-[:BCC]->(edward); CREATE (email_2:Email {id:'2', content:'email contents'}),(bob)-[:SENT]->(email_2),(email_2)-[:TO]->(davina),(email_2)-[:BCC]->(edward); CREATE (email_3:Email {id:'3', content:'email contents'}),(davina)-[:SENT]->(email_3),(email_3)-[:TO]->(bob),(email_3)-[:CC]->(edward); CREATE (email_4:Email {id:'4', content:'email contents'}),(charlie)-[:SENT]->(email_4),(email_4)-[:TO]->(bob),(email_4)-[:TO]->(davina),(email_4)-[:TO]->(edward); CREATE (email_5:Email {id:'5', content:'email contents'}),(davina)-[:SENT]->(email_5),(email_5)-[:TO]->(alice),(email_5)-[:BCC]->(bob),(email_5)-[:BCC]->(edward);

這將導(dǎo)致我們在圖3-10中看到更復(fù)雜，更有趣的圖形。

現(xiàn)在，我們可以查詢此圖以識別潛在的可疑行為：

MATCH (bob:User {username:'Bob'})-[:SENT]->(email)-[:CC]->(alias),(alias)-[:ALIAS_OF]->(bob) RETURN email.id

在這里，我們檢索Bob抄送給他自己的別名之一的地方發(fā)送的所有電子郵件。與此模式匹配的所有電子郵件都表明流氓行為。而且由于Cypher和基礎(chǔ)圖形數(shù)據(jù)庫都具有圖形相似性，因此這些查詢（即使是在大型數(shù)據(jù)集上）也可以非?？焖俚剡\(yùn)行。該查詢返回以下結(jié)果：

+------------------------------------------+ | email | +------------------------------------------+ | Node[6]{id:"1",content:"email contents"} | +------------------------------------------+ 1 row

5.7.4.不斷發(fā)展的領(lǐng)域

與任何數(shù)據(jù)庫一樣，我們的圖形服務(wù)于一個可能隨著時間而發(fā)展的系統(tǒng)。那么當(dāng)圖演化時我們該怎么辦？我們怎么知道什么壞了，或者實(shí)際上，我們怎么知道某件事已經(jīng)壞了？事實(shí)是，我們無法完全避免在圖形數(shù)據(jù)庫中進(jìn)行遷移：就像任何數(shù)據(jù)存儲一樣，它們是生活中不可或缺的事實(shí)。但是在圖形數(shù)據(jù)庫中，它們通常要簡單得多。

在圖中，要添加新的事實(shí)或構(gòu)圖，我們傾向于添加新的節(jié)點(diǎn)和關(guān)系，而不是更改模型。使用新的關(guān)系添加到圖形不會影響任何現(xiàn)有查詢，并且是完全安全的。使用現(xiàn)有的關(guān)系類型來更改圖形，以及更改現(xiàn)有節(jié)點(diǎn)的屬性（不僅是屬性值）可能是安全的，但是我們需要運(yùn)行一組代表性的查詢，以確保在結(jié)構(gòu)化之后圖形仍然適合于目的變化。但是，這些活動與我們在常規(guī)數(shù)據(jù)庫操作期間執(zhí)行的動作完全相同，因此在圖形世界中，遷移實(shí)際上只是照常進(jìn)行。

至此，我們有了一個圖表，描述了誰發(fā)送和接收了電子郵件，以及電子郵件本身的內(nèi)容。但是，當(dāng)然，電子郵件的樂趣之一是收件人可以轉(zhuǎn)發(fā)或回復(fù)他們收到的電子郵件。這樣可以增加互動和知識共享，但是在某些情況下會泄漏重要的業(yè)務(wù)信息。由于我們正在尋找可疑的通信模式，因此我們也應(yīng)該考慮轉(zhuǎn)發(fā)和答復(fù)。

乍一看，似乎不需要使用數(shù)據(jù)庫遷移來更新我們的圖以支持我們的新用例。我們可以做的最簡單的添加就是將FORWARDED和EPLIED_TO關(guān)系添加到圖中，如圖3-11所示。這樣做不會影響任何先前存在的查詢，因?yàn)樗鼈儧]有經(jīng)過編碼以識別新的關(guān)系。

但是，這種方法很快被證明是不合適的。與我們最初使用EMAILED關(guān)系的方式幾乎相同，添加FORWARDED或REPLIED關(guān)系是幼稚和有損的。為了說明這一點(diǎn)，請考慮以下CREATE語句：

... MATCH (email:Email {id:'1234'}) CREATE (alice)-[:REPLIED_TO]->(email) CREATE (davina)-[:FORWARDED]->(email)-[:TO]->(charlie)

在第一個CREATE語句中，我們試圖記錄Alice回復(fù)特定電子郵件的事實(shí)。從左至右閱讀該陳述是合乎邏輯的，但這種情緒是有損的-我們無法確定愛麗絲是回信給所有電子郵件收件人還是直接回信給作者。我們所知道的是，已經(jīng)發(fā)送了一些答復(fù)。第二條語句從左到右也很讀：達(dá)維娜將電子郵件轉(zhuǎn)發(fā)給了查理。但是我們已經(jīng)使用TO關(guān)系來指示給定的電子郵件具有一個TO標(biāo)頭，用于標(biāo)識主要收件人。在這里重復(fù)使用TO使得無法分辨誰是收件人以及誰收到了電子郵件的轉(zhuǎn)發(fā)版本。

要解決此問題，我們必須考慮領(lǐng)域的基礎(chǔ)。回復(fù)電子郵件本身就是新的電子郵件，但它也是回復(fù)。換句話說，回復(fù)具有兩個角色，在圖中可以通過將兩個標(biāo)簽Email和Reply附加到回復(fù)節(jié)點(diǎn)來表示。無論回復(fù)是發(fā)給原始發(fā)件人，所有收件人還是子集，都可以使用相同的熟悉的TO，CC和BCC關(guān)系輕松建模，而原始電子郵件本身可以通過REPLY_TO關(guān)系進(jìn)行引用。這是一系列修改后的一系列寫法，它們是由多個電子郵件操作產(chǎn)生的（再次，我們省略了必要的節(jié)點(diǎn)錨定）：

CREATE (email_6:Email {id:'6', content:'email'}),(bob)-[:SENT]->(email_6),(email_6)-[:TO]->(charlie),(email_6)-[:TO]->(davina); CREATE (reply_1:Email:Reply {id:'7', content:'response'}),(reply_1)-[:REPLY_TO]->(email_6),(davina)-[:SENT]->(reply_1),(reply_1)-[:TO]->(bob),(reply_1)-[:TO]->(charlie); CREATE (reply_2:Email:Reply {id:'8', content:'response'}),(reply_2)-[:REPLY_TO]->(email_6),(bob)-[:SENT]->(reply_2),(reply_2)-[:TO]->(davina),(reply_2)-[:TO]->(charlie),(reply_2)-[:CC]->(alice); CREATE (reply_3:Email:Reply {id:'9', content:'response'}),(reply_3)-[:REPLY_TO]->(reply_1),(charlie)-[:SENT]->(reply_3),(reply_3)-[:TO]->(bob),(reply_3)-[:TO]->(davina); CREATE (reply_4:Email:Reply {id:'10', content:'response'}),(reply_4)-[:REPLY_TO]->(reply_3),(bob)-[:SENT]->(reply_4),(reply_4)-[:TO]->(charlie),(reply_4)-[:TO]->(davina);

這將在圖3-12中創(chuàng)建該圖，該圖顯示了眾多答復(fù)和逐項(xiàng)答復(fù)。

現(xiàn)在，很容易看到誰回復(fù)了鮑勃的原始電子郵件。首先，找到感興趣的電子郵件，然后與所有傳入的REPLY_TO關(guān)系（可能有多個答復(fù)）進(jìn)行匹配，然后從此處與傳入的SENT關(guān)系進(jìn)行匹配：這揭示了發(fā)件人。在Cypher中，這很容易表達(dá)。實(shí)際上，Cypher使得查找回復(fù)到回復(fù)的過程變得很容易，依此類推可以任意深度（盡管在這里我們將深度限制為四級）：

MATCH p=(email:Email {id:'6'})<-[:REPLY_TO*1..4]-(:Reply)<-[:SENT]-(replier) RETURN replier.username AS replier, length(p) - 1 AS depth ORDER BY depth

在這里，我們捕獲每個匹配的路徑，并將其綁定到標(biāo)識符p。然后，在RETURN子句中，計算答復(fù)鏈的長度（SENT關(guān)系減去1），并返回答復(fù)者的姓名和答復(fù)者的深度。此查詢返回以下結(jié)果：

+-------------------+ | replier | depth | +-------------------+ | "Davina" | 1 | | "Bob" | 1 | | "Charlie" | 2 | | "Bob" | 3 | +-------------------+ 4 rows

我們看到Davina和Bob都直接回復(fù)了Bob的原始電子郵件； Charlie回答了其中一項(xiàng)答復(fù)；然后Bob回復(fù)了其中一封回復(fù)。

轉(zhuǎn)發(fā)電子郵件的方式與此類似，可以將其視為新電子郵件，恰好包含原始電子郵件的某些文本。與回復(fù)情況一樣，我們明確地對新電子郵件建模。我們還會引用轉(zhuǎn)發(fā)郵件中的原始電子郵件，以便始終提供詳細(xì)而準(zhǔn)確的出處數(shù)據(jù)。如果轉(zhuǎn)發(fā)的郵件本身是轉(zhuǎn)發(fā)的，則同樣適用，依此類推。例如，如果愛麗絲(Alice)（鮑勃（Bob）的另一位自我）通過電子郵件向鮑勃（Bob）嘗試建立單獨(dú)的具體身份，然后Bob（希望進(jìn)行一些變通）將其轉(zhuǎn)發(fā)給查理（Charlie），然后查理（Charlie）將其轉(zhuǎn)發(fā)給達(dá)維納（Davina），我們實(shí)際上有三封電子郵件考慮。假設(shè)用戶（及其別名）已經(jīng)存在于數(shù)據(jù)庫中，在Cypher中，我們將審核信息寫入數(shù)據(jù)庫，如下所示：

CREATE (email_11:Email {id:'11', content:'email'}),(alice)-[:SENT]->(email_11)-[:TO]->(bob); CREATE (email_12:Email:Forward {id:'12', content:'email'}),(email_12)-[:FORWARD_OF]->(email_11),(bob)-[:SENT]->(email_12)-[:TO]->(charlie); CREATE (email_13:Email:Forward {id:'13', content:'email'}),(email_13)-[:FORWARD_OF]->(email_12),(charlie)-[:SENT]->(email_13)-[:TO]->(davina);

完成這些寫操作后，我們的數(shù)據(jù)庫將包含圖3-13所示的子圖。

使用此圖，我們可以確定轉(zhuǎn)發(fā)的電子郵件鏈的各種路徑。

MATCH (email:Email {id:'11'})<-[f:FORWARD_OF*]-(:Forward) RETURN count(f)

此查詢從給定的電子郵件開始，然后與轉(zhuǎn)發(fā)的電子郵件樹中所有傳入的FOR WARD_OF關(guān)系進(jìn)行任何深度的匹配。這些關(guān)系綁定到標(biāo)識符f。為了計算電子郵件被轉(zhuǎn)發(fā)的次數(shù)，我們使用Cypher的count函數(shù)計算與f綁定的FORWARD_OF關(guān)系的數(shù)量。在此示例中，我們看到原始電子郵件已轉(zhuǎn)發(fā)兩次：

+----------+ | count(f) | +----------+ | 2 | +----------+ 1 row

6.識別節(jié)點(diǎn)和關(guān)系

建模過程可以最好地概括為嘗試創(chuàng)建一個圖形結(jié)構(gòu)，以表達(dá)我們要針對我們的領(lǐng)域提出的問題。也就是說，設(shè)計可查詢性：

描述激發(fā)我們模型的客戶或最終用戶目標(biāo)。

將這些目標(biāo)重寫為我們的領(lǐng)域要問的問題。

確定出現(xiàn)在這些問題中的實(shí)體和關(guān)系。

將這些實(shí)體和關(guān)系轉(zhuǎn)換為Cypher路徑表達(dá)式。

使用類似于我們用來建模領(lǐng)域的路徑表達(dá)式，以圖形模式表達(dá)我們想以域模式問我們的領(lǐng)域的問題。

通過檢查用于描述領(lǐng)域的語言，我們可以非常快速地確定圖中的核心元素：

普通名詞成為標(biāo)簽：例如“ user”和“ email”成為標(biāo)簽User和Email。
帶對象的動詞成為關(guān)系名稱：例如，“sent”和“wrote”成為SENT和WROTE。
專有名詞（例如，人或公司的名稱）是指事物的一個實(shí)例，我們使用一個或多個屬性來捕獲該事物的屬性，將其建模為節(jié)點(diǎn)。

7.避免反模式

通常，不要將實(shí)體編碼為關(guān)系。使用關(guān)系來傳達(dá)有關(guān)實(shí)體之間如何關(guān)聯(lián)以及這些關(guān)系的質(zhì)量的語義。

通常，不要將實(shí)體編碼為關(guān)系。使用關(guān)系來傳達(dá)有關(guān)實(shí)體之間如何關(guān)聯(lián)以及這些關(guān)系的質(zhì)量的語義。域?qū)嶓w在語音中并不總是立即可見，因此我們必須仔細(xì)考慮我們實(shí)際處理的名詞。 Verbing是名詞將名詞轉(zhuǎn)換為動詞的語言習(xí)慣，通常可以隱藏名詞和相應(yīng)域?qū)嶓w的存在。技術(shù)和商業(yè)術(shù)語在此類新詞中尤為流行：如我們所見，我們互相“email”，而不是發(fā)送電子郵件，“google”獲取結(jié)果，而不是搜索Google。

同樣重要的是要認(rèn)識到圖是自然可加的結(jié)構(gòu)。很自然地添加有關(guān)域?qū)嶓w及其使用新節(jié)點(diǎn)和新關(guān)系的相互關(guān)系方面的事實(shí)，即使感覺好像我們正在向數(shù)據(jù)庫中充斥大量數(shù)據(jù)。通常，在寫入時嘗試合并數(shù)據(jù)元素以保持查詢時的效率是一種不好的做法。如果我們按照我們要對數(shù)據(jù)提出的問題進(jìn)行建模，則將出現(xiàn)域的準(zhǔn)確表示。有了這個數(shù)據(jù)模型，我們可以相信圖形數(shù)據(jù)庫在讀取時表現(xiàn)良好。

圖形數(shù)據(jù)庫即使存儲大量數(shù)據(jù)也能保持快速查詢時間。當(dāng)學(xué)習(xí)構(gòu)造我們的圖而不對它們進(jìn)行規(guī)范化時，學(xué)會信任我們的圖數(shù)據(jù)庫非常重要。

8.摘要

圖形數(shù)據(jù)庫使軟件專業(yè)人員可以使用圖形表示問題域，然后在運(yùn)行時持久保存并查詢該圖形。我們可以使用圖來清楚地描述問題域；圖數(shù)據(jù)庫然后允許我們以在域和數(shù)據(jù)之間保持高親和力的方式存儲此表示。此外，圖形建模消除了使用復(fù)雜數(shù)據(jù)管理代碼對數(shù)據(jù)進(jìn)行規(guī)范化和非規(guī)范化的需求。

但是，我們許多人對于使用圖進(jìn)行建模將是新手。我們創(chuàng)建的圖形應(yīng)易于查詢，同時避免混淆實(shí)體和操作-可能會丟失有用的領(lǐng)域知識的不良做法。盡管圖形建模沒有絕對的對與錯，但本章中的指南將幫助您創(chuàng)建可以在許多迭代中滿足系統(tǒng)需求的圖形數(shù)據(jù)，同時始終與代碼演進(jìn)保持同步。

了解了圖形數(shù)據(jù)建模之后，您現(xiàn)在可以考慮進(jìn)行圖形數(shù)據(jù)庫項(xiàng)目。在下一章中，我們將研究規(guī)劃和交付圖形數(shù)據(jù)庫解決方案所涉及的內(nèi)容。

總結(jié)

以上是生活随笔為你收集整理的Neo4j【有与无】【N3】使用图进行数据建模的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。

上一篇： jetson用什么编译器_Jetson
下一篇： DDOS攻击-压力测试工具webbenc