《数据库课程设计》是信息管理与信息系统专业教学体系中一门承前启后的核心实践课程是连接数据库理论知识与实际工程应用的关键桥梁是一门实践性很强的专业综合性课程。在当今大数据与云计算蓬勃发展的时代背景下数据库系统作为信息基础设施的基石其设计质量与开发效率直接影响着各类应用系统的稳定性、可扩展性与数据价值挖掘能力。因此本课程不仅是对前期理论课程知识的综合检验更是对学生系统分析能力、工程化思维能力和团队协作能力的一次全面锤炼。本课程以“工学结合、项目驱动”为基本教学理念要求学生严格遵循软件工程的生命周期方法论完整经历数据库系统从需求萌芽到落地部署的全过程。具体而言课程核心任务涵盖以下关键阶段需求分析通过实地调研或场景模拟准确捕获用户信息管理需求编制规范的需求规格说明书概念模型设计运用实体–联系E-R方法或面向对象建模方法建立独立于具体数据库管理系统DBMS的高层数据抽象模型逻辑模型设计将概念模型转换为关系、网状或层次等逻辑数据结构并运用范式理论进行优化消除数据冗余与更新异常物理模型设计结合所选DBMS本课程以SQL Server为技术平台的内部存储机制、索引策略、事务并发控制参数对逻辑模型进行物理实现层面的调优系统实现与测试利用 SQL 语言编写数据库脚本完成表、视图、存储过程、触发器、函数等数据库对象构建并辅以必要的应用连接程序进行功能验证与性能基准测试。本课程的技术实现环节紧密依托SQL Server关系数据库管理系统使学生能够熟悉运用其图形化管理工具和高级编程特性如动态SQL、事务隔离级别控制等从而将理论上的范式分解、完整性约束、安全性授权等概念转化为切实可执行的数据库方案。同时鼓励学生在完成基础功能的前提下探索索引监控、查询执行计划分析、死锁检测等性能调优手段培养“设计–实现–反馈–迭代”的工程闭环意识。本课程的目的与意义可归纳为以下四个层面能力提升——使学生掌握数据库系统分析、设计、开发与管理的全过程技能具备独立承担中小型数据库应用项目的能力思维塑造——强化系统性思维、抽象思维和批判性思维培养学生从全局视角权衡时间效率、空间开销、安全性与易用性等多维目标规范养成——通过撰写规范的技术文档、遵循编码标准、执行版本控制与测试用例设计使学生受到严格的工程化训练逐步形成严谨、扎实的学术风格与职业素养创新激发——在课程设计中设置开放性选题与扩展挑战鼓励学生针对特定业务场景如电商订单系统、图书馆借阅管理、学生选课平台等提出个性化解决方案激发主动探究与创新实践的热情。通过本课程的系统训练学生将不再止步于编写单条SQL语句或简单的增删改查操作而是能够从软件工程的高度审视数据架构设计理解数据模型对上层业务逻辑的深层约束进而具备在复杂信息系统中承担数据层规划与优化工作的核心竞争力向成长为“懂理论、精技术、重规范、能创新”的高素质应用型人才进一步靠近。最终本课程期望为学生后续的毕业设计、大创项目等数据库相关工程实践奠定坚实而可靠的基础。现将本人课程设计情况汇报如下一、需求分析1.1 需求的来源随着城市化进程的加速和私家车保有量的持续增长停车难已成为城市交通管理中的突出问题。社区、写字楼和住宅小区普遍存在车位资源紧张、信息不对称、利用率低等问题。一方面大量私人车位在空闲时段闲置浪费另一方面有停车需求的用户却难以找到可用车位。基于此背景结合《Web应用技术》课程设计选定“共享车位预约管理系统”作为本课程设计题目旨在通过信息化手段实现车位资源的共享与高效利用。1.2 需求的具体内容本系统需满足以下功能需求1用户管理模块用户注册新用户通过手机号和密码进行注册用户登录已注册用户通过手机号和密码登录系统角色区分系统区分普通用户USER和管理员ADMIN两种角色会话管理支持用户登录状态的保持与注销2车位信息管理模块车位信息展示以卡片形式展示所有车位信息包括车位编号、位置区域、状态、备注等车位状态管理支持可预约、已预约、维护中三种状态车位搜索筛选管理员可按车位编号、位置、状态等关键词进行搜索3车位预约模块在线预约普通用户可查看可预约车位并选择预约时段进行预约预约信息填写需填写预约人姓名、联系电话、预约时段预约状态更新预约成功后自动将车位状态变更为已预约4管理中心模块管理员车位CRUD操作管理员可新增、编辑、删除车位记录数据重置支持恢复示例数据统计汇总显示总记录数、可预约数量等统计信息5个人中心模块账户信息展示显示用户名、手机号、会员等级等预约记录查看展示历史预约记录和订单统计1.3 需求的获取方式本系统需求的获取主要采用以下方式文献调研查阅停车场管理、共享经济等相关文献资料了解行业现状和痛点竞品分析分析现有停车APP如ETCP、停简单等的功能设计借鉴其优点场景模拟模拟用户从查找车位到完成预约的完整流程梳理功能点自顶向下分析从系统整体目标出发逐层分解为具体功能模块1.4 数据字典1.4.1 数据项1用户数据项User数据项名含义类型长度取值范围约束user_id用户编号BIGINT8自增序列主键非空phone手机号VARCHAR1111位数字唯一非空password登录密码VARCHAR64字母数字组合非空user_name用户姓名VARCHAR50中文字符非空role用户角色VARCHAR10USER/ADMIN非空默认USERcreate_time注册时间DATETIME—日期时间非空默认当前时间2车位数据项ParkingSpace数据项名含义类型长度取值范围约束space_id车位编号BIGINT8自增序列主键非空space_code车位代码VARCHAR20如A-101唯一非空region所属区域VARCHAR100如海景花园非空status车位状态VARCHAR10可预约/已预约/维护中非空默认可预约remark备注信息VARCHAR200文本描述可为空create_time创建时间DATETIME—日期时间非空3预约记录数据项Booking数据项名含义类型长度取值范围约束booking_id预约编号BIGINT8自增序列主键非空user_id用户编号BIGINT8外键引用User外键非空space_id车位编号BIGINT8外键引用ParkingSpace外键非空reserve_time预约时段DATETIME—日期时间非空booking_status预约状态VARCHAR10已预约/已完成/已取消非空默认已预约create_time创建时间DATETIME—日期时间非空1.4.2 数据结构1用户信息结构用户 用户编号 手机号 密码 用户姓名 角色 注册时间2车位信息结构车位 车位编号 车位代码 所属区域 车位状态 备注 创建时间3预约记录结构预约记录 预约编号 用户编号 车位编号 预约时段 预约状态 创建时间二、概念结构设计2.1 子系统各自的分E-R图1用户管理子系统E-R图2车位管理子系统E-R3预约管理子系统E-R图2.2 合并分E-R图形成初步E-R图将上述三个子系统的E-R图进行合并消除冗余形成初步的整体E-R图┌──────────────────┐ │ 用户 │ ├──────────────────┤ │ PK user_id │ │ UQ phone │ │ password │ │ user_name │ │ role │ │ create_time │ └────────┬─────────┘ │ 1 │ │ 发起 │ │ N ┌────────┴─────────┐ │ 预约记录 │ ├──────────────────┤ │ PK booking_id │ │ FK user_id │ │ FK space_id │ │ reserve_time │ │ booking_status│ │ create_time │ └────────┬─────────┘ │ │ N │ │ 关联 │ │ 1 ┌────────┴─────────┐ │ 车位 │ ├──────────────────┤ │ PK space_id │ │ UQ space_code │ │ region │ │ status │ │ remark │ │ create_time │ └──────────────────┘2.3 E-R图的优化过程形成基本E-R图优化分析消除冗余属性初步E-R图中预约记录中的user_id和space_id已经通过外键关联到用户和车位实体预约记录中不需要再存储用户姓名、手机号、车位代码等冗余信息这些信息可以通过关联查询获取。规范化处理原系统设计中ParkingRecord将车位信息与预约信息耦合在一起ownerName、phone、reserveTime直接存储在车位记录中。优化后将其拆分为独立的用户实体、车位实体和预约记录实体符合第三范式3NF要求。联系类型确定用户与预约记录一对多1:N一个用户可有多次预约记录车位与预约记录一对多1:N一个车位可被多次预约不同时段优化后的基本E-R图最终版┌──────────────────┐ ┌──────────────────┐ │ 用户 │ │ 车位 │ ├──────────────────┤ ├──────────────────┤ │ PK user_id │ │ PK space_id │ │ UQ phone │ │ UQ space_code │ │ password │ │ region │ │ user_name │ │ status │ │ role │ │ remark │ │ create_time │ │ create_time │ └────────┬─────────┘ └────────┬─────────┘ │ 1 │ 1 │ │ │ 发起 │ 关联 │ │ │ N │ N └──────────┬─────────────────┘ │ ┌───────┴──────────┐ │ 预约记录 │ ├──────────────────┤ │ PK booking_id │ │ FK user_id │ │ FK space_id │ │ reserve_time │ │ booking_status│ │ create_time │ └──────────────────┘2.4 对整体E-R图进行验证验证方法采用用户-用例回溯法将系统功能需求逐一映射到E-R图中的实体和联系。功能需求涉及实体涉及联系能否满足用户注册/登录用户—✓查看车位列表车位—✓预约车位用户、车位、预约记录发起、关联✓查看预约历史用户、预约记录、车位发起、关联✓管理员管理车位车位—✓管理员查看所有预约预约记录、用户、车位发起、关联✓验证结论优化后的E-R图能够完整覆盖系统的所有功能需求实体定义清晰联系类型正确不存在冗余和不一致设计合理。三、逻辑结构设计3.1 把E-R图转变为关系模型根据E-R图向关系模型的转换规则将上述基本E-R图转换为以下关系模式1用户关系UserUser(user_id, phone, password, user_name, role, create_time)主码user_id候选码phone关系描述存储系统用户的基本信息包括登录凭证和角色信息2车位关系ParkingSpaceParkingSpace(space_id, space_code, region, status, remark, create_time)主码space_id候选码space_code关系描述存储车位的基本信息包括编号、位置、状态和备注3预约记录关系BookingBooking(booking_id, user_id, space_id, reserve_time, booking_status, create_time)主码booking_id外码user_id引用User.user_idspace_id引用ParkingSpace.space_id关系描述存储用户预约车位的记录连接用户和车位两个实体3.2 对数据模型进行优化优化依据1范式分析原系统设计中ParkingRecord实体将车位信息spaceCode、region、status、remark与预约信息ownerName、phone、reserveTime耦合在同一个数据结构中存在以下问题插入异常新增一个尚未被预约的车位时ownerName、phone、reserveTime字段必须置空造成数据冗余更新异常当用户修改手机号时需要更新所有关联的预约记录中的phone字段删除异常删除预约记录时可能会丢失车位信息优化后的关系模式满足第三范式3NF满足1NF所有属性都是不可再分的原子值满足2NF每个非主属性完全函数依赖于主码不存在部分依赖满足3NF每个非主属性不传递依赖于主码不存在传递依赖2性能优化考虑在Booking表的user_id和space_id上建立索引提高关联查询效率在ParkingSpace表的status字段上建立索引加快按状态筛选车位的查询在User表的phone字段上建立唯一索引保证登录查询效率3数据完整性约束实体完整性所有主键非空且唯一参照完整性Booking表中的user_id和space_id必须引用已存在的User和ParkingSpace记录用户定义完整性status字段取值限制为可预约、已预约、维护中role字段取值限制为USER、ADMIN3.3 根据应用情况设计用户子模式根据系统不同角色的使用场景设计以下用户子模式视图1普通用户视图v_user_bookingCREATE VIEW v_user_booking AS SELECT b.booking_id, b.reserve_time, b.booking_status, p.space_code, p.region, p.remark, b.user_id FROM Booking b JOIN ParkingSpace p ON b.space_id p.space_id;用途普通用户登录后查看自己的预约记录隐藏其他用户的预约信息和敏感数据。2管理员视图v_admin_bookingCREATE VIEW v_admin_booking AS SELECT b.booking_id, u.user_name, u.phone, p.space_code, p.region, b.reserve_time, b.booking_status, b.create_time FROM Booking b JOIN [User] u ON b.user_id u.user_id JOIN ParkingSpace p ON b.space_id p.space_id;用途管理员查看所有预约记录的完整信息便于管理和统计。3可预约车位视图v_available_spacesCREATE VIEW v_available_spaces AS SELECT space_id, space_code, region, remark FROM ParkingSpace WHERE status N可预约;用途供普通用户浏览可预约车位列表过滤掉已预约和维护中的车位。四、物理结构设计4.1 数据库管理系统选择选择Microsoft SQL Server作为数据库管理系统理由如下项目pom.xml中已配置mssql-jdbc驱动依赖SQL Server提供完善的事务支持、安全机制和备份恢复功能与Spring Boot框架集成良好适合中小型Web应用的数据存储需求4.2 存储引擎与文件组织采用SQL Server默认存储引擎数据文件和日志文件分开存储数据文件.mdf存储用户、车位、预约记录等核心业务数据日志文件.ldf记录数据库事务日志支持故障恢复4.3 索引设计索引名所属表索引列索引类型说明PK_UserUseruser_id聚集索引主键索引自动创建UQ_User_PhoneUserphone唯一非聚集索引加速手机号登录查询PK_ParkingSpaceParkingSpacespace_id聚集索引主键索引UQ_Space_CodeParkingSpacespace_code唯一非聚集索引加速车位编号查询IDX_Space_StatusParkingSpacestatus非聚集索引加速按状态筛选PK_BookingBookingbooking_id聚集索引主键索引IDX_Booking_UserBookinguser_id非聚集索引加速用户预约查询IDX_Booking_SpaceBookingspace_id非聚集索引加速车位预约查询4.4 存储空间估算表名预估行数单行大小总存储量索引空间合计User1,000~200B200KB100KB300KBParkingSpace500~300B150KB80KB230KBBooking10,000~200B2MB500KB2.5MB初期总存储空间约3MB预留10倍增长空间分配初始数据库大小为50MB。五、数据库的实施5.1 完成数据库的创建CREATE DATABASE SharedParkingDB ON PRIMARY ( NAME SharedParkingDB_Data, FILENAME D:\DBData\SharedParkingDB.mdf, SIZE 50MB, MAXSIZE 500MB, FILEGROWTH 10MB ) LOG ON ( NAME SharedParkingDB_Log, FILENAME D:\DBData\SharedParkingDB.ldf, SIZE 10MB, MAXSIZE 100MB, FILEGROWTH 5MB ); GO ​ USE SharedParkingDB; GO5.2 完成数据表的创建CREATE TABLE [User] ( user_id BIGINT IDENTITY(1,1) PRIMARY KEY, phone VARCHAR(11) NOT NULL, password VARCHAR(64) NOT NULL, user_name NVARCHAR(50) NOT NULL, role VARCHAR(10) NOT NULL DEFAULT USER, create_time DATETIME NOT NULL DEFAULT GETDATE(), CONSTRAINT UQ_User_Phone UNIQUE (phone), CONSTRAINT CK_User_Role CHECK (role IN (USER, ADMIN)) ); ​ CREATE TABLE ParkingSpace ( space_id BIGINT IDENTITY(1,1) PRIMARY KEY, space_code VARCHAR(20) NOT NULL, region NVARCHAR(100) NOT NULL, status VARCHAR(10) NOT NULL DEFAULT N可预约, remark NVARCHAR(200), create_time DATETIME NOT NULL DEFAULT GETDATE(), CONSTRAINT UQ_Space_Code UNIQUE (space_code), CONSTRAINT CK_Space_Status CHECK (status IN (N可预约, N已预约, N维护中)) ); ​ CREATE TABLE Booking ( booking_id BIGINT IDENTITY(1,1) PRIMARY KEY, user_id BIGINT NOT NULL, space_id BIGINT NOT NULL, reserve_time DATETIME NOT NULL, booking_status VARCHAR(10) NOT NULL DEFAULT N已预约, create_time DATETIME NOT NULL DEFAULT GETDATE(), CONSTRAINT CK_Booking_Status CHECK (booking_status IN (N已预约, N已完成, N已取消)) );5.3 完成数据表之间联系的创建ALTER TABLE Booking ADD CONSTRAINT FK_Booking_User FOREIGN KEY (user_id) REFERENCES [User](user_id) ON DELETE CASCADE ON UPDATE CASCADE; ​ ALTER TABLE Booking ADD CONSTRAINT FK_Booking_Space FOREIGN KEY (space_id) REFERENCES ParkingSpace(space_id) ON DELETE CASCADE ON UPDATE CASCADE;5.4 导入相关数据INSERT INTO [User] (phone, password, user_name, role) VALUES (13800000000, user123, N张先生, USER), (18800000000, admin123, N管理员, ADMIN); ​ INSERT INTO ParkingSpace (space_code, region, status, remark) VALUES (A-101, N海景花园, N可预约, N靠近电梯适合小型车), (B-205, N云峰商务中心, N已预约, NVIP 车位), (C-312, N城市广场, N维护中, N临时关闭等待检修), (D-108, N阳光花园, N可预约, N地面车位方便进出), (E-220, N金融中心, N可预约, N地下二层有监控覆盖); ​ INSERT INTO Booking (user_id, space_id, reserve_time, booking_status) VALUES (1, 2, 2026-07-02 18:30:00, N已预约);5.5 判断是否要建立相关视图基于3.3节的分析建立以下视图以支持不同用户角色的数据访问需求CREATE VIEW v_user_booking AS SELECT b.booking_id, b.reserve_time, b.booking_status, p.space_code, p.region, p.remark, b.user_id FROM Booking b JOIN ParkingSpace p ON b.space_id p.space_id; GO ​ CREATE VIEW v_admin_booking AS SELECT b.booking_id, u.user_name, u.phone, p.space_code, p.region, b.reserve_time, b.booking_status, b.create_time FROM Booking b JOIN [User] u ON b.user_id u.user_id JOIN ParkingSpace p ON b.space_id p.space_id; GO ​ CREATE VIEW v_available_spaces AS SELECT space_id, space_code, region, remark FROM ParkingSpace WHERE status N可预约; GO5.6 进行相关查询的示例查询1查看所有可预约车位SELECT space_code, region, remark FROM v_available_spaces;查询2查询某用户的预约历史SELECT b.booking_id, p.space_code, p.region, b.reserve_time, b.booking_status FROM Booking b JOIN ParkingSpace p ON b.space_id p.space_id WHERE b.user_id 1 ORDER BY b.create_time DESC;查询3统计各区域车位预约情况SELECT p.region, COUNT(*) AS total_spaces, SUM(CASE WHEN p.status N可预约 THEN 1 ELSE 0 END) AS available, SUM(CASE WHEN p.status N已预约 THEN 1 ELSE 0 END) AS booked, SUM(CASE WHEN p.status N维护中 THEN 1 ELSE 0 END) AS maintenance FROM ParkingSpace p GROUP BY p.region;查询4管理员查看所有预约记录SELECT * FROM v_admin_booking ORDER BY create_time DESC;查询5预约车位事务操作BEGIN TRANSACTION; ​ IF EXISTS (SELECT 1 FROM ParkingSpace WHERE space_id 1 AND status N可预约) BEGIN UPDATE ParkingSpace SET status N已预约 WHERE space_id 1; INSERT INTO Booking (user_id, space_id, reserve_time, booking_status) VALUES (1, 1, 2026-07-15 09:00:00, N已预约); COMMIT TRANSACTION; PRINT 预约成功; END ELSE BEGIN ROLLBACK TRANSACTION; PRINT 该车位不可预约; END;六、数据库的维护6.1 系统优点总结1功能设计方面角色权限分离清晰普通用户和管理员拥有不同的操作界面和功能权限保证了数据安全业务流程完整覆盖了从用户注册、登录、车位浏览、在线预约到订单管理的完整业务流程前端交互友好采用卡片式布局展示车位信息配合Vue.js实现动态数据绑定和搜索过滤用户体验良好2数据库设计方面规范化程度高通过将原系统耦合的数据结构拆分为User、ParkingSpace、Booking三个独立实体满足第三范式要求消除了数据冗余和更新异常约束完善设置了主键约束、唯一约束、外键约束和CHECK约束保证了数据的完整性和一致性索引设计合理针对高频查询场景手机号登录、状态筛选、用户预约查询建立了相应的索引3技术架构方面采用Spring Boot Vue.js的前后端分离架构技术栈成熟稳定使用Session进行用户认证安全性有保障前端采用localStorage进行离线数据缓存在网络异常时仍可使用6.2 改进方向与方案1当前系统中的不足问题描述影响数据持久化缺失当前后端使用内存List存储数据服务重启后数据丢失严重用户认证过于简单硬编码两个测试账号无真实注册功能中等缺少支付模块预约流程无支付环节无法完成交易闭环较高缺少消息通知预约成功后无短信/邮件通知中等前端注册页面未实现注册表单仅为静态展示无后端接口中等2改进方案① 数据持久化改造高优先级将当前内存存储改为真实的数据库存储引入Spring Data JPA或MyBatis作为持久层框架dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-data-jpa/artifactId /dependency创建对应的Repository接口public interface ParkingSpaceRepository extends JpaRepositoryParkingSpace, Long { ListParkingSpace findByStatus(String status); OptionalParkingSpace findBySpaceCode(String spaceCode); }② 用户注册功能完善高优先级新增用户注册接口支持手机号验证密码采用BCrypt加密存储提高安全性增加手机号格式校验和唯一性检查③ 支付模块引入中优先级新增Payment支付记录实体关联预约记录集成第三方支付接口如微信支付、支付宝实现支付状态回调和订单状态联动④ 消息通知服务中优先级新增Notification通知记录实体预约成功/取消时自动发送短信或邮件通知预约到期前发送提醒通知⑤ 数据库备份策略配置SQL Server定时备份任务每日凌晨自动全量备份定期进行备份恢复演练确保数据可恢复性设置事务日志定期截断防止日志文件无限增长⑥ 性能优化对高频查询建立覆盖索引减少回表操作引入Redis缓存热点数据如可预约车位列表对历史预约记录进行归档定期将超过一年的数据迁移到历史表附录系统技术栈说明层次技术版本后端框架Spring Boot3.5.16Java版本JDK17构建工具Maven—数据库Microsoft SQL Server22前端框架Vue.js2.x前端样式原生CSS—项目结构前后端分离—