对于应用程序开发人员来说，我们的编码过程很多场景下都是对现实世界的代码描述。这个描述过程可以理解为数据模型的构建过程。数据模型不仅影响着代码的编写方式（面向对象、函数式编程等等），它也会影响我们后续解决问题的思路。

在计算机系统中，我们常常通过构建层级结构来解构整个系统（例如计算机存储器的层级结构），一个复杂的应用程序往往会有多个中间层次，每个层次都提供一个明确的数据模型来隐藏更低层次中的复杂性。这些抽象出来的数据模型能够为构建整个系统的不同角色提供有效协作的基础。

常见和常用的数据模型，可以抽象为几大类：关系模型、文档模型和图数据模型。

关系模型

关系模型中，数据被组织成关系，其中每个关系是元组的无序集合。它常常被应用在典型的事务处理和批处理中。

关系模型的数据结构清晰明了，没有复杂的嵌套结构，没有复杂的访问路径；关系数据库中，查询优化器自动决定查询的执行细节，避免应用程序开发人员过多的考虑它。应用程序开发过程中，通过对象关系映射（ORM）减少代码中关于对象和数据库表的行列转换。

SQL

关系模型包含了一种查询数据的方法：SQL。SQL是一种声明式查询语言，它能够紧密地遵循关系代数的结构。

对于使用者而言，声明式查询语言只需要指定所需数据的模式：查询结果必须符合哪些条件、如何对数据进行转换，但是不需要明确指出具体的实现细节。上述的这些实现细节，是由数据库系统的查询优化器来决定。

SQL能够提供给使用者相对简洁的API，这使得数据库系统可以在无需对查询做任何更改的情况下进行性能提升。

关系模型面临的挑战

然而，关系模型以及其代表的一批关系型数据库也面临着一些挑战：

  • 上层应用需要数据库提供更好的伸缩性和更大的吞吐量；
  • 关系模型不能很好的支持一些特殊的查询操作，例如社交图谱、网络图谱、公路或地铁网络等场景；
  • 业务需要数据模型有更好的动态性和表现力

文档模型

图数据模型

在解决一对多关系的时候，通常使用文档模型比较合适；在处理简单的多对多关系的情况，关系模型也能够有效解决问题；但是随着数据之间的连接变得复杂，使用图数据模型会显得更加自然。

一个图由两种对象组成：顶点和边。顶点代表模型中的节点或者实体，边连接不同的顶点用于表示顶点之间的关系。使用图数据模型解决问题典型的例子如：社交图谱、网络图谱、公路和地铁网络。

属性图模型

属性图中，每个顶点包括：

  • 唯一的标识符
  • 一组入边
  • 一组出边
  • 一组属性

每条边包括：

  • 唯一标识符
  • 边的起点
  • 边的终点
  • 描述两个顶点之间关系的标签
  • 描述当前关系的属性组

属性图模型有一些重要的特性：

  • 任何顶点都可以有一条边连接到任何顶点，模式灵活；
  • 给定任何顶点，都可以高效地找到它的入边和出边，进而为整个图的遍历提供可能；
  • 不同类型的关系可以使用不同标签，这样相同的两个顶点之间的不同关系也可以通过建立多个边来清晰描述

基于属性图实现的图数据库入：Neo4j、Infinitegraph等。常见的查询语言：声明式查询语言Cypher。实际使用下来，Cyper容易上手、文档丰富、表现力好，如果有业务场景需要图数据库的，推荐尝试下。

三元组存储模型

三元组存储模式大体上与属性图相同，它可以作为属性图的补充。

在三元组存储中，所有信息都以简单的三部分表示形式存储，即主语、谓语和宾语。

三元组的主语相当于属性图中的一个顶点，而宾语可以是两者中的一个：

  • 原始数据类型中的值，即顶点的属性；
  • 整个图中的另一个顶点，这种情况下，谓语则会编程图中的边，宾语是另一个顶点

小结

我们在应用开发过程中，应该结合自己的使用场景和业务需求来谨慎地选择数据模型。

  • 不同类型的模型也有较好的互补
  • 同一种模型也可以有多种查询语言，但通常只有一种是最合适的

原文地址：https://ddia.vonng.com/#/ch2