第二章 數據模型和查詢語言
總結
本章開始介紹了關係型數據庫，非關係型數據庫，圖模型數據。
首先解釋了關係模型和文檔模型是什麼，然後指出了從數據庫模型到應用程序對象模型之間的不匹配（稱爲對象關係不匹配）我們通常使用 ORM 框架來解決從數據庫模型到程序對象的轉換。
接着引出了一對多、多對一、多對多關係以及查詢的局部性。和 json 這種數據格式
使用了 linked 上的簡歷來說明這幾種關係，一個人有多份工作經歷；多個人在同一個地區工作；一個用戶爲另一個用戶的推薦；以及使用者兩種模型進行存儲的做了比較
最後討論了圖數據模型，圖的表示，使用關係模型來表示屬性圖；介紹了一種屬性圖的查詢語言（Cypher查詢語言），並用其構建一個查詢語句和 SQL 的等價查詢語句進行了比較；最後還介紹了三元組存儲和SPARQL，Datalog。圖相關的東西瞭解的不多，有時間還需要多看看
每種數據模型都有自己的適用場景和特點，這章並沒有足夠的細節，下章見
關係模型和文檔模式的比較
一對多關係 和 連接查詢
連接查詢通常使用 ID 來進行連接，ID 可以一直不變，而其對人有意義的值卻時常會變；
規範化通過將相同的數據存儲在一處，那麼這些數據在變化時，就不需要複製給其他副本，減少了不一致性；同時規範化還有許多其他好處。
多對多關係、多對一關係
一對多關係中：
- 關係模型：通過外鍵鏈接，可以使用 SQL 連接或者應用代碼連接；
- 文檔型模型：通過在父記錄中嵌套記錄，而不是存儲在單獨的表
多對一、多對多關係：都是通過標識符來引用（稱爲外鍵或者文檔引用）
容錯屬性
第五章
處理併發性
第七章
文檔模式的便利性
通常文檔表示爲 json 數據格式，而這種格式的數據通常可以任意的添加鍵值對，那麼讀取時客戶端無法保證文檔可能包含的字段。但是應用程序通常假定數據是具有某種格式的，但是不強制執行，這被稱爲寫時模式和讀時模式
寫時模式，在寫入時具有的數據模型，數據庫保證其所有數據都符合這種格式
讀時模式，在讀取時指定一個數據模型版本，如果字段不存在通常會填充默認值
這種方式就像我們打的 jar 包，新版本通常都會對舊版本進行兼容。查詢的客戶端都有指定的數據版本；而寫入通常是最新的版本；但是新版本如果刪除了某個字段，那麼讀時模式就不太好處理了
查詢的局部性
通常一個文檔需要一次性加載至頁面，使用文檔數據庫存儲則只需要一次查詢，如果關係型數據庫將數據存放在不同的表中，則需要多次連接，不管是在 SQL 層面還是在應用代碼層面，這會花費更多的時間。
這需要大多數查詢都滿足局部性的情況下才有效，如果只需要訪問文檔的一部分內容則會很浪費，因爲文檔是一次性全部加載至內存的。
現在的關係型數據庫大多都已經支持 json 格式和 XML 格式，關係模型和文檔模型的界限正在漸漸模糊
數據查詢語言
聲明式查詢
只定義了查詢的模式，而不是指定具體的執行流程，爲查詢優化提供了優化的空間，例如並行查詢，使用何種索引
命令式查詢
類似於代碼，告訴計算機以某種特定的順序執行某些操作。
MapReduce 查詢
既不是聲明式也不是命令式，而是介於兩者之間，查詢的邏輯要用代碼片段來表示，代碼被框架反覆執行。很容易在集羣上分佈式執行。
mapReduce 即是一種編程模型也是一種計算框架。大數據處理的內容很多可以看看這個專欄
圖數據模型
圖在現實生活中很多，社交網絡，公里網絡，網絡圖譜等等
圖由邊和頂點組成
頂點：有唯一標識符，一組出邊，一組入邊；一組屬性
邊：有唯一標識符，邊的起點，邊的終點，描述兩個頂點之間的關係，一組屬性
三元組存儲
三元組：形如（主語，謂語，賓語）這三部分來表示存儲，例如 三元組（狗蛋，喜歡，翠花）；主語是頂點，而賓語是另一個頂點（此時謂語就是邊）或者主語頂點下的屬性的鍵或值