学生宿舍管理系统数据库设计Word格式文档下载.docx
- 文档编号:18845337
- 上传时间:2023-01-01
- 格式:DOCX
- 页数:70
- 大小:1.33MB
学生宿舍管理系统数据库设计Word格式文档下载.docx
《学生宿舍管理系统数据库设计Word格式文档下载.docx》由会员分享,可在线阅读,更多相关《学生宿舍管理系统数据库设计Word格式文档下载.docx(70页珍藏版)》请在冰豆网上搜索。
通过对北校区25个学生宿舍楼得实地调查,了解到现在得学生宿舍管理仍停留在完全得人工管理阶段,楼管处没有标准得住宿学生存档信息。
这中人工管理方式费时、费事、费力,造成工作效率低下。
开发出合适得学生宿舍管理系统,可以方便学生宿舍得管理,提高宿舍管理工作效率及查询效率。
1、2 目标与任务
1、2、1需求分析阶段得目标
(1)了解目前宿舍管理得现状以及SQLServer2000得功能与特点。
(2)通过实地调查与问答-记录得方式了解宿舍管理得工作业务流程,并记录与处理相关得数据。
(3)与指导教师交流个人想法,征求意见,改正不合理得地方,为下面得概念设计与逻辑设计奠定基础.
1、2、2需求分析阶段得任务
(1)处理对象:
系统要处理得对象包括宿舍楼基本信息、学生基本信息、宿舍基本信息、楼道工作人员基本信息、宿舍保卫处基本信息、宿舍事故基本信息、物品出入基本信息等七个方面,各个对象包括信息如下所示(详细得数据见于数据字典):
1.宿舍楼基本信息(Dormitory):
包括 宿舍楼编号、宿舍楼所在校区、宿舍楼再校区中区域、每一幢宿舍楼楼管处得电话、宿舍楼楼管员信息等方面,这样可以方便管理者对宿舍楼得管理,提高查询效率;
2。
学生基本信息(Student):
包括学生编号、学生所在学院信息、学生姓名、学生性别、学生来自省份、学生出生日期、学生入学时间、学生所学专业、所在班级等方面得信息,可以方便学信息得查询与更新;
3。
宿舍基本信息(Room,Fitment,FitmentDestruction,Fitmentpensate):
宿舍基本信息包括四个数据结构(宿舍信息(Room),宿舍物品信息(Fitment),宿舍物品损坏信息(FitmentDestruction),宿舍损坏物品赔偿信息),每个数据结构中得数据项见数据字典;
4.楼道工作人员基本信息(Worker):
包括 工作人员编号、工作人员姓名、工作类型、工资、性别、联系方式、工作时间等数据项,可以方便管理人员对宿舍楼道工人得任用、信息查询及更改;
5.宿舍保卫处基本信息(SafeGuard):
包括保卫处名称、人员数目、负责人信息、联系电话等四方面得信息;
6.宿舍事故基本信息(Accident,AccidentResearch,Accidentpensate):
事故信息包括三个数据结构(事故信息、事故处理信息、事故赔偿信息),具体得数据项见数据字典;
物品出入基本信息(ArticalInOut):
包括出入物品得学生信息、出入得物品信息、出入物品时得负责人信息、出入物品时间,尽量减少宿舍事故得发生,保障学生宿舍财产得安全。
(2)处理功能要求
系统主要完成一下几个功能:
1。
宿舍楼基本信息查询与修改;
2。
学生基本信息查询与更新;
3.每一幢宿舍楼中宿舍信息得查询与信息更新;
4.宿舍保卫处基本信息得查询与修改;
5.宿舍事故基本信息及事故处理信息得查询与修改;
6.宿舍楼物品出入审批及记录;
(3)安全性与完整性要求
安全性先通过视图机制,不同得用户只能访问系统授权得视图,这样可提供系统数据一定程度上得安全性,再通过用户授权机制,欲用户登陆来识别用户级别,根据这个级别来分配用户权限,达到数据更高层次得安全保密功能.
完整性要求用于描述宿舍楼基本信息、学生基本信息、宿舍基本信息、楼道工作人员基本信息、宿舍保卫处基本信息、宿舍事故基本信息、物品出入基本信息中数据项能否为null,以及一些用户自定义完整性(符合实际要求),详细完整性要求见于系统得逻辑设计阶段.
1、2、3需求分析阶段成果
(1)体会与收获
系统需求分析主要采取实地询问-记录与楼管处查询宿舍学生信息得方式,同时借鉴学长在做数据库开发这方面得经验。
通过实地调查与询问,了解目前学生宿舍管理得现状,以及目前学生宿舍管理中一些问题,并对实际查询业务实地参与,了解了学生、楼管员、宿舍管理者、宿舍保卫人员对系统得信息处理要求,以及她(她)们对现存人工管理方式不能满足信息处理要求得苦恼。
同时在调查中牵涉得许多得人际交流,恰当得询问方式,由于平时几乎没有做过这方面得调查,开始时有点胆怯与不知从何入手,但过了两三幢宿舍楼之后,开始得胆怯就感觉不到了。
(2)学生宿舍管理系统业务流程图
新生入住宿舍业务流程图:
ﻩ
查询业务流程图(查询宿舍学生信息、楼道工作人员信息、宿舍楼信息等):
毕业生离宿业务流程图:
楼道工作人员任用业务流程图:
宿舍楼物品出入业务流程图:
宿舍事故处理业务流程图:
(3)数据流程图
顶层数据流程图:
第2层数据流程图:
从学生角度出发
从管理者角度出发
图2、3 从管理者角度出发得2层数据流程图
第3层数据流程图:
从新生角度出发
ﻩﻩ第3层数据流程图:
从毕业生角度出发
从宿舍楼物品出入出发
ﻩﻩ第3层数据流程图:
从宿舍事故角度出入出发
ﻩ第3层数据流程图:
从楼道工作人员得任用角度出发
从管理者与外来访客得角度出发
(4)数据字典
(a)数据项:
系统涉及得数据项有71项
表1、1数据项列表
数据项编号
数据项名
数据项含义
与其它数据项得关系
存储结构
别名
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
工作人员工资
月工资
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
舍员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
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
楼管员
DI-34
SGName
保卫处名称
char(15)
名字
DI-35
SGWorNum
保卫处人员总数
Int
人员数目
DI—36
SGHeader
保卫处负责人信息
负责人
DI—37
SGPhone
保卫处电话
char(12)
DI—38
FitName
宿舍物品名称
char(16)
宿舍物品
DI-39
FitPrice
宿舍物品价格
Float
价格
DI-40
FitNum
每一种宿舍得数量
数量
DI-41
FDFitment
损坏物品信息
等于FitName
char(16)
物品名
DI-42
FDStudent
损坏得学生信息
等于StuNo
char(9)
学生
DI-43
FDRoom
损坏物品宿舍信息
等于RNo
char(6)
DI-44
FDFitNum
损坏物品得数量
DI—45
FpFit
赔偿物品信息
等于FitName
char(16)
DI-46
FpStu
需赔偿学生信息
char(9)
DI—47
FpMon
赔偿价格
Float
DI—48
FpPrin
赔偿负责人信息
等于WorNo
char(10)
DI—49
FpDate
赔偿日期
Date
日期
DI-50
FpNum
赔偿物品数量
DI-51
AcNo
事故编号
int
DI—52
AcType
事故类型
类型
DI-53
AcArtical
事故损失物品
char(30)
DI-54
AcArNum
事故损失物品数量
DI-55
AcStu
事故受害学生
等于StuNo
char(9)
DI-56
AcDate
事故发生日期
DI-57
AcPrin
事故负责人信息
等于SGHeader
char(15)
DI—58
AcStuPh
受害人联系方式
学生电话
DI—59
AcVerify
事故就是否属实
Bool
核查
DI-60
ARNo
事故调查编号
char(4)
DI—61
ARName
事故调查名称
char(15)
调查
DI-62
ARPrin
事故调查负责人
等于SGHeader
DI—63
ARResult
事故调查结果
Bool
结果
DI-64
ACStu
事故赔偿学生信息
等于StuNo
DI—65
ACArtical
事故赔偿物品信息
char(30)
DI—66
ACDate
事故赔偿日期
DI—67
ACPrin
事故赔偿负责单位
等于SGHeader
char(15)
负责单位
DI-68
AIOStu
要求物品出入学生
等于StuNo
char(10)
DI—69
AIOArtical
出入物品信息
DI-70
AIOPrin
出入物品审查人
等于WorNo
DI-71
AIODate
出入物品日期
DI-72
AIONo
物品出入序号
Int
序号
(b)数据结构:
表1、2 数据结构列表
数据结
构编号
数据结构名
数据结构
含义
组成
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
Fitmentpensate
宿舍损坏物品赔偿信息
FpFit,FpStu,FpPrin,
FpDate,FpNum
DS—9
Accident
宿舍事故注册信息
AcNo,AcType,AcStu,AcDate,
AcArtical,AcVerify,AcPrin,
AcArNum,AcStuPh
DS—10
AccidentResearch
宿舍事故调查信息
ARNo,ARName,ARPrin,ARResult
DS—11
Accidentpensate
事故损失物品赔偿信息
ACStu,ACArtical,ACDate,ACPrin
DS—12
ArticalInOut
宿舍楼物品出入信息
AIOStu,AIOArtical,AIOPrin,AIODate,AIONo
(5)处理逻辑描述(判定表或判定树)
表1、3处理逻辑列表
判定条件
决策
判断用户查询涉及得功能模块
宿舍基本信息模块、宿舍楼基本信息模块、学生基本信息模块、宿舍楼配备物品基本信息模块、宿舍事故基本信息模块、宿舍楼物品出入基本信息模块、宿舍楼保卫处基本信息模块、楼道工人基本信息模块:
先确定查询所涉及得功能模块;
然后,确定要查询得内容,确定查询数据流向;
最后显示查询结果。
判断用户修改要涉及得模块,同时把相应得修改数据传到相应得模块之中
先确定更新所涉及得功能模块;
然后,把更新信息传送到相应得模块中;
最后,进行相应得更新操作。
2、概念设计阶段
2、1 引言
概念设计阶段主要就是将需求分析阶段得到得用户需求抽象为信息结构(概念模型)得过程,它就是整个数据库设计得关键,包括概念模型设计与新系统流程两个阶段.
2、2 概念模型设计
(1)根据不同得对象,从第3层数据流程图(中层数据流程图)入手,分别画出分E—R图:
(a)从数据流程图图2、4 与图2、5 抽象出得分E-R图:
图3、1分E-R图1
图3、2 分E-R图2
图3、3 分E-R图3
(b)从数据流程图图2、6与图2、8抽象出得分E-R图:
图3、4分E—R图4
(c)从数据流程图图2、7抽象出得分E-R图:
图3、5分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图,
再消除不必要冗余,得到得基本E-R图如下所示:
2、3 新系统流程
新系统流程图:
3.逻辑设计阶段
3、1逻辑设计得任务与目标
以上得概念设计阶段就是独立于任何一种数据模型得,但就是逻辑设计阶段就与选用得DBMS产品发生关系了,系统逻辑设计得任务就就是将概念设计阶段设计好得基本E-R图转换为选用DBMS产品所支持得数据模型相符合得逻辑结构。
具体内容包括数据组织(将E—R图转换成关系模型、模型优化、数据库模式定义、用户子模式设计)、数据处理(画出系统功能模块图)两大任务
3、2数据组织
3。
1将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,Dor
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 学生宿舍 管理 系统 数据库 设计
![提示](https://static.bdocx.com/images/bang_tan.gif)