课程设计指导书-.doc

个人收集整理 勿做商业用途课程设计指导书一、目的 关系数据库技术应用SQLSERVER数据库课程设计作为独立的教学环节，是信息管理专业实践性环节系列之一，是学习数据库技术与应用课程后进行的一次全面的综合练习。其目的在于加深对关系数据库理论和基本知识的理解，初步掌握使用各种关系数据库为后台数据库设计一个信息管理系统，综合训练学生的分析问题、设计的基本内容和方法,提高解决实际管理问题的能力，以培养学生的专项技能和职业能力。 二、内容及要求 本课程设计重视书面材料的撰写（数据库设计前期的调查，数据库系统分析，用户界面设计）,要求最后采用相应的程序开发工具（例如VB、PowerBuilder、Delphi、ASP、JSP、VB。NET等）进行信息系统的开发实施.1、根据数据库课程设计时间选择适当规模大小的设计课题(给出部分课题供参考,也可自己选择题目,前提是经过指导教师的同意）。2、根据合理的进度安排，按照系统开发的流程及方法,踏实地开展SQLSERVER数据库课程设计活动.3、SQLSERVER数据库课程设计过程中，根据选题的具体需求，在开发各环节中撰写相关的技术文档,最后要求提交比较详细的SQLSERVER数据库课程设计报告和相关的设计作品。 4、根据自己的能力选择适合自己的层次.5、最后根据设计的结果递交一个可以运行的系统或一个符合要求的数据库。三、数据库课程设计时间安排 分散进行(116周).课程设计的截止时间为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逻辑设计:把ER图转换为关系表。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. 系统需求分析阶段61。1 引言61.2 目标与任务61。2.1 需求分析阶段的目标61.2.2 需求分析阶段的任务61。2.3 需求分析阶段成果62. 概念设计阶段62。1 引言62.2 概念模型设计62.3 新系统流程63逻辑设计阶段63。1逻辑设计的任务和目标63.2数据组织63。2.1将ER图转换为关系模型63。2.2模型优化63.2.3数据库模式定义63.2。4用户子模式设计63.3数据处理64物理设计阶段64。1物理设计阶段的目标与任务64。2数据存储方面64.3系统功能模块64。3.1 楼道工人基本的信息查询和更新模块64.3.2 宿舍楼基本信息的查询和更新模块64.3.3 宿舍基本信息的查询和更新模块64.3.4 学生基本信息的查询和更新模块64.3。5 宿舍物品的查询和更新模块64.3.6 宿舍事故的查询和更新模块64.3.7 宿舍物品处理的查询和更新模块64。3。8 宿舍保卫处基本信息的查询和更新模块65数据库实施阶段65.1建立数据库、数据表、视图、索引65.1.1 建立数据库65。1.2 建立数据表65。1。3 建立视图65.1。4 建立索引65。2数据入库65.3创建各个功能的存储过程66系统调试和测试67实习心得68存在的问题及建议6致谢6参考文献6附录1 数据库逻辑结构定义6附录2 存储过程定义6附录3 数据查看和存储过程功能的验证6附录4 所有的SQL运行语句VIII1。 系统需求分析阶段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 数据项列表数据项编号数据项名数据项含义与其它数据项的关系存储结构别名DI1StuNo学生编号char（9)学号DI-2DepName学生所在学院char(20）学院DI-3StuName学生姓名char(10）姓名DI4StuSex学生性别char(2）性别DI-5StuHome学生来自省份char(10)祖籍DI-6StuBorth学生出生时间Date出生日期DI-7StuETime学生入学时间Date入学时间DI8StuPerfect学生所在专业char（20)专业DI-9StuClass学生所在班级编号Int编号DI-10WorNo工作人员编号char(5)编号DI-11WorName工作人员姓名char（10)姓名DI12WorType工作类型char(8)工作类型DI13WorWage工作人员工资Int月工资DI-14WorSex工作人员性别char(2)性别DI15WorPhNo工作人员联系方式char（12)电话DI-16WorTime工作人员工作时间char(30)工作时间DI17RNo宿舍编号char(6）舍号DI-18RHeader舍长信息等于StuNamechar(10)舍长DI19ROne宿舍学生信息同上char(10）舍员1DI-20RTwo宿舍学生信息同上char（10)舍员2DI21RThree宿舍学生信息同上char（10）舍员3DI22RFour宿舍学生信息同上char（10)舍员4DI23RFive宿舍学生信息同上char(10)舍员5DI24RSix宿舍学生信息同上char（10)舍员6DI-25RGrade宿舍学生所属年级等于StuETimechar（4）年级DI-26RDepart宿舍学生所在学院等于DepNamechar(20）学院DI-27RPerfect宿舍学生所学专业等于StuPerfectchar（20)专业DI-28RClass学生所在班级编号等于StuClasschar（2）班级DI-29DorNo宿舍楼编号smallint宿舍楼号DI-30DorCampus宿舍楼所属校区char(4)校区DI31DorLocation宿舍楼在校区位置char（4）宿舍区位DI-32DorPhNo宿舍楼管处电话char（12）电话DI33DorAdminist宿舍楼楼管员信息等于WorNochar(10）楼管员DI34SGName保卫处名称char（15)名字DI-35SGWorNum保卫处人员总数Int人员数目DI-36SGHeader保卫处负责人信息char（10)负责人DI-37SGPhone保卫处电话char(12)电话DI-38FitName宿舍物品名称char(16）宿舍物品DI39FitPrice宿舍物品价格Float价格DI-40FitNum每一种宿舍的数量Int数量DI-41FDFitment损坏物品信息等于FitNamechar（16)物品名DI-42FDStudent损坏的学生信息等于StuNochar（9）学生DI-43FDRoom损坏物品宿舍信息等于RNochar（6）舍号DI-44FDFitNum损坏物品的数量Int数量DI-45FCompFit赔偿物品信息等于FitNamechar（16）物品名DI46FCompStu需赔偿学生信息等于StuNochar(9)学生DI-47FCompMon赔偿价格Float赔偿价格DI48FCompPrin赔偿负责人信息等于WorNochar（10）负责人DI-49FCompDate赔偿日期Date日期DI50FCompNum赔偿物品数量Int数量DI51AcNo事故编号int编号DI52AcType事故类型char(10）类型DI-53AcArtical事故损失物品char(30)物品名DI54AcArNum事故损失物品数量Int数量DI55AcStu事故受害学生等于StuNochar（9)学生DI56AcDate事故发生日期Date日期DI57AcPrin事故负责人信息等于SGHeaderchar(15）负责人DI-58AcStuPh受害人联系方式char(12）学生电话DI-59AcVerify事故是否属实Bool核查DI60ARNo事故调查编号char(4）编号DI-61ARName事故调查名称char(15)调查DI62ARPrin事故调查负责人等于SGHeaderchar（10)负责人DI63ARResult事故调查结果Bool结果DI-64ACStu事故赔偿学生信息等于StuNochar(10)学生DI-65ACArtical事故赔偿物品信息char(30)物品名DI-66ACDate事故赔偿日期Date日期DI67ACPrin事故赔偿负责单位等于SGHeaderchar（15）负责单位DI68AIOStu要求物品出入学生等于StuNochar（10）学生DI-69AIOArtical出入物品信息char（20)物品名DI-70AIOPrin出入物品审查人等于WorNochar(10)负责人DI-71AIODate出入物品日期Date日期DI-72AIONo物品出入序号Int序号（b)数据结构:表1。2 数据结构列表数据结构编号数据结构名数据结构含义组成DS1Student宿舍学生信息StuNo,DepName,StuName，StuSex，StuHome，StuBorth,StuETime，StuPerfect,StuClassDS-2Worker宿舍楼工作人员信息WorTime,WorName,WorType，WorWage,WorSex，WorPhNo,WorNoDS-3Room宿舍信息RNo，RHeader,ROne, RClass，RThree，RFour，RFive,RSix，RGrade,RDepart,RPerfect，RTwo,DS4Dormitory宿舍楼信息DorNo，DorCampus,DorPhNoDorLocation，DorAdministDS-5SafeGuard宿舍保卫处信息SGName,SGWorNum，SGHeader，SGPhoneDS6Fitment宿舍物品配备信息FitName，FitPrice,FitNumDS-7FitmentDestruction宿舍物品损坏信息FDFitment，FDStudent,FDRoom,FDFitNumDS8FitmentCompensate宿舍损坏物品赔偿信息FCompFit,FCompStu，FCompPrin,FCompDate，FCompNumDS9Accident宿舍事故注册信息AcNo，AcType， AcStu，AcDate,AcArtical，AcVerify,AcPrin,AcArNum，AcStuPhDS10AccidentResearch宿舍事故调查信息ARNo，ARName,ARPrin，ARResultDS-11AccidentCompensate事故损失物品赔偿信息ACStu，ACArtical，ACDate,ACPrinDS12ArticalInOut宿舍楼物品出入信息AIOStu,AIOArtical，AIOPrin,AIODate，AIONo（5）处理逻辑描述（判定表或判定树）表1。3 处理逻辑列表判定条件决策判断用户查询涉及的功能模块宿舍基本信息模块、宿舍楼基本信息模块、学生基本信息模块、宿舍楼配备物品基本信息模块、宿舍事故基本信息模块、宿舍楼物品出入基本信息模块、宿舍楼保卫处基本信息模块、楼道工人基本信息模块：先确定查询所涉及的功能模块；然后,确定要查询的内容，确定查询数据流向；最后显示查询结果。判断用户修改要涉及的模块，同时把相应的修改数据传到相应的模块之中宿舍基本信息模块、宿舍楼基本信息模块、学生基本信息模块、宿舍楼配备物品基本信息模块、宿舍事故基本信息模块、宿舍楼物品出入基本信息模块、宿舍楼保卫处基本信息模块、楼道工人基本信息模块：先确定更新所涉及的功能模块；然后，把更新信息传送到相应的模块中；最后，进行相应的更新操作。2. 概念设计阶段2。1 引言概念设计阶段主要是将需求分析阶段得到的用户需求抽象为信息结构（概念模型)的过程,它是整个数据库设计的关键，包括概念模型设计和新系统流程两个阶段.2。2 概念模型设计（1）根据不同的对象，从第3层数据流程图（中层数据流程图）入手，分别画出分ER图：（a)从数据流程图图2.4 与图 2.5 抽象出的分ER图:图3.1 分ER图1图3。2 分ER图2图3。3 分ER图3（b）从数据流程图图2。6与图2.8 抽象出的分ER图:图3。4 分ER图4（c）从数据流程图图2。7 抽象出的分ER图：图3。5 分ER图5（2）各分ER图中每个实体的属性如下所示：学生：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)；各分ER图中联系的属性如下所示：物品出入:ArticalInOut(AIONo，AIOStu，AIOArtical，AIOPrin,AIODate）;宿舍物品处理：包含物品损坏和物品赔偿两个数据结构（将在逻辑设计阶段给出）;事故:包含宿舍事故注册、宿舍事故调查、事故损失物品赔偿三个数据结构（具体的结构将在系统逻辑设计阶段给出).(注:为了节省篇幅，实体与属性的关系没有用图形表示，实体的标识码用下划线划出.)（3）合并各分图，消除属性冲突、命名冲突、结构冲突等三类冲突，得到初步ER图，再消除不必要冗余,得到的基本E-R图如下所示：2.3 新系统流程新系统流程图:3逻辑设计阶段3.1逻辑设计的任务和目标以上的概念设计阶段是独立于任何一种数据模型的，但是逻辑设计阶段就与选用的DBMS产品发生关系了，系统逻辑设计的任务就是将概念设计阶段设计好的基本ER图转换为选用DBMS产品所支持的数据模型相符合的逻辑结构。具体内容包括数据组织（将E-R图转换成关系模型、模型优化、数据库模式定义、用户子模式设计)、数据处理（画出系统功能模块图）两大任务3。2数据组织3。2。1将E-R图转换为关系模型由于宿舍楼与楼道工人的联系方式是1:n（一对多），可以将其之间的联系与n端实体楼道工人合并，宿舍楼与宿舍之间的联系、宿舍与学生之间的联系方式也是1:n，同样也将其之间的联系与n端实体宿舍、学生合并，而宿舍物品与学生、学生与楼道工作人员之间的联系方式则是n：m(多对多），这样要把它们之间的联系转化为独立的关系模式，保卫处与学生之间的联系是1:n（一对多），但是它们之间的联系事故则包含数据结构，为了便于模型优化，将其联系也转化成独立的关系模式，具体的基本ER图向关系模型的转化如下：楼道工人：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 数据库模式定义表编号逻辑结构（基本表)定义完整性和安全性TWorker（详见附录11）（详见附录11）T2Dormitory（详见附录12）（详见附录12)T3Room（详见附录13)（详见附录13）T4Fitment（详见附录14）（详见附录14）T5Student（详见附录15)（详见附录15）T6SafeGuard(详见附录16）（详见附录16）T7ArticalInOut（详见附录17）(详见附录17）T8FitmentDestruction（详见附录18）(详见附录18）T9FitmentCompensate（详见附录19）（详见附录19）T10Accident(详见附录110)（详见附录110）T11AccidentResearch（详见附录111)（详见附录111）T12AccidentCompensate（详见附录112）(详见附录112）3。2.4用户子模式设计表2.2 用户子模式设计(View）列表编号用户子模式(View）作用（共性：提供数据保密和安全保护机制）V1WorView便于查询和修改楼道工人的基本信息V2DormView方便宿舍楼的基本信息的查询、更新V3RoomView以便于宿舍的基本信息的查询和更新V4FitView用于宿舍楼配备物品的基本信息的查询V5StuView便于查询和更改学生的基本信息V6SGView方便学生查询宿舍保卫处的基本信息V7ArIOView以便于物品出入的管理和信息的查询、更改V8FDView便于宿舍物品损坏的的登记及处理和信息的查询V9FCView查询损坏物品赔偿的基本信息，便于宿舍物品的管理V10AccView方便学生事故的注册及保卫人员对事故注册的查询V11ARView便于学生查询宿舍事故调查的基本信息V12ACView方便宿舍事故赔偿的信息查询和更新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 宿舍事故基本信息的查询、更新