二、为什么选择知识图谱？

        关系数据库非常适合创建列表，但对于管理不同实体的网络来说却很糟糕。您是否曾经尝试过使用关系数据库执行任何这些任务？

• 分析患者与数十人、地点和程序互动时的医疗保健护理事件
• 通过涉及的供应商、客户和交易类型网络查找金融欺诈模式
• 优化供应链的依赖关系和相互关联的元素

        这些都是事件、人员和资源网络的例子，这些事件、人员和资源给使用关系数据库的 SQL 分析师带来了巨大的麻烦。随着网络规模的增加，关系数据库的速度呈指数级增长，而图形数据库具有相对线性的关系。如果您正在管理活动和事物的网络或 Web，图形数据库是正确的选择。在未来，我们应该期待看到企业数据组采用关系数据库的组合，对一个业务功能进行孤立的分析，以及知识图谱的组合，用于跨功能的复杂网络化流程。

        基于图形数据库技术的知识图谱旨在处理各种流程和实体网络。在知识图谱中，您具有表示人员、事件、地点、资源、文档等的节点。并且您具有表示节点之间链接的关系（边）。这些关系以名称和方向物理存储在数据库中。并非每个图形数据库都是知识图形。要被视为知识图谱，设计必须将业务语义模型嵌入到跨越多个业务功能的各种节点集中，该模型反映在节点和关系的清晰业务名称中。实质上，您是在从交互的业务的所有部分创建一个无缝的网络，并使用业务语义将数据与它们所代表的流程紧密联系在一起。这可以作为未来生成LLM模型使用的基础。

        为了说明知识图谱中的各种数据集，让我们看一个简单的供应链物流示例。业务流程可以按如下方式建模：

供应链图数据库模型。图片由作者提供。

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

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

        现在，让我们了解一下使用电子商务供应商的方案将典型的关系数据库模型转换为图形模型的过程。假设该供应商正在运行一系列数字营销活动，在其网站上接收订单，并将产品运送给客户。关系模型可能如下所示：

电子商务关系数据库模型。图片由作者提供。

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

电子商务维度模型（数据仓库）。图片由作者提供。

        请注意，事实数据表侧重于事件，维度表表示合并到一个表中的业务实体的所有属性。这种以事件为中心的设计提供了更快的查询时间，但会产生其他问题。每个事件都是一个不同的事实数据表，很难看到从一个事件到相关事件之间的联系。当维度实体（如产品）与另一个维度中的实体（如运营商）共享的所有事件（在多个事实数据表之间拆分时），没有简单的方法可以理解这些关系。维度模型一次关注一个事件，但模糊了不同事件之间的联系。

        图模型通过对过程进行建模，解决了显示实体之间相互关联的问题，如下所示：

电子商务图数据库模型。图片由作者提供。

        乍一看，该图模型与关系模型比维度模型更相似，但它可以用于与数据仓库相同的分析目的。请注意，每个关系都有名称并具有方向。可以在任何节点之间创建关系 - 事件与事件、人与人、文档与事件等。图形查询还允许您以 SQL 无法实现的方式遍历图形。

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

四、提取、转换和加载 （ETL）

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

产品表。 

        使用此查询，我们可以提取过去 24 小时内更新的新产品：

SELECT product_id,
  product_name,
  cost_usd,
  product_status
FROM Product
WHERE last_updated_date > current_date -1;

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

UNWIND $df as row
MERGE 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 的数据帧。我们将合并到节点类型“产品”中，该节点类型由别名“P”引用。然后，“product_id”部分用于绑定到节点中的唯一标识符。之后，Merge 语句看起来类似于 SQL 中的合并。

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

MATCH (p:Product), (o:Order)
WHERE p.product_id = o.order_id
MERGE (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

        此查询将返回广告组名称和订单数量（按亚利桑那州过滤）。请注意，与SQL不同，Cypher中不需要Group By子句。从该查询中，我们将收到以下示例输出：

图形查询的示例结果。图片由作者提供。

        此示例可能看起来微不足道，因为您可以使用订单事实数据表在关系数据库或数据仓库中轻松创建类似的查询。但是，让我们考虑一个更复杂的查询。假设您想查看从广告系列启动到收到可归因投放所花费的时间。在数据仓库中，此查询将跨事实数据表（不是一个简单的任务）并占用大量资源。在关系数据库中，此查询将涉及一长串联接。在图形数据库中，查询如下所示：

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

        我使用了一个示例查询路径，但用户可以采用多种路径来回答不同的业务问题。在查询中，请注意，从“营销活动”到“投放”的路径经过订单和投放之间的关系。另请注意，为了便于阅读，我将路径分为两部分，从第二行中的 Ad 别名开始。查询的输出如下所示：

        图形查询的示例结果。图片由作者提供。