简介一份面向高校计算机专业学生的数据库课程设计文档主题为支持校园卡的食堂消费信息管理系统。文档按数据库设计六阶段展开需求分析明确学生、校园卡、食堂消费、财务部门等处理对象办卡、挂失、充值、消费查询、营业额统计等处理功能以及视图与用户授权的安全性要求概念设计给出E-R图、数据字典、数据流与存储结构逻辑设计将E-R图转化为学生、校园卡、充值、刷卡消费等关系模式并绘制功能模块图物理设计和实施阶段则涉及索引创建原则与C#代码片段。整个包为1个docx文档约540KB排版清晰、结构完整便于对照修改。已有218人学习下载既能帮助理解数据库需求分析到物理实现的全过程也可迁移至其他校园卡应用场景适合作为课程设计和大作业的参考蓝本。1. 这份食堂消费系统数据库设计文档值不值得当模板拿到一份 2014 年的数据库课程设计文档先别急着关掉。它涵盖需求分析、概念结构设计、逻辑结构设计、物理设计、实施阶段 Java 代码把数据库设计的五步流程完整走了一遍。对于正在做数据库原理课设、或者想快速搭一个「校园卡 食堂消费」场景的人来说这份资料能把「需求 → 数据字典 → E-R 图 → 关系模式 → 建表 → 代码」整个链路串起来。支持校园卡的食堂消费信息管理系统这类题目每年都有大量学生要做真正难的不是写代码而是把需求梳理清楚、把关系模式转对。这份文档正好可以作为模板直接改写适合三类人第一次做课程设计、不知道数据字典怎么写的新手想要一个标准化六个阶段的参考结构、懒得从零搭框架的人以及需要快速出成品、直接改表名和界面文字就能交差的老手。2. 需求分析到数据字典五类处理对象与字段的定义方式2.1 为什么需求分析阶段最值得抄很多课程设计一看就是流水账开头一堆背景然后直接甩出几张表。这份文档不一样它把需求分析拆成「目标 → 任务 → 处理对象 → 功能要求 → 安全性完整性要求」五个层次。你在答辩时被问「为什么这个表要有这个字段」答案就在数据字典里。处理对象划分得清楚学生基本信息、校园卡基本信息、食堂消费信息、财务部门信息、校园卡日常事务信息办卡、挂失、充值。每个对象对应几个数据项数据项再沉淀成数据字典这一套下来基本不会漏字段。作为参考时我一般建议先按自己的场景列出所有实体再给每个实体编号。学生实体、卡实体、食堂实体、充值记录、消费记录这些对象的字段大概率比你还多。抄它的框架没问题字段一定要按自己的需求改不然答辩老师一问「身份证号为什么是 Char(18) 而不是 Varchar(18)」就露馅了。2.2 五类对象与功能列表处理对象和功能要求的对应关系可以整理成表格处理对象涉及数据项对应功能学生基本信息 Student学号、姓名、身份证号、性别、院系、专业查询与更新学生基本信息校园卡基本信息 Card卡号、学号、身份证号、卡状态、余额查询校园卡状态食堂刷卡信息 Hconsume消费金额、卡号查询学生在食堂的消费金额财务部门信息部门办公室信息充值管理办卡/挂失/解挂/充值信息学号、充值金额等校园卡日常事务查询与更新五个功能点分别是学生信息查询更新、卡事务管理、卡状态查询、消费金额查询、食堂营业额查询与修改。营业额的查询在需求里写明要体现食堂总体收入状况还能为评价食堂服务质量提供依据——这句话写在需求分析里后面建表时就会自然把「食堂编号」这个维度保留住。2.3 数据字典示例与改写要点原文数据字典给了 12 个数据项我把关键几项整理成表编号数据项名称简述类型及宽度取值范围DI-1Studentid身份证号Char(18)0-999999999999999999DI-2Studentno学生学号Char(9)0-999999999DI-3Studentna学生姓名Char(10)—DI-4Studentsex学生性别Char(4)男/女DI-5Studentbirth出生日期——DI-6Studentdept学生院系Char(20)—DI-7Studentspecial学生专业Char(20)—DI-8Studentclass班级Int0-999999999DI-9Cardstate卡状态Char(20)挂失/未挂失DI-10Cardmoney校园卡余额Float—DI-11CZmoney充值金额Float—DI-12Dinmoney食堂刷卡金额Float—注意一点DI-1 的 Studentid 存的是身份证号而不是学号。这个命名有歧义但是能看出原始设计的意图它是持卡人的身份标识。你在自己的数据字典里字段命名尽量语义一致不要出现「ID 字段实际存身份证号」这种容易搞混的情况。数据字典是这门课被重点检查的部分。写法上要注意「简述」不要用数据库设计术语要用业务语言描述。课堂点评时老师问「Cardmoney 能不能为 NULL」答案是不能因为一张卡创建后余额至少要初始化为 0。如果你用数字类型取值范围要明确写 0这就是用户自定义完整性的一部分。2.4 安全性设计视图 用户授权双层原文在安全性和完整性上给了两个方案一个是视图机制一个是用户授权机制。视图机制解决的是「不同用户只能看到被授权的数据」——比如学生查询自己的消费记录食堂管理员查询营业额财务部门才能执行充值操作这三类角色的可见数据范围完全不同用视图天然隔离。用户授权机制则通过登录识别用户级别再按级别分配权限。这个双层方案在很多课程设计正文里被一句话带过但如果你真在实施阶段建了视图、grant 了权限答辩时是加分项。关于具体视图怎么写我放到第 6 章展开。3. E-R 图到关系模式数据库设计中最容易糊弄的一环3.1 实体与联系梳理学生、校园卡、食堂、充值概念结构设计阶段给出了 E-R 图草图学生和食堂消费之间存在联系。实体划分很明确学生实体、校园卡实体、食堂实体。如果只看 学生 — 食堂消费 这一个联系会漏掉两个重要的联系类型学生「拥有」校园卡、学生给校园卡「充值」。原文在转化时特意处理了这两个联系——拥有关系被独立为充值关系模式消费联系被独立为消费关系模式。这里的逻辑要理解透E-R 图中每一个联系都要在关系模式里有归属。一对一的「拥有」联系可以并入校园卡表一对多的「消费」联系必须独立成表充值虽然是「拥有」的派生行为但因为它有金额字段、有频次单独抽出来更合理——充值记录和余额是两个不同的概念前者是流水后者是当前状态。3.2 转化结果与关系模式分析原文将 E-R 图转化为关系模型后的结果关系模式属性说明StudentStudentidStudentnoStudentnaStudentsexStudentdeptStudentspecial学生实体独立成表CardCardnoStudentnoStudentidCardstateCardmoney校园卡实体独立成表DRechargeStudentnoCzmoney充值关系独立成模式HconsumeConsumemoney消费刷卡关系独立成模式注意原文的 Hconsume 只保留了 Consumemoney 一个属性这在规范化的角度是不足的——消费记录如果要支撑「营业额」查询必须有卡号、消费时间、食堂编号。原文这个地方明显是简化了我在建表建议里会补全。关系模式转化的规范一般是实体变成一张表多对多联系变成一张表一对多联系把一端的主键并入多端。你的设计如果多加了一个「食堂」实体食堂编号就只能出现在消费记录表里而不是出现在学生表里这个原则不能乱。3.3 消费记录独立成表的设计理由原文明确说了一句话为了便于查询学生在食堂刷卡消费信息和校园卡信息管理把消费型刷卡关系转化为独立的关系模式。这句话就是答辩时要说的核心理由。如果消费记录被压缩成 Card 表里的一个字段两个问题就来了一是无法统计单个食堂的营业额二是无法查询一个学生一段时间内的所有消费记录。独立成表后Hconsume 通过 Studentno 或 Cardno 与学生表和卡表关联既可以按学生维度查询刷了几笔也可以按食堂维度聚合营业额。充值关系独立成表也是同理充值有金额、有次数如果把充值累计额放在 Card 表的 Cardmoney 上就丢了流水明细财务对账就无从谈起。3.4 建表 SQL 示例按常见做法补全原文没有给出建表 SQL但关系模式已经定了。基于这些关系模式常见的补全做法如下CREATE TABLE Student ( Studentid CHAR(18) NOT NULL, -- 身份证号 Studentno CHAR(9) NOT NULL, -- 学号 Studentna CHAR(10) NOT NULL, -- 姓名 Studentsex CHAR(4) DEFAULT 男, -- 性别 Studentdept CHAR(20), -- 院系 Studentspecial CHAR(20), -- 专业 PRIMARY KEY (Studentno), -- 学号做主键 UNIQUE KEY (Studentid) -- 身份证号唯一 ); CREATE TABLE Card ( Cardno CHAR(9) NOT NULL, -- 卡号 Studentno CHAR(9) NOT NULL, -- 学号 Studentid CHAR(18) NOT NULL, -- 身份证号 Cardstate CHAR(20) DEFAULT 未挂失, -- 卡状态 Cardmoney FLOAT DEFAULT 0, -- 余额 PRIMARY KEY (Cardno), CONSTRAINT fk_card_student FOREIGN KEY (Studentno) REFERENCES Student(Studentno) );Studentid 这里我用了 CHAR(18)跟原文数据字典一致。卡表通过外键关联学生表保证一张卡确实属于某个学生。注意 FLOAT 存金额其实并不合适课程设计里可以用 DECIMAL(10,2) 替代精度上更合理——第 5 章我会专门展开这个点。充值表和消费表也需要建表消费表我按常见做法补上卡号和时间字段CREATE TABLE DRecharge ( Studentno CHAR(9) NOT NULL, Czmoney FLOAT NOT NULL, RechargeTime DATETIME DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (Studentno, RechargeTime) ); CREATE TABLE Hconsume ( Cardno CHAR(9) NOT NULL, Consumemoney FLOAT NOT NULL, ConsumeTime DATETIME DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (Cardno, ConsumeTime) );充值表的主码用了 (Studentno, RechargeTime)因为一个学生可能多次充值只有学号做不了主码。消费表同理用 (Cardno, ConsumeTime) 联合主码同一张卡在同一时刻只能有一笔消费这个约束成立。4. 物理设计与 Java 实施唯一索引、JDBC 连接串与 DAO 三层4.1 索引设计为什么只在 Card、Student 上建唯一索引原文物理设计阶段有一句很关键的话由于基本表 Card、Student 的主码 Cardno、Studentno 经常出现在查询条件和连接条件中且取值唯一在这两个属性上分别建立唯一索引其他表不建索引或适当建立。这句话背后的逻辑是索引不是越多越好索引维护有代价——每次 INSERT、UPDATE 都要同步更新索引索引多了写性能会明显下降。这就是教科书里说的「以空间换时间」的典型场景。表索引字段索引类型理由StudentStudentno唯一索引主码连接操作频繁CardCardno唯一索引主码消费/挂失查询频繁DRechargeStudentno适当建立普通索引按学号查充值记录HconsumeCardno适当建立普通索引按卡号查消费流水唯一索引保障了主码的唯一性普通索引只用来加速查询。如果你的系统实际跑起来发现「充值记录查询很慢」再给 DRecharge.Studentno 加索引都来得及不必一开始就全部建满。这个「先必要后优化」的思路写在物理设计说明里也会让你的报告更真实。4.2 ConnectDB连接串参数与驱动类名实施阶段给的是 Java Swing JDBC MySQL 的项目骨架代码跨 controller、dao、idao、model、view 五个包分层是清晰的。先看数据库连接类package dao; import java.sql.Connection; import java.sql.DriverManager; public class ConnectDB { public static Connection connect() { try { Class.forName(com.mysql.jdbc.Driver); // 加载驱动程序 Connection con DriverManager.getConnection( jdbc:mysql://localhost:3306/school?useUnicodetruecharacterEncodingutf8, root, 123456); // 连接数据库 return con; } catch (Exception e) { e.printStackTrace(); return null; } } }com.mysql.jdbc.Driver是 MySQL 5.x 时代的驱动类名MySQL 8.0 之后驱动类名变成了com.mysql.cj.jdbc.DriverMySQL Connector/J 的 jar 包版本不同类名也不同。这个点我在第 5 章会作为第一个踩坑记录展开。连接串里的useUnicodetruecharacterEncodingutf8保证了中文数据不会乱码。如果你用的 MySQL 8.0 以上版本连接串后面最好追加serverTimezoneAsia/Shanghai否则会报时区错误。这里的密码123456是开发环境用的实际项目不要硬编码在代码里用配置文件或者环境变量。4.3 FStudentDao 与 IFStudentDao接口解耦与预处理语句再来看 DAO 层IFStudentDao 定义了七个方法FStudentDao 实现了其中一个 addFStudent其余方法都直接抛了UnsupportedOperationExceptionString sql insert into student(StudentId,StudentDe,StudentNa,StudentSex,StudentPo,StudentNo) values(?,?,?,?,?,?); ps con.prepareStatement(sql); ps.setString(1, fStudent.getStudentId()); ps.setString(2, fStudent.getStudentDe()); ps.setString(3, fStudent.getStudentNa()); ps.setString(4, fStudent.getStudentSex()); ps.setString(5, fStudent.getStudentPo()); ps.setString(6, fStudent.getStudentNo()); int n ps.executeUpdate(); return n 0;PreparedStatement是预处理语句和 Statement 的区别在于它先把 SQL 模板提交给数据库预编译再往里传参数既防 SQL 注入又能在多次执行时复用执行计划。参数的setString(1, ...)顺序必须和 SQL 里的?占位顺序完全一致——这个看起来简单实际操作时字段一多就会错位。但这个 Dao 层有个值得注意的问题接口里声明了editFStudent、deleteFStudent却没有实现。放在课程设计的代码评审里这是减分项。你可以有两个处理方式一是把接口里未实现的方法全部补全二是只保留用到的方法删掉接口的多余声明。我一般优先选择补全实现因为答辩时老师会翻代码看到throw new UnsupportedOperationException很显眼。4.4 Swing 界面包菜单框架与窗口分工View 包里每个窗口类对应一个独立功能主窗口 MainWindow 用 JMenuBar 建了四个一级菜单系统管理、财务部门、发卡部门、食堂刷卡机。每个菜单项点击后 new 出对应的窗口类——这个就是典型的「事件驱动 窗口跳转」结构。FStudentAdd 窗口用 GridLayout 做了表单布局性别字段用 JRadioButton 配合 ButtonGroup 实现单选其他字段用 JTextField 接收输入。值得表扬的是它把「保存」按钮的事件在actionPerformed中接上了——虽然注释里写着new MainWindow没有真正保存数据但代码结构是对的创建 FStudent 对象调用 DAO 的 addFStudent 方法然后关闭窗口剩下的就是把 MyBatis 或者 Spring JDBC 换掉内层实现。这套骨架对学习分层思想很有价值。5. 避坑与排查从建表到跑通系统的 5 条真实经验5.1 驱动类名与 MySQL 版本不匹配现象运行 ConnectDB 类时报ClassNotFoundException: com.mysql.jdbc.Driver。原因项目中引入的 MySQL Connector/J 是 8.0 及以上版本8.0 里老的驱动类被移除了只剩下com.mysql.cj.jdbc.Driver。原文代码写于 2014 年当时 MySQL 5.x 是主流用老驱动类名没有毛病但现在直接跑必翻车。解决按你的 Connector/J jar 包版本修改加载类。MySQL 8.0 对应com.mysql.cj.jdbc.Driver5.x 保持原样。保险起见用Class.forName(driverClass)配合配置文件换环境只改配置不动代码。5.2 代码字段名与实际含义错位现象FStudent 模型里的 StudentId 字段在数据字典中是「身份证号」但在视图界面里「学号」「身份证号」两个输入框都存在。原因代码里的 StudentId 存的是身份证号而不是学生 ID命名没有跟上数据字典。这在课程设计代码评审里经常被当成逻辑错误问出来。解决建表前花十分钟把数据字典和 Java 实体字段对齐。StudentId 命名为 IdCard、StudentNo 保持学号一个字段一个名字代码里不会出现 set 错参数的情况。5.3 界面按钮「保存」只有注释没有逻辑现象FStudentAdd 的actionPerformed里btnOK 后直接//new MainWindow;点了之后界面没有任何反应。原因课程设计为了演示效果把按钮事件只留了壳没接业务逻辑。这是 Swing 项目的常见通病——界面画好了数据不落地。解决补上 DAO 调用。在 button OK 分支里 new 一个 FStudent 对象用 setter 把表单字段装进去再 new FStudentDao().addFStudent(student)最后 dispose 当前窗口。5.4 DAO 接口大量方法未实现现象FStudentDao 的 editFStudent、deleteFStudent 等六个方法全是throw new UnsupportedOperationException但接口里声明了这些方法。原因当时只是为了演示新增学生功能其它方法没写完。解决要么删接口里没实现的方法要么补全实现。完整补全无非是再写几个 PreparedStatement 模板工作量不大但答辩观感差很多。5.5 中文乱码与浮点金额精度问题现象页面输入中文姓名保存后数据库里显示乱码金额字段用 FLOAT 存储多次充值后出现 0.8999999 这类误差。原因连接串没有带字符集参数或者表字符集不是 utf8FLOAT 是二进制浮点数表示十进制金额有精度损失。解决建库时指定DEFAULT CHARSETutf8mb4连接串带characterEncodingutf8金额字段用DECIMAL(10,2)替换 FLOAT余额和充值金额都用定点数不会有精度玄学。6. 把完整性约束做成后手的视图授权与触发器验证6.1 用触发器保住充值余额的一致性课程设计原文提到完整性依赖触发器实现但没有给出具体语句。做充值业务时余额和充值流水必须保持一致。一个常见的做法是往 DRecharge 表插入充值记录时触发器同时更新 Card 表的 Cardmoney。DELIMITER $$ CREATE TRIGGER trg_recharge_update_balance AFTER INSERT ON DRecharge FOR EACH ROW BEGIN UPDATE Card SET Cardmoney Cardmoney NEW.Czmoney WHERE Studentno NEW.Studentno; END$$ DELIMITER ;测试方式很简单对某个学号执行一次充值再查 Card 表余额余额增量应当等于充值金额。如果余额没变检查触发器是否创建成功或者 Card 表和 DRecharge 的学号字段格式是否一致——外键字符集不一致也会导致关联失败。6.2 用视图限制查询范围视图在安全机制里承担「限定可见列」的角色。比如学生登录后只能查自己的卡信息和消费流水食堂管理员只能查本食堂营业额。一个按学号过滤的视图CREATE VIEW v_student_card_info AS SELECT s.Studentno, s.Studentna, c.Cardno, c.Cardmoney, c.Cardstate FROM Student s JOIN Card c ON s.Studentno c.Studentno; CREATE VIEW v_dining_turnover AS SELECT h.Cardno, SUM(h.Consumemoney) AS turnover FROM Hconsume h GROUP BY h.Cardno;视图创建后配合GRANT SELECT ON v_student_card_info TO student_user这样的授权语句学生账号只能查视图呈现的列看不到身份证号、院系等字段。这一套下来答辩时的安全性问题基本都能答上。6.3 一份验收清单最后整理一份验证清单拿到任何课程设计资源后按这个顺序过一遍。第一数据字典所有字段都能在建表 SQL 中找到对应列。第二E-R 图里的每个联系都能在关系模式中找到归属。第三外键关联的字段类型和长度完全一致。第四所有金额字段都是 DECIMAL 定点数。第五JDBC 连接串带字符集参数。每一条清单过完后基本不会再有翻车的余地。从那以后我每次做数据库课程设计都强制先走一遍这张清单再动手建表血泪经验换来的习惯。希望帮到你。本文还有配套的精品资源点击获取
简介一份面向高校计算机专业学生的数据库课程设计文档主题为支持校园卡的食堂消费信息管理系统。文档按数据库设计六阶段展开需求分析明确学生、校园卡、食堂消费、财务部门等处理对象办卡、挂失、充值、消费查询、营业额统计等处理功能以及视图与用户授权的安全性要求概念设计给出E-R图、数据字典、数据流与存储结构逻辑设计将E-R图转化为学生、校园卡、充值、刷卡消费等关系模式并绘制功能模块图物理设计和实施阶段则涉及索引创建原则与C#代码片段。整个包为1个docx文档约540KB排版清晰、结构完整便于对照修改。已有218人学习下载既能帮助理解数据库需求分析到物理实现的全过程也可迁移至其他校园卡应用场景适合作为课程设计和大作业的参考蓝本。1. 这份食堂消费系统数据库设计文档值不值得当模板拿到一份 2014 年的数据库课程设计文档先别急着关掉。它涵盖需求分析、概念结构设计、逻辑结构设计、物理设计、实施阶段 Java 代码把数据库设计的五步流程完整走了一遍。对于正在做数据库原理课设、或者想快速搭一个「校园卡 食堂消费」场景的人来说这份资料能把「需求 → 数据字典 → E-R 图 → 关系模式 → 建表 → 代码」整个链路串起来。支持校园卡的食堂消费信息管理系统这类题目每年都有大量学生要做真正难的不是写代码而是把需求梳理清楚、把关系模式转对。这份文档正好可以作为模板直接改写适合三类人第一次做课程设计、不知道数据字典怎么写的新手想要一个标准化六个阶段的参考结构、懒得从零搭框架的人以及需要快速出成品、直接改表名和界面文字就能交差的老手。2. 需求分析到数据字典五类处理对象与字段的定义方式2.1 为什么需求分析阶段最值得抄很多课程设计一看就是流水账开头一堆背景然后直接甩出几张表。这份文档不一样它把需求分析拆成「目标 → 任务 → 处理对象 → 功能要求 → 安全性完整性要求」五个层次。你在答辩时被问「为什么这个表要有这个字段」答案就在数据字典里。处理对象划分得清楚学生基本信息、校园卡基本信息、食堂消费信息、财务部门信息、校园卡日常事务信息办卡、挂失、充值。每个对象对应几个数据项数据项再沉淀成数据字典这一套下来基本不会漏字段。作为参考时我一般建议先按自己的场景列出所有实体再给每个实体编号。学生实体、卡实体、食堂实体、充值记录、消费记录这些对象的字段大概率比你还多。抄它的框架没问题字段一定要按自己的需求改不然答辩老师一问「身份证号为什么是 Char(18) 而不是 Varchar(18)」就露馅了。2.2 五类对象与功能列表处理对象和功能要求的对应关系可以整理成表格处理对象涉及数据项对应功能学生基本信息 Student学号、姓名、身份证号、性别、院系、专业查询与更新学生基本信息校园卡基本信息 Card卡号、学号、身份证号、卡状态、余额查询校园卡状态食堂刷卡信息 Hconsume消费金额、卡号查询学生在食堂的消费金额财务部门信息部门办公室信息充值管理办卡/挂失/解挂/充值信息学号、充值金额等校园卡日常事务查询与更新五个功能点分别是学生信息查询更新、卡事务管理、卡状态查询、消费金额查询、食堂营业额查询与修改。营业额的查询在需求里写明要体现食堂总体收入状况还能为评价食堂服务质量提供依据——这句话写在需求分析里后面建表时就会自然把「食堂编号」这个维度保留住。2.3 数据字典示例与改写要点原文数据字典给了 12 个数据项我把关键几项整理成表编号数据项名称简述类型及宽度取值范围DI-1Studentid身份证号Char(18)0-999999999999999999DI-2Studentno学生学号Char(9)0-999999999DI-3Studentna学生姓名Char(10)—DI-4Studentsex学生性别Char(4)男/女DI-5Studentbirth出生日期——DI-6Studentdept学生院系Char(20)—DI-7Studentspecial学生专业Char(20)—DI-8Studentclass班级Int0-999999999DI-9Cardstate卡状态Char(20)挂失/未挂失DI-10Cardmoney校园卡余额Float—DI-11CZmoney充值金额Float—DI-12Dinmoney食堂刷卡金额Float—注意一点DI-1 的 Studentid 存的是身份证号而不是学号。这个命名有歧义但是能看出原始设计的意图它是持卡人的身份标识。你在自己的数据字典里字段命名尽量语义一致不要出现「ID 字段实际存身份证号」这种容易搞混的情况。数据字典是这门课被重点检查的部分。写法上要注意「简述」不要用数据库设计术语要用业务语言描述。课堂点评时老师问「Cardmoney 能不能为 NULL」答案是不能因为一张卡创建后余额至少要初始化为 0。如果你用数字类型取值范围要明确写 0这就是用户自定义完整性的一部分。2.4 安全性设计视图 用户授权双层原文在安全性和完整性上给了两个方案一个是视图机制一个是用户授权机制。视图机制解决的是「不同用户只能看到被授权的数据」——比如学生查询自己的消费记录食堂管理员查询营业额财务部门才能执行充值操作这三类角色的可见数据范围完全不同用视图天然隔离。用户授权机制则通过登录识别用户级别再按级别分配权限。这个双层方案在很多课程设计正文里被一句话带过但如果你真在实施阶段建了视图、grant 了权限答辩时是加分项。关于具体视图怎么写我放到第 6 章展开。3. E-R 图到关系模式数据库设计中最容易糊弄的一环3.1 实体与联系梳理学生、校园卡、食堂、充值概念结构设计阶段给出了 E-R 图草图学生和食堂消费之间存在联系。实体划分很明确学生实体、校园卡实体、食堂实体。如果只看 学生 — 食堂消费 这一个联系会漏掉两个重要的联系类型学生「拥有」校园卡、学生给校园卡「充值」。原文在转化时特意处理了这两个联系——拥有关系被独立为充值关系模式消费联系被独立为消费关系模式。这里的逻辑要理解透E-R 图中每一个联系都要在关系模式里有归属。一对一的「拥有」联系可以并入校园卡表一对多的「消费」联系必须独立成表充值虽然是「拥有」的派生行为但因为它有金额字段、有频次单独抽出来更合理——充值记录和余额是两个不同的概念前者是流水后者是当前状态。3.2 转化结果与关系模式分析原文将 E-R 图转化为关系模型后的结果关系模式属性说明StudentStudentidStudentnoStudentnaStudentsexStudentdeptStudentspecial学生实体独立成表CardCardnoStudentnoStudentidCardstateCardmoney校园卡实体独立成表DRechargeStudentnoCzmoney充值关系独立成模式HconsumeConsumemoney消费刷卡关系独立成模式注意原文的 Hconsume 只保留了 Consumemoney 一个属性这在规范化的角度是不足的——消费记录如果要支撑「营业额」查询必须有卡号、消费时间、食堂编号。原文这个地方明显是简化了我在建表建议里会补全。关系模式转化的规范一般是实体变成一张表多对多联系变成一张表一对多联系把一端的主键并入多端。你的设计如果多加了一个「食堂」实体食堂编号就只能出现在消费记录表里而不是出现在学生表里这个原则不能乱。3.3 消费记录独立成表的设计理由原文明确说了一句话为了便于查询学生在食堂刷卡消费信息和校园卡信息管理把消费型刷卡关系转化为独立的关系模式。这句话就是答辩时要说的核心理由。如果消费记录被压缩成 Card 表里的一个字段两个问题就来了一是无法统计单个食堂的营业额二是无法查询一个学生一段时间内的所有消费记录。独立成表后Hconsume 通过 Studentno 或 Cardno 与学生表和卡表关联既可以按学生维度查询刷了几笔也可以按食堂维度聚合营业额。充值关系独立成表也是同理充值有金额、有次数如果把充值累计额放在 Card 表的 Cardmoney 上就丢了流水明细财务对账就无从谈起。3.4 建表 SQL 示例按常见做法补全原文没有给出建表 SQL但关系模式已经定了。基于这些关系模式常见的补全做法如下CREATE TABLE Student ( Studentid CHAR(18) NOT NULL, -- 身份证号 Studentno CHAR(9) NOT NULL, -- 学号 Studentna CHAR(10) NOT NULL, -- 姓名 Studentsex CHAR(4) DEFAULT 男, -- 性别 Studentdept CHAR(20), -- 院系 Studentspecial CHAR(20), -- 专业 PRIMARY KEY (Studentno), -- 学号做主键 UNIQUE KEY (Studentid) -- 身份证号唯一 ); CREATE TABLE Card ( Cardno CHAR(9) NOT NULL, -- 卡号 Studentno CHAR(9) NOT NULL, -- 学号 Studentid CHAR(18) NOT NULL, -- 身份证号 Cardstate CHAR(20) DEFAULT 未挂失, -- 卡状态 Cardmoney FLOAT DEFAULT 0, -- 余额 PRIMARY KEY (Cardno), CONSTRAINT fk_card_student FOREIGN KEY (Studentno) REFERENCES Student(Studentno) );Studentid 这里我用了 CHAR(18)跟原文数据字典一致。卡表通过外键关联学生表保证一张卡确实属于某个学生。注意 FLOAT 存金额其实并不合适课程设计里可以用 DECIMAL(10,2) 替代精度上更合理——第 5 章我会专门展开这个点。充值表和消费表也需要建表消费表我按常见做法补上卡号和时间字段CREATE TABLE DRecharge ( Studentno CHAR(9) NOT NULL, Czmoney FLOAT NOT NULL, RechargeTime DATETIME DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (Studentno, RechargeTime) ); CREATE TABLE Hconsume ( Cardno CHAR(9) NOT NULL, Consumemoney FLOAT NOT NULL, ConsumeTime DATETIME DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (Cardno, ConsumeTime) );充值表的主码用了 (Studentno, RechargeTime)因为一个学生可能多次充值只有学号做不了主码。消费表同理用 (Cardno, ConsumeTime) 联合主码同一张卡在同一时刻只能有一笔消费这个约束成立。4. 物理设计与 Java 实施唯一索引、JDBC 连接串与 DAO 三层4.1 索引设计为什么只在 Card、Student 上建唯一索引原文物理设计阶段有一句很关键的话由于基本表 Card、Student 的主码 Cardno、Studentno 经常出现在查询条件和连接条件中且取值唯一在这两个属性上分别建立唯一索引其他表不建索引或适当建立。这句话背后的逻辑是索引不是越多越好索引维护有代价——每次 INSERT、UPDATE 都要同步更新索引索引多了写性能会明显下降。这就是教科书里说的「以空间换时间」的典型场景。表索引字段索引类型理由StudentStudentno唯一索引主码连接操作频繁CardCardno唯一索引主码消费/挂失查询频繁DRechargeStudentno适当建立普通索引按学号查充值记录HconsumeCardno适当建立普通索引按卡号查消费流水唯一索引保障了主码的唯一性普通索引只用来加速查询。如果你的系统实际跑起来发现「充值记录查询很慢」再给 DRecharge.Studentno 加索引都来得及不必一开始就全部建满。这个「先必要后优化」的思路写在物理设计说明里也会让你的报告更真实。4.2 ConnectDB连接串参数与驱动类名实施阶段给的是 Java Swing JDBC MySQL 的项目骨架代码跨 controller、dao、idao、model、view 五个包分层是清晰的。先看数据库连接类package dao; import java.sql.Connection; import java.sql.DriverManager; public class ConnectDB { public static Connection connect() { try { Class.forName(com.mysql.jdbc.Driver); // 加载驱动程序 Connection con DriverManager.getConnection( jdbc:mysql://localhost:3306/school?useUnicodetruecharacterEncodingutf8, root, 123456); // 连接数据库 return con; } catch (Exception e) { e.printStackTrace(); return null; } } }com.mysql.jdbc.Driver是 MySQL 5.x 时代的驱动类名MySQL 8.0 之后驱动类名变成了com.mysql.cj.jdbc.DriverMySQL Connector/J 的 jar 包版本不同类名也不同。这个点我在第 5 章会作为第一个踩坑记录展开。连接串里的useUnicodetruecharacterEncodingutf8保证了中文数据不会乱码。如果你用的 MySQL 8.0 以上版本连接串后面最好追加serverTimezoneAsia/Shanghai否则会报时区错误。这里的密码123456是开发环境用的实际项目不要硬编码在代码里用配置文件或者环境变量。4.3 FStudentDao 与 IFStudentDao接口解耦与预处理语句再来看 DAO 层IFStudentDao 定义了七个方法FStudentDao 实现了其中一个 addFStudent其余方法都直接抛了UnsupportedOperationExceptionString sql insert into student(StudentId,StudentDe,StudentNa,StudentSex,StudentPo,StudentNo) values(?,?,?,?,?,?); ps con.prepareStatement(sql); ps.setString(1, fStudent.getStudentId()); ps.setString(2, fStudent.getStudentDe()); ps.setString(3, fStudent.getStudentNa()); ps.setString(4, fStudent.getStudentSex()); ps.setString(5, fStudent.getStudentPo()); ps.setString(6, fStudent.getStudentNo()); int n ps.executeUpdate(); return n 0;PreparedStatement是预处理语句和 Statement 的区别在于它先把 SQL 模板提交给数据库预编译再往里传参数既防 SQL 注入又能在多次执行时复用执行计划。参数的setString(1, ...)顺序必须和 SQL 里的?占位顺序完全一致——这个看起来简单实际操作时字段一多就会错位。但这个 Dao 层有个值得注意的问题接口里声明了editFStudent、deleteFStudent却没有实现。放在课程设计的代码评审里这是减分项。你可以有两个处理方式一是把接口里未实现的方法全部补全二是只保留用到的方法删掉接口的多余声明。我一般优先选择补全实现因为答辩时老师会翻代码看到throw new UnsupportedOperationException很显眼。4.4 Swing 界面包菜单框架与窗口分工View 包里每个窗口类对应一个独立功能主窗口 MainWindow 用 JMenuBar 建了四个一级菜单系统管理、财务部门、发卡部门、食堂刷卡机。每个菜单项点击后 new 出对应的窗口类——这个就是典型的「事件驱动 窗口跳转」结构。FStudentAdd 窗口用 GridLayout 做了表单布局性别字段用 JRadioButton 配合 ButtonGroup 实现单选其他字段用 JTextField 接收输入。值得表扬的是它把「保存」按钮的事件在actionPerformed中接上了——虽然注释里写着new MainWindow没有真正保存数据但代码结构是对的创建 FStudent 对象调用 DAO 的 addFStudent 方法然后关闭窗口剩下的就是把 MyBatis 或者 Spring JDBC 换掉内层实现。这套骨架对学习分层思想很有价值。5. 避坑与排查从建表到跑通系统的 5 条真实经验5.1 驱动类名与 MySQL 版本不匹配现象运行 ConnectDB 类时报ClassNotFoundException: com.mysql.jdbc.Driver。原因项目中引入的 MySQL Connector/J 是 8.0 及以上版本8.0 里老的驱动类被移除了只剩下com.mysql.cj.jdbc.Driver。原文代码写于 2014 年当时 MySQL 5.x 是主流用老驱动类名没有毛病但现在直接跑必翻车。解决按你的 Connector/J jar 包版本修改加载类。MySQL 8.0 对应com.mysql.cj.jdbc.Driver5.x 保持原样。保险起见用Class.forName(driverClass)配合配置文件换环境只改配置不动代码。5.2 代码字段名与实际含义错位现象FStudent 模型里的 StudentId 字段在数据字典中是「身份证号」但在视图界面里「学号」「身份证号」两个输入框都存在。原因代码里的 StudentId 存的是身份证号而不是学生 ID命名没有跟上数据字典。这在课程设计代码评审里经常被当成逻辑错误问出来。解决建表前花十分钟把数据字典和 Java 实体字段对齐。StudentId 命名为 IdCard、StudentNo 保持学号一个字段一个名字代码里不会出现 set 错参数的情况。5.3 界面按钮「保存」只有注释没有逻辑现象FStudentAdd 的actionPerformed里btnOK 后直接//new MainWindow;点了之后界面没有任何反应。原因课程设计为了演示效果把按钮事件只留了壳没接业务逻辑。这是 Swing 项目的常见通病——界面画好了数据不落地。解决补上 DAO 调用。在 button OK 分支里 new 一个 FStudent 对象用 setter 把表单字段装进去再 new FStudentDao().addFStudent(student)最后 dispose 当前窗口。5.4 DAO 接口大量方法未实现现象FStudentDao 的 editFStudent、deleteFStudent 等六个方法全是throw new UnsupportedOperationException但接口里声明了这些方法。原因当时只是为了演示新增学生功能其它方法没写完。解决要么删接口里没实现的方法要么补全实现。完整补全无非是再写几个 PreparedStatement 模板工作量不大但答辩观感差很多。5.5 中文乱码与浮点金额精度问题现象页面输入中文姓名保存后数据库里显示乱码金额字段用 FLOAT 存储多次充值后出现 0.8999999 这类误差。原因连接串没有带字符集参数或者表字符集不是 utf8FLOAT 是二进制浮点数表示十进制金额有精度损失。解决建库时指定DEFAULT CHARSETutf8mb4连接串带characterEncodingutf8金额字段用DECIMAL(10,2)替换 FLOAT余额和充值金额都用定点数不会有精度玄学。6. 把完整性约束做成后手的视图授权与触发器验证6.1 用触发器保住充值余额的一致性课程设计原文提到完整性依赖触发器实现但没有给出具体语句。做充值业务时余额和充值流水必须保持一致。一个常见的做法是往 DRecharge 表插入充值记录时触发器同时更新 Card 表的 Cardmoney。DELIMITER $$ CREATE TRIGGER trg_recharge_update_balance AFTER INSERT ON DRecharge FOR EACH ROW BEGIN UPDATE Card SET Cardmoney Cardmoney NEW.Czmoney WHERE Studentno NEW.Studentno; END$$ DELIMITER ;测试方式很简单对某个学号执行一次充值再查 Card 表余额余额增量应当等于充值金额。如果余额没变检查触发器是否创建成功或者 Card 表和 DRecharge 的学号字段格式是否一致——外键字符集不一致也会导致关联失败。6.2 用视图限制查询范围视图在安全机制里承担「限定可见列」的角色。比如学生登录后只能查自己的卡信息和消费流水食堂管理员只能查本食堂营业额。一个按学号过滤的视图CREATE VIEW v_student_card_info AS SELECT s.Studentno, s.Studentna, c.Cardno, c.Cardmoney, c.Cardstate FROM Student s JOIN Card c ON s.Studentno c.Studentno; CREATE VIEW v_dining_turnover AS SELECT h.Cardno, SUM(h.Consumemoney) AS turnover FROM Hconsume h GROUP BY h.Cardno;视图创建后配合GRANT SELECT ON v_student_card_info TO student_user这样的授权语句学生账号只能查视图呈现的列看不到身份证号、院系等字段。这一套下来答辩时的安全性问题基本都能答上。6.3 一份验收清单最后整理一份验证清单拿到任何课程设计资源后按这个顺序过一遍。第一数据字典所有字段都能在建表 SQL 中找到对应列。第二E-R 图里的每个联系都能在关系模式中找到归属。第三外键关联的字段类型和长度完全一致。第四所有金额字段都是 DECIMAL 定点数。第五JDBC 连接串带字符集参数。每一条清单过完后基本不会再有翻车的余地。从那以后我每次做数据库课程设计都强制先走一遍这张清单再动手建表血泪经验换来的习惯。希望帮到你。本文还有配套的精品资源点击获取
