图数据库架构论文获最佳行业论文奖

在标准关系数据库将数据存储在链接表中时，图数据库将数据存储在图中，其中边表示数据项之间的关系。图数据库在单客户视图、欺诈检测、推荐和安全等用例中受到客户欢迎，这些用例需要创建数据之间的关系并快速导航这些连接。某中心的图数据库服务旨在实现可扩展性和可用性，允许客户在毫秒内查询数十亿关系。

本文介绍了在图数据库架构语言方面的联合工作，该工作是在某非营利组织的支持下进行的，该组织汇集了图数据库领域的领先组织和学者。架构是定义数据库结构的一种方式——允许的数据类型、它们之间的可能关系以及逻辑约束（如实体的唯一性）。这项工作对客户很重要，因为它将允许他们以跨供应商可移植的方式描述和定义图的结构，并使构建图应用程序更快。这项工作在某计算协会数据管理特别兴趣组的年度会议上获得了最佳行业论文奖。

标签属性图

标签属性图（LPG）数据模型是构建图应用程序的一个突出选择。LPG基于三个原语来建模图形数据：节点、边和属性。下图显示了在金融欺诈场景中标签属性图的摘录。节点表示为绿色圆圈，边表示为连接节点的有向箭头，属性包含在橙色框中。

例如，标识符为1的节点标记为Customer，并带有两个属性，指定字符串值为“Jane Doe”的名称和customerId。节点1和2都连接到节点3，节点3表示具有固定iban号码的共享账户；两条边标记为Owns标签，指定了关系的性质。就像顶点一样，边可以带有属性。在此示例中，属性since指定2021-03-05作为所有权的开始日期。

关系型与图架构

图数据库与关系数据库的一个区别属性是，图数据库不需要显式的架构定义，而关系数据库需要预先定义架构且通常难以更改。为了说明差异，将上图中的图数据模型与可比的关系数据库架构进行比较，如下所示，主键属性带下划线。

关系模型的架构级信息——表和属性名称——在图数据库中作为数据本身的一部分表示。换句话说，通过插入或更改图元素（如节点标签、边标签和属性名称），可以隐式扩展或更改架构，而无需运行（通常繁琐的）架构操作，如ALTER TABLE命令。

例如，在图数据库中，可以简单地添加带有先前未见标签Knows的边来连接代表Jane Doe和John Doe的两个节点，或随时引入带有新标签（如FinancialTransaction）的节点。此类扩展将在关系示例架构中需要表操作。

缺乏显式架构是一个关键区别，降低了在图中开始数据建模和应用程序构建的负担：遵循按需付费范式，构建新应用程序的图应用程序开发人员可以从一小部分数据开始，并在应用程序演进时插入新的节点类型、属性和互连边，而无需维护显式架构。

架构演化

虽然这有助于构建图应用程序的初始速度，但通常看到的是——在整个图应用程序的生命周期中——从隐式架构转向显式架构变得可取。一旦数据库填充了图数据的初始（通常尚未完善）版本，就会出现对灵活架构支持的需求。

在该阶段，架构主要扮演描述性角色：了解最重要的节点/边标签及其属性告诉应用程序开发人员在数据中期望什么，并指导他们编写查询。随着应用程序生命周期的进展，图数据模型稳定，开发人员可能受益于更严格、规范性的架构方法，该方法强烈断言图中的形状和逻辑不变量。

PG-Schema

受这些需求的推动，SIGMOD出版物提出了一种称为PG-Schema的数据定义语言（DDL），旨在向用户展示架构灵活性的全部广度。下图显示了此类图架构的可视化表示，以及相应的语法表示，如数据架构师或应用程序开发人员可能提供的，以正式定义欺诈图示例的架构。

在此示例中，整体架构由顶级GRAPH TYPE定义中 enclosed 的六个元素组成：

GRAPH TYPE定义的前三行引入了所谓的节点类型：person、customer和account；它们描述了图数据中节点的结构约束。例如，customer节点类型告诉我们，可以有带有Customer标签的节点，这些节点带有属性customerId，并源自更通用的person节点类型。具体来说，这意味着带有Customer标签的节点继承在节点类型person中定义的属性name和birthDate。注意，属性还指定数据类型（如字符串、日期或数值），并可能标记为可选。
边类型基于节点类型，并指定连接节点的边的类型和结构。示例定义了一个单一的边类型，连接节点类型customer的节点与类型account的节点。非正式地说，这告诉我们数据图中Customer标记的节点可以通过带有Owns标签的边连接到Account标记的节点，该边注释有属性since，指向日期值。
最后两行指定了超出图结构的额外约束。KEY约束要求iban属性的值唯一标识账户，即没有两个Account标记的节点可以共享相同的IBAN号码。这可以认为是关系数据库中主键的等价物，主键在给定表范围内强制执行一个或多个属性的唯一性。第二个约束强制每个账户至少有一个所有者，这让人想起关系数据库中的外键约束。

还要注意图类型定义中的关键字STRICT：它强制图中的所有元素遵守图类型体中定义的类型之一，并且所有约束都得到满足。具体来说，它意味着我们的图只能包含带有各自属性集的Person-、Customer-和Account标记的节点，唯一可能的边类型是带有Owns标签的客户和账户之间的边，并且必须满足键和外键约束。因此，STRICT关键字可以理解为实现架构优先范式的机制，因为它是最大规范性的并强烈约束图结构。

为了考虑灵活和部分架构用例，PG-Schema提供了LOOSE关键字作为STRICT的替代方案，它具有更宽松的解释：定义为LOOSE的图类型允许未在图类型定义中明确列出的节点和边类型。在图类型级别类似于STRICT与LOOSE关键字的机制可以在语言的不同级别找到。

例如，关键字如OPEN（与隐式默认值CLOSED相对）可用于部分或完全指定带有给定顶点标签的顶点可以携带的属性集（例如，表达Person标记的节点必须具有名称，但可能具有任意一组其他（未知）属性，而不需要枚举整个集）。这些机制产生的灵活性使得易于定义部分架构，可以逐步调整和完善，以捕获上述架构演化需求。

PG-Schema不仅为图架构和约束语言提供了具体建议，而且还旨在提高对标准化图架构方法重要性的认识。论文中的概念和想法由图空间的主要公司和学者共同开发，并且某非营利组织内有 ongoing 倡议，旨在标准化这些概念。

特别是，某非营利组织与目前正在标准化新图查询语言（GQL）的ISO委员会有密切联系。由于一些GQL ISO委员会成员是PG-Schema论文的合著者，因此有持续的双边交流，并且预计GQL标准的未来版本将包括丰富的DDL，可能会采纳论文中提出的概念和想法。