)
博主介绍：✌ 专注于VUE,小程序，安卓，Java,python,物联网专业，有18年开发经验，长年从事毕业指导，项目实战✌选取一个适合的毕业设计题目很重要。✌关注✌私信我✌具体的问题，我会尽力帮助你。
一、研究目的
本研究旨在构建一套基于SpringBoot框架的学生公寓管理系统，以解决高校宿舍管理中存在的人工登记繁琐、信息不统一、资源调配效率低下以及安全监管缺失等突出问题。通过采用微服务架构与RESTful接口设计，系统能够实现宿舍入住登记、学生信息维护、房间分配调度、维修报修处理以及费用结算等核心功能的模块化耦合，从而提高数据一致性与业务流程的自动化水平。系统后端采用SpringBoot作为基础框架，结合Spring Data JPA与MySQL数据库实现数据持久化，利用JWT技术保障接口安全，并通过Swagger文档生成工具提供清晰的接口说明，以便前端开发者快速集成。为满足多终端访问需求，系统还将提供基于Spring MVC的RESTful API，支持移动端与桌面端统一调用。研究的第二目标是对系统性能进行评估，包括并发请求处理能力、数据库查询效率以及接口响应时间等指标，以验证所采用技术方案在高并发环境下的可扩展性。第三目标聚焦于用户体验，通过引入Spring Security与细粒度权限控制，实现不同角色（管理员、宿管员、学生）对功能模块的访问限制，提升系统安全性与易用性。综上所述，本研究通过技术创新与系统实践，力求为高校宿舍管理提供一套高效、可靠且易维护的解决方案，从而提升校园管理智能化水平。
二、研究意义
本研究的意义主要体现在技术创新、管理效能提升、数据安全保障以及学术贡献四个层面。首先，在技术创新层面，基于SpringBoot的微服务架构与RESTful接口设计实现了传统宿舍管理系统的模块化重构，从而突破了单体应用在功能扩展与维护上的瓶颈；其次，在管理效能提升方面，系统通过统一的数据模型与自动化流程，将学生入住登记、房间分配、维修报修及费用结算等关键业务实现数字化、标准化，显著降低人工操作错误率并缩短响应周期；再次，在数据安全保障层面，采用JWT身份验证与细粒度权限控制机制，有效防止未经授权的访问与数据泄露，提升了系统整体安全性；最后，在学术贡献方面，本研究提供了完整的系统设计文档、实现代码以及性能评估结果，可为高校信息化建设提供可复制、可扩展的参考模型，并对SpringBoot在教育管理领域的应用展开了实证研究，为后续相关研究奠定了基础。除此之外，该系统通过引入容器化部署与持续集成/持续交付（CI/CD）流程，进一步提升了部署效率与运维可控性，为高校信息技术部门提供了现代化运维实践的范例。在社会层面，系统的推广应用有助于构建校园安全预警机制，及时发现并处理异常事件，从而保障学生生命财产安全。综上所述，基于SpringBoot的学生公寓管理系统不仅能够显著提升高校宿舍管理效率与安全水平，还为信息技术与教育管理深度融合提供了可行路径，具有重要的理论价值与实践意义。
三、国内外研究现状
国内在学生宿舍管理系统研究方面，主要聚焦于信息化与自动化的实现。早期研究多采用传统的关系型数据库与单体应用架构，功能以入住登记、房间分配、报修处理等为主；随着互联网技术的发展，越来越多高校开始引入Web端与移动端相结合的解决方案，并通过RESTful接口实现前后端分离。近年来，Java生态体系的成熟使得SpringBoot成为主流框架之一，国内多所高校在其基础上构建了可扩展的微服务架构，实现了宿舍信息、学生信息与财务结算等模块的解耦。与此同时，物联网技术的引入为宿舍管理提供了实时监测手段，温湿度传感器、门禁摄像头与能源管理系统被集成到统一平台中，从而实现了对宿舍环境与安全状态的实时可视化。研究成果方面，国内多所高校通过实验验证，系统在入住率提升、报修响应时间缩短以及能源消耗降低等方面均取得显著效果。
国外的研究起步较早，并在技术选型与应用场景上表现出更高的多样性。美国与欧洲部分高校采用基于Ruby on Rails、Django或ASP.NET Core的Web框架，构建了面向学生与管理人员的多租户宿舍管理平台。研究重点往往放在数据驱动决策与智能调度上，例如利用机器学习算法预测空置率、优化房间分配策略，并通过可视化仪表盘为管理者提供实时决策支持。云计算与容器化技术的应用使得系统具备了弹性伸缩能力，能够在高峰期保持稳定性能。国际研究还关注跨系统集成，例如将宿舍管理模块与校园一卡通、学习管理系统以及安全监控平台进行无缝衔接，从而实现“一站式”校园服务。相关成果显示，采用云原生架构的宿舍管理系统在运维成本与用户满意度方面均优于传统部署模式。
在研究方向层面，国内外学者普遍关注智能化与安全性的提升。智能化方面包括基于大数据的需求预测、自动化报修流程以及能源管理优化；安全性方面则强调身份认证、权限细粒度控制与数据加密技术的应用，以满足学生个人信息保护法规。近年来，区块链技术被提出用于宿舍租赁记录的不可篡改与透明化，虽然尚处于实验阶段，但已在部分高校进行试点。另一个重要方向是多模态交互系统的研发，例如通过语音助手、聊天机器人等方式简化学生与宿舍管理之间的沟通流程。
总之，国内外在学生宿舍管理系统研究中均已形成以信息化、自动化为核心的技术路线，并在此基础上进一步探索智能化、云原生与安全合规等前沿方向。通过对比分析可知，国内在SpringBoot微服务架构与物联网集成方面取得了显著进展，而国外则在数据驱动决策与跨系统集成方面表现突出。未来研究可在两者优势基础上，进一步融合人工智能与区块链技术，以实现更高效、更安全、更透明的学生宿舍管理生态。
四、预期达到目标及解决的关键问题
预期目标主要体现在系统功能完整性、技术可行性与应用价值三大维度。首先，系统应实现学生入住登记、房间分配、维修报修、费用结算与安全监控等核心业务流程的全流程自动化，并通过统一的数据模型保证信息的一致性与完整性；其次，技术层面要求采用SpringBoot微服务架构与RESTful接口设计，实现模块化解耦、易扩展与高可维护性；再次，系统需满足高并发访问下的性能指标，包括单次请求响应时间不超过200毫秒、90%并发请求吞吐量不低于每秒5000次，并通过负载均衡与数据库分库分表技术保障可伸缩性；此外，系统安全性是关键目标之一，需通过JWT身份认证、细粒度权限控制与数据加密技术实现对学生个人信息的多层防护，并满足相关法规要求；最后，系统应具备良好的用户体验与易用性，通过简洁直观的前端界面与移动端适配，提升管理员与学生的使用满意度。
在实现上述目标过程中，将面临若干关键技术问题。第一，数据一致性与事务管理是核心难点之一，尤其在分布式微服务环境下，需要设计跨服务的分布式事务解决方案，以防止因网络延迟或节点故障导致的数据不一致；第二，高并发场景下的性能瓶颈主要集中在数据库查询与缓存失效机制，需通过查询优化、索引设计以及Redis等缓存技术降低数据库压力；第三，系统安全性涉及身份认证、权限授权与数据加密三大层面，需要在保证易用性的前提下实现多因素认证与细粒度访问控制，并对敏感数据采用AES或RSA混合加密；第四，系统与现有校园信息平台（如一卡通、学习管理系统、安防监控等）的集成，需解决接口兼容性、数据同步时效性与安全传输等问题；第五，移动端与Web端的前后端分离架构要求RESTful接口设计规范化，并通过Swagger或OpenAPI文档保证接口可读性与可测试性；第六，系统的可维护性与持续交付需要引入CI/CD流水线、容器化部署与灰度发布机制，以降低运维成本并快速响应业务变更。
针对上述关键问题，研究计划将采用分阶段实现策略。首先在单机环境下完成核心业务模块的功能验证与性能基准测试；随后通过Docker容器化与Kubernetes编排，实现微服务的水平扩展与负载均衡；接着引入分布式事务框架（如Saga或TCC模式）解决跨服务一致性问题，并通过Redis缓存与消息队列（如RabbitMQ）提升系统响应速度；随后在安全层面集成OAuth2.0与JWT，配合Spring Security实现细粒度权限控制，并对数据库字段进行加密存储；最后通过接口网关与API网关实现与校园现有系统的无缝对接，并通过日志审计与监控平台（如Prometheus+Grafana）实现运维可视化。通过上述步骤，预期能够构建一套功能完备、性能可靠、安全可控且易于维护的学生公寓管理系统，为高校宿舍管理提供高质量的信息化解决方案。
五、研究内容
本研究围绕基于SpringBoot的学生公寓管理系统展开，整体研究内容可划分为需求分析与建模、系统架构设计与实现、关键技术研发与集成以及系统评估与优化四大阶段。首先，在需求分析与建模阶段，通过访谈高校宿管人员、学生代表及信息技术部门，梳理出系统需支持的核心业务流程，包括入住登记、房间分配、维修报修、费用结算与安全监控，并进一步细化为功能模块与业务规则。随后利用UML用例图与类图对业务流程进行可视化建模，并采用实体关系模型描述数据结构，确保数据层设计满足业务需求的同时兼顾扩展性。接下来，系统架构设计阶段以SpringBoot为基础框架，采用微服务架构将系统拆分为学生管理服务、房间管理服务、报修服务、财务结算服务与安全监控服务等核心子系统，并通过Spring Cloud Gateway统一入口实现API网关功能。每个子系统内部采用Spring Data JPA进行数据访问，数据库选用MySQL并通过分库分表技术提升并发处理能力；同时引入Redis缓存提升热点数据读取速度，并使用RabbitMQ实现异步任务调度，如报修工单的状态变更与通知推送。为保障系统安全，采用JWT进行无状态身份认证，并结合Spring Security实现细粒度权限控制，敏感字段采用AES对称加密存储，传输层使用HTTPS协议。系统前端则采用Vue.js框架与Element Plus组件库实现响应式Web界面，并通过移动端适配提供学生与管理员的移动访问。为了提升房间分配效率，本研究设计了一套基于遗传算法的最优分配模型，输入参数包括学生偏好、房间容量、空置率等，输出为最优入住方案；该模型在后端服务中以Java实现，并通过RESTful接口暴露给前端。安全监控模块则通过接入校园物联网平台，将门禁摄像头与温湿度传感器数据实时上传至系统，并利用WebSocket技术实现实时告警推送。系统集成阶段重点解决与高校现有一卡通、学习管理系统以及校园安防平台的接口兼容问题，采用OpenAPI规范定义统一接口，并通过OAuth2.0授权机制实现跨系统单点登录。为保证系统可维护性与持续交付，本研究构建了Docker Compose环境并规划Kubernetes集群部署方案，配合CI/CD流水线实现自动化构建、测试与灰度发布。最后，在系统评估与优化阶段，采用JMeter对并发请求进行压力测试，目标是单次响应时间低于200毫秒、90%吞吐量不低于每秒5000次；通过OWASP ZAP进行安全漏洞扫描，确保系统满足信息安全合规要求；通过Prometheus与Grafana搭建监控平台，对CPU、内存、数据库连接池等关键指标进行实时可视化。综合上述研究内容，本工作将实现一套功能完备、性能可靠、安全可控且易于维护的学生公寓管理系统，为高校宿舍管理提供先进的信息化解决方案。
六、需求分析
用户需求方面，系统首先需要满足学生的日常使用便利性与信息透明度。学生在入住新学期时，希望能够通过统一的在线入口完成身份验证、填写个人信息、选择房间偏好并提交入住申请；在住宿期间，学生需要随时查询自己的房间状态、报修进度以及费用明细，并能够通过移动端及时接收维修工单的处理结果与费用结算通知。其次，宿管人员与管理层对系统的需求侧重于业务流程的高效化与数据的一致性。宿管员需要能够快速查看所有学生的入住情况、房间空置率以及报修记录，并通过系统自动生成房间分配建议和维修调度表；管理层则关注整体运营指标，如入住率、维修响应时间、费用回收率等，需要系统提供可视化的统计报表与趋势分析。最后，信息技术维护人员对系统的需求强调可扩展性、易维护性与安全合规。系统应支持模块化部署、灰度发布以及日志审计，并满足个人信息保护法规的要求，确保数据在传输与存储过程中的完整性与保密性。
功能需求方面，系统需实现学生信息管理模块，包括身份认证、基本资料维护、学籍状态查询及权限分配等功能；房间管理模块应支持房间属性定义、空置状态监控、容量规划以及基于学生偏好与房间条件的自动分配算法，并提供手动调度与冲突解决接口。报修管理模块需涵盖报修单创建、分类标签、维修工单派发、进度跟踪及工单结案等流程，并支持多渠道（Web、移动端）提交与实时通知。费用结算模块应集成宿舍租金、公共设施使用费以及维修费用的计费与收款功能，支持在线支付接口、账单生成与电子发票开具，并能自动更新学生账户余额。安全监控模块需实现门禁刷卡记录查询、摄像头实时视频流接入、温湿度传感器数据采集以及异常告警推送等功能，并提供可视化的安全事件日志。除此之外，系统还应提供权限管理与审计模块，支持角色定义、细粒度权限配置以及操作日志追溯；以及接口网关与第三方系统对接模块，确保与校园一卡通、学习管理系统及安防平台的数据同步与单点登录。通过上述功能实现，系统将能够满足学生、宿管员、管理层及技术维护人员在使用体验、业务效率、安全合规等多维度的需求。
七、可行性分析
经济可行性方面，系统的总体投入主要包括软件开发、硬件设备、网络设施以及后期运维费用。初始开发阶段预计需要三至四名全职软件工程师与一名项目经理为期六个月，人工成本约为人民币30万元；此外，还需采购服务器、存储设备及网络交换机等硬件，预算约为10万元；软件授权与第三方服务（如支付接口、短信推送）每年费用约为5万元。综合上述，系统的首年投入大约为45万元。相对而言，系统能够显著提升宿舍管理效率，减少人工登记与报修处理时间，每位学生每学期因入住登记与报修所需的人工工时可降低30%，按高校宿管人员平均工资计算，每学期可节省约1.5万元；再加上房间分配优化带来的空置率下降导致租金收入提升约0.5万元，系统在第三学期即可实现收支平衡。若将系统推广至多所高校，规模效应将进一步放大，整体投资回报率可达20%以上。综上所述，从经济角度看，该项目具备可观的成本收益比，并且能够在短期内实现盈亏平衡。
社会可行性方面，系统的推广将直接影响学生、宿管人员以及高校管理层的日常工作与生活质量。学生方面，系统提供一站式在线入住、报修与费用查询功能，极大降低了繁琐的纸质流程，提高了满意度；宿管人员则通过自动化分配与报修调度减少了人工操作错误，提升了工作效率；高校管理层可通过系统生成的统计报表及时掌握宿舍运营状况，支持决策制定。与此同时，系统在数据安全与隐私保护方面采用JWT身份认证、细粒度权限控制与AES加密存储等技术，符合《个人信息保护法》及高校信息安全管理规范，能够获得用户的信任。社会层面还需考虑系统上线后对现有工作流程的冲击，通过培训与渐进式部署降低抵触情绪。总体而言，该系统满足校园社区对信息化、便利化与安全性的共同诉求，具备较高的社会接受度与推广价值。
技术可行性方面，选用SpringBoot框架结合Spring Cloud微服务架构能够实现模块化、易扩展的系统设计。Spring Data JPA与MySQL提供了成熟的ORM与关系型数据库支持，已被多所高校信息系统广泛采用；Redis缓存与RabbitMQ消息队列可有效提升并发处理能力和异步任务调度；JWT与Spring Security保障了身份认证与权限控制的安全性。系统前端采用Vue.js与Element Plus实现响应式界面，移动端适配可通过PWA技术实现离线缓存与推送功能。为了满足高并发访问需求，可通过Docker容器化部署至Kubernetes集群，并利用Nginx或Spring Cloud Gateway进行负载均衡；数据库可采用分库分表与读写分离策略，进一步提升性能。系统与校园现有一卡通、学习管理系统及安防平台的对接可通过RESTful接口与OAuth2.0授权实现，已在多所高校的实践中得到验证。综上所述，从技术角度看，该项目采用成熟、可验证的技术栈，具备良好的可实现性与扩展性。
八、功能分析
系统功能模块可划分为七大核心子系统，分别为学生信息管理子系统、房间与宿舍资源管理子系统、入住与分配管理子系统、报修与维护管理子系统、费用结算与支付管理子系统、安全监控与预警管理子系统以及权限与审计管理子系统。每个子系统内部进一步细化为若干功能模块，并通过统一的RESTful接口实现相互协作。
学生信息管理子系统负责学生身份认证、个人资料维护、学籍状态查询及权限分配等功能。该子系统提供登录注册接口，支持多因素身份验证；提供学生基本信息增删改查接口，包括姓名、学号、专业、联系方式等字段；支持批量导入与导出功能，以便与高校教务系统同步；同时提供学生角色与权限配置接口，允许宿管员为不同角色分配访问权限。房间与宿舍资源管理子系统负责宿舍楼栋、房间属性定义、容量规划以及空置状态监控。该子系统提供楼栋与房间创建、修改、删除接口；支持房间属性设置，如床位数、设施设备列表、温湿度传感器编号等；实现房间空置率统计与实时监控，并通过缓存技术提升查询效率。入住与分配管理子系统实现学生入住登记、退宿办理以及房间分配算法。该子系统提供入住申请接口，支持学生填写入住意向与偏好；在后台采用遗传算法或启发式搜索对空闲房间进行匹配，并生成分配建议；支持手动调度与冲突解决；同时实现退宿流程，包括退宿申请、房间状态更新与押金结算。报修与维护管理子系统负责报修单创建、分类标签、维修工单派发、进度跟踪及工单结案。该子系统提供报修接口，支持上传图片与描述；通过消息队列将报修信息推送给维修人员；实现工单状态变更与通知推送；并支持维修记录查询与统计。费用结算与支付管理子系统负责宿舍租金、公共设施使用费以及维修费用的计费、账单生成与在线支付。该子系统集成支付网关，支持支付宝、微信等方式；提供账单查询、历史支付记录与电子发票开具接口；并支持自动扣款与余额管理。安全监控与预警管理子系统负责门禁刷卡记录查询、摄像头实时视频流接入、温湿度传感器数据采集以及异常告警推送。该子系统通过物联网协议与校园安防平台对接，实时收集门禁事件与环境数据；通过阈值检测触发告警，并通过WebSocket或推送服务将告警信息实时发送给宿管员与学生。权限与审计管理子系统负责角色定义、细粒度权限配置、操作日志追溯与审计。该子系统提供角色创建与编辑接口；支持基于资源路径的权限分配；并记录所有关键操作的时间、操作者与变更内容，满足合规性审计需求。
上述七大核心子系统通过统一的API网关进行入口管理，采用JWT进行无状态身份认证，并通过Spring Security实现细粒度访问控制。前端采用Vue.js框架构建响应式Web界面，并通过移动端适配实现学生与宿管员的多终端访问。后端服务部署于Docker容器化环境，并通过Kubernetes集群实现弹性伸缩；数据库采用MySQL分库分表方案，Redis缓存热点数据，RabbitMQ处理异步任务；日志与监控通过ELK堆栈与Prometheus+Grafana实现。系统整体架构逻辑清晰、功能完整，并具备高度可扩展性与安全性。
九、数据库设计
表名：UserAccount
字段名(英文) | 说明(中文) | 大小 | 类型 | 主外键 | 备注
user_id | 用户编号（主键）| 20 | VARCHAR| PK|
username | 登录用户名| 30 | VARCHAR||
password_hash | 密码哈希值| 64 | VARCHAR||
role_id | 角色编号（外键）| 20 | VARCHAR| FK→Role.role_id|
created_at | 创建时间| N/A | DATETIME||
updated_at | 更新时间| N/A | DATETIME||
表名：Role
字段名(英文) | 说明(中文) | 大小 | 类型 | 主外键 | 备注
role_id | 角色编号（主键）| 20 | VARCHAR| PK|
role_name | 角色名称| 30 | VARCHAR||
表名：Student
字段名(英文) | 说明(中文) | 大小 | 类型 | 主外键 | 备注
student_id | 学号（主键）| 20 | VARCHAR| PK|
user_id | 用户编号（外键）| 20 | VARCHAR| FK→UserAccount.user_id|
name | 姓名| 50 | VARCHAR||
gender | 性别| 1 | CHAR||
birth_date | 出生日期| N/A | DATE||
major | 专业| 50 | VARCHAR||
phone | 联系电话| 15 | VARCHAR||
表名：DormitoryBuilding
字段名(英文) | 说明(中文) | 大小 | 类型 | 主外键 | 备注
building_id | 楼栋编号（主键）| 20 | VARCHAR| PK|
name | 楼栋名称| 50 | VARCHAR||
address | 地址| 100 | VARCHAR||
表名：Room
字段名(英文) | 说明(中文) | 大小 | 类型 | 主外键 | 备注
room_id | 房间编号（主键）| 20 | VARCHAR| PK|
building_id | 楼栋编号（外键）| 20 | VARCHAR| FK→DormitoryBuilding.building_id|
room_number | 房间号| 10 | VARCHAR||
capacity | 容纳人数| N/A | INT||
current_occupancy | 当前入住人数| N/A | INT||
表名：RoomAssignment
字段名(英文) | 说明(中文) | 大小 | 类型 | 主外键 | 备注
assignment_id | 分配编号（主键）| 20 | VARCHAR| PK|
student_id | 学号（外键）| 20 | VARCHAR| FK→Student.student_id|
room_id | 房间编号（外键）| 20 | VARCHAR| FK→Room.room_id|
check_in_date | 入住日期| N/A | DATE||
check_out_date | 退宿日期（可空）| N/A | DATE||
表名：MaintenanceRequest
字段名(英文) | 说明(中文) | 大小 | 类型 | 主外键 | 备注
request_id | 报修编号（主键）| 20 | VARCHAR| PK|
student_id | 学号（外键）| 20 | VARCHAR| FK→Student.student_id|
room_id | 房间编号（外键）| 20 | VARCHAR| FK→Room.room_id|
category | 报修类别（如电器、管道、家具）| 30 | VARCHAR||
description | 报修描述| 200 | VARCHAR||
status | 当前状态（待处理、处理中、已完成）| 20 | VARCHAR||
created_at | 提交时间| N/A | DATETIME||
updated_at | 更新时间| N/A | DATETIME||
表名：PaymentTransaction
字段名(英文) | 说明(中文) | 大小 | 类型 | 主外键 | 备注
transaction_id | 交易编号（主键）| 20 | VARCHAR| PK|
student_id | 学号（外键）| 20 | VARCHAR| FK→Student.student_id|
amount | 金额（元）| N/A | DECIMAL(10,2)||
payment_method | 支付方式（现金、支付宝、微信）| 20 | VARCHAR||
status | 交易状态（已支付、待支付、已退款）| 20 | VARCHAR||
transaction_date | 交易日期| N/A | DATETIME||
表名：DoorAccessLog
字段名(英文) | 说明(中文) | 大小 | 类型 | 主外键 | 备注
log_id | 日志编号（主键）| 20 | VARCHAR| PK|
student_id | 学号（外键）| 20 | VARCHAR| FK→Student.student_id|
room_id | 房间编号（外键）| 20 | VARCHAR| FK→Room.room_id|
access_time | 访问时间| N/A | DATETIME||
access_type | 访问类型（进门、出门）| 10 | VARCHAR||
表名：SensorData
字段名(英文) | 说明(中文) | 大小 | 类型 | 主外键 | 备注
data_id | 数据编号（主键）| 20 | VARCHAR| PK|
room_id | 房间编号（外键）| 20 | VARCHAR| FK→Room.room_id|
temperature | 温度（摄氏度）| N/A | DECIMAL(5,2)||
humidity | 湿度（%）| N/A | DECIMAL(5,2)||
recorded_at | 记录时间| N/A | DATETIME||
十、建表语句
CREATE DATABASE IF NOT EXISTS dormitory_system CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
USE dormitory_system;
-- 角色表
CREATE TABLE IF NOT EXISTS Role (
role_id VARCHAR(20) NOT NULL,
role_name VARCHAR(30) NOT NULL,
PRIMARY KEY (role_id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
-- 用户账号表
CREATE TABLE IF NOT EXISTS UserAccount (
user_id VARCHAR(20) NOT NULL,
username VARCHAR(30) NOT NULL UNIQUE,
password_hash VARCHAR(64) NOT NULL,
role_id VARCHAR(20) NOT NULL,
created_at DATETIME DEFAULT CURRENT_TIMESTAMP,
updated_at DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
PRIMARY KEY (user_id),
CONSTRAINT fk_user_role FOREIGN KEY (role_id)
REFERENCES Role(role_id) ON DELETE RESTRICT ON UPDATE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
-- 学生信息表
CREATE TABLE IF NOT EXISTS Student (
student_id VARCHAR(20) NOT NULL,
user_id VARCHAR(20) NOT NULL,
name VARCHAR(50) NOT NULL,
gender CHAR(1),
birth_date DATE,
major VARCHAR(50),
phone VARCHAR(15),
PRIMARY KEY (student_id),
CONSTRAINT fk_student_user FOREIGN KEY (user_id)
REFERENCES UserAccount(user_id) ON DELETE RESTRICT ON UPDATE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
-- 楼栋表
CREATE TABLE IF NOT EXISTS DormitoryBuilding (
building_id VARCHAR(20) NOT NULL,
name VARCHAR(50) NOT NULL,
address VARCHAR(100),
PRIMARY KEY (building_id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
-- 房间表
CREATE TABLE IF NOT EXISTS Room (
room_id VARCHAR(20) NOT NULL,
building_id VARCHAR(20) NOT NULL,
room_number VARCHAR(10) NOT NULL,
capacity INT UNSIGNED NOT NULL,
current_occupancy INT UNSIGNED DEFAULT 0,
PRIMARY KEY (room_id),
CONSTRAINT fk_room_building FOREIGN KEY (building_id)
REFERENCES DormitoryBuilding(building_id) ON DELETE RESTRICT ON UPDATE CASCADE,
UNIQUE KEY uq_room_building_number (building_id, room_number)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
-- 房间分配表
CREATE TABLE IF NOT EXISTS RoomAssignment (
assignment_id VARCHAR(20) NOT NULL,
student_id VARCHAR(20) NOT NULL,
room_id VARCHAR(20) NOT NULL,
check_in_date DATE NOT NULL,
check_out_date DATE,
PRIMARY KEY (assignment_id),
CONSTRAINT fk_assignment_student FOREIGN KEY (student_id)
REFERENCES Student(student_id) ON DELETE RESTRICT ON UPDATE CASCADE,
CONSTRAINT fk_assignment_room FOREIGN KEY (room_id)
REFERENCES Room(room_id) ON DELETE RESTRICT ON UPDATE CASCADE,
UNIQUE KEY uq_student_room (student_id, room_id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
-- 报修单表
CREATE TABLE IF NOT EXISTS MaintenanceRequest (
request_id VARCHAR(20) NOT NULL,
student_id VARCHAR(20) NOT NULL,
room_id VARCHAR(20) NOT NULL,
category VARCHAR(30),
description VARCHAR(200),
status VARCHAR(20) DEFAULT '待处理',
created_at DATETIME DEFAULT CURRENT_TIMESTAMP,
updated_at DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
PRIMARY KEY (request_id),
CONSTRAINT fk_request_student FOREIGN KEY (student_id)
REFERENCES Student(student_id) ON DELETE RESTRICT ON UPDATE CASCADE,
CONSTRAINT fk_request_room FOREIGN KEY (room_id)
REFERENCES Room(room_id) ON DELETE RESTRICT ON UPDATE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
-- 费用交易表
CREATE TABLE IF NOT EXISTS PaymentTransaction (
transaction_id VARCHAR(20) NOT NULL,
student_id VARCHAR(20) NOT NULL,
amount DECIMAL(10,2) NOT NULL,
payment_method VARCHAR(20),
status VARCHAR(20) DEFAULT '待支付',
transaction_date DATETIME DEFAULT CURRENT_TIMESTAMP,
PRIMARY KEY (transaction_id),
CONSTRAINT fk_payment_student FOREIGN KEY (student_id)
REFERENCES Student(student_id) ON DELETE RESTRICT ON UPDATE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
-- 门禁日志表
CREATE TABLE IF NOT EXISTS DoorAccessLog (
log_id VARCHAR(20) NOT NULL,
student_id VARCHAR(20) NOT NULL,
room_id VARCHAR(20) NOT NULL,
access_time DATETIME DEFAULT CURRENT_TIMESTAMP,
access_type VARCHAR(10),
PRIMARY KEY (log_id),
CONSTRAINT fk_log_student FOREIGN KEY (student_id)
REFERENCES Student(student_id) ON DELETE RESTRICT ON UPDATE CASCADE,
CONSTRAINT fk_log_room FOREIGN KEY (room_id)
REFERENCES Room(room_id) ON DELETE RESTRICT ON UPDATE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
-- 传感器数据表
CREATE TABLE IF NOT EXISTS SensorData (
data_id VARCHAR(20) NOT NULL,
room_id VARCHAR(20) NOT NULL,
temperature DECIMAL(5,2),
humidity DECIMAL(5,2),
recorded_at DATETIME DEFAULT CURRENT_TIMESTAMP,
PRIMARY KEY (data_id),
CONSTRAINT fk_sensor_room FOREIGN KEY (room_id)
REFERENCES Room(room_id) ON DELETE RESTRICT ON UPDATE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
-- 索引（根据业务需要添加）
CREATE INDEX idx_room_building ON Room(building_id);
CREATE INDEX idx_assignment_student ON RoomAssignment(student_id);
CREATE INDEX idx_assignment_room ON RoomAssignment(room_id);
CREATE INDEX idx_request_student ON MaintenanceRequest(student_id);
CREATE INDEX idx_request_room ON MaintenanceRequest(room_id);
CREATE INDEX idx_payment_student ON PaymentTransaction(student_id);
CREATE INDEX idx_log_student ON DoorAccessLog(student_id);
CREATE INDEX idx_log_room ON DoorAccessLog(room_id);
CREATE INDEX idx_sensor_room ON SensorData(room_id);
文章下方名片联系我即可~大家点赞、收藏、关注、评论啦 、查看下方👇🏻获取联系方式👇🏻
