简介一份软件工程与数据库课程设计任务书围绕“图书管理系统”展开完整数据库设计流程适合高校计算机、软件工程专业学生作为课程设计参考。文档覆盖需求分析、概念结构设计E-R图、逻辑结构设计关系模式、主外键与规范化、物理结构设计索引、视图及SQL语句及编码阶段明确学生借阅、续借、归还、查询和管理员图书与学生信息管理等功能。后台推荐SQL Server或Oracle前台开发环境不限可通过ADO、ODBC、OLE DB或JDBC连接数据库。资源为1个doc文档共3页包大小48KB文字内容完整涵盖任务要求、设计步骤、验收材料及参考书目便于对照撰写课程设计报告。已有2737人学习浏览适合正在完成数据库课程设计或需要系统设计模板的学生使用。1. 图书管理系统课程设计一份任务书背后的完整交付路径数据库课程设计里的图书管理系统几乎是高校题库里出现频率最高的题目但真正把它做完、做好靠的不是会写几句 SQL而是把需求分析、概念结构设计、逻辑结构设计、物理结构设计、编码这一整条线走通。我拆过不少版本的课程设计任务书这份文档的特别之处在于它把每一步的交付物都写明白了分 E-R 图、全局 E-R 图、关系模式、索引视图、SQL 语句、带注释的源程序进度还压到两周。很多同学卡住不是因为功能难而是不知道 E-R 图画到什么程度算合格、多对多关系怎么拆表、存储过程写到什么颗粒度能过检查。这篇笔记就按任务书的技术路线逐层拆解把 PowerDesigner 建模和 SQL Server 实现时的几个翻车点一起讲清楚。适合正在做该课程设计的本科生也适合想快速搭一套带借阅流程的管理系统做参考的开发者。2. 需求分析与概念结构设计E-R 图的边界和粒度怎么定2.1 需求先按角色拆学生操作和管理员操作是两条主线拿到任务书第一步别急着画图先把功能清单拉出来。任务书明确写了系统分为面向学生和面向管理员两部分学生可以借阅、续借、归还、查询书籍管理员负责书籍和学生的增加、删除、修改以及对借阅、续借、归还的确认。注意这里有一个容易被忽略的约束条件凭借书证借书每次最多借 8 本借书期限最长 30 天。这俩数字后面会直接变成表字段和存储过程里的校验逻辑设计时漏了编码阶段就得返工。我一般会把需求拆成两张表一张列功能性需求一张列数据约束。功能性需求对应到后续的页面和操作数据约束对应到字段默认值和 SQL 里的 CHECK 或存储过程判断。任务书里还有一句话很关键“每种图书都有书名、书号ISBN、一名或多名作者译者、出版社、定价和内容简介。” 多名作者这个属性就是 E-R 图设计里第一个要决策的点后面会专门讲。先把借阅者的属性也记下来姓名、所在单位、职业。这些字段会直接映射到学生表。需求分析阶段还要确定连接方案。任务书推荐后台用 SQL Server 或 Oracle前台不限制可以用 ADO、ODBC、OLE DB 或 JDBC。这个选择会影响后续所有代码我的建议是选 SQL Server ADO.NETC# WinForms理由有二一是 SQL Server 的图形化管理工具对课程设计阶段调试友好二是 ADO.NET 的 SqlConnection、SqlCommand 写起来直白老师检查代码时容易看懂。如果你的机器上只有 MySQL也不是不行但任务书推荐的后台是 SQL Server 或 Oracle提交时最好保持一致。2.2 三个局部 E-R 图图书、借阅者、借阅记录各管各的属性概念结构设计阶段任务书要求“先选择局部应用画出分 E-R 图最终形成系统的 E-R 图”。这句话的意思是不要一上来就画一张大网而是先把每个业务对象单独拆出来看属性。我习惯拆三个局部应用图书管理、借阅者管理、借阅记录管理。图书实体的属性包括书号ISBN、书名、作者、出版社、定价、内容简介。这里有一个多值属性问题——任务书写了“一名或多名作者”。在概念模型里规范的做法是把作者拆成独立实体用联系表达“图书-作者”的多对多关系但课程设计的规模下这么做会把关系模式从 3 张表变成 4 到 5 张表还要额外处理作者表的增删改。常见的折中方案是保留 Author 字段多位作者用顿号分隔存储在同一个字段里。这么做不符合严格的范式理论但在“一万多册图书、主要验证借阅流程”的课程设计场景里是绝大多数通过验收的做法。如果指导老师特别较真你就在报告里说明“考虑到系统规模作者采用分隔字符串存储”一般都能接受。借阅者实体的属性从任务书里直接抄借书证号、姓名、所在单位、职业。注意借书证号和学号不是一回事借书证号是图书馆内部编号学号是学校教务编号。课程设计里通常用借书证号做主键学号作为候选键加 UNIQUE 约束。借阅记录实体则要包含记录编号、借出日期、应还日期、实际归还日期、续借次数。借阅人、被借图书都通过外键关联不要在借阅记录里冗余书名和读者姓名这是第三范式的要求后面逻辑结构设计时再展开。三个局部 E-R 图之间的关系是借阅者与借阅记录是 1:N图书与借阅记录是 1:N借阅者与图书则通过借阅记录形成间接的多对多。注意在设计时不要直接画“借阅者-图书”的 M:N 联系因为借阅记录带有借出日期、应还日期这些属性它必须是一个独立实体而不是两个实体之间的纯联系。2.3 从分 E-R 图到全局 E-R 图PowerDesigner CDM 落地与检查任务书点名要求使用 PowerDesigner 建立业务处理模型。PowerDesigner 中概念数据模型CDM是独立于具体数据库平台的画好后可以生成物理模型PDM再生成 SQL Server 的建表脚本。有的学校机房装的是 Sybase PowerDesigner 16.5有的装了 15.1操作路径略有差异但核心逻辑一致。建 CDM 的操作步骤新建模型时选择 Conceptual Data Model在工具箱里选 Entity 图标在画布上依次放置图书、借阅者、借阅记录三个实体双击实体在 Attributes 页签里逐个添加属性字段把图书实体的 ISBN 设为标识符Identifier借阅者实体的借书证号设为标识符在工具箱选 Relationship 图标创建“借阅者借阅记录”、“图书被借阅”两个一对多联系。需要注意 PowerDesigner 默认把联系两端都显示为“1,n”或“0,n”鼠标单击联系线在 Cardinalities 页签里把借阅者端设为 1,n借阅记录端设为 0,n表示一个借阅者可以有零到多条借阅记录一条借阅记录必须对应一个借阅者。画完后执行 Check ModelTools - Check Model重点看两类错误一类是实体缺少标识符另一类是联系没有设置基数。常见问题是学号字段既想要它做主键又想保留自增整数主键两个标识符同时存在会导致 PowerDesigner 生成 PDM 时多出候选键影响后续外键引用。我的做法是概念模型里只保留一个主标识符其他唯一字段在逻辑设计阶段加 UNIQUE 约束。全局 E-R 图就是把三个局部图整合到一张画布里确保联系的命名、基数一致然后用 Check Model 跑一遍错误清零再进下一步。提示PowerDesigner 的 Check Model 不检查业务合理性只检查模型完整性。比如“借阅者最多借 8 本”这种约束CDM 里表达不了要留到物理设计的 CHECK 约束或存储过程里实现。3. 逻辑结构与物理结构设计关系模式转换、规范化与 SQL 建表3.1 多对多联系拆表规则借阅记录为什么必须单独建表E-R 图转关系模式有一条铁律一个实体转成一张表实体的属性就是表的字段实体的标识符就是主键1:N 联系把“一”端的主键放到“多”端做外键M:N 联系必须拆成一张独立的关系表两端的主键联合作为这张表的主键。放到图书管理系统的场景里借阅者与图书之间本质上是多对多——一个借阅者可以借多本书一本书可以被多个借阅者借过。如果不在中间做拆解而是把“借阅者借了哪本书”塞进借阅者表就会出现一个读者借 8 本书需要 8 行记录的窘境。借阅记录表就是要拆出来的中间关系表。它同时承担了两个职责一是表达借阅者与图书的联系外键二是存联系本身的属性借出日期、应还日期、归还日期。这种既带外键又带自身属性的表在关系模式里就是一个独立的关系模式。设计时我给它的主键是自增的 RecordID借阅者端外键 ReaderID、图书端外键 BookID 分别指向两张主表。为什么不用联合主键ReaderID BookID因为同一个人可以分两次借同一本书虽然实际业务中会先还再借但联合主键会把这种合法场景堵死。自增主键虽然多一个字段却让后续的续借、归还操作都变得简单SQL 里只要认 RecordID 一条记录即可。3.2 第三范式冗余字段是怎么从借阅表里被赶走的关系模式设计完下一步是分析依赖关系做规范化处理。任务书原话是“分析关系模式中的依赖关系对关系模式规范化处理”。本科课程设计一般做到第三范式3NF就够。第三范式的要求是表中所有非主属性既不部分依赖于主键也不传递依赖于主键。通俗讲就是每张表只描述一件事其他实体的信息一律用外键去引用。最容易出问题的就是借阅记录表。初学者常常把书名、作者、出版社、读者姓名一起写进借阅记录表理由是“查询的时候方便不用 join”。这会在更新时翻车假设某本书的价格调整了如果你只在图书表里改了价格而借阅记录表里的旧价格没改同一本书在两个地方出现不同价格数据就不一致了。书名依赖书号读者姓名依赖借书证号它们都不依赖借阅记录主键这就是部分依赖直接破坏 2NF。所以借阅记录表只能保留RecordID、ReaderID、BookID、BorrowDate、DueDate、ReturnDate、RenewCount、Status。所有跟图书、借阅者相关的信息都通过外键去关联查询。同理借阅者表里不要放“当前借了几本书”这种统计字段。这个数量可以从借阅记录表实时 COUNT 出来。不过这里有个取舍如果每次查询都实时 COUNT借阅频繁时性能会受影响如果冗余一个 BorrowedCount 字段就要保证每次借书、还书都同步更新它。课程设计的数据量只有一万多条记录实时 COUNT 完全够用我不会在借阅者表里加这个冗余字段。但“学生每次最多借 8 本”这个约束存储过程里必须判断否则仅靠表结构拦不住超量借阅。3.3 物理设计参数化字段长度、索引策略与 SQL Server 建表脚本物理结构设计要做三件事分配字段存储长度、建立索引和视图、定义主码和外码。下面是 SQL Server 的建表脚本包含了字段长度、默认值和约束USE LibraryDB; GO CREATE TABLE dbo.Book ( BookID INT IDENTITY(1,1) PRIMARY KEY, ISBN NVARCHAR(20) NOT NULL, Title NVARCHAR(100) NOT NULL, Author NVARCHAR(100) NOT NULL, Publisher NVARCHAR(50) NOT NULL, Price DECIMAL(6,2) NOT NULL, Intro NVARCHAR(500) NULL, TotalCopies INT NOT NULL DEFAULT 1, AvailableCopies INT NOT NULL DEFAULT 1, CONSTRAINT UQ_Book_ISBN UNIQUE (ISBN) ); CREATE TABLE dbo.Reader ( ReaderID INT IDENTITY(1000,1) PRIMARY KEY, ReaderNo CHAR(12) NOT NULL, ReaderName NVARCHAR(20) NOT NULL, Department NVARCHAR(50) NOT NULL, Job NVARCHAR(20) NOT NULL DEFAULT N学生, CONSTRAINT UQ_Reader_No UNIQUE (ReaderNo) ); CREATE TABLE dbo.BorrowRecord ( RecordID INT IDENTITY(1,1) PRIMARY KEY, BookID INT NOT NULL, ReaderID INT NOT NULL, BorrowDate DATETIME NOT NULL DEFAULT GETDATE(), DueDate DATETIME NOT NULL, ReturnDate DATETIME NULL, RenewCount INT NOT NULL DEFAULT 0, Status NVARCHAR(10) NOT NULL DEFAULT N借出, CONSTRAINT FK_Record_Book FOREIGN KEY (BookID) REFERENCES dbo.Book(BookID), CONSTRAINT FK_Record_Reader FOREIGN KEY (ReaderID) REFERENCES dbo.Reader(ReaderID) ); GO这段脚本里有几个实际项目中值得注意的设计点。BookID 用 IDENTITY 自增主键本身不携带业务含义ISBN 单独加 UNIQUE 约束避免 ISBN 输入重复导致两本不同的书共用一个书号。ReaderNo 用 CHAR(12) 固定长度因为借书证号一般是定长的如果用了 NVARCHAR查询时忘了补空格会出现匹配不上的情况。Price 用 DECIMAL(6,2) 而不是 FLOAT货币类型用浮点数会在累计计算时产生精度误差DECIMAL 是定点数6 位精度足够覆盖单本图书价格。TotalCopies 和 AvailableCopies 两个字段是有意做冗余的总册数和可借册数。每次借书把 AvailableCopies 减 1还书加 1。为什么不直接 COUNT 借阅记录因为一本被借走的书在 BorrowRecord 里有记录被下架的书可能没有记录靠 COUNT 很难准确表达“在馆可借”的数量。可借册数负数的问题由 CHECK 约束兜底建表时可以在 AvailableCopies 上再加 CHECK (AvailableCopies 0)。接着建索引和视图。书名和作者是任务书明确要求的查询条件要给它们建索引DueDate 是逾期统计的常用条件也建一个。CREATE INDEX IX_Book_Title ON dbo.Book(Title); CREATE INDEX IX_Book_Author ON dbo.Book(Author); CREATE INDEX IX_Record_DueDate ON dbo.BorrowRecord(DueDate); GO CREATE VIEW dbo.vw_OverdueBooks AS SELECT r.ReaderNo, r.ReaderName, b.Title, br.DueDate, br.Status FROM dbo.BorrowRecord br JOIN dbo.Book b ON br.BookID b.BookID JOIN dbo.Reader r ON br.ReaderID r.ReaderID WHERE br.Status N借出 AND br.DueDate GETDATE(); GO索引的语义说明IX_Book_Title 和 IX_Book_Author 是普通非聚集索引服务“按书名、作者分类查询现有图书数量”的需求IX_Record_DueDate 配合视图里的 DueDate GETDATE() 条件避免全表扫描。视图 vw_OverdueBooks 把逾期未还的图书、读者信息拼成一张宽表前台界面的“逾期列表”直接查这个视图即可不用每次写三表 JOIN。提示SQL Server 中 NVARCHAR 字段建索引会占用比 VARCHAR 更多的空间但对于课程设计的数据量这个差异可以忽略。关键在于把查询条件里的字段放进索引而不是纠结用哪种字符串类型。4. 编码实现SQL Server 存储过程与前台增删改查的联调细节4.1 连接方式选择ADO.NET 连接 SQL Server 的写法与参数说明进入编码阶段任务书推荐采用 ADO、ODBC、OLE DB 或 JDBC 连接数据库。我选用 C# ADO.NET因为 SqlConnection、SqlCommand 的模型最直观而且 SQL Server 的 System.Data.SqlClient 命名空间是现成的不用额外装驱动。连接字符串的写法有几种流派下面是我常用的string connStr Server.;DatabaseLibraryDB;User Idsa;Passwordyour_password;;Server 后面的点代表本机默认实例如果你装的是命名实例这里要写成 Server.\SQLEXPRESS 或机器名\实例名。用 Windows 身份验证则把 User Id 和 Password 换成 Integrated SecurityTrue但课程设计演示时用 Windows 身份验证换一台机器跑就可能连不上sa 账号更稳定。需要注意 sa 账号默认可能被禁用先在 SQL Server Management Studio 里启用。打开连接后前台调用存储过程的惯用方式是用 SqlCommand 指定 CommandType.StoredProcedure而不是拼接 SQL 字符串。两者最大区别是参数化查询天然防 SQL 注入也能让 SQL Server 复用执行计划性能更好。连接对象用完要释放C# 里用 using 块包裹是标准做法否则连接池会被占满第二台机器连不上数据库时排查半天才发现是这里的问题。4.2 借书、还书、续借的存储过程事务与约束一起写存储过程是整个系统的核心借书、还书、续借这些写操作都封装在存储过程里。我先把借书的存储过程完整写出然后逐个说明参数和事务逻辑。CREATE PROCEDURE dbo.usp_BorrowBook ReaderNo CHAR(12), ISBN NVARCHAR(20) AS BEGIN SET NOCOUNT ON; DECLARE ReaderID INT, BookID INT, BorrowedCount INT, MaxBorrow INT, Avail INT; BEGIN TRY BEGIN TRANSACTION; SELECT ReaderID ReaderID FROM dbo.Reader WITH (UPDLOCK) WHERE ReaderNo ReaderNo; SELECT BookID BookID FROM dbo.Book WHERE ISBN ISBN; IF ReaderID IS NULL OR BookID IS NULL THROW 50001, N学号或书号不存在, 1; SELECT BorrowedCount COUNT(*) FROM dbo.BorrowRecord WHERE ReaderID ReaderID AND Status N借出; IF BorrowedCount 8 THROW 50002, N已达最大借阅数量 8 本, 1; SELECT Avail AvailableCopies FROM dbo.Book WHERE BookID BookID; IF Avail 0 THROW 50003, N该书无可借副本, 1; INSERT INTO dbo.BorrowRecord (BookID, ReaderID, BorrowDate, DueDate) VALUES (BookID, ReaderID, GETDATE(), DATEADD(DAY, 30, GETDATE())); UPDATE dbo.Book SET AvailableCopies AvailableCopies - 1 WHERE BookID BookID; COMMIT TRANSACTION; END TRY BEGIN CATCH IF TRANCOUNT 0 ROLLBACK TRANSACTION; THROW; END CATCH END GO参数说明ReaderNo 是借书证号CHAR(12) 传入时必须保证长度够 12 位不足要补空格ISBN 是书号NVARCHAR(20)。存储过程内部先做三件事查借阅者、查图书、校验借阅数量和可借副本。注意 SET NOCOUNT ON 的作用是取消 DONE_IN_PROC 消息否则前台 ExecuteNonQuery 时返回值可能被干扰。关键设计点有两个。一是 WITH (UPDLOCK) 锁定借阅者行防止两个并发的借书请求同时读到同一个 BorrowedCount然后双双通过 8 本上限校验导致实际借出 9 本。这是并发场景下的经典问题单用户演示时看不出来多人同时操作时就会暴露。二是事务包裹 INSERT 和 UPDATE借阅记录插入成功、可借副本扣减失败时整个事务回滚不会出现“记录建了但库存没减”的脏数据。DATEADD(DAY, 30, GETDATE()) 直接把到期日算成借出日加 30 天边界情况由 SQL Server 的日期函数处理不担心大小月。还书和续借的存储过程结构类似。还书时先确认这条借阅记录状态是“借出”把 ReturnDate 置为 GETDATE()、Status 改成“已还”同时把 Book 表的 AvailableCopies 加 1整个过程同样放在事务里。续借则要先判断是否已续借过一次、是否已过期过期图书不允许续借必须归还后再借。4.3 前台调用顺序查询、借阅、归还三个页面的核心逻辑前台我用 WinForms 演示但核心调用逻辑对 Web 前端同样适用。借书按钮的 Click 事件里做四件事从界面控件取值、构造存储过程参数、执行命令、根据异常给用户反馈。using (SqlConnection conn new SqlConnection(connStr)) using (SqlCommand cmd new SqlCommand(usp_BorrowBook, conn)) { cmd.CommandType CommandType.StoredProcedure; cmd.Parameters.AddWithValue(ReaderNo, txtReaderNo.Text.Trim().PadRight(12)); cmd.Parameters.AddWithValue(ISBN, txtISBN.Text.Trim()); conn.Open(); try { cmd.ExecuteNonQuery(); MessageBox.Show(借书成功); RefreshBookList(); } catch (SqlException ex) { MessageBox.Show(ex.Message, 借书失败); } }代码逻辑txtReaderNo.Text.Trim().PadRight(12) 保证 CHAR(12) 字段匹配如果不做 PadRight前台输入的短证号可能匹配不上数据库里的定长字符串ExecuteNonQuery 执行存储过程成功则刷新图书列表失败则弹出 SQL Server 抛出的错误信息。classic 的坑是很多初学者用 ExecuteReader 来跑存储过程返回的是 SELECT 结果而这里借书操作没有返回结果集应该用 ExecuteNonQuery。查询图书模块相对简单用 SqlDataAdapter 填充 DataTable绑定到 DataGridViewSQL 语句里用 LIKE 实现书名、作者的关键字查询。有一件事必须提醒查询的 SQL 也要用参数不要写 string.Format 拼接否则书名里带个单引号就直接把查询打崩了这在图书管理系统里很常见因为书名里真的会有《Its...》这种字符。5. 避坑指南与常见问题排查五条数据库课程设计的血泪经验5.1 借阅记录表里冗余了书名改价格时数据不一致现象管理员修改图书定价后借阅历史里显示的旧价格没变和新价格对不上。原因借阅记录表里直接存了书名、作者、价格等图书相关字段。这些信息本来依赖图书表的主键却被复制到了借阅记录里形成传递依赖破坏第三范式。解决把借阅记录表瘦身只保留 RecordID、BookID、ReaderID、BorrowDate、DueDate、ReturnDate、RenewCount、Status。前台展示历史借阅时用 JOIN 把图书表和借阅者表的字段查出来不要从借阅记录里直接取冗余字段。如果之前已经建错了表用 ALTER TABLE 把冗余列删掉再修改查询语句。5.2 并发借书突破 8 本上限多人同时操作时数据异常现象演示时单机操作一切正常但两个同学同时在两台机器上给同一读者借书每人第 8 本都成功了最终该读者库里显示借了 9 本。原因存储过程里先 SELECT 再判断再 INSERT判断语句执行时另一个事务还没提交两个请求读到相同的旧计数。这是典型的并发读写竞争没有锁保护就会出问题。解决在借书存储过程的起始处对 Reader 表的目标记录加 UPDLOCK让并发的第二个事务等待第一个事务提交后再读取计数。除了加锁也可以在 Reader 表上建触发器或者用应用层锁但对课程设计来说存储过程里加 UPDLOCK 是最直观的解法。5.3 到期日算错直接手工加 30 天没考虑大小月现象读者 3 月 30 日借的书应还日期被前台代码算成 4 月 29 日实际应该 4 月 29 日没错——但如果用字符串截取再加天数到了闰年 2 月就会出乱子。原因有些实现里把 BorrowDate 转成字符串取月份加 1 拼成应还日期这种字符串拼日期的方式遇到跨年、大小月、闰年就翻车。解决到期日一律在 SQL Server 里用 DATEADD(DAY, 30, BorrowDate) 计算数据库引擎会处理所有日历边界情况。前台展示只负责读 DueDate 字段不要在前台重新计算。同样续借操作也要基于当前 DueDate 再 DATEADD而不是基于 BorrowDate 重算。5.4 删除图书被外键挡住管理员删不掉旧书现象管理员想下架一本旧书执行 DELETE FROM Book 时报外键冲突错误提示 BorrowRecord 表有相关记录引用。原因这本书有借阅历史BorrowRecord 表里存在指向 BookID 的外键。默认情况下外键会阻止删除主表记录这是保护数据完整性的正常行为。解决课程设计的数据删除一般是逻辑删除也就是给 Book 表加一个 IsDeleted 标志位查询时默认过滤掉已删除的书而不是物理删除记录。如果确实要物理删除可以先删除关联的借阅记录再删图书或者在建外键时加 ON DELETE CASCADE但 CASCADE 会连同借阅历史一起删掉对图书管理系统不合适我建议用 IsDeleted 方案。5.5 PowerDesigner 生成的 SQL 在 SQL Server 里跑不通现象在 PowerDesigner 里把 CDM 转成 PDM再生成 SQL Server 的建表脚本执行时报错列类型未知或标识符重复。原因CDM 里的数据类型是平台无关的转 PDM 时 PowerDesigner 需要映射到 SQL Server 的具体类型。如果 CDM 里字段用了 Characters默认映射到 SQL Server 可能是 TEXT 或者 CHARACTER VARYING版本不同映射规则也不同另外 CDM 里建的候选键在生成 SQL 时会多出 UNIQUE 约束和主键冲突。解决生成脚本后先人工检查三类地方字符串类型是否被映射成 NVARCHAR/VARCHAR自增列是否生成 IDENTITY主键和外键是否生成 PRIMARY KEY/FOREIGN KEY。更省事的做法是不依赖自动生成直接在 SQL Server Management Studio 里按第三节的脚本手动建表建表后再把表结构导回 PowerDesigner 更新 PDM保证文档和实际库一致。6. 验收前自检把任务书的检查点过一遍再提交课程设计验收不是看代码能不能跑而是看整个设计链路是否完整。我给自己定了一个自检清单提交前按顺序过一遍每个检查点都跑一次验证脚本。第一遍检查需求分析文档是否覆盖任务书全部功能点包括学生借阅、续借、归还、查询管理员增删改和确认逐条对照打勾。第二遍检查概念结构里头分 E-R 图和全局 E-R 图是否齐全实体、属性、标识符、联系、基数是否和文档一致。第三遍检查逻辑结构里关系模式是否满足第三范式每张表是否都有主键和外键多对多联系是否拆成独立表。第四遍检查物理设计里字段长度、索引、视图、SQL 语句、CHECK 约束是否都写进报告。接着跑一段验证 SQL把关键约束一次性查出来确认没有脏数据SELECT r.ReaderNo, COUNT(*) AS 当前借出数 FROM dbo.BorrowRecord br JOIN dbo.Reader r ON br.ReaderID r.ReaderID WHERE br.Status N借出 GROUP BY r.ReaderNo HAVING COUNT(*) 8; SELECT Title FROM dbo.Book WHERE AvailableCopies 0;这两条查询专门检查两类异常读者借出数超过 8 本、图书可借副本为负数。如果都返回空结果集说明数据是干净的。视图 vw_OverdueBooks 也要顺手跑一遍确认逾期列表能正常显示。最后一步是过一遍演示流程新进图书录入学生查询借书超量时拦下还书续借管理员修改图书信息删除异常记录。每个操作都看数据库对应字段的变化。我以前交过一版E-R 图画得很漂亮但存储过程里没有事务多借几次就出现了可借副本负数被老师当场指出来。从那以后我每次提交前都强制跑一遍上面这两条 SQL确认约束、索引、存储过程、视图全部到位才敢上交。希望帮到你。本文还有配套的精品资源点击获取