中华诗词知识库 · 第三章数据结构设计Knowledge Base of Chinese Poetry (KBCP) — Chapter 3: SchemaGitHub 开源地址https://github.com/liang1057/Knowledge-Base-of-Chinese-Poetry如果资源对你有帮助欢迎 Star 支持JSON数据下载https://download.csdn.net/download/sdust_dx/92826598 前言前两章讲到了数据和数据清洗本章将正式进入数据层的核心设计——Schema模式定义。中华诗词的数据结构有一个显著特点半结构化与非结构化并存。一首诗的正文是自由文本但体裁、格律、意象、情感等属性又需要高度标准化。如果 Schema 设计过于简单后续 RAG 检索和知识图谱构建将举步维艰如果设计过于臃肿又会给数据清洗和入库带来巨大成本。因此本章的核心目标是在“文学自由表达”与“机器可理解”之间找到最佳平衡点。️ 一、总体的数据结构五表联动与词汇标准化整个知识库的底层采用SQLite作为关系型存储引擎Schema 层通过 ORM 风格封装了 5 张核心表形成如下关系表名职责关键关联poem诗词作品主表外键关联dynasty、authorauthor诗人/作者信息通过dynasty_id关联朝代dynasty朝代元数据独立基础表统一时间轴vocab受控词汇表全库标签体系的标准化源头myschema元数据记录记录 Schema 自身版本与变更注意所有标签类字段如genre、form、theme、style、emotion等均不存储自由文本而是指向vocab表的标准化键值。这为后续的多义词消歧、同义词扩展和向量检索打下了基础。这也是我重构了两次得到的经验。️ 二、核心表2.1 诗词表table_poem— 这也是全库最复杂的实体poem表是知识库的核心字段设计遵循**“分层存储、逐层解析”**的原则。经过多次完善已经达到了 40 个字段将其划分为 8 个逻辑层分层设计思路层级设计意图典型应用基础信息唯一标识与溯源全库去重、跨库对齐结构化内容将自由文本拆解为机器可处理的单元按句检索、格律校验、文本比对文学属性建立体裁与格律的标准化分类筛选“所有七言律诗”、检索“平水韵作品”扩展信息保留人类可读的释义与背景RAG 生成回答时的引用素材标签体系多维度语义标注向量检索的元数据过滤、主题冲突检测检索优化倒排索引与 faceted search 支持“春天的离别诗”“涉及长安的边塞诗”RAG 相关为向量库与知识图谱预留接口相似作品推荐、引用溯源管理字段数据治理与版本控制审核流程、增量更新classtable_poem(EntityBase):def__init__(self):super().__init__()self.SetTableName(poem)# 1. 基础信息层self.AddColumn(colNamepoem_id,colTypetext,...)self.AddColumn(colNametitle,colTypetext,...)self.AddColumn(colNameauthor,colTypetext,...)self.AddColumn(colNamedynasty,colTypetext,...)# 2. 结构化内容层self.AddColumn(colNamecontent,colTypetext,...)self.AddColumn(colNameparagraphs,colTypevarchar,...)self.AddColumn(colNamesentences,colTypevarchar,...)self.AddColumn(colNameline_count,colTypeint,...)self.AddColumn(colNamechar_count,colTypeint,...)# 3. 文学属性层self.AddColumn(colNamegenre,colTypetext,...)# 诗/词/曲/赋self.AddColumn(colNameform,colTypevarchar,...)# 五言绝句/七言律诗...self.AddColumn(colNamemeter,colTypetext,...)# 平水韵/中华新韵# 4. 扩展信息层self.AddColumn(colNamedescription,colTypetext,...)self.AddColumn(colNametranslation,colTypetext,...)self.AddColumn(colNameappreciation,colTypetext,...)self.AddColumn(colNamebackground,colTypetext,...)# 5. 知识增强与标签体系层self.AddColumn(colNametheme,colTypevarchar,...)self.AddColumn(colNamestyle,colTypevarchar,...)self.AddColumn(colNameemotion,colTypevarchar,...)self.AddColumn(colNameimagery,colTypevarchar,...)self.AddColumn(colNameallusions,colTypevarchar,...)# 6. 检索优化层self.AddColumn(colNamekeywords,colTypevarchar,...)self.AddColumn(colNameseason,colTypetext,...)self.AddColumn(colNamefestival,colTypetext,...)self.AddColumn(colNameplaces_involved,colTypevarchar,...)self.AddColumn(colNamepeople_involved,colTypevarchar,...)# 7. RAG 相关层self.AddColumn(colNamecitation_text,colTypetext,...)self.AddColumn(colNamealiases,colTypevarchar,...)self.AddColumn(colNamerelated_poem_ids,colTypevarchar,...)# 8. 管理层self.AddColumn(colNamecreated_at,colTypetext,...)self.AddColumn(colNamedata_version,colTypetext,...)self.AddColumn(colNamereview_status,colTypetext,...)几个关键字段的深入说明poem_id编码规则采用朝代编号-作者编号-诗词编号的三段式结构例如T-12345-678901。这种设计天然支持按朝代、按作者分片且无需 JOIN 即可快速定位。paragraphs与sentences词有上下阕曲有牌调诗有联句。保留段落切分和句子切分两套数组既方便前端渲染也方便 NLP 模型做句级嵌入。citation_textRAG 输出时必须给出可溯源的原文。该字段强制保留标准原文含标点避免在检索-生成链路中出现“篡改原文”的幻觉。2.2 作者表table_author— 别名体系诗人往往有名、字、号、谥号、别称等多重身份标识。如果把这些混在一个字段里检索“东坡居士”时将无法关联到“苏轼”。classtable_author(EntityBase):def__init__(self):self.SetTableName(author)self.AddColumn(colNameauthor_id,colTypetext,...)self.AddColumn(colNamename,colTypetext,...)# 标准名苏轼self.AddColumn(colNamecourtesy_name,colTypetext,...)# 字子瞻self.AddColumn(colNameart_name,colTypevarchar,...)# 号[东坡居士]self.AddColumn(colNameother_names,colTypevarchar,...)# 别名[苏东坡,...]self.AddColumn(colNamestyle_summary,colTypevarchar,...)self.AddColumn(colNamemajor_themes,colTypevarchar,...)self.AddColumn(colNamecommon_imagery,colTypevarchar,...)设计要点other_names和art_name均采用varchar数组序列化存储。在入库阶段通过OpenCC进行繁简转换预处理确保“蘇軾”与“苏轼”指向同一实体。2.3 朝代表table_dynasty— 时间轴统一classtable_dynasty(EntityBase):def__init__(self):self.SetTableName(dynasty)self.AddColumn(colNamedynasty_id,colTypetext,...)# 如 Tself.AddColumn(colNamename,colTypetext,...)# 唐self.AddColumn(colNameanother_name,colTypevarchar,...)# [李唐,大唐]self.AddColumn(colNamestart_year,colTypeint,...)self.AddColumn(colNameend_year,colTypeint,...)特别说明name字段标注为“用于诗词的”标准朝代名。例如“先秦”作为一个统一朝代节点涵盖夏、商、周、春秋、战国等子时期避免在诗词分类上过度碎片化。2.4 词汇表table_vocab— 全库可控的“语义字典”这是整个知识库标准化程度最高的表也是后续 RAG 检索质量的决定性因素classtable_vocab(EntityBase):def__init__(self):self.SetTableName(vocab)self.AddColumn(colNamevocab_id,colTypetext,...)self.AddColumn(colNamename,colTypetext,...)# 标准类目名如主题self.AddColumn(colNamekey,colTypetext,...)# 键如 themeself.AddColumn(colNamevalue,colTypetext,...)# 值如 山水为什么必须独立建表以theme主题为例如果允许自由录入会出现“山水”“山水田园”“自然山水”等多种写法导致向量检索时同主题无法聚合。通过vocab表强制收敛所有主题必须从预设词表中选取保证了** faceted search 的精确性**。这也是我做数据治理和数据标准化工作积累的经验。2.5 元数据记录表table_myschema— Schema 的自描述classtable_myschema(EntityBase):def__init__(self):self.SetTableName(myschema)# 记录每个表的字段中文名、键名、类型self.AddColumns(colNames[schema_id,table_name,column_label,column_name,type],...)这张表看似“元数据的元数据”但在实际项目中非常有用当后续通过代码自动生成前端表单、API 文档或向量库字段映射时可以直接读取myschema获得人类可读的字段说明避免硬编码。 三、工程实现亮点3.1 EntityBase 的 ORM 风格封装所有表均继承自EntityBase通过AddColumn/AddColumns链式调用完成字段注册。这种设计的优势在于自文档化字段定义即注释源码即 Schema 文档。可扩展新增字段只需追加一行不需要去搞SQL。驱动生成可基于EntityBase的元数据自动生成建表 SQL、Pydantic Model 和前端表单。3.2 OpenCC 的预处理集成fromopenccimportOpenCC sc2tcOpenCC(s2t)# 简体转繁体tc2scOpenCC(t2s)# 繁体转简体在数据入库管道中所有title、content、author等字段均会经过繁简双向转换校验。这确保了无论原始数据源是《全唐诗》的繁体版本还是现代整理的简体版本最终都能归一化处理。3.3 字段类型的刻意选择类型使用场景原因text大段文本SQLite 的 TEXT 无长度限制适合正文、赏析varchar数组/列表存储 JSON 序列化的标签数组如[月,霜]int统计值行数、字数、年份便于范围查询 四、与 RAG 架构的衔接当前 Schema 中与 RAG 直接相关的字段已预留了三个层次文本层content、paragraphs、sentences→ 用于向量嵌入Embedding元数据层theme、style、emotion、imagery→ 用于向量检索时的过滤条件Metadata Filtering关系层related_poem_ids→ 用于知识图谱构建和跨文档主题关联预留说明源码中注释掉的related、similar、related_author等字段将在第四章向量库设计中决定是保留为关系表还是直接存入向量数据库的 payload。 五、本章小结设计目标实现方式标准化vocab受控词表 全库唯一编号结构化正文/段落/句子三级切分 行数字数统计可扩展EntityBase链式字段注册 版本管理字段RAG 友好标签体系 引用文本 相关作品 ID多语言兼容OpenCC繁简转换 别名体系下一章将会介绍诗词的Web可视化以及使用大数据模型进行的智能化分析。如果本文对你有帮助欢迎 Star 支持GitHub 开源地址https://github.com/liang1057/Knowledge-Base-of-Chinese-PoetryCSDN 专栏中华诗词知识库KBCP系列文章 交流邮箱liang1057163.com版权声明本文为博主原创文章遵循 CC 4.0 BY-SA 版权协议转载请附上原文出处链接和本声明。
