简介：这是一份数据库课程设计报告，完整呈现银行管理系统的开发过程，适合正在完成数据库课程设计或学习SQL Server与VC++编程的读者参考。报告从选题目的与设计内容入手，围绕用户管理、账户操作、数据库备份恢复三大模块展开需求分析，给出了储户表、活期存取款表、定期存款/取款表及操作记录表的字段定义，并绘制E-R图辅助理解数据库概念结构与逻辑结构。系统实现部分基于Visual C++ 6.0和SQL Server，以CRecordSet类访问数据库，展示了关键功能代码与运行结果，能帮助读者快速掌握数据库表设计与前台界面联调的基本方法。资源为单份docx文档，全文12页，压缩包大小仅107KB，便于本地查阅和二次编辑参考。该文档已有660人浏览学习，对实训报告撰写和系统设计思路梳理具有实用价值。

1. 为什么一份银行管理系统课程设计报告值得你逐页看

数据库课程设计选“银行管理系统”这个题目的学生非常多，但大多数人的产出是“代码能跑、报告凑页”。这份《数据库课程设计报告银行管理系统》不一样的地方在于：它把数据库设计的完整链路——E-R 图、逻辑结构、物理结构、主外键约束、VC++ 6.0 访问 SQL Server 的 CRecordSet 代码——按课程设计报告的规范串了起来。你下载它，不只是拿到一份银行管理系统的需求分析和表结构说明，更是拿到了一份“数据库设计 + VC 前台编程”的完整参考，答辩时老师追问的字段约束、外键走向、删除逻辑，它都能给出具体交代。正在写课程设计报告的学生，以及需要 VC++ 6.0 连接 SQL Server 代码范例的从业者，都值得把这份文档逐页看一遍。

2. 把银行账户体系拆成四张表：E-R 图到物理设计的落地

2.1 E-R 图的实体关系：储户、活期、定期是怎么连起来的

银行管理系统最核心的建模对象不是“用户”，而是“账户”和“账户上的每一笔钱”。这份报告里，E-R 图的核心实体是银行储户，围绕它派生出货期存取款、定期存取款、定期操作记录三个实体，彼此通过“帐号”这个字段建立联系。

这里的建模思路有一个值得注意的点：储户表和活期存取款表是一对多关系，一个账户会有多条存取款流水；储户表和定期存款表也是一对多关系，一个账户可以有多笔不同年份、不同利率的定期存款。把“账户余额”放在储户表里，把“每笔操作的金额、类型、日期、利息”放在流水表里，这是典型的“主表存当前状态、从表存操作历史”的设计。如果你在自己的课程设计里把余额也放进流水表，就会出现“余额到底以哪个字段为准”的歧义，老师问起来很容易卡壳。

E-R 图中定期存取款和定期操作记录之间的连线，则体现了“定期存款到期取款后留下一笔历史记录”的业务闭环。这个设计我后面会在避坑章节里专门讲，因为它有一个隐藏的外键隐患。

2.2 储户表与活期存取款表：字段级设计说明

储户表是整张系统的主表，报告里给出的字段设计如下：

需要注意两个细节：一是密码字段用了定长char(6)，因为报告规定密码必须 6 位，定长 char 在比较时不需要处理变长边界，读取性能略好；二是“帐号”这个词在报告里统一用的是“帐”而不是“账”，建表时如果你自己从零写脚本，要注意保持一致，否则后面写 SQL 查询时字段名对不上会报错。

活期存取款表是储户表的从表，所有字段都要求非空，主键是自增的 nID，外键指向储户表的帐号。它比储户表多了两个关键字段：CInterest利息和CStyle操作类型（存入/支出）。这里有一个课程设计里常见的偷懒做法——把利息算成一个固定值直接存进去，而不是用“本金 × 利率 × 天数”实时计算。报告的字段设计支持存利息值，但如果你想在答辩时显得更专业，可以把利息设计成可计算的字段，或者至少准备一段 SQL 说明利率怎么参与计算。

2.3 定期三张表的设计逻辑与主外键走向

定期业务在报告里被拆成了三张表：定期存款表、定期取款表、定期操作记录表。这是这份报告里最有“设计含量”的部分，但也最有争议。

定期存款表记录每笔定期存款的金额、存储年份、存储利率，主键是 nID，外键指向储户表帐号。定期取款表记录取款人姓名、取款金额、取款日期，主键是 nID，但它的外键指向的却是定期存款表的 nID——这意味着每笔取款必须关联到一笔具体的定期存款记录。定期操作记录表则以 nID 为索引，记录存取款人姓名、类型、金额、年份、日期，外键同时指向定期存款表和定期取款表。

这套设计在逻辑上能自洽：取款是针对某笔存款的支取，历史记录是存取业务的操作流水。但它带来的实际问题是——如果一笔定期存款是 1 万元，用户分两次各取 5000 元，第二次取款时“定期取款表外键指向存款表 nID”这个约束就会让系统难以表达“同一笔存款被部分支取”的事实。课程设计阶段这样做可以接受，但如果这是生产系统，我会把定期取款表改成独立的支取流水表，用“存款编号 + 支取金额”的方式记录。你把这个缺陷写进报告的“不足与改进”一节，反而是加分项。

2.4 物理设计里值得抄的三个细节

第一，所有表的所有字段都标了“非空”，主键用单字段而不是复合主键。对于课程设计来说，单字段主键配合自增 nID 是最省事的方案，复合主键在 CRecordSet 里操作时反而容易出现主键冲突。第二，外键关系数量控制在 4 条以内，没有出现多级级联的复杂引用，这对 SQL Server 2000 这种老版本数据库来说是比较稳妥的做法。第三，varchar 长度给得很克制：姓名 20、密码 6、身份证号 20、开户地点 30，没有出现那种所有字段一律 varchar(255) 的偷懒写法——这恰恰是答辩时老师会翻着看的地方。

3. VC++ 6.0 + SQL Server 2000：环境搭建与 CRecordSet 数据链路

3.1 这套老技术栈现在怎么跑起来

报告里的开发环境是 Windows XP + VC++ 6.0 + SQL Server 2000，Pentium 4、512MB 内存——这套组合在今天的主流机器上已经很难直接安装。如果你下载报告后打算照着复现，最常见的做法是装一个虚拟机，在虚拟机里部署 Windows XP，然后依次安装 SQL Server 2000 和 VC++ 6.0。SQL Server 2000 的个人版和企业版在 XP 上都跑得比较稳，VC++ 6.0 装完后记得装 SP6 补丁，否则在 XP 上经常出现调试器崩溃的玄学问题。

如果你的机器是 64 位系统，还有一个替代方案：用 SQL Server 2005 或 2008 的 Express 版做兼容，VC++ 6.0 通过 ODBC 连接数据库时，只要数据源配置正确，代码层基本不需要改动。报告里使用的 CRecordSet 类走的是 ODBC 数据源，不是直连，所以数据库版本的小幅升级对代码影响很小。这个兼容性细节在答辩时可以主动提一句，老师会认为你考虑过环境迁移问题。

3.2 建库与 ODBC 数据源配置

报告里给出的建库步骤是：打开企业管理器，新建 SQL Server 注册，然后新建数据库 Bank。建库之后还有一个关键步骤——配置 ODBC 数据源，报告里没有明确写出这一步，但 CRecordSet 要工作，ODBC 数据源是绕不过去的。操作路径是：控制面板 → 管理工具 → 数据源 (ODBC) → 系统 DSN → 添加 → 选择 SQL Server 驱动 → 填写数据源名称（一般叫 Bank，与数据库同名）→ 选择服务器 → 勾选使用 SQL Server 身份验证 → 更改默认数据库为 Bank。

这里有一个容易翻车的细节：系统 DSN 和用户 DSN 的区别。VC++ 6.0 生成的程序如果以管理员身份运行，会读取系统 DSN；如果以普通用户运行，读的可能是用户 DSN。课程设计演示时如果换了登录用户导致 DSN 找不到了，程序会报“无法连接数据源”。我一般会直接配系统 DSN，并且在演示前先手动打开 ODBC 管理器确认数据源列表里能看到 Bank。

3.3 CRecordSet 访问数据库的关键步骤

报告里实现数据访问的方式是 MFC 的 CRecordSet 类，它是 ODBC 之上的封装。使用流程分三步：

第一，在 VC++ 6.0 里为每个数据表生成一个 CRecordSet 派生类。菜单路径是：插入 → 新建类 → 类类型选择 Generic Class，基类填 CRecordSet。然后在类的头文件里加入数据库的声明宏：

// AccountSet.h class CAccountSet : public CRecordset { public: CAccountSet(CDatabase* pDatabase = NULL); // 下面这组宏告诉 CRecordSet 要操作哪张表、哪些字段 CString m_CNo; CString m_CName; CString m_CPassword; ... };

// AccountSet.cpp IMPLEMENT_DYNAMIC(CAccountSet, CRecordset) CAccountSet::CAccountSet(CDatabase* pdb) : CRecordset(pdb) { m_CNo = _T(""); m_CName = _T(""); m_nFields = 8; // 字段数量必须与实际表一致，多了少了都会引起绑定错误 }

// 运行时绑定到 Account 表 CString CAccountSet::GetDefaultSQL() { return _T("[Account]"); // 表名要用方括号包住，避免与 SQL 关键字冲突 } void CAccountSet::DoFieldExchange(CFieldExchange* pFX) { pFX->SetFieldType(CFieldExchange::outputColumn); RFX_Text(pFX, _T("[CNo]"), m_CNo); RFX_Text(pFX, _T("[CName]"), m_CName); RFX_Text(pFX, _T("[CPassword]"), m_CPassword); }

这里几个参数要说明一下：m_nFields是字段数量，必须和DoFieldExchange里 RFX 绑定的字段数量完全一致，少一个会在 Open 时报“记录集字段数与查询不一致”；GetDefaultSQL返回的表名如果包含特殊字符，必须用方括号包裹，否则 SQL 解析会出错；RFX_Text 用于 varchar/char 类型，RFX_Double 对应 float 字段，数值字段用错了宏会出现数据错位。

第二，在需要使用数据的对话框类（比如 CLoginDlg）里声明一个 CAccountSet 成员变量：

// LoginDlg.h class CLoginDlg : public CDialog { public: CAccountSet m_recordset; // 关联到 Account 表的记录集 };

第三，用 Open 方法配合 SQL 语句查询数据。这一步报告里的代码写得很典型，后面的章节我会贴完整代码。

3.4 连接阶段的典型报错与排查方向

CRecordSet 的 Open 失败，大概率是三个原因。一是 ODBC 数据源没配好，错误信息通常是“找不到数据源名称并且没有指定默认驱动程序”，这时候回 ODBC 管理器检查 DSN 名称和数据库名是否都叫 Bank；二是 SQL Server 没启动或者不允许 TCP/IP 连接，错误信息是“连接超时”或“用户登录失败”，这时候先用查询分析器手动登录一次，排除数据库自身问题；三是 SQL 语句里的表名或字段名写错，Open 不会给你详细的 SQL 语法错误，只会告诉“查询错误”，排查方法是把strSQL.Format里的那条 SQL 复制到查询分析器里跑一遍，这是最快定位问题的方式。

4. 登录、开户与销户：核心模块的代码逐段拆解

4.1 登录对话框：验证链路与状态清理

登录模块的逻辑骨架是“先检查输入合法性，再查数据库验证密码，最后用全局变量传递当前账户”。先看完整的 OnOK 响应函数：

void CLoginDlg::OnOK() { UpdateData(TRUE); // 把控件内容刷新到成员变量 // 第一关：三项输入都不能为空 if (m_strNo == "") { MessageBox("Please Input the Account Number!"); m_ctrNo.SetFocus(); return; } if (m_strPassword == "") { MessageBox("Please Input the Password!"); m_ctrPassword.SetFocus(); return; } if (m_strRePassword == "") { MessageBox("Please Input the Confirm Password!"); m_ctrRePassword.SetFocus(); return; } // 第二关：密码和确认密码必须一致 if (m_strPassword != m_strRePassword) { MessageBox("Two Passwords Are Differed!"); m_strPassword = ""; m_strRePassword = ""; UpdateData(FALSE); m_ctrPassword.SetFocus(); return; } // 第三关：用账号构造 SQL，打开记录集 CString strSQL; strSQL.Format("select * from Account where CNo = '%s'", m_strNo); if (!m_recordset.Open(AFX_DB_USE_DEFAULT_TYPE, strSQL)) { MessageBox("Open Database Filed!", "Database Error", MB_OK); return; } // 第四关：验证密码是否匹配 if (m_recordset.m_CPassword != m_strPassword) { MessageBox("Password Error! Please Rewrite!"); m_recordset.Close(); m_strPassword = ""; m_strRePassword = ""; UpdateData(FALSE); m_ctrPassword.SetFocus(); return; } // 登录成功：把当前账户号保存到 App 类里的全局成员 CBankApp* ptheApp = (CBankApp*)AfxGetApp(); ptheApp->strNo = m_strNo; CDialog::OnOK(); }

这段代码的设计思路是“关卡式验证”：每一层只做一件事，失败了就停留在登录框并让用户修正。需要注意两个容易被忽略的细节：第一，密码错误后不仅清空了密码框，还调了UpdateData(FALSE)把清空结果同步回界面，否则用户看到的是上次输入的内容；第二，登录成功后把m_strNo存到CBankApp的成员strNo里，这是整个系统共享“当前登录用户”的常见做法，比用全局变量清爽，也比在每个对话框里重复查询登录账号要可靠。

这里有一个 SQL 注入的隐患值得在答辩时主动说明：strSQL.Format("select * from Account where CNo = '%s'", m_strNo)直接把用户输入拼进 SQL，如果用户输入' or '1'='1，WHERE 条件就被绕过了。课程设计阶段可以这样写，但你最好在报告里补一句“生产环境应使用参数化查询或存储过程”，这是老师很吃这一套的加分表述。

4.2 开户对话框：初始化控件与 Insert 写入

开户模块的核心操作是把新账户写入 Account 表，同时初始化一条活期存取款记录。报告里给出了 OnInitDialog 的初始化代码：

BOOL CAccountDlg::OnInitDialog() { CDialog::OnInitDialog(); m_tmDate = CTime::GetCurrentTime(); // 开户日期默认取当前时间 m_ctrSex.AddString("男"); // 性别下拉框预置两个选项 m_ctrSex.AddString("女"); UpdateData(FALSE); return TRUE; }

这段代码解决的是“界面初始化”：日期控件默认显示当天、性别下拉框预置内容。真正写入账户的 SQL 逻辑在 OK 按钮响应函数里，常见做法是构造两条 INSERT：

void CAccountDlg::OnOK() { UpdateData(TRUE); // 第一笔写入：Account 表，账户基本信息 CString strSQL; strSQL.Format( "INSERT INTO Account (CNo, CName, CPassword, CID, CSex, CBalance, CDate, CAddress) " "VALUES ('%s', '%s', '%s', '%s', '%s', %f, '%s', '%s')", m_strNo, m_strName, m_strPassword, m_strID, m_strSex, m_bBalance, m_tmDate.Format("%Y-%m-%d"), m_strAddress); m_recordset.Open(AFX_DB_USE_DEFAULT_TYPE, strSQL); m_recordset.Close(); // 第二笔写入：Current 表，开户同时插入一条金额为 0 的活期流水 CString strSQL2; strSQL2.Format( "INSERT INTO Current (CNo, CMoney, CStyle, CDate, CInterest, CBalance) " "VALUES ('%s', 0, '存入', '%s', 0, %f)", m_strNo, m_tmDate.Format("%Y-%m-%d"), m_bBalance); m_recordset2.Open(AFX_DB_USE_DEFAULT_TYPE, strSQL2); m_recordset2.Close(); CDialog::OnOK(); }

这里有一个参数匹配的问题要特别注意：%f对应 float 类型的m_bBalance，%s对应 CString 类型的字段，顺序必须和前面的 VALUES 顺序严格一致。如果m_strSex是从下拉框取到的“男”或“女”，它的格式是 CString，没问题；如果下拉框选项和实际存储值不一致，会出现性别栏写入空值。

另外，开户时同时写两张表，这本质上是“同一个业务事务里的两个操作”。课程设计报告里没有用事务包裹，但你在答辩时被问到“如果第一句 INSERT 成功、第二句 INSERT 失败怎么办”，可以回答“应该用CDatabase::BeginTrans和CommitTrans把两步包成事务”，并现场改给你看。这是报告里明显留了口子、但你能补上的地方。

4.3 销户流程：业务校验顺序为什么不能乱

删除账户是这份报告里最有价值的代码段之一，因为它体现了“业务规则校验优先于数据删除”的意识。完整代码如下：

void CMainFrame::OnDeleteAccount() { CBankApp* ptheApp = (CBankApp*)AfxGetApp(); CString strSQL; // 第一步：查出当前登录用户在 Account 表中的记录 strSQL.Format("select * from Account where CNo = '%s'", ptheApp->strNo); CAccountSet recordset; if (!recordset.Open(AFX_DB_USE_DEFAULT_TYPE, strSQL)) { MessageBox("Open Database Filed!", "Database Error", MB_OK); return; } // 第二步：二次确认 if (MessageBox("确定删除该用户?", "提示", MB_YESNO) == IDYES) { // 第三关：活期存款余额必须为 0 if (recordset.m_CBalance != 0) { recordset.Close(); MessageBox("用户账户中活期存款仍存有余额，无法进行销户!"); return; } // 第四关：定期存款表里不能有未结清的定期账目 CTimeDepositSet tds; CString strRecord; strRecord.Format("select * from TimeDeposit where CNo = '%s'", ptheApp->strNo); if (!tds.Open(AFX_DB_USE_DEFAULT_TYPE, strRecord)) { recordset.Close(); MessageBox("Open Database Filed!", "Database Error", MB_OK); return; } if (tds.GetRecordCount() != 0) { recordset.Close(); tds.Close(); MessageBox("用户账户中仍存有定期账目，无法销户!"); return; } // 第五关：删除并刷新记录集 recordset.Delete(); recordset.Requery(); recordset.Close(); MessageBox("用户账户删除成功!"); } else { recordset.Close(); return; } }

这段代码的顺序设计很有讲究：先查账户，再确认意图，再查活期余额，再查定期账目，全部通过之后才执行 Delete。如果顺序反过来——先删了账户再查定期——外键约束会直接阻止删除或者留下孤儿数据。代码里用GetRecordCount() != 0判断定期账目是否存在，这个函数在 CRecordSet 打开后第一次调用是可靠的；但如果你在 Requery 之后调用它，结果可能不准，所以判断要放在查询之后立即执行，不要插入别的数据库操作。

4.4 查询账户信息：列表控件的 refresh 思路

账户信息查询窗口的设计是“顶部显示当前账户的基本信息，下面用 CListCtrl 展示操作流水”，报告里安排了一个RefreshList()成员函数来初始化列表。CListCtrl 的操作套路是“先删除旧行，再逐条插入新行”：

void CAccountInfo::RefreshList() { // 清空旧数据 m_ctrList.DeleteAllItems(); // 用 SQL 查询当前账户的全部活期流水 CString strSQL; strSQL.Format("select * from Current where CNo = '%s'", m_strNo); CCurrentSet recordset; if (!recordset.Open(AFX_DB_USE_DEFAULT_TYPE, strSQL)) return; // 逐条插入列表 int nIndex = 0; while (!recordset.IsEOF()) { m_ctrList.InsertItem(nIndex, recordset.m_CDate.Format("%Y-%m-%d %H:%M")); m_ctrList.SetItemText(nIndex, 1, recordset.m_CStyle); m_ctrList.SetItemText(nIndex, 2, ...); // 把金额转成字符串填入 nIndex++; recordset.MoveNext(); // 千万记得移动游标，否则死循环 } recordset.Close(); }

这里的重点是IsEOF()和MoveNext()的组合：IsEOF()判断是否到达记录集末尾，MoveNext()移动游标到下一行，两个缺一个都会出问题——缺了 MoveNext 会死循环，缺了 IsEOF 会在最后一条记录上多读一次。金额字段是 float 类型，转成字符串显示时建议用%.2f格式化成两位小数，直接用%f会显示一长串小数，答辩演示时很难看。

5. 避坑与常见问题：课程设计里最容易翻车的五个场景

5.1 SQL Server 2000 在 Windows 7 及以上系统装不上

现象：安装程序启动后抛出“安装失败”或“无法找到 Microsoft SQL Server 2000 运行库”，强行装完也无法启动服务。

原因：SQL Server 2000 发布于 2000 年，它的安装程序和运行时依赖大量 XP 时代的系统组件，在 Windows 7、Windows 10 上兼容性极差，尤其是安装检测阶段会报“内存不足”之类的误导性错误。

解决：装一个 Windows XP 虚拟机，在虚拟机里安装 SQL Server 2000。VMware 或 VirtualBox 都行，XP 镜像加 SQL Server 2000 安装盘大约需要 2GB 磁盘空间。数据库文件、代码、VC++ 6.0 全部放在虚拟机里，和宿主机共享文件夹传输。这是我做过多次课程设计环境后觉得最省事的方案。

5.2 CRecordSet.Open 报“找不到数据源名称”

现象：程序编译链接都正常，一运行到m_recordset.Open()就弹“找不到数据源名称并且没有指定默认驱动程序”，或者“ODBC 驱动程序管理器”报错。

原因：ODBC 数据源没配置，或者配置了用户 DSN 但程序以管理员权限运行读的是系统 DSN，两个 DSN 不一致。

解决：打开控制面板 → 管理工具 → 数据源 (ODBC)，选择“系统 DSN”选项卡，添加 SQL Server 驱动，数据源名称填 Bank，服务器选本机，勾选“使用用户输入的登录 ID 和密码的 SQL Server 验证”，并把默认数据库改成 Bank。改完后点“测试数据源”确认连接成功，再去跑程序。这个测试按钮能省你大量排查时间。

5.3 密码明明正确，登录却提示“Password Error”

现象：在数据库里手动插入了一条账户记录，程序里输入正确的账号密码，仍然提示密码错误。直接在查询分析器里执行select * from Account where CNo='...'，能查到数据，密码字段看起来也对。

原因：密码字段是char(6)定长类型。如果你手动插入的密码不足 6 位，比如“abc123”正好 6 位没事；如果是“abc”这种短密码，SQL Server 会把后面补空格存进去，而程序中输密码不会自动补空格，两边比较必然不等。

解决：一律使用 6 位密码，插入数据时用'123456'这种长度刚好等于 6 的字符串。或者检查字段里是否带了空格，用select len(CPassword) from Account看一眼实际长度。不要用trim()之类的方式绕，课程设计阶段保持“证卡密码必须 6 位”的业务规则是最稳妥的。

5.4 销户时活期余额是 0，但代码判定“有余额”

现象：在数据库里把账户的CBalance更新为 0，但程序在销户时仍然弹“活期存款仍存有余额，无法销户”。

原因：recordset.m_CBalance != 0直接用 float 做等于判断。float 是浮点数，在 SQL Server 里存储的 0 可能是0.0000000012，或者中间经过一次运算后变成很小的非零值，直接比较就会误判。这是浮点数做等值比较的经典坑。

解决：改为fabs(recordset.m_CBalance) > 0.001这种方式，定义一个极小阈值。或者更彻底一点，把 Account 表的CBalance字段类型从 float 改成 decimal(18,2)，金额字段本来就不应该用 float 存，float 的精度误差在银行存款场景是完全不可接受的。报告里用 float 是为了图省事，你在答辩时主动提出这个改进，属于“指出课程设计的不足并给出生产级方案”。

5.5 定期取款表的外键指向，导致一笔存款只能被取一次

现象：给一笔定期存款设计了两笔取款记录，第二笔存进去或者取出来的时候，程序提示违反外键约束，或者查询定期操作记录时出现重复 nID 冲突。

原因：报告里定期取款表的外键指向定期存款表的 nID，隐含的语义是“一笔定期存款对应一次取款”。如果用户在真实场景里分多次取同一笔定期存款，这个模型就表达不了。

解决：课程设计阶段，把业务规则限定为“定期存款到期后一次性取出”，在报告里说明这个限制。如果你想做得更完善，把定期取款表改成独立的取款流水表，新增字段DepositID记录关联的存款记录编号，不把取款的 nID 直接当外键。这个设计改动工作量不大，但在答辩讲设计思路时非常出彩，属于“我发现了问题并且给出了方案”。

6. 答辩前的自查清单与三个加分扩展

6.1 自测流程：十分钟跑完的完整业务链路

答辩之前，我建议你按下面这个顺序手动走一遍完整流程，任何一步失败都要在答辩前修掉。先打开系统，新开一个账户，录入账号、姓名、6 位密码、身份证号、性别、地址、初始金额；然后关掉程序重新打开，用这个账户登录；登录后做一笔活期存款、一笔活期取款，去查一下操作记录，确认流水的类型、金额、日期都正确；接着存一笔定期，不要马上取，再去删除账户，此时应该弹出“定期账目未清无法销户”；然后取定期，再去删除账户，此时应该提示“活期仍有余额”；把活期余额取到 0，再次删除，应该能删成功。这套流程覆盖了登录、开户、存取款、定期、销户全部核心路径，跑通了，你的业务逻辑基本没有大问题。

6.2 三个加分扩展：在报告里主动写出来

第一个是给“开户写两张表”加上事务。用CDatabase::BeginTrans()包住两条 INSERT，CommitTrans()提交，任何一条失败就Rollback()。代码只需要加三行，但体现的是“数据一致性”意识。第二个是给 Account 表加一个登录失败次数统计，连续输错 3 次锁定账户，这是一个很简单的字段加判断逻辑，但答辩时老师会觉得你想过真实安全问题。第三个是备份恢复功能不要只调用 SQL Server 的BACKUP DATABASE命令，可以在程序里加一个“备份前检查磁盘可用空间”的步骤，这个细节对生产场景很关键，说出去很加分。

最后说点个人教训。我早年做课程设计时，总觉得“代码能跑就行”，直到有一次答辩，老师现场让我连续两次取同一笔定期存款，我的系统直接报外键冲突——那一刻我才意识到，数据库课程设计真正的评分点不在界面好不好看，而在表和表之间的关系能不能覆盖真实业务。从那以后，我每写完一个课程设计，都会强制走一遍“新建用户 → 存钱 → 取钱 → 定期存入 → 到期支取 → 销户”的完整链路，确认每个环节的 SQL 都能在查询分析器里手动跑通，再写进报告交付。希望这份银行管理系统报告的拆解能帮到你，把坑提前避掉。

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