4、药物-靶点-疾病关系建模：实体与关系设计归纳总结
这一章我们来聊聊实体和关系怎么设计。说实话，关系建模做好了，后续的推理、查询都顺；做不好，后面各种坑等着你填。我做知识图谱这些年，最深的体会就是：关系比实体更容易翻车。
核心实体：三驾马车
药物重定位的知识图谱，离不开三个核心实体药物、靶点、疾病。每个实体都需要定义唯一的标识符，以及一套核心属性。我个人习惯用 UniProt ID 作为靶点实体的主键，DrugBank ID 作为药物主键，DOID 或 ICD-10 作为疾病主键。为什么？因为这几个数据库更新及时，且互相交叉引用，你想想看，后面做实体对齐的时候省多少事。
我在项目里踩过这个坑：一开始图省事，直接用名称字符串当实体 ID。结果同一种药有多个别名（比如阿司匹林也叫乙酰水杨酸），查询时匹配不上，数据乱成一团。后来全部换成标准 ID 才救回来。
下面是我常用的实体属性清单：
| 实体类型 | 推荐标识符 | 核心属性（示例） |
|---|---|---|
| 药物 | DrugBank ID | 名称、SMILES、分子量、给药途径 |
| 靶点 | UniProt ID | 基因名、物种、亚细胞定位、功能描述 |
| 疾病 | DOID / ICD-10 | 名称、ICD编码、症状、相关基因列表 |
关系类型设计：别只画一条线
关系是知识图谱的灵魂。药物、靶点、疾病两两之间至少存在三类关系。嗯，这里要注意每种关系的方向性和语义标签。
- 药物 → 靶点：如抑制、激活、调节。我个人建议尽量细化，比如"抑制"比"相互作用"更有价值。
- 靶点 → 疾病：如参与、导致、保护。此处的方向很重要——同一个基因在某些疾病中是致病靶点，在另一些疾病中可能是保护因子。我记得有一次团队把方向弄反了，推理出来的药物推荐完全不对。
- 药物 → 疾病：如治疗、预防、引起副作用。这是重定位推理的最关键关系，也是我们最终要预测的对象。
除了这三种，还可以有药物-药物（协同/拮抗）、疾病-疾病（共病关系）等辅助关系。但在最小可用模型中，先把核心关系的质量做扎实。
关系属性：别忘了带上证据
很多初学者只给关系加一个标签，忽略了关系本身也可以有属性。比如"药物抑制靶点"这条关系，可以带上IC50值、实验方法、文献PMID。没有这些证据属性的关系，在推理时很难评估可信度。
我的做法是用属性图模型（比如 Neo4j 的 labeled property graph），把证据信息挂载在关系上。下面是一个 Cypher 示例：
CREATE (d:Drug {id: "DB00001", name: "阿司匹林"})
CREATE (t:Target {id: "P23219", name: "COX-1"})
CREATE (d)-[:INHIBITS {
ic50: 1.2,
unit: "μM",
source: "PubMed:12345678",
assay: "酶活性抑制试验"
}]->(t)实体-关系拓扑总图
上面讲了不少细节，我画了一张核心结构图，帮你把它们串起来。这张图展示了最常见的三元关系回路：
你看，靶点位于中间，扮演桥梁角色。重定位的核心思路就是：药物 A 已知抑制靶点 X，靶点 X 已知参与疾病 Y，那么药物 A 很可能对疾病 Y 有治疗潜力。这个推理链就是最简单的三元组闭合。
设计总结：三原则与一清单
做了好几个知识图谱项目以后，我总结出三条设计原则：
- 标识先行：每个实体必须关联一个权威数据库的稳定 ID，不要用名称当主键。
- 关系要具体：一张表里超过 80% 的关系如果是"相关"就别做了——信息量太低。
- 证据留痕：关系的置信度、来源参考文献、实验条件，必须作为属性挂载。
最后附上一张检查清单，你可以对着看：
实体-关系设计检查清单
- ✅ 药物实体是否有唯一 ID（DrugBank ID）？
- ✅ 靶点实体是否有唯一 ID（UniProt ID）？
- ✅ 疾病实体是否有唯一 ID（DOID）？
- ✅ 药物→靶点关系是否区分抑制/激活/调节？
- ✅ 靶点→疾病关系是否标注方向（导致 vs 保护）？
- ✅ 药物→疾病关系是否包含副作用方向？
- ✅ 每条关系是否都带有置信度或证据来源？
做到以上几点，你的药物重定位知识图谱至少不会在建模阶段埋坑。下一个章节我会带你看看怎么把这些设计落地成代码。记住：关系设计的质量，决定了推理的上限。