处与学生之间的联系是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－１ T－2 T－3 T－4 T－5 T－6 T－7 T－8 T－9 T－10 T－11 T－12
逻辑结构(基本表)定义
Worker（详见附录1－1） Dormitory（详见附录1－2） Room（详见附录1－3） Fitment（详见附录1－4） Student（详见附录1－5） SafeGuard（详见附录1－6） ArticalInOut（详见附录1－7） FitmentDestruction（详见附录1－8） FitmentCompensate（详见附录1－9） Accident（详见附录1－10）
AccidentResearch（详见附录1－11） AccidentCompensate（详见附录1－12）
完整性和安全性
（详见附录1－1） （详见附录1－2） （详见附录1－3） （详见附录1－4） （详见附录1－5） （详见附录1－6） （详见附录1－7） （详见附录1－8） （详见附录1－9） （详见附录1－10） （详见附录1－11） （详见附录1－12）
3.2.4用户子模式设计
表2.2 用户子模式设计(View)列表
编号
V－1 V－2 V－3 V－4 V－5 V－6 V－7 V－8 V－9 V－10 V－11 V－12
用户子模式(View) WorView DormView RoomView FitView StuView SGView ArIOView FDView FCView AccView ARView 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 宿舍基本信息的查询、更新功能模块图
学生宿舍管理系统oracle数据库设计教学总结
