数据库课设---学生宿舍管理系统(sql server+C#)

****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. 实体属性

实体属性如图所示：

图1 实体属性图

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

实体间联系见下图

图2 E-R图

3.3数据设计图

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

图3 Power Designer设计图

4.逻辑结构设计

4.1关系模型

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

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

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

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

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

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

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

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

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

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

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

4.2 表格

楼栋表

表1 楼栋表

字段名

语义

类型

长度

主键

必须非空

外键

Bno

楼栋号

Char

√

Locate

楼栋位置

Char

√

宿舍表

表2 宿舍表

字段名

语义

类型

长度

主键

必须非空

外键

Did

宿舍号

Char

√

Dcapacity

居住人数

Int

√

Locate

位置

Char

√

学生信息表

表3 学生信息表

字段名

语义

类型

长度

主键

必须非空

外键

Sno

学号

Char

√

Sname

学生姓名

Char

√

Ssex

性别

Char

√

Sclass

班级

Char

√

Sbedno

床位

Int

Did

宿舍号

Char

√

维修人员表

表4维修人员信息表

字段名

语义

类型

长度

主键

必须非空

外键

Mno

学号

Char

√

Mname

学生姓名

Char

√

Msex

性别

Char

√

Mage

班级

int

√

报销表

表5 报销表

字段名

语义

类型

长度

主键

必须非空

外键

报销号

Char

√

Rid

维修单号

Char

√

Mno

工号

Char

√

Rprice

报销金额

int

√

Restate

报销状态

Char

√

访客记录表

表6 访客记录表

字段名

语义

类型

长度

主键

必须非空

外键

RecordID

访客号

Char

√

Sno

学生学号

Char

√

Visitorname

访客姓名

Char

√

Visitorcontact

访客电话

Char

√

VisitDate

访客日期

date

√

VisitTime

访客时间

time

√

Remarks

访问理由

Char

100

√

Vstate

审批状态

Char

√

评分表

表7 评分表

字段名

语义

类型

长度

主键

必须非空

外键

Rid

维修单号

Char

√

Mno

维修工号

Char

√

score

评分

Int

√

remarks

评价

Char

100

√

登陆表

表8 登录表

字段名

语义

类型

长度

主键

必须非空

外键

账号

Char

√

psw

密码

Char

√

维修表

表9 维修表

字段名

语义

类型

长度

主键

必须非空

外键

Rid

维修单号

Char

√

Did

宿舍号

Char

√

RepairDate

维修日期

date

√

Remarks

损坏描述

Char

100

√

Stuffname

维修人员

Char

√

Rstate

审批状态

Char

√

Restate

维修状态

Char

√

访客离开报备表

表10 访客离开报备表

字段名

语义

类型

长度

主键

必须非空

外键

RecordID

访客号

Char

√

Rstate

离开状态

Char

√

Rdate

离开日期

date

√

Restate

核实状态

Char

100

√

4.3 触发器与过程

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

4.4 视图

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