TigerGraph | 图数据库建模佳实践

（一）引言
我们知道，家庭物品收纳整理有个重要的原则，就是分类。人们不会把所有的衣物乱堆在一起，而会按衣服的用途、颜色等等进行分类，这样衣物才会井然有序，容易取用。

类似的，现代企业的数据容量爆发式增长，如果没有数据模型，数据就会杂乱无章。人们需要对数据按业务概念进行抽象和归类，设计数据结构，让数据各归其位，这就是数据建模的过程。

（二）数据建模的重要性
数据建模影响重大，因为它是业务与技术之间的桥梁。企业从数据库的建立之初，到日常的数据分析，无时无刻不与数据模型打交道。

当业务人员对日常数据进行分析时，当决策层依据数据做决策时，必需要将业务语言依据数据模型转化为查询。一个好的数据模型，能让数据分析人员容易理解，也容易使用，并且解决日常的业务问题性能足够、消耗的资源足够少。因此设计模型有比较强的查询用例导向性。

对于分析类的数据库来说，数据建模还要考量输入数据格式。我们要基于已有的数据挖掘其中的信息，而不能脱离实际。

二、数据建模的常用方法
（一）E-R模型
数据建模常用的方法，就是E-R（实体-关系）模型，它在传统的关系型数据库中就已经非常流行，其本质上是一种图的方法，也就是关心数据中有哪些实体，有哪些属性可以用来描述这些实体，实体与实体之间有哪些重要的关系，然而再将这些实体、关系和属性的类别进行抽象。

举个例子，学校里有很多学生、很多老师，也开了很多课堂，那么就可以把学生、老师和课堂抽象成三类实体。我们会发现，容易抽象为实体的类型往往是一些名词。每个实体都有一些描述本身特征的点，比如描述老师的姓名、性别、年龄等等，这在数据模型中称为属性。而实体与实体之间常常都有某种关系，比如李学生参加语言课，王老师教语文课，那么学生与课程之间的参加关系、老师与课堂之间的教的关系，可以抽象成两类关系。关系经常会是一些动词。

（二）用图描绘E-R模型
有很多种描绘E-R模型的方式，比如UML。不管哪样的表达方式，我们明显可以看到E-R模型就是一种图状的模型。

我们都知道，关系型数据库终落地都是一张张独立的表，表与表之间的关联关系并不直接，以至于很多新手数据分析师都忘了关心设计之初的E-R模型。近十多年大数据的发展，虽然大大提升了对大数据的存储和计算能力，但是深层的分析方法仍然没有脱离表的思维方式。而用表去表达图状的E-R模型，既不直观，又缺少灵活性，还牺牲了查询的性能和深度分析的能力。

直到遇到了原生的图数据库，我们看到它在设计上、使用上都高度重视关系，将关系视为“一等公民”，数据建模才能完美实现E-R模型，数据模型也能反映业务概念，数据查询的表达能力也发生了质的飞越，以往觉得很难的查询在图中表达起来直接而又高效。

三、图数据库建模佳实践
以下将以TigerGraph为例，介绍图数据库数据建模的佳实践。其中涉及九大主题，从点到面，逐步展开。由于篇幅有限，本文只细述了前三点，剩余内容欢迎大家移步TigerGraph官网观看webinar。

（一）哪些可以作为点？哪些可以作为边？
一般而言，图数据库建模中，会把实体或者抽象的概念定义为顶点，把关系定义为边。举例：

（一）把实体定义为顶点

比如：人、用户、公司、账号、产品、地址、电话号码和设备等。

（二）把抽象的概念定义为顶点

比如：类型、状态和角色等。

（三）把关系定义为边

比如：（某人和另一人）是同事关系、（员工）工作于（公司）、（公司）受（另一公司）控股、（人）拥有（账号）、（客户）购买（产品）、（员工）住在（地址）、（产品）属于（类型）等。

（二）选择边的类型：无向边？有向边？反向边？

有向边和无向边
边按有无方向性分为有向边和无向边。有向边具有方向性，只能从它连接的一个点跳到另外一个点，而不能从另外一个点反过来跳回个点。无向边则无此限制，可以从任一点跳到另一点。有些图数据库支持无向边，有些则不支持，只能通过两条有向边来实现无向边的功能。TigerGraph是同时支持有向边和无向边的。

虽然无向边存储空间比有向边多，但从实践的经验上看，无向边能表达更多的业务场景，因为未来很可能存在两个顶点互相跳来跳去的情况。比如学生参与课堂的例子，可能以课堂为起点，通过参与这条边去查询参与该课堂的学生，也可能以学生为起点通过参与这条边去查询该学生参与的课堂。

如果一条边连接的两个顶点是不同类型的顶点的话，在查询时通过限制起始顶点的类型，相当于指定了方向。因此大部分场景，优先考虑使用无向边。

即使一条边连接的两个顶点是相同类型的顶点，也可能用无向边表示，比如朋友关系就是没有方向性的。

只有一条边连接的两个顶点是相同类型的顶点，同时又要指明方向，比如社交网络中的关注关系，起点和终点都是用户，但一个是关注人，一个是被关注人，关注关系是具有明确的方向性，此时非用有向边不可。

反向边
仍以社交网络中的关注关系为例，假如查询用例中既有查询用户关注了谁，也有查询用户被谁关注的场景，那么单单使用有向边就不够了。此时需要有向边结合反向边才能实现该功能。比如既要有关注这条边，也要被关注这条与之一一对应的边。

在TigerGraph中，用户定义有向边时，可以配置为反向边，此时反向边是随着有向边的创建而同时创建的，并且其拥有与相应有向边一模一样的属性。

（三）边类型的颗粒度

当两个顶点之间有多种关系时，有两种选择：一是将每种关系定义为一类边；二是将所有关系定义为一类边，并通过关系类型字段来区分这到底是哪类边。

前者的优点是，当遍历某一类边时，性能更优，但当遍历所有边时，语句不够简洁，尤其是当边的类型非常多时，会使schema过于庞大。后者则相反。

一般来说，要考虑两个因素，一是边的类型有多少，二是对所有边进行查询的情况居多还是对个别类型的边进行查询的情况居多。