图数据库，第2版

第 4 章 构建图形数据库应用程序 构建图形数据库应用程序

本作品已使用人工智能进行翻译。欢迎您提供反馈和意见：[e-mail]

在本章中，我们将讨论使用图形数据库的一些实际问题。在前几章中，我们已经了解了图形数据；在本章中，我们将在开发图形数据库应用程序时应用这些知识。我们将探讨可能出现的一些数据建模问题，以及可供我们选择的一些应用程序架构。

根据我们的经验，图形数据库应用程序非常适合使用当今广泛使用的进化、增量和迭代软件开发实践进行开发。这些实践的一个主要特点是在整个软件开发生命周期中普遍进行测试。在这里，我们将展示如何以测试驱动的方式开发数据模型和应用程序。

在本章的最后，我们将探讨在规划生产时需要考虑的一些问题。

数据建模

我们在第 3 章中详细介绍了图形数据的建模和处理。在此，我们总结了一些更重要的建模指南，并讨论了图形数据模型的实施如何与迭代和增量软件开发技术相匹配。

根据应用需求描述模型

我们需要对数据提出的问题有助于识别实体和关系。Agile 用户故事提供了一种简洁的方法，可以从外到内、以用户为中心来表达应用程序的需求，以及在满足这种需求的过程中产生的问题。¹下面是一个书评网络应用程序的用户故事示例：

作为一个喜欢一本书的读者，我想知道其他喜欢同一本书的读者喜欢哪些书，这样我就可以找到其他书来读。

这个故事表达了用户的需求，这也是我们数据模型的形式和内容的动机。从数据建模的角度来看，AS A 子句建立了一个上下文，包括两个实体--一个读者和一本书--以及连接它们的LIKES 关系。然后，I WANT 子句提出了一个问题：喜欢我正在阅读的这本书的读者还喜欢哪些书？这个问题揭示了更多的LIKES 关系和更多的实体：其他读者和其他书籍。

如图 4-1 所示，我们在分析用户故事时发现的实体和关系很快就转化成了一个简单的数据模型。

图 4-1. 书评用户故事的数据模型

由于该数据模型直接编码了用户故事中提出的问题，因此它适合以类似的方式进行查询，从而反映出我们想对数据提出的问题的结构，即既然爱丽丝喜欢《沙丘》，那就找到其他喜欢《沙丘》的人喜欢的书：

MATCH (:Reader {name:'Alice'})-[:LIKES]->(:Book {title:'Dune'})
      <-[:LIKES]-(:Reader)-[:LIKES]->(books:Book)
RETURN books.title

节点代表事物，关系代表结构

虽然并非适用于所有情况，但这些一般准则将帮助我们选择何时使用节点，何时使用关系：

• 使用节点来表示实体，即我们感兴趣的领域中的事物，它们可以被标记和分组。

• 利用关系来表达实体之间的联系，并为每个实体建立语义上下文，从而构建领域结构。

• 使用关系方向进一步明确关系语义。许多关系是不对称的，这就是为什么属性图中的关系总是有向的。对于双向关系，我们应该让查询忽略方向，而不是使用两个关系。

• 使用节点属性来表示实体属性，以及任何必要的实体元数据，如时间戳、版本号等。

• 使用关系属性来表达关系的强度、权重或质量，以及任何必要的关系元数据，如时间戳、版本号等。

勤于发现和捕捉领域实体是有好处的。正如我们在第 3 章中所看到的，使用漫不经心的关系名称来为本应表示为节点的事物建模是相对容易的。如果我们想使用关系来建模一个实体--例如电子邮件或评论--我们必须确保这个实体不能与其他两个以上的实体相关。记住，一个关系必须有一个起始节点和一个终止节点--不多也不少。如果我们后来发现需要将我们建模为关系的实体连接到两个以上的其他实体，我们就必须将关系内部的实体重构为一个单独的节点。这是对数据模型的破坏性更改，很可能要求我们对产生或消耗数据的任何查询和应用代码进行更改。 ...