1. 概念 1.1. 實體 1.1.1. 通常用名詞來表示 1.1.2. 描述一個領域中的事物或者事物類型 1.1.2.1. 汽車 1.1.2.2. 用戶 1.1.2.3. 地理位置 1.1.3. 在邏輯模型和技術實現過程中，實體通常會變成“頂點” 1.2. 關係 1.2.1. 用動詞（或動詞短語） ...
1. 概念
1.1. 實體
1.1.1. 通常用名詞來表示
1.1.2. 描述一個領域中的事物或者事物類型
1.1.2.1. 汽車
1.1.2.2. 用戶
1.1.2.3. 地理位置
1.1.3. 在邏輯模型和技術實現過程中，實體通常會變成“頂點”
1.2. 關係
1.2.1. 用動詞（或動詞短語）來表示
1.2.2. 描述實體之間的互動
1.2.2.1. 一輛卡車移動到一個位置”場景里的移動
1.2.2.2. “一個人加了另一個人為好友”
1.2.3. 在邏輯模型和技術實現過程中，關係通常會變成“邊”
1.2.4. 邊和關係並不一定是相同的東西。雖然用在概念模型中的實體和關係和用在邏輯模型中的頂點和邊經常有很強的相關性，但它們之間並不總是一一對應的
1.3. 屬性
1.3.1. 用名詞來表示
1.3.2. 通常在實體或關係的上下文中出現，描述實體或關係的特性
1.4. 訪問模式
1.4.1. 描述在領域中互動的疑問或方法
1.4.2. 互動疑問
1.4.2.1. 這輛卡車會去哪兒
1.4.2.2. 誰是這個人的好友
1.4.3. 在邏輯模型和技術實現過程中，訪問模式通常會變成“查詢”
1.5. 基數（cardinality）
1.5.1. 一個集合中元素的數量
1.6. 多重性（multiplicity）
1.6.1. 對一個集合可以擁有的最小基數和最大基數的說明
1.6.2. 一對多、零對多、多對多
1.6.3. 用來約束相關實體的數量
2. 唯一性
2.1. 數據的唯一性指，在一個數據集中，如何度量指定數據重覆的次數
2.2. 唯一性被定義為兩個頂點之間允許的、具有指定標簽的邊的數量
2.3. 邊的不正確的唯一性定義是圖建模過程中最普遍的問題之一，而且經常引發查詢問題
2.4. 正確地設計數據模型，以正確反映邊的唯一性
2.5. ataStax Enterprise Graph和JanusGraph，會把邊的唯一性的顯式定義作為模式定義的一部分
2.6. 單獨唯一指零條或一條邊
2.6.1. 兩個實例頂點之間只有唯一具有指定標簽的邊
2.6.2. 優先使用單獨唯一性
2.7. 多重唯一指超過一條邊
2.7.1. 兩個實例頂點之間可以有一條或多條具有指定標簽的邊
2.7.2. 只在特殊需要時才考慮多重唯一性
2.8. 單獨唯一性顯然比多重唯一性普遍得多
2.9. 不恰當的唯一性
2.9.1. 返回太少的數據
2.9.1.1. 當一條邊被定義為單獨唯一的，但事實上應該是多重唯一的時，就會發生這種情況
2.9.2. 返回重覆的數據
2.9.2.1. 當一條邊被定義為多重唯一的，但事實上應該是單獨唯一的時候，就會發生這種情況
2.9.3. 糟糕的查詢性能
2.9.3.1. 用多重唯一的邊取代本來可以用單獨唯一表示的邊是導致查詢性能變差的首要原因
2.9.3.1.1. 資料庫不得不做更多事情來從一個帶有多條邊的查詢中返回數據
3. 數據建模
3.1. 將真實世界的實體和關係轉換為相應的軟體表示
3.2. 圖數據的建模過程相較於關係資料庫，我們的思維方式必須從“實體第一”（更準確地說，是“實體唯一”）轉變為“實體加關係”
3.3. 物理數據模型大多數時候就是我們要查詢的結果
3.4. 概念模型是最終用戶與軟體開發人員的溝通橋梁
3.5. 數據設計過程中的失誤將在代碼實現過程中引起更難修複的問題
3.6. 所有實現都意味著一定程度的代碼編寫、測試和數據載入
3.7. 構建包含複雜領域中的高度關聯數據、可以在生產環境運行的應用程式
3.8. 要採取的方式會降低這種風險，並把數據模型變化所帶來的痛苦降到最低
4. 建模步驟
4.1. 理解問題
4.1.1. 昨天的完美應用在明天看來就是功能不全的
4.1.2. 早期在理解業務問題、用例和通用領域術語上進行大量時間投資，是建立好的數據模型的基礎
4.1.2.1. 這將降低你在後期大幅修改設計的風險
4.1.3. 領域和範圍
4.1.3.1. 每個業務問題都可以無限擴展，所以把範圍定義得越精確，我們離成功就越近
4.1.3.2. 定義了業務問題的邊界
4.1.3.2.1. 該應用程式能為用戶帶來什麼
4.1.3.2.2. 該應用程式需要記錄哪些類型的信息才能完成這些任務
4.1.3.2.3. 誰是應用程式的用戶
4.1.3.2.3.1. 聚焦在傳統意義的最終用戶上
4.1.3.2.3.2. 不包括系統管理員、客戶服務人員，以及其他負責對複雜的技術解決方案提供運維的人員
4.1.4. 業務實體
4.1.4.1. 找出應用程式的基礎構件，以及這些構件之間的關係
4.1.4.2. 定義良好的關係不僅需要名字，還需要對關係如何連接實體以及定義關係所需的各種潛在屬性有一定的理解
4.1.4.3. 這個應用程式會運用哪些要素或事物
4.1.4.4. 這些要素之間有什麼關係
4.1.4.5. 每個實體有哪些關鍵數據
4.1.5. 功能
4.1.5.1. 進入概念模型時，會把功能變成訪問模式
4.1.5.1.1. 為系統構建查詢
4.1.5.2. 人們將如何使用系統
4.1.5.3. 要為用戶解答哪些疑問
4.2. 構建概念數據模型
4.2.1. 白板模型
4.2.2. 花點兒時間理解和定義業務領域是非常重要的
4.2.3. 對實體進行識別和歸類
4.2.3.1. 先從領域中提取實體
4.2.3.2. 從尋找名詞開始
4.2.3.3. 應該用單數名詞來命名所有的實體
4.2.3.3.1. 每個實體代表某項的單個實例
4.2.3.3.2. 對於圖數據建模來說，單數的名稱更合適
4.2.4. 識別實體間的關係
4.2.4.1. 確定關係，即怎麼做
4.2.4.2. 不要小看這種為了聚焦於手頭上的首要任務而設的虛擬“想法停車場”
4.2.4.3. 不是在功能性疑問的回答中尋找名詞，而是尋找動詞
4.2.4.4. 會把每個動詞和相應的實體名字進行合併
4.2.4.4.1. 格式是“名詞-動詞-名詞”或“實體-關係-實體”
4.3. 構建邏輯數據模型
4.3.1. 大部分圖資料庫是沒有模式的
4.3.2. 把那些實體和關係轉換成圖的概念——頂點、邊和屬性
4.3.3. 步驟
4.3.3.1. 把實體轉換成頂點
4.3.3.1.1. 從概念模型中識別所有相關的實體
4.3.3.1.1.1. 作為一個通用規則，我們通過在功能疑問清單中尋找名詞的方式來為應用程式找出實體
4.3.3.1.1.2. 因為名詞代表實物或邏輯元素，所以它們通常是在應用程式中解決問題所需實體的最佳標識
4.3.3.1.2. 以標簽的形式給頂點一個名字，該標簽在圖模型中是此類實體的唯一標識
4.3.3.1.2.1. 模型圖中的標簽用於對代表類似概念的頂點進行分組和歸類
4.3.3.1.2.2. 決定標簽的名字並不是小事
4.3.3.1.2.3. 好的標簽名要簡短、清晰和準確
4.3.3.1.2.4. 把頂點的標簽命名為單數名詞是最佳實踐
4.3.3.1.2.5. 儘量用通用的名字作為標簽名也是一種最佳實踐
4.3.3.1.2.6. 標簽和屬性命名規則的一致性對於應用程式的維護至關重要
4.3.3.1.2.7. 一致性為開發人員和系統管理員提供了可預測性
4.3.3.1.2.8. 統一使用小寫單數單詞作為標簽的名字
4.3.3.1.2.9. 在圖資料庫中，每個頂點僅關聯一個標簽通常是比較穩妥的做法
4.3.3.1.2.9.1. 這是Apache TinkerPop項目的做法
4.3.3.1.2.9.1.1. Neo4j和Amazon Nepture，支持一個頂點有多個標簽
4.3.3.1.2.9.2. 模式繼承中，一個頂點有多個標簽是合適的
4.3.3.2. 把關係轉換成邊
4.3.3.2.1. 邊會包含方向、唯一性這些在關係資料庫中沒有的特性
4.3.3.2.2. 尋找關係
4.3.3.2.2.1. 從概念數據模型中識別相關的關係
4.3.3.2.3. 命名邊的標簽
4.3.3.2.3.1. 為邊命名，作為圖數據模型中某個關係的唯一標簽
4.3.3.2.3.2. 邊首尾連接的是同一個頂點
4.3.3.2.3.2.1. 這種邊叫作環
