简介这是一套基于Python与MongoDB的WEB电影数据库课程设计完整方案面向计算机相关专业做数据库大作业、课设或初期项目演示的学生。内容覆盖数据导入与脱敏处理、基于Flask的前后端交互、用户观影记录检索、关键词查询、风格热门榜等核心功能并配有数据分析文档、E-R图、界面截图及操作报告适合从入门到进阶的Python开发者参考复用。共77个文件主要包括Python脚本、HTML/CSS/JS前端页面、Markdown文档、PNG/JPG截图和配置文件等压缩包仅4.96MB下载后可快速按目录定位源码、文档或数据集。已有359人学习浏览。资源为作者答辩平均96分的真实作业所有代码均测试通过除功能实现外还额外整理云服务器部署、MongoDB安装与副本集配置、docker排错思路、索引优化等环境搭建经验能有效减少踩坑成本值得作为完整课设模板借鉴。1. 一个电影数据库大作业的完整形态从数据到报告都有什么前两天有个同学拿着他的数据库大作业来找我说是“电影数据库的数据系统”代码写了大半但老师问他数据从哪来、怎么保证不重复、报告里要放什么他全卡住了。这种情况我见得很多——不是 SQL 没学会而是把大作业理解成了“写代码”忽略了后面的数据集、分析、文档和操作报告其实也是产品的一部分。这门课的大作业之所以选“电影数据库”是因为电影数据天然带多对多关系、带数值字段、带时间维度足够把范式、外键、聚合查询、可视化全串起来。合适的对象是那些需要交一份完整课程设计的人既要有能跑的 Python 代码又要有数据文件、分析图表和一份能直接打印的报告。这篇文章就顺着这个交付物的顺序讲选型、建表、造数、分析、避坑、写文档六段走完照着做就能凑齐一套能答辩的成果。2. 数据库选型与六张核心表为什么 SQLite 最适合课堂演示2.1 为什么 SQLite 比 MySQL 更适合答辩演示选型一句话如果你的课程没有强制指定数据库我的第一建议永远是 SQLite而不是 MySQL。原因很实在SQLite 是文件型数据库整个数据库就是一个 .db 文件U 盘拷走、换电脑打开、答辩现场演示全都不需要安装服务、配置账号密码、处理端口占用。这对课程设计场景是致命的省心你不需要在演示前半小时还在跟 MySQL 服务较劲。MySQL 的优势是“显得更企业级”但它带来的成本是你得让老师那边也能跑起来或者至少你演示的机器上服务别崩。很多翻车现场不是因为 SQL 写错而是 MySQL 连不上。SQLite 没有这个问题Python 标准库自带 sqlite3不需要装任何第三方包就能开搞。如果你的课程硬性要求 MySQL代码切换点其实很小。连接部分从sqlite3.connect(film.db)换成pymysql.connect(host..., user..., password...)占位符从?换成%s自增字段从AUTOINCREMENT换成AUTO_INCREMENT。其余的表结构、查询逻辑、数据分析代码全部通用。我会在下面的建表语句里标注这些差异点方便你两套都试。2.2 建库建表先定主表再补关联表一次写出六张表我一般把电影数据库拆成六张表这个规模刚好能展示“关系型数据库”的设计思路又不至于为了复杂而复杂movies存电影本体genres和movie_genres处理电影与类型的多对多directors和movie_directors处理导演的多对多ratings单独存打分记录把“用户评分”和“电影信息”彻底分开。-- 创建六张核心表SQLite 方言 PRAGMA foreign_keys ON; -- SQLite 默认不启用外键约束必须手动开 CREATE TABLE movies ( movie_id INTEGER PRIMARY KEY AUTOINCREMENT, title TEXT NOT NULL, year INTEGER NOT NULL, country TEXT, language TEXT, duration_min INTEGER, budget REAL, box_office REAL ); CREATE TABLE genres ( genre_id INTEGER PRIMARY KEY AUTOINCREMENT, genre_name TEXT UNIQUE NOT NULL ); CREATE TABLE movie_genres ( movie_id INTEGER NOT NULL, genre_id INTEGER NOT NULL, PRIMARY KEY (movie_id, genre_id), FOREIGN KEY (movie_id) REFERENCES movies(movie_id), FOREIGN KEY (genre_id) REFERENCES genres(genre_id) ); CREATE TABLE directors ( director_id INTEGER PRIMARY KEY AUTOINCREMENT, director_name TEXT NOT NULL, birth_year INTEGER ); CREATE TABLE movie_directors ( movie_id INTEGER NOT NULL, director_id INTEGER NOT NULL, PRIMARY KEY (movie_id, director_id), FOREIGN KEY (movie_id) REFERENCES movies(movie_id), FOREIGN KEY (director_id) REFERENCES directors(director_id) ); CREATE TABLE ratings ( rating_id INTEGER PRIMARY KEY AUTOINCREMENT, movie_id INTEGER NOT NULL, rating_score REAL NOT NULL CHECK (rating_score BETWEEN 1 AND 10), rating_time TEXT, user_id INTEGER, FOREIGN KEY (movie_id) REFERENCES movies(movie_id) );这段 SQL 里有几个设计是刻意的。movie_genres和movie_directors都是典型的“桥表”主键由两个外键联合组成这就在物理层面保证了“同一部电影不会重复关联同一个类型或同一个导演”不用在业务代码里做去重判断。ratings表里的CHECK约束把评分钉死在 1 到 10 之间比你在 Python 里写if判断更可靠因为数据库层拦截了所有非法写入。budget和box_office我用REAL而不是INTEGER因为金额单位可能是“万美元”也可能是“元”用浮点能兼容小数。如果后续统计要用“票房减预算”算盈利浮点字段直接加减即可不用先做类型转换。这一整套表结构不依赖于某个特定数据库MySQL 下只需把AUTOINCREMENT换成AUTO_INCREMENT其余原样可用。2.3 索引与约束让统计查询不慢、数据不乱写完表结构紧接着要干的一件事是建索引。大作业的数据量通常是几百到几千条这个量级任何查询都快得感觉不到索引存在但答辩时老师经常会问“你的系统数据量大了怎么办”索引就是标准答案。在ratings.movie_id上建索引能让“按电影聚合评分”这种高频查询走索引扫描在movies.year上建索引能让所有按年份分组统计的查询稳定提速。CREATE INDEX idx_ratings_movie ON ratings(movie_id); CREATE INDEX idx_movies_year ON movies(year);建索引的同时别忘了给关键的字段加唯一约束。genres.genre_name已经加了UNIQUE这保证了“剧情”这个类型不会因为一次导入失误出现两行。同理在清洗数据时每部电影对应一个固定的movie_id关联表里的数据只增不删这样后面分析阶段做那些 JOIN 查询时才不会出现“类型占比超过 100%”这种让人摸不着头脑的结果。3. 用 Python 灌数据数据集构造与清洗的两个阶段3.1 没有现成数据时用脚本造一批贴近结构的仿真数据很多人在数据集这步就卡住了——网上找不到“同时带导演、类型、评分、票房、时长”的干净 CSV有版权的榜单数据又不敢直接往报告里贴。我的做法是自己造仿真数据数据格式完全按目标表结构来字段类型、取值范围、多对多关系全部模拟真实场景数量可调。把这套生成脚本放进交付物里老师反而会认为你理解了数据从哪里来。# generate_data.py —— 生成 300 部虚构电影信息并写入 CSV import csv import random random.seed(42) title_prefix [暗夜, 星际, 追光, 无声, 逆风, 零度, 迷城, 远山] title_suffix [行者, 边境, 回响, 航线, 黎明, 代码, 孤岛, 旅人] genres_pool [剧情, 动作, 科幻, 喜剧, 悬疑, 爱情, 动画, 纪录] director_pool [ (陈远航, 1960), (林默, 1975), (赵一舟, 1982), (苏晚晴, 1970), (高野, 1968), (周明川, 1988) ] countries [中国, 美国, 日本, 法国, 英国] def make_title(): return random.choice(title_prefix) random.choice(title_suffix) def make_movie_row(movie_id): return { movie_id: movie_id, title: make_title(), year: random.randint(1980, 2024), country: random.choice(countries), language: 未知, duration_min: random.randint(90, 150), budget: round(random.uniform(500, 8000), 2), box_office: round(random.uniform(800, 30000), 2), } def main(): movies [] for mid in range(1, 301): row make_movie_row(mid) row[language] {中国: 汉语, 美国: 英语, 日本: 日语, 法国: 法语, 英国: 英语}[row[country]] movies.append(row) with open(movies.csv, w, newline, encodingutf-8-sig) as f: writer csv.DictWriter(f, fieldnameslist(movies[0].keys())) writer.writeheader() writer.writerows(movies) if __name__ __main__: main()这里有两个参数值得说明。random.seed(42)让每次运行生成的数据完全一致这一点对答辩非常关键——昨天分析出的图表今天重新跑还能复现不会出现“老师你看我这个结果”的时候数字对不上。写 CSV 用了encodingutf-8-sig这个不是玄学是因为 Excel 直接打开 UTF-8 文件会乱码utf-8-sig带 BOM 头是让 Excel 正确识别中文的最低成本手段。语言字段我刻意没有直接随机赋值而是通过国家映射出来这模拟了真实数据里“字段间有依赖关系”的情况。年份范围控制在 1980 到 2024时长控制在 90 到 150 分钟预算和票房保持正相关性这些边界设定让你的数据看起来像真的而不是一眼假的随机数。如果你想调整数据量把这个脚本里的range(1, 301)改成别的数字就行关联表的数据量请继续看 3.2 节怎么跟着扩。3.2 有公开数据集时三遍清洗再入库如果你确实找到了合适的公开数据别直接往数据库里灌先做三遍清洗。第一遍处理编码和空值第二遍处理类型和去重第三遍检查关联完整性。我见过太多人把数据导进去之后一跑统计发现 1950 年出现了一部时长 0 分钟的电影就是因为跳过了第一遍。# clean_data.py —— 把原始 CSV 清洗成入库标准格式 import pandas as pd df pd.read_csv(raw_movies.csv, encodingutf-8-sig) # 第一遍空值与编码 df df.dropna(subset[title, year]) df df[df[title].str.strip() ! ] # 第二遍类型强转 异常值过滤 df[year] pd.to_numeric(df[year], errorscoerce).astype(Int64) df[duration_min] pd.to_numeric(df[duration_min], errorscoerce) df df[(df[year] 1888) (df[year] 2024)] df df[(df[duration_min].isna()) | (df[duration_min].between(30, 300))] # 第三遍去重 df df.drop_duplicates(subset[title, year], keepfirst) df.to_csv(clean_movies.csv, indexFalse, encodingutf-8-sig)这段代码的每一遍都对应一个真实场景里的高频问题。pd.to_numeric加errorscoerce会把“1990年”这种混入了汉字的脏数据转成缺失值而不是让程序直接报错astype(Int64)是 pandas 里能保留 NaN 的整数类型直接用int会在空值时崩溃。年份过滤的下限 1888 是电影史公认的第一部电影诞生年份低于这个数字的数据一定有问题。去重逻辑用的是title year组合而不是只看标题。因为不同国家完全可能存在同名电影比如经典的“翻拍同名”只看标题会误删。keepfirst保证重名数据留下第一行丢掉后续所有重复行。这一步做完数据才具备入库的基本资格。3.3 把数据组织成文件数据集交付物的标准姿势很多人在交数据集的环节犯懒直接把 CSV 往压缩包里一扔。我一般会组织成data/raw/、data/clean/、data/processed/三层结构原始数据放 raw清洗脚本输出放 clean最终导入数据库的关联文件放 processed。每一层配一个README.md写明字段含义、编码格式、每张表的行数。这份说明本身在答辩时就是加分项它证明你不是只会跑通代码而是对数据的生命周期有意识。processed 目录里需要额外放两个关联文件电影-类型关联表、电影-导演关联表。这两个文件的数据量不是电影数的 1 倍而是取决于每部电影挂几个类型、几个导演模拟真实世界时每部电影挂 14 个类型、12 个导演比较合理。生成方式就是在 3.1 的脚本里再加一层随机分配控制好movie_id的范围不要超出主表即可。4. 数据分析不是炫技四段代码做出答辩能讲的结论4.1 连接数据库的公共方法一个 db.py 打通所有查询数据分析的第一步是统一的数据库访问入口。把连接和查询封装成一个公共模块后面所有分析脚本都用它既避免了每写一段分析就复制一遍连接代码也让整个项目看起来有一个“系统”的架构。这个模块非常简单但很多人会忽略参数化查询直接用 f-string 拼 SQL这是比较危险的习惯。# db.py —— 公共数据库访问模块 import sqlite3 DB_PATH film.db def get_conn(): conn sqlite3.connect(DB_PATH) conn.row_factory sqlite3.Row # 让查询结果支持按列名访问 return conn def query_all(sql, params()): conn get_conn() rows conn.execute(sql, params).fetchall() conn.close() return rowsconn.row_factory sqlite3.Row这行的价值在于返回的每一行可以像字典一样用row[title]取字段而不是记住第几列是标题。query_all接收sql和params两个参数SQL 里的?占位符由 sqlite3 负责转义数据里有单引号、百分号都不会破坏语句结构。这一点在后面所有分析脚本里都会反复使用。4.2 评分分布与年份趋势让 matplotlib 输出能放进报告的图接下来是整份大作业里最出效果的部分评分分布直方图和年份产量趋势图。这两张图几乎能应对所有“你的数据分析做了什么”的提问因为评分分布讲质量、年份趋势讲数量两张图结合起来就是数据全景。# analysis.py —— 评分分布与年份趋势 import matplotlib.pyplot as plt import pandas as pd from db import query_all # 评分分布 score_rows query_all(SELECT rating_score FROM ratings) df_score pd.DataFrame(score_rows, columns[rating_score]) df_score[rating_score] df_score[rating_score].astype(float) plt.rcParams[font.sans-serif] [SimHei, Arial Unicode MS, sans-serif] plt.rcParams[axes.unicode_minus] False plt.figure(figsize(8, 5)) plt.hist(df_score[rating_score], bins9, range(1, 10), edgecolorwhite) plt.xlabel(评分) plt.ylabel(评分数) plt.title(用户评分分布) plt.tight_layout() plt.savefig(report/score_distribution.png, dpi150)评分分布这一段的调参重点是bins9和range(1, 10)。评分范围 1 到 10分 9 个箱子就把 12、23 这样的区间连续切出来不会出现边界的评分掉到图外。dpi150保证图片放进 Word 或 PDF 后依然清晰不是那种放大就糊的截图。年份趋势图需要先把movies.year按区间分组统计各年代上映数量。我的习惯是用 SQL 完成聚合Python 只负责画图因为 SQL 里的GROUP BY比 pandas 的groupby在答辩时更好解释——老师一问“数据在哪分组的”你可以直接指数据库而不是指代码。4.3 类型占比与导演产出两组能体现 JOIN 的高级查询类型占比是必须用 JOIN 才能算出来的统计直接查movies表拿不到任何类型信息。这里的核心点是统计单位是“电影-类型”记录数而不是“电影”数。# 类型 TOP10 占比 sql SELECT g.genre_name, COUNT(*) AS cnt FROM movie_genres mg JOIN genres g ON mg.genre_id g.genre_id GROUP BY g.genre_name ORDER BY cnt DESC LIMIT 10; type_rows query_all(sql) df_type pd.DataFrame(type_rows, columns[genre_name, cnt]) df_type[cnt] df_type[cnt].astype(int) plt.figure(figsize(8, 5)) plt.bar(df_type[genre_name], df_type[cnt]) plt.xticks(rotation45) plt.tight_layout() plt.savefig(report/genre_top10.png, dpi150)这里 COUNT 统计的是关联记录数。一部电影同时挂“剧情”和“爱情”两个类型它会在“剧情”和“爱情”各被计数一次。这符合业务逻辑——类型占比反映的是类型标签的覆盖广度而不是电影数量的分配比例。如果你要算“每部电影的平均类型数”那就用COUNT(*) / COUNT(DISTINCT mg.movie_id)这两个口径的差别是答辩时的高频问题。导演产出分析看的是头部效应哪几位导演作品多、平均评分高。这个查询需要三表 JOIN同时用AVG(rating_score)做聚合正好把整份作业里最难的部分集中展示出来。记得在最终报告里截取查询结果的表格光说“我查了”没有说服力把前五行贴出来。5. 大作业避坑实录五个让数据系统翻车的经典问题5.1 中文乱码Excel 打开 CSV 全是乱码程序里读出来也是乱码现象生成的movies.csv用 Excel 打开后中文全是问号或乱码pandas 读回来再写入数据库查出来还是乱码。原因CSV 文件用的是 UTF-8 编码而老版本 Excel 默认按 GBK/ANSI 打开反过来如果数据源是 GBK 编码Python 默认读取方式又解不对。解决写入 CSV 时统一用encodingutf-8-sig读取时不要省略编码参数。数据库入库前先在 Python 里把全部字符串字段做一次.strip()和编码归一我习惯写成str(text).encode(utf-8).decode(utf-8)能提前炸掉大部分隐藏的非法字符。5.2 外键约束不生效删了电影评分记录却还删不掉现象在 SQLite 里执行DELETE FROM movies WHERE movie_id 10死活报错“外键约束失败”可你在建表时明明写了FOREIGN KEY。原因SQLite 有个反直觉的默认行为——外键约束默认是关闭的必须在每次连接后执行PRAGMA foreign_keys ON。没开这个开关你建表时的REFERENCES只是摆设数据随便乱插等到想删数据时才突然被拦住。解决get_conn() 里连接后立刻执行conn.execute(PRAGMA foreign_keys ON)并且建表 SQL 的第一行也写上。两条都加确保不管走哪条路径连接数据库外键都是开着的。这个问题极其隐蔽排查半天往往就栽在这句 PRAGMA 上。5.3 JOIN 结果翻倍类型占比加起来超过 100%现象在“类型占比”分析里把各类型百分比一加发现是 142%明显不对。原因一部电影挂了三个类型统计类型时它被计了三次。条形图里每个柱子的“记录数”本身没错但如果你把它当成“电影数”去解释总和必然超过 100%。解决分清统计口径。展示类型标签覆盖度就用COUNT(*)并明确标注单位是“记录数”展示电影数量就用COUNT(DISTINCT movie_id)。我在 4.3 节写的 SQL 用的是前者但代码注释里一定要说明白否则答辩时这个问题容易变成唯一被追问的点。5.4 数据写进去了查询查不到提交时机不对现象脚本执行完没有报错检查数据库文件也确认连接的是同一个路径但另一个脚本查不到刚才插入的记录。原因sqlite3 默认开启了事务执行INSERT或UPDATE后如果没有conn.commit()数据只停留在当前连接的内存视图里其他连接看不见。解决所有写操作最后都要conn.commit()或者用上下文管理器。我建议把写操作封装成一个函数函数末尾统一提交、统一关连接。只要保证“提交和关闭”永远成对出现这个坑就不会反复踩。5.5 换台电脑就跑不了数据库文件路径写死现象代码在自己电脑上一切正常拷到答辩机器上直接报错“no such table”因为程序找不到film.db文件了。原因代码里写的是相对路径sqlite3.connect(film.db)这个路径取决于命令行的工作目录而不是代码文件所在目录。换一台电脑工作目录一变连接就指向了一个不存在的空数据库文件。解决基于代码文件位置定位数据库路径用BASE_DIR os.path.dirname(os.path.abspath(__file__))再拼上DB_PATH os.path.join(BASE_DIR, data, film.db)。这样不管从哪个目录启动脚本数据库路径都稳定指向项目内部不会出现“代码对路径错”的尴尬。6. 文档与操作报告怎么收尾结构、ER 图和测试用例一个不少最后一段实操是文档说明与操作报告的整理。操作报告和论文不一样不需要大量理论铺垫但每一个小标题都要能回答“做了什么、怎么做的、结果如何”。我习惯用这个结构需求分析与功能设计、数据库设计附 ER 图、系统实现说明、测试记录、使用说明、心得体会。其中 ER 图是老师必看的内容用绘图工具画出六张表的关系即可核心是标清楚movie_genres和movie_directors两张桥表的多对多连接。测试记录不要写“测试全部通过”这种空话用一张表格列 45 个具体用例插入合法电影、插入重复电影、查询某年评分最高的电影、删除被评分引用的电影。每条记录对应的 SQL 执行结果和预期是否一致。这张表能让你的报告立刻和其他人拉开差距因为这已经不是“我做完了”而是“我验证过了”。实体关系示意文本版 movies 1 — n movie_genres n — 1 genres movies 1 — n movie_directors n — 1 directors movies 1 — n ratings使用说明部分请写清楚启动顺序先运行数据生成脚本再运行建表脚本然后运行导入脚本最后运行分析脚本生成图表。这一步看起来简单但很多人的文档省略了“先运行数据生成脚本”导致别人拿到代码后直接报错误以为程序有 bug。我现在的习惯是先按顺序跑一遍交付物里的全部脚本确认能复现结果再去整理文档。我在这里吃过大亏——曾经以为自己的代码没问题结果换台新电脑按 README 跑第一步就挂了。这套流程走完你手里的交付物就是完整的代码、数据库文件、数据集、图表、测试记录、操作报告。别把时间花在把 SQL 写得更花哨上数据干净、结构完整、文档对齐这三点才是拿高分最稳的路。希望帮到你。本文还有配套的精品资源点击获取
简介这是一套基于Python与MongoDB的WEB电影数据库课程设计完整方案面向计算机相关专业做数据库大作业、课设或初期项目演示的学生。内容覆盖数据导入与脱敏处理、基于Flask的前后端交互、用户观影记录检索、关键词查询、风格热门榜等核心功能并配有数据分析文档、E-R图、界面截图及操作报告适合从入门到进阶的Python开发者参考复用。共77个文件主要包括Python脚本、HTML/CSS/JS前端页面、Markdown文档、PNG/JPG截图和配置文件等压缩包仅4.96MB下载后可快速按目录定位源码、文档或数据集。已有359人学习浏览。资源为作者答辩平均96分的真实作业所有代码均测试通过除功能实现外还额外整理云服务器部署、MongoDB安装与副本集配置、docker排错思路、索引优化等环境搭建经验能有效减少踩坑成本值得作为完整课设模板借鉴。1. 一个电影数据库大作业的完整形态从数据到报告都有什么前两天有个同学拿着他的数据库大作业来找我说是“电影数据库的数据系统”代码写了大半但老师问他数据从哪来、怎么保证不重复、报告里要放什么他全卡住了。这种情况我见得很多——不是 SQL 没学会而是把大作业理解成了“写代码”忽略了后面的数据集、分析、文档和操作报告其实也是产品的一部分。这门课的大作业之所以选“电影数据库”是因为电影数据天然带多对多关系、带数值字段、带时间维度足够把范式、外键、聚合查询、可视化全串起来。合适的对象是那些需要交一份完整课程设计的人既要有能跑的 Python 代码又要有数据文件、分析图表和一份能直接打印的报告。这篇文章就顺着这个交付物的顺序讲选型、建表、造数、分析、避坑、写文档六段走完照着做就能凑齐一套能答辩的成果。2. 数据库选型与六张核心表为什么 SQLite 最适合课堂演示2.1 为什么 SQLite 比 MySQL 更适合答辩演示选型一句话如果你的课程没有强制指定数据库我的第一建议永远是 SQLite而不是 MySQL。原因很实在SQLite 是文件型数据库整个数据库就是一个 .db 文件U 盘拷走、换电脑打开、答辩现场演示全都不需要安装服务、配置账号密码、处理端口占用。这对课程设计场景是致命的省心你不需要在演示前半小时还在跟 MySQL 服务较劲。MySQL 的优势是“显得更企业级”但它带来的成本是你得让老师那边也能跑起来或者至少你演示的机器上服务别崩。很多翻车现场不是因为 SQL 写错而是 MySQL 连不上。SQLite 没有这个问题Python 标准库自带 sqlite3不需要装任何第三方包就能开搞。如果你的课程硬性要求 MySQL代码切换点其实很小。连接部分从sqlite3.connect(film.db)换成pymysql.connect(host..., user..., password...)占位符从?换成%s自增字段从AUTOINCREMENT换成AUTO_INCREMENT。其余的表结构、查询逻辑、数据分析代码全部通用。我会在下面的建表语句里标注这些差异点方便你两套都试。2.2 建库建表先定主表再补关联表一次写出六张表我一般把电影数据库拆成六张表这个规模刚好能展示“关系型数据库”的设计思路又不至于为了复杂而复杂movies存电影本体genres和movie_genres处理电影与类型的多对多directors和movie_directors处理导演的多对多ratings单独存打分记录把“用户评分”和“电影信息”彻底分开。-- 创建六张核心表SQLite 方言 PRAGMA foreign_keys ON; -- SQLite 默认不启用外键约束必须手动开 CREATE TABLE movies ( movie_id INTEGER PRIMARY KEY AUTOINCREMENT, title TEXT NOT NULL, year INTEGER NOT NULL, country TEXT, language TEXT, duration_min INTEGER, budget REAL, box_office REAL ); CREATE TABLE genres ( genre_id INTEGER PRIMARY KEY AUTOINCREMENT, genre_name TEXT UNIQUE NOT NULL ); CREATE TABLE movie_genres ( movie_id INTEGER NOT NULL, genre_id INTEGER NOT NULL, PRIMARY KEY (movie_id, genre_id), FOREIGN KEY (movie_id) REFERENCES movies(movie_id), FOREIGN KEY (genre_id) REFERENCES genres(genre_id) ); CREATE TABLE directors ( director_id INTEGER PRIMARY KEY AUTOINCREMENT, director_name TEXT NOT NULL, birth_year INTEGER ); CREATE TABLE movie_directors ( movie_id INTEGER NOT NULL, director_id INTEGER NOT NULL, PRIMARY KEY (movie_id, director_id), FOREIGN KEY (movie_id) REFERENCES movies(movie_id), FOREIGN KEY (director_id) REFERENCES directors(director_id) ); CREATE TABLE ratings ( rating_id INTEGER PRIMARY KEY AUTOINCREMENT, movie_id INTEGER NOT NULL, rating_score REAL NOT NULL CHECK (rating_score BETWEEN 1 AND 10), rating_time TEXT, user_id INTEGER, FOREIGN KEY (movie_id) REFERENCES movies(movie_id) );这段 SQL 里有几个设计是刻意的。movie_genres和movie_directors都是典型的“桥表”主键由两个外键联合组成这就在物理层面保证了“同一部电影不会重复关联同一个类型或同一个导演”不用在业务代码里做去重判断。ratings表里的CHECK约束把评分钉死在 1 到 10 之间比你在 Python 里写if判断更可靠因为数据库层拦截了所有非法写入。budget和box_office我用REAL而不是INTEGER因为金额单位可能是“万美元”也可能是“元”用浮点能兼容小数。如果后续统计要用“票房减预算”算盈利浮点字段直接加减即可不用先做类型转换。这一整套表结构不依赖于某个特定数据库MySQL 下只需把AUTOINCREMENT换成AUTO_INCREMENT其余原样可用。2.3 索引与约束让统计查询不慢、数据不乱写完表结构紧接着要干的一件事是建索引。大作业的数据量通常是几百到几千条这个量级任何查询都快得感觉不到索引存在但答辩时老师经常会问“你的系统数据量大了怎么办”索引就是标准答案。在ratings.movie_id上建索引能让“按电影聚合评分”这种高频查询走索引扫描在movies.year上建索引能让所有按年份分组统计的查询稳定提速。CREATE INDEX idx_ratings_movie ON ratings(movie_id); CREATE INDEX idx_movies_year ON movies(year);建索引的同时别忘了给关键的字段加唯一约束。genres.genre_name已经加了UNIQUE这保证了“剧情”这个类型不会因为一次导入失误出现两行。同理在清洗数据时每部电影对应一个固定的movie_id关联表里的数据只增不删这样后面分析阶段做那些 JOIN 查询时才不会出现“类型占比超过 100%”这种让人摸不着头脑的结果。3. 用 Python 灌数据数据集构造与清洗的两个阶段3.1 没有现成数据时用脚本造一批贴近结构的仿真数据很多人在数据集这步就卡住了——网上找不到“同时带导演、类型、评分、票房、时长”的干净 CSV有版权的榜单数据又不敢直接往报告里贴。我的做法是自己造仿真数据数据格式完全按目标表结构来字段类型、取值范围、多对多关系全部模拟真实场景数量可调。把这套生成脚本放进交付物里老师反而会认为你理解了数据从哪里来。# generate_data.py —— 生成 300 部虚构电影信息并写入 CSV import csv import random random.seed(42) title_prefix [暗夜, 星际, 追光, 无声, 逆风, 零度, 迷城, 远山] title_suffix [行者, 边境, 回响, 航线, 黎明, 代码, 孤岛, 旅人] genres_pool [剧情, 动作, 科幻, 喜剧, 悬疑, 爱情, 动画, 纪录] director_pool [ (陈远航, 1960), (林默, 1975), (赵一舟, 1982), (苏晚晴, 1970), (高野, 1968), (周明川, 1988) ] countries [中国, 美国, 日本, 法国, 英国] def make_title(): return random.choice(title_prefix) random.choice(title_suffix) def make_movie_row(movie_id): return { movie_id: movie_id, title: make_title(), year: random.randint(1980, 2024), country: random.choice(countries), language: 未知, duration_min: random.randint(90, 150), budget: round(random.uniform(500, 8000), 2), box_office: round(random.uniform(800, 30000), 2), } def main(): movies [] for mid in range(1, 301): row make_movie_row(mid) row[language] {中国: 汉语, 美国: 英语, 日本: 日语, 法国: 法语, 英国: 英语}[row[country]] movies.append(row) with open(movies.csv, w, newline, encodingutf-8-sig) as f: writer csv.DictWriter(f, fieldnameslist(movies[0].keys())) writer.writeheader() writer.writerows(movies) if __name__ __main__: main()这里有两个参数值得说明。random.seed(42)让每次运行生成的数据完全一致这一点对答辩非常关键——昨天分析出的图表今天重新跑还能复现不会出现“老师你看我这个结果”的时候数字对不上。写 CSV 用了encodingutf-8-sig这个不是玄学是因为 Excel 直接打开 UTF-8 文件会乱码utf-8-sig带 BOM 头是让 Excel 正确识别中文的最低成本手段。语言字段我刻意没有直接随机赋值而是通过国家映射出来这模拟了真实数据里“字段间有依赖关系”的情况。年份范围控制在 1980 到 2024时长控制在 90 到 150 分钟预算和票房保持正相关性这些边界设定让你的数据看起来像真的而不是一眼假的随机数。如果你想调整数据量把这个脚本里的range(1, 301)改成别的数字就行关联表的数据量请继续看 3.2 节怎么跟着扩。3.2 有公开数据集时三遍清洗再入库如果你确实找到了合适的公开数据别直接往数据库里灌先做三遍清洗。第一遍处理编码和空值第二遍处理类型和去重第三遍检查关联完整性。我见过太多人把数据导进去之后一跑统计发现 1950 年出现了一部时长 0 分钟的电影就是因为跳过了第一遍。# clean_data.py —— 把原始 CSV 清洗成入库标准格式 import pandas as pd df pd.read_csv(raw_movies.csv, encodingutf-8-sig) # 第一遍空值与编码 df df.dropna(subset[title, year]) df df[df[title].str.strip() ! ] # 第二遍类型强转 异常值过滤 df[year] pd.to_numeric(df[year], errorscoerce).astype(Int64) df[duration_min] pd.to_numeric(df[duration_min], errorscoerce) df df[(df[year] 1888) (df[year] 2024)] df df[(df[duration_min].isna()) | (df[duration_min].between(30, 300))] # 第三遍去重 df df.drop_duplicates(subset[title, year], keepfirst) df.to_csv(clean_movies.csv, indexFalse, encodingutf-8-sig)这段代码的每一遍都对应一个真实场景里的高频问题。pd.to_numeric加errorscoerce会把“1990年”这种混入了汉字的脏数据转成缺失值而不是让程序直接报错astype(Int64)是 pandas 里能保留 NaN 的整数类型直接用int会在空值时崩溃。年份过滤的下限 1888 是电影史公认的第一部电影诞生年份低于这个数字的数据一定有问题。去重逻辑用的是title year组合而不是只看标题。因为不同国家完全可能存在同名电影比如经典的“翻拍同名”只看标题会误删。keepfirst保证重名数据留下第一行丢掉后续所有重复行。这一步做完数据才具备入库的基本资格。3.3 把数据组织成文件数据集交付物的标准姿势很多人在交数据集的环节犯懒直接把 CSV 往压缩包里一扔。我一般会组织成data/raw/、data/clean/、data/processed/三层结构原始数据放 raw清洗脚本输出放 clean最终导入数据库的关联文件放 processed。每一层配一个README.md写明字段含义、编码格式、每张表的行数。这份说明本身在答辩时就是加分项它证明你不是只会跑通代码而是对数据的生命周期有意识。processed 目录里需要额外放两个关联文件电影-类型关联表、电影-导演关联表。这两个文件的数据量不是电影数的 1 倍而是取决于每部电影挂几个类型、几个导演模拟真实世界时每部电影挂 14 个类型、12 个导演比较合理。生成方式就是在 3.1 的脚本里再加一层随机分配控制好movie_id的范围不要超出主表即可。4. 数据分析不是炫技四段代码做出答辩能讲的结论4.1 连接数据库的公共方法一个 db.py 打通所有查询数据分析的第一步是统一的数据库访问入口。把连接和查询封装成一个公共模块后面所有分析脚本都用它既避免了每写一段分析就复制一遍连接代码也让整个项目看起来有一个“系统”的架构。这个模块非常简单但很多人会忽略参数化查询直接用 f-string 拼 SQL这是比较危险的习惯。# db.py —— 公共数据库访问模块 import sqlite3 DB_PATH film.db def get_conn(): conn sqlite3.connect(DB_PATH) conn.row_factory sqlite3.Row # 让查询结果支持按列名访问 return conn def query_all(sql, params()): conn get_conn() rows conn.execute(sql, params).fetchall() conn.close() return rowsconn.row_factory sqlite3.Row这行的价值在于返回的每一行可以像字典一样用row[title]取字段而不是记住第几列是标题。query_all接收sql和params两个参数SQL 里的?占位符由 sqlite3 负责转义数据里有单引号、百分号都不会破坏语句结构。这一点在后面所有分析脚本里都会反复使用。4.2 评分分布与年份趋势让 matplotlib 输出能放进报告的图接下来是整份大作业里最出效果的部分评分分布直方图和年份产量趋势图。这两张图几乎能应对所有“你的数据分析做了什么”的提问因为评分分布讲质量、年份趋势讲数量两张图结合起来就是数据全景。# analysis.py —— 评分分布与年份趋势 import matplotlib.pyplot as plt import pandas as pd from db import query_all # 评分分布 score_rows query_all(SELECT rating_score FROM ratings) df_score pd.DataFrame(score_rows, columns[rating_score]) df_score[rating_score] df_score[rating_score].astype(float) plt.rcParams[font.sans-serif] [SimHei, Arial Unicode MS, sans-serif] plt.rcParams[axes.unicode_minus] False plt.figure(figsize(8, 5)) plt.hist(df_score[rating_score], bins9, range(1, 10), edgecolorwhite) plt.xlabel(评分) plt.ylabel(评分数) plt.title(用户评分分布) plt.tight_layout() plt.savefig(report/score_distribution.png, dpi150)评分分布这一段的调参重点是bins9和range(1, 10)。评分范围 1 到 10分 9 个箱子就把 12、23 这样的区间连续切出来不会出现边界的评分掉到图外。dpi150保证图片放进 Word 或 PDF 后依然清晰不是那种放大就糊的截图。年份趋势图需要先把movies.year按区间分组统计各年代上映数量。我的习惯是用 SQL 完成聚合Python 只负责画图因为 SQL 里的GROUP BY比 pandas 的groupby在答辩时更好解释——老师一问“数据在哪分组的”你可以直接指数据库而不是指代码。4.3 类型占比与导演产出两组能体现 JOIN 的高级查询类型占比是必须用 JOIN 才能算出来的统计直接查movies表拿不到任何类型信息。这里的核心点是统计单位是“电影-类型”记录数而不是“电影”数。# 类型 TOP10 占比 sql SELECT g.genre_name, COUNT(*) AS cnt FROM movie_genres mg JOIN genres g ON mg.genre_id g.genre_id GROUP BY g.genre_name ORDER BY cnt DESC LIMIT 10; type_rows query_all(sql) df_type pd.DataFrame(type_rows, columns[genre_name, cnt]) df_type[cnt] df_type[cnt].astype(int) plt.figure(figsize(8, 5)) plt.bar(df_type[genre_name], df_type[cnt]) plt.xticks(rotation45) plt.tight_layout() plt.savefig(report/genre_top10.png, dpi150)这里 COUNT 统计的是关联记录数。一部电影同时挂“剧情”和“爱情”两个类型它会在“剧情”和“爱情”各被计数一次。这符合业务逻辑——类型占比反映的是类型标签的覆盖广度而不是电影数量的分配比例。如果你要算“每部电影的平均类型数”那就用COUNT(*) / COUNT(DISTINCT mg.movie_id)这两个口径的差别是答辩时的高频问题。导演产出分析看的是头部效应哪几位导演作品多、平均评分高。这个查询需要三表 JOIN同时用AVG(rating_score)做聚合正好把整份作业里最难的部分集中展示出来。记得在最终报告里截取查询结果的表格光说“我查了”没有说服力把前五行贴出来。5. 大作业避坑实录五个让数据系统翻车的经典问题5.1 中文乱码Excel 打开 CSV 全是乱码程序里读出来也是乱码现象生成的movies.csv用 Excel 打开后中文全是问号或乱码pandas 读回来再写入数据库查出来还是乱码。原因CSV 文件用的是 UTF-8 编码而老版本 Excel 默认按 GBK/ANSI 打开反过来如果数据源是 GBK 编码Python 默认读取方式又解不对。解决写入 CSV 时统一用encodingutf-8-sig读取时不要省略编码参数。数据库入库前先在 Python 里把全部字符串字段做一次.strip()和编码归一我习惯写成str(text).encode(utf-8).decode(utf-8)能提前炸掉大部分隐藏的非法字符。5.2 外键约束不生效删了电影评分记录却还删不掉现象在 SQLite 里执行DELETE FROM movies WHERE movie_id 10死活报错“外键约束失败”可你在建表时明明写了FOREIGN KEY。原因SQLite 有个反直觉的默认行为——外键约束默认是关闭的必须在每次连接后执行PRAGMA foreign_keys ON。没开这个开关你建表时的REFERENCES只是摆设数据随便乱插等到想删数据时才突然被拦住。解决get_conn() 里连接后立刻执行conn.execute(PRAGMA foreign_keys ON)并且建表 SQL 的第一行也写上。两条都加确保不管走哪条路径连接数据库外键都是开着的。这个问题极其隐蔽排查半天往往就栽在这句 PRAGMA 上。5.3 JOIN 结果翻倍类型占比加起来超过 100%现象在“类型占比”分析里把各类型百分比一加发现是 142%明显不对。原因一部电影挂了三个类型统计类型时它被计了三次。条形图里每个柱子的“记录数”本身没错但如果你把它当成“电影数”去解释总和必然超过 100%。解决分清统计口径。展示类型标签覆盖度就用COUNT(*)并明确标注单位是“记录数”展示电影数量就用COUNT(DISTINCT movie_id)。我在 4.3 节写的 SQL 用的是前者但代码注释里一定要说明白否则答辩时这个问题容易变成唯一被追问的点。5.4 数据写进去了查询查不到提交时机不对现象脚本执行完没有报错检查数据库文件也确认连接的是同一个路径但另一个脚本查不到刚才插入的记录。原因sqlite3 默认开启了事务执行INSERT或UPDATE后如果没有conn.commit()数据只停留在当前连接的内存视图里其他连接看不见。解决所有写操作最后都要conn.commit()或者用上下文管理器。我建议把写操作封装成一个函数函数末尾统一提交、统一关连接。只要保证“提交和关闭”永远成对出现这个坑就不会反复踩。5.5 换台电脑就跑不了数据库文件路径写死现象代码在自己电脑上一切正常拷到答辩机器上直接报错“no such table”因为程序找不到film.db文件了。原因代码里写的是相对路径sqlite3.connect(film.db)这个路径取决于命令行的工作目录而不是代码文件所在目录。换一台电脑工作目录一变连接就指向了一个不存在的空数据库文件。解决基于代码文件位置定位数据库路径用BASE_DIR os.path.dirname(os.path.abspath(__file__))再拼上DB_PATH os.path.join(BASE_DIR, data, film.db)。这样不管从哪个目录启动脚本数据库路径都稳定指向项目内部不会出现“代码对路径错”的尴尬。6. 文档与操作报告怎么收尾结构、ER 图和测试用例一个不少最后一段实操是文档说明与操作报告的整理。操作报告和论文不一样不需要大量理论铺垫但每一个小标题都要能回答“做了什么、怎么做的、结果如何”。我习惯用这个结构需求分析与功能设计、数据库设计附 ER 图、系统实现说明、测试记录、使用说明、心得体会。其中 ER 图是老师必看的内容用绘图工具画出六张表的关系即可核心是标清楚movie_genres和movie_directors两张桥表的多对多连接。测试记录不要写“测试全部通过”这种空话用一张表格列 45 个具体用例插入合法电影、插入重复电影、查询某年评分最高的电影、删除被评分引用的电影。每条记录对应的 SQL 执行结果和预期是否一致。这张表能让你的报告立刻和其他人拉开差距因为这已经不是“我做完了”而是“我验证过了”。实体关系示意文本版 movies 1 — n movie_genres n — 1 genres movies 1 — n movie_directors n — 1 directors movies 1 — n ratings使用说明部分请写清楚启动顺序先运行数据生成脚本再运行建表脚本然后运行导入脚本最后运行分析脚本生成图表。这一步看起来简单但很多人的文档省略了“先运行数据生成脚本”导致别人拿到代码后直接报错误以为程序有 bug。我现在的习惯是先按顺序跑一遍交付物里的全部脚本确认能复现结果再去整理文档。我在这里吃过大亏——曾经以为自己的代码没问题结果换台新电脑按 README 跑第一步就挂了。这套流程走完你手里的交付物就是完整的代码、数据库文件、数据集、图表、测试记录、操作报告。别把时间花在把 SQL 写得更花哨上数据干净、结构完整、文档对齐这三点才是拿高分最稳的路。希望帮到你。本文还有配套的精品资源点击获取
