图数据模型
总述
在前面发现,不同的数据模型中在处理多对多的关系时,处理方式和性能有着很大的不同。如果你的应用有大量的一对多的关系,并且记录之间没什么关系，那文档关系库就很适合你了。但如果多对多的关系在你的应用中随处可见时,应该怎么办？关系数据库可以处理简单的关系,但是当你发现你的数据之间的联系越来越多，越来越复杂的时候，你该考虑把你的数据用图的方式建模了。
图的定义很简单,由两部分组成，节点和边，典型的例子包括
社交图谱,每个人是一个节点，人之间的关系是边
网页图谱,每个网页是一个节点,网页之间的Link是边
道路,铁路网络,交叉口是节点,路是边
上面给到的例子节点都是同一个类型的,但实际上图中的节点是允许异构的，也就是说可以在一个数据库中存储多种类型的数据。这正是图数据库的强大之处。facebook维护了一个巨大的图数据库,里面的节点包括人、地点、事件、评论等等，边包括两个人之间的关系,某个人在某个地点签到等等
以下图2-5为例，我们可以看到lucy生于Idaho,Alain生于Beaune,两个人目前结婚居住于London
目前市面上有几种不同的构建和查询图的方式,我们主要讨论两种, 属性图(property graph),例如neo4j,Titan 和 三元组 (triple-store),例如Datomic。 随后会讲一下一些说明型查询语言,比如Cypher, SPARQL, and Datalog
属性图
在属性图中,每个节点有以下内容构成
1. 唯一id
2. 一些指向别的节点的边
3. 一些指向自己的边
4. 若干属性,kv类型
每条边有以下内容
1. 唯一id
2. 1个起点
3. 1个终点
4. 一个描述起点终点关系的标记（居住,属于等等）
你可以想象成一个图有以下两个关系表组成，一个存储了节点的信息，一个存储了边的信息
CREATE TABLE vertices (
vertex_id integer PRIMARY KEY,
properties json
);
CREATE TABLE edges (
edge_id integer PRIMARY KEY,
tail_vertex integer REFERENCES vertices (vertex_id),
head_vertex integer REFERENCES vertices (vertex_id),
label text,
properties json
);
CREATE INDEX edges_tails ON edges (tail_vertex);
CREATE INDEX edges_heads ON edges (head_vertex);
图模型有几个重要的特质
1. 任何节点之间都可以相连，没有规定某种节点可以或者不可以彼此相连
2. 给一个节点，可以快速找到与这个节点相连的边
3. 由于给不同的关系起了不同的名字(label),所以可以在一个简单的图当中存储多种关系，并且这个数据模型依然很清爽
这些特征使得图模型在表达类似Figure 2-5这类数据时十分灵活。如果在传统关系数据库中，这个会有比较大的麻烦，比如美国下属机构叫郡或者州，而法国下级行政单位交县，同样一个国家下属行政单位名字还不一样。
我们可以基于图模型来表达获取很多常识，比如我们把人和食物作为节点，某个人和某种食物之间存在过敏的关系，我们就可以用图数据库很快找到某些人都可以吃的食物。而且图模型是拥抱变化的，你可以很轻松的对你的数据进行扩展。
Cypher 查询语言
Cypher是neo4j的查询语言，同SQL一样，它是一种说明性语言，下面是针对Figure2-5部分数据插入数据的例子.
CREATE
(NAmerica:Location {name:'North America', type:'continent'}),
(USA:Location {name:'United States', type:'country' }),
(Idaho:Location {name:'Idaho', type:'state' }),
(Lucy:Person {name:'Lucy' }),
(Idaho) -[:WITHIN]-> (USA) -[:WITHIN]-> (NAmerica),
(Lucy) -[:BORN_IN]-> (Idaho)
第一行代表一个节点的名字叫NAmerica,他是一个Location,,他有两个属性一个是name一个是type
(Lucy) -[:BORN_IN]-> (Idaho) 这行的意思是Lucy这个节点和Idaho这个节点之间有一个关系，关系的名字叫BORN_IN
当整个图都构建好后,我们就可以做些有意思的查询，比如那些人是从美国移民到欧洲的，具体方法是找到满足以下要求的节点
与某一个location节点有BORN_IN关系,这个节点属于美国
与某一个location节点有LIVE_IN关系，这个节点属于欧洲
具体的代码如下
MATCH
(person) -[:BORN_IN]-> () -[:WITHIN*0..]-> (us:Location {name:'United States'}),
(person) -[:LIVES_IN]-> () -[:WITHIN*0..]-> (eu:Location {name:'Europe'})
RETURN person.name
这个命令实现的大致方法是这样,首先根据名字找到美国和欧洲两个节点,然后根据WITH_IN关系找到所有的关联的LOCATION节点,最后找哪些人与对应的节点有BORN_IN和LIVE_IN关系就可以了。
但作为一个说明性语言，其实你不需要关心底层的实现逻辑，有一大票人还帮你做这些优化，他们肯定做的比你好。
用SQL来查图数据
在SQL中，我们一般都用join来查找这些关系,但是这有一个问题,在这之前,你都知道你应该join哪些数据，怎么join。但是在图查询中,这个就往往做不到了，因为比如在找属于美国的地方的时候,我们会沿着WITH_IN这个关系一直找到头，也就是我们不知道会join多少次。
在Cypher中 **WITHIN\*0** 就表达的很直白,沿着WITHIN这个边走0或者更多次,就好像正则里面的\*
SQL也支持，叫递归表查询(*recursive common table expressions*)，下面是个例子，但是我只建议你知道他很难写就好了，因为正常人肯定不会这么搞得。
WITH RECURSIVE
-- in_usa is the set of vertex IDs of all locations within the United States
in_usa(vertex_id) AS (
SELECT vertex_id FROM vertices WHERE properties->>'name' = 'United States'
UNION
SELECT edges.tail_vertex FROM edges
JOIN in_usa ON edges.head_vertex = in_usa.vertex_id
WHERE edges.label = 'within'
),
-- in_europe is the set of vertex IDs of all locations within Europe
in_europe(vertex_id) AS (
SELECT vertex_id FROM vertices WHERE properties->>'name' = 'Europe'
UNION
SELECT edges.tail_vertex FROM edges
JOIN in_europe ON edges.head_vertex = in_europe.vertex_id
WHERE edges.label = 'within'
),
-- born_in_usa is the set of vertex IDs of all people born in the US
born_in_usa(vertex_id) AS (
SELECT edges.tail_vertex FROM edges
JOIN in_usa ON edges.head_vertex = in_usa.vertex_id
WHERE edges.label = 'born_in'
),
lives_in_europe(vertex_id) AS (
SELECT edges.tail_vertex FROM edges
JOIN in_europe ON edges.head_vertex = in_europe.vertex_id
WHERE edges.label = 'lives_in'
)
SELECT vertices.properties->>'name'
FROM vertices
-- join to find those people who were both born in the US *and* live in Europe
JOIN born_in_usa ON vertices.vertex_id = born_in_usa.vertex_id
JOIN lives_in_europe ON vertices.vertex_id = lives_in_europe.vertex_id;
```
用Cypher,4行就搞定了SQL写了这么长还看不懂,看到选择一个正确的数据模型的意义了吧
三元组存储法和SPARQL
其实从根上讲，三元组存储法和上面讲的属性图没什么区别，只是换了个名字。简单来说一切关系可以用一个3元祖表示,例如(Jim, likes,bananas)代表jim喜欢吃香蕉。(Lucy, age, 33)代表Lucy今年33岁. 他和前面的属性图可以互相转换，很简单。
还是以Figure 2-5作为例子
@prefix :.
_:lucy a :Person.
_:lucy :name "Lucy".
_:lucy :bornIn _:idaho.
_:idaho a :Location.
_:idaho :name "Idaho".
_:idaho :type "state".
_:idaho :within _:usa.
_:usa a :Location.
_:usa :name "United States".
_:usa :type "country".
_:usa :within _:namerica.
_:namerica a :Location.
_:namerica :name "North America".
_:namerica :type "continent".
如果你觉得写那么多遍lucy太麻烦，可以这样
@prefix :.
_:lucy a :Person; :name "Lucy"; :bornIn _:idaho.
_:idaho a :Location; :name "Idaho"; :type "state"; :within _:usa.
_:usa a :Location; :name "United States"; :type "country"; :within _:namerica.
_:namerica a :Location; :name "North America"; :type "continent".
语义网络
没什么用，主要谈了谈semantic web的历史，和RDF的介绍没什么值钱的东西
###SPARQL###
SPARQL是三元组存储的查询语言，整体来说跟Cypher还是挺像的，同样是查从美国移民到欧洲的query
```
SELECT ?personName WHERE {
?person :name ?personName.
?person :bornIn / :within* / :name "United States".
?person :livesIn / :within* / :name "Europe".
}
```
因为他不区分关系和属性，所以在查例如所有包含名称为United States的节点时语法不太一样
(usa {name:'United States'}) # Cypher
?usa :name "United States". # SPARQL
基础:Datalog
Datalog问世已久，但是码农圈知道的不多，这是一个很有历史感的语言，不想敲了，很神奇这个表达方式，很程序员
总结
最开始，所有的数其实是存储成一个树结构的，但是这种方式很难表达多对多的关系，所有我们发明了关系模型，但是最近我们发现，在某些应用中，关系模型使用起来不是很方便，效果不太好，所以引入了新的非关系数据库，这主要有两大类
文档数据库主要解决自组织的数据,一条数据里面有很多属性,但是不同数据之间的关系却比较少
图数据库走的方向恰好相反，它主要针对存在大量关系的数据
三种模型彼此擅长的领域表现的很好，但是在其他地方就不太好了，正好像关系型数据库可以存储和查询一个图，只是非常的麻烦。所以我们需要针对自己的应用选择合适的数据模型，而不是一个通用的模型。
其实还有很多模型没有介绍，简单给个例子
基因研究者有项研究叫做序列相似度的查找，拿一个很长的字符串，表达一段DNA，在数据库中找到与之相似但不完全一样的一个片段，上面3个模型对这种需求都搞不定，所以发明了基因数据库,GenBank
量子物理经常需要处理几百PB的数据，所以发明了 Large Hadron Collider,这个项目旨在控制使用的硬件的需求不会因为这巨大量的数据而爆炸
全文搜索是种数据模型其实还有争议，信息检索是一个宏大的内容，第三章详细讨论
