学生宿舍管理系统oracle数据库设计.docx
- 文档编号:6282431
- 上传时间:2023-01-05
- 格式:DOCX
- 页数:64
- 大小:1.32MB
学生宿舍管理系统oracle数据库设计.docx
《学生宿舍管理系统oracle数据库设计.docx》由会员分享,可在线阅读,更多相关《学生宿舍管理系统oracle数据库设计.docx(64页珍藏版)》请在冰豆网上搜索。
学生宿舍管理系统oracle数据库设计
学生宿舍管理系统数据库设计
1.系统需求分析阶段
1.1.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.1.3需求分析阶段成果
(1)体会与收获
系统需求分析主要采取实地询问-记录和楼管处查询宿舍学生信息的方式,同时借鉴学长在做数据库开发这方面的经验。
通过实地调查和询问,了解目前学生宿舍管理的现状,以及目前学生宿舍管理中一些问题,并对实际查询业务实地参与,了解了学生、楼管员、宿舍管理者、宿舍保卫人员对系统的信息处理要求,以及他(她)们对现存人工管理方式不能满足信息处理要求的苦恼。
同时在调查中牵涉的许多的人际交流,恰当的询问方式,由于平时几乎没有做过这方面的调查,开始时有点胆怯和不知从何入手,但过了两三幢宿舍楼之后,开始的胆怯就感觉不到了。
(2)学生宿舍管理系统业务流程图
新生入住宿舍业务流程图:
查询业务流程图(查询宿舍学生信息、楼道工作人员信息、宿舍楼信息等):
毕业生离宿业务流程图:
楼道工作人员任用业务流程图:
宿舍楼物品出入业务流程图:
宿舍事故处理业务流程图:
(3)数据流程图
顶层数据流程图:
第2层数据流程图:
从学生角度出发
第2层数据流程图:
从管理者角度出发
图2.3从管理者角度出发的2层数据流程图
第3层数据流程图:
从新生角度出发
第3层数据流程图:
从毕业生角度出发
第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
工作人员工资
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)数据结构:
表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
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)处理逻辑描述(判定表或判定树)
表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.2.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,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);
(注:
标有直线下划线的为主属性,标有波浪线下划线的是外键属性,主属性与外键属性一起构成主码)
3.2.2模型优化
关系模式Worker,Dormitory,Fitment,SafeGuard,ArticalInOut,FitmentDestruction,FitmentCompensate,Accident,AccidentResearch,AccidentCompensate不存在非主属性对主属性的部分函数依赖,也不存在传递函数依赖,已经达到了3NF,但是宿舍关系模式(Room)中存在着一些不应该有的数据冗余,现将模型优化为:
Room(RNo,RHeader,RGrade,RDepart,RPerfect,DorNo,DorCampus,DorLocation);虽然Room中还存在一些数据冗余,但可以提高查询效率。
3.2.3数据库模式定义
表2.1数据库模式定义表
编号
逻辑结构(基本表)定义
完整性和安全性
T-1
Worker(详见附录1-1)
(详见附录1-1)
T-2
Dormitory(详见附录1-2)
(详见附录1-2)
T-3
Room(详见附录1-3)
(详见附录1-3)
T-4
Fitment(详见附录1-4)
(详见附录1-4)
T-5
Student(详见附录1-5)
(详见附录1-5)
T-6
SafeGuard(详见附录1-6)
(详见附录1-6)
T-7
ArticalInOut(详见附录1-7)
(详见附录1-7)
T-8
FitmentDestruction(详见附录1-8)
(详见附录1-8)
T-9
FitmentCompensate(详见附录1-9)
(详见附录1-9)
T-10
Accident(详见附录1-10)
(详见附录1-10)
T-11
AccidentResearch(详见附录1-11)
(详见附录1-11)
T-12
AccidentComp
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 学生宿舍 管理 系统 oracle 数据库 设计
![提示](https://static.bdocx.com/images/bang_tan.gif)