1.引言

1.1 內容及要求

設計內容：設計學生宿舍管理系統。

設計要求：

（1）數據庫應用系統開發的需求分析，寫出比較完善系統功能。

（2）數據庫概念模型設計、邏輯模型設計以及物理模型設計。

（3）完成功能模塊結構設計并編寫代碼實現。

（4）軟件總體測試及修改。

（5）撰寫軟件設計說明書。

1.2 系統環境選擇

1. 數據庫系統選擇：Microsoft SQL Server 2019
2. 數據庫管理系統選擇：Microsoft SQL Server Management Studio 18
3. 前端開發語言選擇：C#
4. 前端開發軟件：Visual Studio 2019
5. 前端開發框架：Windows 窗體應用(.NET Framework 4.8)

2.需求分析

2.1 設計背景

學生宿舍管理系統的設計背景源于對傳統宿舍管理方式的改進需求。傳統方式存在信息不透明、手動操作繁瑣等問題，導致住宿分配不公平、報修反饋滯后等困擾。通過引入宿舍管理系統，可以提高管理效率和便捷性，簡化操作流程，提供學生宿舍申請、報修、查詢等功能。系統能夠數字化宿舍分配，實現公平和透明，同時提供維修管理和訪客功能，提升宿舍管理質量和學生滿意度。數據統計和分析功能為管理員提供決策支持，幫助改進管理策略。通過系統，學生和管理員可以獲得準確、實時的宿舍信息，增加管理的透明性和公正性。綜上所述，學生宿舍管理系統的設計背景是為了提高管理效率、提供便捷服務、實現公平和透明的宿舍管理，提升學生生活質量和學習環境。

2.2 功能分析

系統需要有一個登錄頁面，不同用戶登錄后，對不同的功能具有不同的權限。數據庫用戶包括學生、維修員、管理員等多個角色。

信息要求：

• 管理員可以查詢學生信息、宿舍信息、維修人員信息、維修信息及訪客信息。
• 維修人員可以查詢修改維修單號、查詢維修評價等信息。
• 學生可以查詢訪客審批進度、維修進度等信息。

處理要求：

• 學生可以在系統內部報銷損壞，申請訪客訪問，訪客離開報備。在維修之后還可以對此次維修做出評價。
• 管理員看到學生提交上來的申請后會進行審批。審批的結果學生都可以查詢到。當維修申請通過后，此維修單將會自動傳遞給維修師傅，維修師傅便可以維修。在維修完之后管理員還要對維修人員提交的報銷進行審批，通過則報銷維修費用。管理員還會核實訪客離開的報備。
• 維修人員可以查詢到通過審批且未維修的單子從而選擇接單。維修完成后由維修人員提交維修完成表和報銷單。維修人員可以查詢報銷狀態和學生對自己的維修評價。

2.3 數據項和數據結構

數據項：

宿舍號、宿舍人數、宿舍地址、樓棟號、樓棟地址、學生學號、姓名、班級、學生性別、床號、訪客號、訪客姓名、訪客電話、訪客日期、訪客時間、訪問理由、訪客審批狀態、離開時間、核實狀態、維修單號、維修時間、維修審核狀態、維修狀態、報銷狀態、維修人員姓名、損壞描述、維修人員工號、維修人員性別、維修人員年齡、維修評分、維修具體評價、報銷金額、管理員賬戶、維修人員賬戶、用戶賬戶、密碼。

1. 宿舍號。類型：字符串型。長度：20。含義：唯一標識用來區別每個宿舍。
2. 宿舍人數。類型：整數類型。含義：記錄當前宿舍居住人數。
3. 宿舍地址。類型：字符串型。長度：40。含義：記錄宿舍地址。
4. 樓棟號。類型：字符串型。長度：20。含義：唯一標識樓棟。
5. 樓棟地址。類型：字符串型。長度：40。含義：記錄樓棟地址。
6. 學生學號。類型：字符串型。長度：20。含義：唯一標識學生。
7. 學生姓名。類型：字符串型。長度：20。含義：學生的姓名。
8. 班級。類型：字符串型。長度：25。含義：學生班級。
9. 學生性別。類型：字符串類型。長度：2。含義：學生的性別只能是男生或者女生。
10. 床號。類型：整數。含義：學生睡的床號。不能超過宿舍最大人數。
11. 訪客號：類型：字符串類型。長度25。含義：唯一標識訪客信息。
12. 訪客姓名。類型：字符串型。長度：20。含義：記錄訪客的姓名。
13. 訪客電話。類型：字符串型。長度：20。含義：記錄訪客聯系方式。
14. 訪客日期。類型：時間類型。含義：記錄訪客訪問時間。
15. 訪客時間。類型：字符串型。長度：10。含義：記錄訪客具體訪問時間。
16. 訪問理由。類型：字符串型。長度：100。含義：描述訪問原因。
17. 訪客審批狀態。類型：字符串型。長度：10。含義：審批狀態只能是三種：待審核，已通過，未通過。
18. 離開時間。類型：字符串型。長度：10。含義：訪客離開時間。
19. 核實狀態：類型：字符串型。長度：10。含義：核實狀態只能是三種：待核實，已核實，核實有誤。
20. 維修單號。類型：字符串型。長度：20。含義：唯一區分維修單。
21. 維修時間。類型：時間類型。含義：記錄維修時間。
22. 維修審核狀態。類型：字符串型。長度：10。含義：審批狀態只能是三種：待審核，已通過，未通過。
23. 維修狀態。類型：字符串型。長度：10。含義：維修狀態只能是三種：待審核，已維修，未維修。
24. 報銷狀態。類型：字符串型。長度：10。含義：報銷狀態只能是三種：待審核，已報銷，未報銷。
25. 維修人員姓名。類型：字符串型。長度10.含義：維修人員姓名。
26. 損壞描述。類型：字符串型。長度：100。含義：描述損壞原因。
27. 維修人員工號。類型：字符串型。長度：15。含義：唯一記錄維修人員。
28. 維修人員性別。類型：字符串類型。長度：2。含義：維修人員的性別只能是男生或者女生。
29. 維修人員年齡。類型：整型。含義：記錄維修人員年齡。
30. 維修評分。類型：整數類型。含義：評分大于等于0且小等用于100。
31. 維修具體評價。類型：字符串型。長度：100。含義：描述維修評價。
32. 報銷金額。類型：字符串型。含義：報銷費用。
33. 管理員賬戶、維修人員賬戶、用戶賬戶。類型：字符串型。長度：100。含義：賬號不能重復。
34. 密碼。類型：字符串型。長度：100。含義：當密碼正確時，才能登陸成功。

數據結構：

1. 學生信息(學號，姓名，班級，性別，床位，居住宿舍)
2. 宿舍(宿舍門牌號，宿舍人數，宿舍地址)
3. 樓棟(樓棟號，樓棟地址)
4. 訪客記錄表(訪客號，訪問學生學號，訪客姓名，訪客電話，訪客日期，訪客時間，訪問審批狀態)
5. 訪客報備表(訪客號，離開狀態，離開時間，核實狀態)
6. 維修記錄表(維修單號，維修宿舍號，維修時間，維修人員姓名，損壞原因描述，審核狀態，維修狀態)
7. 維修人員(工號，姓名，年齡，性別)
8. 評分表(維修單號，維修人員姓名，評分，具體評價)
9. 報銷表(維修單號，維修人員姓名，報銷金額，報銷狀態)
10. 賬戶登錄表(賬號，密碼)

2.4 安全性和完整性

安全性要求：

1. 設置管理員，維修員，用戶多種角色。
2. 在設計時，對不同的角色賦予不同的權限。
3. 用戶的權限有申請維修，訪客申請。查詢訪客申請進度，查詢維修進度。在維修人員維修完之后，用戶還可以評分。除此以外，用戶還可以查詢修改個人信息，修改登錄密碼。
4. 維修人員的權限有查詢選擇維修單進行維修，還可以修改維修狀態。查詢維修評價。申請維修報銷等。但是維修人員只能修改維修單上的部分屬性。例如維修單號，維修地點，損壞原因等維修員是修改不了的。除此以外，維修員可以自己修改密碼和查詢個人信息。
5. 管理員被賦予的權限是最大的。管理員對所有基本表基本都可以進行增刪改查。管理員還被賦予審核的權限。例如訪客申請，管理員可以通過也可以拒絕訪問。在管理員做出決策后，用戶或者維修人員都可以查詢到。

完整性要求：

1. 無論是管理員，維修員還是用戶他們的賬號是主鍵，密碼均不可以為空。
2. 學生的學號是主鍵，姓名，班級等均都不能為空。年齡為正整數。
3. 樓棟表中，樓棟號為主鍵，樓棟地址不為空。
4. 學生和維修人員的性別只能是男或者女。
5. 在宿舍表中，宿舍門牌號為主鍵，居住人數可為0，宿舍所處樓棟不能為空。
6. 維修人員信息表中，工號為主鍵，姓名不能為空。年齡為正整數且年齡要大于等于25。
7. 維修表中，維修號是主鍵。宿舍號是外碼參照宿舍表。其中維修審核狀態，維修狀態不能為空且只能處于：待審核，已通過，未通過三種狀態。
8. 評分表中，維修單號是外碼，參照維修表。評分大于等于0且小于等于100且不為空。具體評價可為空。
9. 報銷表中，報銷單號為主鍵。維修單號和維修工姓名為外碼參照維修人員表。報銷金額不為空且為正整數。報銷狀態只能是:待審核，已報銷，拒絕報銷這三種。
10. 訪客表中，訪客號為主鍵。拜訪學生學號為外鍵，參照學 生表。訪客信號，訪客電話，訪客訪問日期和訪問理由均 不能為空。
11. 訪客未離開時，離開報備無法提交
12. 刪除宿舍時，把學生表中住在此宿舍的學生床位置0并且 把宿舍置空。維修表里的宿舍號碼也置為空值。
13. 刪除學生信息時，其所居住的宿舍人數減一。同時訪客記錄中與該學生對應的記錄也會刪除。當修改學生住宿的宿舍時，原宿舍人數減一，新宿舍人數加一。同時床位不能重復以及這個宿舍是否滿員要進行判斷。添加學生信息時，不能與已經存在的學生學號相同，同時若該學生入住某宿舍此宿舍人數加一。

1. 概念結構的設計
   1. 實體屬性

實體屬性如圖所示：

圖1 實體屬性圖

3.2 實體間的聯系(E-R圖)

實體間聯系見下圖

圖2 E-R圖

3.3數據設計圖

利用Power Designer 設計的數據庫圖如下所示：

圖3 Power Designer設計圖

4.邏輯結構設計

4.1關系模型

本文中，用下劃線標識主碼，用粗體標識外碼

樓棟(樓棟號，樓棟位置)

宿舍(宿舍門牌號，宿舍人數，宿舍地址)

學生信息(學號，姓名，班級，性別，床位，居住宿舍)

維修人員(工號，姓名，年齡，性別)

訪客記錄表(訪客號，訪問學生學號，訪客姓名，訪客電話，訪客 日期，訪客時間，訪問審批狀態)

訪客報備表(訪客號，離開狀態，離開時間，核實狀態)

維修記錄表(維修單號，維修宿舍號，維修時間，維修人員工號， 損壞原因描述，審核狀態，維修狀態)

評分表(維修單號，維修人員工號，評分，具體評價)

報銷表(維修單號，維修人員工號，報銷金額，報銷狀態)

賬戶登錄表(賬號，密碼)

4.2 表格

1. 樓棟表

表1 樓棟表

字段名	語義	類型	長度	主鍵	必須非空	外鍵
Bno	樓棟號	Char	20	√	√
Locate	樓棟位置	Char	30		√

1. 宿舍表

表2 宿舍表

字段名	語義	類型	長度	主鍵	必須非空	外鍵
Did	宿舍號	Char	20	√	√
Dcapacity	居住人數	Int			√
Locate	位置	Char	30		√	√

1. 學生信息表

表3 學生信息表

字段名	語義	類型	長度	主鍵	必須非空	外鍵
Sno	學號	Char	20	√	√
Sname	學生姓名	Char	20		√
Ssex	性別	Char	2		√
Sclass	班級	Char	20		√
Sbedno	床位	Int
Did	宿舍號	Char	20			√

1. 維修人員表

表4維修人員信息表

字段名	語義	類型	長度	主鍵	必須非空	外鍵
Mno	學號	Char	20	√	√
Mname	學生姓名	Char	20		√
Msex	性別	Char	2		√
Mage	班級	int			√

1. 報銷表

表5 報銷表

字段名	語義	類型	長度	主鍵	必須非空	外鍵
ID	報銷號	Char	20	√	√
Rid	維修單號	Char	20		√	√
Mno	工號	Char	20		√	√
Rprice	報銷金額	int			√
Restate	報銷狀態	Char	10		√

1. 訪客記錄表

表6 訪客記錄表

字段名	語義	類型	長度	主鍵	必須非空	外鍵
RecordID	訪客號	Char	50	√	√
Sno	學生學號	Char	20		√	√
Visitorname	訪客姓名	Char	50		√
Visitorcontact	訪客電話	Char	20		√
VisitDate	訪客日期	date			√
VisitTime	訪客時間	time			√
Remarks	訪問理由	Char	100		√
Vstate	審批狀態	Char	20		√

1. 評分表

表7 評分表

字段名	語義	類型	長度	主鍵	必須非空	外鍵
Rid	維修單號	Char	20	√	√
Mno	維修工號	Char	20		√	√
score	評分	Int			√
remarks	評價	Char	100		√

1. 登陸表

表8 登錄表

字段名	語義	類型	長度	主鍵	必須非空	外鍵
ID	賬號	Char	20	√	√
psw	密碼	Char	20		√

1. 維修表

表9 維修表

字段名	語義	類型	長度	主鍵	必須非空	外鍵
Rid	維修單號	Char	20	√	√
Did	宿舍號	Char	20		√	√
RepairDate	維修日期	date			√
Remarks	損壞描述	Char	100		√
Stuffname	維修人員	Char	20		√
Rstate	審批狀態	Char	20		√
Restate	維修狀態	Char	20		√

1. 訪客離開報備表

表10 訪客離開報備表

字段名	語義	類型	長度	主鍵	必須非空	外鍵
RecordID	訪客號	Char	20		√	√
Rstate	離開狀態	Char	20		√
Rdate	離開日期	date			√
Restate	核實狀態	Char	100		√

4.3 觸發器與過程

1. 當更換學生的宿舍時，原宿舍人數減一，新宿舍的人數加一。
2. 當學生提交維修申請時，維修表的審批狀態自動置為待審批，維修狀態自動置為待維修。
3. 當學生提交訪客申請時，訪客的審批狀態自動置為待審批。
4. 當維修人員提交報銷申請時，維修狀態自動置為待審批。
5. 當管理員刪除學生信息時，學生所在原宿舍人數自動減一，與之對應的訪客記錄刪除。
6. 當管理員刪除宿舍信息時，學生所在宿舍置為空值且床位置為0，同時對應的宿舍維修單里的宿舍號置為空。
7. 刪除維修人員時，對應的報銷表和維修表里維修人員的工號置為空值，但是維修和報銷記錄保留。

4.4 視圖

1. 當學生查詢訪客申請時，僅需知道管理員是否審批通過，所以為了更加讓用戶更加簡潔的獲取信息，在原表上創建行列子集視圖，僅展示訪客號，訪客姓名，訪問學生學號以及管理員審批結果。
2. 當管理員查詢一個維修單的維修情況時，需要知道維修的情況和報銷的金額，所以把維修評價表和報銷表連接創建對應視圖。
3. 維修師傅查詢維修單時，僅能看見管理員審批通過的維修單。所以創建視圖把管理員審批通過的且未維修的維修單展示出來(維修審批屬性不展示)。

5.物理結構的設計

1. 為學生表建立聚簇。按照學生學號設置為聚簇碼能大大提高查詢學生信息的速度。
2. 為宿舍表建立聚簇。按照宿舍門牌號設置為聚簇碼能大大提高查詢宿舍信息的速度。
3. 為維修表，訪客表建立聚簇。因為這倆個表除了學生頻繁查詢外，管理人員也會頻繁查詢。
4. 因為報銷表會被維修人員和管理人員頻繁查詢，所以按照報銷單號建立聚簇索引。

6.功能設計

6.1 核心功能

在本次設計學生宿舍管理系統中，除了最基本的增刪改查功能外，還添加了倆個功能閉環：維修功能閉環，訪客功能閉環。

維修功能閉環：

• 學生提交維修申請。
• 管理員對學生提交的申請進行審批。審批結果只有倆種情況： 通過或不通過。
• 若管理員同意維修，維修人員可以在維修申請中查到此維修 單，選擇此單并進行維修。
• 維修完成后，學生可以對此次維修進行評價。維修人員也可 以在系統查到學生的評價。
• 與此同時，維修人員填寫報銷表，提交報銷申請。
• 管理員審批報銷表，核實是否屬實然后選擇是否報銷同時備 份數據庫保留歷史數據。
• 維修人員可以查詢報銷結果。

訪客功能閉環：

• 學生提交訪客申請。
• 管理員對訪客申請進行審批。審批結果倆種情況：同意或不 同意。
• 學生查詢審核結果，若通過訪客訪問。
• 訪客離開后，學生提交訪客離開報備，告知管理員。
• 管理員核實報備并且備份數據庫保留歷史數據。

6.2 功能模塊

圖4 功能模塊總體設計圖

管理員功能設計

1. 管理員可以對所有表進行增刪改查，基本上所有屬性管理員都可以修改。
2. 管理員要對各種申請進行審核。如維修申請，報銷申請，訪客申請等等。
3. 管理員可以修改自己的信息。
4. 管理員可以查詢管理員系統使用手冊。

維修員功能設計

1. 維修員可以查詢維修單號并且進行維修。
2. 維修員可以查看學生對自己的維修評價。
3. 維修員可以提交報銷申請。
4. 維修員可以修改個人信息。
5. 維修員可以查詢維修員使用手冊。

學生功能設計

1. 學生可以提交維修申請，訪客申請，訪客離開報備。
2. 學生可以查詢維修進度，訪客申請進度。
3. 學生可以修改個人信息。
4. 學生可以查詢學生使用手冊。

1. 系統實現

系統實現的展示順序：首先展示登陸界面，然后展示管理員界面，接著展示維修員界面，最后展示管理員界面。展示的過程中會把不同界面的功能展示出來。除此以外最后會單獨展示維修功能閉環和訪客功能閉環。

7.1 登錄界面

圖5 登錄界面

用戶選擇身份。若用戶沒有賬號密碼可以點擊下方的藍色字體注冊。

圖6 注冊界面

若用戶輸入錯誤的賬號密碼，系統會報錯登陸失敗。

圖7 登錄失敗界面

7.2 管理員界面

選擇管理員，并成功登錄。

圖8 管理員主界面

1. 修改密碼

管理員可以修改個人登錄密碼點擊右上角的系統，再點修改密碼即可。

圖9 修改密碼界面

1. 數據庫備份

點擊數據庫備份功能，系統會把整個數據庫備份到指定磁盤位置。

圖10 數據庫備份

1. 審核功能

審核功能會在展示兩個閉環時再具體介紹。、

圖11 審核功能

1. 學生信息管理功能

圖12 學生界面

1. 添加學生信息

增加一名學號為2023039名字為張偉且居住在201宿舍8號床的學生信息。

圖13 添加學生界面

圖14 添加學生結果

此處設置了觸發器，當201宿舍增加一個人的時候原宿舍人數從3變為了4。

圖15 添加學生結果

1. 修改學生信息

把202039張偉的宿舍改到101去。原宿舍人數減一，新宿舍人數加一。

圖16 修改學生界面

圖17 修改學生結果

1. 刪除學生信息

刪除202101劉東的信息。他原先居住的宿舍人數減一，同時訪問他的訪客信息中訪問學生學號置為空。

圖18 刪除學生

圖19 刪除學生結果

圖20 刪除學生宿舍人數

圖21 訪客信息更改

1. 學生查詢

此處采用模糊查詢，輸入徐查詢結果如下。

圖22 學生信息查詢

1. 宿舍信息主界面

圖23 宿舍信息主界面

1. 新建宿舍和修改宿舍信息

新建一個202宿舍初始居住最大人數為6，之后修改為9。

圖24 新建和修改學生信息

1. 刪除宿舍

刪除宿舍101。住在此處的學生此時宿舍號置為空且床位號置為0，維修單此處的宿舍信息也置為空。

圖25 未刪除時學生信息

圖26 刪除后學生信息

圖27 刪除前維修單信息

圖28 刪除后維修單信息

1. 查詢宿舍信息

輸入102。查詢住在此宿舍的學生姓名。

圖29 查詢宿舍信息

1. 維修信息管理，訪客信息管理，維修人員信息管理界面

由于這個幾個界面實現的功能就是增刪查改，和前面的學生信息管理，宿舍信息管理操做極其類似，所以僅僅展示主界面，功能就不在贅述。

圖30 維修主界面

圖31 訪客主界面

圖32?維修員信息主界面

7.3 維修員界面

圖33?維修員主界面

1. 查詢維修單號

圖34?維修處理界面

注意：維修員能看到的維修單要管理員審核通過且未維修才會被顯示出來。

輸入010。查詢維修單。

圖35 查詢結果

其他功能：維修評價，報銷還有查詢評價和報銷進度會在維修功能閉環中詳細說明，這里不在贅述。

7.4 學生主界面

圖36 學生主界面

學生界面的所有功能將在維修閉環和訪客閉環中詳細說明，這里不再贅述。

7.5 維修閉環功能展示

1. 學生提出維修申請

宿舍201玻璃損壞，學生提交維修申請。

圖37 提交維修

1. 管理員審批

圖38 管理員審批

??管理員審批通過后，維修員可在維修列表中查到此維修申請。

1. 維修員維修

圖39 維修員接單

圖40 維修員確認維修

1. 學生查詢維修進度和評分

圖41 學生查詢維修進度

圖42 學生評價

1. 維修員查詢評價

圖43 維修員查詢評價

1. 維修員報銷申請

圖44 維修員選擇報銷單

圖45 維修員填寫報銷單

1. 管理員審核報銷

圖46 管理員審核報銷

管理員選擇拒絕報銷。

1. 維修員查詢報銷

圖47 維修員查詢報銷

7.6 訪客閉環功能展示

1. 學生提交訪客申請

圖48 學生提交訪客申請

1. 管理員審核

圖49 管理員查詢申請

圖50 管理員審批

1. 用戶查詢審批結果

圖51 用戶查詢審批結果

1. 用戶報備訪客離開

圖52 用戶提交離開備份

1. 管理員核實并且備份

圖53 管理員核實

由于未離開，所以管理員選擇核實有誤。

1. 心得體會

學習數據庫系統原理并完成數據課設后，我獲得了寶貴的經驗和深刻的體會。通過學習數據庫系統原理，我深入了解了數據庫的核心概念、數據模型和基本操作。我學會了如何設計和規劃數據庫結構，以及如何使用SQL語言進行數據查詢和管理。

在完成數據課設的過程中，我親身體驗了數據庫設計的挑戰和樂趣。我需要分析問題需求，設計數據庫表結構，優化查詢性能，并實現各種復雜的查詢功能。通過這個過程，我提高了數據建模和規范化的能力，同時也鍛煉了問題解決和調試技巧。

此外，我意識到數據庫的重要性和廣泛應用的范圍。無論是企業的數據管理、網站的后臺系統還是科學研究領域，數據庫都扮演著關鍵的角色。良好的數據庫設計和高效的數據操作可以提高數據的可靠性、安全性和性能，對于組織和業務的發展至關重要。

總的來說，學習數據庫系統原理并完成數據課設是一次充實而有價值的經歷。我不僅獲得了理論知識，還掌握了實際應用的技能。這些經驗將對我的學習和職業發展產生長遠的影響，使我更好地理解和應用數據庫技術。