本文指导读者何时使用图数据库。您将了解使用数据库的好处、挑战以及需要考虑的事项。
近年来，图数据库的使用大幅增长，它们正在成为任何行业组织的有前途的解决方案。它们增加的灵活性使得以传统关系数据库无法做到的方式利用关系和连接变得更加容易。但是你怎么知道什么时候使用图数据库呢？在本文中，我们探讨了在考虑使用图数据库时应考虑的事项，并展示了完全不使用图数据库的最佳方法。
什么是图数据库？
图数据库是一种使用图论作为其数据模型基础的数据库。图数据库将连通性视为一等公民，使其比更老式的关系数据库更适合表示连通数据。
有两种类型的图技术：RDF/语义网和属性图。虽然语义 Web 标准存在的时间更长，但属性图已成为主导技术，而 Cypher 是采用最多的图查询语言。
本质上，属性图数据库中的数据模型由以下属性组成：
节点、边、属性和标签：
- 节点可以有属性。
- 节点可以有带有一个或多个标签的标签。
- 边是有向的并连接节点以在图中创建结构。
- 边可以有属性。
图数据库往往用于使用互连数据的应用程序。一些常见的用例包括：
- 推荐引擎
- 语义搜索
- 反洗钱
- 欺诈识别
- 360 度客户视图
除了这些应用程序之外，图数据库已成为有前途的解决方案，适用于不仅需要管理大量数据而且需要生成关键业务洞察力的组织。图数据库有望成为获得此类洞察力的最简单方法，因为它可以让我们更轻松地理解数据中的关系和上下文。
图数据库的挑战
但是，尽管有这些崇高的承诺，图数据库并没有征服世界。根据DB-Engines的数据，截至 2022 年 10 月，它们仅占数据库空间的 1.8%，与实现这些承诺相去甚远。
有几个原因可以解释采用图数据库的困难。它们可以总结如下：
建模高度互连的数据
由于图数据库的高表达能力和相关的复杂性，在图形中对数据建模并不容易。它类似于建模知识，也称为知识工程——一种需要高度专业化的工程师的高级技能。这使得图很难被一般开发人员受众采用，从而设置了很高的进入门槛。
保持数据的一致性
图数据库的另一个大问题是缺乏强制模式。图数据库主要将模式验证委托给应用层，无论是隐式还是显式。这使得难以构建具有复杂数据的应用程序，其中数据库中的数据一致性至关重要。图数据库中缺乏明确强制执行的模式可能成为广泛采用的主要障碍。
查询数据
查询图表也有其自身的困难。鉴于（隐式）数据模型控制可以表达的路径，您必须以某种方式设计您的查询以匹配该隐式数据模型。之所以这特别具有挑战性，是因为您可能没有以最佳方式对数据建模。此外，大多数图数据库缺少重要的建模结构，例如嵌套或 n 元关系，这会导致建模决策的不一致。有时您可能将关系定义为节点，有时则定义为边。您的查询可能并不总是触及正确的数据。
强类型数据库
克服这些挑战对于帮助实现图表的承诺至关重要。
这就是为什么我们开发了一种新型数据库：强类型数据库 TypeDB。
我们构建了 TypeDB（可用的开源），通过提供更高级的类型系统来抽象出图数据库的低级实现，使开发人员更容易处理复杂的数据。TypeDB 的类型系统基于以下核心概念。
实体关系模型
TypeDB 使使用众所周知的实体关系模型对数据建模成为可能。与图数据库不同，这意味着我们可以将任何 ER 图直接映射到我们在 TypeQL（TypeDB 的查询语言）中的实现方式，而无需经过规范化过程。这意味着我们在概念上将模型视为人类的方式也是我们在 TypeDB 中用代码实现它的方式。
TypeDB的模型由实体类型、关系类型和属性类型组成，并引入了角色类型。下面的示例显示了 TypeQL 中的基本模型是如何编写的：
define
person sub entity,
owns name,
plays employment:employee;
company sub entity,
owns name,
plays employment:employer;
employment sub relation,
relates employee,
relates employer;
name sub attribute,
value string;
在这个命名法中，正方形表示实体；菱形表示关系；椭圆表示属性。此图概述了一个包含两个实体（一个人和一个公司）的模型，并且两个实体都拥有一个名称属性。人在雇佣关系中扮演雇员的角色，而公司扮演雇主的角色。
类型层次结构
TypeDB 提供开箱即用的建模类型层次结构的能力，这是特征图数据库本身不支持的。遵循面向对象类型系统的原则，TypeDB 确保所有类型都继承其超类型的行为和属性。这使得复杂的数据结构可重用，并通过多态性使数据解释更加丰富。
在下面的示例中，建模了一个三级实体人员层次结构。它的所有子类型都将继承属性的_名字_和_姓氏，_而不必一一重新声明：
define
person sub entity,
owns first-name,
owns last-name;
student sub person;
undergrad sub student;
postgrad sub student;
teacher sub person;
supervisor sub teacher;
professor sub teacher;
此类型层次结构描述了一个类型为 person 的实体，该实体由学生和教师类型进行子类型化。学生分为本科生和研究生两种，教师分为导师、导师和教授两种。
嵌套关系
关系是描述两个或多个事物之间关联的概念。有时，这些东西本身就是关系，这意味着对直接引用另一个关系（嵌套关系）的关系进行建模。图数据库不允许对嵌套关系进行建模，这需要将二进制边指向二进制边。实现这一目标的唯一可能方法是通过_具体化_，将一条边转换为一个节点，以便另一条边可以指向它。
然而，TypeDB 确实允许嵌套关系，从而可以以最自然的形式对数据进行建模。在下面的示例中，类型 marriage 的关系被分配给变量_$mar，然后用于通过关系_located将其连接到__城市：
match
$alice isa person, has name "Alice";
$bob isa person, has name "Bob";
$mar ($alice, $bob) isa marriage;
$city isa city;
($mar, $city) isa location;
在这个图中，“Alice”这个人扮演妻子的角色，“Bob”这个人扮演婚姻关系中的丈夫角色。婚姻是一个嵌套关系，因为它也在位置关系中扮演定位的角色，其中“伦敦”城市在同一关系中扮演定位的角色。
N元关系
在现实世界中，关系不仅仅是两个事物之间的二元联系。这就是为什么通常需要同时捕获三个或更多相互关联的事物的原因。将它们表示为单独的二元关系会导致信息丢失，这就是图数据库中发生的情况。另一方面，TypeDB 可以自然地将任意数量的事物表示为一个关系，例如，无需具体化模型。
在此示例中，n 元关系_转换_连接了三个不同的实体：_人物_实体、_角色_实体和_电影_实体：
match
$person isa person, has name "Leonardo";
$character isa character, has name "Jack";
$movie isa movie, has name $movie-name;
(actor: $person, character: $character, movie: $movie) isa cast;
get $movie-name;
这是类型转换的 n 元关系的示例，特别是三元关系。这种关系涉及三个实体：电影“泰坦尼克号”扮演电影角色，“莱昂纳多”扮演演员角色，角色“杰克”扮演这个角色关系中的角色。
安全
与图数据库不同，TypeDB 提供了一种描述数据逻辑结构的方法，允许 TypeDB 验证您的代码是否正确插入和查询数据。查询验证超越了静态类型检查，包括对无意义查询的逻辑验证。有了严格的类型检查错误，你就有了一个可以信任的数据集。
_在下面的示例插入查询中， Charlie_和_DataCo_之间的关系将被拒绝，因为一个_人_不能与一家_公司_结婚（假设模式遵循现实世界）。
insert
$charlie isa person, has name "Charlie";
$dataCo isa company, has name "DataCo";
(husband: $charlie, wife: $dataCo) isa marriage; # invalid relation
commit>>
ERROR: invalid data detected during type validation
推理
最后，TypeDB 提供了一个内置的推理引擎，使 TypeDB 能够得出新的见解，并提供对这些见解的完整解释。另一方面，属性图不提供本机推理功能。
TypeDB 中的推理基于您的架构中定义的规则。在查询运行期间，如果满足数据集中的某种逻辑形式（如规则中定义的），系统将得出新的结论。就像编程中的函数一样，规则可以相互链接，在数据级别创建行为抽象。
使用下面的规则，TypeDB 将能够推断出一个_城市_位于一个 大陆，即使两者之间不存在明确的关系。
define
rule transitive-location:
when {
(located: $city, locating: $country) isa location;
(located: $country, locating: $continent) isa location;
} then {
(located: $city, locating: $continent) isa location;
};
使用自动推理，TypeDB 可以推断“卡姆登”行政区和“英国”国家之间的关系（虚线），即使它们没有直接连接。
结论
那么我们什么时候使用图数据库呢？图适用于依赖复杂且相互关联的数据的应用程序。然而，正如我们所见，它们缺乏广泛采用凸显了现有图数据库解决方案的主要失败和挑战。为了克服这些挑战并实现图数据库的最初承诺，我们构建了 TypeDB。
原文标题：When To Use a Graph Database?
原文链接：https://dzone.com/articles/when-to-use-a-graph-database
