1.引言

1.1 内容及要求

设计内容：设计学生宿舍管理系统。

设计要求：

（1）数据库应用系统开发的需求分析，写出比较完善系统功能。

（2）数据库概念模型设计、逻辑模型设计以及物理模型设计。

（3）完成功能模块结构设计并编写代码实现。

（4）软件总体测试及修改。

（5）撰写软件设计说明书。

1.2 系统环境选择

数据库系统选择：Microsoft SQL Server 2019数据库管理系统选择：Microsoft SQL Server Management Studio 18前端开发语言选择：C#前端开发软件：Visual Studio 2019前端开发框架：Windows 窗体应用(.NET Framework 4.8)

2.需求分析

2.1 设计背景

学生宿舍管理系统的设计背景源于对传统宿舍管理方式的改进需求。传统方式存在信息不透明、手动操作繁琐等问题，导致住宿分配不公平、报修反馈滞后等困扰。通过引入宿舍管理系统，可以提高管理效率和便捷性，简化操作流程，提供学生宿舍申请、报修、查询等功能。系统能够数字化宿舍分配，实现公平和透明，同时提供维修管理和访客功能，提升宿舍管理质量和学生满意度。数据统计和分析功能为管理员提供决策支持，帮助改进管理策略。通过系统，学生和管理员可以获得准确、实时的宿舍信息，增加管理的透明性和公正性。综上所述，学生宿舍管理系统的设计背景是为了提高管理效率、提供便捷服务、实现公平和透明的宿舍管理，提升学生生活质量和学习环境。

2.2 功能分析

系统需要有一个登录页面，不同用户登录后，对不同的功能具有不同的权限。数据库用户包括学生、维修员、管理员等多个角色。

信息要求：

管理员可以查询学生信息、宿舍信息、维修人员信息、维修信息及访客信息。维修人员可以查询修改维修单号、查询维修评价等信息。学生可以查询访客审批进度、维修进度等信息。

处理要求：

学生可以在系统内部报销损坏，申请访客访问，访客离开报备。在维修之后还可以对此次维修做出评价。管理员看到学生提交上来的申请后会进行审批。审批的结果学生都可以查询到。当维修申请通过后，此维修单将会自动传递给维修师傅，维修师傅便可以维修。在维修完之后管理员还要对维修人员提交的报销进行审批，通过则报销维修费用。管理员还会核实访客离开的报备。维修人员可以查询到通过审批且未维修的单子从而选择接单。维修完成后由维修人员提交维修完成表和报销单。维修人员可以查询报销状态和学生对自己的维修评价。

2.3 数据项和数据结构

数据项：

宿舍号、宿舍人数、宿舍地址、楼栋号、楼栋地址、学生学号、姓名、班级、学生性别、床号、访客号、访客姓名、访客电话、访客日期、访客时间、访问理由、访客审批状态、离开时间、核实状态、维修单号、维修时间、维修审核状态、维修状态、报销状态、维修人员姓名、损坏描述、维修人员工号、维修人员性别、维修人员年龄、维修评分、维修具体评价、报销金额、管理员账户、维修人员账户、用户账户、密码。

宿舍号。类型：字符串型。长度：20。含义：唯一标识用来区别每个宿舍。宿舍人数。类型：整数类型。含义：记录当前宿舍居住人数。宿舍地址。类型：字符串型。长度：40。含义：记录宿舍地址。楼栋号。类型：字符串型。长度：20。含义：唯一标识楼栋。楼栋地址。类型：字符串型。长度：40。含义：记录楼栋地址。学生学号。类型：字符串型。长度：20。含义：唯一标识学生。学生姓名。类型：字符串型。长度：20。含义：学生的姓名。班级。类型：字符串型。长度：25。含义：学生班级。学生性别。类型：字符串类型。长度：2。含义：学生的性别只能是男生或者女生。床号。类型：整数。含义：学生睡的床号。不能超过宿舍最大人数。访客号：类型：字符串类型。长度25。含义：唯一标识访客信息。访客姓名。类型：字符串型。长度：20。含义：记录访客的姓名。访客电话。类型：字符串型。长度：20。含义：记录访客联系方式。访客日期。类型：时间类型。含义：记录访客访问时间。访客时间。类型：字符串型。长度：10。含义：记录访客具体访问时间。访问理由。类型：字符串型。长度：100。含义：描述访问原因。访客审批状态。类型：字符串型。长度：10。含义：审批状态只能是三种：待审核，已通过，未通过。离开时间。类型：字符串型。长度：10。含义：访客离开时间。核实状态：类型：字符串型。长度：10。含义：核实状态只能是三种：待核实，已核实，核实有误。维修单号。类型：字符串型。长度：20。含义：唯一区分维修单。维修时间。类型：时间类型。含义：记录维修时间。维修审核状态。类型：字符串型。长度：10。含义：审批状态只能是三种：待审核，已通过，未通过。维修状态。类型：字符串型。长度：10。含义：维修状态只能是三种：待审核，已维修，未维修。报销状态。类型：字符串型。长度：10。含义：报销状态只能是三种：待审核，已报销，未报销。维修人员姓名。类型：字符串型。长度10.含义：维修人员姓名。损坏描述。类型：字符串型。长度：100。含义：描述损坏原因。维修人员工号。类型：字符串型。长度：15。含义：唯一记录维修人员。维修人员性别。类型：字符串类型。长度：2。含义：维修人员的性别只能是男生或者女生。维修人员年龄。类型：整型。含义：记录维修人员年龄。维修评分。类型：整数类型。含义：评分大于等于0且小等用于100。维修具体评价。类型：字符串型。长度：100。含义：描述维修评价。报销金额。类型：字符串型。含义：报销费用。管理员账户、维修人员账户、用户账户。类型：字符串型。长度：100。含义：账号不能重复。密码。类型：字符串型。长度：100。含义：当密码正确时，才能登陆成功。

数据结构：

学生信息(学号，姓名，班级，性别，床位，居住宿舍)宿舍(宿舍门牌号，宿舍人数，宿舍地址)楼栋(楼栋号，楼栋地址)访客记录表(访客号，访问学生学号，访客姓名，访客电话，访客日期，访客时间，访问审批状态)访客报备表(访客号，离开状态，离开时间，核实状态)维修记录表(维修单号，维修宿舍号，维修时间，维修人员姓名，损坏原因描述，审核状态，维修状态)维修人员(工号，姓名，年龄，性别)评分表(维修单号，维修人员姓名，评分，具体评价)报销表(维修单号，维修人员姓名，报销金额，报销状态)账户登录表(账号，密码)

2.4 安全性和完整性

安全性要求：

设置管理员，维修员，用户多种角色。在设计时，对不同的角色赋予不同的权限。用户的权限有申请维修，访客申请。查询访客申请进度，查询维修进度。在维修人员维修完之后，用户还可以评分。除此以外，用户还可以查询修改个人信息，修改登录密码。维修人员的权限有查询选择维修单进行维修，还可以修改维修状态。查询维修评价。申请维修报销等。但是维修人员只能修改维修单上的部分属性。例如维修单号，维修地点，损坏原因等维修员是修改不了的。除此以外，维修员可以自己修改密码和查询个人信息。管理员被赋予的权限是最大的。管理员对所有基本表基本都可以进行增删改查。管理员还被赋予审核的权限。例如访客申请，管理员可以通过也可以拒绝访问。在管理员做出决策后，用户或者维修人员都可以查询到。

完整性要求：

无论是管理员，维修员还是用户他们的账号是主键，密码均不可以为空。学生的学号是主键，姓名，班级等均都不能为空。年龄为正整数。楼栋表中，楼栋号为主键，楼栋地址不为空。学生和维修人员的性别只能是男或者女。在宿舍表中，宿舍门牌号为主键，居住人数可为0，宿舍所处楼栋不能为空。维修人员信息表中，工号为主键，姓名不能为空。年龄为正整数且年龄要大于等于25。维修表中，维修号是主键。宿舍号是外码参照宿舍表。其中维修审核状态，维修状态不能为空且只能处于：待审核，已通过，未通过三种状态。评分表中，维修单号是外码，参照维修表。评分大于等于0且小于等于100且不为空。具体评价可为空。报销表中，报销单号为主键。维修单号和维修工姓名为外码参照维修人员表。报销金额不为空且为正整数。报销状态只能是:待审核，已报销，拒绝报销这三种。访客表中，访客号为主键。拜访学生学号为外键，参照学 生表。访客信号，访客电话，访客访问日期和访问理由均 不能为空。访客未离开时，离开报备无法提交删除宿舍时，把学生表中住在此宿舍的学生床位置0并且 把宿舍置空。维修表里的宿舍号码也置为空值。删除学生信息时，其所居住的宿舍人数减一。同时访客记录中与该学生对应的记录也会删除。当修改学生住宿的宿舍时，原宿舍人数减一，新宿舍人数加一。同时床位不能重复以及这个宿舍是否满员要进行判断。添加学生信息时，不能与已经存在的学生学号相同，同时若该学生入住某宿舍此宿舍人数加一。 概念结构的设计 实体属性

实体属性如图所示：

图1 实体属性图

3.2 实体间的联系(E-R图)

实体间联系见下图

图2 E-R图

3.3数据设计图

利用Power Designer 设计的数据库图如下所示：

图3 Power Designer设计图

4.逻辑结构设计

4.1关系模型

本文中，用下划线标识主码，用粗体标识外码

楼栋(楼栋号，楼栋位置)

宿舍(宿舍门牌号，宿舍人数，宿舍地址)

学生信息(学号，姓名，班级，性别，床位，居住宿舍)

维修人员(工号，姓名，年龄，性别)

访客记录表(访客号，访问学生学号，访客姓名，访客电话，访客 日期，访客时间，访问审批状态)

访客报备表(访客号，离开状态，离开时间，核实状态)

维修记录表(维修单号，维修宿舍号，维修时间，维修人员工号， 损坏原因描述，审核状态，维修状态)

评分表(维修单号，维修人员工号，评分，具体评价)

报销表(维修单号，维修人员工号，报销金额，报销状态)

账户登录表(账号，密码)

4.2 表格

楼栋表

表1 楼栋表

字段名	语义	类型	长度	主键	必须非空	外键
Bno	楼栋号	Char	20	√	√
Locate	楼栋位置	Char	30		√

宿舍表

表2 宿舍表

字段名	语义	类型	长度	主键	必须非空	外键
Did	宿舍号	Char	20	√	√
Dcapacity	居住人数	Int			√
Locate	位置	Char	30		√	√

学生信息表

表3 学生信息表

字段名	语义	类型	长度	主键	必须非空	外键
Sno	学号	Char	20	√	√
Sname	学生姓名	Char	20		√
Ssex	性别	Char	2		√
Sclass	班级	Char	20		√
Sbedno	床位	Int
Did	宿舍号	Char	20			√

维修人员表

表4维修人员信息表

字段名	语义	类型	长度	主键	必须非空	外键
Mno	学号	Char	20	√	√
Mname	学生姓名	Char	20		√
Msex	性别	Char	2		√
Mage	班级	int			√

报销表

表5 报销表

字段名	语义	类型	长度	主键	必须非空	外键
ID	报销号	Char	20	√	√
Rid	维修单号	Char	20		√	√
Mno	工号	Char	20		√	√
Rprice	报销金额	int			√
Restate	报销状态	Char	10		√

访客记录表

表6 访客记录表

字段名	语义	类型	长度	主键	必须非空	外键
RecordID	访客号	Char	50	√	√
Sno	学生学号	Char	20		√	√
Visitorname	访客姓名	Char	50		√
Visitorcontact	访客电话	Char	20		√
VisitDate	访客日期	date			√
VisitTime	访客时间	time			√
Remarks	访问理由	Char	100		√
Vstate	审批状态	Char	20		√

评分表

表7 评分表

字段名	语义	类型	长度	主键	必须非空	外键
Rid	维修单号	Char	20	√	√
Mno	维修工号	Char	20		√	√
score	评分	Int			√
remarks	评价	Char	100		√

登陆表

表8 登录表

字段名	语义	类型	长度	主键	必须非空	外键
ID	账号	Char	20	√	√
psw	密码	Char	20		√

维修表

表9 维修表

字段名	语义	类型	长度	主键	必须非空	外键
Rid	维修单号	Char	20	√	√
Did	宿舍号	Char	20		√	√
RepairDate	维修日期	date			√
Remarks	损坏描述	Char	100		√
Stuffname	维修人员	Char	20		√
Rstate	审批状态	Char	20		√
Restate	维修状态	Char	20		√

访客离开报备表

表10 访客离开报备表

字段名	语义	类型	长度	主键	必须非空	外键
RecordID	访客号	Char	20		√	√
Rstate	离开状态	Char	20		√
Rdate	离开日期	date			√
Restate	核实状态	Char	100		√

4.3 触发器与过程

当更换学生的宿舍时，原宿舍人数减一，新宿舍的人数加一。当学生提交维修申请时，维修表的审批状态自动置为待审批，维修状态自动置为待维修。当学生提交访客申请时，访客的审批状态自动置为待审批。当维修人员提交报销申请时，维修状态自动置为待审批。当管理员删除学生信息时，学生所在原宿舍人数自动减一，与之对应的访客记录删除。当管理员删除宿舍信息时，学生所在宿舍置为空值且床位置为0，同时对应的宿舍维修单里的宿舍号置为空。删除维修人员时，对应的报销表和维修表里维修人员的工号置为空值，但是维修和报销记录保留。

4.4 视图

当学生查询访客申请时，仅需知道管理员是否审批通过，所以为了更加让用户更加简洁的获取信息，在原表上创建行列子集视图，仅展示访客号，访客姓名，访问学生学号以及管理员审批结果。当管理员查询一个维修单的维修情况时，需要知道维修的情况和报销的金额，所以把维修评价表和报销表连接创建对应视图。维修师傅查询维修单时，仅能看见管理员审批通过的维修单。所以创建视图把管理员审批通过的且未维修的维修单展示出来(维修审批属性不展示)。

5.物理结构的设计

为学生表建立聚簇。按照学生学号设置为聚簇码能大大提高查询学生信息的速度。为宿舍表建立聚簇。按照宿舍门牌号设置为聚簇码能大大提高查询宿舍信息的速度。为维修表，访客表建立聚簇。因为这俩个表除了学生频繁查询外，管理人员也会频繁查询。因为报销表会被维修人员和管理人员频繁查询，所以按照报销单号建立聚簇索引。

6.功能设计

6.1 核心功能

在本次设计学生宿舍管理系统中，除了最基本的增删改查功能外，还添加了俩个功能闭环：维修功能闭环，访客功能闭环。

维修功能闭环：

学生提交维修申请。管理员对学生提交的申请进行审批。审批结果只有俩种情况： 通过或不通过。若管理员同意维修，维修人员可以在维修申请中查到此维修 单，选择此单并进行维修。维修完成后，学生可以对此次维修进行评价。维修人员也可 以在系统查到学生的评价。与此同时，维修人员填写报销表，提交报销申请。管理员审批报销表，核实是否属实然后选择是否报销同时备 份数据库保留历史数据。维修人员可以查询报销结果。

访客功能闭环：

学生提交访客申请。管理员对访客申请进行审批。审批结果俩种情况：同意或不 同意。学生查询审核结果，若通过访客访问。访客离开后，学生提交访客离开报备，告知管理员。管理员核实报备并且备份数据库保留历史数据。

6.2 功能模块

图4 功能模块总体设计图

管理员功能设计

管理员可以对所有表进行增删改查，基本上所有属性管理员都可以修改。管理员要对各种申请进行审核。如维修申请，报销申请，访客申请等等。管理员可以修改自己的信息。管理员可以查询管理员系统使用手册。

维修员功能设计

维修员可以查询维修单号并且进行维修。维修员可以查看学生对自己的维修评价。维修员可以提交报销申请。维修员可以修改个人信息。维修员可以查询维修员使用手册。

学生功能设计

学生可以提交维修申请，访客申请，访客离开报备。学生可以查询维修进度，访客申请进度。学生可以修改个人信息。学生可以查询学生使用手册。

系统实现

系统实现的展示顺序：首先展示登陆界面，然后展示管理员界面，接着展示维修员界面，最后展示管理员界面。展示的过程中会把不同界面的功能展示出来。除此以外最后会单独展示维修功能闭环和访客功能闭环。

7.1 登录界面

图5 登录界面

用户选择身份。若用户没有账号密码可以点击下方的蓝色字体注册。

图6 注册界面

若用户输入错误的账号密码，系统会报错登陆失败。

图7 登录失败界面

7.2 管理员界面

选择管理员，并成功登录。

图8 管理员主界面

修改密码

管理员可以修改个人登录密码点击右上角的系统，再点修改密码即可。

图9 修改密码界面

数据库备份

点击数据库备份功能，系统会把整个数据库备份到指定磁盘位置。

图10 数据库备份

审核功能

审核功能会在展示两个闭环时再具体介绍。、

图11 审核功能

学生信息管理功能

图12 学生界面

添加学生信息

增加一名学号为2023039名字为张伟且居住在201宿舍8号床的学生信息。

图13 添加学生界面

图14 添加学生结果

此处设置了触发器，当201宿舍增加一个人的时候原宿舍人数从3变为了4。

图15 添加学生结果

修改学生信息

把202039张伟的宿舍改到101去。原宿舍人数减一，新宿舍人数加一。

图16 修改学生界面

图17 修改学生结果

删除学生信息

删除202101刘东的信息。他原先居住的宿舍人数减一，同时访问他的访客信息中访问学生学号置为空。

图18 删除学生

图19 删除学生结果

图20 删除学生宿舍人数

图21 访客信息更改

学生查询

此处采用模糊查询，输入徐查询结果如下。

图22 学生信息查询

宿舍信息主界面

图23 宿舍信息主界面

新建宿舍和修改宿舍信息

新建一个202宿舍初始居住最大人数为6，之后修改为9。

图24 新建和修改学生信息

删除宿舍

删除宿舍101。住在此处的学生此时宿舍号置为空且床位号置为0，维修单此处的宿舍信息也置为空。

图25 未删除时学生信息

图26 删除后学生信息

图27 删除前维修单信息

图28 删除后维修单信息

查询宿舍信息

输入102。查询住在此宿舍的学生姓名。

图29 查询宿舍信息

维修信息管理，访客信息管理，维修人员信息管理界面

由于这个几个界面实现的功能就是增删查改，和前面的学生信息管理，宿舍信息管理操做极其类似，所以仅仅展示主界面，功能就不在赘述。

图30 维修主界面

图31 访客主界面

图32 维修员信息主界面

7.3 维修员界面

图33 维修员主界面

查询维修单号

图34 维修处理界面

注意：维修员能看到的维修单要管理员审核通过且未维修才会被显示出来。

输入010。查询维修单。

图35 查询结果

其他功能：维修评价，报销还有查询评价和报销进度会在维修功能闭环中详细说明，这里不在赘述。

7.4 学生主界面

图36 学生主界面

学生界面的所有功能将在维修闭环和访客闭环中详细说明，这里不再赘述。

7.5 维修闭环功能展示

学生提出维修申请

宿舍201玻璃损坏，学生提交维修申请。

图37 提交维修

管理员审批

图38 管理员审批

  管理员审批通过后，维修员可在维修列表中查到此维修申请。

维修员维修

图39 维修员接单

图40 维修员确认维修

学生查询维修进度和评分

图41 学生查询维修进度

图42 学生评价

维修员查询评价

图43 维修员查询评价

维修员报销申请

图44 维修员选择报销单

图45 维修员填写报销单

管理员审核报销

图46 管理员审核报销

管理员选择拒绝报销。

维修员查询报销

图47 维修员查询报销

7.6 访客闭环功能展示

学生提交访客申请

图48 学生提交访客申请

管理员审核

图49 管理员查询申请

图50 管理员审批

用户查询审批结果

图51 用户查询审批结果

用户报备访客离开

图52 用户提交离开备份

管理员核实并且备份

图53 管理员核实

由于未离开，所以管理员选择核实有误。

心得体会

学习数据库系统原理并完成数据课设后，我获得了宝贵的经验和深刻的体会。通过学习数据库系统原理，我深入了解了数据库的核心概念、数据模型和基本操作。我学会了如何设计和规划数据库结构，以及如何使用SQL语言进行数据查询和管理。

在完成数据课设的过程中，我亲身体验了数据库设计的挑战和乐趣。我需要分析问题需求，设计数据库表结构，优化查询性能，并实现各种复杂的查询功能。通过这个过程，我提高了数据建模和规范化的能力，同时也锻炼了问题解决和调试技巧。

此外，我意识到数据库的重要性和广泛应用的范围。无论是企业的数据管理、网站的后台系统还是科学研究领域，数据库都扮演着关键的角色。良好的数据库设计和高效的数据操作可以提高数据的可靠性、安全性和性能，对于组织和业务的发展至关重要。

总的来说，学习数据库系统原理并完成数据课设是一次充实而有价值的经历。我不仅获得了理论知识，还掌握了实际应用的技能。这些经验将对我的学习和职业发展产生长远的影响，使我更好地理解和应用数据库技术。