宿舍信息管理系統(tǒng)

1、數(shù)據(jù)庫系統(tǒng)原理課程設計報告題目：宿舍信息管理系統(tǒng)專業(yè)班級： 2016級軟件工程（2）班 指導教師： 王曉妍 學生姓名一： 趙欣睿 完成任務 ： 需求分析 （頁碼起止：38 ） 學生姓名二： 陳思慧 完成任務 ： 數(shù)據(jù)實施 （頁碼起止： 1923 ） 學生姓名三： 劉偉 完成任務 ： 概念設計 （頁碼起止： 1114 ） 學生姓名四： 崔子涵 完成任務 ： 邏輯設計 （頁碼起止： 1517 ） 目錄1 引言11.1 問題描述11.2開發(fā)環(huán)境和運行環(huán)境12 需求分析32.1系統(tǒng)功能基本的要求32.2企業(yè)對系統(tǒng)實現(xiàn)的要求32.4數(shù)據(jù)流程62.5數(shù)據(jù)字典83 概念設計113.1設計分e-r圖113.2

2、設計完成的總e-r圖144 邏輯結構設計154.1圖向關系模式的轉換154.2關系模型的優(yōu)化174.3用戶子模式的設計175物理結構設計階段186數(shù)據(jù)實施和維護196.1建立數(shù)據(jù)庫196.2建表196.3建查詢206.4建存儲過程226.5建觸發(fā)器237總結25參考文獻261 引言1.1 問題描述學生宿舍管理系統(tǒng)對于一個學校來說是必不可少的組成部分。目前好多學校還停留在宿舍管理人員手工記錄數(shù)據(jù)的最初階段，手工記錄對于規(guī)模小的學校來說還勉強可以接受，但對于學生信息量比較龐大，需要記錄存檔的數(shù)據(jù)比較多的高校來說，人工記錄是相當麻煩的。而且當查找某條記錄時，由于數(shù)據(jù)量龐大，還只能靠人工去一條一條的查

3、找，這樣不但麻煩還浪費了許多時間，效率也比較低。當今社會是飛速進步的世界，原始的記錄方式已經(jīng)被社會所淘汰了，計算機化管理正是適應時代的產(chǎn)物。信息世界永遠不會是一個平靜的世界，當一種技術不能滿足需求時，就會有新的技術誕生并取代舊技術。21 世紀的今天,信息社會占著主流地位，計算機在各行各業(yè)中的運用已經(jīng)得到普及，自動化、信息化的管理越來越廣泛應用于各個領域。我們針對如此，設計了一套學生宿舍管理系統(tǒng)。學生宿舍管理系統(tǒng)采用的是計算機化管理，系統(tǒng)做的盡量人性化，使用者會感到操作非常方便，管理人員需要做的就是將數(shù)據(jù)輸入到系統(tǒng)的數(shù)據(jù)庫中去。由于數(shù)據(jù)庫存儲容量相當大，而且比較穩(wěn)定，適合較長時間的保存，也不容易

4、丟失。這無疑是為信息存儲量比較大的學校提供了一個方便、快捷的操作方式。本系統(tǒng)具有運行速度快、安全性高、穩(wěn)定性好的優(yōu)點，并且具備修改功能，能夠快速的查詢學校所需的住宿信息。面對目前學校發(fā)展的實際狀況，我們通過實地調研之后，對宿舍管理系統(tǒng)的設計開發(fā)做了一個詳細的概述。1.2開發(fā)環(huán)境和運行環(huán)境本學生宿舍信息管理系統(tǒng)(數(shù)據(jù)庫系統(tǒng)) 的開發(fā)運行環(huán)境如下: 開發(fā)環(huán)境：Windows7數(shù)據(jù)庫管理系統(tǒng): MYSQL 5.5硬件運行環(huán)境:服務器:最低配置 P以上 CPU, 256MB 以上內存， 1G 以上硬盤空間。客戶端:最低配置 P以上 CPU, 128 MB 以上內存， 400M 以上硬盤空間。

5、軟件環(huán)境:服務器操作系統(tǒng):Windows2000Server 企業(yè)版客戶端操作系統(tǒng): WindowsXP/Windows7,瀏覽器要求 IE6.0 以上后臺數(shù)據(jù)庫系統(tǒng):MYSQL 5.5 及以上版本 數(shù)據(jù)庫的建立需要 MYSQL 來實現(xiàn)， 本系統(tǒng)實現(xiàn)使用的是 MYSQL 5.5， 它適用于MYSQL 5.5 及以上版本。2 需求分析2.1系統(tǒng)功能基本的要求宿舍管理的主要工作是學校宿舍基本信息的錄入：為學生分、退宿舍和繳費；宿舍衛(wèi)生檢查；水電費的收??；宿舍、學生的查詢以及對來訪人員的登記。宿舍分配的過程是：新生入學之前，每個園區(qū)將接到安排在本園區(qū)住宿的同學名單，并根據(jù)學生基本信息按約定的分配原則

6、給每個學生初定宿舍床位。一般的分配原則是：同一學院的學生應該分配在同一幢樓，同一班級的學生應該分配在房號連續(xù)的寢室。當學生報到后，宿舍管理員根據(jù)住宿分配情況開出需支付的住宿費清單，學生到財務處繳費后方可入住。宿舍分配結束后，宿舍管理員對學生住房情況、房產(chǎn)信息進行維護、查詢、管理、統(tǒng)計。2.2企業(yè)對系統(tǒng)實現(xiàn)的要求系統(tǒng)要處理的對象包括用戶系統(tǒng)登錄信息、入住學生基本信息、宿舍基本信息、宿舍衛(wèi)生檢查信息、宿舍水電繳費信息、宿舍公物報修信息、來訪登記信息等八個方面，各個對象包括信息如下所示（詳細的數(shù)據(jù)見于數(shù)據(jù)字典）：1.用戶系統(tǒng)登錄信息：包括添加用戶，修改密碼，退出系統(tǒng)等方面，這樣2.可以方便管理者對宿

7、舍樓的管理，提高查詢效率；3.學生基本信息：包括 學號、學生姓名、學生性別、學生所學專業(yè)、宿舍號、入住時間等方面的信息，可以方便學生信息的查詢和更新；4宿舍基本信息：宿舍基本信息包括宿舍號、宿舍電話、住宿費、宿舍財產(chǎn)；5宿舍衛(wèi)生檢查信息：包括宿舍號、檢查情況、檢查日期；6宿舍水電繳費信息：包括宿舍號、繳費人、繳費量、繳費日期等四方面的信息；7宿舍公物報修信息：報修信息包括宿舍號、報修人、保修日期、修理日期、報修情況等信息，具體的數(shù)據(jù)項見數(shù)據(jù)字典；8.來訪登記信息：包括宿舍號、來訪人、被訪人、來訪時間、離開時間、備注等信息。2.2.1.信息要求:信息的錄入是通過系統(tǒng)錄入學生的情況，保證了學生住宿

8、情況的完整性，查詢則是可以對有所或者個別要了解學生的情況進行分類查詢，系統(tǒng)的查詢可以一步到位，并且模糊查詢減小了在不知道學生具體情況下查詢的難度。 2.2.2.處理要求：當學生基本信息發(fā)生變化時，宿舍樓管理員能對其進行修改。比如，某些同學搬到其他的宿舍中去，他們在本宿舍樓中相應的記錄就應該刪去；或者學生轉換專業(yè)，他們記錄中院系的信息也要作相應的修改等等。 當宿舍樓的電話號碼發(fā)生變更時，宿舍樓管理員能根據(jù)有關證明做出修改。 當快件到達本宿舍樓時，宿舍樓管理員應依據(jù)到達快件的相關信息在快件信息中插入一條記錄，當同學們接收快件后，管理員應登記快件的接收時間，表明該信件已成功到達收

9、信人的手中。2.2.3.安全性與完整性要求：1.安全性要求 (1).系統(tǒng)應對不同的數(shù)據(jù)設置不同的訪問級別，限制訪問用戶可查詢和處理數(shù)據(jù)的類別和內容；(2).系統(tǒng)實現(xiàn)：數(shù)據(jù)備份、數(shù)據(jù)恢復，以防止重大失誤、或是系統(tǒng)故障引起的損失； 2.完整性要求(1).各種信息記錄的完整性，信息記錄內容不能為空；(2).各種數(shù)據(jù)間相互的聯(lián)系的正確性；(3).相同的數(shù)據(jù)在不同記錄中的一致性。2.3系統(tǒng)功能的設計通過對用戶需求和系統(tǒng)設計思想的分析，可以得出該宿舍管理信息系統(tǒng)大致可以分為幾大模塊：宿舍基本信息模塊、學生入住模塊、衛(wèi)生檢查模塊、水電收費模塊、宿舍報表維修模塊、外來人員登記模塊系統(tǒng)業(yè)務流程圖：圖2.3-1

10、系統(tǒng)業(yè)務流程圖系統(tǒng)功能模塊圖：圖2.3-2 系統(tǒng)總功能模塊圖主要模塊的功能：1.宿舍基本信息模塊：添加、修改、查詢和刪除宿舍基本信息，如宿舍房號，財產(chǎn)，床位等。2.學生入住模塊：添加、修改、查詢和刪除學生入住、退宿信息，包括學生一些基本信息、繳費等。3.衛(wèi)生檢查模塊：對宿舍衛(wèi)生檢查、評比、統(tǒng)計等。4.水電收費模塊：對超出規(guī)定部分的水電收費管理。5.宿舍保修模塊：對報修情況的登記、時間安排、修理結果檢查等。6.來訪人員登記模塊：來訪人員的登記管理等。2.4數(shù)據(jù)流程數(shù)據(jù)流圖圖2.4-1 宿舍信息管理系統(tǒng)總數(shù)據(jù)流圖圖2.4-2 宿舍信息登記分數(shù)據(jù)流圖圖2.4-3 宿舍衛(wèi)生檢查分數(shù)據(jù)流圖圖2.4-4

11、宿舍水電收費分數(shù)據(jù)流圖圖2.4-5宿舍報修分數(shù)據(jù)流圖圖2.4-6來訪人員登記分數(shù)據(jù)流圖2.5數(shù)據(jù)字典部分重要表：表2.5-1 用戶數(shù)據(jù)字典序號列名數(shù)據(jù)類型長度小數(shù)位標識主鍵允許空默認值說明備注1UnameVarchar206是是否用戶ID2UpasswordVarchar204否用戶密碼表2.5-2 住宿學生數(shù)據(jù)字典序號列名數(shù)據(jù)類型長度小數(shù)位標識主鍵允許空默認值說明備注1SnoVarchar20是是否Lis學號住宿學生學號2SnameVarchar20姓名住宿學生姓名3Ssex0Varchar4性別4SdeptVarchar40專業(yè)學生專業(yè)5DnoVarchar6宿舍號住宿學生住宿號6Sche

12、ckinVarchar8入住時間新生搬入時間表2.5-3 學生宿舍數(shù)據(jù)字典序號列名數(shù)據(jù)類型長度小數(shù)位標識主鍵允許空默認值說明備注1Dnovarchar6是是否宿舍號2Dphonevarchar15是否否宿舍電話3PnameVarchar20否宿舍財產(chǎn)表2.5-4 報修數(shù)據(jù)字典序號列名數(shù)據(jù)類型長度小數(shù)位標識主鍵允許空默認值說明備注1Dnovarchar6是是否宿舍號報修人宿舍號2Pnovarchar2否物品號報修物品編號3Rsubmitvarchar8是提交日期報修提交日期4Rsolvevarchar8是解決日期問題解決日期 5RreasonVarchar50否保修原因物品損壞原因 表2.5-5

13、 衛(wèi)生檢查數(shù)據(jù)字典序號列名數(shù)據(jù)類型長度小數(shù)位標識主鍵允許空默認值說明備注1Dnovarchar6否宿舍號檢查宿舍號2ChTimevarchar14檢查時間衛(wèi)生檢查時間3ChResultvarchar10 否檢查結果衛(wèi)生檢查評定 表2.5-6 水電數(shù)據(jù)字典序號列名數(shù)據(jù)類型長度小數(shù)位標識主鍵允許空默認值說明備注1Dnovarchar6否宿舍號水電宿舍號2CostVarchar8否已用費用水電消費情況3LeftFeeVarchar8否剩余費用水電剩余情況4CtFeevarchar8否續(xù)交費用續(xù)交水電費用表2.5-7來訪人員數(shù)據(jù)字典序號列名數(shù)據(jù)類型長度小數(shù)位標識主鍵允許空默認值說明備注1SnoVarc

14、har20否學號住宿學生學號2Snamevarchar20 否姓名住宿學生姓名3SsexVarchar4否性別4SdeptVarchar40否專業(yè)學生專業(yè)5DnoMoney6否宿舍號被訪學生宿舍號6ScheckinMoney8否進入時間正課時間被訪進入時間7OutTimeMoney8否離開時間正課時間被訪結束后外出時間3 概念設計3.1實體聯(lián)系圖 由于表格過多只列舉部分表格設計實體聯(lián)系圖如下：圖3.1-1 宿舍信息表實體聯(lián)系圖（被參照關系）圖3.1-2 學生信息表實體聯(lián)系圖（參照關系）圖3.1-3 宿舍報修信息表實體聯(lián)系圖（參照關系）圖3.1-4 衛(wèi)生檢查信息表實體聯(lián)系圖（參照關系）圖3.1-

15、5 水電收費信息表實體聯(lián)系圖（參照關系）圖3.1-6 來訪人員信息表實體聯(lián)系圖（參照關系）3.2設計完成的總e-r圖圖3.2-1 總 E-R 圖4 邏輯結構設計4.1圖向關系模式的轉換部分關系模式如下：Dorm (dormID, phone, Dmoney, bedNum, chairNum, deskNum, DRemark)Student (SID, Sname ,Ssex , class, dormID, phone)Checkinfo (checkID ,dormID ,CDate ,CSate , CRemark)Charge (chargeID, dormID, MDate, EB

16、uy, CPerson, CMoney)Repair (repairID, dormID, DateIn, DateRepair, Person, repair, reason, repairmoney )Register (RegisterID,PcomeID,PcomeName,DateCome,Plook,dormID,Dateleave,Remark)主碼：灰色背景外碼：加粗字體4.2關系模型的優(yōu)化有了關系模型，可以進一步優(yōu)化，方法為：a.確定數(shù)據(jù)依賴。b.對數(shù)據(jù)依賴進行極小化處理，消除冗余聯(lián)系（參看范式理論）。c.確定范式級別，根據(jù)應用環(huán)境，對某些模式進行合并或分解。具體操作為：確定

17、了各關系的主鍵，確定關系的聯(lián)系，如外鍵等。如，student（DormID）>dorm（DormID）repair（DormID）>dorm（DormID）等等另外對冗余關系進行合并或分解。4.3用戶子模式的設計這部分主要是考慮使用方便性和效率問題，主要借助視圖手段實現(xiàn)，包括：a.建立視圖，使用更符合用戶習慣的別名。b.對不同級別的用戶定義不同的視圖，以保證系統(tǒng)的安全性。c.對復雜的查詢操作，可以定義視圖，簡化用戶對系統(tǒng)的使用。針對一般用戶查詢學號，姓名，宿舍號，宿舍電話比較頻繁，建立一個包括學號，姓名，宿舍號，宿舍電話的視圖：視圖1（sno，sname，DormID，phone）

18、其他視圖依據(jù)需要另外設置。5物理結構設計階段數(shù)據(jù)庫在物理設備上的存儲結構與存取方法稱為數(shù)據(jù)庫的物理結構，它依賴于選定的數(shù)據(jù)庫管理系統(tǒng)。為一個給定的邏輯數(shù)據(jù)模型選取一個最適合的應用要求的物理結構的過程，就是數(shù)據(jù)庫的物理設計。數(shù)據(jù)庫的物理設計通常分為兩步：1.確定數(shù)據(jù)庫的物理結構，在關系數(shù)據(jù)庫中主要指存取方法和存儲結構；2.對物理結構進行評價，評價的重點是時間和空間的效率。5.1 關系模式存取方法的選擇確定數(shù)據(jù)庫的存取方法，就是確定建立哪些存儲路徑以實現(xiàn)快速存取數(shù)據(jù)庫中的數(shù)據(jù)?，F(xiàn)行的 DBMS 一般都提供了多種存取方法，如索引法、HASH 法等。其中，最常用的是索引法，本系統(tǒng)也采用的是索引法。我們

19、在經(jīng)常需要搜索的列和主關鍵字上建立了唯一索引。5.2 確定數(shù)據(jù)庫的存儲結構由于不同 PC 機所安裝的數(shù)據(jù)庫軟件位置不一定相同,所以數(shù)據(jù)文件與日志文件的存放位置也不一定相同。6數(shù)據(jù)實施和維護6.1建立數(shù)據(jù)庫Create database dormitory;6.2建表 1.建宿舍學生入住信息表create table student(SID varchar(20) primary key,SName varchar(20),SSex varchar(20),class varchar(20),dormID varchar(20),phone varchar(11) );表 6.2-1 學生入住信

20、息表（student)2.建宿舍繳費表 create table charge(ChargeID int identity(1,1) primary key,dormID varchar(20),MDate datetime,EBuy varchar(20),CPerson varchar(20),CMoney varchar(20); 表 6.2-2 宿舍水電繳費表(charge)3.宿舍衛(wèi)生檢查表create table checkinfo(CheckID int identity(1,1) primary key,dormID varchar(20),CDate datetime,CSa

21、te varchar(100),CRemark varchar(100);表 6.2-3 宿舍衛(wèi)生檢查表(checkinfo)4.建宿舍基本信息表create table dorm(dormID varchar(20) primary key,phone varchar(20),DMoney varchar(20),bedNum int,chairNum int,deskNum int,DRemark varchar(20);表 6.2-4 宿舍基本信息表（dorm）5.建宿舍外來人員記錄表create table register(Register int identity(1,1) pri

22、mary key,PComeName varchar(20),PComeID varchar(18),DateCome datetime,PLook varchar(20),dormID varchar(20),DateLeave datetime,Remark varchar(100);表 6.2-5 宿舍外來人員記錄表(register)6. 建宿舍報修表create table repair(RepairID int identity(1,1) primary key,dormID varchar(20),DateIn datetime,DateRepair datetime,perso

23、n varchar(20),repair varchar(20),reason varchar(20),repairmoney varchar(20);表6.2-6 宿舍報修表(repair)6.3建查詢 1、 查詢衛(wèi)生檢查不合格宿舍 Select Csate from  checkinfo  where Cremark < 60;查詢結果：圖6.3-1 查詢結果圖12、 查詢各個宿舍衛(wèi)生檢查成績，并按降序排列Select Csate,Cremark from checkinfo order by Cremark

24、60;desc;查詢結果： 圖6.3-2 查詢結果圖23、 查詢軟件1班所在的宿舍號Select  dormID,class from student where class=”軟1”;查詢結果：圖6.3-3 查詢結果圖34、 查詢宿舍檢查不合格的舍員名單Select SName from student,checkinfo where checkinfo.dormID=student.dormID and Gremark<60;查詢結果：圖6.3-4 查詢結果圖45、 查詢指定日期的所有的銷售單SELECT dorm.phoneFROM dorm,chec

25、kinfoWHERE dorm.dormID = checkinfo.dormID and checkinfo.CSate='合格'查詢結果：圖6.3-5 查詢結果56.4建存儲過程1創(chuàng)建一個存儲過程，查詢學生表中的詳細信息delimiter $CREATE PROCEDURE Stu()BEGINSELECT * FROM student ;END$delimiter;圖6.4-1 存儲過程結果圖12. 創(chuàng)建一個存儲過程，查詢201宿舍的具體情況 delimiter $CREATE PROCEDURE Sdorm()BEGIN

26、SELECT * FROM dorm WHERE dormID=201;END$delimiter;圖6.4-2 存儲過程結果圖23創(chuàng)建一個存儲過程，用于查詢檢查大于60分的宿舍程序：delimiter$CREATE procedure proc_1 (Cremark char(100)BEGINSELECT dormID FROM checkinfo WHERE Cremark>60;END$delimiter;輸入?yún)?shù)60圖6.4-3 存儲過程結果圖36.5建觸發(fā)器準備學生數(shù)目統(tǒng)計表：CREATE TABLE student_count( Student_count INT(11)

27、DEFAULT 0);INSERT INTO student_count VALUES(0);創(chuàng)建觸發(fā)器，在向學生表INSERT數(shù)據(jù)時，學生數(shù)增加，DELETE學生時，學生數(shù)減少。CREATE TRIGGER trigger_student_count_insertAFTER INSERTON student_info FOR EACH ROWUPDATE student_count SET student_count=student_count+1;CREATE TRIGGER trigger_student_count_deleteAFTER DELETEON student_info FOR EACH ROWUPDATE student_count SET student_count=student_co