简介电影院售票系统数据库课程设计完整工程文件来自山东大学数据库系统课程实践适合作为高校数据库课程设计参考。项目围绕购票业务展开覆盖数据库需求分析、E-R概念建模、关系表逻辑设计、物理存储规划、前端交互与系统测试等关键环节能帮助学习者理解数据库从概念模型到实际实现的完整链路。整份压缩包共158个文件大小约4.54MB内部以TSX/TypeScript组件、JavaScript脚本、CSS样式、PNG/SVG图标、JSON配置以及SQL建表脚本为主从文件结构可看出涵盖影片列表、场次安排、放映厅布局、登录与个人中心等多个功能模块SQL脚本则提供数据表结构与初始数据目录组织清晰便于按模块查阅。目前已有127人学习下载。资源内附页面预览截图配合前端代码可快速还原选座、订票、支付等核心流程结合SQL脚本还能分析表关系与索引设计为数据库课程报告撰写、项目二次开发或设计文档整理提供了具体素材。1. 电影院售票系统课设不是多建几张表而是把并发卖票这件事想清楚数据库系统课程设计里电影院售票系统是出现频率最高的题目之一。表面上是给用户、电影、场次、订单各建一张表可真正到了评审展示老师总会追问一句两个人同时点同一个座位你的系统怎么保证只有一个人买到很多压缩包里的 cinema-ticketing 项目界面和基本表都能跑可一上并发就翻车。这篇文章不打算复述哪份源码而是把跟这个课设强相关的 ER 建模、DDL 设计、事务隔离级别、唯一约束和压测脚本串成一条能照做的路径。适合正在做类似课设的同学也适合想搞清数据库原理在小型售票系统里怎么落地的人。2. 从 ER 图到关系模式先把电影院的数据模型钉死2.1 实体和联系怎么定选座、场次、订单三条线别揉成一张大宽表数据库系统概论里最经典的做法是先用 ER 图模拟现实世界再转成关系模式。电影院售票系统里最小的实体集合通常是用户、电影、影厅、场次、座位、订单、票。难的不是把这些实体列出来而是把“场次和座位之间的联系”想清楚。一部电影有多个场次一个影厅里有多个座位某个座位在某个场次里能不能买才是售票系统的核心状态。最容易踩的坑是做成一张大宽表把用户姓名、电影名、影厅名、座位号、订单金额、支付时间全塞进“电影票”表里。表面写起来省事可一旦电影改名或影厅调整这张表会出现大量不一致数据。正确做法是把它们拆成多个关系用户一对多订单场次一对多票据座位通过票据跟订单关联。你可以先列一个数据字典草图关系模式核心字段用途useruser_id, username, phone购票人moviemovie_id, title, duration, release_date影片信息hallhall_id, hall_name, seat_rows, seat_cols影厅规划seatseat_id, hall_id, seat_row, seat_col物理座位screeningscreening_id, movie_id, hall_id, start_time排片场次ordersorder_id, order_no, user_id, screening_id, total_amount, status一次购票订单ticketsticket_id, order_id, screening_id, seat_id, price, status一张座位的归属这样拆开之后一个场次对应的某个座位是否出售不需要额外建一张“座位状态表”只要查票据表里有没有对应记录就行。如果查不到说明这个位置可以买。这个思路后面解决外键删除问题时会很关键。2.2 主键、外键和唯一约束用一段能直接跑的 DDL 把表建出来很多同学写建表 SQL 只给主键外键和索引全凭感觉。这里我推荐一套可以直接在 MySQL 8 里执行的建表脚本重点放在 tickets 表上的联合唯一约束。CREATE TABLE user ( user_id INT AUTO_INCREMENT PRIMARY KEY, username VARCHAR(50) NOT NULL, phone VARCHAR(20) NOT NULL ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; CREATE TABLE movie ( movie_id INT AUTO_INCREMENT PRIMARY KEY, title VARCHAR(100) NOT NULL, duration INT NOT NULL COMMENT 时长单位分钟, release_date DATE DEFAULT NULL ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; CREATE TABLE hall ( hall_id INT AUTO_INCREMENT PRIMARY KEY, hall_name VARCHAR(50) NOT NULL, seat_rows INT NOT NULL COMMENT 排数, seat_cols INT NOT NULL COMMENT 每排座位数 ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; CREATE TABLE seat ( seat_id INT AUTO_INCREMENT PRIMARY KEY, hall_id INT NOT NULL, seat_row INT NOT NULL, seat_col INT NOT NULL, UNIQUE KEY uk_hall_seat (hall_id, seat_row, seat_col), FOREIGN KEY (hall_id) REFERENCES hall(hall_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; CREATE TABLE screening ( screening_id INT AUTO_INCREMENT PRIMARY KEY, movie_id INT NOT NULL, hall_id INT NOT NULL, start_time DATETIME NOT NULL, base_price DECIMAL(8,2) NOT NULL, FOREIGN KEY (movie_id) REFERENCES movie(movie_id), FOREIGN KEY (hall_id) REFERENCES hall(hall_id), KEY idx_start_time (start_time) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; CREATE TABLE orders ( order_id INT AUTO_INCREMENT PRIMARY KEY, order_no VARCHAR(32) NOT NULL, user_id INT NOT NULL, screening_id INT NOT NULL, total_amount DECIMAL(10,2) NOT NULL, status TINYINT NOT NULL DEFAULT 0 COMMENT 0待支付 1已支付 2已取消, create_time DATETIME NOT NULL, pay_time DATETIME DEFAULT NULL, UNIQUE KEY uk_order_no (order_no), FOREIGN KEY (user_id) REFERENCES user(user_id), FOREIGN KEY (screening_id) REFERENCES screening(screening_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; CREATE TABLE tickets ( ticket_id INT AUTO_INCREMENT PRIMARY KEY, order_id INT NOT NULL, screening_id INT NOT NULL, seat_id INT NOT NULL, price DECIMAL(8,2) NOT NULL, status TINYINT NOT NULL DEFAULT 0 COMMENT 0待使用 1已使用 2已退票, UNIQUE KEY uk_screening_seat (screening_id, seat_id), FOREIGN KEY (order_id) REFERENCES orders(order_id), FOREIGN KEY (screening_id) REFERENCES screening(screening_id), FOREIGN KEY (seat_id) REFERENCES seat(seat_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;为什么 money 字段要用 DECIMAL 而不是 FLOAT因为电影票价格是十进制小数浮点数在累加和比较时会有精度误差数据库系统原理课里讲过这里不碰运气。为什么 tickets 表要加uk_screening_seat这是整个系统防超卖的最后一道闸门比在应用层加锁更可靠。没有这个唯一约束事务开得再认真也可能由于并发插入顺序问题生产出重复座位。2.3 数据字典要和 ER 图同步评审最先挑的就是字段值写没写全课设报告里最容易被扣分的就是数据字典不清晰。很多同学只画一张 ER 图然后贴一段建表代码就算完事。老师通常先看字段注释、数据范围和约束表述。建议每个表都做一张这样的表字段名类型约束说明order_noVARCHAR(32)NOT NULL, UNIQUE订单编号应用层生成statusTINYINTNOT NULL, DEFAULT 00待支付1已支付2已取消create_timeDATETIMENOT NULL下单时间应用层写入screening_idINTNOT NULL, FK指向排片表不用写得像正式软件需求那么重但要把每个字段为什么存在、默认值多少、取值边界说清楚。数据字典和 ER 图放一起老师看报告时就能快速对照也方便你自己在编码阶段发现字段缺失。3. 购票不超卖事务、锁和唯一约束的配合3.1 一次点击购票在 SQL 层要拆几步前端用户点“选座购买”看起来是一个动作数据库里至少要拆成三步校验场次、创建订单、插入票。如果订单和票不在同一个事务里一旦第二步和第三步中间某个环节失败就会留下只有订单没有票的数据垃圾。常见做法是把这三步包在一个手动事务里START TRANSACTION; -- 1. 校验场次还在售 SELECT screening_id FROM screening WHERE screening_id %s AND status 0 FOR SHARE; -- 2. 创建订单 INSERT INTO orders (order_no, user_id, screening_id, total_amount, status, create_time) VALUES (CONCAT(CK, NOW(), %s), %s, %s, 45.00, 1, NOW()); SET order_id LAST_INSERT_ID(); -- 3. 插入票 INSERT INTO tickets (order_id, screening_id, seat_id, price, status) VALUES (order_id, %s, %s, 45.00, 0); COMMIT;字段%s是应用层参数别把用户输入直接拼进 SQL。SELECT ... FOR SHARE是共享锁用来确保排片没有被管理员删掉同时不会阻塞别人购买其他座位。第三步插入票时如果两个事务同时插入同一场次同一座位数据库会因为唯一约束让其中一个事务直接报重复键错误从而保证只有一张票能插进去。3.2 三种防超卖方案课设里唯一约束比悲观锁更省心我见过不少同学在购票逻辑里写SELECT ... FOR UPDATE先锁座位行再判断座位状态再插入票。这在单条数据上没问题但多个人同时操作不同座位时锁的顺序不一致容易触发死锁。换到 REPEATABLE READ 隔离级别下还有可能引入间隙锁出问题更难排查。更贴合课设的做法是直接依赖唯一约束插入即校验失败即回滚。import pymysql conn pymysql.connect( hostlocalhost, userroot, password123456, databasecinema, charsetutf8mb4, autocommitFalse ) try: with conn.cursor() as cur: cur.execute( INSERT INTO orders (order_no, user_id, screening_id, total_amount, status, create_time) VALUES (%s, %s, %s, %s, 1, NOW()), (order_no, user_id, screening_id, 45.00)) order_id cur.lastrowid cur.execute( INSERT INTO tickets (order_id, screening_id, seat_id, price, status) VALUES (%s, %s, %s, %s, 0), (order_id, screening_id, seat_id, 45.00)) conn.commit() result success except pymysql.IntegrityError as e: conn.rollback() result duplicate finally: conn.close()这段代码里IntegrityError就是唯一约束撞出来的异常。业务逻辑拿到异常后可以给前端返回“这个座位已被选请换一个位置”不需要自己去查状态。相比SELECT FOR UPDATE方案这减少了锁的持续时间和死锁概率代码量也更小。三种方案对比放在课设报告里也很好用先查后插加悲观锁实现直观但锁粒度不好控制唯一约束加事务回滚数据库兜底适合绝大多数票务场景应用层分布式锁课设没必要做老师问起来反而容易暴露自己没理解分布式环境下的锁边界。3.3 隔离级别和锁等待参数默认值知道在什么情况下才需要动MySQL 默认的 REPEATABLE READ 在这个场景下不需要刻意改。很多人一听并发就想改成 READ UNCOMMITTED那是性能换一致性完全没必要。REPEATABLE READ 配合唯一约束已经能保证同一场次同一座位并发插入时只有一个成功。有一个参数建议在应用连接串里调小innodb_lock_wait_timeout 5。默认是 50 秒课设演示时如果某条事务锁冲突前端会卡住很久没反应。调成 5 秒页面最多等 5 秒就报错方便你很快看到问题。另外在 Python 程序里要设置autocommitFalse手动控制事务边界。如果你用 Java JDBC连接串上记得加serverTimezoneAsia/Shanghai不然时间字段死活少 8 小时。4. 让压缩包变成能跑的项目从 SQL 脚本到可视化界面的组织方式4.1 一个能过审的课设压缩包目录与代码分层怎么摆拿到一个类似 cinema-ticketing.zip 的项目别急着解压后直接用 IDE 打开。先看一眼目录结构是否干净。常见的合格结构是这样的cinema-ticketing/ ├── sql/ │ ├── schema.sql │ ├── data.sql │ └── query_demo.sql ├── src/ │ ├── dao/ │ ├── service/ │ ├── ui/ │ └── main.py ├── report/ │ ├── ER.png │ └── 课程设计报告.md └── requirements.txtschema.sql放建表语句data.sql放测试数据query_demo.sql放评讲时常用的几条查询。src 底下按 dao 数据访问、service 业务逻辑、ui 界面分层。别把 IDE 的 .idea 文件夹或者 node_modules 打进去压缩包体积大不说老师还可能打开找不到入口。如果项目是用 Java Swing 或 JavaFX 写的DAO 层用 JDBCService 层处理事务UI 层只负责接收点击事件。把 SQL 查出的结果映射成对象不要在界面类里写大段 SQL。这样即使最后只剩 3 天赶报告也能快速描述清每个文件的职责。4.2 连接参数两个必坑字符集、时区、自动提交数据库连接这一步翻车率极高。Python 用 PyMySQL 连接时这几个参数是必写的conn pymysql.connect( hostlocalhost, # 默认本机 userroot, # 不要写死 root演示时再填 password123456, databasecinema, charsetutf8mb4, # 别用 utf8会漏掉特殊字符 autocommitFalse, # 手动控制事务 connect_timeout5 )Java JDBC 对应参数是String url jdbc:mysql://localhost:3306/cinema ?useUnicodetruecharacterEncodingutf8 serverTimezoneAsia/Shanghai useSSLfalse;charsetutf8mb4比utf8多覆盖 Emoji 和部分生僻字票务系统里用户名保不齐有人用特殊符号。useSSLfalse是避免本机连接时多一次证书校验加快连接速度。connect_timeout5比默认的 30 秒更适合课堂演示数据库没起来时页面也不会半天没反应。4.3 测试数据别用手点写一个初始化脚本生成几百个座位手动一行行插入电影、影厅再挨个加座位做完手指就废了。主流做法是用 SQL 脚本组合生成。下面这段脚本给 1 号厅自动生成 10 排、每排 16 个座位INSERT INTO hall (hall_name, seat_rows, seat_cols) VALUES (1号厅, 10, 16); SET hall_id LAST_INSERT_ID(); INSERT INTO seat (hall_id, seat_row, seat_col) SELECT hall_id, r.n, c.n FROM ( SELECT 1 AS n UNION ALL SELECT 2 UNION ALL SELECT 3 UNION ALL SELECT 4 UNION ALL SELECT 5 UNION ALL SELECT 6 UNION ALL SELECT 7 UNION ALL SELECT 8 UNION ALL SELECT 9 UNION ALL SELECT 10 ) r CROSS JOIN ( SELECT 1 AS n UNION ALL SELECT 2 UNION ALL SELECT 3 UNION ALL SELECT 4 UNION ALL SELECT 5 UNION ALL SELECT 6 UNION ALL SELECT 7 UNION ALL SELECT 8 UNION ALL SELECT 9 UNION ALL SELECT 10 UNION ALL SELECT 11 UNION ALL SELECT 12 UNION ALL SELECT 13 UNION ALL SELECT 14 UNION ALL SELECT 15 UNION ALL SELECT 16 ) c;CROSS JOIN把 10 个排数字和 16 个列数字做笛卡尔积生成 160 行座位记录。这样只要调整第一个子查询的行数就能适配不同影厅。用 UNION 构造数字序列不够优雅但胜在纯 SQL 不用存储过程MySQL 5.7 和 8.0 都能直接跑。5. 避坑实录外键删除、索引失效和并发重座的四个现场5.1 同一场次同一座位被两个人同时买走现象两个客户端同时打开同一个场次的座位图都看到最后一排 5 座可买各自点下单最后数据库里出现两条订单和两条相同座位的票据。原因应用层先查SELECT status FROM ... WHERE seat_id?发现是 0 再执行插入。这两个动作之间没有并发控制第二个用户查到的也是 0。如果 IF 判断和 INSERT 不是同一个事务或者没有唯一约束超卖必然发生。解决把创建订单和插入票据放进同一事务并在tickets表建UNIQUE KEY (screening_id, seat_id)。并发情况下谁先提交谁成功另一个事务插入时被唯一索引挡住抛出重复键异常然后回滚订单。记住唯一约束不是优化手段是这道题的兜底方案。5.2 删除排片时报外键错误现象管理员想删掉一场放错的电影场次数据库报Cannot delete or update a parent row: a foreign key constraint fails明明订单表里查不到这笔场次的订单。原因很多同学为了让座位状态可查询会额外建一张screening_seat表把所有场次和所有座位的组合预先插入进去。删除场次时这张子表里几百条记录还引用着父表所以外键报错。可预期内这条场次根本没卖出去理论上应该能删。解决放弃“预生成座位状态表”的设计座位是否可售用tickets表是否存在对应(screening_id, seat_id)来判断。没有票就没有占用不需要为每个场次复制一遍座位。如果一定要保留预生成表删除场次时需要先删子表数据或者给子表外键加ON DELETE CASCADE。但从项目可维护性看后者容易误伤数据不推荐。5.3 选座页面的可用座位查询越来越慢现象场次数据量不大但用户打开选座页时可用座位查询要 1 到 2 秒。看执行计划发现走了全表扫描。原因查询语句写成WHERE hall_id ? AND seat_row LIKE %5%对seat_row列做模糊匹配索引失效。或者使用WHERE seat_id NOT IN (SELECT seat_id FROM tickets WHERE screening_id ?)且 seats 表主键结果集很大时NOT IN子查询可能让优化器放弃索引。解决可用座位查询标准写法是左连接SELECT s.seat_id, s.seat_row, s.seat_col FROM seat s LEFT JOIN tickets t ON t.screening_id %s AND t.seat_id s.seat_id WHERE s.hall_id %s AND t.ticket_id IS NULL;在tickets.screening_id和seat_id上已经有唯一索引左连接可以直接命中索引。座位的筛选走seat.hall_id索引也很快。课设数据量不大这条 SQL 足够。5.4 订单记录的时间和界面显示对不上现象数据库里create_time明明存的是 2025-06-01 14:30接口返回后页面显示 2025-06-01 06:30相差 8 小时。原因数据库连接串少配serverTimezoneAsia/Shanghai驱动默认拿本地系统时区做转换导致 JDBC 读取 DATETIME 时加了一次时区偏移。MySQL 8 的驱动对时区特别敏感这个问题在本地 Windows 和 Linux 上表现还不一样容易被误判成数据库时间写错。解决连接串统一加serverTimezoneAsia/Shanghai。如果用的是 Python直接datetime.now()写入本地时间然后pytz或zoneinfo统一转成东八区再存。更省事的方式是数据库字段用TIMESTAMP并设置DEFAULT CURRENT_TIMESTAMP让 MySQL 处理时区应用层只做展示。6. 最后一道手活20 行并发脚本验证你的售票系统6.1 只测同一批线程的并发脚本演示前最好自己做一次并发冒烟测试别等老师现场抓着两个人同时点。我一般写一个 Python 脚本起 10 个线程抢同一个座位观察成功数量和失败原因。import threading import pymysql config { host: localhost, user: root, password: 123456, database: cinema, charset: utf8mb4, autocommit: False, } success 0 errors [] lock threading.Lock() def buy(seat_id): global success conn pymysql.connect(**config) try: with conn.cursor() as cur: order_no ftest-{seat_id}-{threading.get_ident()} cur.execute( INSERT INTO orders (order_no, user_id, screening_id, total_amount, status, create_time) VALUES (%s, 1, 1, 45.00, 1, NOW()), (order_no,)) order_id cur.lastrowid cur.execute( INSERT INTO tickets (order_id, screening_id, seat_id, price, status) VALUES (%s, 1, %s, 45.00, 0), (order_id, seat_id)) conn.commit() with lock: success 1 except Exception as e: conn.rollback() with lock: errors.append(str(e)) finally: conn.close() threads [threading.Thread(targetbuy, args(64,)) for _ in range(10)] for t in threads: t.start() for t in threads: t.join() print(f成功 {success} 条失败 {len(errors)} 条) for err in errors[:3]: print(err.split(\n)[0] if err else )脚本里故意让 10 个线程都用同一个seat_id64目的就是制造重复冲突。如果成功数不大于 1说明唯一约束没建对或者事务提交时机不对。6.2 看结果之前先设定两条合格线第一成功数必须等于实际竞争到的座位数这里是 1。第二失败记录里必须是重复键异常比如Duplicate entry 1-64 for key tickets.uk_screening_seat而不能再多出现死锁或者锁等待超时。如果看到Lock wait timeout exceeded先检查是不是有事务一直没提交再考虑要不要把innodb_lock_wait_timeout调小。我会在课设演示前一天跑三遍这个脚本。第一遍看功能第二遍看锁等待第三遍把线程数量从 10 加到 50确认错误列表里有没有出现预料之外的异常。这个习惯救过我一次有一版代码在插入票据前加了一次冗余查询50 个线程并发时 MySQL 连接池被打满后来改成连接一行一关才扛住。希望你不需要踩这个坑但提前把这一手验完演示时才不会在台上慌张。希望帮到你。本文还有配套的精品资源点击获取