基于RAG的物流冷链运输咨询系统设计计算机毕设(源码+lw+部署文档+讲解等)

基于RAG的物流冷链运输咨询系统设计计算机毕设(源码+lw+部署文档+讲解等)

发布时间：2026/9/29 15:09:35
基于RAG的物流冷链运输咨询系统设计计算机毕设(源码+lw+部署文档+讲解等) 博主介绍✌ 专注于VUE,小程序安卓Java,python,物联网专业有18年开发经验长年从事毕业指导项目实战✌选取一个适合的毕业设计题目很重要。✌关注✌私信我✌具体的问题我会尽力帮助你。一、研究目的本研究旨在构建一种基于检索增强生成技术的物流冷链运输咨询系统以提升冷链物流管理的智能化水平。 在全球供应链日益复杂、食品安全与温度敏感性要求日趋严格的背景下传统的冷链运输决策往往依赖人工经验和静态规则导致响应时间延长、资源配置低效以及易产生温度偏差。 为解决上述痛点本研究将检索增强生成技术与冷链物流知识图谱相结合构建一个能够实时检索相关文献、行业标准及历史运输数据并通过自然语言生成模块为运营人员提供精准、可解释的决策建议的系统框架。 该系统通过对海量结构化与非结构化信息进行语义索引实现对温度监测日志、设备维护记录、路线规划方案等多源数据的高效检索从而为用户提供基于证据的运输路径优化、装载方案调整以及风险预警。 研究的核心目标之一是验证检索增强生成模型在冷链场景下的可解释性与鲁棒性即在面对不同温度波动、设备故障或突发事件时系统能够及时检索相关案例并生成可操作的应对措施。 通过与行业合作伙伴开展实证实验本研究将评估系统在降低货物损耗率、缩短运输周期以及提升客户满意度方面的实际效果并对比传统决策支持工具的性能差异。 此外研究还将探讨知识图谱在冷链物流中的动态更新机制确保系统能够持续吸收最新法规、技术进展和运营经验从而保持长期的适用性与前瞻性。 在实现层面本研究计划采用分层架构将检索模块、生成模块与业务逻辑层分离以便于后期的功能扩展和性能优化。 最终本研究期望通过构建可复制、可扩展的冷链运输咨询系统为物流企业提供一种基于人工智能技术的决策支持工具进而推动冷链物流行业向更高效、更安全、更绿色的方向发展。二、研究意义本研究的意义主要体现在对冷链物流行业信息化与智能化水平的提升、对食品安全风险管理的强化以及对可持续发展目标的贡献。 首先随着全球供应链网络的日益复杂化和消费者对食品安全要求的不断提高传统基于经验与静态规则的冷链运输决策已难以满足实时性与精准性的双重需求。 本研究通过引入检索增强生成技术将海量结构化与非结构化数据进行语义融合能够在短时间内为运营人员提供基于证据的运输路径优化方案从而显著降低温度偏差导致的货物损耗率。 其次系统通过知识图谱动态更新行业标准与最佳实践实现对突发事件的快速响应与风险预警为冷链企业构建了一个可解释、可追溯的决策支持框架提升了管理透明度与合规性。 再者在推动技术创新方面本研究将自然语言处理、语义检索与物流优化算法有机结合形成了一套可迁移至其他供应链场景的技术范式为学术界提供了跨域研究的案例与方法论参考。 此外系统的部署将促进冷链企业数字化转型降低人工成本提高运营效率从而在经济层面实现成本节约与利润提升。 在社会层面减少因温度失控导致的食品浪费将直接推动资源节约与环境保护目标的实现符合联合国可持续发展目标中的负责任消费与生产。 综上所述本研究不仅为冷链物流行业提供了具有前瞻性与实用性的技术方案也为相关学科交叉研究提供了丰富的数据资源与实验平台具有重要的理论价值与应用前景。三、国内外研究现状国内外在物流冷链运输领域的研究已形成多条互补的技术路线主要可归纳为实时监测与数据采集、预测与优化决策、信息共享与可追溯性以及智能化辅助系统等四大方向。 在实时监测与数据采集方面国内研究聚焦于基于物联网技术的温度传感网络建设利用低功耗蓝牙、LoRaWAN等无线通信协议实现对冷链车辆及仓储环境的全程监控国外则在此基础上进一步引入边缘计算节点将数据预处理与异常检测任务迁移至现场设备以降低云端负载并提升响应速度。 预测与优化决策方面国内学者多采用统计学习与机器学习方法对温度曲线进行回归预测并结合遗传算法或粒子群优化实现路线与装载方案的优化国外研究则更倾向于深度强化学习框架通过模拟环境训练智能体以在多目标约束下动态决策已在部分大型物流企业中得到试点应用。 信息共享与可追溯性方面国内外均重视区块链技术的引入以实现货物从源头到终端的不可篡改记录中国的一些企业已将基于以太坊或超级账本的冷链溯源平台与温度监测系统对接形成闭环管理欧美则通过标准化接口与第三方数据平台实现跨行业信息共享提升整体供应链透明度。 智能化辅助系统方面国内研究多聚焦于基于规则引擎和专家系统的决策支持而国外则在自然语言处理与检索增强生成RAG技术上取得进展利用大模型结合知识图谱为运营人员提供可解释的建议。 综上所述国内外在冷链物流领域已形成以物联网为支撑、以大数据与人工智能为驱动的多维技术体系但在检索增强生成与知识图谱深度融合方面仍处于起步阶段。 本研究正是在此背景下尝试将RAG技术与冷链物流知识图谱相结合以实现更精准、更可解释的运输咨询服务从而填补现有研究的空白并推动行业技术升级。四、预期达到目标及解决的关键问题预期目标主要包括构建一套基于检索增强生成技术的物流冷链运输咨询系统、验证其在实际运营中的有效性与可解释性以及为行业提供可复制的技术框架。 首先系统需实现对温度监测日志、设备维护记录、路线规划方案等多源数据的语义检索并通过自然语言生成模块为运营人员提供精准、可操作的决策建议其次系统应在响应时间不超过三秒的前提下完成检索与生成任务以满足冷链运输实时性的要求再次系统需支持知识图谱动态更新机制使其能够持续吸收最新法规、行业标准与运营经验从而保持长期适用性。 最终本研究期望通过与行业合作伙伴开展实证实验验证系统在降低货物损耗率、缩短运输周期以及提升客户满意度方面的实际效果并对比传统决策支持工具的性能差异。关键问题主要集中在数据异构性与质量保障、模型可解释性与鲁棒性、实时性能与资源消耗以及知识图谱维护与更新。 数据层面冷链物流涉及结构化温度传感数据、半结构化设备日志及非结构化文本报告如何统一语义表示并保证检索准确率是首要挑战模型层面检索增强生成技术在生成过程中可能产生事实错误或缺乏可解释性如何通过知识图谱约束与后验校验提升输出可信度亟待解决实时层面系统需在有限的计算资源下完成检索与生成任务如何设计高效的检索索引与模型压缩方案是技术难点知识图谱层面行业标准与最佳实践随时更新如何实现知识图谱的增量学习与版本管理以保证系统始终反映最新信息也是关键研究方向。五、研究内容本研究围绕构建一套基于检索增强生成RAG技术的物流冷链运输咨询系统展开整体研究内容可分为数据采集与预处理、知识图谱构建、检索模块设计、生成模块设计、系统集成与性能优化以及实验评估七大部分。 通过上述步骤旨在实现对冷链运输过程中的温度监测日志、设备维护记录、路线规划方案等多源数据的语义检索并利用自然语言生成技术为运营人员提供可解释的决策建议。首先数据采集与预处理阶段将从合作物流企业获取实时温度传感器数据、车辆定位信息、设备维护日志以及历史运输记录等多维度数据。 对于结构化传感器数据采用时间序列标准化方法进行缺失值插补与噪声过滤 对于半结构化日志与非结构化文本则通过分词、命名实体识别与关系抽取技术将其转换为统一的知识表示格式。 预处理完成后所有数据将被存入统一的数据仓库并建立时间戳索引以支持高效检索。其次知识图谱构建阶段将基于预处理后的数据以及行业标准文档、法规条款和最佳实践手册等构建多层次的冷链物流知识图谱。 该图谱包含实体如温度阈值、设备类型、运输路线、属性如容忍温度范围、保质期以及关系如“适用于”“受限于”“关联风险”。 为保证知识图谱的可扩展性与可维护性将采用本体驱动的方式利用OWL或RDF技术定义领域本体并通过推理引擎实现隐式知识的自动发现。第三检索模块设计将结合向量检索与传统基于关键词的检索相结合的混合策略。 对于结构化查询将使用倒排索引和布尔检索 对于语义查询将利用预训练的句子编码器如Sentence-BERT将文本映射到向量空间并通过FAISS等高效近似最近邻算法实现快速匹配。 该模块需支持多模态检索即同时考虑温度曲线、设备状态和路线信息以提供更精确的检索结果。第四生成模块设计将采用基于Transformer的大模型如GPT或BART并通过检索增强技术与知识图谱进行融合。 在生成过程中系统首先根据检索结果获取相关文档片段并将其作为上下文注入模型 同时通过知识图谱的实体与关系信息对生成内容进行约束确保输出符合行业规范且可解释。 为降低模型推理成本将采用模型蒸馏与参数剪枝技术对原始大模型进行压缩以满足实时响应需求。第五系统集成与性能优化阶段将把上述模块整合为统一的微服务架构。 通过容器化部署Docker/Kubernetes实现模块的弹性伸缩 采用消息队列Kafka实现异步任务调度 在数据流与计算资源之间引入缓存层Redis以降低延迟。 此外将对检索与生成流程进行瓶颈分析针对热点查询与高并发场景进行性能调优。第六实验评估阶段将通过与合作企业的真实运营数据进行对比实验评估系统在温度偏差预警、路线优化建议、装载方案调整等方面的准确率、召回率和响应时间。 同时将设计用户体验问卷与专家评审机制对生成建议的可解释性与实用性进行定量与定性评价。 通过多维度指标评估验证系统在降低货物损耗、缩短运输周期以及提升客户满意度方面的实际效果。综上所述本研究将从数据层面到模型层面再到系统集成与评估全方位构建并验证基于RAG技术的物流冷链运输咨询系统为行业提供一种可复制、可扩展且具备高可解释性的智能决策支持方案。六、需求分析用户需求方面系统的主要使用者包括冷链物流企业的运营管理人员、仓储与运输调度员以及质量安全监管部门。 运营管理人员需要能够实时掌握车辆温度曲线、设备状态以及路线动态以便在温度偏差或设备故障发生时迅速做出调整 他们期望系统能够提供基于历史数据与行业标准的风险预警并给出可操作的装载与路线优化建议从而降低货物损耗率并提升运输效率 仓储调度员则关注于装载方案的动态调整与仓库温控管理期望系统能够根据实时温度监测结果和库存状态自动生成最优装载清单并在温度异常时提供即时报警与处理方案 质量安全监管部门则需要系统能够生成可追溯的运输记录报告满足法规对冷链溯源的合规要求并对异常事件进行归因分析。 综上所述用户需求主要集中在实时监测、风险预警、决策支持、合规可追溯以及操作便捷性等方面。功能需求方面系统应包含数据采集与预处理模块以实现对温度传感器数据、车辆定位信息、设备维护日志以及历史运输记录等多源数据的统一采集与清洗 知识图谱管理模块需支持行业标准、法规条款和最佳实践手册的本体化建模并能够进行增量更新与版本控制 检索引擎模块应结合向量检索与传统关键词检索支持多模态查询并提供高效的近似最近邻搜索 生成引擎模块基于Transformer大模型并通过检索增强技术与知识图谱约束能够生成可解释且符合行业规范的决策建议 用户界面模块应提供交互式仪表盘展示实时温度曲线、风险预警状态以及建议方案并支持自定义视图与报表导出 通知与报警模块需实现多渠道推送短信、邮件、App推送并支持阈值自定义 性能监控与日志管理模块应记录系统运行指标支持弹性伸缩与故障诊断。 以上功能需求共同构成了满足用户在实时监测、风险预警、决策支持与合规可追溯等方面的完整系统功能。七、可行性分析经济可行性方面本系统的研发成本主要集中在数据采集设备、服务器与云计算资源、人工智能模型训练与部署以及后期维护与升级。 通过与行业龙头企业合作获取现有传感器网络和物流数据可显著降低初期硬件投入 同时采用开源大模型与向量检索框架如Sentence‑BERT、FAISS可减少算法研发费用 在云端部署微服务架构后按需扩容的弹性计算模式能够将运维成本控制在可接受范围内。 从收益角度看系统能够帮助企业降低因温度偏差导致的货物损耗率平均可节约5%至10%的物流成本 通过优化路线与装载方案还能缩短运输周期、提升客户满意度从而提升订单量与利润空间。 结合行业规模与市场需求预测系统在三到五年内即可实现成本回收并产生正向现金流显示出良好的经济可行性。社会可行性方面冷链物流直接关系到食品安全与公众健康系统的实施能够提升温度监测的透明度与可追溯性符合国家对食品安全监管的要求 通过提供实时风险预警与决策支持可降低因温差导致的食品腐败事件从而提升消费者信任。 同时系统采用用户友好的交互界面与多渠道报警功能降低了操作门槛易于被不同层级的物流从业人员接受 其数据合规性设计符合《个人信息保护法》与《网络安全法》能够在保障隐私的前提下实现数据共享。 在社会影响层面系统的推广有助于推动冷链物流行业向数字化、智能化转型提升整体行业竞争力与可持续发展水平。技术可行性方面现有物联网传感器、边缘计算节点以及云平台已能够满足实时数据采集与处理需求 语义检索与向量检索技术已在工业互联网领域得到广泛应用可直接迁移至本系统 检索增强生成技术基于Transformer模型已在多模态问答与知识图谱融合中取得显著效果且可通过模型蒸馏与参数剪枝实现实时推理。 知识图谱构建方面行业标准与法规可通过本体化建模实现结构化表达推理引擎能够自动发现隐式关系 由于冷链物流数据具有时序性与空间性系统需在检索与生成模块中加入时间窗口与地理约束以保证结果的时效性与准确性。 在系统集成层面微服务架构与容器化部署能够实现模块间的松耦合与弹性伸缩 通过消息队列实现异步任务调度可有效缓解高并发场景下的计算压力。 综合上述技术要素本系统在技术可行性上具备成熟的基础与实现路径。八、功能分析系统功能模块设计围绕用户需求与技术可行性展开逻辑分为七大核心模块每个模块内部进一步细化为若干子功能以实现对冷链物流全过程的实时监测、风险预警、决策支持与合规可追溯。数据采集与预处理模块负责从温度传感器、车辆定位设备、设备维护系统以及历史运输记录等多源数据平台获取原始信息通过时间戳同步与缺失值插补技术保证数据完整性对结构化传感器数据采用标准化滤波与异常检测算法去除噪声并标记温度偏差对半结构化日志与非结构化文本进行分词、命名实体识别与关系抽取将其转换为统一的知识表示格式最终将清洗后的数据存入统一的数据仓库并构建时间序列索引以支持高效检索。知识图谱管理模块以行业本体为核心构建多层次的冷链物流知识图谱通过OWL或RDF定义实体、属性与关系涵盖温度阈值、设备类型、运输路线、法规条款等利用推理引擎实现隐式知识的自动发现与更新支持增量学习与版本管理保证知识库随行业标准变化而动态演进。检索引擎模块结合传统关键词检索与向量检索技术提供多模态查询能力对结构化查询使用倒排索引与布尔逻辑对语义查询利用Sentence‑BERT将文本映射至向量空间并通过FAISS实现近似最近邻搜索支持时间窗口与地理约束过滤以提高检索结果的时效性与相关性检索结果以可视化面板展示并提供原始文档片段供后续生成模块使用。生成引擎模块基于Transformer大模型采用检索增强生成RAG架构在生成过程中将检索得到的文档片段与知识图谱中的实体关系作为上下文注入模型通过知识图谱约束机制对输出进行事实校验与可解释性增强为降低推理延迟采用模型蒸馏与参数剪枝技术对原始大模型进行压缩生成结果以自然语言形式呈现给用户并可导出为结构化报告。用户界面与仪表盘模块提供交互式可视化平台实时展示温度曲线、设备状态、路线动态与风险预警支持自定义视图布局与报表模板通过多级权限管理确保不同角色运营管理、调度员、监管部门获得相应信息访问权限界面设计遵循人机工程学原则降低操作门槛。通知与报警模块负责多渠道推送与事件响应根据预设阈值触发短信、邮件或App推送报警支持自定义报警规则与优先级对异常事件进行归因分析并记录在系统日志中以便后续追溯。性能监控与日志管理模块实时收集系统运行指标CPU、内存、网络延迟等通过Grafana等可视化工具展示健康状态日志模块采用分布式日志框架支持查询与审计对关键操作进行审计跟踪满足合规要求。上述七大功能模块通过微服务架构实现解耦与弹性伸缩容器化部署保证环境一致性消息队列实现异步任务调度缓解高并发场景下的计算压力整体系统能够在三秒内完成检索与生成响应满足冷链物流实时决策需求。九、数据库设计表一SensorData传感器数据表字段名(英文) | 说明(中文) | 大小 | 类型 | 主外键 | 备注sensor_id | 传感器编号 | 20 | VARCHAR(20) | PK | 主键唯一标识每条记录vehicle_id | 车辆编号 | 20 | VARCHAR(20) | FK→Vehicle.vehicle_id | 外键关联车辆表timestamp | 数据采集时间戳 | - | DATETIME | - | 记录传感器数据的采集时间temperature | 温度值摄氏度 | - | DECIMAL(5,2) | - | 传感器测得温度humidity | 湿度值% | - | DECIMAL(5,2) | - | 传感器测得湿度表二Vehicle车辆信息表字段名(英文) | 说明(中文) | 大小 | 类型 | 主外键 | 备注vehicle_id | 车辆编号 | 20 | VARCHAR(20) | PK | 主键唯一标识每辆车license_plate | 车牌号 | 10 | VARCHAR(10) | - |driver_name | 驾驶员姓名 | 50 | VARCHAR(50) | - |capacity_km3 | 装载容量立方米 | - | DECIMAL(6,2) | -表三MaintenanceLog维护日志表字段名(英文) | 说明(中文) | 大小 | 类型 | 主外键 | 备注log_id | 日志编号 | 20 | VARCHAR(20) | PK | 主键唯一标识每条日志vehicle_id | 车辆编号 | 20 | VARCHAR(20) | FK→Vehicle.vehicle_id | 外键关联车辆表maintenance_date | 维护日期时间戳 | - | DATETIME | -description | 维护描述信息 | - | TEXT | -表四RoutePlan路线规划表字段名(英文) | 说明(中文) | 大小 | 类型 | 主外键 | 备注route_id | 路线编号 | 20 | VARCHAR(20) | PK | 主键唯一标识每条路线规划vehicle_id | 车辆编号 | 20 | VARCHAR(20) | FK→Vehicle.vehicle_id | 外键关联车辆表start_location | 起点位置描述 | 100 | VARCHAR(100) | -end_location | 终点位置描述 | 100 | VARCHAR(100) | -planned_start_time | 计划起始时间戳 | - | DATETIME | -planned_end_time | 计划结束时间戳 | - | DATETIME | -status | 路线状态规划中、执行中、已完成 | 20 | VARCHAR(20) | -表五LoadPlan装载方案表字段名(英文) | 说明(中文) | 大小 | 类型 | 主外键 | 备注load_plan_id | 装载方案编号 | 20 | VARCHAR(20) | PK | 主键唯一标识每个装载方案route_id | 路线编号 | 20 | VARCHAR(20) | FK→RoutePlan.route_id | 外键关联路线规划表product_type | 产品类别如蔬菜、肉类 | 50 | VARCHAR(50) | -quantity_kg | 装载重量千克 | - | DECIMAL(10,2) | -temp_requirement_min | 最低温度要求摄氏度 | - | DECIMAL(5,2) | -temp_requirement_max | 最高温度要求摄氏度 | - | DECIMAL(5,2) | -表六TransportRecord运输记录表字段名(英文) | 说明(中文) | 大小 | 类型 | 主外键 | 备注record_id | 记录编号 | 20 | VARCHAR(20) | PK | 主键唯一标识每条运输记录route_id | 路线编号 | 20 | VARCHAR(20) | FK→RoutePlan.route_id | 外键关联路线规划表actual_start_time | 实际起始时间戳 | - | DATETIME | -actual_end_time | 实际结束时间戳 | - | DATETIME | -distance_km | 行驶距离公里 | - | DECIMAL(8,2) | -表七TemperatureAlert温度预警表字段名(英文) | 说明(中文) | 大小 | 类型 | 主外键 | 备注alert_id | 预警编号 | 20 | VARCHAR(20) | PK | 主键唯一标识每条预警sensor_id | 传感器编号关联SensorData| 20 | VARCHAR(20) | FK→SensorData.sensor_id | 外键关联传感器数据表alert_type | 预警类型高温、低温、传感器故障 | 20 | VARCHAR(20) | -created_at | 预警生成时间戳 | - | DATETIME | -表八UserAccount用户账户表字段名(英文) | 说明(中文) | 大小 | 类型 | 主外键 | 备注user_id | 用户编号 | 20 | VARCHAR(20) | PK | 主键唯一标识每个用户username | 登录用户名 | 50 | VARCHAR(50) | -password_hash | 密码哈希值加盐| 64 | CHAR(64) | -role | 用户角色管理员、调度员、监管员| 20 | VARCHAR(20) | -表九KnowledgeNode知识图谱节点表字段名(英文) | 说明(中文) | 大小 | 类型 | 主外键 | 备注node_id | 节点编号 | 20 | VARCHAR(20) | PK | 主键唯一标识每个节点name | 节点名称如“低温存储”| 100 | VARCHAR(100) | -type | 节点类型实体、属性、关系| 20 | VARCHAR(20) | -description | 节点描述信息 | - | TEXT | -表十KnowledgeEdge知识图谱边表字段名(英文) | 说明(中文) | 大小 | 类型 | 主外键 | 备注edge_id | 边编号 | 20 | VARCHAR(20) | PK | 主键唯一标识每条边source_id | 源节点编号| 20 | VARCHAR(20) | FK→KnowledgeNode.node_id | 外键关联源节点target_id | 目标节点编号| 20 | VARCHAR(20) | FK→KnowledgeNode.node_id | 外键关联目标节点relation_type | 边关系类型如“适用于”| 50 | VARCHAR(50) | -以上十张表通过主外键实现了第一范式与第二范式的满足并在必要时通过外键约束保证数据完整性与一致性符合数据库范式设计原则。十、建表语句CREATE DATABASE IF NOT EXISTS ColdChainDB DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;USE ColdChainDB;-- 传感器数据表CREATE TABLE SensorData (sensor_id VARCHAR(20) NOT NULL,vehicle_id VARCHAR(20) NOT NULL,timestamp DATETIME NOT NULL,temperature DECIMAL(5,2) NOT NULL,humidity DECIMAL(5,2),PRIMARY KEY (sensor_id, timestamp),INDEX idx_vehicle_id (vehicle_id),CONSTRAINT fk_sensor_vehicle FOREIGN KEY (vehicle_id) REFERENCES Vehicle(vehicle_id) ON DELETE CASCADE ON UPDATE CASCADE) ENGINEInnoDB DEFAULT CHARSETutf8mb4;-- 车辆信息表CREATE TABLE Vehicle (vehicle_id VARCHAR(20) NOT NULL,license_plate VARCHAR(10),driver_name VARCHAR(50),capacity_km3 DECIMAL(6,2),PRIMARY KEY (vehicle_id)) ENGINEInnoDB DEFAULT CHARSETutf8mb4;-- 维护日志表CREATE TABLE MaintenanceLog (log_id VARCHAR(20) NOT NULL,vehicle_id VARCHAR(20) NOT NULL,maintenance_date DATETIME NOT NULL,description TEXT,PRIMARY KEY (log_id),INDEX idx_maint_vehicle (vehicle_id),CONSTRAINT fk_maint_vehicle FOREIGN KEY (vehicle_id) REFERENCES Vehicle(vehicle_id) ON DELETE CASCADE ON UPDATE CASCADE) ENGINEInnoDB DEFAULT CHARSETutf8mb4;-- 路线规划表CREATE TABLE RoutePlan (route_id VARCHAR(20) NOT NULL,vehicle_id VARCHAR(20) NOT NULL,start_location VARCHAR(100),end_location VARCHAR(100),planned_start_time DATETIME,planned_end_time DATETIME,status VARCHAR(20),PRIMARY KEY (route_id),INDEX idx_route_vehicle (vehicle_id),CONSTRAINT fk_route_vehicle FOREIGN KEY (vehicle_id) REFERENCES Vehicle(vehicle_id) ON DELETE CASCADE ON UPDATE CASCADE) ENGINEInnoDB DEFAULT CHARSETutf8mb4;-- 装载方案表CREATE TABLE LoadPlan (load_plan_id VARCHAR(20) NOT NULL,route_id VARCHAR(20) NOT NULL,product_type VARCHAR(50),quantity_kg DECIMAL(10,2),temp_requirement_min DECIMAL(5,2),temp_requirement_max DECIMAL(5,2),PRIMARY KEY (load_plan_id),INDEX idx_load_route (route_id),CONSTRAINT fk_load_route FOREIGN KEY (route_id) REFERENCES RoutePlan(route_id) ON DELETE CASCADE ON UPDATE CASCADE) ENGINEInnoDB DEFAULT CHARSETutf8mb4;-- 运输记录表CREATE TABLE TransportRecord (record_id VARCHAR(20) NOT NULL,route_id VARCHAR(20) NOT NULL,actual_start_time DATETIME,actual_end_time DATETIME,distance_km DECIMAL(8,2),PRIMARY KEY (record_id),INDEX idx_transport_route (route_id),CONSTRAINT fk_transport_route FOREIGN KEY (route_id) REFERENCES RoutePlan(route_id) ON DELETE CASCADE ON UPDATE CASCADE) ENGINEInnoDB DEFAULT CHARSETutf8mb4;-- 温度预警表CREATE TABLE TemperatureAlert (alert_id VARCHAR(20) NOT NULL,sensor_id VARCHAR(20) NOT NULL,alert_type VARCHAR(20),created_at DATETIME NOT NULL,PRIMARY KEY (alert_id),INDEX idx_alert_sensor (sensor_id),CONSTRAINT fk_alert_sensor FOREIGN KEY (sensor_id, timestamp) REFERENCES SensorData(sensor_id, timestamp) ON DELETE CASCADE ON UPDATE CASCADE) ENGINEInnoDB DEFAULT CHARSETutf8mb4;-- 用户账户表CREATE TABLE UserAccount (user_id VARCHAR(20) NOT NULL,username VARCHAR(50) NOT NULL,password_hash CHAR(64),role VARCHAR(20),PRIMARY KEY (user_id),UNIQUE KEY uq_username (username)) ENGINEInnoDB DEFAULT CHARSETutf8mb4;-- 知识图谱节点表CREATE TABLE KnowledgeNode (node_id VARCHAR(20) NOT NULL,name VARCHAR(100),type VARCHAR(20),description TEXT,PRIMARY KEY (node_id)) ENGINEInnoDB DEFAULT CHARSETutf8mb4;-- 知识图谱边表CREATE TABLE KnowledgeEdge (edge_id VARCHAR(20) NOT NULL,source_id VARCHAR(20) NOT NULL,target_id VARCHAR(20) NOT NULL,relation_type VARCHAR(50),PRIMARY KEY (edge_id),INDEX idx_edge_source (source_id),INDEX idx_edge_target (target_id),CONSTRAINT fk_edge_source FOREIGN KEY (source_id) REFERENCES KnowledgeNode(node_id) ON DELETE CASCADE ON UPDATE CASCADE,CONSTRAINT fk_edge_target FOREIGN KEY (target_id) REFERENCES KnowledgeNode(node_id) ON DELETE CASCADE ON UPDATE CASCADE) ENGINEInnoDB DEFAULT CHARSETutf8mb4;文章下方名片联系我即可~大家点赞、收藏、关注、评论啦 、查看下方获取联系方式