1.2 属性图模型与 Neo4j：四件积木与免索引邻接

1.2 属性图模型与 Neo4j

本节摘要：属性图模型只有四件积木——节点、关系、属性、标签——组合起来却能表达绝大多数业务拓扑。本节逐件拆解它们的语法与设计惯例，讲清"节点存名词、关系存动词"的建模口径，并解释 Neo4j 免索引邻接的实现原理：为什么走一步关系是常数成本。读完后你应当能对着一张业务草图，手工翻译出一幅属性图。

上一节我们说"图模型把关联当存储"，本节就来拆这个"存储"到底由什么构成。这是全册的理论地基，第 2 章的每一行 Cypher 都在操作这四件积木。

从一张草图说起

把 1.1 的社交场景画在白纸上：圆圈是人、方块是电影、箭头上写着"喜欢"。这幅涂鸦已经是一个合法的属性图——所谓属性图（Property Graph），指的就是节点与关系都可以携带属性的图模型。它比 RDF 三元组更贴近工程师的直觉：实体就是实体，关系就是关系，不必把一切都拆成主谓宾。

积木一：节点——存"名词"

节点代表实体：人、公司、电影、订单、设备。Cypher 里用一对圆括号表示：

// 三种常见写法：匿名节点、带标签、带标签与属性
()
(p:Person)
(p:Person {name: 'Alice', age: 30})
​

节点必须有唯一的内部 id，由存储引擎自动分配；业务上的唯一性（比如用户名不重复）不靠它，靠约束，第 3 章写入一节会专门处理。

积木二与三：关系与属性——存"动词"和"形容词"

关系永远有方向、有类型，且必须连接两个节点（允许自环，起点终点相同，但不允许悬空）。属性则是挂在节点或关系上的键值对：

// 一条完整的关系模式：方向 + 类型 + 属性
(Alice:Person)-[:LIKES {since: 2024, rating: 5}]->(Matrix:Movie)
​

注意 LIKES 关系自己带着 since 和 rating——这是关系型数据库做不到的自然表达：在关系库里"打分的元信息"只能单独建一张评分表，而在属性图里它就长在关系上。

建模惯例值得单独强调，因为它决定了后续所有查询的形状：

⚠️ 关系类型拼写是新手高发坑：Likes 与 LIKES 在默认配置下是两个不同的类型，MATCH 时静默查不到结果。团队约定一个大小写规范，从第一天起执行。

积木四：标签——节点的"分类目"

标签把节点分成逻辑集合，一个节点可以同时拥有多个标签。它的工程意义有两个：一是查询时圈定扫描范围，二是为索引与约束提供挂载点：

// 一个节点，两个标签：既是员工又是顾客
CREATE (n:Person:Customer {name: 'Grace', customerId: 'C-1001'})
​

标签不必事先注册，CREATE 时随手就长出来——灵活是灵活，代价是拼写错误同样静默生效。第 3 章讲约束时会看到如何用schema 手段兜底。

免索引邻接：为什么走一步是常数成本

这是 Neo4j 与"在关系库上模拟图"的实现级分水岭。直觉版本：每个节点旁边都存着一张小纸条，记录它牵着的每一条关系的物理地址。要找 Alice 喜欢什么，不需要在全库索引里搜"Alice"，直接顺着纸条跳过去即可。

节点记录 (Alice)
  ├─ 关系引用: LIKES  -> 关系记录 #8412  -> 指向节点 (The Matrix)
  ├─ 关系引用: LIKES  -> 关系记录 #8413  -> 指向节点 (Inception)
  └─ 关系引用: FRIENDS_WITH -> 关系记录 #8420 -> 指向节点 (Bob)
​

由此得到两条推论：其一，遍历成本只与"这一步牵出多少条关系"有关，与全图规模无关；其二，越热的节点（关联越多）访问它的邻接反而越快——缓存命中率高。第 5 章拆存储引擎时，会再深入到记录文件的页布局。

变式演练：把业务草图翻译成属性图

试着把下面的需求翻译成图：员工属于部门，部门属于公司；员工之间有"汇报"关系；员工参与项目，项目有预算属性。

// 参考建模（先自己画，再对照）
CREATE (g:Company {name: 'GaiaTech'})
CREATE (eng:Department {name: 'Engineering'})-[:BELONGS_TO]->(g)
CREATE (a:Employee {name: 'Alice'})-[:WORKS_IN]->(eng)
CREATE (b:Employee {name: 'Bob'})-[:WORKS_IN]->(eng)
CREATE (b)-[:REPORTS_TO]->(a)
CREATE (p:Project {name: 'Atlas', budget: 1200000})<-[:JOINS]-(a)
​

参考答案的设计取舍：REPORTS_TO 用关系而非属性，因为汇报链未来要做递归遍历（"向上找五级汇报人"）；预算留在 Project 节点上，因为它是项目的单值特征而非实体间关系。

再进一步：建模中的两个灰色地带

属性还是标签？ "VIP 用户"可以是一个属性 level: 'vip'，也可以是一个标签 :Vip。判据是：需要用它做图筛选的边界（"只在这些节点间建索引与约束"），就用标签；只是展示字段，就用属性。

关系方向选哪边？ 惯例是"从主语到宾语"：(员工)-[:WORKS_IN]->(部门) 而不是反着。查询时 Cypher 允许无方向匹配兜底，但建模期把方向定死，后续读写两侧都少踩坑。

这两个灰色地带没有标准答案，团队内部统一口径比选哪个更重要——建模评审时把它们写进团队的建模规约里。

本节要点回顾

• 属性图 = 节点 + 关系 + 属性 + 标签，节点存名词、关系存动词、属性存形容词、标签做分类；
• 关系有方向、有类型、可携带属性，永远不悬空；
• 标签是索引与约束的挂载点，一个节点可多标签；
• 免索引邻接让"走一步"是常数成本，这是图数据库性能叙事的物理根基；
• 命名规范（关系类型大写、属性驼峰）要从第一个节点开始执行。

模型已经立起来了，下一节动手：装环境、导数据、跑通第一条查询。