图数据库架构论文荣获最佳行业论文奖
SIGMOD会议上由某中心研究人员与合作者共同发表的论文提出了一种灵活的数据定义语言，能够实现复杂图数据库的快速开发。
在标准关系数据库将数据存储在链接表中时，图数据库将数据存储在图中，其中边表示数据项之间的关系。图数据库在单一客户视图、欺诈检测、推荐和安全等用例中很受客户欢迎，这些用例需要在数据之间创建关系并快速浏览这些连接。某中心的图数据库服务专为可扩展性和可用性而设计，允许客户在毫秒内查询数十亿个关系。
在这篇博客文章中，介绍了一项关于图数据库模式语言的联合工作，这项工作是在关联数据基准委员会（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定义中 enclosed 的六个元素组成：
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标准将包括一个丰富的数据定义语言，可能会采纳论文中提出的概念和想法。
