课程设计指导书-.doc

个人收集整理 勿做商业用途
课程设计指导书
一、目的
关系数据库技术应用SQLSERVER数据库课程设计作为独立的教学环节，是《信息管理专业》实践性环节系列之一，是学习《数据库技术与应用》课程后进行的一次全面的综合练习。其目的在于加深对关系数据库理论和基本知识的理解，初步掌握使用各种关系数据库为后台数据库设计一个信息管理系统，综合训练学生的分析问题、设计的基本内容和方法,提高解决实际管理问题的能力，以培养学生的专项技能和职业能力。
二、内容及要求
本课程设计重视书面材料的撰写（数据库设计前期的调查，数据库系统分析，用户界面设计）,要求最后采用相应的程序开发工具（例如VB、PowerBuilder、Delphi、ASP、JSP、VB。NET等）进行信息系统的开发实施.
1、根据数据库课程设计时间选择适当规模大小的设计课题(给出部分课题供参考,也可自己选择题目,前提是经过指导教师的同意）。
2、根据合理的进度安排，按照系统开发的流程及方法,踏实地开展SQLSERVER数据库课程设计活动.
3、SQLSERVER数据库课程设计过程中，根据选题的具体需求，在开发各环节中撰写相关的技术文档,最后要求提交比较详细的SQLSERVER数据库课程设计报告和相关的设计作品。
4、根据自己的能力选择适合自己的层次.
5、最后根据设计的结果递交一个可以运行的系统或一个符合要求的数据库。
三、数据库课程设计时间安排
分散进行(1－16周).课程设计的截止时间为2012年12月20日，逾后者将取消本次课程设计的成绩。
四、考查
由指导教师根据学生完成数据库课程设计任务的情况（数据库课程设计报告的质量40％和系统开发过程的工作态度20％，系统开发情况40%)综合打分。成绩评定实行百分制。注意：课程设计最后要随机抽取不少于占总数1/3的小组进行答辨。
五、报告撰写要求
课程设计报告撰写的基本要求是报告原则上不少于4000字，需在封面注明设计选题、班级、课题组成员姓名、学号，其正文至少包括如下几个方面的内容：
1、系统概述（现状分析,系统目标等）
2、系统数据库分析部分(必需）
1）、需求分析
2）、数据库物理结构分析
3)、数据库逻辑结构设计（重点）
4）、数据词典
3、系统（界面）设计部分(必需）
1）、数据录入、修改、删除界面设计
2）、数据查询与打印输出设计
3）、系统的维护、安全设计
六、参考题目
图书管理系统（实验室物资管理系统,学生选课管理系统，学生学籍管理系统，学生成绩管理系统,学生公寓管理系统,机房管理系统，单位工资管理系统，商场销售管理系统等)，同学们也可以提出自己的课题名。
七、具体要求：
（一)设计分析报告要求:
1．需求分析内容：
l 用户需求说明；
l 顶层上下文数据流图，选择画出一个一层的数据流图；
l 选择说明一个完整的数据字典。
2．概念设计内容：
l 画出完整的E-R模型图；
l 包括实体、联系以及实体、联系的属性。
3．逻辑设计:把E—R图转换为关系表。
l 实体类型的转换
l 联系的转换
l 视图设计（设计一些常用的视图以供查询，如图书和读者信息的视图）
l 完整性约束设计（实体完整性、参照完整性、用户自定义完整性)
4．系统模块设计：
l 系统的功能划分及描述；
l 主要用户界面；
l 系统使用说明和安装说明等。
5. 数据库实施：
l 存储设计（数据文件、日志文件的大小以及存储位置）
l 索引设计（对经常需要查询的数据建立索引）
l 存储过程设计（对一些复杂的查询和数据的插入更新等操作可封装在存储过程中）
l 触发器的设计（当读者借阅图书时,使该图书的状态变为不可借等)
l 数据库的实施（设计数据进行数据的装载）
6. 系统测试
（二）系统功能要求（针对于图书馆管理系统，其他管理系统可参考此项)
1．基本实体类型（参考）:
l 图书借阅者实体
l 图书实体
l 图书管理员实体
l 违规类型实体
2．管理功能：
l 用户（管理员和借阅者）登录帐户管理
l 图书借阅/归还管理
l 违规处罚管理(要记录每次处罚情况)
l 各种必要的查询和报表功能
3．查询界面和条件
l 要有两个以上的多表连接查询；
l 要有两个以上的多个条件组合（与、或）查询；
l 每类基本的实体都有增、删、改和查询界面；
(三)其它要求
1．界面要求 要求界面美观，操作方便。
2．安全性需求(可简化）
l 限制用户对数据的访问范围
l 限制用户操作级别（普通用户、设备管理员、系统管理员)
l 限制对数据表修改权限
八、能力要求
（1）基本设计要求：(可参考附录一的课程设计报告)
要求学生设计一个数据库，该数据库能够为某一系统应用，并且要符合以下要求:
l 该系统开发由系统需求分析阶段、概念设计阶段、逻辑设计阶段、数据库实施阶段、系统调试和测试阶段、参考文献、附录等阶段组成.
l 数据库的完整性约束。
l 使用select完成较为复杂的查询。
l 使用存储过程实现一部分复杂的应用逻辑。
l 为不同的用户设计不同的用户视图.
l 为使用该数据库的系统设计完整的功能。
l 课程设计报告。
（2）较高要求（可参考附录2的课程设计报告）
要求学生设计带有数据库的应用系统,该系统能够完成一些基本的功能，如登陆、注册、更新、删除等，并且符合以下要求:
l 该系统开发由系统需求分析阶段、概念设计阶段、逻辑设计阶段、数据库实施阶段、系统调试和测试阶段、参考文献、附录等阶段组成。
l 为不同的用户设计不同的用户视图,并能通过视图进行查询。
l 程序开发(自学一门面向对象的程序语言,进行系统的开发）。
l 课程设计报告.
同学们可根据自己的能力完成最后的课程设计。

附录1
课程设计论文

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

姓 名： 翟紫阳
专 业： 信息管理与信息技术
指导老师：
完成日期： 2012年12月13日

VII

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

目 录
1. 系统需求分析阶段 6
1。1 引言 6
1.2 目标与任务 6
1。2.1 需求分析阶段的目标 6
1.2.2 需求分析阶段的任务 6
1。2.3 需求分析阶段成果 6
2. 概念设计阶段 6
2。1 引言 6
2.2 概念模型设计 6
2.3 新系统流程 6
3．逻辑设计阶段 6
3。1逻辑设计的任务和目标 6
3.2数据组织 6
3。2.1将E—R图转换为关系模型 6
3。2.2模型优化 6
3.2.3数据库模式定义 6
3.2。4用户子模式设计 6
3.3数据处理 6
4．物理设计阶段 6
4。1物理设计阶段的目标与任务 6
4。2数据存储方面 6
4.3系统功能模块 6
4。3.1 楼道工人基本的信息查询和更新模块 6
4.3.2 宿舍楼基本信息的查询和更新模块 6
4.3.3 宿舍基本信息的查询和更新模块 6
4.3.4 学生基本信息的查询和更新模块 6
4.3。5 宿舍物品的查询和更新模块 6
4.3.6 宿舍事故的查询和更新模块 6
4.3.7 宿舍物品处理的查询和更新模块 6
4。3。8 宿舍保卫处基本信息的查询和更新模块 6
5．数据库实施阶段 6
5.1建立数据库、数据表、视图、索引 6
5.1.1 建立数据库 6
5。1.2 建立数据表 6
5。1。3 建立视图 6
5.1。4 建立索引 6
5。2数据入库 6
5.3创建各个功能的存储过程 6
6．系统调试和测试 6
7．实习心得 6
8．存在的问题及建议 6
致谢 6
参考文献 6
附录1 数据库逻辑结构定义 6
附录2 存储过程定义 6
附录3 数据查看和存储过程功能的验证 6
附录4 所有的SQL运行语句 VI

II
1。 系统需求分析阶段
1。1 引言
通过对北校区25个学生宿舍楼的实地调查，了解到现在的学生宿舍管理仍停留在完全的人工管理阶段，楼管处没有标准的住宿学生存档信息。这中人工管理方式费时、费事、费力，造成工作效率低下。开发出合适的学生宿舍管理系统,可以方便学生宿舍的管理，提高宿舍管理工作效率及查询效率。
1。2 目标与任务
1。2.1 需求分析阶段的目标
（1)了解目前宿舍管理的现状以及SQL Server 2000的功能和特点.
(2）通过实地调查和问答－记录的方式了解宿舍管理的工作业务流程，并记录和处理相关的数据。
（3）与指导教师交流个人想法，征求意见，改正不合理的地方，为下面的概念设计与逻辑设计奠定基础.
1。2。2 需求分析阶段的任务
（1）处理对象:
系统要处理的对象包括宿舍楼基本信息、学生基本信息、宿舍基本信息、楼道工作人员基本信息、宿舍保卫处基本信息、宿舍事故基本信息、物品出入基本信息等七个方面，各个对象包括信息如下所示（详细的数据见于数据字典):
1．车库基本信息(）：包括 汽车编号、汽车型号、生产日期、价格、生产厂家可方便查询汽车的信息的查询以及更新。
2．客户基本信息（）：包括 姓名、联系方式、住址和客户编号利用这些数据可以快速的查找到客户的信息并更改。
（2）处理功能要求
系统主要完成一下几个功能：
1．车库基本信息查询与修改;
2．客户基本信息查询与更新;
3．汽车销售记录查询及修改
(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 宿舍事故基本信息的查询、更新