2020-10-06 01:21:28 +08:00
# 2. 資料模型與查詢語言
2020-10-06 09:25:46 +08:00
2020-10-06 01:21:28 +08:00
> 語言的邊界就是思想的邊界。
>
> —— 路德維奇·維特根斯坦， （ ）
>
-------------------
[TOC]
資料模型可能是軟體開發中最重要的部分了，因為它們的影響如此深遠：不僅僅影響著軟體的編寫方式，而且影響著我們的**解題思路**。
多數應用使用層層疊加的資料模型構建。對於每層資料模型的關鍵問題是：它是如何用低一層資料模型來**表示**的？例如：
1. 作為一名應用開發人員， （ ， ， ， ， ， ） ， ，
2. 當要儲存那些資料結構時， ， ，
3. 資料庫軟體的工程師選定如何以記憶體、磁碟或網路上的位元組來表示JSON/XML/關係/圖資料。這類表示形式使資料有可能以各種方式來查詢，搜尋，操縱和處理。
4. 在更低的層次上，硬體工程師已經想出了使用電流，光脈衝，磁場或者其他東西來表示位元組的方法。
一個複雜的應用程式可能會有更多的中間層次， ， ： （ ）
資料模型種類繁多，每個資料模型都帶有如何使用的設想。有些用法很容易，有些則不支援如此；有些操作執行很快，有些則表現很差；有些資料轉換非常自然，有些則很麻煩。
掌握一個數據模型需要花費很多精力（想想關係資料建模有多少本書）。即便只使用一個數據模型，不用操心其內部工作機制，構建軟體也是非常困難的。然而，因為資料模型對上層軟體的功能（能做什麼，不能做什麼）有著至深的影響，所以選擇一個適合的資料模型是非常重要的。
在本章中， （ ） ， ， ， ， （ ）
## 關係模型與文件模型
現在最著名的資料模型可能是SQL。它基於Edgar Codd在1970年提出的關係模型【1】： （ （
關係模型曾是一個理論性的提議， ， （ ）
關係資料庫起源於商業資料處理， ， ：
當時的其他資料庫迫使應用程式開發人員必須考慮資料庫內部的資料表示形式。關係模型致力於將上述實現細節隱藏在更簡潔的介面之後。
多年來， ， ， ， ，
隨著電腦越來越強大和互聯，它們開始用於日益多樣化的目的。關係資料庫非常成功地被推廣到業務資料處理的原始範圍之外更為廣泛的用例上。你今天在網上看到的大部分內容依舊是由關係資料庫來提供支援，無論是線上釋出，討論，社交網路，電子商務，遊戲，軟體即服務生產力應用程式等等內容。
### NoSQL的誕生
現在 - 2010年代， ， ， ， ， ， ， ， （ ）
採用NoSQL資料庫的背後有幾個驅動因素， ：
* 需要比關係資料庫更好的可擴充套件性，包括非常大的資料集或非常高的寫入吞吐量
* 相比商業資料庫產品，免費和開源軟體更受偏愛。
* 關係模型不能很好地支援一些特殊的查詢操作
* 受挫於關係模型的限制性，
不同的應用程式有不同的需求，一個用例的最佳技術選擇可能不同於另一個用例的最佳技術選擇。因此，在可預見的未來，關係資料庫似乎可能會繼續與各種非關係資料庫一起使用 - 這種想法有時也被稱為**混合持久化（ ）
### 物件關係不匹配
目前大多數應用程式開發都使用面向物件的程式語言來開發， ： ， ， ， ， （ ）
[^i]: 一個從電子學借用的術語。每個電路的輸入和輸出都有一定的阻抗（交流電阻）。當你將一個電路的輸出連線到另一個電路的輸入時，如果兩個電路的輸出和輸入阻抗匹配，則連線上的功率傳輸將被最大化。阻抗不匹配會導致訊號反射及其他問題。
像ActiveRecord和Hibernate這樣的 **物件關係對映（ ） 框架可以減少這個轉換層所需的樣板程式碼的數量，但是它們不能完全隱藏這兩個模型之間的差異。
2020-10-06 09:25:46 +08:00
2020-10-06 01:21:28 +08:00
**圖2-1 使用關係型模式來表示領英簡介**
2020-10-06 09:25:46 +08:00
例如，[圖2-1](../img/fig2-1.png)展示瞭如何在關係模式中表示簡歷（ ） ， ， ， ， ：
2020-10-06 01:21:28 +08:00
2020-10-06 09:25:46 +08:00
* 傳統SQL模型（ ： ） ， ， ， ，
2020-10-06 01:21:28 +08:00
* 後續的SQL標準增加了對結構化資料型別和XML資料的支援;這允許將多值資料儲存在單行內， ， ， ， ，
* 第三種選擇是將職業， ， ， ，
對於一個像簡歷這樣自包含文件的資料結構而言， ： （ ， ， ）
**例2-1. 用JSON文件表示一個LinkedIn簡介**
```json
{
"user_id": 251,
"first_name": "Bill",
"last_name": "Gates",
"summary": "Co-chair of the Bill & Melinda Gates... Active blogger.",
"region_id": "us:91",
"industry_id": 131,
"photo_url": "/p/7/000/253/05b/308dd6e.jpg",
"positions": [
{
"job_title": "Co-chair",
"organization": "Bill & Melinda Gates Foundation"
},
{
"job_title": "Co-founder, Chairman",
"organization": "Microsoft"
}
],
"education": [
{
"school_name": "Harvard University",
"start": 1973,
"end": 1975
},
{
"school_name": "Lakeside School, Seattle",
"start": null,
"end": null
}
],
"contact_info": {
"blog": "http://thegatesnotes.com",
"twitter": "http://twitter.com/BillGates"
}
}
```
有一些開發人員認為JSON模型減少了應用程式程式碼和儲存層之間的阻抗不匹配。不過， ，
2020-10-06 09:25:46 +08:00
JSON表示比[圖2-1](../img/fig2-1.png)中的多表模式具有更好的**區域性性（ ） ） ， ， ，
2020-10-06 01:21:28 +08:00
2020-10-06 09:25:46 +08:00
從使用者簡介檔案到使用者職位， ， ， （
2020-10-06 01:21:28 +08:00
2020-10-06 09:25:46 +08:00
2020-10-06 01:21:28 +08:00
**圖2-2 一對多關係構建了一個樹結構**
### 多對一和多對多的關係
在上一節的[例2-1]()中，`region_id`和`industry_id`是以ID， ？
如果使用者介面用一個自由文字欄位來輸入區域和行業，那麼將他們儲存為純文字字串是合理的。另一方式是給出地理區域和行業的標準化的列表，並讓使用者從下拉列表或自動填充器中進行選擇，其優勢如下：
* 各個簡介之間樣式和拼寫統一
* 避免歧義（例如，如果有幾個同名的城市）
* 易於更新——名稱只儲存在一個地方，如果需要更改（例如，由於政治事件而改變城市名稱），很容易進行全面更新。
* 本地化支援——當網站翻譯成其他語言時，標準化的列表可以被本地化，使得地區和行業可以使用使用者的語言來顯示
* 更好的搜尋——例如， ， （ ）
儲存ID還是文字字串， **副本（ ） 問題。當使用ID時， （ ： ） ， （ ） ，
使用ID的好處是， ， ： ， ， ， （ ， ） **規範化（ ） 的關鍵思想。[^ii]
[^ii]: 關於關係模型的文獻區分了幾種不同的規範形式，但這些區別幾乎沒有實際意義。一個經驗法則是，如果重複儲存了可以儲存在一個地方的值，則模式就不是**規範化（ ）
> 資料庫管理員和開發人員喜歡爭論規範化和非規範化，讓我們暫時保留判斷吧。在本書的[第三部分](part-iii.md)，我們將回到這個話題，探討系統的方法用以處理快取，非規範化和衍生資料。
不幸的是， （ ， ） ， ， ， ， ，
[^iii]: 在撰寫本文時， ， ，
如果資料庫本身不支援連線，則必須在應用程式程式碼中透過對資料庫進行多個查詢來模擬連線。（在這種情況中，地區和行業的列表可能很小，改動很少，應用程式可以簡單地將其儲存在記憶體中。不過，執行連線的工作從資料庫被轉移到應用程式程式碼上。
此外，即便應用程式的最初版本適合無連線的文件模型，隨著功能新增到應用程式中，資料會變得更加互聯。例如，考慮一下對簡歷例子進行的一些修改：
***組織和學校作為實體***
2020-10-06 09:25:46 +08:00
在前面的描述中，`organization`（使用者工作的公司）和`school_name`（他們學習的地方）只是字串。也許他們應該是對實體的引用呢？然後，每個組織，學校或大學都可以擁有自己的網頁（標識，新聞提要等）。每個簡歷可以連結到它所提到的組織和學校，並且包括他們的圖示和其他資訊（參見[圖2-3](../img/fig2-3.png)， ）
2020-10-06 01:21:28 +08:00
***推薦***
假設你想新增一個新的功能：一個使用者可以為另一個使用者寫一個推薦。在使用者的簡歷上顯示推薦，並附上推薦使用者的姓名和照片。如果推薦人更新他們的照片，那他們寫的任何建議都需要顯示新的照片。因此，推薦應該擁有作者個人簡介的引用。
2020-10-06 09:25:46 +08:00
2020-10-06 01:21:28 +08:00
**圖2-3 公司名不僅是字串， （ ）
2020-10-06 09:25:46 +08:00
[圖2-4 ](../img/fig2-4.png )闡明瞭這些新功能需要如何使用多對多關係。每個虛線矩形內的資料可以分組成一個文件，但是對單位，學校和其他使用者的引用需要表示成引用，並且在查詢時需要連線。
2020-10-06 01:21:28 +08:00
2020-10-06 09:25:46 +08:00
2020-10-06 01:21:28 +08:00
**圖2-4 使用多對多關係擴充套件簡歷**
### 文件資料庫是否在重蹈覆轍？
在多對多的關係和連線已常規用在關係資料庫時， ： ， ，
20世紀70年代最受歡迎的業務資料處理資料庫是IBM的資訊管理系統（ ） ， ， ，
2020-10-06 09:25:46 +08:00
IMS的設計中使用了一個相當簡單的資料模型， （ ） ， ，
2020-10-06 01:21:28 +08:00
同文檔資料庫一樣， ， ， （ ）
那時人們提出了各種不同的解決方案來解決層次模型的侷限性。其中最突出的兩個是**關係模型（ ） （ ， ） （ ） （ ， ）
那兩個模式解決的問題與當前的問題相關，因此值得簡要回顧一下那場辯論。
#### 網路模型
網路模型由一個稱為資料系統語言會議（ ） ，
CODASYL模型是層次模型的推廣。在層次模型的樹結構中， ； ， ， ，
網路模型中記錄之間的連結不是外來鍵，而更像程式語言中的指標（同時仍然儲存在磁碟上）。訪問記錄的唯一方法是跟隨從根記錄起沿這些鏈路所形成的路徑。這被稱為**訪問路徑（ ）
最簡單的情況下，訪問路徑類似遍歷連結串列：從列表頭開始，每次檢視一條記錄，直到找到所需的記錄。但在多對多關係的情況中，數條不同的路徑可以到達相同的記錄，網路模型的程式設計師必須跟蹤這些不同的訪問路徑。
CODASYL中的查詢是透過利用遍歷記錄列和跟隨訪問路徑表在資料庫中移動遊標來執行的。如果記錄有多個父結點（ ） ， ，
儘管手動選擇訪問路徑夠能最有效地利用20世紀70年代非常有限的硬體功能（ ， ） ， ， ， ， ，
#### 關係模型
相比之下，關係模型做的就是將所有的資料放在光天化日之下：一個 **關係（表）** 只是一個 **元組（行）** 的集合，僅此而已。如果你想讀取資料，它沒有迷宮似的巢狀結構，也沒有複雜的訪問路徑。你可以選中符合任意條件的行，讀取表中的任何或所有行。你可以透過指定某些列作為匹配關鍵字來讀取特定行。你可以在任何表中插入一個新的行，而不必擔心與其他表的外來鍵關係[^iv]。
[^iv]: 外來鍵約束允許對修改約束， ， ， ，
在關係資料庫中，查詢最佳化器自動決定查詢的哪些部分以哪個順序執行，以及使用哪些索引。這些選擇實際上是“訪問路徑”，但最大的區別在於它們是由查詢最佳化器自動生成的，而不是由程式設計師生成，所以我們很少需要考慮它們。
如果想按新的方式查詢資料，你可以宣告一個新的索引，查詢會自動使用最合適的那些索引。無需更改查詢來利用新的索引。（請參閱“[用於資料的查詢語言](#用於資料的查詢語言)”。）關係模型因此使新增應用程式新功能變得更加容易。
關係資料庫的查詢最佳化器是複雜的， ： ， ，
#### 與文件資料庫相比
在一個方面，文件資料庫還原為層次模型：在其父記錄中儲存巢狀記錄（[圖2-1]()中的一對多關係，如`positions`，
但是，在表示多對一和多對多的關係時，關係資料庫和文件資料庫並沒有根本的不同：在這兩種情況下，相關專案都被一個唯一的識別符號引用，這個識別符號在關係模型中被稱為**外來鍵**，在文件模型中稱為**文件引用**【9】。該識別符號在讀取時透過連線或後續查詢來解析。迄今為止，
### 關係型資料庫與文件資料庫在今日的對比
將關係資料庫與文件資料庫進行比較時，可以考慮許多方面的差異，包括它們的容錯屬性（參閱[第5章](ch5.md)）和處理併發性（參閱[第7章](ch7.md)）。本章將只關注資料模型中的差異。
支援文件資料模型的主要論據是架構靈活性，因區域性性而擁有更好的效能，以及對於某些應用程式而言更接近於應用程式使用的資料結構。關係模型透過為連線提供更好的支援以及支援多對一和多對多的關係來反擊。
#### 哪個資料模型更方便寫程式碼？
2020-10-06 09:25:46 +08:00
如果應用程式中的資料具有類似文件的結構（即，一對多關係樹，通常一次性載入整個樹），那麼使用文件模型可能是一個好主意。將類似文件的結構分解成多個表（如[圖2-1](../img/fig2-1.png)中的`positions`，
2020-10-06 01:21:28 +08:00
文件模型有一定的侷限性： ， ， （ ） ， ，
文件資料庫對連線的糟糕支援也許或也許不是一個問題， ， ，
但是， ， ， ， ， ， ，
很難說在一般情況下哪個資料模型讓應用程式程式碼更簡單；它取決於資料項之間存在的關係種類。對於高度相聯的資料，選用文件模型是糟糕的，選用關係模型是可接受的，而選用圖形模型（參見“[圖資料模型](#圖資料模型)”）是最自然的。
#### 文件模型中的架構靈活性
大多數文件資料庫以及關係資料庫中的JSON支援都不會強制文件中的資料採用何種模式。關係資料庫的XML支援通常帶有可選的模式驗證。沒有模式意味著可以將任意的鍵和值新增到文件中， ，
文件資料庫有時稱為**無模式（ ） ， ， ， （ ） （ ） （ ， ， ）
讀時模式類似於程式語言中的動態（ ） ， （ ） ， ，
在應用程式想要改變其資料格式的情況下， ， ， ， ， ：
```go
if (user & & user.name & & !user.first_name) {
// Documents written before Dec 8, 2013 don't have first_name
user.first_name = user.name.split(" ")[0];
}
```
另一方面，在“靜態型別”資料庫模式中，通常會執行以下 **遷移（ ） 操作：
```sql
ALTER TABLE users ADD COLUMN first_name text;
UPDATE users SET first_name = split_part(name, ' ', 1); -- PostgreSQL
UPDATE users SET first_name = substring_index(name, ' ', 1); -- MySQL
```
模式變更的速度很慢，而且要求停運。它的這種壞名譽並不是完全應得的：大多數關係資料庫系統可在幾毫秒內執行`ALTER TABLE`語句。MySQL是一個值得注意的例外， ， ，
大型表上執行`UPDATE`語句在任何資料庫上都可能會很慢，因為每一行都需要重寫。要是不可接受的話，應用程式可以將`first_name`設定為預設值`NULL`，並在讀取時再填充，就像使用文件資料庫一樣。
當由於某種原因（例如，資料是異構的）集合中的專案並不都具有相同的結構時,讀時模式更具優勢。例如，如果：
* 存在許多不同型別的物件，將每種型別的物件放在自己的表中是不現實的。
* 資料的結構由外部系統決定。你無法控制外部系統且它隨時可能變化。
在上述情況下，模式的壞處遠大於它的幫助，無模式文件可能是一個更加自然的資料模型。但是，要是所有記錄都具有相同的結構，那麼模式是記錄並強制這種結構的有效機制。第四章將更詳細地討論模式和模式演化。
2020-10-10 19:46:40 +08:00
#### 查詢的資料區域性
2020-10-06 01:21:28 +08:00
2020-10-10 19:46:40 +08:00
文件通常以單個連續字串形式進行儲存， ， （ ） （ ， ） ， （
2020-10-06 01:21:28 +08:00
區域性性僅僅適用於同時需要文件絕大部分內容的情況。資料庫通常需要載入整個文件， ， ， ， ，
2020-10-10 19:46:40 +08:00
值得指出的是， ， ， （ ） **多表索引叢集表（ ） 的類似特性【28】。Bigtable資料模型（ ） **列族（ ） 概念與管理區域性性的目的類似【29】。
2020-10-06 01:21:28 +08:00
在[第3章](ch3.md)將還會看到更多關於區域性性的內容。
#### 文件和關係資料庫的融合
自2000年代中期以來， （ ） ，
從9.3版本開始的PostgreSQL 【8】， ，
在文件資料庫中， ， （ ， ， ， ）
隨著時間的推移，關係資料庫和文件資料庫似乎變得越來越相似，這是一件好事：資料模型相互補充[^v]，如果一個數據庫能夠處理類似文件的資料，並能夠對其執行關係查詢，那麼應用程式就可以使用最符合其需求的功能組合。
關係模型和文件模型的混合是未來資料庫一條很好的路線。
[^v]: Codd對關係模型【1】的原始描述實際上允許在關係模式中與JSON文件非常相似。他稱之為**非簡單域（ ） ， ， （ ） ， ，
## 資料查詢語言
當引入關係模型時， ： **宣告式** 查詢語言， **命令式** 程式碼來查詢資料庫。那是什麼意思？
許多常用的程式語言是命令式的。例如，給定一個動物物種的列表，返回列表中的鯊魚可以這樣寫：
```js
function getSharks() {
var sharks = [];
for (var i = 0; i < animals.length ; i + + ) {
if (animals[i].family === "Sharks") {
sharks.push(animals[i]);
}
}
return sharks;
}
```
在關係代數中：
$$
sharks = σ
$$
σ（希臘字母西格瑪）是選擇運算子，只返回符合條件的動物，`family="shark"`。
定義SQL時， ：
```sql
SELECT * FROM animals WHERE family ='Sharks';
```
命令式語言告訴計算機以特定順序執行某些操作。可以想象一下，逐行地遍歷程式碼，評估條件，更新變數，並決定是否再迴圈一遍。
在宣告式查詢語言（ ） ，
宣告式查詢語言是迷人的， ， ，
例如，在本節開頭所示的命令程式碼中，動物列表以特定順序出現。如果資料庫想要在後臺回收未使用的磁碟空間，則可能需要移動記錄，這會改變動物出現的順序。資料庫能否安全地執行，而不會中斷查詢？
SQL示例不確保任何特定的順序， ，
最後， ， ， ， ， ， ，
### Web上的宣告式查詢
宣告式查詢語言的優勢不僅限於資料庫。為了說明這一點， ：
假設你有一個關於海洋動物的網站。使用者當前正在檢視鯊魚頁面，因此你將當前所選的導航專案“鯊魚”標記為當前選中專案。
```html
< ul >
< li class = "selected" >
< p > Sharks< / p >
< ul >
< li > Great White Shark< / li >
< li > Tiger Shark< / li >
< li > Hammerhead Shark< / li >
< / ul >
< / li >
< li > < p > Whales< / p >
< ul >
< li > Blue Whale< / li >
< li > Humpback Whale< / li >
< li > Fin Whale< / li >
< / ul >
< / li >
< / ul >
```
現在想讓當前所選頁面的標題具有一個藍色的背景， ：
```css
li.selected > p {
background-color: blue;
}
```
這裡的CSS選擇器`li.selected> p`聲明瞭我們想要應用藍色樣式的元素的模式：即其直接父元素是具有`selected`CSS類的`< li > `元素的所有`< p > `元素。示例中的元素`< p > Sharks < / p > `匹配此模式，但`< p > Whales < / p > `不匹配，因為其`< li > `父元素缺少`class =“selected”`。
如果使用XSL而不是CSS， ：
```xml
< xsl:template match = "li[@class='selected']/p" >
< fo:block background-color = "blue" >
< xsl:apply-templates / >
< / fo:block >
< / xsl:template >
```
這裡的XPath表示式`li[@class='selected']/p`相當於上例中的CSS選擇器`li.selected> p`。CSS和XSL的共同之處在於，
想象一下， ， **文件物件模型（ ） API， ：
```js
var liElements = document.getElementsByTagName("li");
for (var i = 0; i < liElements.length ; i + + ) {
if (liElements[i].className === "selected") {
var children = liElements[i].childNodes;
for (var j = 0; j < children.length ; j + + ) {
var child = children[j];
if (child.nodeType === Node.ELEMENT_NODE & & child.tagName === "P") {
child.setAttribute("style", "background-color: blue");
}
}
}
}
```
這段JavaScript程式碼命令式地將元素設定為藍色背景， ， ， ：
* 如果選定的類被移除（例如，因為使用者點選了不同的頁面），即使程式碼重新執行，藍色背景也不會被移除 - 因此該專案將保持突出顯示， ，
* 如果你想要利用新的API（ （ ） ， ，
在Web瀏覽器中， ， ，
[^vi]: vi ，
### MapReduce查詢
MapReduce是一個由Google推廣的程式設計模型， （ ） ，
MapReduce將[第10章](ch10.md)中有更詳細的描述。現在我們將簡要討論一下MongoDB使用的模型。
MapReduce既不是一個宣告式的查詢語言， ， ： ，
最好舉例來解釋MapReduce模型。假設你是一名海洋生物學家， ， ，
在PostgreSQL中， ：
```sql
SELECT
date_trunc('month', observation_timestamp) AS observation_month,
sum(num_animals) AS total_animals
FROM observations
WHERE family = 'Sharks'
GROUP BY observation_month;
```
`date_trunc('month'， 函式用於確定包含`timestamp`的日曆月份，並返回代表該月份開始的另一個時間戳。換句話說，它將時間戳舍入成最近的月份。
這個查詢首先過濾觀察記錄，以只顯示鯊魚家族的物種，然後根據它們發生的日曆月份對觀察記錄果進行分組，最後將在該月的所有觀察記錄中看到的動物數目加起來。
同樣的查詢用MongoDB的MapReduce功能可以按如下來表述：
```js
db.observations.mapReduce(function map() {
var year = this.observationTimestamp.getFullYear();
var month = this.observationTimestamp.getMonth() + 1;
emit(year + "-" + month, this.numAnimals);
},
function reduce(key, values) {
return Array.sum(values);
},
{
query: {
family: "Sharks"
},
out: "monthlySharkReport"
});
```
* 可以宣告式地指定只考慮鯊魚種類的過濾器（ ）
* 每個匹配查詢的文件都會呼叫一次JavaScript函式`map`，將`this`設定為文件物件。
* `map` 函式發出一個鍵（包括年份和月份的字串，如`"2013-12"`或`"2014-1"`）和一個值（該觀察記錄中的動物數量）。
* `map` 發出的鍵值對按鍵來分組。對於具有相同鍵（即，相同的月份和年份）的所有鍵值對，呼叫一次`reduce`函式。
* `reduce` 函式將特定月份內所有觀測記錄中的動物數量相加。
* 將最終的輸出寫入到`monthlySharkReport`集合中。
例如，假設`observations`集合包含這兩個文件：
```json
{
observationTimestamp: Date.parse( "Mon, 25 Dec 1995 12:34:56 GMT"),
family: "Sharks",
species: "Carcharodon carcharias",
numAnimals: 3
{
}
observationTimestamp: Date.parse("Tue, 12 Dec 1995 16:17:18 GMT"),
family: "Sharks",
species: "Carcharias taurus",
numAnimals: 4
}
```
對每個文件都會呼叫一次`map`函式，結果將是`emit("1995-12",3)`和`emit("1995-12",4)`。隨後，以`reduce("1995-12",[3,4])`呼叫`reduce`函式，將返回`7`。
map和reduce函式在功能上有所限制： ， ， ， ， ， ： ， ，
MapReduce是一個相當底層的程式設計模型， （ ） ， ， ，
能夠在查詢中使用JavaScript程式碼是高階查詢的一個重要特性， ，
MapReduce的一個可用性問題是， ， ， ， ：
```js
db.observations.aggregate([
{ $match: { family: "Sharks" } },
{ $group: {
_id: {
year: { $year: "$observationTimestamp" },
month: { $month: "$observationTimestamp" }
},
totalAnimals: { $sum: "$numAnimals" } }}
]);
```
聚合管道語言與SQL的子集具有類似表現力， ，
## 圖資料模型
如我們之前所見，多對多關係是不同資料模型之間具有區別性的重要特徵。如果你的應用程式大多數的關係是一對多關係（樹狀結構化資料），或者大多數記錄之間不存在關係，那麼使用文件模型是合適的。
但是，要是多對多關係在你的資料中很常見呢？關係模型可以處理多對多關係的簡單情況，但是隨著資料之間的連線變得更加複雜，將資料建模為圖形顯得更加自然。
一個圖由兩種物件組成：**頂點（ ） （ ） （ ） （ ） （ （ ） （ ）
***社交圖譜***
頂點是人，邊指示哪些人彼此認識。
***網路圖譜***
頂點是網頁，
***公路或鐵路網路***
頂點是交叉路口，邊線代表它們之間的道路或鐵路線。
可以將那些眾所周知的演算法運用到這些圖上： ， ， ，
在剛剛給出的例子中， （ ， ） ， ： ， ， ， ： ， ， ， ， ， ， ，
2020-10-06 09:25:46 +08:00
在本節中，我們將使用[圖2-5](../img/fig2-5.png)所示的示例。它可以從社交網路或系譜資料庫中獲得： ， ，
2020-10-06 01:21:28 +08:00
2020-10-06 09:25:46 +08:00
2020-10-06 01:21:28 +08:00
**圖2-5 圖資料結構示例（框代表頂點，箭頭代表邊）**
有幾種不同但相關的方法用來構建和查詢圖表中的資料。在本節中， （ ， ） （ ） （ ， ） ： ， ， （
### 屬性圖
在屬性圖模型中，每個**頂點（ ）
* 唯一的識別符號
* 一組 **出邊（ ）
* 一組 **入邊（ ）
* 一組屬性（鍵值對）
每條 **邊（ ） 包括：
* 唯一識別符號
* **邊的起點/尾部頂點（ ）
* **邊的終點/頭部頂點（ ）
* 描述兩個頂點之間關係型別的標籤
* 一組屬性（鍵值對）
可以將圖儲存看作由兩個關係表組成：一個儲存頂點，另一個儲存邊，如[例2-2]()所示（ ） ； ，
**例2-2 使用關係模式來表示屬性圖**
```sql
CREATE TABLE vertices (
vertex_id INTEGER PRIMARY KEY,
properties JSON
);
CREATE TABLE edges (
edge_id INTEGER PRIMARY KEY,
tail_vertex INTEGER REFERENCES vertices (vertex_id),
head_vertex INTEGER REFERENCES vertices (vertex_id),
label TEXT,
properties JSON
);
CREATE INDEX edges_tails ON edges (tail_vertex);
CREATE INDEX edges_heads ON edges (head_vertex);
```
關於這個模型的一些重要方面是：
1. 任何頂點都可以有一條邊連線到任何其他頂點。沒有模式限制哪種事物可不可以關聯。
2. 給定任何頂點，可以高效地找到它的入邊和出邊，從而遍歷圖，即沿著一系列頂點的路徑前後移動。（這就是為什麼[例2-2]()在`tail_vertex`和`head_vertex`列上都有索引的原因。）
3. 透過對不同型別的關係使用不同的標籤，可以在一個圖中儲存幾種不同的資訊，同時仍然保持一個清晰的資料模型。
2020-10-06 09:25:46 +08:00
這些特性為資料建模提供了很大的靈活性，如[圖2-5](../img/fig2-5.png)所示。圖中顯示了一些傳統關係模式難以表達的事情， （ ， ） ， （ ） ， （ ， ）
2020-10-06 01:21:28 +08:00
你可以想象延伸圖還能包括許多關於Lucy和Alain， ， （ ， ） ， ， ， ， ： ，
### Cypher查詢語言
Cypher是屬性圖的宣告式查詢語言， （ ， ）
2020-10-06 09:25:46 +08:00
[例2-3]()顯示了將[圖2-5](../img/fig2-5.png)的左邊部分插入圖形資料庫的Cypher查詢。可以類似地新增圖的其餘部分， （ ） ： （ ）
2020-10-06 01:21:28 +08:00
**例2-3 將圖2-5中的資料子集表示為Cypher查詢**
```cypher
CREATE
(NAmerica:Location {name:'North America', type:'continent'}),
(USA:Location {name:'United States', type:'country' }),
(Idaho:Location {name:'Idaho', type:'state' }),
(Lucy:Person {name:'Lucy' }),
(Idaho) -[:WITHIN]-> (USA) -[:WITHIN]-> (NAmerica),
(Lucy) -[:BORN_IN]-> (Idaho)
```
2020-10-06 09:25:46 +08:00
當[圖2-5](../img/fig2-5.png)的所有頂點和邊被新增到資料庫後，讓我們提些有趣的問題：例如，找到所有從美國移民到歐洲的人的名字。更確切地說，這裡我們想要找到符合下麵條件的所有頂點，並且返回這些頂點的`name`屬性：該頂點擁有一條連到美國任一位置的`BORN_IN`邊，和一條連到歐洲的任一位置的`LIVING_IN`邊。
2020-10-06 01:21:28 +08:00
[例2-4]()展示瞭如何在Cypher中表達這個查詢。在MATCH子句中使用相同的箭頭符號來查詢圖中的模式：
**例2-4 查詢所有從美國移民到歐洲的人的Cypher查詢：
```cypher
MATCH
(person) -[:BORN_IN]-> () -[:WITHIN*0..]-> (us:Location {name:'United States'}),
(person) -[:LIVES_IN]-> () -[:WITHIN*0..]-> (eu:Location {name:'Europe'})
RETURN person.name
```
查詢按如下來解讀：
> 找到滿足以下兩個條件的所有頂點（ ） ：
> 1. `person`頂點擁有一條到某個頂點的`BORN_IN`出邊。從那個頂點開始，沿著一系列`WITHIN`出邊最終到達一個型別為`Location`，
>
> 2. `person`頂點還擁有一條`LIVES_IN`出邊。沿著這條邊，可以透過一系列`WITHIN`出邊最終到達一個型別為`Location`，
>
> 對於這樣的`Person`頂點，返回其`name`屬性。
執行這條查詢可能會有幾種可行的查詢路徑。這裡給出的描述建議首先掃描資料庫中的所有人，檢查每個人的出生地和居住地，然後只返回符合條件的那些人。
等價地，也可以從兩個`Location`頂點開始反向地查詢。假如`name`屬性上有索引，則可以高效地找到代表美國和歐洲的兩個頂點。然後，沿著所有`WITHIN`入邊，可以繼續查找出所有在美國和歐洲的位置（州，地區，城市等）。最後，查找出那些可以由`BORN_IN`或`LIVES_IN`入邊到那些位置頂點的人。
通常對於宣告式查詢語言來說，在編寫查詢語句時，不需要指定執行細節：查詢最佳化程式會自動選擇預測效率最高的策略，因此你可以繼續編寫應用程式的其他部分。
### SQL中的圖查詢
[例2-2]()建議在關係資料庫中表示圖資料。但是， ， ？
答案是肯定的，但有些困難。在關係資料庫中，你通常會事先知道在查詢中需要哪些連線。在圖查詢中，你可能需要在找到待查詢的頂點之前，遍歷可變數量的邊。也就是說，連線的數量事先並不確定。
在我們的例子中，
在Cypher中， * 0`非常簡潔地表述了上述事實：“沿著`WITHIN`邊，零次或多次”。它很像正則表示式中的`* `運算子。
自SQL:1999， （ （ ， ， ） ， ，
**例2-5 與示例2-4同樣的查詢，
```sql
WITH RECURSIVE
-- in_usa 包含所有的美國境內的位置ID
in_usa(vertex_id) AS (
SELECT vertex_id FROM vertices WHERE properties ->> 'name' = 'United States'
UNION
SELECT edges.tail_vertex FROM edges
JOIN in_usa ON edges.head_vertex = in_usa.vertex_id
WHERE edges.label = 'within'
),
-- in_europe 包含所有的歐洲境內的位置ID
in_europe(vertex_id) AS (
SELECT vertex_id FROM vertices WHERE properties ->> 'name' = 'Europe'
UNION
SELECT edges.tail_vertex FROM edges
JOIN in_europe ON edges.head_vertex = in_europe.vertex_id
WHERE edges.label = 'within' ),
-- born_in_usa 包含了所有型別為Person，
born_in_usa(vertex_id) AS (
SELECT edges.tail_vertex FROM edges
JOIN in_usa ON edges.head_vertex = in_usa.vertex_id
WHERE edges.label = 'born_in' ),
-- lives_in_europe 包含了所有型別為Person，
lives_in_europe(vertex_id) AS (
SELECT edges.tail_vertex FROM edges
JOIN in_europe ON edges.head_vertex = in_europe.vertex_id
WHERE edges.label = 'lives_in')
SELECT vertices.properties ->> 'name'
FROM vertices
JOIN born_in_usa ON vertices.vertex_id = born_in_usa.vertex_id
JOIN lives_in_europe ON vertices.vertex_id = lives_in_europe.vertex_id;
```
* 首先，查詢`name`屬性為`United States`的頂點，將其作為`in_usa`頂點的集合的第一個元素。
* 從`in_usa`集合的頂點出發，沿著所有的`with_in`入邊，將其尾頂點加入同一集合，不斷遞迴直到所有`with_in`入邊都被訪問完畢。
* 同理，從`name`屬性為`Europe`的頂點出發，建立`in_europe`頂點的集合。
* 對於`in_usa`集合中的每個頂點，根據`born_in`入邊來查找出生在美國某個地方的人。
* 同樣，對於`in_europe`集合中的每個頂點，根據`lives_in`入邊來查詢居住在歐洲的人。
* 最後，把在美國出生的人的集合與在歐洲居住的人的集合相交。
同一個查詢， ， ，
### 三元組儲存和SPARQL
三元組儲存模式大體上與屬性圖模型相同，用不同的詞來描述相同的想法。不過仍然值得討論，因為三元組儲存有很多現成的工具和語言，這些工具和語言對於構建應用程式的工具箱可能是寶貴的補充。
在三元組儲存中，所有資訊都以非常簡單的三部分表示形式儲存（**主語**， ， ** (吉姆, 喜歡 ,香蕉)** 中，**吉姆** 是主語，**喜歡** 是謂語（動詞），**香蕉** 是物件。
三元組的主語相當於圖中的一個頂點。而賓語是下面兩者之一：
1. 原始資料型別中的值，例如字串或數字。在這種情況下，三元組的謂語和賓語相當於主語頂點上的屬性的鍵和值。例如，`(lucy, age, 33)`就像屬性`{“age”：
2. 圖中的另一個頂點。在這種情況下，謂語是圖中的一條邊，主語是其尾部頂點，而賓語是其頭部頂點。例如，在`(lucy, marriedTo, alain)`中主語和賓語`lucy`和`alain`都是頂點，並且謂語`marriedTo`是連線他們的邊的標籤。
[例2-6]()顯示了與[例2-3]()相同的資料， （ （ ） ）
**例2-6 圖2-5中的資料子集，
```reStructuredText
@prefix : < urn:example: > .
_:lucy a :Person.
_:lucy :name "Lucy".
_:lucy :bornIn _:idaho.
_:idaho a :Location.
_:idaho :name "Idaho".
_:idaho :type "state".
_:idaho :within _:usa.
_:usa a :Location
_:usa :name "United States"
_:usa :type "country".
_:usa :within _:namerica.
_:namerica a :Location
_:namerica :name "North America"
_:namerica :type :"continent"
```
在這個例子中，圖的頂點被寫為：`_： _:usa.`。當謂語是一個屬性時，該賓語是一個字串，如`_ :usa :name "United States"`
一遍又一遍地重複相同的主語看起來相當重複， ， ， ：
**例2-7 一種相對例2-6寫入資料的更為簡潔的方法。**
```
@prefix : < urn:example: > .
_:lucy a :Person; :name "Lucy"; :bornIn _:idaho.
_:idaho a :Location; :name "Idaho"; :type "state"; :within _:usa
_:usa a :Loaction; :name "United States"; :type "country"; :within _:namerica.
_:namerica a :Location; :name "North America"; :type "continent".
```
#### 語義網路
如果你閱讀更多關於三元組儲存的資訊， ， ，
[^vii]: 從技術上講， ，
從本質上講語義網是一個簡單且合理的想法：網站已經將資訊釋出為文字和圖片供人類閱讀，為什麼不將資訊作為機器可讀的資料也釋出給計算機呢？**資源描述框架**（ ） ，
不幸的是，這個語義網在二十一世紀初被過度使用，但到目前為止沒有任何跡象表明已在實踐中實現，這使得許多人呲之以鼻。它還遭受了過多的令人眼花繚亂的縮略詞，過於複雜的標準提議和狂妄自大的苦果。
然而， ， ，
#### RDF資料模型
[例2-7]()中使用的Turtle語言是一種用於RDF資料的人可讀格式。有時候， ， ， ， ，
**例2-8 用RDF/XML語法表示例2-7的資料**
```xml
< rdf:RDF xmlns = "urn:example:"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
< Location rdf:nodeID = "idaho" >
< name > Idaho< / name >
< type > state< / type >
< within >
< Location rdf:nodeID = "usa" >
< name > United States< / name >
< type > country< / type >
< within >
< Location rdf:nodeID = "namerica" >
< name > North America< / name >
< type > continent< / type >
< / Location >
< / within >
< / Location >
< / within >
< / Location >
< Person rdf:nodeID = "lucy" >
< name > Lucy< / name >
< bornIn rdf:nodeID = "idaho" / >
< / Person >
< / rdf:RDF >
```
RDF有一些奇怪之處， ， ， ， `<http://my-company.com/namespace#within>` 或`< http: // my-company . com / namespace # lives_in > `，而不僅僅是`WITHIN`或`LIVES_IN`。這個設計背後的原因為了讓你能夠把你的資料和其他人的資料結合起來，如果他們賦予單詞`within`或者`lives_in`不同的含義，兩者也不會衝突，因為它們的謂語實際上是`< http: // other . org / foo # within > `和`< http: // other . org / foo # lives_in > `。
從RDF的角度來看， `<http://my-company.com/namespace>` 不一定需要能解析成什麼東西，它只是一個名稱空間。為避免與`http://URL`混淆， ， ： ：
### SPARQL查詢語言
**SPARQL**是一種用於三元組儲存的面向RDF資料模型的查詢語言， （ ， ） ， ，
與之前相同的查詢 - 查詢從美國轉移到歐洲的人 - 使用SPARQL比使用Cypher甚至更為簡潔（
**例2-9 與示例2-4相同的查詢，
```sparql
PREFIX : < urn:example: >
SELECT ?personName WHERE {
?person :name ?personName.
?person :bornIn / :within* / :name "United States".
?person :livesIn / :within* / :name "Europe".
}
```
結構非常相似。以下兩個表示式是等價的（ ） ：
```
(person) -[:BORN_IN]-> () -[:WITHIN*0..]-> (location) # Cypher
?person :bornIn / :within* ?location. # SPARQL
```
因為RDF不區分屬性和邊， ， ，
```
(usa {name:'United States'}) # Cypher
?usa :name "United States". # SPARQL
```
SPARQL是一種很好的查詢語言——哪怕語義網從未實現，
> #### 圖形資料庫與網路模型相比較
>
> 在“[文件資料庫是否在重蹈覆轍？](#文件資料庫是否在重蹈覆轍？)”中， ， ？
>
> 不，他們在幾個重要方面有所不同：
>
> * 在CODASYL中， ， ， ：
> * 在CODASYL中， ， ，
> * 在CODASYL， ， （ ） ， ， （ ）
> * 在CODASYL中， ， ， ， ， ， ，
>
>
### 基礎：
**Datalog**是比SPARQL或Cypher更古老的語言， ， ，
在實踐中， ： ， ，
[^viii]: Datomic和Cascalog使用Datalog的Clojure S表示式語法。在下面的例子中使用了一個更容易閱讀的Prolog語法，
Datalog的資料模型類似於三元組模式， （
**例2-10 用Datalog來表示圖2-5中的資料子集**
```prolog
name(namerica, 'North America').
type(namerica, continent).
name(usa, 'United States').
type(usa, country).
within(usa, namerica).
name(idaho, 'Idaho').
type(idaho, state).
within(idaho, usa).
name(lucy, 'Lucy').
born_in(lucy, idaho).
```
既然已經定義了資料，我們可以像之前一樣編寫相同的查詢，如[例2-11]()所示。它看起來有點不同於Cypher或SPARQL的等價物， ， ，
**例2-11 與示例2-4相同的查詢，
```
within_recursive(Location, Name) :- name(Location, Name). /* Rule 1 */
within_recursive(Location, Name) :- within(Location, Via), /* Rule 2 */
within_recursive(Via, Name).
migrated(Name, BornIn, LivingIn) :- name(Person, Name), /* Rule 3 */
born_in(Person, BornLoc),
within_recursive(BornLoc, BornIn),
lives_in(Person, LivingLoc),
within_recursive(LivingLoc, LivingIn).
?- migrated(Who, 'United States', 'Europe'). /* Who = 'Lucy'. */
```
Cypher和SPARQL使用SELECT立即跳轉，
在規則中， ， ，
要是系統可以在`:-` 運算子的右側找到與所有謂語的一個匹配，就運用該規則。當規則運用時，就好像透過`:-`的左側將其新增到資料庫（將變數替換成它們匹配的值）。
因此，一種可能的應用規則的方式是：
1. 資料庫存在`name(namerica, 'North America')`，
2. 資料庫存在`within(usa, namerica)`，在上一步驟中生成`within_recursive(namerica, 'North America')`，
3. 資料庫存在`within(idaho, usa)`，在上一步生成`within_recursive(usa, 'North America')`，
2020-10-06 09:25:46 +08:00
透過重複應用規則1和2，
2020-10-06 01:21:28 +08:00
2020-10-06 09:25:46 +08:00
2020-10-06 01:21:28 +08:00
**圖2-6 使用示例2-11中的Datalog規則來確定愛達荷州在北美。**
現在規則3可以找到出生在某個地方`BornIn`的人，並住在某個地方`LivingIn`。透過查詢`BornIn ='United States'`和`LivingIn ='Europe'`，並將此人作為變數`Who`， ，
相對於本章討論的其他查詢語言， ， ， ， ，
## 本章小結
資料模型是一個巨大的課題，在本章中，我們快速瀏覽了各種不同的模型。我們沒有足夠的空間來詳細介紹每個模型的細節，但是希望這個概述足以激起你的興趣，以更多地瞭解最適合你的應用需求的模型。
在歷史上， （ ） ， ， ， ：
1. **文件資料庫**的應用場景是：資料通常是自我包含的，而且文件之間的關係非常稀少。
2. **圖形資料庫**用於相反的場景：任意事物都可能與任何事物相關聯。
這三種模型（文件，關係和圖形）在今天都被廣泛使用，並且在各自的領域都發揮很好。一個模型可以用另一個模型來模擬 — 例如，圖資料可以在關係資料庫中表示 — 但結果往往是糟糕的。這就是為什麼我們有著針對不同目的的不同系統，而不是一個單一的萬能解決方案。
文件資料庫和圖資料庫有一個共同點，那就是它們通常不會為儲存的資料強制一個模式，這可以使應用程式更容易適應不斷變化的需求。但是應用程式很可能仍會假定資料具有一定的結構；這只是模式是明確的（寫入時強制）還是隱含的（讀取時處理）的問題。
每個資料模型都具有各自的查詢語言或框架， ： ， ， ， ， ， ，
雖然我們已經覆蓋了很多層面，但仍然有許多資料模型沒有提到。舉幾個簡單的例子：
* 使用基因組資料的研究人員通常需要執行**序列相似性搜尋**， （ ） ， ，
* 粒子物理學家數十年來一直在進行大資料型別的大規模資料分析， （ ） ！ ，
* **全文搜尋**可以說是一種經常與資料庫一起使用的資料模型。資訊檢索是一個很大的專業課題，我們不會在本書中詳細介紹，但是我們將在第三章和第三章中介紹搜尋索引。
讓我們暫時將其放在一邊。在[下一章](ch3.md)中，我們將討論在**實現**本章描述的資料模型時會遇到的一些權衡。
## 參考文獻
1. Edgar F. Codd: “[A Relational Model of Data for Large Shared Data Banks](https://www.seas.upenn.edu/~zives/03f/cis550/codd.pdf),” *Communications of the ACM* , volume 13, number 6, pages 377– doi:10.1145/362384.362685 ](http://dx.doi.org/10.1145/362384.362685 )
1. Michael Stonebraker and Joseph M. Hellerstein: “[What Goes Around Comes Around](http://mitpress2.mit.edu/books/chapters/0262693143chapm1.pdf),”
in *Readings in Database Systems* , 4th edition, MIT Press, pages 2–
1. Pramod J. Sadalage and Martin Fowler: *NoSQL Distilled* . Addison-Wesley, August 2012. ISBN:
978-0-321-82662-6
1. Eric Evans: “[NoSQL: What's in a Name?](http://blog.sym-link.com/2009/10/30/nosql_whats_in_a_name.html),” *blog.sym-link.com* , October 30, 2009.
1. James Phillips: “[Surprises in Our NoSQL Adoption Survey](http://blog.couchbase.com/nosql-adoption-survey-surprises),” *blog.couchbase.com* , February 8, 2012.
1. Michael Wagner: *SQL/XML:2006 – . Diplomica Verlag, Hamburg, 2010. ISBN: 978-3-836-64609-3
1. “[XML Data in SQL Server](http://technet.microsoft.com/en-us/library/bb522446.aspx),” SQL Server 2012 documentation, *technet.microsoft.com* , 2013.
1. “[PostgreSQL 9.3.1 Documentation](http://www.postgresql.org/docs/9.3/static/index.html),” The PostgreSQL Global Development Group, 2013.
1. “[The MongoDB 2.4 Manual](http://docs.mongodb.org/manual/),” MongoDB, Inc., 2013.
1. “[RethinkDB 1.11 Documentation](http://www.rethinkdb.com/docs/),” *rethinkdb.com* , 2013.
1. “[Apache CouchDB 1.6 Documentation](http://docs.couchdb.org/en/latest/),” *docs.couchdb.org* , 2014.
1. Lin Qiao, Kapil Surlaker, Shirshanka Das, et al.: “[On Brewing Fresh Espresso: LinkedIn’ *ACM International Conference on Management of Data* (SIGMOD), June 2013.
1. Rick Long, Mark Harrington, Robert Hain, and Geoff Nicholls: < a href = "http://www.redbooks.ibm.com/redbooks/pdfs/sg245352.pdf" > *IMS Primer*</ a > . IBM Redbook SG24-5352-00, IBM International Technical Support Organization, January 2000.
1. Stephen D. Bartlett: “[IBM’
1. Sarah Mei: “[Why You Should Never Use MongoDB](http://www.sarahmei.com/blog/2013/11/11/why-you-should-never-use-mongodb/),” *sarahmei.com* , November 11, 2013.
1. J. S. Knowles and D. M. R. Bell: “The CODASYL Model,” in *Databases—Role and Structure: An Advanced Course* , edited by P. M. Stocker, P. M. D. Gray, and M. P. Atkinson, pages 19–
1. Charles W. Bachman: “[The Programmer as Navigator](http://dl.acm.org/citation.cfm?id=362534),” *Communications of the ACM* , volume 16, number 11, pages 653– doi:10.1145/355611.362534 ](http://dx.doi.org/10.1145/355611.362534 )
1. Joseph M. Hellerstein, Michael Stonebraker, and James Hamilton: “[Architecture of a Database System](http://db.cs.berkeley.edu/papers/fntdb07-architecture.pdf),”
*Foundations and Trends in Databases* , volume 1, number 2, pages 141– doi:10.1561/1900000002 ](http://dx.doi.org/10.1561/1900000002 )
1. Sandeep Parikh and Kelly Stirman: “[Schema Design for Time Series Data in MongoDB](http://blog.mongodb.org/post/65517193370/schema-design-for-time-series-data-in-mongodb),” *blog.mongodb.org* , October 30, 2013.
1. Martin Fowler: “[Schemaless Data Structures](http://martinfowler.com/articles/schemaless/),” *martinfowler.com* , January 7, 2013.
1. Amr Awadallah: “[Schema-on-Read vs. Schema-on-Write](http://www.slideshare.net/awadallah/schemaonread-vs-schemaonwrite),” at *Berkeley EECS RAD Lab Retreat* , Santa Cruz, CA, May 2009.
1. Martin Odersky: “[The Trouble with Types](http://www.infoq.com/presentations/data-types-issues),” at *Strange Loop* , September 2013.
1. Conrad Irwin: “[MongoDB—Confessions of a PostgreSQL Lover](https://speakerdeck.com/conradirwin/mongodb-confessions-of-a-postgresql-lover),” at *HTML5DevConf* , October 2013.
1. “[Percona Toolkit Documentation: pt-online-schema-change](http://www.percona.com/doc/percona-toolkit/2.2/pt-online-schema-change.html),” Percona Ireland Ltd., 2013.
1. Rany Keddo, Tobias Bielohlawek, and Tobias Schmidt: “[Large Hadron Migrator](https://github.com/soundcloud/lhm),” SoundCloud, 2013. Shlomi Noach:
“[gh-ost: GitHub's Online Schema Migration Tool for MySQL](http://githubengineering.com/gh-ost-github-s-online-migration-tool-for-mysql/),” *githubengineering.com* , August 1, 2016.
1. James C. Corbett, Jeffrey Dean, Michael Epstein, et al.: “[Spanner: Google’ *10th USENIX Symposium on Operating System Design and Implementation* (OSDI),
October 2012.
1. Donald K. Burleson: “[Reduce I/O with Oracle Cluster Tables](http://www.dba-oracle.com/oracle_tip_hash_index_cluster_table.htm),” *dba-oracle.com* .
1. Fay Chang, Jeffrey Dean, Sanjay Ghemawat, et al.: “[Bigtable: A Distributed Storage System for Structured Data](http://research.google.com/archive/bigtable.html),” at *7th USENIX Symposium on Operating System Design and Implementation* (OSDI), November 2006.
1. Bobbie J. Cochrane and Kathy A. McKnight: “[DB2 JSON Capabilities, Part 1: Introduction to DB2 JSON](http://www.ibm.com/developerworks/data/library/techarticle/dm-1306nosqlforjson1/),” IBM developerWorks, June 20, 2013.
1. Herb Sutter: “[The Free Lunch Is Over: A Fundamental Turn Toward Concurrency in Software](http://www.gotw.ca/publications/concurrency-ddj.htm),” *Dr. Dobb's Journal* , volume 30, number 3, pages 202-210, March 2005.
1. Joseph M. Hellerstein: “[The Declarative Imperative: Experiences and Conjectures in Distributed Logic](http://www.eecs.berkeley.edu/Pubs/TechRpts/2010/EECS-2010-90.pdf),” Electrical Engineering and Computer Sciences, University of California at Berkeley, Tech report UCB/EECS-2010-90, June 2010.
1. Jeffrey Dean and Sanjay Ghemawat: “[MapReduce: Simplified Data Processing on Large Clusters](http://research.google.com/archive/mapreduce.html),” at *6th USENIX Symposium on Operating System Design and Implementation* (OSDI), December 2004.
1. Craig Kerstiens: “[JavaScript in Your Postgres](https://blog.heroku.com/javascript_in_your_postgres),” *blog.heroku.com* , June 5, 2013.
1. Nathan Bronson, Zach Amsden, George Cabrera, et al.: “[TAO: Facebook’ *USENIX Annual Technical Conference* (USENIX ATC), June 2013.
1. “[Apache TinkerPop3.2.3 Documentation](http://tinkerpop.apache.org/docs/3.2.3/reference/),” *tinkerpop.apache.org* , October 2016.
1. “[The Neo4j Manual v2.0.0](http://docs.neo4j.org/chunked/2.0.0/index.html),” Neo Technology, 2013. Emil Eifrem: [Twitter correspondence ](https://twitter.com/emileifrem/status/419107961512804352 ), January 3, 2014.
1. David Beckett and Tim Berners-Lee: “[Turtle –
1. “[Datomic Development Resources](http://docs.datomic.com/),” Metadata Partners, LLC, 2013. W3C RDF Working Group: “[Resource Description Framework (RDF)](http://www.w3.org/RDF/),” *w3.org* , 10 February 2004.
1. “[Apache Jena](http://jena.apache.org/),” Apache Software Foundation.
1. Steve Harris, Andy Seaborne, and Eric Prud'hommeaux: “[SPARQL 1.1 Query Language](http://www.w3.org/TR/sparql11-query/),”
W3C Recommendation, March 2013.
1. Todd J. Green, Shan Shan Huang, Boon Thau Loo, and Wenchao Zhou: “[Datalog and Recursive Query Processing](http://blogs.evergreen.edu/sosw/files/2014/04/Green-Vol5-DBS-017.pdf),” *Foundations and Trends in Databases* , volume 5, number 2, pages 105– doi:10.1561/1900000017 ](http://dx.doi.org/10.1561/1900000017 )
1. Stefano Ceri, Georg Gottlob, and Letizia Tanca: “[What You Always Wanted to Know About Datalog (And Never Dared to Ask)](https://www.researchgate.net/profile/Letizia_Tanca/publication/3296132_What_you_always_wanted_to_know_about_Datalog_and_never_dared_to_ask/links/0fcfd50ca2d20473ca000000.pdf),” *IEEE Transactions on Knowledge and Data Engineering* , volume 1, number 1, pages 146– doi:10.1109/69.43410 ](http://dx.doi.org/10.1109/69.43410 )
1. Serge Abiteboul, Richard Hull, and Victor Vianu: < a href = "http://webdam.inria.fr/Alice/" > *Foundations of Databases*</ a > . Addison-Wesley, 1995. ISBN: 978-0-201-53771-0, available online at *webdam.inria.fr/Alice*
1. Nathan Marz: “[Cascalog](http://cascalog.org/)," *cascalog.org* . Dennis A. Benson, Ilene Karsch-Mizrachi, David J. Lipman, et al.:
“[GenBank](http://nar.oxfordjournals.org/content/36/suppl_1/D25.full-text-lowres.pdf),” *Nucleic Acids Research* , volume 36, Database issue, pages D25– doi:10.1093/nar/gkm929 ](http://dx.doi.org/10.1093/nar/gkm929 )
1. Fons Rademakers: “[ROOT for Big Data Analysis](http://indico.cern.ch/getFile.py/access?contribId=13& resId=0& materialId=slides& confId=246453),” at *Workshop on the Future of Big Data Management* ,
London, UK, June 2013.
------
| 上一章 | 目錄 | 下一章 |
| -------------------------------------- | ------------------------------- | ---------------------------- |
| [第一章：可靠、可擴充套件、可維護 ](ch1.md ) | [設計資料密集型應用 ](README.md ) | [第三章：儲存與檢索 ](ch3.md ) |
