数据库课程设计学生宿舍管理系统毕业设计论文管理资料.docx

数据库课程设计学生宿舍管理系统毕业设计论文管理资料.docx

《数据库课程设计学生宿舍管理系统毕业设计论文管理资料.docx》由会员分享，可在线阅读，更多相关《数据库课程设计学生宿舍管理系统毕业设计论文管理资料.docx（73页珍藏版）》请在冰豆网上搜索。

数据库课程设计学生宿舍管理系统毕业设计论文管理资料

摘要

学生宿舍管理系统是应对学生宿舍管理的现代化、网络化，逐步摆脱当前学生宿舍管理的人工管理方式，提高学生宿舍管理效率而开发的，它包括宿舍学生基本信息管理、楼道工人基本信息管理、宿舍楼基本信息管理、宿舍基本信息管理、宿舍事故基本信息管理、宿舍楼物品出入基本信息管理、宿舍楼保卫处基本信息管理、宿舍配备物品及处理管理等八大功能模块，并提供了对各功能模块的查询和更新功能，且这两种功能基本上是通过存储过程来实现的，其中宿舍学生基本信息管理、宿舍基本信息管理是系统开发的重点。

该系统开发由系统需求分析阶段、概念设计阶段、逻辑设计阶段、数据库实施阶段、系统调试和测试阶段、参考文献、附录等阶段组成。

关键字：

学生宿舍管理，宿舍管理现代化，宿舍管理网络化，人工管理，功能模块，存储过程

1.系统需求分析阶段

引言

通过对北校区25个学生宿舍楼的实地调查，了解到现在的学生宿舍管理仍停留在完全的人工管理阶段，楼管处没有标准的住宿学生存档信息。

这中人工管理方式费时、费事、费力，造成工作效率低下。

开发出合适的学生宿舍管理系统，可以方便学生宿舍的管理，提高宿舍管理工作效率及查询效率。

目标与任务

需求分析阶段的目标

（1）了解目前宿舍管理的现状以及SQLServer2000的功能和特点。

（2）通过实地调查和问答－记录的方式了解宿舍管理的工作业务流程，并记录和处理相关的数据。

（3）与指导教师交流个人想法，征求意见，改正不合理的地方，为下面的概念设计与逻辑设计奠定基础。

需求分析阶段的任务

（1）处理对象：

系统要处理的对象包括宿舍楼基本信息、学生基本信息、宿舍基本信息、楼道工作人员基本信息、宿舍保卫处基本信息、宿舍事故基本信息、物品出入基本信息等七个方面，各个对象包括信息如下所示（详细的数据见于数据字典）：

1．宿舍楼基本信息（Dormitory）：

包括宿舍楼编号、宿舍楼所在校区、宿舍楼再校区中区域、每一幢宿舍楼楼管处的电话、宿舍楼楼管员信息等方面，这样可以方便管理者对宿舍楼的管理，提高查询效率；

2．学生基本信息（Student）：

包括学生编号、学生所在学院信息、学生姓名、学生性别、学生来自省份、学生出生日期、学生入学时间、学生所学专业、所在班级等方面的信息，可以方便学信息的查询和更新；

3．宿舍基本信息（Room，Fitment，FitmentDestruction，FitmentCompensate）：

宿舍基本信息包括四个数据结构（宿舍信息（Room），宿舍物品信息（Fitment），宿舍物品损坏信息（FitmentDestruction）,宿舍损坏物品赔偿信息）,每个数据结构中的数据项见数据字典；

4．楼道工作人员基本信息（Worker）：

包括工作人员编号、工作人员姓名、工作类型、工资、性别、联系方式、工作时间等数据项，可以方便管理人员对宿舍楼道工人的任用、信息查询及更改；

5．宿舍保卫处基本信息（SafeGuard）：

包括保卫处名称、人员数目、负责人信息、联系电话等四方面的信息；

6．宿舍事故基本信息（Accident，AccidentResearch，AccidentCompensate）：

事故信息包括三个数据结构（事故信息、事故处理信息、事故赔偿信息），具体的数据项见数据字典；

物品出入基本信息（ArticalInOut）：

包括出入物品的学生信息、出入的物品信息、出入物品时的负责人信息、出入物品时间，尽量减少宿舍事故的发生，保障学生宿舍财产的安全。

（2）处理功能要求

系统主要完成一下几个功能：

1．宿舍楼基本信息查询与修改；

2．学生基本信息查询与更新；

3．每一幢宿舍楼中宿舍信息的查询与信息更新；

4．宿舍保卫处基本信息的查询和修改；

5．宿舍事故基本信息及事故处理信息的查询和修改；

6．宿舍楼物品出入审批及记录；

（3）安全性和完整性要求

安全性先通过视图机制，不同的用户只能访问系统授权的视图，这样可提供系统数据一定程度上的安全性，再通过用户授权机制，欲用户登陆来识别用户级别，根据这个级别来分配用户权限，达到数据更高层次的安全保密功能。

完整性要求用于描述宿舍楼基本信息、学生基本信息、宿舍基本信息、楼道工作人员基本信息、宿舍保卫处基本信息、宿舍事故基本信息、物品出入基本信息中数据项能否为null，以及一些用户自定义完整性（符合实际要求），详细完整性要求见于系统的逻辑设计阶段。

需求分析阶段成果

（1）体会与收获

系统需求分析主要采取实地询问－记录和楼管处查询宿舍学生信息的方式，同时借鉴学长在做数据库开发这方面的经验。

通过实地调查和询问，了解目前学生宿舍管理的现状，以及目前学生宿舍管理中一些问题，并对实际查询业务实地参与，了解了学生、楼管员、宿舍管理者、宿舍保卫人员对系统的信息处理要求，以及他（她）们对现存人工管理方式不能满足信息处理要求的苦恼。

同时在调查中牵涉的许多的人际交流，恰当的询问方式，由于平时几乎没有做过这方面的调查，开始时有点胆怯和不知从何入手，但过了两三幢宿舍楼之后，开始的胆怯就感觉不到了。

（2）学生宿舍管理系统业务流程图

新生入住宿舍业务流程图：

查询业务流程图（查询宿舍学生信息、楼道工作人员信息、宿舍楼信息等）：

毕业生离宿业务流程图：

楼道工作人员任用业务流程图：

宿舍楼物品出入业务流程图：

宿舍事故处理业务流程图：

（3）数据流程图

顶层数据流程图：

第2层数据流程图：

从学生角度出发

第2层数据流程图：

从管理者角度出发

从管理者角度出发的2层数据流程图

第3层数据流程图：

从新生角度出发

第3层数据流程图：

从毕业生角度出发

第3层数据流程图：

从宿舍楼物品出入出发

第3层数据流程图：

从宿舍事故角度出入出发

第3层数据流程图：

从楼道工作人员的任用角度出发

第3层数据流程图：

从管理者和外来访客的角度出发

（4）数据字典

（a）数据项：

系统涉及的数据项有71项

数据项列表

数据项编号

数据项名

数据项含义

与其它数据项的关系

存储结构

别名

DI-1

StuNo

学生编号

char（9）

学号

DI-2

DepName

学生所在学院

char（20）

学院

DI-3

StuName

学生姓名

char（10）

姓名

DI-4

StuSex

学生性别

char

（2）

性别

DI-5

StuHome

学生来自省份

char（10）

祖籍

DI-6

StuBorth

学生出生时间

Date

出生日期

DI-7

StuETime

学生入学时间

Date

入学时间

DI-8

StuPerfect

学生所在专业

char（20）

专业

DI-9

StuClass

学生所在班级编号

Int

编号

DI-10

WorNo

工作人员编号

char（5）

编号

DI-11

WorName

工作人员姓名

char（10）

姓名

DI-12

WorType

工作类型

char（8）

工作类型

DI-13

WorWage

工作人员工资

Int

月工资

DI-14

WorSex

工作人员性别

char

（2）

性别

DI-15

WorPhNo

工作人员联系方式

char（12）

电话

DI-16

WorTime

工作人员工作时间

char（30）

工作时间

DI-17

RNo

宿舍编号

char（6）

舍号

DI-18

RHeader

舍长信息

等于StuName

char（10）

舍长

DI-19

ROne

宿舍学生信息

同上

char（10）

舍员1

DI-20

RTwo

宿舍学生信息

同上

char（10）

舍员2

DI-21

RThree

宿舍学生信息

同上

char（10）

舍员3

DI-22

RFour

宿舍学生信息

同上

char（10）

舍员4

DI-23

RFive

宿舍学生信息

同上

char（10）

舍员5

DI-24

RSix

宿舍学生信息

同上

char（10）

舍员6

DI-25

RGrade

宿舍学生所属年级

等于StuETime

char（4）

年级

DI-26

RDepart

宿舍学生所在学院

等于DepName

char（20）

学院

DI-27

RPerfect

宿舍学生所学专业

等于StuPerfect

char（20）

专业

DI-28

RClass

学生所在班级编号

等于StuClass

char

（2）

班级

DI-29

DorNo

宿舍楼编号

smallint

宿舍楼号

DI-30

DorCampus

宿舍楼所属校区

char（4）

校区

DI-31

DorLocation

宿舍楼在校区位置

char（4）

宿舍区位

DI-32

DorPhNo

宿舍楼管处电话

char（12）

电话

DI-33

DorAdminist

宿舍楼楼管员信息

等于WorNo

char（10）

楼管员

DI-34

SGName

保卫处名称

char（15）

名字

DI-35

SGWorNum

保卫处人员总数

Int

人员数目

DI-36

SGHeader

保卫处负责人信息

char（10）

负责人

DI-37

SGPhone

保卫处电话

char（12）

电话

DI-38

FitName

宿舍物品名称

char（16）

宿舍物品

DI-39

FitPrice

宿舍物品价格

Float

价格

DI-40

FitNum

每一种宿舍的数量

Int

数量

DI-41

FDFitment

损坏物品信息

等于FitName

char（16）

物品名

DI-42

FDStudent

损坏的学生信息

等于StuNo

char（9）

学生

DI-43

FDRoom

损坏物品宿舍信息

等于RNo

char（6）

舍号

DI-44

FDFitNum

损坏物品的数量

Int

数量

DI-45

FCompFit

赔偿物品信息

等于FitName

char（16）

物品名

DI-46

FCompStu

需赔偿学生信息

等于StuNo

char（9）

学生

DI-47

FCompMon

赔偿价格

Float

赔偿价格

DI-48

FCompPrin

赔偿负责人信息

等于WorNo

char（10）

负责人

DI-49

FCompDate

赔偿日期

Date

日期

DI-50

FCompNum

赔偿物品数量

Int

数量

DI-51

AcNo

事故编号

int

编号

DI-52

AcType

事故类型

char（10）

类型

DI-53

AcArtical

事故损失物品

char（30）

物品名

DI-54

AcArNum

事故损失物品数量

Int

数量

DI-55

AcStu

事故受害学生

等于StuNo

char（9）

学生

DI-56

AcDate

事故发生日期

Date

日期

DI-57

AcPrin

事故负责人信息

等于SGHeader

char（15）

负责人

DI-58

AcStuPh

受害人联系方式

char（12）

学生电话

DI-59

AcVerify

事故是否属实

Bool

核查

DI-60

ARNo

事故调查编号

char（4）

编号

DI-61

ARName

事故调查名称

char（15）

调查

DI-62

ARPrin

事故调查负责人

等于SGHeader

char（10）

负责人

DI-63

ARResult

事故调查结果

Bool

结果

DI-64

ACStu

事故赔偿学生信息

等于StuNo

char（10）

学生

DI-65

ACArtical

事故赔偿物品信息

char（30）

物品名

DI-66

ACDate

事故赔偿日期

Date

日期

DI-67

ACPrin

事故赔偿负责单位

等于SGHeader

char（15）

负责单位

DI-68

AIOStu

要求物品出入学生

等于StuNo

char（10）

学生

DI-69

AIOArtical

出入物品信息

char（20）

物品名

DI-70

AIOPrin

出入物品审查人

等于WorNo

char（10）

负责人

DI-71

AIODate

出入物品日期

Date

日期

DI-72

AIONo

物品出入序号

Int

序号

（b）数据结构：

数据结构列表

数据结

构编号

数据结构名

数据结构

含义

组成

DS-1

Student

宿舍学生信息

StuNo,DepName,StuName,StuSex,StuHome,

StuBorth,StuETime,StuPerfect,StuClass

DS-2

Worker

宿舍楼工作人员信息

WorTime,WorName,WorType,

WorWage,WorSex,WorPhNo,WorNo

DS-3

Room

宿舍信息

RNo,RHeader,ROne,RClass,

RThree,RFour,RFive,RSix,RGrade,

RDepart,RPerfect,RTwo,

DS-4

Dormitory

宿舍楼信息

DorNo,DorCampus,DorPhNo

DorLocation,DorAdminist

DS-5

SafeGuard

宿舍保卫处信息

SGName,SGWorNum,SGHeader,SGPhone

DS-6

Fitment

宿舍物品配备信息

FitName,FitPrice,FitNum

DS-7

FitmentDestruction

宿舍物品损坏信息

FDFitment,FDStudent,FDRoom,FDFitNum

DS-8

FitmentCompensate

宿舍损坏物品赔偿信息

FCompFit,FCompStu,FCompPrin,

FCompDate,FCompNum

DS-9

Accident

宿舍事故注册信息

AcNo,AcType,AcStu,AcDate,

AcArtical,AcVerify,AcPrin,

AcArNum,AcStuPh

DS-10

AccidentResearch

宿舍事故调查信息

ARNo,ARName,ARPrin,ARResult

DS-11

AccidentCompensate

事故损失物品赔偿信息

ACStu,ACArtical,ACDate,ACPrin

DS-12

ArticalInOut

宿舍楼物品出入信息

AIOStu,AIOArtical,AIOPrin,AIODate,AIONo

（5）处理逻辑描述（判定表或判定树）

处理逻辑列表

判定条件

决策

判断用户查询涉及的功能模块

宿舍基本信息模块、宿舍楼基本信息模块、学生基本信息模块、宿舍楼配备物品基本信息模块、宿舍事故基本信息模块、宿舍楼物品出入基本信息模块、宿舍楼保卫处基本信息模块、楼道工人基本信息模块：

先确定查询所涉及的功能模块；然后，确定要查询的内容，确定查询数据流向；最后显示查询结果。

判断用户修改要涉及的模块，同时把相应的修改数据传到相应的模块之中

宿舍基本信息模块、宿舍楼基本信息模块、学生基本信息模块、宿舍楼配备物品基本信息模块、宿舍事故基本信息模块、宿舍楼物品出入基本信息模块、宿舍楼保卫处基本信息模块、楼道工人基本信息模块：

先确定更新所涉及的功能模块；然后，把更新信息传送到相应的模块中；最后，进行相应的更新操作。

2.概念设计阶段

引言

概念设计阶段主要是将需求分析阶段得到的用户需求抽象为信息结构（概念模型）的过程,它是整个数据库设计的关键，包括概念模型设计和新系统流程两个阶段。

概念模型设计

（1）根据不同的对象，从第3层数据流程图（中层数据流程图）入手，分别画出分E－R图：

（a）与图抽象出的分E－R图：

分E－R图1

分E－R图2

分E－R图3

（b）抽象出的分E－R图：

分E－R图4

（c）抽象出的分E－R图：

分E－R图5

（2）各分E－R图中每个实体的属性如下所示：

学生：

Student（StuNo，DepName，StuName，StuSex，StuHome，StuBorth，StuETime，

StuPerfect，StuClass）；

宿舍：

Room（RNo，RHeader，ROne，RClass，RThree，RFour，RFive，RSix，

RGrade，RDepart，RPerfect，RTwo）；

宿舍楼：

Dormitory（DorNo，DorCampus，DorLocation，DorPhNo，DorAdminist）；

宿舍物品：

Fitment（FitName，FitPrice，FitNum）；

楼道工作人员：

Worker（WorNo，WorName，WorType，WorWage，WorSex,

WorPhNo，WorTime）；

保卫处：

SafeGuard（SGName，SGWorNum，SGHeader，SGPhone）；

各分E－R图中联系的属性如下所示：

物品出入：

ArticalInOut（AIONo，AIOStu，AIOArtical，AIOPrin，AIODate）；

宿舍物品处理：

包含物品损坏和物品赔偿两个数据结构（将在逻辑设计阶段给出）；

事故：

包含宿舍事故注册、宿舍事故调查、事故损失物品赔偿三个数据结构（具体的结构将

在系统逻辑设计阶段给出）。

（注:

为了节省篇幅，实体与属性的关系没有用图形表示，实体的标识码用下划线划出。

）

（3）合并各分Ｅ－Ｒ图,消除属性冲突、命名冲突、结构冲突等三类冲突，得到初步E-R图，

再消除不必要冗余，得到的基本E-R图如下所示：

新系统流程

新系统流程图：

3．逻辑设计阶段

以上的概念设计阶段是独立于任何一种数据模型的，但是逻辑设计阶段就与选用的DBMS产品发生关系了，系统逻辑设计的任务就是将概念设计阶段设计好的基本E-R图转换为选用DBMS产品所支持的数据模型相符合的逻辑结构。

具体内容包括数据组织（将E-R图转换成关系模型、模型优化、数据库模式定义、用户子模式设计）、数据处理（画出系统功能模块图）两大任务

由于宿舍楼与楼道工人的联系方式是1:

n（一对多），可以将其之间的联系与n端实体楼道工人合并，宿舍楼与宿舍之间的联系、宿舍与学生之间的联系方式也是1:

n，同样也将其之间的联系与n端实体宿舍、学生合并，而宿舍物品与学生、学生与楼道工作人员之间的联系方式则是n:

m（多对多），这样要把它们之间的联系转化为独立的关系模式，保卫处与学生之间的联系是1:

n（一对多），但是它们之间的联系事故则包含数据结构，为了便于模型优化，将其联系也转化成独立的关系模式，具体的基本E-R图向关系模型的转化如下：

楼道工人：

Worker（WorNo，WorName，WorType，WorWage，WorSex,

WorPhNo，WorTime，DorNo，DorCampus，DorLocation）；

宿舍楼：

Dormitory（DorNo，DorCampus，DorLocation，DorPhNo，DorAdminist）；

宿舍：

Room（RNo，RHeader，ROne，RClass，RThree，RFour，RFive，RSix，

RGrade，RDepart，RPerfect，RTwo，DorNo，DorCampus，DorLocation）；

宿舍物品：

Fitment（FitName，FitPrice，FitNum，DorNo，DorCampus，DorLocation）；

学生：

Student（StuNo，DepName，StuName，StuSex，StuHome，StuBorth，StuETime，

StuPerfect，StuClass，RNo，DorNo，DorCampus，DorLocation）；

保卫处：

SafeGuard（SGName，SGWorNum，SGHeader，SGPhone）；

物品出入：

ArticalInOut（AIONo，StuNo，AIOArtical，AIOPrin，AIODate,DorNo，

DorCampus，DorLocation）；

宿舍物品处理包含两个数据结构（宿舍物品损坏信息，宿舍物品损坏赔偿信息），基于表的各个属性都是原子项的考虑，现将宿舍物品处理分解为：

宿舍物品损坏、宿舍损坏物品赔偿，具体如下：

宿舍物品损坏：

FitmentDestruction（FitName，StuNo，RNo，FDFitNum,DorNo，

DorCampus，DorLocation）；（消除命名冲突）

宿舍物品损坏赔偿：

FitmentCompensate（FitName，StuNo，FCPrin，FCompDate，

FCompNum）；（消除命名冲突）

宿舍事故包含三个数据结构（宿舍事故注册信息、宿舍事故调查信息、宿舍事故损失物品赔偿信息），同样基于表的原子性的考虑也将事故分解为：

事故注册、事故调查、

事故赔偿，具体如下：

事故注册：

Accident（AcNo，AcType，StuNo，AcDate，AcArtical，AcVerify，SGName，

AcArNum，AcStuPh）；

事故调查：

AccidentResearch（AcNo，ARName，SGName，ARResult）；

事故赔偿：

AccidentCompensate（AcNo，ACStu，AcArtical，ACDate，SGName）；

（注：

标有直线下划线的为主属性，标有波浪线下划线的是外键属性，主属性与外键属性一起构成主码）

关系模式Worker，Dormitory，Fitment，SafeGuard，ArticalInOut，FitmentDestruction，FitmentCompensate，Accident，AccidentResearch，AccidentCompensate不存在非主属性对主属性的部分函数依赖，也不存在传递函数依赖，已经达到了3NF，但是宿舍关系模式（Room）中存在着一些不应该有的数据冗余，现将模型优化为：

Room（RNo，RHeader，RGrade，RDepart，RPerfect，DorNo，DorCampus，DorLocation）；虽然Room中还存在一些数据冗余，但可以提高查询效率。