《数据库系统基础学习知识原理》课程教学设计报告样式典范(学生宿舍管理方案计划系统数据库设计).doc

-! 题 目： 学生宿舍管理系统数据库设计 课程设计（论文）任务书 软 件 学 院 网络工程 专 业 班 一、课程设计(论文)题目 学生宿舍管理系统数据库设计 二、课程设计(论文)工作自 2015 年 12 月 28 日起至 2016 年 1月 1 日止 三、课程设计(论文) 地点: 软件工程实训中心 四、课程设计(论文)内容要求： 1．本课程设计的目的 （1）巩固和加深对数据库基本知识的理解，提高综合运用课程知识的能力。 （2）使学生巩固所学的理论基础知识的理解，掌握数据库设计的全过程及技术与方法。 （3）培养学生编制软件文档及开发应用系统的能力，提高学生独立分析问题、解决问题的能力，锻炼和加强学生的动手能力。使学生掌握使用各种计算机资料和有关参考资料。 2．课程设计的任务及要求 （1）根据选题任务要求，收集并查询相关文献资料，明确系统需求；通过对系统的功能分析和数据分析进行系统的需求分析设计，完成业务流程图、数据流图（DFD图）及数据字典（DD）等阶段性成果； （2）数据库的概念结构设计，完成基本全局E-R图的设计并体现设计过程； （3）数据库的逻辑结构设计，完成数据库关系模式的设计及优化； （4）数据库的物理结构设计，完成数据库实施的所有sql脚本的编写及索引文件的创建；完成安全性控制及完整性约束； （5）数据库的实施； （6）特别要求自己独立完成； 2）创新要求： 在基本要求达到后，可进行创新设计，如完善的功能、友好的人机界面。 3）课程设计论文编写要求 （1）要按照书稿的规格打印与写课程设计报告书； （2）报告包括目录、绪论、正文、小结、参考文献、附录等； （3）课程设计报告装订按学校的统一要求完成； 4）课程设计进度安排 内容 天数 地点 构思及收集资料 1 图书馆 数据库设计 3 实验室 撰写报告 1 图书馆、实验室 学生签名： (必须手写) 2015 年 12 月28 日 课程设计(论文)评审意见 （1）考勤（20分）：优（　）、良（　）、中（　）、一般（　）、差（　）； （2）设计内容（40分）：优（　）、良（　）、中（　）、一般（　）、差（　）； （3）答辩　　（25分）：优（　）、良（　）、中（　）、一般（　）、差（　）； （4）文档格式规范整齐（15分）优（　）、良（　）、中（　）、一般（　）、差（　）； （5）任何抄袭成绩一律归零； 评阅人： 职称： 讲师 2016年 1 月 1日 目 录 1. 系统需求分析阶段 1 1.1 引言 1 1.2 目标与任务 1 1.2.1 需求分析阶段的目标 1 1.2.2 需求分析阶段的任务 1 1.2.3 需求分析阶段成果 3 2.1 引言 12 2.2 概念模型设计 12 2.3 新系统流程 14 3．逻辑设计阶段 15 3.1逻辑设计的任务和目标 15 3.2数据组织 15 3.2.1将E-R图转换为关系模型 15 3.2.2模型优化 16 3.2.3数据库模式定义 16 3.2.4用户子模式设计 17 3.3数据处理 17 4．物理设计阶段 18 4.1物理设计阶段的目标与任务 18 4.2数据存储方面 18 4.3系统功能模块 18 4.3.1 楼道工人基本的信息查询和更新模块 18 4.3.2 宿舍楼基本信息的查询和更新模块 19 4.3.3 宿舍基本信息的查询和更新模块 20 4.3.4 学生基本信息的查询和更新模块 20 4.3.5 宿舍物品的查询和更新模块 21 4.3.6 宿舍事故的查询和更新模块 21 4.3.7 宿舍物品处理的查询和更新模块 22 4.3.8 宿舍保卫处基本信息的查询和更新模块 22 5．数据库实施阶段 24 5.1建立数据库、数据表、视图、索引 24 5.1.1 建立数据库 24 5.1.2 建立数据表 24 5.1.3 建立视图 28 5.1.4 建立索引 30 5.2数据入库 30 参考文献 32 附录1 数据库逻辑结构定义 33 附录2 存储过程定义 37 附录3 所有的SQL运行语句 42 -! 1. 系统需求分析阶段 1.1 引言 通过对学生宿舍楼的实地调查，了解到现在的学生宿舍管理仍停留在完全的人工管理阶段，楼管处没有标准的住宿学生存档信息。这中人工管理方式费时、费事、费力，造成工作效率低下。开发出合适的学生宿舍管理系统，可以方便学生宿舍的管理，提高宿舍管理工作效率及查询效率。 1.2 目标与任务 1.2.1 需求分析阶段的目标 （1）了解目前宿舍管理的现状以及SQL Server 2000的功能和特点。 （2）通过实地调查和问答－记录的方式了解宿舍管理的工作业务流程，并记录和处理相关的数据。 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）数据流程图 顶层数据流程图： 第2层数据流程图：从学生角度出发 第2层数据流程图：从管理者角度出发 第3层数据流程图：从新生角度出发 第3层数据流程图：从毕业生角度出发 第3层数据流程图：从宿舍楼物品出入出发 第3层数据流程图：从宿舍事故角度出入出发 第3层数据流程图：从楼道工作人员的任用角度出发 第3层数据流程图：从管理者和外来访客的角度出发 （3）数据字典 （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 （4）处理逻辑描述（判定表或判定树） 表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的属性值经常发生变化，权衡系统为维护索引付出的代价，可考虑不建立索引，也可以适当建立索引。 5．物理设计阶段 5.1系统功能模块 5.1.1 楼道工人基本的信息查询和更新模块 将实现对楼道工人基本信息的查询和更新（修改、插入、删除）操作，方便于楼道工人的任用和更换，具体的功能模块图如下： 图4.2 楼道工人基本信息的查询、更新功能模块图 (注： 表示系统给用户的信息，以下与此相同) 5.1.2 宿舍楼基本信息的查询和更新模块 将完成对宿舍楼基本信息的查询、更新（修改、插入、删除）操作，便于宿舍的集中管理，具体的功能模块图如下所示： 图4.3 宿舍楼基本信息的查询、更新功能模块图 5.1.3 宿舍基本信息的查询和更新模块 将达到对宿舍基本信息的查询、更新（修改、插入、删除）操作的目的，具体的功能模块图如下所示： 图4.4 宿舍基本信息的查询、更新功能模块图 5.1.4 学生基本信息的查询和更新模块 将完成对学生基本信息的查询和插入、删除、修改等更新操作，具体的功能模块如下所示： 图4.5 宿舍学生基本信息的查询、更新功能模块图 5.1.5 宿舍物品的查询和更新模块 将实现对宿舍物品基本信息的查询、插入、删除、修改等操作，以方便于宿舍物品的配备，具体的功能模块图如下： 图4.6 宿舍物品基本信息的查询、更新功能模块图 5.1.6 宿舍事故的查询和更新模块 将实现对宿舍事故的插入和更新操作，方便宿舍事故的快速处理，及时了解事故处理的结果，具体的功能模块图如下： 图4.7 宿舍事故基本信息的查询、更新功能模块图 5.1.7 宿舍物品处理的查询和更新模块 将完成对宿舍物品处理基本信息的查询、插入、删除、修改等操作，方便于宿舍物品的处理，具体的功能模块图如下所示： 图4.8 宿舍物品处理基本信息的查询、更新功能模块图 5.1.8 宿舍保卫处基本信息的查询和更新模块 将实现对宿舍保卫处基本信息的查询和更新（包括更改、插入、删除）操作，方便于宿舍意外事故的处理，具体的功能模块图如下： 图4.9 宿舍楼保卫处基本信息的查询、更新功能模块图 5.2系统模块实现 （如果完成了系统开发，可在此处写出软件设计具体实现的模块截图等，打印时去掉红色字部分）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