图数据库是用来组织高度关联数据的一种数据存储系统，相对传统的关系型数据库，它有着查询、分析更加高效的优势，在社交网络、公安、交通、金融等领域都有良好的应用前景。
本文从数据模型入手，介绍图数据库的逻辑模型和基本概念，希望能够帮助感兴趣的同学，叩开图数据库世界的大门。为了增加文章的趣味性，选用了JanusGraph官方样例Graph of the Gods进行讲解。
Graph of the Gods
读一点神话
虽然样例中节点和边的数量不多，但如果不了解上下文，理解起来还是会有一些偏差。所以，Ivan先带诸位跳出技术主题，读一点希腊罗马神话故事。
之所以说希腊罗马神话，是因为罗马基本上继承和延续了希腊文明，希腊神话与罗马神话基本是一套体系，希腊神都有对应的罗马神。
宙斯三兄弟
Satum（萨杜恩，[希]克洛诺斯）是Jupiter（朱庇特，[希]大名鼎鼎的宙斯）的父亲，也就是第二代众神，世界的主宰。克洛诺斯与其他第二代诸神被统称为Titan（泰坦，也译为提坦）神族。克洛诺斯在推翻代众神（克洛诺斯的父亲）时被诅咒，自己的统治也会被后代推翻。
因此，克洛诺斯在所有孩子出生后都将其吞入腹中，希望避免诅咒的发生，当然这也为后来宙斯的行动提供了合法性。看到太多孩子被吞掉，宙斯的母亲实在无法容忍，于是在宙斯出生时她谎称生了一块石头，宙斯得以躲过了被吞噬的命运。
果然，长大后的宙斯推翻了克洛诺斯的统治，解救出了被吞入腹中的兄弟姐妹（即第三代众神，也被称为奥林匹斯神族），并和他的两个兄弟一起通过抽签决定对世界的统治权。终的结果是由宙斯主管人间；Neptune（尼普顿，[希]海神波塞冬）主管海洋；Pluto（普路同，[希]冥王哈迪斯）主管冥界。
Ivan的希腊神话启蒙读物，致敬一下
很有意思的是，部分图数据库产品也特别钟情于希腊罗马神话，JanusGraph的前身数据库Titan即来自第二代神族的名称；Janus本身是罗马神话中的双面神；而AWS在2017年发布了一款面向公有云的图数据库，命名则来自第三代神族中的海神Neptune。
大力神——海格力斯
宙斯之子：赫拉克勒斯（剧照）
Hercules（海格力斯，[希]赫拉克勒斯）是希腊罗马神话中的大力神，始终是西方文艺作品中的热门题材，比如凡尔赛宫“海格力斯厅”的穹顶油画（封面）；佛罗伦萨市政厅前，与美男子“大卫”比邻的雕像“海格力斯和凯克斯”；近年来的好莱坞电影《宙斯之子：赫拉克勒斯》、《大力神》等。
Graph of the Gods 讲述了一个删减版的海格力斯传奇。海格力斯是宙斯的儿子，他的母亲Alcmene（阿尔克墨涅）是一个凡人，因此他获得了某种神的属性，成为半人半神。天后赫拉因为嫉妒改变了海格力斯的命运，迫使他必须完成的“十二试炼”（Twelve Labours），这是十二项几乎无法完成的挑战。
项是杀死凶猛的狮子Nemean（尼米亚），尼米亚是一头从月亮上掉下来的狮子，巨大无比，任何人间的武器都无法穿透它的狮皮，海格力斯终还是用神力勒死了它，在雅典娜的指点下用狮子的利爪剥下了狮皮并做成盔甲，而死去的尼米亚则化作了星空中的“狮子座”。
第二项是杀死Hydra（九头蛇海德拉），海格力斯同样完成了任务，并用海德拉的血来浸泡他的箭头，被射中的人必死无疑。在某些版本的神话中，尼米亚与海德拉之间还有一段凄美的爱情故事。
第十二项是冥界看门犬Cerberus（刻耳柏洛斯），海格力斯的任务是将其从冥界带到人间，而后再带回冥界。海格力斯来到冥界请求冥王哈迪斯允许他带走刻耳柏洛斯。哈迪斯答应了他的请求，但条件是海格力斯要徒手与刻耳柏洛斯搏斗，终英雄凭借神力降伏了三头犬。
在成功完成十二试炼后海格力斯又经历了很多事情，终死后成为大力神并迎娶青春女神赫伯为妻，永远生活在奥林匹斯山。当然十二试炼后的故事就和Graph of the Gods没有关系了。
背景资料讲得差不多了，各位看官不妨回到文章头部的 Graph of the Gods 再去看看其含义，是不是更清楚了一些。
下面让我们回到技术视角分析下如何通过结构化的形式来表达上述的人物关系。
逻辑模型解读
图数据库的一个特点是逻辑模型与物理模型是非常接近的，或者说就是合二为一的，限于篇幅，本文仅作逻辑模型方面的解读。
节点（Node）和边（Edge）是构造图模型的基本元素，两者都可以附加属性（Property）来增强表述能力，此外还引入了标签（Label）用于丰富节点的层次结构，从而更简练的勾勒出了故事中的主要人物关系和情节。
通常，附加了属性的图被称为属性图（PG），增加标签后称为标签属性图（LPG），Graph of the Gods就是一个标准的LPG。
节点
节点可以被赋予了不同的标签（Label），标签的引入极大提升了图模型的表现能力，标签与面向对象中的类概念相通，可以对节点进行再次组织。图中的节点被分为六种不同的标签，我们再归并为三大类。
>人物
titan：第二代神族，故事里只出现了一位，Satum
god：第三代神族，宙斯、海神、冥王
demigod：半神，海格力斯
human：海格力斯的母亲，Alcmene
上述四类采用同样属性结构，即名称和年龄属性。
>地点
location：包括sky,sea,tartarus
>怪兽
monster：包括尼米亚狮子,九头蛇海德拉, 冥界看门犬
边（关系）
图中没有显式表达边的类型，通过三种不同的连线符号表示，空心箭头、实心箭头、带十字尾的实心箭头。
三类边的共同特点是具有方向性，也就是“有向边”，所以构成的图称为为“有向图”。从图的构成来说，也可以是无向边进行连接，很多工具都是支持无向边的，比如R。但增加“方向”这个元素后，有向边显然更具有表现力，所以图数据库往往都是支持有向边的，而在JanusGraph中则规定必须使用有向边，不能定义无向边。
JanusGraph中边的标签类型共有五种，包括
MULTI
SIMPLE
MANY2ONE
ONE2MANY
ONE2ONE
这五种标签类型不同于上文提到的三种不同符号的边，而是更高层次的抽象，不同类型代表了对所连接节点及其之间关系的不同约束。MULTI与SIMPLE是用以约束所连接的两个节点间是否允许存在同类关系，而后三类关系是约束所连接节点与其他节点产生同类关系的出度、入度。后三类关系在前两类的基础上做了进一步的增强表述。
>空心箭头
UML采用了类似的空心箭头用以表示实体间的继承关系，箭头所指方向为父类，尾部为子类。图中mother,father两种关系都采用这种符号，在语义似乎是很接近的。
但事实上，我们上述谈到五种类型中并没有直接体现继承的语义。mother,father这两类关系可以被抽象为MANY2ONE，关系尾部所指向的节点，其出度只能，而头部所指向节点，其入度是没有限制的。孩子只能有一个母亲（父亲），而母亲（父亲）可以有多个孩子。
>实心箭头
实心箭头表示关联关系，在两个节点中无明显的方向关系，则可以使用双向箭头来表示，实际上是两条边，例如图中的brother；而有些场景可以确定单一方向，例如pet。
表达兄弟关系，显然是SIMPLE，两个节点在同一方向上不会存在多个brother关系，因为这个关系是静态的；同时关系对节点的出度、入度显然也不构成约束，所以不适用后三类关系。
表达饲养宠物的关系，是反映属主的静态信息，在物品与属主之间显然也不存在多条边的必要性。反之，如果是某种动态的事件则适用于MULTI，例如账户之间的转账交易。
>十字尾的实心箭头
带十字尾的是实心箭头代表lives，按照我们刚刚的分析逻辑，如果是模糊的居住状态，则一样是个SIMPLE类型的关系；如果是某个时刻非常严格的位置关系，则应该是MANY2ONE，因为某个事物在同一时刻只能处于一个位置，而这个位置可以容纳多个事物。
属性
除名称外，关系还可以附加属性。
lives关系的属性为reason，用于标注选择居住地的原因。
battled关系附加了两个属性，其中time用以表示十二试炼的次序编号；place是一个二维数组表示发生的地点，两个数字分别代表北纬与东经，比如北纬38.1,东经23.7，恰好是雅典城的北部，也就是尼米亚所在位置。
建模过程的取舍
在宙斯三兄弟与其父亲的联结关系中，在宙斯与克洛诺斯之间标注了直接的父子关系，海神与冥王仅与宙斯标注了兄弟关系，间接体现了与克洛诺斯的父子关系。为什么不是采用直接的父子关系来组织这四位大神呢，父子加兄弟，使用两类关系是不是更繁琐呢？
Ivan认为这和关系型数据库建模一样，取舍之道在于模型是否能更准确的体现业务场景。我们前面提到的故事中，杀父救兄的人是宙斯，其他兄弟与父亲的关系不是故事的主线，因此以宙斯为核心来表现四者之间的关系，显然更准确的反映了场景。
实际应用中，在进行业务建模时我们也会面临类似的取舍。
