企业官网建设流程全解析

简介：这套员工信息管理系统源码包来自数据库课程设计，基于Python和MySQL开发，适合高校计算机专业学生在课程设计、毕业设计或实训项目中参考。资源共9个文件，体积约6.71MB，包含2个Python源程序、2份doc课程设计报告与说明文档、4张png设计图（E-R图、数据流图及系统运行界面）以及1个md说明文件，类型覆盖代码、文档和图表，便于对照学习。项目通过pymysql库连接MySQL，实现了员工档案的新增、查询、修改、删除，以及部门信息管理等典型功能，完整演示了从数据库设计、SQL语句编写到Python业务逻辑实现的流程。文档和图片能帮助理解表结构、数据流向和界面设计，源码则可以直接运行和扩展。已有4343人学习下载，对于需要快速完成员工信息管理系统课设的读者，这份资源提供了可复用的代码模板和清晰的文档思路，能够节省大量从零搭建的时间。

1. 为什么用 Python + MySQL 做员工信息管理系统：课设需求与技术选型

“数据库课程设计”这个题目每年都有一批人卡壳，不是不会写 SQL，而是不知道系统要拆几个模块、数据落成几张表、代码长什么样才算完整。真正动手建库时，很多人反而在第一行连接代码就卡住了。

这套员工信息管理系统只用了 Python 和 MySQL 两样技术，Python 负责业务逻辑与命令行交互，MySQL 负责数据落地。Python 语法友好、单文件能跑通，MySQL 是导师最熟悉的数据库，看表结构就知道你在做什么，是课设里最稳的组合。

系统走控制台菜单交互，不依赖前端框架，把考察重点放在数据组织、SQL 编写和事务处理上。适合要交数据库课程设计的学生，也适合想快速搭一套完整参考系统的开发者。下面一条线拆完，照着改就能交。

2. 需求分析与总体架构设计：四大功能模块与五张核心表的职责划分

课设和真实项目的差别在于，范围要小但链条要完整。员工信息管理系统看起来简单，真要覆盖“录入—维护—查询—统计”这条链路，需求就得先拆清楚，否则建表时就会漏字段，写代码时又会发现功能互相打架。这一章先落需求清单，再定架构，最后把五张表的结构定死，后续所有代码都围着这份设计走。

2.1 需求拆解：从课设任务书到可落地的功能清单

任务书里常见的要求是“实现员工信息的录入、修改、删除、查询和统计”，这句话只能算方向，不能直接开工。我在拆需求时通常会把每个功能对应到具体的数据库操作，确保每个菜单项都有明确的 SQL 支撑，也方便答辩时回答“这个功能是怎么实现的”。

四个模块对应四个独立的代码文件，菜单在入口文件里统一调度。逻辑上每个模块只做一件事：登录模块只校验身份，员工模块只处理单条员工数据的增删改，统计模块只做聚合查询。这样拆的好处很明显，答辩时导师问“模块化怎么体现”，直接说文件划分和调用关系就能答清楚。

2.2 总体架构：展示层、业务层、数据层的三层划分

整个系统按三层结构组织：最上层是控制台菜单和输入输出，中间层是业务逻辑，最底层是数据库操作。三层之间不交叉，展示层不会直接写 SQL，业务层不负责打印菜单，数据层只提供连接和执行查询的通道。

调用关系是单向的：main.py 根据用户输入调用 auth 或 employee 或 stats，这三个模块通过 db.py 拿连接执行 SQL，执行完把结果返回展示层。这里有个容易被忽略的点：db.py 是唯一允许出现 pymysql 操作的地方，其他模块只调用它提供的函数，这样万一要换数据库或者改连接方式，只动一个文件。

2.3 数据库设计：五张核心表的建表 SQL

表结构直接决定代码好不好写，也决定答辩时能不能讲出设计依据。这里设计了五张表：admin_user 管登录，department 管部门，employee 存员工主体信息，attendance 存考勤记录，salary 存工资记录。核心是 employee 表，另外四张围着它转。

CREATE DATABASE IF NOT EXISTS employee_db DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; USE employee_db; CREATE TABLE admin_user ( id INT AUTO_INCREMENT PRIMARY KEY, username VARCHAR(30) NOT NULL UNIQUE, password_hash CHAR(32) NOT NULL, create_time DATETIME DEFAULT CURRENT_TIMESTAMP ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; CREATE TABLE department ( dept_id INT AUTO_INCREMENT PRIMARY KEY, dept_name VARCHAR(50) NOT NULL UNIQUE, manager VARCHAR(20), phone VARCHAR(20) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; CREATE TABLE employee ( emp_id INT AUTO_INCREMENT PRIMARY KEY, emp_no VARCHAR(20) NOT NULL UNIQUE, name VARCHAR(20) NOT NULL, gender CHAR(2) DEFAULT '男', birthday DATE, phone VARCHAR(20), email VARCHAR(50), dept_id INT NOT NULL, hire_date DATE, salary DECIMAL(10,2) DEFAULT 0.00, status TINYINT DEFAULT 1 COMMENT '1在职 0离职', CONSTRAINT fk_emp_dept FOREIGN KEY (dept_id) REFERENCES department(dept_id) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; CREATE TABLE attendance ( att_id INT AUTO_INCREMENT PRIMARY KEY, emp_id INT NOT NULL, work_date DATE NOT NULL, check_in TIME, check_out TIME, status VARCHAR(10) DEFAULT '正常', CONSTRAINT fk_att_emp FOREIGN KEY (emp_id) REFERENCES employee(emp_id), UNIQUE KEY uk_emp_date (emp_id, work_date) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; CREATE TABLE salary ( sal_id INT AUTO_INCREMENT PRIMARY KEY, emp_id INT NOT NULL, month CHAR(7) NOT NULL COMMENT '格式 2025-01', base_salary DECIMAL(10,2) DEFAULT 0.00, bonus DECIMAL(10,2) DEFAULT 0.00, deduction DECIMAL(10,2) DEFAULT 0.00, final_salary DECIMAL(10,2) DEFAULT 0.00, CONSTRAINT fk_sal_emp FOREIGN KEY (emp_id) REFERENCES employee(emp_id), UNIQUE KEY uk_emp_month (emp_id, month) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

建表脚本一次性执行完，初始化管理员账号和几个测试部门也放在同一个 SQL 文件里，方便课程设计报告里附上“数据初始化脚本”这一节。注意所有表都指定了 ENGINE=InnoDB，因为 InnoDB 支持事务和外键，这是答辩时一定会被问到的点。

2.4 关键字段与约束设计说明

这里几个设计决策是答辩的加分项。第一，员工表用 emp_id 自增主键，同时给 emp_no 加唯一约束，工号是业务上唯一的标识，主键是内部使用，两者分离可以避免工号修改时牵连外键。第二，工资字段用 DECIMAL(10,2) 而不是 FLOAT，金额用浮点会累积精度误差，这是数据库设计的经典考点。第三，status 字段做软删除标记，离职不物理删行，保留历史数据。

表间关系是典型的 1:N：部门对员工一对多，员工对考勤一对多，员工对工资一对多。员工表里只存 dept_id 不冗余部门名称，符合第三范式的要求，这也是“为什么这样设计”的标准答案。考勤表的唯一键 (emp_id, work_date) 保证同一天不能重复打卡，工资表的唯一键 (emp_id, month) 保证一个月只能有一条工资记录，两个唯一键都是靠约束兜底，比代码里先查后插更可靠。

3. 核心模块代码实现：连接封装、登录鉴权与员工 CRUD 落地

设计稿定了就要落到代码。这一章按“连接工具 → 登录鉴权 → CRUD → 软删除”的顺序写，每一段代码都是能直接复制到项目里跑通的，重点不是炫技，而是让课设代码看起来结构清晰、每行都有存在的理由。

3.1 数据库连接模块：配置集中管理与连接工具封装

连接信息如果散落在各个文件里，改一次密码要翻三个文件，这是新手项目最常见的坏味道。做法是把连接参数统一放到 config.py，db.py 只负责“拿连接”和“关连接”两件事。

# config.py DB_CONFIG = { "host": "localhost", "port": 3306, "user": "root", "password": "123456", "database": "employee_db", "charset": "utf8mb4" }

# db.py import pymysql from config import DB_CONFIG def get_conn(): return pymysql.connect( host=DB_CONFIG["host"], port=DB_CONFIG["port"], user=DB_CONFIG["user"], password=DB_CONFIG["password"], database=DB_CONFIG["database"], charset=DB_CONFIG["charset"], cursorclass=pymysql.cursors.DictCursor, # 查询结果返回字典，按列名取值 autocommit=False # 关闭自动提交，事务由业务代码控制 ) def close_all(conn, cursor): if cursor: cursor.close() if conn: conn.close()

cursorclass 指定 DictCursor 后，fetchone() 返回的是字典，可以用 row["name"] 取值，比默认的元组下标好读得多。autocommit=False 是刻意的，插入、修改必须显式 commit 才生效，配合异常分支的 rollback，才能讲清楚事务处理。close_all 放在 finally 里调用，保证连接一定会被释放，这一条直接规避后面要讲的“连接泄漏”问题。

3.2 登录鉴权模块：密码哈希与登录状态控制

登录模块的逻辑很简单：输入用户名密码，查 admin_user 表，匹配成功就进入主菜单。但密码不能明文存储，也不能用字符串拼接 SQL。下面的写法把密码做 MD5 哈希后落库，查询全部走参数化。

# auth.py import hashlib from db import get_conn, close_all def md5_password(pwd: str) -> str: """MD5 哈希，用于密码存储和校验""" return hashlib.md5(pwd.encode("utf-8")).hexdigest() def login(): conn = get_conn() cursor = conn.cursor() try: username = input("请输入用户名: ").strip() password = md5_password(input("请输入密码: ").strip()) sql = "SELECT id, username FROM admin_user WHERE username=%s AND password=%s" cursor.execute(sql, (username, password)) user = cursor.fetchone() if user: print(f"登录成功，欢迎 {user['username']}") return user print("用户名或密码错误") return None finally: close_all(conn, cursor)

踩过的坑是新手容易把 MD5 写在 SELECT 外面然后和数据库里存的明文比，两边永远对不上。正确口径是“注册时存哈希，登录时算哈希再比哈希”。初始化管理员数据时用下面这句：INSERT INTO admin_user (username, password_hash) VALUES ('admin', MD5('123456'))。md5 在真实生产环境已经不够安全，课设里用它展示“密码不能明文落库”的思路即可，代码注释里写明可换 bcrypt。

3.3 员工新增与修改：参数化 INSERT / UPDATE 的完整写法

员工新增是最能体现基本功的功能，字段多、类型杂、还要处理异常。下面这段把输入、校验、执行、提交、回滚串成一条完整链路。

# employee.py from db import get_conn, close_all def add_employee(): conn = get_conn() cursor = conn.cursor() try: emp_no = input("请输入工号: ").strip() name = input("请输入姓名: ").strip() gender = input("请输入性别(男/女): ").strip() dept_id = int(input("请输入部门ID: ").strip()) salary = float(input("请输入工资: ").strip()) sql = """INSERT INTO employee (emp_no, name, gender, dept_id, salary, status) VALUES (%s, %s, %s, %s, %s, 1)""" cursor.execute(sql, (emp_no, name, gender, dept_id, salary)) conn.commit() print(f"员工 {name} 添加成功，影响行数 {cursor.rowcount}") except ValueError: conn.rollback() print("输入格式有误，部门ID和工资必须是数字") except Exception as e: conn.rollback() print(f"添加失败：{e}") finally: close_all(conn, cursor)

注意两个细节：所有用户输入都先 strip() 去掉头尾空格，防止“工号带了空格导致唯一约束冲突”这种玄学问题；int() 和 float() 包在 try 里，用户输入非数字时不会让整个程序崩溃。修改员工用 UPDATE employee SET name=%s, phone=%s WHERE emp_id=%s，套路完全一样，只多一个 WHERE 条件定位记录。

提示：execute 的第二个参数传元组，哪怕只有一个占位符也要写成 (value, )，逗号不能省，这是 Python 语法里最容易漏的地方。

3.4 离职处理：用软删除代替物理删除

删除功能如果用 DELETE，员工历史记录就没了，后面考勤和工资表的外键还会变成孤儿数据。更稳的做法是把 status 从 1 改成 0，查询默认只看在职员工，离职数据保留在库里。

def remove_employee(emp_id: int): conn = get_conn() cursor = conn.cursor() try: sql = "UPDATE employee SET status=0 WHERE emp_id=%s AND status=1" cursor.execute(sql, (emp_id,)) conn.commit() if cursor.rowcount == 0: print("该员工不存在或已离职") else: print(f"员工 {emp_id} 已标记为离职") except Exception as e: conn.rollback() print(f"操作失败：{e}") finally: close_all(conn, cursor)

软删除在答辩时很好讲：一是数据可追溯，二是保留考勤工资历史，三是只改一个字段成本低。对应的查询语句统一加上 AND status=1，列表页就不会出现已离职人员。

4. 查询统计与报表输出：多条件筛选、分页与部门人数统计的做法

查询统计是课设里差异化最大的部分，做得好的能直接把评分拉高。这一章解决三个实际问题：条件可有可无时 SQL 怎么写、数据多了怎么分页、统计结果怎么让导师一眼看到亮点。

4.1 多条件组合查询：动态 SQL 与参数校验

用户可能只输入姓名，也可能同时输入部门加最低工资，条件数量不确定。动态拼接 WHERE 子句的标准做法是维护一个参数列表，只有用户输入了才追加条件。

def search_employee(): conn = get_conn() cursor = conn.cursor() try: name = input("姓名(直接回车跳过): ").strip() dept_id = input("部门ID(直接回车跳过): ").strip() min_salary = input("最低工资(直接回车跳过): ").strip() sql = "SELECT * FROM employee WHERE status=1" params = [] if name: sql += " AND name LIKE %s" params.append(f"%{name}%") if dept_id: sql += " AND dept_id = %s" params.append(int(dept_id)) if min_salary: sql += " AND salary >= %s" params.append(float(min_salary)) cursor.execute(sql, params) rows = cursor.fetchall() if not rows: print("没有匹配的记录") for r in rows: print(f"{r['emp_no']} {r['name']} 部门{r['dept_id']} 工资{r['salary']}") finally: close_all(conn, cursor)

WHERE status=1 后面跟 AND 是常用技巧，叫“拼条件前先放一个恒真条件”，避免判断“是不是第一个条件要不要加 WHERE”的麻烦。更关键的是，动态拼的是 SQL 结构，值永远走 %s 参数化，用户输入再花哨也不会被当成 SQL 执行。LIKE 查询记得自己拼好 % 再传给参数，不要在 SQL 里写 LIKE '%s%'，那会直接报错。

4.2 分页查询：LIMIT / OFFSET 与页码边界

数据超过几十条后，一次性查出来既不美观也不好讲解。分页查询要处理两件事：算总页数、判断页码越界。

def page_query(page: int, page_size: int = 5): conn = get_conn() cursor = conn.cursor() try: cursor.execute("SELECT COUNT(*) AS cnt FROM employee WHERE status=1") total = cursor.fetchone()["cnt"] total_pages = (total + page_size - 1) // page_size if page < 1 or page > total_pages: print(f"页码越界，共 {total_pages} 页") return sql = """SELECT emp_no, name, dept_id, salary FROM employee WHERE status=1 ORDER BY emp_id LIMIT %s OFFSET %s""" cursor.execute(sql, (page_size, (page - 1) * page_size)) for r in cursor.fetchall(): print(f"{r['emp_no']} {r['name']} 部门{r['dept_id']} 工资{r['salary']}") print(f"第 {page}/{total_pages} 页，共 {total} 条") finally: close_all(conn, cursor)

总页数用 (total + page_size - 1) // page_size 向上取整，这是整数分页的标准写法。OFFSET 是 (page-1) * page_size，第 1 页偏移 0，第 2 页偏移 5，这条公式背下来就不会错。判断越界放在查询之前，否则用户输了个 999 页，数据库白查一遍，答辩时提一句“先算页数再决定要不要查”就能体现细节。

4.3 部门人数统计：GROUP BY 与左连接

统计每个部门多少人，核心是 GROUP BY，但直接用员工表分组会漏掉没有人的空部门。要在答辩中讲出水平，就得用 LEFT JOIN。

def dept_stat(): conn = get_conn() cursor = conn.cursor() try: sql = """SELECT d.dept_name, COUNT(e.emp_id) AS emp_count FROM department d LEFT JOIN employee e ON d.dept_id = e.dept_id AND e.status=1 GROUP BY d.dept_id, d.dept_name ORDER BY emp_count DESC""" cursor.execute(sql) for r in cursor.fetchall(): print(f"{r['dept_name']}: {r['emp_count']} 人") finally: close_all(conn, cursor)

LEFT JOIN 保证 department 表每行都出现，没人的部门 COUNT(e.emp_id) 结果是 0。注意 ON 条件里带了 e.status=1，把已离职的人排除在统计口径外。GROUP BY 的列要和 SELECT 里出现的非聚合列一致，这里按 dept_id 和 dept_name 两个字段分组，MySQL 的 ONLY_FULL_GROUP_BY 模式才不会报错。

4.4 报表输出：统计结果导出 CSV

课设加分项是把统计结果落成文件，导师不用看控制台滚动，直接打开 Excel 就能检查。用 Python 标准库 csv 写文件，二十行以内搞定。

import csv def export_dept_stat(): conn = get_conn() cursor = conn.cursor() try: cursor.execute("""SELECT d.dept_name, COUNT(e.emp_id) AS emp_count FROM department d LEFT JOIN employee e ON d.dept_id = e.dept_id AND e.status=1 GROUP BY d.dept_id, d.dept_name""") rows = cursor.fetchall() with open("dept_stat.csv", "w", newline="", encoding="utf-8-sig") as f: writer = csv.writer(f) writer.writerow(["部门名称", "员工人数"]) for r in rows: writer.writerow([r["dept_name"], r["emp_count"]]) print("已导出 dept_stat.csv") finally: close_all(conn, cursor)

编码用 utf-8-sig 而不是 utf-8，因为 Excel 打开 UTF-8 无 BOM 的 CSV 会乱码，这是导出功能最容易翻车的点。csv.writer 配 newline="" 是 Python 官方推荐写法，避免 Windows 下多出空行。这一小段代码放进报告里，页面效果远好于贴一堆打印语句。

5. 常见问题与避坑指南：课设开发中最容易翻车的五个点

下面五个问题是我见过出现频率最高的，基本覆盖了从建库到交付的完整链路。每条都按“现象 → 原因 → 解决”写，开发时踩到任何一个，回来对照就能定位。

5.1 中文乱码：三处字符集不一致

现象：插入中文后查询显示成 ?? 或者一堆看不懂的符号，控制台输出也被搅乱。

原因：字符集不一致。MySQL 服务端默认可能是 latin1，建库时没指定字符集，Python 连接也没传 charset，三处各用各的编码，中文在转换过程中直接丢失。很多同学只改一处，问题依旧，以为是玄学。

解决：建库时统一指定 utf8mb4，连接参数里加 charset="utf8mb4"，如果还不行，检查 my.ini 里 [mysqld] 段加 character-set-server=utf8mb4 并重启服务。判断问题在哪一处，用命令行客户端插入一条中文再查，能显示就是 Python 这边没配好，不能显示就是库表字符集不对。

5.2 连接泄漏：Too many connections

现象：程序跑几次后突然报 pymysql.err.OperationalError: Too many connections，重启 MySQL 才好。

原因：每次调用 get_conn() 都新建连接，用完没关。MySQL 默认最多 151 个连接，课设的循环菜单跑几十次就满了。这是新手最容易犯的错，因为本地开发时前几次根本不报错，问题一直积累到临界点才爆发。

解决：所有操作统一走 try/finally，finally 里调 close_all(conn, cursor)。如果用的是 with conn.cursor() as cursor 写法，也要确认连接本身被关闭。写代码时记住一条规则：get_conn 和 close_all 必须成对出现，就像开文件必须配 close 一样，写完自查一遍。

5.3 SQL 注入：字符串拼接导致翻车

现象：在搜索框输入' OR '1'='1，查出全部员工数据，甚至把表删了。

原因：SQL 用了 f-string 直接拼用户输入。select * from employee where name = '{name}'这种写法，用户输入一旦包含单引号，SQL 语义就被改写，条件恒真，等于把数据库钥匙交出去了。课设里数据不重要，但这个坏习惯会被导师直接点名。

解决：全部改用参数化查询，占位符 %s，值通过 cursor.execute(sql, params) 传入，pymysql 会帮你做转义。注意表名、列名不能用占位符参数化，但这类场景在课设里很少出现，能用白名单校验的地方不要拼字符串。

5.4 事务没提交：数据改了查不到

现象：插入数据后程序显示“添加成功”，但换个窗口查询没有这条记录，或者程序重启后数据消失了。

原因：连接设置了 autocommit=False，执行 INSERT 后数据只存在当前事务里，没有 commit 就不落盘。有的同学只在某些函数里写了 commit，另一些函数漏了，于是功能时好时坏，非常误导排查方向。

解决：每个增删改操作成功路径上必须显式 commit，异常路径上必须 rollback。建议在写操作函数的最后、打印成功信息之前调 commit，固定位置写死，别想着“最后统一提交”。还有一个后悔药：实在不确定哪里漏了，可以把 pymysql.connect 的 autocommit 改成 True 临时救急，但答辩时要能说清两种模式的区别。

注意：fetchone() 返回 None 不代表出错，要区分“没查到数据”和“SQL 执行异常”，后者才需要进 except 分支。

5.5 日期与金额字段的类型坑

现象：生日和入职日期显示成“1999/1/1 00:00:00”，工资排序结果不对，1 万和 9999 的排序经常出乎意料。

原因：建表时把生日建成 VARCHAR，工资建成 FLOAT。字符串日期没法按大小比较，浮点金额有精度误差，排序和统计口径全是乱的。源头是建表时图省事，没按语义选类型。

解决：日期字段用 DATE，金额字段用 DECIMAL(10,2)。Python 这边写入日期时先处理成 'YYYY-MM-DD' 格式，读取到的 datetime 对象用 strftime 再展示。工资初始化一律用 Decimal 或两位小数浮点，不要从输入框直接拿原始字符串塞进数据库。

6. 项目验收与答辩技巧：从功能演示到提问预演

代码写完不等于能交差，课设的临门一脚是演示和答辩。我见过不少项目功能完整，但演示时没有测试数据、操作顺序混乱，导师看了十分钟还看不出系统做了什么。提前把流程和话术准备好，效果是完全不同的。

6.1 演示前必做的四步检查

第一步，重置数据库到干净状态，重新执行建表和初始化脚本，确保演示现场不会因为之前调试留下的脏数据翻车。第二步，预置三到五条有辨识度的测试数据，部门、工资、日期都要有点差异，这样演示查询统计时能看到不同结果。第三步，自己完整走一遍演示流程至少两遍，重点验证增删改查后数据的一致性——新增后能查到，离职后再查列表不出现。第四步，准备一份“后悔药”脚本，万一演示时误删了数据，一键恢复测试数据，不要现场手敲 SQL。

6.2 答辩高频提问与参考答案

答辩时被问住不用硬扛，承认设计局限比狡辩强，比如 MD5 的明文安全问题，可以说“真实项目会换成 bcrypt，课设重点是展示流程正确”，导师反而认可你的知识面。

6.3 收尾检查清单

最后用十分钟核对四件事：代码里不残留调试用的 print 和写死的路径；配置文件里数据库密码改成通用占位说明；报告里的表和实际建表语句完全一致；源码文件里包含建表 SQL、初始化数据、核心代码三部分。我从那以后每次带课设项目都会强制走一遍“重置数据 → 完整演示 → 问题预演”的流程，这个习惯帮我和学生避开了不少尴尬时刻，也把答辩的主动权拿回自己手里。

这套方案的完整源码、建表脚本和演示数据都是可以直接拿来改的，按第二章的表结构建库，再对照第三章和第四章的代码逐模块替换，就能拼出你自己的员工信息管理系统。希望帮到你。

本文还有配套的精品资源，点击获取