Question

除了能够方便地将现实世界中互相关联的数据映射到图中，图形化数据模型还允许你以很有意思的方式使用数据。通过关注于领域中关系的值，可以找到新的视角和答案，它们都隐藏在关系之中，等着我们去发掘。

7.7.1 单个节点的多重角色

借助 Neo4j 无模式的特性，单一的节点或关系并不限于只能映射到一个领域类中。有时候，对于有限的范围/上下文，一种很好的方式就是将领域类构造为更小的概念/角色。

例如，Order 在生命周期不同阶段使用的方式会有所区别。根据当前的状态，它可能会是购物车、客户订单、派发单或回单。每个状态都会关联不同的属性、约束或操作。通常来讲，这会建模为多个实体并分别存储到各自的表中，或者只有一个 Order 类，然后作为很大很稀疏的一个行存储到表中。借助于图数据库无模式的特性，Order 可以存储到一个节点中，但是只包含当前状态（以及过去状态中包含的并且以后会继续需要的属性）所需要的属性（和关系）。通常，会在生命周期之中获取属性和关系，并且在完成时被简化和锁定。

Spring Data Neo4j 允许使用不同的类来对这种实体进行建模，每个类涵盖生命周期的某一个阶段。这些实体共享一些属性；每个又有一些唯一的属性。所有的实体映射到同一个节点之上，根据在使用 template.findOne(id,type) 进行加载时所提供的类型，或者在运行时使用 template.projectTo(object, type)，这样就能够在不同的上下文中使用不同的实体了。当所投影的实体要进行存储时，只有它目前的属性（和关系）会被更新；其他已有的会保持现状。

7.7.2 以产品分类和标签为例讲解图中的索引

为了处理更大的产品目录并简化信息的探查，将产品进行分类是很重要的。一个原始的方式就是为每个产品使用一个分类属性，这在长期可用性方面是有所不足的。在图中，每个实体有多个指向分类节点的关联关系是很自然的事情。添加一个分类树，这样每个树都能与其子树保持关系并且每个产品与其所在的分类也能保持关系，这是很简单的。典型的应用场景为：

• 基于分类树导航；
• 列出某个分类子树下的所有产品；
• 列出相同分类下的类似产品；
• 查找产品分类之间隐式/不明显的关系（如儿童护理产品与年轻父母的生活产品）。

对于标签也是一样，它比分类的限制性更小，通常会形成一个更自然的图，所有实体都与标签关联，而不是像分类这样的等级树。在图数据库中，多个分类和标签都会形成隐形的二级索引结构，它们能够以很多不同的方式对存储的实体进行导航式访问，还有其他的二级索引（如地理信息、时间相关的指标或其他有意思的维度），如示例 7-22 所示。

示例 7-22 产品的分类和标签

Category 形成了一个父子关系的嵌套组合结构。每个分类有一个唯一的名字和一组子类。Category 对象用来创建结构以及产品到分类之间的关系。为了使用产品之间的互联性，一个自定义（使用注解）的查询将会从起始（或根）分类开始，通过 0 到 5 个关系找到连接到这个子树上的产品。所有附着在关系上的产品将会作为列表返回。

7.7.3 利用类似的兴趣（协同过滤）

协同过滤（Collaborative filtering），如示例 7-23 所示，它基于这样的假设，那就是我们能找到其他的“人”，这些人与当前的用户相比具有类似的/可对比的兴趣和行为。至于用于描述相似的实际条件，如搜索/购买历史、评论等，都是与领域相关的。算法能够得到的信息越多，结果会越好。

在下一步中，将会考虑类似的人所购买或喜欢的产品（根据他们提到的次数以及/或他们的评分），除此之外，还可能会排除用户已经购买、拥有或不感兴趣的条目。

示例 7-23 协同过滤

7.7.4 推荐

几乎在所有的领域，尤其是电子商务领域之中，为用户推荐感兴趣的产品主要会使用所收集到的信息，这些信息来源于所评论的产品和购买行为。很显然，我们可以根据用户直接的评论来生成推荐，尤其是当缺乏实际的购买历史或没有关联的用户账号时。对于初始级别的建议来说，简单地按照数量和评论等级（或更为高级的评分机制）依序列出就足够了。

对于更高级的推荐来说，可以使用一些考虑到多个输入数据维度（如等级、购买历史、人口信息、广告曝光情况以及地理信息等）的算法。

示例 7-24 中的查询会查找顾客的所有评级信息并返回评级最高（取决于平均）的一页产品。

示例 7-24 简单的推荐