图数据库架构语言PG-Schema获最佳论文奖

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

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

标签属性图

标签属性图（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定义中封装的六个元素组成：

前三行引入了所谓的节点类型：person、customer和account；它们描述了图形数据中节点的结构约束。例如，customer节点类型告诉我们，可以有带有标签Customer的节点，这些节点携带属性customerId，并从更一般的person节点类型派生。具体来说，这意味着带有标签Customer的节点继承了在person节点类型中定义的属性name和birthDate。请注意，属性还指定了数据类型（如string、date或数值），并且可能被标记为可选的。
边类型建立在节点类型之上，并指定连接节点的边的类型和结构。我们的示例定义了一个单一的边类型，连接节点类型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标签的节点必须具有name但可能具有任意一组其他（未知）属性，而无需枚举整个集合）。这些机制产生的灵活性使得定义部分模式变得容易，这些模式可以逐步调整和细化，以捕获上述草图模式演进需求。

PG-Schema不仅为图模式和约束语言提供了具体建议，而且还旨在提高对标准化图模式方法重要性的认识。论文中的概念和思想由图空间的主要公司和学者共同开发，并且LDBC内部正在进行的倡议旨在标准化这些概念。

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