ARTICLE DETAIL

资讯详情

深耕网站建设与运营推广的一线实战洞察。

机房管理系统课程设计:E-R图到SQL Server建表语句全解析

机房管理系统课程设计:E-R图到SQL Server建表语句全解析 简介一份完整Word版的广东工业大学数据库课程设计报告主题为机房管理系统设计适合高校数据库课程设计及数据库应用开发学习者参考。报告以机房上机管理为业务背景按课程设计流程依次展开系统需求分析、总体设计、数据库设计和应用程序调试内容覆盖设备采购、设备登记、借用归还、配件与消耗品管理、设备问题记录、维修报废以及机房使用安排等核心模块并配有系统总体功能模块图和菜单设计。数据库设计部分给出了E-R图、数据库逻辑模型和T-SQL建表语句应用程序设计部分展示了模块查询调试与成果显示开发环境基于Windows XP、SQL Server 2005与PowerBuilder体现了数据库类课程设计的常用技术栈。整套资料为一个规范排版的doc文档压缩包大小约1.27MB便于直接阅读或打印已有185人学习适合作为数据库课程设计报告模板也适合用于快速理解机房管理信息系统从需求分析到库表设计、界面调试的完整流程。1. 机房管理系统的课程设计报告核心是一套能复用的数据库方案做数据库课程设计的人十个里有八个拿到“机房管理系统”这种题目时第一反应都是先想界面怎么画、按钮怎么排。这份广东工业大学的课程设计报告走的完全是另一条路先把设备采购、登记、借用、维修、报废这 9 类业务操作拆清楚再落成 5 张 SQL Server 表最后才谈 PowerBuilder 界面。换句话说它最值钱的部分不是那几张截图而是从 E-R 图到建表语句这一整套“业务 → 数据模型”的推导过程。适合两类人一类是正在做机房管理系统课程设计、需要完整表结构参考的学生另一类是手头有零散设备台账、想用关系数据库把采购到报废全流程管起来的人。下面按文档的原始顺序把需求、表设计、建表语句和调试思路拆开讲。2. 需求分析与系统边界把 9 类业务操作翻译成功能模块2.1 业务需求拆解设备的全生命周期原文 1.1.1 里列了 9 条系统要求这 9 条不是随手写的顺着读就是一台设备的完整生命周期采购 → 登记 → 使用中动作借用、归还、添加配置→ 出问题 → 维修 → 报废旁边还挂着配件和消耗品两条辅助线。把它们和文档后半部分的表一一对应能得到这样一张映射表业务操作原文要求落点表 / 字段设备采购第 1 条设备采购表新设备登记第 2 条设备信息表借用 / 归还记录第 3 条设备信息表.借用 / 设备信息表.归还配件登记第 4 条配件信息表消耗品领用第 5 条消耗品信息表添加配置第 6 条设备信息表.配件信息字符型字段人工追加设备问题登记第 7 条问题设备信息表设备维修第 8 条问题设备信息表.维修情况 / 维修结果设备报废第 9 条设备信息表.设备报废这张映射表能看出两个设计取向。第一原小组没有为“借用归还记录”单独建流水表而是把借出和归还做成设备信息表里的两个数字字段。设备数量不大时这个方案够用一台设备被借走再还回更新字段就行但真实业务里借用是高频操作一台设备可能被借走多次单字段方案会覆盖历史记录。第二设备问题表和维修记录合并成了一张表一个问题对应一条维修记录没有独立的维修单。这个粒度做课程设计完全没问题答辩时能说清“为什么这样合并”就行。2.2 查询统计与上机安排两类核心使用场景原文开发目的里把系统功能分成两块查询统计和机房上机安排管理。查询统计覆盖七个点——采购单打印、按条件查设备配置信息和数量、查可用设备数量、查配件数量、查消耗品数量、查问题记录、查维修记录上机安排覆盖四个点——查可用机房、查机房可用计算机、填写使用安排日期/人数/人群/教师、查机房空闲时间。这两类需求直接决定了下游表结构。查询统计要求每张表都能回答“现在有多少可用”这类问题所以设备信息表必须带借用、报废字段配件和消耗品必须独立建表而不是塞进主表否则 count(*) 写起来非常别扭。这里有个值得注意的缺口原文没有给上机安排单独建表建表语句里也看不到机房实体表。也就是说原小组最终交付的库表只覆盖了查询统计上机安排大概率是在 PowerBuilder 端用 DataWindow 直接展示或内存数组里筛选。复现时如果老师要求“机房安排管理也要有表”需要自己补一张上机安排表字段照着原文列出的使用日期、使用人数、使用人群、带上机教师再加一个机房编号外键即可。2.3 开发环境选型XP SQL Server 2005 PowerBuilder 为什么够用原文开发环境写的是 Windows XP、SQL Server 2005 个人版、PowerBuilder。这个组合在课程设计场景里非常典型SQL Server 2005 建库建表门槛低SSMS 图形界面和 T-SQL 配合对初学者友好PowerBuilder 的 DataWindow 天生适合做查询统计类界面拖一个 DataWindow 控件连上数据源查询、打印基本不用手写太多代码。文档选择“先建好表再画界面”和这个技术栈的配合是顺的。不过现在的读者要复现会遇到两个现实问题。SQL Server 2005 在 Win10 / Win11 上大概率装不上常见做法是用 SQL Server 2008 R2 Express 或 2012 Express 替代只要不用到 2005 特有的语法文档里的建表脚本可以原样跑。PowerBuilder 同理用 Sybase PowerBuilder 12 或社区版都能打开工程界面操作逻辑不变。这套环境选择的迁移思路在后面避坑章还会提到。3. 数据库设计E-R 图拆解与五张核心表的字段逻辑3.1 E-R 图管理员、学生、计算机三个实体如何串联原文 3.1 节的总 E-R 图只列了三个实体——管理员、学生、计算机但关系覆盖了采购、登记、借用归还、配件、消耗品、问题、维修、报废一整串业务动作。这里有个命名上的小错位所谓“计算机”实体承载的其实是设备信息管理而“管理员”在文档后面的菜单设计里被分裂成了设备采购人员、设备管理人员、机房管理人员、维修人员等多个角色只是 E-R 图阶段被压缩成了一个实体。课程设计要求粒度不高这样画可以理解但复现时建议把角色拆开否则后面写权限控制会很痛苦。这份 E-R 图真正值得学的是关系标注方式把业务的“动词”全部画到实体连线上让每条连线都对应一个可落表的数据动作。我一般画 E-R 图也按这个习惯来——先列实体设备、采购单、配件、消耗品、问题、上机安排再在连线上写动词采购、登记、借用、归还、维修、报废最后根据动词决定要不要给关系加属性。这样做的好处是画完图基本就能看出哪些关系需要建独立表、哪些关系可以用字段状态代替。3.2 逻辑模型五张表的字段、类型、宽度与约束原文 3.2 节给出了五张表的结构定义其中设备信息表是绝对核心一张表同时承担设备登记、借用归还、报废、添加配置四个动作的状态记录字段名类型宽度关键字说明编号numeric6主键设备资产编号名称char8设备名称品牌char10设备品牌作用char30简要说明可用功能配置信息char60详细配置名称/型号/数量管理者char6设备责任人配件信息char60配件明细名称/型号/数量/存放地点存放位置char10物理位置设备报废numeric6非空表示已报废价格numeric10设备购置价格借用numeric6非空表示当前借出设备编号归还numeric6归还后写回的设备编号另外四张表的核心字段如下。问题设备信息表编号numeric(6)主键、详细情况char(60)、维修情况char(60)、问题发生日期、维修结果char(10)。设备采购表采购单char(10)主键、日期、厂家、保修期、保修电话、保修联系人、设备价格、设备详细配置、采购人、采购数量。消耗品信息表名称char(12)主键、使用情况char(16)、数量tinyint带 0 到 100 的范围约束。配件信息表型号char(10)主键、使用情况、数量tinyint带约束、存放地点char(16)。表结构里有几个设计逻辑值得说。配件和消耗品独立成表避免了主表字段无限膨胀而且数量字段都加了范围约束——这是文档里少数几个真正用到了数据库约束的地方。问题设备信息表把维修记录塞进来虽然粒度粗但查询“哪些设备还没修好”非常直接一条 SQL 就能带出维修情况字段的状态。采购表的主键用采购单号而不是自增 ID这种业务主键在课程设计里很常见答辩时能说清楚为什么要用采购单号就行。3.3 字段设计里的四个关键决定第一个是“总编号”与“编号”的双轨制。原文 1.1.1 写得比较绕“相同设备的总编号是不同的编号相同设备的编号是相同的”。翻译一下编号是型号编号同一批同型号设备共享一个编号用来统计“某种设备有多少台”总编号是每台设备的唯一资产编号用来定位“具体是哪一台”。对应到表里编号做主键其实不太严谨因为同型号多台设备共享编号时主键会冲突但课程设计阶段按“每台设备唯一编号”去理解也能自洽。更稳的做法是编号留作普通字段额外加一个自增 ID 做物理主键。第二个是借用/归还不做流水表前面已经分析过这里不再展开。第三个是日期字段的类型问题原文 3.2 节里“问题发生日期”写的是“日期型 8”但 3.3 节建表语句里写的是 numeric(8)这两种写法在 SQL Server 里是完全不同的东西后者插入 2013-06-18 这种文本日期会直接失败。第四个是配件信息表的粒度原文定义的配件表只有型号、数量、存放地点三列没有关联具体设备它管的是“仓库里有多少某型号配件”而不是“某个设备装了什么配件”——设备装的配件信息放在设备信息表的“配件信息”字符字段里靠人工写文本。典型的课程设计取舍粒度粗但实现快。4. T-SQL 建表实战从逻辑模型到可运行的建表代码4.1 建表语句逐段拆解原文 3.3 节的建表脚本可以直接跑但有几处前后不一致的地方必须先修正设备采购表在文档里出现了两遍第二遍才是完整版配件信息表的建表语句比逻辑模型多了一列“使用情况”日期字段按逻辑模型修正为 datetime。下面是整理后的完整脚本-- 1. 先建 schema避免后续每条语句都写完整前缀 create schema [机房]; go -- 2. 设备主表一台设备一行借用/归还/报废状态都在这张表上更新 create table [机房].[设备信息数据库结构表] ( 编号 numeric(6) primary key, -- 设备资产编号主键 名称 char(8), -- 设备名称 品牌 char(10), -- 品牌 作用 char(30), -- 功能说明 配置信息 char(60), -- 详细配置名称/型号/数量 管理者 char(6), -- 责任人 配件信息 char(60), -- 设备上安装的配件明细 存放位置 char(10), -- 机房等物理位置 设备报废 numeric(6), -- 非空表示已报废 价格 numeric(10), -- 购置价格 借用 numeric(6), -- 非空表示当前借出 归还 numeric(6) -- 归还后写回 ); go -- 3. 问题设备表一个问题一行维修信息和结果直接放这张表 create table [机房].[问题设备信息数据库结构表] ( 编号 numeric(6) primary key, -- 对应设备主表编号 详细情况 char(60), -- 问题描述 维修情况 char(60), -- 维修人、维修方案、内容 问题发生日期 datetime, -- 注意原文此处为 numeric(8)已修正 维修结果 char(10) -- 是否修好 ); go -- 4. 设备采购表一次采购一行采购单号做主键 create table [机房].[设备采购] ( 采购单 char(10) primary key, -- 采购单号 日期 datetime, -- 采购日期 厂家 char(20), -- 供货厂家 保修期 tinyint check (保修期 between 1 and 60), -- 月数 保修电话 numeric(11) check (保修电话 between 10000000000 and 99999999999), 保修联系人 char(4), 设备价格 numeric(10), 设备详细配置 char(30), 采购人 char(4), 采购数量 tinyint check (采购数量 between 0 and 100) ); go -- 5. 消耗品信息表一种消耗品一行 create table [机房].[消耗品信息] ( 名称 char(12) primary key, 使用情况 char(16), 数量 tinyint check (数量 between 0 and 100) ); go -- 6. 配件信息表一种型号的配件一行按型号管理仓库库存 create table [机房].[配件信息] ( 型号 char(10) primary key, 使用情况 char(16), 数量 tinyint check (数量 between 0 and 100), 存放地点 char(16) ); go代码逻辑说明create schema 先建好命名空间后续 create table 用 [机房].[表名] 的方式引用避免对象名冲突。设备主表把借用、归还、设备报废三个状态字段都放在同一行意味着设备状态变更就是 UPDATE 一行记录而不是 INSERT 一条流水这是整套设计里最核心的取舍。问题设备表的编号字段和主表编号对应但原文没有加外键约束表间引用关系完全靠应用层保证——这在课程设计里可以接受但如果想拿高分建议在第 4.3 节的做法里补上外键。参数说明numeric(6) 表示最多 6 位数字能覆盖从几百到几十万的设备编号量级char(n) 是定长字符存取快但会占满固定字节tinyint 是 0 到 255 的整数原文用来做数量字段配合 check 约束能挡住负数和超大批量数据。日期字段我统一修正为 datetime这是 SQL Server 的标准日期时间类型原文里 numeric(8) 的写法在真实插入日期数据时会翻车。4.2 check 约束与字段类型设计里最容易被忽略的坑原文的建表脚本里有三条 check 约束写法非常典型几乎每个复现的人都会踩到保修期 tinyint check(保修期 2), 保修电话 tinyint check(保修电话 11), 采购数量 tinyint check(采购数量 10)这三条的本意是限制位数保修期 2 年、保修电话 11 位、采购数量 10 台。但 check 约束里写“ 2”的含义是“仅当保修期等于 2 时才允许插入”而不是“限制为 2 位”。结果就是插入一台保修期 3 年的设备会被拒插入真实的 11 位手机号 13800138000 也会被拒——因为 13800138000 不等于 11而且 tinyint 根本装不下 11 位数字。采购数量同理等于把每次采购量锁死为 10 台。正确的做法是把位数限制写成范围判断-- 保修期按月算允许 1 到 60 个月 保修期 tinyint check (保修期 between 1 and 60), -- 保修电话用 numeric(11) 存储校验写成范围 保修电话 numeric(11) check (保修电话 between 10000000000 and 99999999999), -- 采购数量不允许负数上限按业务给 采购数量 tinyint check (采购数量 between 0 and 100)课程设计里 check 约束最常见的两个误用一是把位数限制写成恒等判断二是约束写成固定值。这两个错误在答辩时被老师问到的概率极高复现时建议直接改成上面的写法省得现场尴尬。4.3 建表后的自检清单脚本能跑通不代表库表设计没问题我一般会按下面六步走一遍在 SSMS 新建查询先跑 create schema确认没有“对象已存在”的报错。按 4.1 的顺序逐张建表每张表后跟一个 go便于定位哪张表出了问题。用系统视图验证表是否全部创建成功select name, create_date from sys.tables where schema_id schema_id(机房);插入一条最小合法记录验证主键和 check 约束没有被意外限制住。比如采购数量先插 5确认能通过。故意插入一条违反 check 的记录比如采购数量为 -1确认约束真的会拦截。想加分的话补上外键关系alter table [机房].[问题设备信息数据库结构表] add constraint fk_problem_device foreign key (编号) references [机房].[设备信息数据库结构表](编号);提示追加外键前要保证两张表编号数据一致否则 alter 语句会执行失败。这套自检清单的用意是建表不是写完 create table 就结束了约束、主键、外键之间的相互影响必须用插入测试数据的方式验证一遍尤其是 check 约束这种容易被写错的地方。5. 避坑与排查SQL Server 2005 环境下最常见的四个翻车现场5.1 踩坑一char(8) 存中文查询出来尾部带空格或被截断现象设备名称插入“显示器”三个字后单独查询数据正常但和其他表关联或用 PowerBuilder 展示时名称后面出现大量空格名称超过 4 个汉字时插入直接报错或静默截断。原因中文在 SQL Server 默认排序规则下按双字节存储char(8) 是 8 个字节实际只能装 4 个汉字。“显示器”占 6 字节可以放下但“戴尔显示器”占 8 字节正好满再加一个字符就放不下了。定长 char 类型查询时会按固定宽度返回尾部空格会跟着数据走关联字段一对比就暴露。解决把名称、品牌、作用、管理者这些面向用户的字段换成 nvarchar修改语句如下alter table [机房].[设备信息数据库结构表] alter column 名称 nvarchar(20); alter table [机房].[设备信息数据库结构表] alter column 品牌 nvarchar(30); alter table [机房].[设备信息数据库结构表] alter column 作用 nvarchar(100);提示改列类型前先确认表里没有超长数据否则 alter 会因为“截断字符串或二进制数据”失败。5.2 踩坑二check(采购数量 10) 把合法采购单全部挡在门外现象按文档原样建表后插入一条采购数量为 5 的记录SQL Server 直接报错“INSERT 语句与 CHECK 约束冲突”。原因原文把“位数 10”理解成“等于 10”check 约束被写成恒等判断。这个问题在 4.2 已经详细拆过实际复现时凡是照抄原文约束的人第一次插入合法数据必然翻车。解决先删除旧约束再添加新约束。SQL Server 2005 里不能直接修改约束需要两条语句配合alter table [机房].[设备采购] drop constraint CK__设备采购__采购数量__xxxx; alter table [机房].[设备采购] add constraint ck_purchase_qty check (采购数量 between 0 and 100);约束名可以从对象资源管理器的“约束”节点里查或者用脚本生成功能看原始名称。更省事的做法是直接 drop 整张表重新建课程设计阶段没有存量数据重建成本最低。5.3 踩坑三PowerBuilder 连接不上本地 SQL Server 2005 实例现象PowerBuilder 里点连接测试报“不能连接到数据库”或“用户 sa 登录失败”但 SSMS 里用 Windows 身份验证能正常打开库。原因SQL Server 2005 默认安装时 TCP/IP 协议多半是禁用的而且身份验证模式默认是“Windows 身份验证”sa 账号默认禁用。PowerBuilder 的 DataWindow 走的是 TCP/IP SQL 账号登录两边对不上自然连不上。解决打开 SQL Server Configuration Manager把实例的 TCP/IP 协议启用再到 SSMS 服务器属性 → 安全性里把身份验证模式改成“SQL Server 和 Windows 身份验证模式”启用 sa 账号并设密码最后重启 SQL Server 服务。PowerBuilder 连接脚本的常见写法如下sqlca.DBMS MSS Microsoft SQL Server 2012 sqlca.Database 机房 sqlca.UserID sa sqlca.DBPass your_password sqlca.ServerName 127.0.0.1 sqlca.AutoCommit true sqlca.DBParm MsgTerse注意不同 PowerBuilder 版本能识别的 DBMS 字符串不一样旧版本可能是“MSS Microsoft SQL Server 6.x”以安装版本下拉框里实际显示的为准。5.4 通用排错路径从界面报错反查到数据层界面报错时不要急着改代码我一般按三步走。第一步复制错误文本看是数据库错误还是 PB 自身错误——SQL Server 的错误号以 2 开头PB 自身错误以 1 开头或直接是中文描述。第二步把 DataWindow 里的 SQL 语句拖到 SSMS 里单独跑一遍库表有没有问题立刻暴露这一步能过滤掉一半的“假报错”。第三步如果同一条 SQL 在 SSMS 能跑、在 PB 跑不了检查连接的数据库名是否写错、AutoCommit 是否开启、事务是否被残留代码卡住。这三个检查点做完大部分连接问题都能定位。6. 进阶用三条验证 SQL 评估这套库表设计是否成立6.1 验证一设备状态统计拿到这套表结构后第一条要跑的验证 SQL 是设备状态统计用来确认借用、报废两个状态字段真的能支撑“可用设备数量”这个核心查询select count(*) as 总设备数, sum(case when 借用 0 and 设备报废 0 then 1 else 0 end) as 可用设备数 from [机房].[设备信息数据库结构表];逻辑说明借用为 0 表示未被借出设备报废为 0 表示未报废两个条件同时满足才能算可用设备。这条 SQL 能跑通说明状态字段的取值规范是自洽的如果结果是 NULL 或错误多半是数据初始化时没给默认值。6.2 验证二check 约束是否按预期拦截修改完 check 约束后用一条必失败的插入验证拦截逻辑-- 这条语句应当报错数量不能超过 100 insert into [机房].[消耗品信息](名称, 使用情况, 数量) values (A4纸, 正常, 101);说明如果这条语句没有报错而是插入成功说明 check 约束没有生效或者被去掉了得回头检查表定义。这条验证配合 6.1 一起跑一张表“能查”和“能被正确约束”两个维度就都覆盖了。6.3 迁移到现代架构的最小改动如果现在有人要拿这套设计做 Spring Boot 毕业设计表结构可以直接平移但要改三处把全部 char 字段换成 nvarchar解决中文编码问题把借用、归还两个状态字段拆成独立的 borrow_record 流水表解决历史记录被覆盖的问题补一张上机安排表字段就用原文列出的使用日期、使用人数、使用人群、带上机教师外加机房编号外键。这三处改完这套 2013 年的表结构放进 2025 年的 Web 项目里依然能打。从那以后我拿到任何一份课程设计文档都会先跑一遍验证 SQL 再看界面截图这个习惯帮我避开过不少文档写得很漂亮、库里全是洞的项目。希望帮到你。本文还有配套的精品资源点击获取
返回列表