第二章 数据模型和查询语言
总结
本章开始介绍了关系型数据库，非关系型数据库，图模型数据。
首先解释了关系模型和文档模型是什么，然后指出了从数据库模型到应用程序对象模型之间的不匹配（称为对象关系不匹配）我们通常使用 ORM 框架来解决从数据库模型到程序对象的转换。
接着引出了一对多、多对一、多对多关系以及查询的局部性。和 json 这种数据格式
使用了 linked 上的简历来说明这几种关系，一个人有多份工作经历；多个人在同一个地区工作；一个用户为另一个用户的推荐；以及使用者两种模型进行存储的做了比较
最后讨论了图数据模型，图的表示，使用关系模型来表示属性图；介绍了一种属性图的查询语言（Cypher查询语言），并用其构建一个查询语句和 SQL 的等价查询语句进行了比较；最后还介绍了三元组存储和SPARQL，Datalog。图相关的东西了解的不多，有时间还需要多看看
每种数据模型都有自己的适用场景和特点，这章并没有足够的细节，下章见
关系模型和文档模式的比较
一对多关系 和 连接查询
连接查询通常使用 ID 来进行连接，ID 可以一直不变，而其对人有意义的值却时常会变；
规范化通过将相同的数据存储在一处，那么这些数据在变化时，就不需要复制给其他副本，减少了不一致性；同时规范化还有许多其他好处。
多对多关系、多对一关系
一对多关系中：
- 关系模型：通过外键链接，可以使用 SQL 连接或者应用代码连接；
- 文档型模型：通过在父记录中嵌套记录，而不是存储在单独的表
多对一、多对多关系：都是通过标识符来引用（称为外键或者文档引用）
容错属性
第五章
处理并发性
第七章
文档模式的便利性
通常文档表示为 json 数据格式，而这种格式的数据通常可以任意的添加键值对，那么读取时客户端无法保证文档可能包含的字段。但是应用程序通常假定数据是具有某种格式的，但是不强制执行，这被称为写时模式和读时模式
写时模式，在写入时具有的数据模型，数据库保证其所有数据都符合这种格式
读时模式，在读取时指定一个数据模型版本，如果字段不存在通常会填充默认值
这种方式就像我们打的 jar 包，新版本通常都会对旧版本进行兼容。查询的客户端都有指定的数据版本；而写入通常是最新的版本；但是新版本如果删除了某个字段，那么读时模式就不太好处理了
查询的局部性
通常一个文档需要一次性加载至页面，使用文档数据库存储则只需要一次查询，如果关系型数据库将数据存放在不同的表中，则需要多次连接，不管是在 SQL 层面还是在应用代码层面，这会花费更多的时间。
这需要大多数查询都满足局部性的情况下才有效，如果只需要访问文档的一部分内容则会很浪费，因为文档是一次性全部加载至内存的。
现在的关系型数据库大多都已经支持 json 格式和 XML 格式，关系模型和文档模型的界限正在渐渐模糊
数据查询语言
声明式查询
只定义了查询的模式，而不是指定具体的执行流程，为查询优化提供了优化的空间，例如并行查询，使用何种索引
命令式查询
类似于代码，告诉计算机以某种特定的顺序执行某些操作。
MapReduce 查询
既不是声明式也不是命令式，而是介于两者之间，查询的逻辑要用代码片段来表示，代码被框架反复执行。很容易在集群上分布式执行。
mapReduce 即是一种编程模型也是一种计算框架。大数据处理的内容很多可以看看这个专栏
图数据模型
图在现实生活中很多，社交网络，公里网络，网络图谱等等
图由边和顶点组成
顶点：有唯一标识符，一组出边，一组入边；一组属性
边：有唯一标识符，边的起点，边的终点，描述两个顶点之间的关系，一组属性
三元组存储
三元组：形如（主语，谓语，宾语）这三部分来表示存储，例如 三元组（狗蛋，喜欢，翠花）；主语是顶点，而宾语是另一个顶点（此时谓语就是边）或者主语顶点下的属性的键或值