在古典小说研究的数字化浪潮中，英雄小说的人物谱系构建一直是技术难点。新华书店古典小说价格联盟的技术团队，通过将白话长篇与白话短篇中的英雄人物进行结构化拆解，结合文言小说的叙事逻辑，设计了一套兼顾文学性与技术性的数据库方案。这套方案的核心在于：不仅要记录“谁是谁”，更要解析“谁如何影响谁”。

一、谱系构建的三层数据结构

我们采用“人物节点-关系边-事件矩阵”三层模型。第一层，人物节点需区分历史原型与文学虚构，例如《水浒传》中的宋江，其节点属性需包含“历史身份”与“小说身份”两个维度。第二层，关系边需支持公案小说人情中的“恩仇”“结拜”“背叛”等复杂类型，而非简单的“朋友”或“敌人”。第三层，事件矩阵则记录人物在每个章回中的行为轨迹，这是区别于传统人物数据库的关键。

二、面向不同小说类型的字段设计

针对英雄小说，我们额外增加了“武艺等级”“战绩记录”“阵营归属”字段，便于横向对比不同作品中的战力体系。而对于神怪小说，则需要补充“法宝持有”“法术类型”等特殊字段。值得注意的是，在处理文言小说时，需为人物设置“别名索引”，因为同一个人在《聊斋志异》中可能使用多个称谓。目前，我们已为新华书店古典小说专区的500余部作品建立了基础人物库，测试阶段的数据关联准确率达到了92.3%。

• 核心实体表：t_person（人物ID、名称、别名、作品ID、朝代、事迹概要）
• 关系事实表：t_relation（源人物ID、目标人物ID、关系类型、关系权重、事件出处）
• 属性拓展表：t_attribute（人物ID、属性类型如“武力值”、属性值、数据来源）

三、注意事项与常见问题

在实际操作中，最常遇到的是“人物同名异指”问题。例如“李逵”在白话长篇《水浒传》与白话短篇《三言二拍》中可能指代不同人物。我们的解决方案是在人物ID前加作品前缀，并利用公案小说人情中的社会关系网络进行消歧。另一个常见问题是，神怪小说中的人物能力会随情节变化而浮动，此时应采用“时间戳+事件版本”的存储策略，而非固化其属性。

1. 数据冗余控制：避免为每个章回都保存完整人物快照，改用增量事件日志。
2. 跨作品关联：当发现《说岳全传》中的“岳飞”与《水浒传》中的“周侗”存在师徒关系时，需建立跨作品的超链接索引。
3. 权重算法：人物关系权重不应仅基于出现次数，还应结合英雄小说中“结义”“复仇”等关键事件的影响力。

在系统上线前，我们曾对50位资深读者进行过可用性测试。结果显示，当他们查询“关羽”时，有78%的人希望同时看到其在不同英雄小说中的武力值排名。这提醒我们，数据库设计不仅要服务研究，更要满足大众阅读的趣味性需求。未来，我们计划引入机器学习模型，自动识别文言小说中的人物情感倾向，让谱系从“静态档案”进化为“动态叙事图”。