中国古代天象记录是传统天文学为我们留下的独一无二的宝贵遗产。天文学研究涉及的时间尺度往往较长，尽管现代天文观测设备大大提高了研究对象的空间分辨率，但在时间尺度上仍然缺乏充足的信息。而古代天象记录恰好可以弥补现代观测设备在时间尺度上的缺憾，对天文学前沿理论，如超新星爆发、太阳活动与日地关系、彗星等，可能提供有价值的科学数据。

以历史超新星为例，瑞典天文学家克努特·伦德马克早在1921年便整理了中国古代的新星观测记录，并指出中国古代的客星记录可能与新星爆发有关^[1]。20世纪40年代，荷兰天文学家简·奥尔特等人进一步将中国1054年记录的客星与超新星爆发联系起来，而蟹状星云即为此次超新星爆发的遗迹^[2]，再次激起了国际天文界对中国古代天象记录的兴趣。随着射电天文观测的兴起，为了证实超新星爆发的射电表征，天文界在上世纪五十年代密切关注了中国古代的客星记录。1955年，文[3]系统搜集了中国古代的客星记录，并进行了初步分析，在国际天文界引起强烈反响。西方著名天文学家约瑟夫·什克洛夫斯基^[4]、恩斯特·欧皮克^[5]、奥托·斯特鲁维^[6]、弗里茨·兹威基^[7]均曾开展或关注过使用中国古代客星记录的研究。在国内，紫金山天文台张钰哲先生^[8]、南京大学汪珍如先生^[9-10]、北京天文台李启斌先生^[11]等一批著名天文学家，也都曾专门发表过利用古代天象记录取得的研究成果。

近年来，天文学理论和观测手段进步迅速，天文学界对中国古代天象记录的兴趣有增无减。例如，苏珊·霍夫曼、尼古劳斯·福格特等人提出了一套分析及证认古代客星记录的方法，除新星和超新星遗迹外，行星状星云、共生星、脉冲星等其他类型的天体也纳入了候选范围^[12]。文[13]证认了公元386年的客星记录对应的现代天文观测源。文[14]根据古代日食记录研究了地球自转的长周期变化。

与之形成鲜明对比的是，中国古代天象记录的整理与校勘仍然停留在上世纪八十年代末《中国古代天象记录总集》^[15] (以下简称《总集》) 的水平。《总集》是上世纪七十年代至八十年代末集全国力量完成的重要成果，对中国古代太阳黑子、极光、陨石、日食、月食、月掩行星、新星和超新星、彗星、流星雨和流星等10个类别的天象记录做了全面的收集和整理。但从如今的视角来看，《总集》已经远不能满足天文学研究工作的需要，存在诸多问题：从科学应用的角度来说，《总集》中收集的天象记录仅给出了原始文本，缺少上下文及对其科学参数的辨析与考证，难以应用于现代天文学研究，没有提供英文翻译，也不便于国外研究人员使用；从出版形式上来说，《总集》作为纸质书籍，检索不够方便，另外目前也已绝版，导致可利用度不高；最后，从文献学的角度来说，随着近年来古籍整理工作的进展，我们发现《总集》收集的天象记录仍不够全面，有较多遗漏，在已收录的天象记录中，也有一些文本错误，此外，《总集》只标注了卷页号，却未说明使用的文献版本，给使用者进一步查询、核对带来了困难。

针对上述问题，近年来学界呼吁将数字化手段引入中国古代天象记录的整理工作，并对记录的关键科学参数进行定量分析。如在2013年香山科学会议第482次讨论会上，与会专家认为应尽快对中国古代天象记录进行全面整理，建立古代天象记录数据库和相关的应用研究平台。

由此可见，若能借助现代信息技术建立一套中国古代天象记录的数字化检索与整理平台，面向全世界的天文研究者开放使用，将对进一步挖掘古代天象记录的科学应用价值、推进天象记录的整理、加强文化自信具有重要意义。本文详细分析了古代天象记录检索、整理过程中的功能需求，并在此基础上运用面向文档数据库、全文检索、语法分析、Web等技术，设计并开发了中国古代天象记录数据库，本文主要介绍其设计与实现方法，并展示了系统的运行效果。

1 系统功能需求分析

中国古代天象记录数据库的核心目标是借助信息技术手段，为用户提供便捷的天象记录检索和数据库管理功能，使其成为中国古代天象记录的数字化检索与整理平台。为此，系统可按照业务功能划分为天象记录检索和数据库管理两大功能版块，如图 1。

1.1 天象记录检索功能

天象记录检索功能面向数据库的一般使用者。古代天象记录中包含丰富的科学和史料信息，这些信息的结构、类型多样，是典型的异构数据。此外，由于古代天象记录研究具有交叉学科的属性，因此，数据库面向的一般用户群体是多样的，主要包括天文研究人员和文史研究人员两大类，他们对于古代天象记录的信息需求也不同。天文研究人员的关注重点在于天象记录中的科学信息，如天象对应的现代天文观测源，天象发生的位置及颜色、亮度等信息。而文史研究人员则更关注天象的记载文字、文献出处等文本信息。

为满足不同类型用户对古代天象记录中异构数据的多样化检索需求，数据库应提供以下8种相关功能，解决以往天象记录整理成果难以检索的问题。

(1) 语法检索：数据库应提供一种领域专用语言(Domain Specific Language, DSL)，支持字符串、列表、数字等基本数据类型以及与(and)、或(or)、非(not) 等逻辑运算，以满足用户的复杂查询需求。

(2) 全文检索：对于天象记录中的纯文本信息，如文献记载内容、文献来源等，数据库应提供全文检索服务。同时，为提高检索的查准率和查全率，数据库应支持准确和模糊两种全文检索类型。

(3) 锥形检索：对于天象记录中的天区位置信息，数据库应提供天文数据库中常用的锥形检索服务，用户输入天区的赤经、赤纬及角半径，即可检索发生在该天区内的天象记录。

(4) 地理位置检索：天象记录中除天区位置外，还包括另一类位置信息，即记录观测的地理位置，对此，数据库也应具备检索能力。

(5) 结构化检索：对于天象记录中的结构化信息，如天象的开始与结束时间、天象类型等，数据库应提供结构化检索服务。

(6) 检索结果展示：数据库需将检索的结果以表格或列表的形式向用户展示。

(7) 检索结果聚合：数据库应支持检索结果聚合，对检索结果做简单的统计分析，得到结果概览，从而帮助用户快速了解检索结果的整体情况，用户也可以根据聚合信息对结果做进一步筛选。

(8) 检索结果排序：数据库可以按照某种标准对检索结果进行排序，从而提高用户的检索效率。

1.2 数据库管理功能

除面向一般使用者的检索功能，数据库还应为管理者提供天象记录和用户管理的功能，包括添加、删除、编辑记录及用户注册、登录、信息修改、删除等功能。

2 系统架构与实现

如图 2，中国古代天象记录数据库采用基于前后端分离模式的浏览器/服务器架构(Browser/Server Architecture) 实现，自底向上由数据存储模块、后端模块和前端模块组成。数据存储模块为整个数据库系统提供记录持久化存储与底层记录检索服务的支持。后端模块主要通过数据存储模块提供的基本存储与检索服务，实现天象记录检索和数据库管理等核心业务逻辑。前端模块负责整个数据库系统的最终呈现，是用户与数据库系统之间的交互接口。

2.1 数据存储模块

该部分需要选定系统的存储方案，并确定记录的一般存储格式。

2.1.1 存储方案

从记录存储的角度来说，天象记录中各字段属性的内聚性强，同一字段属性值在不同记录间很少复用，比较适合采用将一个对象的所有信息存储在单一文档中的文档数据模型进行描述，不适合采用传统的关系数据模型，因此，本系统选用面向文档的数据库MongoDB作为主数据库。

但从记录检索的角度来讲，天象记录中存在较多的文本字段，因此，对数据库的全文检索能力有较高的要求，而MongoDB和传统的关系型数据库对全文检索的支持均较差，难以满足天象记录全文检索这一核心业务需求。天文文献全文检索系统^[16]与本系统的场景较为类似，该系统采用Lucene检索引擎实现全文检索，但直接使用Lucene引擎十分复杂，目前开发中很少直接应用，因此，本系统采用基于Lucene的全文检索引擎Elasticsearch提供记录检索服务，该引擎对Lucene进行封装，提供了方便易用的接口及对海量数据的存储、检索能力，是目前最为流行的全文检索解决方案。对全文检索服务来说，决定其结果查准率和查全率的关键因素是对搜索条件及天象记录原始文本的分词效果，本系统采用中文自然语言处理工具包HanLP作为分词器。另外，考虑到天象记录中存在诸多古天文专有名词，系统添加了根据《中国古代天文学词典》^[17]制作的分词字典作为补充。

MongoDB和Elasticsearch之间通过Monstache实现天象记录数据的同步。Monstache是基于Go语言编写的开源MongoDB和Elasticsearch实时同步工具。当管理者对天象记录做添加、编辑、删除操作时，Monstache基于MongoDB的oplog日志机制将对天象记录的改动同步至Elasticsearch引擎，从而保证MongoDB和Elasticsearch之间数据的一致性。

此方案也实现了数据存储模块的主从复制和读写分离。由MongoDB数据库作为主数据库，处理增删改等数据库管理类请求，Elasticsearch作为从数据库，处理对数据库的各类检索请求，从而提高了记录存储的冗余性和系统的可用性。

2.1.2 数据库字段

数据库系统最基础的是数据存储的格式，这直接关系到数据库的信息容量及日后使用、管理的效率和难度，数据库的详细字段设计如表 1，其中标有“zh/en”的字段均包含“zh_hant”和“en”两个子字段。

与之前的整理工作相比，本数据库不仅要包含存储原始文献文本的字段，更要有存储天象记录科学参数化描述的字段，例如天象记录的时间、位置、亮度和颜色等。同时，为方便国外研究人员使用，提高数据库的国际化水平，记录中的各项文本信息还需要预留存储英文翻译的字段。另外，为方便研究者查询参考，数据库中还包括相关文献字段，将相关应用研究成果进行索引。为满足上述需求，本数据库的字段由证认天体(celestial_body)、文献记载(record)、天象(phenomenon)、观测者(observer)和相关文献(refs) 共5部分组成，每部分又包含若干子字段。

2.2 后端模块

该模块需根据MongoDB与Elasticsearch提供的基本语法，实现天象记录检索和数据库管理等核心功能。考虑到Elasticsearch对系统资源的消耗已经较高，所以后端选用高性能的Rust语言编写。该语言采用所有权和生命周期模型实现内存管理，没有运行开销和垃圾回收，在保证高可靠性和内存安全性的基础上，具有极高的性能。同时其语法特性丰富，有优秀的表达能力，因此，在运行效率和开发效率之间达到了较好的平衡。具体的Web框架采用基于Rust语言编写的高性能异步框架Axum。后端模块由天象记录检索和数据库管理两个子模块构成。

2.2.1 天象记录检索子模块

天象记录检索子模块主要处理用户的检索请求，并完成对检索结果的聚合、排序，实现对中国古代天象记录的数字化检索。该模块又包含语法检索、检索结果排序、检索结果聚合3个子模块。其中，语法检索模块定义了一种专门用于天象记录检索的领域专用语言DSL及其解析器，作为数据库的基本检索框架。对于前端模块传入的DSL检索语句，语法检索模块的解析器进行语法分析，并根据分析结果得到的用户检索的字段类型，调用不同的检索接口，生成相应的Elasticsearch检索和聚合语句，并提交Elasticsearch引擎执行，得到检索和聚合结果。同时按照用户指定的排序方式，对检索的结果进行排序。相关流程如图 3。

通常来说，简单的DSL语法定义及分析可以通过正则表达式完成，但本数据库的DSL语法需支持多种数据类型及逻辑运算，使用正则表达式难以表达复杂的语法结构，因此采用表达能力更强的解析表达文法(Parsing Expression Grammar, PEG) ^[19]表达DSL语法。与同样经常用于表达复杂语法的上下文无关文法(Context Free Grammar, CFG) 相比，PEG的语法规则本身便是解析规则，而非生成规则，故可以直接用于语法分析，且消除了二义性，更适合本数据库系统注重语法分析，以将DSL语句转化为Elasticsearch检索和聚合语句的场景。

DSL检索语句由检索表达式Expr及通过与、或、非逻辑运算符的连接组成，检索表达式Expr的一般形式为

${\rm{ }}Expr{\rm{ }} \leftarrow {\rm{ }}Field\,MatchOp\,Value\,,$

(1)

其中，Field表示所有可检索字段；MatchOp表示匹配符，支持大于(>)、小于(＜)、判等3种匹配运算，判等运算分为模糊匹配(: )和精确匹配(=) 两种类型；Value表示值，支持字符串(String)、浮点数(Double)、日期(Date)和列表([]) 等多种数据类型。检索表达式的详细定义如表 2，其中列表类型由“单元类型[]”表示，如String[] 表示字符串列表。

2.2.2 数据库管理子模块

数据库管理子模块面向数据库的管理者，提供中国古代天象记录的数字化整理服务，该模块又分为用户管理和记录管理两个子模块。

(1) 用户管理：实现用户管理的核心为权限认证机制。考虑到本系统是日后天文学史系列数字化工具的一部分，因此存在跨域认证的需求。为使各数字化工具间的用户系统能够互通，本系统采用目前较为流行的跨域认证方案JWT (JSON Web Token)。JWT的基本原理是用户凭借用户名、密码或其他安全凭证，向服务器发起认证请求，服务器认证通过后，向用户返回由服务器签名过的安全令牌。此后，用户再与服务器通信，访问需要认证的服务时，便可凭借此安全令牌证明自己的身份，服务器端也仅通过此安全令牌认定用户身份。因此与传统的基于Session和Cookie的认证方案相比，JWT方案的服务器端除用于签名的密钥外，是无状态的，可以方便地实现跨域扩展，同时也减轻了服务器的压力，提高了认证系统的可用性。目前，数据库的用户系统仅面向数据库管理用户，尚未面向普通用户开放，用户注册为邀请制，用户可以自主修改用户名、密码等信息，但对用户的删除操作需要超级管理员完成。

(2) 记录管理：用户在通过登录认证后，便可对天象记录进行添加、删除和编辑等管理操作。修改操作提交至MongoDB数据库执行完毕后，由Monstache基于MongoDB数据库的oplog机制同步至Elasticsearch引擎。

2.3 前端模块

前端模块是用户与数据库系统的交互接口，本数据库系统采用Vue3和基于Vue3的组件库Element Plus开发了一套便于用户使用的交互界面。前端模块与后端模块之间基于RESTful API接口和Ajax通信方式，采用JSON (JavaScript Object Notation) 数据格式进行交互。前端页面可分为前台和后台两大类，其中前台页面又包括首页、检索页和记录详情页，后台页面包括登录页、记录管理页和用户管理页。

3 系统展示

最终实现的中国古代天象记录数据库部署在了CPU为Intel Xeon Silver 4210R@2.4 GHz，内存为128 GB，操作系统为Debian 10的环境中。目前已根据《总集》，录入了720条示例数据。图 4~图 6为系统前台页面的测试截图。

图 4为数据库的首页。图 5为在数据库中检索记载内容包含“客星”或“周伯星”且证认天体为“SN 1006”，类型为“新星/超新星”的天象记录的结果。数据库检索页面自上而下为导航栏、搜索栏、排序方式选择栏、结果返回面板，结果返回面板自左至右为检索结果聚合面板和检索结果展示面板。

用户可以在导航栏中切换网页使用的语言，若选择使用英文，也将显示记录中各字段的英文翻译，方便国外学者使用。检索结果提供了结果高亮功能，命中的关键词以加粗红色字体标出。在录入示例数据的过程中，我们补充了部分记录在文献中的上下文，如某天象发生前后的历史事件等，这对于研究者判定记录的可信度等有重要作用。但这也造成了用户难以快速锁定天象记录本身，故系统将天象记录以黄褐色背景标出，提高用户的查阅效率。

对于检索结果的展示，系统提供了两种方式。一是如图 5 (a)的表格方式，该方式显示的信息密度较高，用户可以快速查看记录信息。但对于单一的记录来说，表格的显示方式为横向显示，这导致部分信息量较大的记录难以完全呈现，不便于用户查看。因此除表格显示模式外，系统还提供了如图 5 (b)的竖向显示的列表模式，方便用户读取检索结果。

为降低用户的检索难度，本系统并未直接将语法检索模块暴露给用户，而是进行了不同程度的封装。按使用的难易程度，系统由易到难提供了简单检索、高级检索、语法检索3种方式。简单检索仅能选择检索字段，不支持逻辑运算符连接，如图 4首页是简单检索；图 5 (a)为高级检索，可添加多个检索条件，不同检索条件之间可以使用与、或、非等逻辑运算符连接，表达比简单检索更为复杂的检索逻辑；语法检索则最为灵活，用户可直接输入检索语句进行检索，如图 5 (b)。

在检索结果页中，用户只能查看记录的部分信息，为查询记录全部字段的信息，用户可以点击检索结果页中感兴趣的记录条目，进入记录详情页，如图 6。

4 总结与展望

中国古代天象记录数据库综合运用面向文档数据库、全文检索、语法分析、Web等技术，实现了对古代天象记录的数字化检索与整理，与过去的天象记录整理成果相比，具有检索方便、更新及时、考虑了记录中的科学参数、国际化程度较高等优势。

但是，目前数据库仍然有不足之处。接下来，将逐步开放面向普通用户的用户系统，普通用户登录后可以申请提交数据库中未收录的记录条目，或对已有条目提出修改意见，并由后台管理人员进行审核，从而借助用户系统加管理员审核的方式，修正数据库中的问题，确保异构数据的一致性。此外也将开发个人记录图书馆的功能，用户可以根据研究需要，创建多个记录图书馆，从而支持天象记录的个性化整理和应用。

对于《总集》中剩余的一万余条天象记录，数据库将逐步录入。如前文所述，由于时代所限，《总集》在整理过程中有较多遗漏，并且随着近年来古籍整理和考古工作的开展，新发现的传世古籍和出土文献不断涌现，其中也包括一些天象记录。对于这些《总集》遗漏或之前未见的天象记录，数据库也将跟进补充。

此外，数据库将进一步改善用户界面和检索逻辑，并根据用户反馈，持续改进数据库中存在的其他问题，更好地为使用中国古代天象记录的研究人员服务，使中国古代天象记录数据库成为动态更新的天象记录应用研究平台。