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语言举行数据查询和管理。
在完成数据课设的过程中，我亲身体验了数据库计划的挑战和乐趣。我需要分析题目需求，计划数据库表结构，优化查询性能，并实现各种复杂的查询功能。通过这个过程，我进步了数据建模和规范化的能力，同时也锻炼了题目办理和调试技巧。
此外，我意识到数据库的重要性和广泛应用的范围。无论是企业的数据管理、网站的后台体系照旧科学研究领域，数据库都扮演着关键的角色。良好的数据库计划和高效的数据操作可以进步数据的可靠性、安全性和性能，对于构造和业务的发展至关重要。
总的来说，学习数据库体系原理并完成数据课设是一次充实而有价值的经历。我不仅得到了理论知识，还掌握了实际应用的技能。这些经验将对我的学习和职业发展产生长远的影响，使我更好地理解和应用数据库技术。
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。 | 
