本章主要是介绍了不同的数据模型。作者的给的数据模型构建方式
现实世界需求的数据结构建模
存储数据结构时的数据模型
操作数据模型的方式
硬件层面如何表示
关系型与文档型
关系模型
数据基于组织成关系，在SQL中就是表的概念，每个关系都是元祖的无序集合（在sql中称为行）。关系型数据库的核心在于商业化数据处理，提供事务处理和批处理。
关系型模型存在对象--关系不匹配的情况，比如交互的对象和存储对象（多张表）不一致（书中给出了一个概念叫阻抗失配）。当出现数据一对多情况时，作者举了一个查看简历的例子，简历由多张表构成，多表的关联会导致查询效率会下降。但在多对一和多对多的情况下，维护了数据文本信息与ID的关系，更适合相关业务（多对多比如国籍与ID是一张表，而人员的信息表里填写的是id）。
文档型
书中以查看简历的例子引出文档型模型的几个优点
- 对象和关系匹配。由于存储的结构是json类型，非常适合一对多的场景，不需要关联表查询
- 模式灵活。如果进行改表操作，关系型需要表锁，文档型不需要
同样也会有一些缺点
- 不适用于多对一，多对多场景。主要是由于文档型模型对join的方式优化不如关系型
- 查询数据的局限性。由于采用了json或者xml方式，访问文档某一小部分，数据库会加载整个文档，导致效率较低
融合
-
mysql等关系型数据库支持json方式数据存储
-
mongoDb等文档型数据库在客户端驱动程序自动解析数据库的引用关系（join）
数据查询语言
声明式语言
告诉服务输入条件以及所需要的结果。这种方式隐藏了实现细节，用户不需要关心内部是如何实现。同时，如何操作由服务进行调度，也更适合并行处理。比如SQL以及web开发中的CSS等。
数据库语言更适合声明式语言。
命令式语言
告诉服务如何去执行。这种方式需要用户编写操作步骤。不太适合并行处理。
MapReduce
书中给出了一个例子用来说明在map和reduce步骤中，即是用了声明式语言（定义类型）以及命令式语言（执行步骤）。
图状数据模型
当多对多关系中数据关联非常复杂的时候，比如社交网络，此时关系型模型不能胜任。
图状数据模型包括顶点和边。
属性图模型
顶点
- 唯一标识符
- 出边集合
- 入边集合
- 属性集合
边
- 唯一标识符
- 边开始的顶点
- 边结束的顶点
- 顶点间关系的标签
- 属性集合
Cypher查询语言是属性图模型的查询语言
三元存储模型
采用主体-谓语-客体。
顶点
- 主体
- 客体也可以成为顶点
边
- 谓语
- 谓语和客体肠胃主体的键值对
SPARQL和Datalog是该模型查询语言
其他
这章节主要是讲述了一些数据模型。不同的数据模型在不同场景的应用。
