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. 这种边叫作环