为什么需要知识图谱？

关系数据库非常适合创建列表，但在管理多样化实体网络方面表现糟糕。你是否曾尝试用关系数据库做以下任务：

•分析一个病人在接受护理过程中与数十个医生、地点和程序的互动•发现涉及供应商、客户和交易类型的金融诈骗模式•优化供应链中依赖关系和互联元素

这些都是事件、人物和资源网络的例子，使用关系数据库的 SQL 分析师会因此头痛不已。随着网络规模的增加，关系数据库变得指数级变慢，而图数据库的性能则相对呈线性关系。如果你管理的是活动和事物的网络或网状结构，那么图数据库是最佳选择。未来，我们应期望看到企业数据组采用关系数据库进行单一业务功能的孤立分析，并使用知识图谱处理跨功能的复杂网络流程。

基于图数据库技术的知识图谱，旨在处理多样化的流程和实体网络。在知识图谱中，你有代表人物、事件、地点、资源、文档等的节点，还有代表节点间连接的关系（边）。这些关系在数据库中以名称和方向物理存储。并非每个图数据库都是知识图谱。要被认为是知识图谱，其设计必须嵌入业务语义模型，反映在节点和关系的明确业务名称中，并涵盖多个业务功能的多样化节点集合。你实质上是在将所有相互作用的业务部分无缝连接起来，并使用业务语义紧密地将数据与它们所代表的流程绑定在一起。这可以作为未来生成式LLM模型使用的基础。

为了说明知识图谱中的多样化数据集，让我们来看一个简单的供应链物流例子。业务流程可能被建模如下：

这个模型可以扩展到包括业务流程的任何相关部分：客户退货、发票、原材料、制造流程、员工，甚至客户评价。没有预定义的模式，因此模型可以向任何方向或深度扩展。

从关系模型到维度模型再到图模型

现在，让我们通过一个电商供应商的场景，逐步讲解如何将典型的关系数据库模型转换为图模型。假设这个供应商正在运行一系列数字营销活动，通过网站接收订单，并将产品运送给客户。关系模型可能如下所示：

如果我们将其转换为数据仓库使用的维度模型，模型可能如下所示：

注意，事实表集中于事件，而维度表将一个业务实体的所有属性组合成一个表。这种以事件为中心的设计加快了查询时间，但也带来了其他问题。每个事件都是一个独立的事实表，很难看出一个事件与相关事件之间的联系。没有简单的方法理解维度实体（如产品）与另一个维度实体（如承运人）共享的所有事件之间的关系，因为这些关系分散在多个事实表中。维度模型关注单个事件，但模糊了不同事件之间的连接。

图模型通过如下方式建模流程，解决了实体之间相互关联的问题：

初看之下，这个图模型与关系模型相比更相似，但它可以用于与数据仓库相同的分析目的。注意每个关系都有名称和方向。关系可以在任何节点之间创建——事件到事件，人物到人物，文档到事件等。图查询还允许你以 SQL 不可能的方式遍历图。

例如，你可以收集与某个关键事件相关的所有节点，并研究其发生模式。层次结构得以保留，每个级别可以单独引用，不像非规范化的维度表。最重要的是，图在建模业务中的任何事件或实体时更加灵活，无需遵循严格的模式约束。图被设计成与业务的语义模型相匹配。

提取、转换和加载（ETL）

现在，让我们看一个示例关系数据库表，并创建一些示例脚本，将数据提取、转换并加载到图数据库中。本文将使用 Neo4j 的 Cypher 语言，这是最流行的商业图数据库。但这些概念也适用于其他变体的图查询语言（GQL）。我们将使用以下示例产品表：

使用以下查询可以提取最近24小时内更新的新产品：

SELECT product_id,product_name,cost_usd,product_statusFROM ProductWHERE last_updated_date > current_date -1;

我们可以将这些结果提取到一个名为“df”的 Python Pandas 数据帧中，打开一个图数据库连接，然后使用以下脚本将数据帧合并到图中：

UNWIND $df as rowMERGE INTO (p:Product {product_id: row.product_id})SET p.product_name = row.product_name,p.cost_usd = row.cost_usd,p.product_status= row.product_status,p.last_updated_date = datetime();

第一行引用了一个参数“df”，即来自 Pandas 的数据帧。我们将合并到节点类型“Product”，它由别名“P”引用。然后，“product_id”部分用于绑定到节点中的唯一标识符。之后，Merge 语句看起来类似于 SQL 中的合并。

在使用类似上述的合并语句创建了每个节点后，我们创建关系。关系可以在同一脚本中创建，也可以在后处理脚本中使用如下的合并命令创建：

MATCH (p:Product), (o:Order)WHERE p.product_id = o.order_idMERGE (o)-[:CONTAINS]->(p);

Match 语句看起来像 Oracle 中的传统连接用法，在 Match 之后声明两个节点类型，然后在 Where 子句中进行连接。

图模型上的查询 

假设我们已经构建了图，现在想查询它。我们可以使用如下查询查看推动亚利桑那州订单的广告组：

MATCH (ag:AdGroup)<-[:BELONGS_TO]-(a:Ad)-[:DRIVES]->(o:Order)<-[:PLACES]-(c:Customer)WHERE c.state = 'AZ'RETURN ag.group_name,COUNT(o) as order_count

这个查询将返回广告组名称和订单数量，筛选条件为亚利桑那州。注意，在 Cypher 中不需要 Group By 子句，这与 SQL 不同。从这个查询中，我们将得到如下示例输出：

这个示例看起来可能很简单，因为你可以轻松地在关系数据库或数据仓库中使用订单事实表创建类似查询。但让我们考虑一个更复杂的查询。假设你想查看从营销活动启动到相关交付收到的时间。在数据仓库中，这个查询将跨越事实表（不是一个简单的任务）并消耗大量资源。在关系数据库中，这个查询将涉及一长串的连接。在图数据库中，查询如下所示：

MATCH (cp:Campaign)<-[:BELONGS_TO]-(ag:AdGroup)<-[:BELONGS_TO]-(a:Ad)MATCH (a)-[:DRIVES]->(o:Order)<-[:FULFILLS]-(d:Delivery)RETURN cp.campaign_name,cp.start_date as campaign_launch_date,MAX(d.receive_date) as last_delivery_date

我使用了一个示例查询路径，但用户可以采取多种路径来回答不同的业务问题。在查询中，注意从 Campaign 到 Delivery 的路径经过 Order 和 Delivery 之间的关系。为了可读性，我将路径分成两部分，从第二行的 Ad 别名开始。查询的输出如下所示：

结论 

我们已经看了一些将电子商务业务流程从关系模型转换为图模型的示例步骤，但我们无法在一篇文章中涵盖所有设计原则。希望你已经看到，图数据库所需的技术技能与关系数据库相当，迁移并不是一个巨大的障碍。

最大的挑战是重新训练你的思维，远离传统的关系建模技术，转而使用语义或，业务建模。如果你看到了图技术的潜在应用，试着进行一个概念验证项目。使用知识图谱进行分析的可能性远远超过二维表格！