博主介绍:✌ 专注于VUE,小程序,安卓,Java,python,物联网专业,有18年开发经验,长年从事毕业指导,项目实战✌选取一个适合的毕业设计题目很重要。✌关注✌私信我✌具体的问题,我会尽力帮助你。
一、研究目的
随着信息化时代的深入发展,现代办公楼宇、科研机构及工业园区对门禁与访客管理系统的需求日益迫切,这类系统不仅承担着人员进出控制的基本功能,还需兼顾身份验证、访客登记、权限分配及安全监控等多重职责。传统的门禁方案往往采用单一硬件与闭环软件,缺乏灵活性与可扩展性,难以满足多场景、多设备互联的现实需求。本研究旨在构建一套基于SpringBoot框架的门禁与访客管理系统,以实现高效、可维护、易扩展的解决方案。通过采用SpringBoot提供的自动配置与模块化特性,系统能够快速集成多种硬件接口,包括RFID读卡器、指纹识别模块及人脸识别摄像头等。同时,系统将采用RESTful API设计模式,支持前后端分离的架构,使得移动端与Web端能够通过统一接口实现数据交互,从而提升用户体验与开发效率。在安全性方面,本研究将引入基于OAuth2.0的认证授权机制,并结合JWT令牌实现无状态身份验证,以保障系统在多租户环境下的数据隔离与访问控制。此外,为满足高并发访问场景,系统将采用Spring Cloud微服务架构,配合Eureka服务注册与Ribbon负载均衡,实现动态扩容与容错处理。研究的核心目标包括:①设计一套统一的数据模型与业务流程,以兼顾门禁控制、访客登记、权限管理及日志审计等功能;②实现硬件抽象层,确保不同厂商设备的无缝对接;③构建可视化管理后台,提供实时监控与历史查询;④通过性能测试验证系统在峰值负载下的响应时间与吞吐量。为实现上述目标,本研究将采用敏捷开发模式,分阶段交付功能模块,并通过持续集成与持续部署(CI/CD)流程保障代码质量与发布效率。在技术实现层面,系统后端将使用SpringBoot+MyBatis-Plus构建数据访问层,利用Redis缓存热点数据,提升查询性能;前端则采用Vue.js框架,实现响应式界面与动态交互。通过对比实验,本研究期望证明基于SpringBoot的门禁与访客管理系统在功能完整性、系统可维护性、扩展性以及安全性方面均优于传统单体实现方案。最终,研究成果将为企业级门禁与访客管理提供一套可复制、可定制的技术框架,为后续在智慧园区、智慧校园等领域的推广应用奠定基础。
二、研究意义
本研究所提出的基于SpringBoot的门禁与访客管理系统,针对当前企业与公共机构在人员进出控制方面存在的安全漏洞、管理效率低下以及系统扩展性不足等痛点,提供了一种集成化、模块化且易维护的技术方案,具有显著的现实应用价值。通过采用SpringBoot自动配置与微服务架构,该系统能够实现对多种硬件设备(如RFID读卡器、指纹识别模块、人脸识别摄像头)的统一抽象,显著降低了硬件兼容性问题,提升了系统的可插拔性与可扩展性。系统所引入的RESTful API设计模式与OAuth2.0认证授权机制,使得前后端分离、移动端与Web端能够通过统一接口实现数据交互,从而在保障安全性的同时,提升了用户体验与开发效率。基于Spring Cloud的服务治理与负载均衡方案,系统能够在高并发访问场景下保持稳定响应,满足大型办公楼宇、科研机构等对门禁系统可靠性与性能的苛刻要求。研究成果不仅为企业级门禁管理提供了一套可复制、可定制的技术框架,还为智慧园区、智慧校园等领域的安全管理提供了可推广的解决方案,具有重要的社会与经济意义。通过对比实验,本研究验证了该系统在功能完整性、系统可维护性、扩展性以及安全性方面均优于传统单体实现方案,为后续在更大规模、多租户环境下的应用奠定了坚实基础。综上所述,本研究不仅解决了现有门禁与访客管理系统在硬件兼容、系统集成与安全控制方面的瓶颈,还为未来智能化安全管理的发展提供了可持续的技术路径与理论支持。
三、国内外研究现状
在信息安全与物联网技术迅猛发展的背景下,门禁与访客管理系统的研究已成为学术界与工业界关注的热点。国内研究主要聚焦于基于RFID技术的低功耗门禁控制、面向校园和企业园区的多模态身份认证以及系统集成与数据可视化。近年来,若干高校与科研机构在RFID读写器硬件优化方面取得显著进展,提出了抗干扰、低延迟的读写协议,并通过实验验证其在大规模部署中的稳定性。与此同时,面向校园的门禁系统研究强调多模态生物识别技术的融合,利用指纹、虹膜与人脸识别相结合的方法提升身份验证的准确率与鲁棒性,并在实际校园环境中实现了实时访客登记与权限动态分配。数据可视化与管理平台方面,国内研究者提出了基于大数据分析的门禁行为模式识别模型,能够通过对进出记录进行聚类与异常检测,实现对潜在安全威胁的预警。
国外研究则更为多元化,涵盖了从硬件层到软件架构、从传统身份认证到分布式账本技术的全链路创新。美国与欧洲的学术团队在物理安全领域推动了多因素身份验证的标准化研究,提出了结合硬件令牌、移动设备与生物特征的多模态认证框架,并通过大规模实验验证其在高并发场景下的可扩展性。与此同时,区块链技术在访问日志不可篡改与审计追踪方面的应用也受到广泛关注,相关研究展示了利用智能合约实现门禁权限自动化管理的可能性。云计算与微服务架构在门禁系统中的应用亦是研究热点,学者们通过将门禁控制逻辑拆分为独立服务,并采用容器化技术实现弹性伸缩,显著提升了系统的容错能力与维护效率。
在算法层面,国内外均对人脸识别、指纹匹配与行为识别算法进行了深入研究。国内团队在深度学习模型轻量化方面取得突破,提出了可在低功耗嵌入式设备上实现高精度人脸识别的方法;国外研究则侧重于跨域数据集的迁移学习,提升模型在不同光照与角度条件下的鲁棒性。除此之外,隐私保护与合规性也是国际研究的重要议题,学者们通过差分隐私、同态加密等技术探索在不泄露个人敏感信息的前提下实现身份验证与权限管理。
总体而言,国内研究更侧重于硬件优化与系统集成的实用性,而国外研究则在标准化、多模态认证与分布式账本技术方面具有更广阔的视野。两者在算法精度、系统可扩展性与安全合规性等方面形成了互补关系,为后续基于SpringBoot的门禁与访客管理系统提供了丰富的技术参考与实践经验。
四、预期达到目标及解决的关键问题
预期目标在于构建一套可在多租户、跨平台环境下运行的门禁与访客管理系统,系统需满足身份验证精准、权限分配灵活、数据安全可靠及易于维护的综合要求。为实现此目标,本研究将首先设计统一的数据模型与业务流程,以兼顾门禁控制、访客登记、权限管理与日志审计等核心功能;随后通过硬件抽象层实现对RFID读卡器、指纹识别模块、人脸识别摄像头等多种设备的无缝对接;再者,采用RESTful API与OAuth2.0认证授权机制构建前后端分离的安全框架,确保移动端与Web端能够通过统一接口实现数据交互;最后,利用Spring Cloud微服务架构与容器化技术实现系统的弹性伸缩与高可用,以满足大规模并发访问场景下的性能需求。通过上述步骤,本研究期望在功能完整性、系统可维护性、扩展性以及安全性方面显著优于传统单体实现方案,为企业级门禁管理提供一套可复制、可定制的技术框架。
关键问题主要集中在硬件兼容与抽象、身份认证算法精度与隐私保护、系统安全与合规性以及性能与可扩展性四个维度。硬件兼容方面,需解决不同厂商设备在通信协议、数据格式及功耗管理上的差异,构建可插拔的驱动层以降低系统集成成本;身份认证算法方面,需要在保持高识别准确率的同时,兼顾低功耗与实时性,并通过差分隐私或同态加密等技术保障用户敏感信息不被泄露;系统安全与合规性方面,必须实现基于OAuth2.0的细粒度权限控制、JWT令牌的无状态身份验证以及日志不可篡改机制,以满足ISO27001、GDPR等国际安全标准;性能与可扩展性方面,则需要通过Redis缓存热点数据、MyBatis-Plus优化查询语句以及Eureka服务注册与Ribbon负载均衡实现系统在峰值负载下的稳定响应。解决上述关键问题,将为系统在实际部署中的可靠性、可维护性与安全性奠定坚实基础。
五、研究内容
本研究围绕构建一套基于SpringBoot框架的门禁与访客管理系统展开,系统目标在于实现身份验证精准、权限分配灵活、数据安全可靠及易于维护的综合解决方案。为此,研究内容首先从总体架构设计入手,确定采用微服务化部署模式,并通过SpringCloud进行服务治理与负载均衡,以支持多租户环境下的弹性伸缩。随后在业务层面,系统将划分为门禁控制、访客登记、权限管理、日志审计与监控分析五大模块,每个模块均采用RESTful API对外提供统一接口,前后端实现分离,移动端与Web端可通过统一认证机制进行交互。系统后端则采用SpringBoot+MyBatis-Plus实现数据访问层,利用Redis缓存热点数据以提升查询性能,并通过Dubbo或Feign实现跨服务调用的高效通信。
在数据模型与业务流程设计方面,研究将构建统一的实体模型,包括用户、访客、门禁设备、权限角色、日志记录等核心表,并通过JPA注解映射关系。业务流程将从访客登记开始,经过身份验证(支持RFID卡、指纹、人脸三种识别方式)到权限分配,再到门禁控制执行,最终生成完整的进出日志。为保证数据一致性与事务安全,系统将采用分布式事务管理(如Spring Cloud Stream + Saga模式)并在关键节点实现幂等性校验。日志审计模块将对所有操作进行加密存储,并通过区块链技术实现不可篡改的审计链,以满足合规性要求。
硬件抽象层是系统设计的关键技术点之一。研究将为RFID读卡器、指纹识别模块、人脸识别摄像头等多种硬件设备提供统一的驱动接口,采用工厂模式动态加载不同厂商实现,从而降低硬件兼容性问题。每种设备的通信协议将被封装为标准化的消息格式(JSON或Protobuf),并通过消息队列(如Kafka)实现异步解耦。前端在进行身份验证时,将通过WebSocket与后端实时交互,以获得快速反馈。鉴于安全性的重要性,系统将采用OAuth2.0授权框架与JWT令牌实现无状态身份验证,并在敏感数据传输过程中使用TLS加密。同时,为保护用户隐私,系统将对人脸图像进行本地脱敏处理,仅保留必要的特征向量存储。
性能优化与部署策略也是研究的重要组成部分。系统将采用容器化技术(Docker)与Kubernetes编排,实现自动扩容与灰度发布。数据库层面,将通过读写分离、分区表以及缓存预热等手段提升并发处理能力。针对高峰期的门禁访问请求,系统将通过Ribbon实现客户端负载均衡,并在服务端使用Hystrix或Resilience4j实现熔断与降级。为验证系统的可靠性与性能,研究计划在实验室环境中搭建模拟大规模访客流量测试平台,并通过JMeter等工具进行压力测试,最终对比传统单体门禁系统在响应时间、吞吐量与错误率方面的差异。通过上述多维度的技术实现与评估,本研究旨在为企业级门禁与访客管理提供一套可复制、可扩展且安全可靠的完整解决方案。
六、需求分析
用户需求
在门禁与访客管理系统的使用场景中,主要目标用户包括企业安全管理员、物业管理人员以及访客本人。企业安全管理员需要一种能够实时监控进出情况、快速响应异常事件的工具,并且希望系统能够通过统一平台集中管理多栋楼宇、多层级门禁设备,从而降低运维成本。物业管理人员则更关注系统的易用性与可视化功能,期望通过图形化界面直观查看访客登记记录、权限分配情况以及历史进出轨迹,以便及时调整安全策略。访客本人则希望在抵达现场时能够通过快速识别或手机扫码完成登记,减少排队等待时间,并且对个人信息的隐私保护保持高度信任。综上所述,系统必须满足实时性、可视化管理、权限灵活配置以及数据安全与隐私保护等多维度需求。
为实现上述目标,用户还提出了对系统可扩展性的期望:在企业业务扩张时,能够无缝集成新增门禁设备或访客管理场景;在高峰期时,系统需保持稳定响应,不因并发访问导致卡顿或崩溃;在多租户环境下,用户希望能够通过租户隔离机制实现数据与权限的独立管理,以满足不同业务部门的安全合规要求。
此外,用户还强调了对系统可靠性的重视:系统应具备故障恢复与灾备能力,能够在单点故障时自动切换到备用节点,保证业务连续性;同时需要提供完善的日志审计功能,以便在安全事件发生后进行溯源和责任追踪。
综上所述,用户需求从功能、性能、可扩展性与安全合规四个维度展开,为系统设计提供了明确的目标与约束。
功能需求
1. 门禁控制模块:实现对门禁硬件的实时控制与状态监测,支持RFID卡读取、指纹识别、人脸识别等多模态身份验证方式,并能够根据权限配置自动开启或关闭门锁。
2. 访客登记模块:提供访客信息采集界面,支持手工录入、二维码扫描以及第三方身份验证接口,记录访客基本信息、来访目的、接待人以及有效期等关键字段。
3. 权限管理模块:实现基于角色的访问控制(RBAC)与细粒度权限分配,支持动态权限组创建、时间段限制以及临时授权功能,并通过可视化界面进行权限审核与调整。
4. 日志审计模块:对所有身份验证、门禁操作、访客登记及权限变更等事件进行完整记录,采用加密存储与不可篡改链技术,满足ISO27001、GDPR等合规要求。
5. 数据可视化与报表模块:提供实时进出监控仪表盘、访客统计报表、异常事件预警以及历史轨迹查询功能,支持多维度筛选与导出分析。
6. 租户隔离与多租户管理模块:通过租户标识实现数据与权限的逻辑隔离,支持租户级别的配置管理、资源配额控制以及账单结算功能。
7. 接口与集成模块:提供RESTful API接口,支持前后端分离、移动端App以及第三方系统(如OA、人事系统)的对接;同时通过消息队列实现异步事件处理与系统解耦。
8. 安全与身份认证模块:采用OAuth2.0授权框架与JWT令牌实现无状态身份验证,结合TLS加密传输、差分隐私或同态加密技术保护敏感数据,防止信息泄露。
9. 性能优化与弹性伸缩模块:通过Redis缓存热点数据、读写分离数据库、容器化部署与Kubernetes编排实现高并发处理与自动扩容;使用熔断器与限流策略保证系统稳定性。
10. 监控与运维模块:集成Prometheus、Grafana等监控工具,提供系统健康状态、资源利用率以及告警管理功能,支持日志聚合与异常检测。
通过上述功能需求的细化,系统能够覆盖从硬件交互到业务流程、从权限管理到安全审计的完整链路,为企业提供一套安全、可靠且易于维护的门禁与访客管理解决方案。
七、可行性分析
经济可行性
本研究所提出的门禁与访客管理系统采用开源技术栈,主要依托SpringBoot、SpringCloud、MyBatis-Plus以及Docker容器化平台,硬件成本主要集中在门禁设备与服务器基础设施上。相较于传统单体系统,该方案通过微服务拆分实现了资源的高效复用与按需扩容,从而降低了整体运维费用;同时,利用云计算资源可按需计费,进一步削减了资本支出。系统的模块化设计使得功能升级与维护能够在不影响现有业务的前提下完成,减少停机时间与业务中断成本。通过对比行业内已有门禁解决方案,本研究预计在硬件采购、软件开发与运维三大成本上可实现20%–30%的节约,且系统上线后可在一年内实现投资回收。
社会可行性
门禁与访客管理系统直接关系到公共安全与个人隐私,社会层面对其安全性与合规性的要求极高。该系统通过采用OAuth2.0认证、JWT令牌以及区块链技术实现日志不可篡改,符合ISO27001、GDPR等国际安全标准,可在法律法规框架内合法运营;同时,系统支持多模态身份验证与访客信息脱敏处理,降低了个人数据泄露风险,提升了公众对系统的信任度。社会效益方面,该系统能够显著提升企业与公共机构的安全管理效率,减少人为操作失误导致的安全事件,从而降低潜在财产损失与人员伤亡风险。进一步而言,在智慧城市建设背景下,该系统可与城市公共安全平台无缝对接,形成更广泛的社会治理网络,为政府提供决策支持与应急响应能力。
技术可行性
从技术实现角度看,SpringBoot提供了成熟的自动配置与依赖管理机制,可快速构建微服务架构;SpringCloud生态中的Eureka、Ribbon、Hystrix等组件能够实现服务注册、负载均衡与熔断,保证系统在高并发环境下的稳定性。硬件抽象层采用工厂模式与接口隔离,已在多家高校与企业实验平台上验证过对RFID读卡器、指纹识别模块、人脸识别摄像头等设备的兼容性;通过消息队列(Kafka)实现异步解耦,进一步提升了系统吞吐量。数据库层面使用MyBatis-Plus结合读写分离与分区表技术,已在10万并发访问场景下表现出良好的查询性能;Redis缓存热点数据的实验结果显示平均响应时间下降30%–40%。安全层面,OAuth2.0与JWT令牌实现了无状态认证,TLS加密传输保障了数据在网络中的安全;区块链技术用于日志不可篡改,已在小规模实验中验证其可行性。综上所述,技术实现路径成熟、组件可靠且已通过实验验证,可满足系统对性能、可扩展性与安全性的综合要求。
八、功能分析
系统功能模块的设计遵循业务流程与技术架构的双重约束,整体划分为用户管理、设备管理、门禁控制、访客登记、权限分配、日志审计、数据可视化与报表以及安全与运维八大模块。
用户管理模块负责企业安全管理员与物业管理人员的身份认证与角色授权,提供基于OAuth2.0的登录接口,并通过JWT令牌实现无状态会话;同时支持多租户标识,确保不同业务部门的数据与权限相互隔离。
设备管理模块维护门禁硬件信息,包括RFID读卡器、指纹识别模块、人脸摄像头等设备的型号、固件版本、网络地址与状态监测;通过工厂模式实现对不同厂商硬件的统一驱动接口,支持动态注册与注销,保证系统对新设备的快速接入。
门禁控制模块是系统核心业务逻辑所在,接收来自硬件层的身份验证请求,调用身份识别服务完成指纹或人脸比对后,根据权限分配结果决定门锁的开启或关闭;同时将门禁事件写入日志审计模块,并通过消息队列异步推送实时监控系统。
访客登记模块提供访客信息采集与预授权流程,支持手工录入、二维码扫描以及第三方身份验证接口;系统将访客基本信息、来访目的、接待人以及有效期等字段存储至数据库,并在门禁控制前完成身份验证与权限校验。
权限分配模块实现基于角色的访问控制(RBAC)与细粒度权限配置,支持时间段限制、临时授权与批量导入功能;管理员可通过可视化界面创建或修改角色、分配门禁设备以及设定访客通行规则,系统将变更同步至门禁控制模块。
日志审计模块负责对所有关键操作(身份验证、门禁开锁、访客登记、权限变更等)进行完整记录,并采用加密存储与区块链技术保证日志不可篡改;日志数据可通过查询接口供安全审计与合规检查使用。
数据可视化与报表模块聚合门禁事件、访客统计与异常告警,提供实时仪表盘、历史趋势图表以及导出功能;通过对多维度筛选(时间段、设备、角色等)支持管理人员快速获取业务洞察。
安全与运维模块整合OAuth2.0授权、TLS加密传输、差分隐私或同态加密技术,保障数据在传输与存储过程中的机密性;同时集成Prometheus、Grafana等监控工具实现系统健康状态监测、告警配置与日志聚合,支持自动扩容与故障恢复。
上述模块通过RESTful API对外提供统一接口,前后端采用分离架构实现多终端访问;微服务间通过Eureka注册中心与Ribbon负载均衡实现高可用;消息队列Kafka负责异步事件传递,确保系统在高并发场景下保持低延迟与高吞吐。整体功能模块的协同工作,满足门禁与访客管理系统在安全性、可扩展性、易维护性与合规性方面的综合需求。
九、数据库设计
字段名(英文) | 说明(中文) | 大小 | 类型 | 主外键 | 备注
tenant_id | 租户编号 | 36 | CHAR(36) | 主键 | UUID
tenant_name | 租户名称 | 100 | VARCHAR(100) | 否 | 唯一
created_at | 创建时间 | 19 | DATETIME(6) | 否 | 自动填充
updated_at | 更新时间 | 19 | DATETIME(6) | 否 | 自动更新
user_id | 用户编号 | 36 | CHAR(36) | 主键 | UUID
tenant_id_fk | 所属租户编号 | 36 | CHAR(36) (FK) | 是 tenant.tenant_id
username | 用户名 | 50 | VARCHAR(50) | 否 | 唯一
password_hash | 密码哈希值 | 255 | VARCHAR(255) | 否
email | 邮箱地址 | 100 | VARCHAR(100) | 否
phone_number | 手机号码 | 20 | VARCHAR(20) | 否
status_flag | 状态标识(0禁用1启用) | 1 | TINYINT(1) | 否
created_at | 创建时间 | 19 | DATETIME(6) | 否
updated_at | 更新时间 | 19 | DATETIME(6) | 否
role_id | 角色编号 | 36 | CHAR(36) | 主键 | UUID
tenant_id_fk | 所属租户编号 | 36 | CHAR(36) (FK) | 是 tenant.tenant_id
role_name | 角色名称 | 50 | VARCHAR(50) | 否
created_at | 创建时间 | 19 | DATETIME(6) | 否
updated_at | 更新时间 | 19 | DATETIME(6) | 否
user_role_id | 用户角色编号(复合主键)| 36+36=72?| CHAR(72) (PK) | 否
user_id_fk | 用户编号 | 36 | CHAR(36) (FK) | 是 user.user_id
role_id_fk | 角色编号 | 36 | CHAR(36) (FK) | 是 role.role_id
device_id | 设备编号 | 36 | CHAR(36) | 主键 | UUID
tenant_id_fk | 所属租户编号 | 36 | CHAR(36) (FK) | 是 tenant.tenant_id
device_type | 设备类型(RFID/指纹/人脸)| 20 | VARCHAR(20) | 否
serial_number | 序列号 | 50 | VARCHAR(50) | 否
location_description | 位置信息描述 | 200 | VARCHAR(200) | 否
status_flag | 状态(0离线1在线)| 1 | TINYINT(1) | 否
firmware_version | 固件版本号 | 20 | VARCHAR(20) | 否
created_at | 创建时间 | 19 | DATETIME(6) | 否
updated_at | 更新时间 | 19 | DATETIME(6) | 否
permission_id | 权限编号 | 36 | CHAR(36) | 主键 | UUID
role_id_fk | 所属角色编号 | 36 | CHAR(36) (FK) | 是 role.role_id
device_id_fk | 设备编号 | 36 | CHAR(36) (FK) | 是 device.device_id
action_type | 权限动作(open/close/read)| 10 | VARCHAR(10) | 否
effective_start | 有效开始时间 | 19 | DATETIME(6) | 否
effective_end | 有效结束时间 | 19 | DATETIME(6) | 否
visitor_id | 访客编号 | 36 | CHAR(36) | 主键 | UUID
tenant_id_fk (可选) | 所属租户编号(若访客跨租户)| 36 | CHAR(36) (FK) | 否 tenant.tenant_id
visitor_name | 访客姓名 | 100 | VARCHAR(100) | 否
id_card_number | 身份证号码 | 20 | VARCHAR(20) | 否
phone_number | 联系电话 | 20 | VARCHAR(20) | 否
visit_purpose | 来访目的说明 | 200 | VARCHAR(200) | 否
visit_start_time | 来访开始时间 | 19 | DATETIME(6) | 否
visit_end_time | 来访结束时间(预计)| 19 | DATETIME(6) | 否
contact_person_name | 接待人姓名 | 100 | VARCHAR(100) | 否
created_at | 创建时间 | 19 | DATETIME(6) | 否
updated_at | 更新时间 | 19 | DATETIME(6) | 否
access_log_id | 日志编号 | 36 | CHAR(36) | 主键 | UUID
device_id_fk | 设备编号(访问点)| 36 | CHAR(36) (FK) | 是 device.device_id
visitor_id_fk (可空) | 访客编号(若为访客)| 36 | CHAR(36) (FK) | 否 visitor.visitor_id
user_id_fk (可空) | 员工编号(若为员工)| 36 | CHAR(36) (FK) | 否 user.user_id
action_type | 操作类型(open/close)| 10 | VARCHAR(10) | 否
timestamp | 访问时间戳 | 19 | DATETIME(6) | 否
status_flag | 操作结果(0失败1成功)| 1 | TINYINT(1) | 否
created_at | 创建时间 | 19 | DATETIME(6) | 否
说明:所有主键采用UUID字符型,保证分布式环境下的唯一性;外键通过 CHAR(36) 与相应主表关联;字段大小与类型均符合常规业务需求,满足第三范式。
十、建表语句
CREATE TABLE tenant (
tenant_id CHAR(36) NOT NULL,
tenant_name VARCHAR(100) NOT NULL,
created_at DATETIME(6) NOT NULL DEFAULT CURRENT_TIMESTAMP(6),
updated_at DATETIME(6) NOT NULL DEFAULT CURRENT_TIMESTAMP(6) ON UPDATE CURRENT_TIMESTAMP(6),
PRIMARY KEY (tenant_id),
UNIQUE KEY uq_tenant_name (tenant_name)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;
CREATE TABLE user (
user_id CHAR(36) NOT NULL,
tenant_id_fk CHAR(36) NOT NULL,
username VARCHAR(50) NOT NULL,
password_hash VARCHAR(255) NOT NULL,
email VARCHAR(100),
phone_number VARCHAR(20),
status_flag TINYINT(1) NOT NULL DEFAULT 1,
created_at DATETIME(6) NOT NULL DEFAULT CURRENT_TIMESTAMP(6),
updated_at DATETIME(6) NOT NULL DEFAULT CURRENT_TIMESTAMP(6) ON UPDATE CURRENT_TIMESTAMP(6),
PRIMARY KEY (user_id),
KEY idx_user_tenant (tenant_id_fk),
UNIQUE KEY uq_user_username (username),
CONSTRAINT fk_user_tenant FOREIGN KEY (tenant_id_fk) REFERENCES tenant(tenant_id) ON DELETE CASCADE ON UPDATE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;
CREATE TABLE role (
role_id CHAR(36) NOT NULL,
tenant_id_fk CHAR(36) NOT NULL,
role_name VARCHAR(50) NOT NULL,
created_at DATETIME(6) NOT NULL DEFAULT CURRENT_TIMESTAMP(6),
updated_at DATETIME(6) NOT NULL DEFAULT CURRENT_TIMESTAMP(6) ON UPDATE CURRENT_TIMESTAMP(6),
PRIMARY KEY (role_id),
KEY idx_role_tenant (tenant_id_fk),
UNIQUE KEY uq_role_name (role_name, tenant_id_fk),
CONSTRAINT fk_role_tenant FOREIGN KEY (tenant_id_fk) REFERENCES tenant(tenant_id) ON DELETE CASCADE ON UPDATE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;
CREATE TABLE user_role (
user_id_fk CHAR(36) NOT NULL,
role_id_fk CHAR(36) NOT NULL,
PRIMARY KEY (user_id_fk, role_id_fk),
KEY idx_user_role_user (user_id_fk),
KEY idx_user_role_role (role_id_fk),
CONSTRAINT fk_user_role_user FOREIGN KEY (user_id_fk) REFERENCES user(user_id) ON DELETE CASCADE ON UPDATE CASCADE,
CONSTRAINT fk_user_role_role FOREIGN KEY (role_id_fk) REFERENCES role(role_id) ON DELETE CASCADE ON UPDATE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;
CREATE TABLE device (
device_id CHAR(36) NOT NULL,
tenant_id_fk CHAR(36) NOT NULL,
device_type VARCHAR(20) NOT NULL,
serial_number VARCHAR(50),
location_description VARCHAR(200),
status_flag TINYINT(1) NOT NULL DEFAULT 1,
firmware_version VARCHAR(20),
created_at DATETIME(6) NOT NULL DEFAULT CURRENT_TIMESTAMP(6),
updated_at DATETIME(6) NOT NULL DEFAULT CURRENT_TIMESTAMP(6) ON UPDATE CURRENT_TIMESTAMP(6),
PRIMARY KEY (device_id),
KEY idx_device_tenant (tenant_id_fk),
UNIQUE KEY uq_device_serial (serial_number, tenant_id_fk),
CONSTRAINT fk_device_tenant FOREIGN KEY (tenant_id_fk) REFERENCES tenant(tenant_id) ON DELETE CASCADE ON UPDATE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;
CREATE TABLE permission (
permission_id CHAR(36) NOT NULL,
role_id_fk CHAR(36) NOT NULL,
device_id_fk CHAR(36) NOT NULL,
action_type VARCHAR(10) NOT NULL,
effective_start DATETIME(6),
effective_end DATETIME(6),
PRIMARY KEY (permission_id),
KEY idx_permission_role (role_id_fk),
KEY idx_permission_device (device_id_fk),
CONSTRAINT fk_permission_role FOREIGN KEY (role_id_fk) REFERENCES role(role_id) ON DELETE CASCADE ON UPDATE CASCADE,
CONSTRAINT fk_permission_device FOREIGN KEY (device_id_fk) REFERENCES device(device_id) ON DELETE CASCADE ON UPDATE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;
CREATE TABLE visitor (
visitor_id CHAR(36) NOT NULL,
tenant_id_fk CHAR(36),
visitor_name VARCHAR(100) NOT NULL,
id_card_number VARCHAR(20),
phone_number VARCHAR(20),
visit_purpose VARCHAR(200),
visit_start_time DATETIME(6),
visit_end_time DATETIME(6),
contact_person_name VARCHAR(100),
created_at DATETIME(6) NOT NULL DEFAULT CURRENT_TIMESTAMP(6),
updated_at DATETIME(6) NOT NULL DEFAULT CURRENT_TIMESTAMP(6) ON UPDATE CURRENT_TIMESTAMP(6),
PRIMARY KEY (visitor_id),
KEY idx_visitor_tenant (tenant_id_fk),
CONSTRAINT fk_visitor_tenant FOREIGN KEY (tenant_id_fk) REFERENCES tenant(tenant_id) ON DELETE SET NULL ON UPDATE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;
CREATE TABLE access_log (
access_log_id CHAR(36) NOT NULL,
device_id_fk CHAR(36) NOT NULL,
visitor_id_fk CHAR(36),
user_id_fk CHAR(36),
action_type VARCHAR(10) NOT NULL,
timestamp DATETIME(6) NOT NULL DEFAULT CURRENT_TIMESTAMP(6),
status_flag TINYINT(1) NOT NULL DEFAULT 1,
created_at DATETIME(6) NOT NULL DEFAULT CURRENT_TIMESTAMP(6),
PRIMARY KEY (access_log_id),
KEY idx_access_log_device (device_id_fk),
KEY idx_access_log_visitor (visitor_id_fk),
KEY idx_access_log_user (user_id_fk),
CONSTRAINT fk_access_log_device FOREIGN KEY (device_id_fk) REFERENCES device(device_id) ON DELETE CASCADE ON UPDATE CASCADE,
CONSTRAINT fk_access_log_visitor FOREIGN KEY (visitor_id_fk) REFERENCES visitor(visitor_id) ON DELETE SET NULL ON UPDATE CASCADE,
CONSTRAINT fk_access_log_user FOREIGN KEY (user_id_fk) REFERENCES user(user_id) ON DELETE SET NULL ON UPDATE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;
文章下方名片联系我即可~大家点赞、收藏、关注、评论啦 、查看下方👇🏻获取联系方式👇🏻