简介《工厂数据库管理系统》课程设计文档面向数据库原理课程学生及需要完成类似设计任务的开发者提供从需求分析、E-R建模、关系模式转换到物理设计、安全维护的完整过程。资源为单个 PDF 压缩包大小约 2.1MB内容包含数据项定义、数据结构与数据流说明、多对多关系处理方案中间表设计、第三范式判定、字段及索引定义、触发器与备份策略等核心知识点并配有具体的关系表结构和 SQL 实现思路。报告覆盖工厂、车间、工人、产品、零件、仓库六个实体的表结构设计明确主键与外键给出两种多对多存储方案的取舍可帮助读者快速掌握数据库课程设计的规范流程。目前已有 405 人学习下载适合用于课程设计参考、期末复习或实际项目中的数据模型梳理。1. 这份工厂数据库管理系统PDF把数据库课程设计的完整闭环讲透了数据库这门课期末考试能过的学生有一大半但能把课程设计从需求分析一路做到权限配置的不到一半。这份《工厂数据库管理系统.pdf》是少见的完整样例一个工厂有厂名和厂长名厂下有车间车间里有工人车间既生产产品又生产零件产品和零件都入库仓库还要记库存——整个场景覆盖了一对多、多对多、复合主键、外键约束、3NF验证、索引、视图和存储过程。它适合正在赶数据库课程设计的人也适合想把“E-R图转关系模型”这条路彻底走通的人。PDF里给出了6个实体、4张联系表共10个关系模式直接可以当设计报告的骨架照着复现一遍相当于把数据库设计的六个阶段从头到尾跑了一遍省掉大量翻教材的时间。2. 需求分析与概念结构E-R图怎么拆成实体表和联系表2.1 六个实体、四类联系E-R模型的拆解逻辑原文给出的信息需求一共8条工厂包括厂名和厂长名一个厂内有多个车间一个车间有多个工人一个车间生产多种产品一个车间生产多种零件一个零件也可能由多个车间制造一个产品由多种零件组成一种零件也可装配出多种产品产品与零件均存入仓库厂内有多个仓库。把这8条一一映射到E-R图就是6个实体、4个一对多联系、4个多对多联系。教学中最容易出错的地方是把“一个车间生产多种零件一个零件也可能由多个车间制造”看成了一对多。判断是否多对多的标准就一句话能不能反过来也成立。零件能由多个车间制造那它就是多对多。需求编号联系类型参与实体转换方式厂-车间一对多Factory、Workshop车间表加FacName外键厂-仓库一对多Factory、Warehouse仓库表加FacName外键车间-工人一对多Workshop、Worker工人表加WorkNo外键车间-产品一对多Workshop、Product产品表加WorkNo外键车间-零件多对多Workshop、Compents新建WC联系表产品-零件多对多Product、Compents新建PC联系表仓库-产品多对多Warehouse、Product新建WaP联系表仓库-零件多对多Warehouse、Compents新建WaC联系表一对多联系的处理原则是把“一”这一侧的主键放进“多”这一侧的表中做外键。所以工人表、产品表、车间表、仓库表分别带上了所属上一级的键。多对多无法靠外键解决只能拆出独立的联系表最终形成WC、PC、WaP、WaC四张联系表。2.2 数据项定义与数据流写需求分析报告时直接能用的素材原文第二部分给了一张完整的数据项表这是这份PDF最有价值的部分之一。它把每个字段的名字、含义、类型、宽度、小数位数全部定义了一遍不需要自己再去翻教材推导。数据项名含义类型宽度小数位FacName工厂名Char10-FacMName厂长名Char8-CNo车间主任编号Char8-WorkNo车间号Char4-WorkAddress车间地址Char12-Workphone车间电话Char5-WorkerNo职工号Char5-WorkerName职工名Char8-WorkerAge职工年龄Int4-WorkerSex性别Char2-WorkerType工种Char10-ProductNo产品号Char5-ProductName产品名称Char12-ProductPrice产品价格Numeric51ComNo零件号Char5-ComWeight零件重量Int4-ComPrice零件价格Numeric51WareNo仓库号Char5-WNo仓库主任编号Char8-Warephone仓库电话Char12-有一点必须提醒原文数据项表的类型宽度和后面物理设计阶段的表结构不完全一致。比如FacName在数据项表里是Char(10)物理设计阶段变成Varchar(30)车间号从Char(4)变成Varchar(10)。这种前后不一致在课程设计文档里很常见动手建表时以物理设计阶段的表结构为准报告里两处都保留答辩时被问到就大方承认物理阶段做了修正。数据流部分原文列了Factory、Workshop、WorkerQK、ProductQK、CompentsQK、WareQK六条数据流每条对应一个实体表的数据构成。这一节在答辩时经常被问到“你的数据从哪里来到哪里去”把每条数据流的字段组成列出来直接回答的是“哪个表由哪些字段拼起来”本质上就是一张表结构的清单。2.3 联系表的字段与约束仓库-产品和仓库-零件的两种建模选择原文在处理仓库与零件、仓库与产品两个多对多联系时专门对比了两种方法。方法一是建两个存储表仓库零件存储表、仓库产品存储表把仓库号、零件号/产品号分别作为外键。方法二是只建一个仓库物品存储表用仓库号、物品号、库存量三个属性搞定一切。原文结论是方法一更好理由可以归结为两点清晰性和参照完整性。方法二用一个“物品号”同时表达产品和零件SQL的外键只能引用一个表“物品号”既可能指向产品表又可能指向零件表外键约束直接失效。联系表的字段设计我一般遵循一套固定模板多对多联系表的主键取两端实体的主键组合外键分别指向两端数量字段用CHECK约束保证非负。建表SQL通常长这样CREATE TABLE WaP ( WareNo varchar(10) NOT NULL, ProductNo varchar(10) NOT NULL, Snum1 int NOT NULL CHECK (Snum1 0), PRIMARY KEY (WareNo, ProductNo), FOREIGN KEY (WareNo) REFERENCES Warehouse(WareNo), FOREIGN KEY (ProductNo) REFERENCES Product(ProductNo) );说明WaP表示仓库和产品的存储联系主键是WareNoProductNo复合主键同一种产品在同一个仓库只会有一条库存记录。两个外键分别引用仓库表和产品表从约束层面保证不会出现不存在的仓库号或产品号。Snum1的CHECK约束把库存量下限锁死在0比在应用层判断更可靠。WaC仓库-零件表结构完全同理只是字段从ProductNo换成ComNo、Snum1换成Snum2。记住一个关键点多对多联系表的外键字段不允许为NULL因为它是主键的一部分主键为NULL就违反了实体完整性。照这个模板写4张联系表都能保持一致的风格。3. 逻辑结构设计关系模式转换、函数依赖与3NF验证3.1 从E-R图到10个关系模式为什么不是6张表而是10张把E-R图转关系模型最容易漏掉的就是多对多联系。原文写得很明确“建立了6个实体关系表并且把实体键作为表的关键字4个一对多的联系把一这边的实体键放到多这边做为外键4个多对多的联系建立了4个联系表。”翻译成操作步骤就是三步第一步6个实体各建一张表主键取实体的标识符。工厂表主键FacName、车间表主键WorkNo、职工表主键WorkerNo、产品表主键ProductNo、零件表主键ComNo、仓库表主键WareNo。第二步处理一对多。工人表加WorkNo外键产品表加WorkNo外键车间表加FacName外键仓库表加FacName外键。第三步处理多对多。车间与零件、产品与零件、仓库与产品、仓库与零件各自独立建联系表主键由参与实体的主键联合组成。所以最终是6张实体表加4张联系表一共10个关系模式。很多学生只建了8张表漏掉的多半是WC或PC因为车间生产零件和产品组装零件这两个联系在E-R图里容易被看成实体属性。全部关系模式汇总如下关系模式主键外键函数依赖要点FactoryFacName无FacName→FMNameWorkshopWorkNoFacNameWorkNo→CNo, WorkAddress, Workphone, FacNameWorkerWorkerNoWorkNoWorkerNo→WorkerName, WorkerAge, WorkerSex, WorkerType, WorkNoProductProductNoWorkNoProductNo→ProductName, ProductPrice, WorkNoCompentsComNo无ComNo→ComWeight, ComPriceWarehouseWareNoFacNameWareNo→WName, Warephone, FacNameWCWorkNoComNoWorkNo、ComNo(WorkNo, ComNo)→ComNum1PCProductNoComNoProductNo、ComNo(ProductNo, ComNo)→ProNum, ComNum2WaPWareNoProductNoWareNo、ProductNo(WareNo, ProductNo)→Snum1WaCWareNoComNoWareNo、ComNo(WareNo, ComNo)→Snum2表里的10个关系模式直接支撑后面的3NF判定写课程设计报告时这张表就是逻辑结构设计章节的主干。3.2 主键与函数依赖集3NF判定怎么才算完整原文为每个关系模式都列了函数依赖集这是判定3NF的关键素材。以Worker为例WorkerNo → WorkerName WorkerNo → WorkerAge WorkerNo → WorkerSex WorkerNo → WorkerType WorkerNo → WorkNo所有非主属性都完全函数依赖于主键WorkerNo不存在组合键真子集决定非主属性的情况也没有候选键穿过中间属性再决定其他属性的传递链所以Worker属于3NF。WC表判定更快。WC(WorkNo, ComNo, ComNum1)只有一个非主属性ComNum1它直接依赖完整主键(WorkNo, ComNo)既没有部分依赖也没有传递依赖天然满足3NF。这类纯联系表只要没塞冗余字段3NF验证几乎秒过。有一个细节值得写进报告原文把车间主任编号CNo放在Workshop表而不是Worker表这个设计是刻意规避传递依赖的。如果把CNo放进Worker表且车间主任本身就是职工会出现WorkerNo→WorkNo→CNo的传递依赖链Worker表就会滑出3NF。原文档用“编号引用”替代“名字冗余”用外键关系维持完整性这个处理在答辩时能讲出设计思考来。原文结论“10个关系模式都属于3NF”可以直接采用但建议每个表都补一句判定理由格式参照上面的Worker依赖集老师检查时一目了然。3.3 多对多联系的两种建表方案一个存储表还是两个存储表原文针对仓库存储这个场景专门做了方案对比这是课程设计里少见的论证环节值得保留。方案一是两个存储表方案二是一个通用物品表两者的差异可以浓缩成一张表对比项方案一WaP WaC方案二仓库物品存储表表数量21外键约束各自清晰引用产品表/零件表无法定义外键或只能弱约束查询效率按类型定位走各自索引必须带物品类型条件可读性建表看名字就知道存什么需要看物品号前缀才知道类型扩展性产品零件分别加字段互不影响公共字段无法覆盖个性需求方案二看起来表少实际上牺牲的是数据库最核心的参照完整性。物品号一会儿指向产品表一会儿指向零件表SQL层面根本没法表达“要么产品要么零件”这种逻辑只能靠应用层代码自己管。等做库存报表时一旦类型判断写错产品号被当成零件号去关联零件表SQL不报错但查出来的数据全错查错的过程还很隐蔽。所以原文坚持用两个存储表我也支持这个判断。原则很简单如果两边的后续业务差异大宁可用两张结构相似的表也不要把两种语义强行揉进一个字段。这张对比表可以直接搬进课程设计报告的方案论证部分。4. 物理设计与实施建库建表、索引、权限、存储过程的落地SQL4.1 建库与建表顺序先实体表后联系表外键才不会报错原文实施阶段要求“所有操作必须在查询分析器中用SQL语句或系统存储过程完成”。对应到现在的SQL Server环境就是SSMS的“新建查询”窗口。建表顺序有讲究必须先建被引用的父表再建引用方。常规顺序是Factory → Workshop → Worker → Product → Compents → Warehouse然后建WC、PC、WaP、WaC四张联系表。但注意车间表里有个CNo字段原文完整性要求写的是“参照职工号”职工表在车间表之后才建直接在产品物理设计那张表里引用Worker会报循环依赖这个问题在避坑章节展开。先看常规建库和实体表写法CREATE DATABASE factory; GO USE factory; GO CREATE TABLE Factory ( FacName varchar(30) PRIMARY KEY, FMName varchar(8) NOT NULL ); GO CREATE TABLE Workshop ( WorkNo varchar(10) PRIMARY KEY, CNo varchar(8) NOT NULL, WorkAddress varchar(20) NOT NULL, Workphone varchar(12) NOT NULL, FacName varchar(30) NOT NULL, FOREIGN KEY (FacName) REFERENCES Factory(FacName) ); GO说明工厂表主键是厂名厂长名不能为空这是实体完整性约束。车间表外键FacName引用工厂表保证车间必然归属一个已存在的工厂。这里没有给CNo加外键因为它指向后续才创建的Worker表要在Worker建完后用ALTER TABLE补上否则SQL Server直接报“引用的表不存在”。继续建完Worker、Product、Compents、Warehouse四张实体表后再按避坑章节的顺序补齐CNo外键然后创建联系表就不再有顺序问题。完整脚本里每张表都带主键、外键、CHECK约束比只写CREATE TABLE要有说服力得多。4.2 索引与完整性约束让查询分析器里的执行计划更可控原文物理设计阶段给出了索引方案每个表一个索引文件索引关键字基本和主键一致。SQL Server中主键默认生成聚集索引所以下面这些在主键上额外建普通索引的语句在实操中是重复的但课程设计的意义在于展示“确定索引文件和索引关键字”这个设计步骤CREATE INDEX IDX_Factory_FacName ON Factory(FacName); CREATE INDEX IDX_Workshop_WorkNo ON Workshop(WorkNo); CREATE INDEX IDX_Worker_WorkerNo ON Worker(WorkerNo); CREATE INDEX IDX_Product_ProductNo ON Product(ProductNo); CREATE INDEX IDX_Compents_ComNo ON Compents(ComNo); CREATE INDEX IDX_Warehouse_WareNo ON Warehouse(WareNo); GO说明这6条索引全部建立在主键字段上作用是让按主键查询的语句走索引查找而不是全表扫描。真正的增量价值在联系表的复合索引上比如WAP_IDX(WareNo, ProductNo)、WAC_IDX(WareNo, ComNo)这类复合索引在“按仓库查库存”时收益明显因为仓库号是复合主键的第一个字段过滤效率最高。索引这玩意说到底是平衡术建多了写操作变慢建少了读操作变慢没什么玄学看执行计划就懂。课程设计阶段按文档要求建完即可生产环境还得结合真实查询频率来取舍。4.3 安全策略用户、角色、授权与视图的配法原文安全设计部分写了“添加新用户hh”并逐个表把权限授给hh。SQL Server里的落地方式分两步先建登录名和数据库用户再授权。USE factory; GO CREATE LOGIN hh WITH PASSWORD Hh123456; CREATE USER hh FOR LOGIN hh; GO GRANT SELECT, INSERT, UPDATE, DELETE ON Factory TO hh; GRANT SELECT, INSERT, UPDATE, DELETE ON Workshop TO hh; GRANT SELECT, INSERT, UPDATE, DELETE ON Worker TO hh; GRANT SELECT, INSERT, UPDATE, DELETE ON Product TO hh; GRANT SELECT, INSERT, UPDATE, DELETE ON Compents TO hh; GRANT SELECT, INSERT, UPDATE, DELETE ON Warehouse TO hh; GO说明CREATE LOGIN创建的是服务器级登录名CREATE USER创建的是数据库级用户中间用FOR LOGIN把两者关联起来。GRANT语句把六张实体表的增删改查权限全部给到hh用户。实际演示时可以演示更细的授权比如只给Worker表SELECT权限体现“最小权限原则”。视图部分原文只给出了“创建视图”的标题没有具体SQL。常见做法是给“车间-工人信息”建一个连接视图把底层连表和字段映射藏起来CREATE VIEW v_WorkerWorkshop AS SELECT w.WorkerNo, w.WorkerName, w.WorkerType, ws.WorkNo, ws.WorkAddress FROM Worker w JOIN Workshop ws ON w.WorkNo ws.WorkNo; GO说明视图对用户暴露的是一个已连接好的宽表不用关心外键关系。hh用户如果只被授予视图的SELECT权限就看不到底层表结构这是数据库安全策略里“通过视图限制敏感列”的标准用法。4.4 存储过程与触发器把增删改查封装成系统调用原文实施阶段为每张表都创建了存储过程。生产中用存储过程的好处是统一管理SQL逻辑、减少客户端拼SQL带来的注入风险。课程设计里最标准的做法是为Worker表建一个插入存储过程CREATE PROCEDURE sp_InsertWorker WorkerNo varchar(10), WorkerName varchar(8), WorkerAge int, WorkerSex varchar(2), WorkerType varchar(20), WorkNo varchar(10) AS BEGIN INSERT INTO Worker(WorkerNo, WorkerName, WorkerAge, WorkerSex, WorkerType, WorkNo) VALUES (WorkerNo, WorkerName, WorkerAge, WorkerSex, WorkerType, WorkNo); END; GO EXEC sp_InsertWorker W001, 张三, 28, 男, 车工, C001;说明CREATE PROCEDURE把INSERT封装成可重复调用的过程参数类型和表字段一一对应。执行时用EXEC传参不用再写完整INSERT语句。这样做的实际价值有三个客户端不直接碰表结构插入逻辑变更只改存储过程权限可以收窄到“只允许执行存储过程而不允许直接操作表”。触发器原文只给了需求没有给具体案例。我一般用“保护父表”的例子来演示复杂完整性约束——删除工厂前先检查还有没有车间关联CREATE TRIGGER trg_ProtectFactory ON Factory INSTEAD OF DELETE AS BEGIN IF EXISTS (SELECT 1 FROM deleted d JOIN Workshop w ON d.FacName w.FacName) BEGIN RAISERROR(该工厂下仍有车间禁止删除, 16, 1); ROLLBACK TRANSACTION; END END; GO说明INSTEAD OF DELETE让删除操作先经过触发器判断如果工厂名在Workshop表中还有引用就抛错回滚。这个逻辑用外键ON DELETE也能做一部分但触发器能输出自定义错误信息还能在回滚前做更多业务验证正好对应原文“实现复杂的数据完整性约束”的要求。5. 避坑指南照着这份PDF建库时最容易翻车的五个点5.1 现象创建联系表时外键报错“引用的表不存在”照着文档一步步建建到WC联系表时SQL Server报错FOREIGN KEY 引用无效的表。原因很直接W C表引用了Compents表但Compents还没创建。解决方法是严格按“先实体表后联系表”的顺序执行建表脚本。这个坑还有更隐蔽的版本Workshop表里的CNo字段被要求“参照职工号”但Worker表排在Workshop后面形成循环引用。直接在建表语句里写FOREIGN KEY (CNo) REFERENCES Worker(WorkerNo)必然失败。我的处理顺序是先创建Factory和Worker再创建Workshop并把CNo外键指向Worker其他外键保持原来方向。也就是把Workshop和Worker的建表顺序对调就能避开循环依赖。5.2 现象numeric(5,1)字段插不进大数产品价格和零件价格都定义成numeric(5,1)意味着整数部分最多4位最大值是9999.9不对numeric(5,1)总共5位、小数占1位整数只有4位最大999.9。向产品表插一条价格1200的记录直接报“将 numeric 转换为数据类型 numeric 时发生算术溢出错误”。原因是对精度理解不到位。numeric(p,s)的p是总位数s是小数位整数可用位数是p-s。课程设计报告里写numeric(5,1)没问题实际建表时建议把价格改成numeric(8,2)同时保留CHECK(ProductPrice 0)。文档是设计草稿建表脚本是交付物两者允许存在微调。5.3 现象文档字段命名不一致建表建到一半发现对不上这份PDF本身存在多处命名不一致。厂长名在数据项表里是FacMName在物理设计表里写成FMName零件表有时叫Compents有时叫Components职工年龄数据项表里写成WoerkerAge物理表里又是WorkerAge库存量字段Snum1和Sum1混用。原因就是文档经过多轮修订前后没完全同步。解决方法是建表前先整理一张字段别名对照表统一以物理设计阶段的列名为准。涉及位置文档出现过的写法统一后采用厂长名FacMName / FMNameFMName零件表名Compents / ComponentsCompents职工年龄WoerkerAge / WorkerAgeWorkerAge产品库存量Snum1 / Sum1Snum1零件库存量Snum2 / Sum2Snum2整理完这张表再写SQL建到一半发现对不上的情况基本能避免。答辩时如果被问到就说明这是物理设计阶段对逻辑设计的规范化修正。5.4 现象复合主键与自增主键的选择困难做过实际系统的人看到WC、PC这些联系表会犹豫是不是加一个自增ID更好文档的做法是直接用两端主键组成复合主键这个设计在课程设计场景是对的因为仓库号和产品号的组合本身就唯一加自增ID反而多一个没业务含义的字段。复合主键唯一的坑在查询效率过滤条件如果不带复合主键的第一个字段索引利用率会下降。比如“按仓库号查所有产品库存”能走WaP表的复合索引但“按产品号反查它在哪些仓库”就无法有效利用(WareNo, ProductNo)这个索引。解决办法是按需为产品号单独建索引或者在查询量大的场景把复合主键改造成自增主键外加唯一约束两种方案都各有适用边界。课程设计阶段按文档保留复合主键但要在报告里写清楚主键选择不只是为了唯一性还要考虑查询路径。5.5 现象把零件和产品共用一个物品号导致参照完整性丢失这是原文专门对比过的方法二用一个仓库物品存储表靠物品号区分产品和零件。建表时不报错数据也能插进去但没法建立外键因为一个外键字段只能引用一张表。等到做库存报表时问题就来了查“仓库里有哪种产品”必须依赖应用代码先判断物品号前缀一旦判断条件写错产品号被当成零件号关联到零件表SQL不报错结果却全是错的。更麻烦的是产品表和零件表的字段差异会在公共表里被抹平产品想加个“批次号”字段零件根本用不上公共表只能干瞪眼。数据库设计的底线就是别把两种语义的对象塞进同一个字段。遇到这种场景拆表是正解方案一的两张存储表结构清晰、外键完整还能各自扩展独立字段代价仅仅是多一张表完全值得。6. 验证与自查把这份课程设计变成自己的三个习惯6.1 用系统表核对10张表和主外键信息建完库别急着关查询分析器先跑一段系统视图查询确认表数量和主外键与设计一致USE factory; SELECT t.name AS TableName, OBJECT_NAME(f.parent_object_id) AS ParentTable, OBJECT_NAME(f.referenced_object_id) AS ReferencedTable FROM sys.tables t LEFT JOIN sys.foreign_keys f ON t.object_id f.parent_object_id ORDER BY t.name;说明sys.tables列出当前库所有用户表sys.foreign_keys记录外键关系。结果里应该有10张表外键按设计一一对应。我复现这个设计时第一遍就漏了WC表产品表和零件表的组装关系完全没体现靠这个查询发现才补回来。6.2 用sp_helpindex检查索引是否与设计一致索引方案建完后用系统存储过程确认每个索引实际建立在哪些字段上EXEC sp_helpindex WaP; EXEC sp_helpindex Worker;说明sp_helpindex是SQL Server内置存储过程传入表名就能返回该表的索引列表包括索引名、索引字段、是否唯一。这个命令比翻图形界面快适合课程设计演示时当场验证“索引关键字和设计文档一致”。6.3 用覆盖度查询验证所有信息需求都能被表结构回答最后一个习惯是把需求分析里的8条信息需求逐条翻译成SQL查询看能不能查出来。例如“一个车间生产哪些产品”对应SELECT WorkNo, ProductNo, ProductName FROM Product WHERE WorkNo C001;说明这条查询对应“一个车间生产多种产品”的需求。用同样的方式把“某个零件由哪些车间制造”“每个仓库的产品库存总量”“某个产品由哪些零件组成”全部走一遍。如果有一条需求映射不到SQL说明关系模式有遗漏这时候回头改E-R图和表结构还来得及比答辩被老师问到才发现要体面得多。从那以后我每次做类似的数据库设计都会在交付前强制走这三步系统表查表和外键、sp_helpindex查索引、需求覆盖度查询走查。做完这三步数据库才敢说设计完成。这份PDF的完整价值就在于把从需求分析到权限配置的整条链路串起来了下载后照着建一遍跑通之后再回来读逻辑结构设计那一章理解和第一次看完全不一样希望帮到你。本文还有配套的精品资源点击获取
