企业官网建设流程全解析

博主介绍：✌ 专注于Java,python,✌关注✌私信我✌具体的问题，我会尽力帮助你。

一、研究目的

在传统的诗词检索与问答系统中，文本检索往往依赖于关键词匹配或全文搜索，这种方法在面对多义词、同音异义词以及古典语言的语义歧义时，准确率与召回率均难以满足学术研究与文化传播的需求。为此，本研究旨在构建一个基于知识图谱的诗词知识问答系统，以结构化、语义化的方式对诗词文本、作者、流派、主题等多维信息进行统一建模，从而实现更精准、高效的问答服务。通过将诗词实体与其属性以及相互关系映射到图数据库中，系统能够利用图遍历算法快速定位答案，并支持多步推理与关联查询，显著提升用户体验。

知识图谱作为一种兼具可扩展性与语义表达力的知识表示框架，在自然语言处理与信息检索领域已被证明具有显著优势。Neo4j 作为业界主流的图数据库，提供了高效的图存储与查询引擎，并支持 Cypher 查询语言，可满足复杂关系查询的需求。Python 作为数据处理与机器学习的主流编程语言，拥有丰富的生态库，能够方便地实现数据清洗、实体抽取、关系抽象以及前端交互等功能。将 Python 与 Neo4j 结合，可在保持开发效率的同时，实现高性能的知识图谱构建与问答推理。

本研究的主要目标包括：首先，设计并实现一个可自动化采集与清洗古典诗词文本、作者信息、流派分类及主题标签等多源数据的管道；其次，基于自然语言处理技术抽取实体与关系，并将其映射到 Neo4j 中构建统一的知识图谱；再次，开发基于图查询的问答引擎，实现对用户自然语言问题的语义解析、查询生成与答案生成；最后，通过实验评估系统在准确率、召回率、响应时延等指标上的表现，并与传统检索方法进行对比分析。

通过上述目标的实现，本研究期望在以下方面产生贡献：一是为古典诗词研究提供一种可视化、交互式的知识探索工具，促进学术交流与文化传播；二是验证知识图谱在文本语义理解与问答场景中的有效性，为后续基于图数据库的文本检索研究提供经验与方法；三是为 Python 与 Neo4j 的深度集成提供可复用的工程实践案例，推动相关技术在文化遗产数字化领域的应用。

二、研究意义

本研究所提出的基于知识图谱的诗词知识问答系统，具有重要的学术与社会意义。首先，在学术研究层面，它突破了传统文本检索对关键词匹配的依赖，通过将诗词实体、作者、流派、主题及其相互关系统一映射到图数据库中，实现了语义层面的深度解析与多维关联查询，从而为文学研究者提供了更为精准、高效的研究工具；其次，在文化遗产数字化与传播层面，该系统能够以可视化、交互式的方式呈现古典诗词的知识结构，降低专业门槛，提升公众对中国传统文化的认知与兴趣；再次，在技术创新层面，本研究通过将 Python 与 Neo4j 深度集成，展示了在大规模文本数据处理、实体抽取与关系推理方面的可行路径，为类似领域的知识图谱构建提供了可复制、可扩展的技术框架。

从社会价值角度来看，诗词问答系统能够满足教育、旅游、媒体等多元化需求，为高校课程教学提供即时、精准的参考资料；在旅游业中，游客可通过语音或文本查询获取诗词背后的历史背景与文化内涵，提升文化体验质量；在媒体与出版领域，该系统可作为内容创作的辅助工具，帮助编辑快速检索相关信息，提高工作效率。与此同时，该系统对传统诗词的数字化保存与传播具有积极作用，有助于防止珍贵文化资源的流失与遗忘。

在理论层面，本研究通过对知识图谱构建、语义解析及图查询算法的深入探讨，丰富了自然语言处理与信息检索交叉领域的研究成果。具体而言，系统所采用的实体抽取与关系抽象方法，可为其他古籍文本、科学文献等领域的知识图谱构建提供参考；其基于 Cypher 的查询生成策略，为复杂问答场景下的语义映射与答案推理提供了新的思路。综上所述，本研究不仅在技术实现层面具有创新性，更在学术价值、社会效益与文化传承等方面展现了深远意义。

三、国内外研究现状

国内外在古典文学知识图谱与问答系统方面的研究已形成若干主流方向，且取得了显著进展。首先，在知识图谱构建层面，国外学者通过对英美诗歌、戏剧文本的实体抽取与关系标注，构建了如PoetryNet、English Literature Knowledge Graph等大型语义网络，这些工作为后续的检索与推理奠定了数据基础。国内方面，近年来以中文古典诗词为核心的知识图谱研究逐渐兴起，其中最具代表性的成果包括“中华诗词知识图谱”与“唐诗宋词实体关系库”，这些系统通过结合文本挖掘、命名实体识别与知识融合技术，将作者、流派、主题、情感等多维属性映射到图结构中，显著提升了语义查询的准确性。其次，在检索与问答技术层面，国外研究普遍采用基于深度学习的语义匹配模型，如BERT、ERNIE等预训练语言模型，在诗歌检索任务上取得了比传统TF-IDF更优的召回率与精确率。国内学术界则将这些模型与传统检索算法相结合，提出了基于BM25+BERT的混合检索框架，能够在保留高召回率的同时提升答案质量。再次，在问答系统实现层面，国外多采用基于Transformer的生成式问答模型，例如OpenAI GPT系列，在诗歌解释与创作辅助任务中表现出色。国内研究者则更多关注基于图数据库的推理式问答，通过Cypher查询与图遍历实现多步推理，解决了传统文本检索无法覆盖的复杂语义关系。最后，在技术实现层面，Neo4j作为主流图数据库在国外已被广泛用于知识图谱存储与查询，而国内则通过Python结合Neo4j的Cypher接口，构建了可扩展的知识图谱构建与问答服务框架，显著降低了系统开发成本。总体来看，国内外在知识图谱构建、语义检索、深度学习问答与图数据库技术方面均已形成成熟的研究体系，但在古典中文文本的语言歧义处理、跨域知识融合以及多模态问答等方面仍存在挑战。

四、预期达到目标及解决的关键问题

预期目标首先是构建一套完整的古典诗词知识图谱，涵盖作者、流派、主题、情感色彩及其相互关系，并通过Python脚本实现数据清洗与实体抽取，最终将结构化信息存储于Neo4j数据库中；其次是开发基于Cypher查询与图遍历的问答引擎，能够接受自然语言输入，解析语义并返回精准答案，同时支持多步推理与关联查询；再次通过实验评估系统在准确率、召回率、响应时延等指标上的表现，并与传统全文检索方法进行对比，以验证知识图谱在诗词问答场景中的优势；最后致力于形成可复用的技术框架，为后续文化遗产数字化与跨学科研究提供参考。

关键问题主要集中在数据采集与预处理方面，古典诗词文本多来源且格式不一，如何统一编码、去除噪声并构建标准化的文本库仍是挑战；实体识别方面，古代人物、地名与现代命名体系差异显著，现有中文NER模型对古文的适应性不足，需要结合规则与深度学习方法提升准确率；关系抽取方面，诗词中隐含的情感、主题关联往往通过修辞手法表达，如何从文本中提取这些非显式关系并映射为图边仍需创新算法；图谱设计方面，如何在保持查询效率的同时兼顾多维属性与层级关系，需要在节点类型与属性命名上进行细致规划；查询性能方面，Cypher语句的优化与索引策略的选择直接影响系统响应速度，需要针对诗词问答场景定制高效执行计划；自然语言理解方面，古典诗词的语言结构与现代汉语差异较大，问答系统需在语义解析层面兼顾古文特征，以避免误检或漏检。

五、研究内容

本研究旨在构建一套基于知识图谱的诗词知识问答系统，系统核心在于将古典诗词文本与作者、流派、主题、情感等多维信息进行结构化建模，并通过图数据库实现高效的语义检索与推理。研究范围涵盖数据采集与清洗、实体与关系抽取、知识图谱设计与实现、问答引擎开发以及系统评估与优化。

首先，数据采集阶段将从公开诗词数据库、数字图书馆及学术文献中提取原始文本，并采用统一的编码标准进行存储。随后通过正则表达式与规则匹配对文本进行预处理，包括去除注释、标点规范化、分行重组等操作，以确保后续抽取过程的准确性。

在知识图谱构建方面，研究将结合基于规则的命名实体识别与深度学习模型，对作者、地名、时代及诗词标题等实体进行抽取，并利用句法分析与语义角色标注技术识别“作者-创作-诗词”“诗词-主题”“诗词-情感色彩”等关系。构建完成后，将对实体与关系进行去重与标准化，形成统一的节点类型与边类型，并设计多层次属性模型以支持多维查询。

Neo4j数据库将作为知识图谱的存储与查询平台。研究将通过Python驱动实现数据导入脚本，利用Cypher语句批量创建节点与边，并为常用属性建立索引，以提升查询效率。针对诗词文本的全文检索需求，将在Neo4j中创建全文索引，并结合图遍历算法实现跨节点的深度查询。

问答引擎的核心在于将自然语言问题映射为Cypher查询。为此，研究将实现基于BERT或ERNIE的语义解析模块，对用户输入进行分词、实体识别与意图判断，并根据预定义的模板生成对应的Cypher语句。系统将支持多步推理，例如“谁是唐代诗人李白的同流派诗人？”通过链式查询实现答案检索。

答案生成层面，系统将采用检索式方法返回最相关节点或边的信息，并对结果进行格式化与可视化展示。为提升用户体验，研究将探索在检索结果基础上加入简短的诗词摘录与情感分析摘要，以提供更丰富的语义信息。

系统架构采用前后端分离模式，后端使用Python Flask框架封装Neo4j查询接口，前端通过Vue.js实现交互式问答界面。整个系统将部署在云服务器上，并通过RESTful API实现模块化调用，以便未来功能扩展。

评估计划将从准确率、召回率、响应时延以及用户满意度四个维度进行量化测评。对比传统全文检索与基于知识图谱的问答方法，预期在复杂多义问题上将显著提升答案质量。实验数据将以公开诗词语料为基准，并通过人工标注的黄金标准进行验证。

最终，本研究预计能够提供一套可复用的古典诗词知识图谱构建与问答框架，为文学研究、文化传播与教育等领域提供技术支持，并为中文古典文本语义理解与知识图谱应用开辟新的研究方向。

六、需求分析

用户需求方面，系统的主要使用者包括文学研究者、教育工作者、文化爱好者以及旅游服务人员。研究者期望能够通过精准的语义检索快速定位诗词创作背景、作者关系与流派归属，从而支持论文写作与学术讨论；教育工作者则需要一个可视化的教学工具，能够展示诗词之间的内在联系与情感色彩，辅助课堂讲解与学生练习；文化爱好者和旅游服务人员希望借助问答系统获取诗词背后的历史故事、地理信息以及艺术赏析，以提升文化体验与导览质量。用户对系统的交互体验提出了高要求，期望界面简洁直观、响应速度快，并能支持多语言输入与语音识别，满足不同场景下的使用需求。除此之外，系统还需具备可扩展性，以便后续添加新的诗词数据源、知识维度以及多模态信息，从而持续满足用户日益增长的探索深度与广度。

功能需求方面，系统首先需要实现高效的数据采集与清洗模块，能够从公开数据库、数字图书馆以及学术文献中抓取原始诗词文本，并通过统一编码与格式化规则消除噪声。其次，实体与关系抽取功能必须结合规则匹配与深度学习模型，对作者、地名、时代、流派及情感色彩等多维属性进行准确识别，并构建“创作”“同流派”“主题关联”等语义边。随后，知识图谱存储层需采用Neo4j数据库，支持批量节点与边导入、全文索引与属性索引的创建，并保证查询性能满足实时问答需求。问答引擎应包含自然语言理解模块，对用户输入进行分词、实体识别与意图判定，并通过模板化或生成式方法将语义映射为Cypher查询语句。答案生成层需对检索结果进行格式化，提供诗词摘录、作者信息与情感分析摘要，并支持多步推理以回答复杂问题。前端交互界面应实现文本输入、语音识别、结果展示与可视化图谱浏览功能，并兼容移动端与桌面端。最后，系统还需提供权限管理、日志审计与性能监控模块，以保障数据安全与运维稳定。

七、可行性分析

经济可行性方面，本项目的主要成本主要集中在数据采集与清洗、知识图谱构建、系统开发与部署以及后期维护与运营。数据采集阶段可利用现有公开诗词数据库和数字图书馆的API接口，减少人工抓取成本；若需补充稀缺古籍文本，可通过与高校、博物馆合作获取授权，费用相对可控。知识图谱构建所需的自然语言处理模型，如BERT、ERNIE等，可采用开源版本或云服务的预训练模型，避免高昂的训练成本。系统开发方面，Python与Neo4j均为成熟的开源技术栈，开发人员可通过现有框架快速搭建后端服务与前端交互界面，硬件部署可选择云服务器或本地服务器，按需扩容以降低初期投入。运营成本主要包括服务器租赁、数据存储与备份、人工维护以及持续更新的费用。综合评估后，项目总投入预计在数十万元人民币范围内，且通过向高校、文化机构提供定制化服务、开发API接口以及可能的版权授权等方式，可在三至五年内实现成本回收并产生可观收益。

社会可行性方面，本系统的实施将显著提升公众对中国古典诗词文化的认知与传播效率，符合国家文化软实力建设与数字人文发展的战略需求。教育领域将受益于该系统提供的精准检索与可视化展示功能，教师可利用其进行课堂教学、作业批改及学生自主学习；研究机构则可借助知识图谱进行大规模文本分析、流派演变研究以及跨学科交叉研究；旅游与文化产业也能通过系统提供的诗词导览与背景解读服务，提升游客体验并推动文化旅游经济。系统采用多语言输入与语音识别功能，可满足不同用户群体的使用习惯，进一步扩大受众范围。社会层面还需关注数据版权与隐私保护，项目将严格遵守《著作权法》与《个人信息保护法》规定，确保所有采集数据均取得合法授权，并对用户查询记录进行匿名化处理，从而获得公众与监管部门的信任。

技术可行性方面，项目所依赖的核心技术已在学术界与工业界得到充分验证。自然语言处理领域的预训练模型如BERT、ERNIE在中文文本理解任务中表现卓越，可通过迁移学习进一步提升古典诗词实体识别与关系抽取的准确率；图数据库Neo4j提供高效的图存储与Cypher查询语言，已被广泛应用于知识图谱构建与语义推理；Python生态系统中丰富的数据处理、Web框架与可视化库为系统开发提供了完整工具链。技术挑战主要集中在古典文本的歧义处理、命名实体识别的领域适配以及多步推理查询的性能优化。针对这些挑战，项目计划采用混合规则与深度学习相结合的方法进行实体抽取，并通过自定义词典与语义角色标注提升模型鲁棒性；在图查询层面，将为常用属性建立索引、编写高效Cypher模板，并利用Neo4j的并行查询特性降低响应时延。综上所述，技术实现可行且具备进一步优化空间，能够满足系统功能需求与性能指标。

八、功能分析

系统功能模块划分为八大层次，分别为数据采集与预处理模块、实体与关系抽取模块、知识图谱构建与存储模块、自然语言理解与查询生成模块、答案检索与排序模块、可视化展示与交互接口模块、服务治理与安全管理模块以及监控日志分析模块。

数据采集与预处理模块负责从公开诗词数据库、数字图书馆及学术文献中抓取原始文本，并对文本进行编码统一、标点规范化、行分割重组及噪声过滤。该模块还需构建标准化的元数据表格，记录来源、版权信息与采集时间，为后续审计与合规提供依据。

实体与关系抽取模块采用规则匹配与深度学习相结合的方法，对预处理后的文本进行命名实体识别（作者、地名、时代、流派等）以及语义角色标注，以识别“创作”“同流派”“主题关联”“情感色彩”等多种关系。抽取结果以统一的JSON格式输出，并通过去重与标准化流程生成干净的实体与边列表。

知识图谱构建与存储模块利用Neo4j数据库实现图数据的持久化。该模块负责将抽取出的节点与边批量导入数据库，创建节点标签、属性索引以及全文索引，并根据业务需求定义关系类型与属性。通过Cypher脚本实现高效批量写入，并提供接口供后续查询层调用。

自然语言理解与查询生成模块是问答引擎的核心。首先对用户输入进行分词、词性标注与实体识别，随后基于预训练语言模型（如BERT、ERNIE）进行语义解析与意图识别。根据解析结果匹配预定义的查询模板或动态生成Cypher查询语句，并将其提交给知识图谱查询层。

答案检索与排序模块接收Cypher执行结果后，对返回的节点与边进行格式化，提取诗词文本、作者信息、主题标签与情感分析摘要。该模块还实现多步推理支持，例如链式查询“谁是唐代诗人李白的同流派诗人”，并通过评分机制对候选答案进行排序，以保证最终返回的答案既准确又简洁。

可视化展示与交互接口模块负责将检索结果以图形化方式呈现给用户。前端采用Vue.js框架实现响应式页面，支持文本输入、语音识别与结果高亮显示。图谱浏览器基于Neo4j的图形展示插件，提供节点属性查看、关系路径追踪与主题聚类等功能，使用户能够直观理解诗词之间的关联网络。

服务治理与安全管理模块实现统一的身份认证、权限控制与访问日志记录。通过OAuth2.0或JWT机制保障API调用安全，并对敏感数据进行加密存储。该模块还提供接口限流、熔断与重试策略，以提升系统的鲁棒性。

监控日志分析模块负责实时收集系统运行指标（CPU、内存、查询时延、错误率等）并通过Grafana或Prometheus可视化仪表盘展示。日志聚合器将后端日志发送至ELK堆栈，支持快速定位性能瓶颈与异常事件，为运维与持续改进提供数据支持。

上述模块相互协作，形成从数据获取到答案呈现的闭环，实现了基于知识图谱的诗词知识问答系统的完整功能。

九、数据库设计

字段名(英文) | 说明(中文) | 大小 | 类型 | 主外键 | 备注
---|---|---|---|---|---
author_id | 作者表主键，唯一标识作者。 | 10 | INT UNSIGNED NOT NULL AUTO_INCREMENT | 主键 | 自增
name | 作者姓名。 | 100 | VARCHAR(100) NOT NULL | |
birth_year | 出生年份，若未知则为空。 | 4 | SMALLINT NULL | |
death_year | 去世年份，若未知则为空。 | 4 | SMALLINT NULL | |
nationality | 国籍或地区。 | 50 | VARCHAR(50) NULL | |
biography | 作者简介，较长文本。 | 65535 | TEXT NULL | |
poem_id | 诗词表主键，唯一标识一首诗。 | 10 | INT UNSIGNED NOT NULL AUTO_INCREMENT | 主键 | 自增
title | 诗词标题。 | 200 | VARCHAR(200) NOT NULL | |
dynasty | 所属朝代。 | 50 | VARCHAR(50) NULL | |
publication_year | 出版年份，若未知则为空。 | 4 | SMALLINT NULL | |
content | 原始诗词全文。 | -1 (CLOB) | TEXT NOT NULL | |
theme_id | 主题表主键，唯一标识一个主题。 | 10 | INT UNSIGNED NOT NULL AUTO_INCREMENT | 主键 | 自增
name_theme | 主题名称，例如“山水”“爱情”。 | 100 | VARCHAR(100) NOT NULL | |
emotion_id | 情感表主键，唯一标识一种情感色彩。 | 10 | INT UNSIGNED NOT NULL AUTO_INCREMENT | 主键 | 自增
name_emotion | 情感名称，例如“悲愁”“喜悦”。 | 100 | VARCHAR(100) NOT NULL | |
flow_id | 流派表主键，唯一标识一种文学流派。 | 10 | INT UNSIGNED NOT NULL AUTO_INCREMENT | 主键 | 自增
name_flow | 流派名称，例如“唐诗三百首”“宋词正韵”。 | 100 | VARCHAR(100) NOT NULL | |
location_id | 地点表主键，唯一标识一个地点。 | 10 | INT UNSIGNED NOT NULL AUTO_INCREMENT | 主键 | 自增
name_location | 地点名称，例如“江南”“黄山”。 | 200 | VARCHAR(200) NOT NULL | |
poem_author_id | 诗词作者关联表主键，唯一标识一条关联记录。 | 10 | INT UNSIGNED NOT NULL AUTO_INCREMENT | 主键 | 自增
poem_id_fk | 外键，指向诗词表。 | 10 | INT UNSIGNED NOT NULL | 外键 (poem.poem_id) |
author_id_fk | 外键，指向作者表。 | 10 | INT UNSIGNED NOT NULL | 外键 (author.author_id) |
poem_theme_id | 诗词主题关联表主键，唯一标识一条关联记录。 | 10 | INT UNSIGNED NOT NULL AUTO_INCREMENT | 主键 | 自增
poem_id_fk_theme | 外键，指向诗词表。 | 10 | INT UNSIGNED NOT NULL | 外键 (poem.poem_id) |
theme_id_fk | 外键，指向主题表。 | 10 | INT UNSIGNED NOT NULL | 外键 (theme.theme_id) |
poem_emotion_id | 诗词情感关联表主键，唯一标识一条关联记录。 | 10 | INT UNSIGNED NOT NULL AUTO_INCREMENT | 主键 | 自增
poem_id_fk_emotion | 外键，指向诗词表。 | 10 | INT UNSIGNED NOT NULL | 外键 (poem.poem_id) |
emotion_id_fk | 外键，指向情感表。 | 10 | INT UNSIGNED NOT NULL | 外键 (emotion.emotion_id) |
author_flow_id | 作者流派关联表主键，唯一标识一条关联记录。 | 10 | INT UNSIGNED NOT NULL AUTO_INCREMENT | 主键 | 自增
author_id_fk_flow | 外键，指向作者表。 | 10 | INT UNSIGNED NOT NULL | 外键 (author.author_id) |
flow_id_fk_author | 外键，指向流派表。 | 10 | INT UNSIGNED NOT NULL | 外键 (flow.flow_id) |
poem_location_id | 诗词地点关联表主键，唯一标识一条关联记录。 | 10 | INT UNSIGNED NOT NULL AUTO_INCREMENT | 主键 | 自增
poem_id_fk_location | 外键，指向诗词表。 | 10 | INT UNSIGNED NOT NULL | 外键 (poem.poem_id) |
location_id_fk | 外键，指向地点表。 | 10 | INT UNSIGNED NOT NULL | 外键 (location.location_id) |
source_id | 数据源表主键，唯一标识一种数据来源。 | 10 | INT UNSIGNED NOT NULL AUTO_INCREMENT | 主键 | 自增
name_source | 数据源名称，例如“中华诗词数据库”。 | 200 | VARCHAR(200) NOT NULL | |
url_source | 数据源网址。 | 255 | VARCHAR(255) NULL | |
license_info | 版权信息或许可协议。 | 500 | VARCHAR(500) NULL | |

以上表结构遵循第一范式，主键唯一标识记录，外键维护表间完整性；多对多关系通过关联表实现，避免冗余；字段类型与长度根据实际内容设定，满足数据完整性与查询效率。

十、建表语句

以下为完整的 MySQL 建表脚本，已包含所有字段、主键、外键以及必要的索引。脚本使用 InnoDB 存储引擎并采用 utf8mb4 字符集，以兼容中文字符。

-- 1. 作者表
CREATE TABLE author (
author_id INT UNSIGNED NOT NULL AUTO_INCREMENT,
name VARCHAR(100) NOT NULL,
birth_year SMALLINT NULL,
death_year SMALLINT NULL,
nationality VARCHAR(50) NULL,
biography TEXT NULL,
PRIMARY KEY (author_id),
UNIQUE KEY uk_author_name (name)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

-- 2. 诗词表
CREATE TABLE poem (
poem_id INT UNSIGNED NOT NULL AUTO_INCREMENT,
title VARCHAR(200) NOT NULL,
dynasty VARCHAR(50) NULL,
publication_year SMALLINT NULL,
content TEXT NOT NULL,
PRIMARY KEY (poem_id),
UNIQUE KEY uk_poem_title (title)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

-- 3. 主题表
CREATE TABLE theme (
theme_id INT UNSIGNED NOT NULL AUTO_INCREMENT,
name_theme VARCHAR(100) NOT NULL,
PRIMARY KEY (theme_id),
UNIQUE KEY uk_theme_name (name_theme)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

-- 4. 情感表
CREATE TABLE emotion (
emotion_id INT UNSIGNED NOT NULL AUTO_INCREMENT,
name_emotion VARCHAR(100) NOT NULL,
PRIMARY KEY (emotion_id),
UNIQUE KEY uk_emotion_name (name_emotion)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

-- 5. 流派表
CREATE TABLE flow (
flow_id INT UNSIGNED NOT NULL AUTO_INCREMENT,
name_flow VARCHAR(100) NOT NULL,
PRIMARY KEY (flow_id),
UNIQUE KEY uk_flow_name (name_flow)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

-- 6. 地点表
CREATE TABLE location (
location_id INT UNSIGNED NOT NULL AUTO_INCREMENT,
name_location VARCHAR(200) NOT NULL,
PRIMARY KEY (location_id),
UNIQUE KEY uk_location_name (name_location)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

-- 7. 数据源表
CREATE TABLE source (
source_id INT UNSIGNED NOT NULL AUTO_INCREMENT,
name_source VARCHAR(200) NOT NULL,
url_source VARCHAR(255) NULL,
license_info VARCHAR(500) NULL,
PRIMARY KEY (source_id),
UNIQUE KEY uk_source_name (name_source)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

-- 8. 诗词-作者关联表
CREATE TABLE poem_author (
poem_author_id INT UNSIGNED NOT NULL AUTO_INCREMENT,
poem_id_fk INT UNSIGNED NOT NULL,
author_id_fk INT UNSIGNED NOT NULL,
PRIMARY KEY (poem_author_id),
UNIQUE KEY uk_poem_author_unique (poem_id_fk, author_id_fk),
KEY idx_poem_author_poem (poem_id_fk),
KEY idx_poem_author_author (author_id_fk),
CONSTRAINT fk_pa_poem
FOREIGN KEY (poem_id_fk) REFERENCES poem(poem_id)
ON DELETE RESTRICT ON UPDATE CASCADE,
CONSTRAINT fk_pa_author
FOREIGN KEY (author_id_fk) REFERENCES author(author_id)
ON DELETE RESTRICT ON UPDATE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

-- 9. 诗词-主题关联表
CREATE TABLE poem_theme (
poem_theme_id INT UNSIGNED NOT NULL AUTO_INCREMENT,
poem_id_fk_theme INT UNSIGNED NOT NULL,
theme_id_fk INT UNSIGNED NOT NULL,
PRIMARY KEY (poem_theme_id),
UNIQUE KEY uk_poem_theme_unique (poem_id_fk_theme, theme_id_fk),
KEY idx_pt_poem (poem_id_fk_theme),
KEY idx_pt_theme (theme_id_fk),
CONSTRAINT fk_pt_poem
FOREIGN KEY (poem_id_fk_theme) REFERENCES poem(poem_id)
ON DELETE RESTRICT ON UPDATE CASCADE,
CONSTRAINT fk_pt_theme
FOREIGN KEY (theme_id_fk) REFERENCES theme(theme_id)
ON DELETE RESTRICT ON UPDATE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

-- 10. 诗词-情感关联表
CREATE TABLE poem_emotion (
poem_emotion_id INT UNSIGNED NOT NULL AUTO_INCREMENT,
poem_id_fk_emotion INT UNSIGNED NOT NULL,
emotion_id_fk INT UNSIGNED NOT NULL,
PRIMARY KEY (poem_emotion_id),
UNIQUE KEY uk_poem_emotion_unique (poem_id_fk_emotion, emotion_id_fk),
KEY idx_pe_poem (poem_id_fk_emotion),
KEY idx_pe_emotion (emotion_id_fk),
CONSTRAINT fk_pe_poem
FOREIGN KEY (poem_id_fk_emotion) REFERENCES poem(poem_id)
ON DELETE RESTRICT ON UPDATE CASCADE,
CONSTRAINT fk_pe_emotion
FOREIGN KEY (emotion_id_fk) REFERENCES emotion(emotion_id)
ON DELETE RESTRICT ON UPDATE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

-- 11. 作者-流派关联表
CREATE TABLE author_flow (
author_flow_id INT UNSIGNED NOT NULL AUTO_INCREMENT,
author_id_fk_flow INT UNSIGNED NOT NULL,
flow_id_fk_author INT UNSIGNED NOT NULL,
PRIMARY KEY (author_flow_id),
UNIQUE KEY uk_author_flow_unique (author_id_fk_flow, flow_id_fk_author),
KEY idx_af_author (author_id_fk_flow),
KEY idx_af_flow (flow_id_fk_author),
CONSTRAINT fk_af_author
FOREIGN KEY (author_id_fk_flow) REFERENCES author(author_id)
ON DELETE RESTRICT ON UPDATE CASCADE,
CONSTRAINT fk_af_flow
FOREIGN KEY (flow_id_fk_author) REFERENCES flow(flow_id)
ON DELETE RESTRICT ON UPDATE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

-- 12. 诗词-地点关联表
CREATE TABLE poem_location (
poem_location_id INT UNSIGNED NOT NULL AUTO_INCREMENT,
poem_id_fk_location INT UNSIGNED NOT NULL,
location_id_fk INT UNSIGNED NOT NULL,
PRIMARY KEY (poem_location_id),
UNIQUE KEY uk_poem_location_unique (poem_id_fk_location, location_id_fk),
KEY idx_pl_poem (poem_id_fk_location),
KEY idx_pl_location (location_id_fk),
CONSTRAINT fk_pl_poem
FOREIGN KEY (poem_id_fk_location) REFERENCES poem(poem_id)
ON DELETE RESTRICT ON UPDATE CASCADE,
CONSTRAINT fk_pl_location
FOREIGN KEY (location_id_fk) REFERENCES location(location_id)
ON DELETE RESTRICT ON UPDATE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

上述脚本已满足第一、第二范式，主键唯一标识每条记录，外键保证表间完整性；通过 UNIQUE 约束避免重复关联记录；对外键列建立索引以提升查询性能。请根据实际部署环境执行以上脚本即可完成数据库结构的搭建。

下方名片联系我即可~大家点赞、收藏、关注、评论啦 、查看下方👇🏻获取联系方式👇🏻