图形数据建模基础知识

原文链接：https://graphacademy.neo4j.com/courses/modeling-fundamentals/8-adding-intermediate-nodes/2-c-add-intermediate-node/

1. 图数据模型基础

核心概念：

• 节点（Node）：表示一个实体，例如人、电影、公司。
• 关系（Relationship）：表示两个节点之间的联系，例如“朋友”、“喜欢”、“雇佣”。
• 标签（Label）：节点的分类（如 :Person, :Movie）。
• 属性（Property）：节点或关系上的键值对，比如名字、出生年份等。

示例：

MERGE (p:Person {name: 'Tom Hanks'})
MERGE (m:Movie {title: 'Forrest Gump'})
MERGE (p)-[:ACTED_IN]->(m)
                              
// MATCH (m:Movie {title: 'Forrest Gump'})
// DETACH DELETE m

Tom Hanks 作为演员出演了 Forrest Gump。

---

2. 建模节点（Entity Design）

原则：

• 识别实体：从业务需求中提取实体，例如：电影系统中的“电影”、“演员”、“角色”。
• 避免过度实体化：不是所有数据都要做成节点，比如“上映年份”更适合作为属性，而不是单独节点。

示例：

✅ 合适的建模：

MERGE (:Movie {title: 'Inception', released: 2010})

❌ 不推荐的建模（过度实体化）：

MERGE (:Movie {title: 'Inception'})-[:RELEASED_IN]->(:Year {value: 2010})

您可以通过运行以下代码来验证是否已创建节点：

MATCH (n) RETURN n

---

3. 建模关系（Relationship Design）

原则：

• 明确两个节点之间的业务语义。
• 给关系命名时使用动词（如：ACTED_IN, DIRECTED, FOLLOWS）。
• 关系可以拥有属性（例如“评分”、“角色名”等）。

示例：

MERGE (:Person {name: 'Keanu Reeves'})-[:ACTED_IN {role: 'Neo'}]->(:Movie {title: 'The Matrix'})

---

4. 测试图模型

目的：

• 用小量数据验证模型是否支持你预期的查询。
• 检查结构是否清晰、是否冗余。

例如：你能否快速查询“Keanu Reeves 演过哪些电影”？

MATCH (p:Person {name: 'Keanu Reeves'})-[:ACTED_IN]->(m:Movie)
RETURN m.title

---

5. 重构图模型（Refactoring）

场景：

• 建模的图表并不能回答所有用例。
• 出现了一个新的使用案例，您必须在数据模型中考虑该案例。
• 用例的 Cypher 性能不佳，尤其是在图形缩放时

方法：

• 合并/拆分节点
• 添加中间节点
• 改变关系方向或类型

示例：

重构前：

分析查询

您可以使用关键字PROFILE查看查询的性能。

PROFILE MATCH (p:Person)-[:ACTED_IN]-()
WHERE p.born < '1950'
RETURN p.name

在此查询的第一步中，我们看到返回了 5 行。 您可以想象，如果这是一个包含数百万个节点的满载图形，那么在步骤 1 中，它将需要检索大量 Person 节点，其中一些节点不是 actor。 优化此检索的一种方法是更改数据模型以包含 Person 节点的 Actor 标签。

重构后： 增加了 :Actor 标签：

MATCH (p:Person)
WHERE exists ((p)-[:ACTED_IN]-())
SET p:Actor

//使用重构后的查询
MATCH (p:Actor)
WHERE p.born < '1950'
RETURN p.name

语义正交标签

“语义正交”是一个花哨的术语，意思是标签彼此无关。 您应该注意不要在不同的上下文中使用相同类型的标签。 例如，对所有类型的节点使用区域对于大多数查询没有用。

下面是一个示例，其中 Person 节点和 User 节点都标有区域。 如果没有区域对这两种类型的节点都很重要的使用案例， 对 Person 节点和 User 节点使用相同的标签没有帮助。

别这样：