学生宿舍管理系统数据库设计1Word格式.docx
- 文档编号:15349955
- 上传时间:2022-10-29
- 格式:DOCX
- 页数:52
- 大小:39.12KB
学生宿舍管理系统数据库设计1Word格式.docx
《学生宿舍管理系统数据库设计1Word格式.docx》由会员分享,可在线阅读,更多相关《学生宿舍管理系统数据库设计1Word格式.docx(52页珍藏版)》请在冰豆网上搜索。
3.2数据组织14
3.2.1将E-R图转换为关系模型14
3.2.2模型优化15
3.2.3数据库模式定义16
3.2.4用户子模式设计16
3.3数据处理16
4.物理设计阶段17
4.1物理设计阶段的目标与任务17
4.2数据存储方面17
4.3系统功能模块17
4.3.1楼道工人基本的信息查询和更新模块18
4.3.2宿舍楼基本信息的查询和更新模块18
4.3.3宿舍基本信息的查询和更新模块19
4.3.4学生基本信息的查询和更新模块20
4.3.5宿舍物品的查询和更新模块20
4.3.6宿舍事故的查询和更新模块21
4.3.7宿舍物品处理的查询和更新模块21
4.3.8宿舍保卫处基本信息的查询和更新模块22
5.数据库实施阶段22
5.1建立数据库、数据表、视图、索引22
5.1.1建立数据库22
5.1.2建立数据表22
5.1.3建立视图26
5.1.4建立索引28
5.2数据入库28
5.3创建各个功能的存储过程29
6.系统调试和测试29
7.实习心得32
8.存在的问题及建议32
参考文献33
附录1数据库逻辑结构定义34
附录2存储过程定义38
附录3数据查看和存储过程功能的验证43
附录4所有的SQL运行语句48
1.系统需求分析阶段
1.1引言
通过对北校区25个学生宿舍楼的实地调查,了解到现在的学生宿舍管理仍停留在完全的人工管理阶段,楼管处没有标准的住宿学生存档信息。
这中人工管理方式费时、费事、费力,造成工作效率低下。
开发出合适的学生宿舍管理系统,可以方便学生宿舍的管理,提高宿舍管理工作效率及查询效率。
1.2目标与任务
1.2.1需求分析阶段的目标
(1)了解目前宿舍管理的现状以及SQLServer2000的功能和特点。
(2)通过实地调查和问答-记录的方式了解宿舍管理的工作业务流程,并记录和处理相关的数据。
(3)与指导教师交流个人想法,征求意见,改正不合理的地方,为下面的概念设计与逻辑设计奠定基础。
1.2.2需求分析阶段的任务
(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需求分析阶段成果
(1)体会与收获
系统需求分析主要采取实地询问-记录和楼管处查询宿舍学生信息的方式,同时借鉴学长在做数据库开发这方面的经验。
通过实地调查和询问,了解目前学生宿舍管理的现状,以及目前学生宿舍管理中一些问题,并对实际查询业务实地参与,了解了学生、楼管员、宿舍管理者、宿舍保卫人员对系统的信息处理要求,以及他(她)们对现存人工管理方式不能满足信息处理要求的苦恼。
同时在调查中牵涉的许多的人际交流,恰当的询问方式,由于平时几乎没有做过这方面的调查,开始时有点胆怯和不知从何入手,但过了两三幢宿舍楼之后,开始的胆怯就感觉不到了。
(2)学生宿舍管理系统业务流程图
新生入住宿舍业务流程图:
查询业务流程图(查询宿舍学生信息、楼道工作人员信息、宿舍楼信息等):
毕业生离宿业务流程图:
楼道工作人员任用业务流程图:
宿舍楼物品出入业务流程图:
宿舍事故处理业务流程图:
(3)数据流程图
顶层数据流程图:
第2层数据流程图:
从学生角度出发
从管理者角度出发
图2.3从管理者角度出发的2层数据流程图
第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
学生来自省份
祖籍
DI-6
StuBorth
学生出生时间
Date
出生日期
DI-7
StuETime
学生入学时间
入学时间
DI-8
StuPerfect
学生所在专业
专业
DI-9
StuClass
学生所在班级编号
Int
编号
DI-10
WorNo
工作人员编号
char(5)
DI-11
WorName
工作人员姓名
DI-12
WorType
工作类型
char(8)
DI-13
WorWage
工作人员工资
月工资
DI-14
WorSex
工作人员性别
DI-15
WorPhNo
工作人员联系方式
char(12)
电话
DI-16
WorTime
工作人员工作时间
char(30)
工作时间
DI-17
RNo
宿舍编号
char(6)
舍号
DI-18
RHeader
舍长信息
等于StuName
舍长
DI-19
ROne
宿舍学生信息
同上
舍员1
DI-20
RTwo
舍员2
DI-21
RThree
舍员3
DI-22
RFour
舍员4
DI-23
RFive
舍员5
DI-24
RSix
舍员6
DI-25
RGrade
宿舍学生所属年级
等于StuETime
char(4)
年级
DI-26
RDepart
宿舍学生所在学院
等于DepName
DI-27
RPerfect
宿舍学生所学专业
等于StuPerfect
DI-28
RClass
等于StuClass
班级
DI-29
DorNo
宿舍楼编号
smallint
宿舍楼号
DI-30
DorCampus
宿舍楼所属校区
校区
DI-31
DorLocation
宿舍楼在校区位置
宿舍区位
DI-32
DorPhNo
宿舍楼管处电话
DI-33
DorAdminist
宿舍楼楼管员信息
等于WorNo
楼管员
DI-34
SGName
保卫处名称
char(15)
名字
DI-35
SGWorNum
保卫处人员总数
人员数目
DI-36
SGHeader
保卫处负责人信息
负责人
DI-37
SGPhone
保卫处电话
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 学生宿舍 管理 系统 数据库 设计