(数据库课程设计)学生宿舍管理系统毕业设计论文(2)

来源：56doc.com 资料编号：5D4019 资料等级：★★★★★ %E8%B5%84%E6%96%99%E7%BC%96%E5%8F%B7%EF%BC%9A5D4019

资料以网页介绍的为准,下载后不会有水印.资料仅供学习参考之用. 密保惠帮助

资料介绍

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）