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. 这种边叫作环
4.3.3.2.4. 为边分配方向4.3.3.2.4.1. 以定义始末顶点类型4.3.3.2.4.2. 从一个顶点（出顶点）出发，到另一个顶点（入顶点）4.3.3.2.5. 确定边的唯一性4.3.3.2.5.1. 根据这条边在两个指定顶点间存在的次数，确定边的唯一性4.3.3.2.5.2. 描述了具有相同标签的边从一个顶点的实例连接到另一个顶点的实例的次数4.3.3.2.5.3. 描述了两个顶点间允许的、具有指定标签的边的最大数量4.3.3.2.5.4. 多重唯一（multiple uniqueness）4.3.3.2.5.5. 单独唯一（single uniqueness）4.3.3.2.5.6. 并不是在描述一条边的特性，而是在描述一组边的特性4.3.3.3. 寻找属性，并将其分配到顶点和边上4.3.3.3.1. 属性是用来描述顶点或边的特性的键-值对4.3.3.3.2. 和列不同，应用程序不会在图数据库中向属性插入默认值或null值4.3.3.3.3. 保存null值或为属性赋予默认值是没有必要的4.3.3.3.4. 为顶点和边都赋予属性的能力，正是图数据库和关系数据库的另一个本质区别4.4. 检查模型4.4.1. 顶点和边读起来像一个句子吗？是的4.4.2. 是否有不同的顶点标签或边标签具有相同的属性？没有4.4.3. 这个模型看起来合理吗？是的
