学生宿舍标准管理系统数据库设计.doc

信息工程学院
oracle数据库课程设计

学生宿舍管理系统数据库设计

姓 名： 544532 范春江
专 业： 计算机科学和技术
指导老师： 杨海霞
完成日期： .6.26

摘 要
学生宿舍管理系统是应对学生宿舍管理现代化、网络化，逐步摆脱目前学生宿舍管理人工管理方法，提升学生宿舍管理效率而开发，它包含宿舍学生基础信息管理、楼道工人基础信息管理、宿舍楼基础信息管理、宿舍基础信息管理、宿舍事故基础信息管理、宿舍楼物品出入基础信息管理、宿舍楼保卫处基础信息管理、宿舍配置物品及处理管理等八大功效模块，并提供了对各功效模块查询和更新功效，且这两种功效基础上是经过存放过程来实现，其中宿舍学生基础信息管理、宿舍基础信息管理是系统开发关键。
该系统开发由系统需求分析阶段、概念设计阶段、逻辑设计阶段、数据库实施阶段、系统调试和测试阶段、参考文件、附录等阶段组成。
关键字：学生宿舍管理，宿舍管理现代化，宿舍管理网络化，人工管理，功效模块，存放过程

目 录
1. 系统需求分析阶段 1
1.1 引言 1
1.2 目标和任务 1
1.2.1 需求分析阶段目标 1
1.2.2 需求分析阶段任务 1
1.2.3 需求分析阶段结果 2
2. 概念设计阶段 11
2.1 引言 11
2.2 概念模型设计 12
2.3 新系统步骤 13
3．逻辑设计阶段 14
3.1逻辑设计任务和目标 14
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
参考文件 33
附录1 数据库逻辑结构定义 34
附录2 存放过程定义 38
附录3 数据查看和存放过程功效验证 43
附录4 全部SQL运行语句 48

1. 系统需求分析阶段
1.1 引言
经过对北校区25个学生宿舍楼实地调查，了解到现在学生宿舍管理仍停留在完全人工管理阶段，楼管处没有标准住宿学生存档信息。这中人工管理方法费时、费事、费力，造成工作效率低下。开发出适宜学生宿舍管理系统，能够方便学生宿舍管理，提升宿舍管理工作效率及查询效率。
1.2 目标和任务
1.2.1 需求分析阶段目标
（1）了解现在宿舍管理现实状况和SQL Server 功效和特点。
（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层数据步骤图：从管理者角度出发
图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图以下所表示：

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－１
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
AccidentCompensate（详见附录1－12）
（详见附录1－12）
3.2.4用户子模式设计
表2.2 用户子模式设计(View)列表
编号
用户子模式(View)
作用(共性：提供数据保密和安全保护机制)
V－1
WorView
便于查询和修改楼道工人基础信息
V－2
DormView
方便宿舍楼基础信息查询、更新
V－3
RoomView
方便于宿舍基础信息查询和更新
V－4
FitView
用于宿舍楼配置物品基础信息查询
V－5
StuView
便于查询和更改学生基础信息
V－6
SGView
方便学生查询宿舍保卫处基础信息
V－7
ArIOView
方便于物品出入管理和信息查询、更改
V－8
FDView
便于宿舍物品损坏登记及处理和信息查询
V－9
FCView
查询损坏物品赔偿基础信息，便于宿舍物品管理
V－10
AccView
方便学生事故注册及保卫人员对事故注册查询
V－11
ARView
便于学生查询宿舍事故调查基础信息
V－12
ACView
方便宿舍事故赔偿信息查询和更新
3.3数据处理
系统功效模块图：

4．物理设计阶段
4.1物理设计阶段目标和任务
数据库物理设计就是为逻辑数据模型选择一个最适宜应用要求物理结构过程，在这个阶段中要完成两大任务：
（1）确定数据库物理结构，在关系数据库中关键是存取方法和存放结构；
（2）对物理结构进行评价，评价关键是时间和空间效率。
4.2数据存放方面
为数据库中各基础表建立索引以下：
1. 因为基础表Room，Student主码RNo，StuNo常常在查询条件和连接操作连接条件中出现，且它们值唯一，考虑在两个属性上建立唯一性索引；
2. Dormitory主码DorNo，DorCampus，DorLocation常常在查询条件中出现，且它们组合值唯一，考虑在它们之上建立组合索引；
3. 基础表Student一属性StuName，常常在查询条件中出现，且常常出现在相等比较条件中，考虑在其之上建立聚簇索引；
4. 基础表Fitment、SafeGuard属性值几乎不会有什么改变，更新率很低，可考虑合适建立索引；
5. 基础表Worker，ArticalInOut，FitmentDestruction，FitmentCompensate，Accident，AccidentResearch，AccidentCompensate属性值常常发生改变，权衡系统为维护索引付出代价，可考虑不建立索引，也能够合适建立索引。
4.3系统功效模块
4.3.1 楼道工人基础信息查询和更新模块
将实现对楼道工人基础信息查询和更新（修改、插入、删除）操作，方便于楼道工人任用和更换，具体功效模块图以下：

图4.2 楼道工人基础信息查询、更新功效模块图
(注： 表示系统给用户信息，以下和此相同)
4.3.2 宿舍楼基础信息查询和更新模块
将完成对宿舍楼基础信息查询、更新（修改、插入、删除）操作，便于宿舍集中管理，具体功效模块图以下所表示：

图4.3 宿舍楼基础信息查询、更新功效模块图
4.3.3 宿舍基础信息查询和更新模块
将达成对宿舍基础信息查询、更新（修改、插入、删除）操作目标，具体功效模块图以下所表示：

图4.4 宿舍基础信息查询、更新功效模块图
4.3.4 学生基础信息查询和更新模块
将完成对学生基础信息查询和插入、删除、修改等更新操作，具体功效模块以下所表示：

图4.5 宿舍学生基础信息查询、更新功效模块图
4.3.5 宿舍物品查询和更新模块
将实现对宿舍物品基础信息查询、插入、删除、修改等操作，以方便于宿舍物品配置，具体功效模块图以下：

图4.6 宿舍物品基础信息查询、更新功效模块图
4.3.6 宿舍事故查询和更新模块
将实现对宿舍事故插入和更新操作，方便宿舍事故快速处理，立即了解事故处理结果，具体功效模块图以下：

图4.7 宿舍事故基础信息查询、更新功效模块图
4.3.7 宿舍物品处理查询和更新模块
将完成对宿舍物品处理基础信息查询、插入、删除、修改等操作，方便于宿舍物品处理，具体功效模块图以下所表示：

图4.8 宿舍物品处理基础信息查询、更新功效模块图
4.3.8 宿舍保卫处基础信息查询和更新模块
将实现对宿舍保卫处基础信息查询和更新（包含更改、插入、删除）操作，方便于宿舍意外事故处理，具体功效模块图以下：

图4.9 宿舍楼保卫处基础信息查询、更新功效模块图
5．数据库实施阶段
5.1建立数据库、数据表、视图、索引
5.1.1 建立数据库
create database Student_Dormitory_Management;
5.1.2 建立数据表
（1）楼道工人基础信息表建立：
create table Worker（
WorNo char(5） not null unique,
WorName char(10) not null,
WorType char(8) not null,
WorWage int not null,
WorSex char(2) not null,
WorPhNo char(12) null,
WorTime char(30) null,
DorNo smallint not null,
DorCampus char(4) not null,
DorLocation char(4) not null,
primary key(WorNo),
foreign key(DorNo， DorCampus， DorLocation) references Dormitory(DorNo，DorCampus，DorLocation),
check(WorWage >= 0),
check(WorSex = ‘男’ or WorSex = ‘女’));
（2）宿舍楼基础信息表建立：
create table Dormitory(
DorNo smallint not null,
DorCampus char(4) not null,
DorLocation char(4) not null,
DorPhNo char(12) null,
DorAdminist char(10) null,
primary key(DorNo,DorCampus,DorLocation),
check(DorNo>0 and DorNo<100));
（3）宿舍基础信息表建立：
create table Room(
RNo char(6) not null unique,
RHeader char(10) null,
RGrade char(4) not null,
RDepart char(20) not null,
RPerfect char(20) not null,
DorNo smallint not null,
DorCampus char(4) not null,
DorLocation char(4) not null,
primary key(RNo),
foreign key(DorNo， DorCampus， DorLocation) references
Dormitory(DorNo，DorCampus，DorLocation));
（4）宿舍楼配置物品基础信息表建立：
create table Fitment(
FitName char(16) not null unique,
FitPrice float not null,
FitNum int not null,
DorNo smallint not null,
DorCampus char(4) not null,
DorLocation char(4) not null,
primary key(FitName),
foreign key(DorNo， DorCampus， DorLocation) references
Dormitory(DorNo，DorCampus，DorL