1. 研究背景与国内外现状
1.1. 两色金鸡菊产业特性与溯源需求
两色金鸡菊(Coreopsis tinctoria)，作为菊科金鸡菊属一年生草本植物，原产于北美[1]，如今在我国新疆、云南、甘肃等地区广泛分布。其不仅以独特的观赏价值在园林景观中备受青睐，成为美化环境的重要元素，还因其富含黄酮类、多酚类、绿原酸、挥发油、氨基酸、总皂苷、多糖等多种活性成分[2]，在药用、茶饮加工等领域展现出巨大的应用潜力。在药用方面，《中国壮药图鉴》记载其可清热毒、除湿毒，对目赤肿痛、急慢性痢疾、疮疡肿毒等病症具有治疗功效，现代研究还发现其在治疗腹泻、感染和慢性代谢疾病等方面也有一定作用；茶饮加工中，其花泡制的茶饮香气扑鼻，且随着热水冲泡，花中的天然色素逐渐溶入水中，赋予茶汤一抹清亮的红色，深受消费者喜爱。
随着市场需求的扩大，两色金鸡菊的种植、加工及流通环节日益复杂，产品质量参差不齐、溯源信息不透明等问题逐渐凸显[3]，亟需建立一套完善的溯源系统，实现对两色金鸡菊全流程的追踪管理，成为保障产品质量、维护消费者权益的迫切需求。
在溯源系统中，数据库作为核心支撑部分，承担着数据存储、管理与交互的关键功能。它犹如整个溯源系统的“大脑”，系统运行过程中产生的各类数据，包括种植过程中的土壤环境数据、施肥用药记录，加工环节的工艺参数、设备运行数据，以及流通环节的物流轨迹、仓储条件数据等，都需要数据库进行高效存储。同时，数据库要能够对这些海量数据进行科学管理，确保数据的准确性、完整性和一致性，以便在需要时能够快速、准确地进行数据检索和调用，实现产品信息的全流程追溯。可以说，前期数据库设计质量的优劣，直接决定了溯源系统能否稳定、高效运行，以及是否具备良好的可扩展性，以适应未来市场发展和业务变化的需求。本文基于两色金鸡菊的产业链特点，从深入的需求分析入手，系统阐述数据库的概念设计、逻辑设计、物理设计及实现过程[4]，旨在为两色金鸡菊溯源系统的后续开发筑牢坚实基础，推动两色金鸡菊产业朝着规范化、标准化、可追溯化方向发展。
1.2. 国内外农产品/药材溯源数据库研究进展
1.2.1. 农产品溯源数据库研究
在农产品溯源数据库领域，国内外已形成较为成熟的研究体系与实践案例。国外以欧盟、美国为代表，注重全链条数据完整性与技术融合应用。欧盟早在21世纪初便通过《通用食品法》构建农产品追溯框架，其数据库设计强调“从农场到餐桌”的全环节覆盖，例如肉类产品追溯数据库中，不仅记录牲畜养殖地、饲料来源、疫苗接种记录，还包含屠宰加工流程、运输车辆GPS轨迹等细节，通过统一的GS1编码体系实现跨环节数据无缝对接，消费者可通过包装条码查询完整溯源信息[5]。美国则依托物联网与大数据技术提升数据库动态监控能力，如加州水果溯源系统中，通过土壤传感器实时采集温湿度、酸碱度数据，结合无人机巡检图像，实现种植环节数据自动化采集[6]；数据库后端通过数据挖掘算法分析生产参数与品质关联，为种植户提供精准管理建议，同时为监管部门提供质量风险预警支持。
国内研究则围绕“互联网 + 农业”战略快速推进，聚焦特色农产品的个性化溯源需求[7]。在水果、蔬菜等大宗农产品领域，已有多个地区构建了结合地理信息系统(GIS)的溯源数据库——例如山东苹果种植基地的溯源系统，消费者扫描二维码即可获取果园地理位置(通过GIS地图直观展示)、采摘时间、施肥用药记录等信息；浙江蔬菜溯源数据库则进一步整合生产主体资质、检测报告等数据，实现“产地准出–市场准入”的衔接。此外，国内研究还注重数据库的实用性与低成本性，例如针对中小种植户开发的移动端数据录入系统，通过简化操作界面降低使用门槛，有效解决了基层数据采集难的问题。
1.2.2. 药材溯源数据库研究
药材作为特殊农产品，其溯源数据库研究更侧重质量安全性与产地真实性。国外研究以先进分析技术与数据库结合为特色，例如稳定同位素溯源技术的应用——由于不同产地土壤、气候条件差异，药材中C、N、H、O等同位素自然丰度存在显著区别，相关数据库通过收录全球主要药材产区的同位素特征数据，为产地鉴别提供科学依据[8]。此外，德国药用植物溯源系统还整合了指纹图谱技术，将药材有效成分色谱数据存入数据库，通过比对样本与数据库标准图谱，快速鉴别药材真伪与品质等级。
国内药材溯源数据库研究则以“全产业链标准化”为核心方向，形成国家、地方、企业多层级建设格局。工业和信息化部牵头建设的“中药全产业链质量可追溯数据平台”是典型代表，该平台制定了涵盖种植、加工、炮制、流通的统一数据标准，目前已覆盖全国21个省市、457个种植基地，服务100余家重点中药企业，涉及113种常用中药材；数据库日均更新种植管理、饮片加工数据约1.2万条，累计数据量超2TB，不仅为企业提供生产流程记录工具，还为监管部门提供全国中药材质量动态监控视图[9]。地方层面，特色药材溯源数据库建设成效显著，如广东新会陈皮溯源系统，数据库不仅记录种苗品种、种植年限等基础信息，还包含仓储环境温湿度变化、陈化周期等特色数据，通过“区块链 + 数据库”技术确保数据不可篡改，有效维护新会陈皮的地理标志产品价值。
1.2.3. 研究现状总结与本文定位
综合来看，现有研究已在农产品/药材溯源数据库的“数据采集–存储–应用”全流程形成技术积累，但仍存在两方面局限：一是“数据孤岛”问题突出。不同品类、不同地区的溯源数据库缺乏统一数据接口，例如水果溯源数据库与蔬菜溯源数据库无法实现跨品类数据联动，难以支撑多品类农产品综合监管；二是特色小众产品适配性不足。现有数据库多针对大宗农产品(如粮食、水果)或常用中药材(如人参、当归)设计，未考虑两色金鸡菊这类“观赏–药用–茶饮”多用途特色植物的产业链特性，例如其加工环节涉及的“花瓣提取工艺参数”、流通环节的“色素稳定性监控数据”，在现有数据库中无对应字段设计，无法直接复用。
本文正是针对上述局限开展研究：一方面，借鉴现有数据库的全链条数据架构与技术经验(如传感器数据采集、GIS地理信息整合)；另一方面，结合两色金鸡菊“多用途、小品类”的产业特点，设计专属数据字段与表结构，填补特色植物溯源数据库的研究空白，同时为后续同类小众农产品/药材的溯源数据库建设提供可复用的设计框架，既是对现有研究的补充，也是特色场景下的创新应用。
2. 系统需求分析
2.1. 业务流程梳理
两色金鸡菊的产业链涵盖种植、采收、加工、仓储、运输、销售6大环节，各环节的关键信息需纳入溯源体系，如图1所示。
种植环节：包括种植基地信息、种子来源、种植时间、田间管理(施肥、灌溉、病虫害防治)、环境数据(温度、湿度、光照)等；
采收环节：记录采收时间、采收人员、采收批次、鲜品质量检测结果(如含水率、杂质率)；
加工环节：涉及加工企业信息、加工工艺(杀青、干燥、粉碎等)、加工时间、半成品检测指标(如活性成分含量)；
仓储环节：存储仓库信息、入库时间、存储条件(温度、湿度)、库存变动记录；
运输环节：运输企业、运输方式、起止时间、运输过程中的环境监控数据；
销售环节：销售渠道(商超、电商、经销商)、销售时间、产品批次与溯源码关联信息。
Figure 1. Flow chart of operations
图1. 业务流程图
2.2. 功能需求
溯源系统需实现数据采集、存储、查询、追溯四大核心功能，对应数据库的需求，如图2所示。
数据采集：支持种植户、加工企业、物流商等多主体通过终端录入数据，数据库需兼容结构化数据(如时间、数值)与半结构化数据(如图片、检测报告)；
数据存储：确保全产业链数据的完整性与关联性，需存储约50万条基础记录(按年交易量10万吨估算)，并支持历史数据归档；
数据查询：满足多维度查询需求，如按产品溯源码查询全流程信息、按批次查询加工记录、按种植基地查询环境数据；
追溯功能：实现“正向追踪”(从种植到销售)与“反向溯源”(从销售端追溯至种植端)，数据库需支持高效的关联查询。
Figure 2. Function requirement diagram
图2. 功能需求图
2.3. 非功能需求
安全性：敏感数据(如企业联系方式、检测数据)需加密存储[10]，不同用户角色(如管理员、企业、消费者)权限需严格区分；
可靠性：数据存储需保证99.9%的可用性[11]，支持定期备份与灾难恢复；
性能：单条溯源信息查询响应时间 ≤ 1秒[12]，并发查询支持500用户同时在线；
可扩展性：预留字段与表结构，支持未来新增环节(如深加工、出口检疫)的数据存储需求。
3. 数据库概念设计
3.1. 实体识别
基于业务流程梳理，识别出以下核心实体：
种植基地：包含基地基本信息、地理位置、负责人等；
种子：记录种子来源、品种、检疫证明等；
种植记录：关联种植基地与种子，记录种植过程数据；
环境监测点：采集种植区域的温湿度、光照等环境数据；
采收批次：对应某一时间段内的采收信息，关联种植基地；
加工企业：包含企业资质、加工设备、工艺流程等；
加工记录：关联采收批次与加工企业，记录加工过程指标；
仓储仓库：存储仓库位置、设施、存储条件等信息；
库存记录：关联加工半成品/成品与仓库，记录库存变动；
运输单：关联发货仓库与收货方，记录运输过程数据；
销售订单：包含销售渠道、交易信息，关联运输单与产品批次；
溯源码：唯一标识单个产品或批次，关联全流程记录。
3.2. E-R图设计
通过实体间的关系分析，绘制E-R图(实体–关系图)如图3所示。
一对一关系：溯源码与产品批次一一对应，一个批次对应唯一溯源码；
一对多关系：一个种植基地可对应多个种植记录，一个加工企业可处理多个采收批次；
多对多关系：运输单可关联多个库存记录(同一批次分多车运输)，通过“运输–库存关联表”实现间接关联。
核心实体关系示例：
种植基地(基地ID)→种植记录(基地ID，外键)；
采收批次(批次ID)→加工记录(批次ID，外键)；
加工记录(加工ID)→库存记录(加工ID，外键)；
库存记录(库存ID)→运输单(库存ID，外键)；
运输单(运输ID)→销售订单(运输ID，外键)；
销售订单(订单ID)→溯源码(订单ID，外键)。
Figure 3. Entity-Relationship (E-R) model diagram
图3. 实体–联系(E-R)模型图
4. 数据库逻辑设计
4.1. 表结构设计
根据E-R图转换为关系模式，共设计15张核心表，涵盖产业链各环节，部分关键表结构见表1~4：
Table 1. Planting base table (t_planting_base)
表1. 种植基地表(t_planting_base)
字段名 |
数据类型 |
约束 |
说明 |
base_id |
VARCHAR (32) |
PRIMARY KEY |
基地唯一标识(UUID) |
base_name |
VARCHAR (100) |
NOT NULL |
基地名称 |
location |
VARCHAR (200) |
NOT NULL |
地理位置(经纬度) |
responsible_person |
VARCHAR (50) |
NOT NULL |
负责人姓名 |
contact |
VARCHAR (20) |
UNIQUE |
联系电话 |
qualification |
VARCHAR (255) |
|
资质证明路径 |
create_time |
DATETIME |
NOT NULL |
记录创建时间 |
Table 2. Planting record table (t_planting_record)
表2. 种植记录表(t_planting_record)
字段名 |
数据类型 |
约束 |
说明 |
planting_id |
VARCHAR (32) |
PRIMARY KEY |
种植记录ID |
base_id |
VARCHAR (32) |
FOREIGN KEY |
关联种植基地 |
seed_id |
VARCHAR (32) |
FOREIGN KEY |
关联种子信息 |
plant_date |
DATE |
NOT NULL |
种植日期 |
expected_harvest_date |
DATE |
|
预计采收日期 |
area |
DECIMAL (10, 2) |
NOT NULL |
种植面积(亩) |
fertilization |
TEXT |
|
施肥记录(JSON格式) |
pest_control |
TEXT |
|
病虫害防治记录 |
Table 3. Processing record table (t_processing_record)
表3. 加工记录表(t_processing_record)
字段名 |
数据类型 |
约束 |
说明 |
processing_id |
VARCHAR (32) |
PRIMARY KEY |
加工记录ID |
batch_id |
VARCHAR (32) |
FOREIGN KEY |
关联采收批次 |
enterprise_id |
VARCHAR (32) |
FOREIGN KEY |
关联加工企业 |
process_type |
VARCHAR (50) |
NOT NULL |
加工类型(杀青/干燥) |
start_time |
DATETIME |
NOT NULL |
加工开始时间 |
end_time |
DATETIME |
NOT NULL |
加工结束时间 |
active_ingredient |
DECIMAL (8, 2) |
|
活性成分含量(%) |
inspector |
VARCHAR (50) |
NOT NULL |
检测人员 |
Table 4. Trace code table (t_trace_code)
表4. 溯源码表(t_trace_code)
字段名 |
数据类型 |
约束 |
说明 |
trace_code |
VARCHAR (64) |
PRIMARY KEY |
溯源码(二维码内容) |
order_id |
VARCHAR (32) |
FOREIGN KEY |
关联销售订单 |
product_batch |
VARCHAR (50) |
NOT NULL |
产品批次号 |
production_date |
DATE |
NOT NULL |
生产日期 |
expiry_date |
DATE |
NOT NULL |
保质期至 |
status |
TINYINT |
NOT NULL |
状态(0-未激活，1-已激活) |
4.2. 关系约束设计
主键约束：所有表均以UUID作为主键，确保全局唯一性；
外键约束：通过外键关联实现表间数据一致性，如processing_id关联batch_id，删除采收批次记录时需先删除关联的加工记录；
非空约束：关键业务字段(如种植日期、加工时间)设置非空约束，避免核心数据缺失；
唯一约束：溯源码、企业联系方式等字段设置唯一约束，防止重复录入；
检查约束：对数值型字段设置范围限制，如活性成分含量active_ingredient取值范围为0~100。
5. 数据库物理设计
5.1. 数据库选型
考虑到系统需求(中等数据量、高并发查询、开源免费)，选择MySQL 8.0作为数据库管理系统，理由如下：
5.2. 存储引擎与字符集
存储引擎：核心业务表采用InnoDB，支持事务与外键；日志表(如操作日志、错误日志)采用MyISAM，优化写入性能；
字符集：采用UTF8mb4字符集，支持中文、英文及特殊符号(如希腊字母表示的化学指标)，避免乱码问题。
5.3. 数据库选型
为提升查询效率，设计以下关键索引：
主键索引：所有表的主键字段自动创建主键索引；
外键索引：外键字段(如base_id、batch_id)创建普通索引，加速关联查询；
联合索引：在高频查询字段组合上创建联合索引，如(trace_code, product_batch) (用于按溯源码 + 批次查询)、(plant_date, base_id) (用于按时间 + 基地查询种植记录)；
全文索引：在processing_type (加工类型)、pest_control (病虫害防治)等文本字段上创建全文索引，支持模糊查询。
5.4. 分区策略
针对数据量较大的表(如环境监测表、运输记录表)，采用水平分区：
5.5. 数据备份与恢复
备份策略：每日23:00执行全量备份，采用MySQLdump工具生成备份文件，存储至异地服务器；每6小时执行增量备份，记录日志文件(binlog)，确保数据恢复点精确到小时；
恢复机制：支持基于时间点的恢复，通过全量备份 + 增量日志还原指定时间的数据状态。
6. 数据库实现
6.1. 数据库创建
通过SQL语句创建数据库及核心表，示例如图4所示：
Figure 4. Partial encoding
图4. 部分编码
6.2. 数据接口设计
为实现与溯源系统前端及终端设备的数据交互，设计RESTful API接口，部分核心接口如下：
种植记录录入：POST /api/planting/record，接收JSON格式数据，调用存储过程写入t_planting_record；
加工记录录入：POST /api/processing/record，支持批量导入(单次最多100条)。
溯源查询：GET /api/trace?code=xxx，通过溯源码查询全流程数据，关联7张表实现联合查询；
批次查询：GET /api/batch?batchId=xxx，返回该批次的采收、加工、运输信息。
用户认证：POST /api/auth/login，验证用户身份并分配数据访问权限；
权限控制：基于角色的访问控制(RBAC)，通过数据库视图限制用户可访问的字段(如消费者不可见企业联系方式)。
6.2. 数据安全实现
敏感数据加密：联系电话、检测报告编号等字段采用AES-256加密存储，密钥通过环境变量管理；
SQL注入防护：所有接口采用参数化查询，避免直接拼接SQL语句；
日志审计：创建操作日志表(t_operation_log)，记录用户登录、数据修改等行为，支持追溯异常操作。
7. 数据库测试与优化
7.1. 功能测试
通过黑盒测试验证数据库功能：
数据录入测试：模拟1000条种植记录、500条加工记录录入，检查是否符合约束规则(如非空字段不得为空)；
关联查询测试：通过溯源码查询全流程数据，验证是否返回完整的种植、加工、销售信息；
权限测试：使用不同角色账号登录，检查是否只能访问授权数据(如消费者无法查看种植基地的联系电话)。
7.2. 性能测试
采用 JMeter 工具进行性能测试：
并发查询测试：模拟500用户同时查询溯源信息，平均响应时间为0.6秒，满足 ≤ 1秒的需求；
数据插入测试：批量插入10万条环境监测数据，耗时87秒，吞吐量约1150条/秒；
大数据量查询测试：在100万条历史记录中查询某批次的加工信息，索引命中情况下查询时间 ≤ 0.3秒。
7.3. 优化措施
查询优化：对慢查询(如未命中索引的全表扫描)进行SQL改写，添加必要索引；
存储优化：对超过3年的历史数据进行归档，转移至只读表空间，减少活跃数据量；
连接池优化：配置数据库连接池参数(最大连接数500，空闲超时300秒)，避免连接耗尽。
8. 结语
本文聚焦两色金鸡菊溯源系统前期数据库的设计与实现工作，通过系统性的技术攻关，形成了一套可支撑全产业链数据管理的完整解决方案。其核心技术路径是从产业链全流程梳理入手，明确了数据库的功能需求与非功能指标，为架构设计奠定了扎实基础[13]。在概念设计阶段，运用E-R图精准呈现数据模型，成功识别出12个核心实体及关联关系，构建了清晰的逻辑框架。基于此，设计15张核心数据表，完整定义字段约束规则与索引优化策略，确保数据存储的规范性与查询效率[14]。在物理实现层面，完成数据库部署、接口开发及安全防护体系搭建，经多维度测试验证，系统展现出优异的稳定性与高效性[15]。
该数据库可全面支撑两色金鸡菊从种植到销售的全流程数据溯源，为后续系统开发提供可靠的数据存储架构。
未来扩展有三方面：一是引入InfluxDB存储环境监测高频数据，提升读写效能[16]；二是结合区块链实现数据不可篡改，用智能合约验证真实性，增强公信力[17]；三是将设计模式复用至甘草、枸杞等药用植物溯源系统[18]，为中药材质量管控提供参考。
通过持续优化，该数据库将完善产业数据管理能力[19]，支撑两色金鸡菊产业标准化、规范化发展，助力提升产品质量与市场竞争力[20]。
基金项目
2023年新疆维吾尔自治区重点研发计划项目(项目编号：2023B02010-2；课题编号：2023B02010-2；子课题编号：2023B02010-2-3)。
NOTES
*通讯作者。