学生宿舍管理系统oracle数据库设计Word文档下载推荐.docx
- 文档编号:7194592
- 上传时间:2023-05-08
- 格式:DOCX
- 页数:68
- 大小:1.30MB
学生宿舍管理系统oracle数据库设计Word文档下载推荐.docx
《学生宿舍管理系统oracle数据库设计Word文档下载推荐.docx》由会员分享,可在线阅读,更多相关《学生宿舍管理系统oracle数据库设计Word文档下载推荐.docx(68页珍藏版)》请在冰点文库上搜索。
从毕业生角度出发
从宿舍楼物品出入出发
从宿舍事故角度出入出发
从楼道工作人员的任用角度出发
从管理者和外来访客的角度出发
(4)数据字典
(a)数据项:
系统涉及的数据项有71项
表1.1数据项列表
数据项编号
数据项名
数据项含义
与其它数据项的关系
存储结构
别名
1
学生编号
(9)
学号
2
学生所在学院
(20)
学院
3
学生姓名
(10)
姓名
4
学生性别
(2)
性别
5
学生来自省份
祖籍
6
学生出生时间
出生日期
7
学生入学时间
入学时间
8
学生所在专业
专业
9
学生所在班级编号
编号
10
工作人员编号
(5)
11
工作人员姓名
12
工作类型
(8)
13
工作人员工资
月工资
14
工作人员性别
15
工作人员联系方式
(12)
电话
16
工作人员工作时间
(30)
工作时间
17
宿舍编号
(6)
舍号
18
舍长信息
等于
舍长
19
宿舍学生信息
同上
舍员1
20
舍员2
21
舍员3
22
舍员4
23
舍员5
24
舍员6
25
宿舍学生所属年级
(4)
年级
26
宿舍学生所在学院
27
宿舍学生所学专业
28
班级
29
宿舍楼编号
宿舍楼号
30
宿舍楼所属校区
校区
31
宿舍楼在校区位置
宿舍区位
32
宿舍楼管处电话
33
宿舍楼楼管员信息
楼管员
34
保卫处名称
(15)
名字
35
保卫处人员总数
人员数目
36
保卫处负责人信息
负责人
37
保卫处电话
38
宿舍物品名称
(16)
宿舍物品
39
宿舍物品价格
价格
40
每一种宿舍的数量
数量
41
损坏物品信息
物品名
42
损坏的学生信息
学生
43
损坏物品宿舍信息
44
损坏物品的数量
45
赔偿物品信息
46
需赔偿学生信息
47
赔偿价格
48
赔偿负责人信息
49
赔偿日期
日期
50
赔偿物品数量
51
事故编号
52
事故类型
类型
53
事故损失物品
54
事故损失物品数量
55
事故受害学生
56
事故发生日期
57
事故负责人信息
58
受害人联系方式
学生电话
59
事故是否属实
核查
60
ARNo
事故调查编号
61
事故调查名称
调查
62
事故调查负责人
63
事故调查结果
结果
64
事故赔偿学生信息
65
事故赔偿物品信息
66
事故赔偿日期
67
事故赔偿负责单位
负责单位
68
要求物品出入学生
69
出入物品信息
70
出入物品审查人
71
出入物品日期
72
物品出入序号
序号
(b)数据结构:
表1.2数据结构列表
数据结
构编号
数据结构名
数据结构
含义
组成
宿舍楼工作人员信息
宿舍信息
,
宿舍楼信息
宿舍保卫处信息
宿舍物品配备信息
宿舍物品损坏信息
宿舍损坏物品赔偿信息
宿舍事故注册信息
宿舍事故调查信息
事故损失物品赔偿信息
宿舍楼物品出入信息
(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图中每个实体的属性如下所示:
学生:
(,,,,,,,
,);
宿舍:
(,,,,,,,,
,,,);
宿舍楼:
(,,,,);
宿舍物品:
(,,);
楼道工作人员:
(,,,,,
保卫处:
(,,,);
各分E-R图中联系的属性如下所示:
物品出入:
宿舍物品处理:
包含物品损坏和物品赔偿两个数据结构(将在逻辑设计阶段给出);
事故:
包含宿舍事故注册、宿舍事故调查、事故损失物品赔偿三个数据结构(具体的结构将
在系统逻辑设计阶段给出)。
(注:
为了节省篇幅,实体与属性的关系没有用图形表示,实体的标识码用下划线划出。
)
(3)合并各分E-R图,消除属性冲突、命名冲突、结构冲突等三类冲突,得到初步图,
再消除不必要冗余,得到的基本图如下所示:
2.3新系统流程
新系统流程图:
3.逻辑设计阶段
3.1逻辑设计的任务和目标
以上的概念设计阶段是独立于任何一种数据模型的,但是逻辑设计阶段就与选用的产品发生关系了,系统逻辑设计的任务就是将概念设计阶段设计好的基本图转换为选用产品所支持的数据模型相符合的逻辑结构。
具体内容包括数据组织(将图转换成关系模型、模型优化、数据库模式定义、用户子模式设计)、数据处理(画出系统功能模块图)两大任务
3.2数据组织
3.2.1将图转换为关系模型
由于宿舍楼与楼道工人的联系方式是1(一对多),可以将其之间的联系与n端实体楼道工人合并,宿舍楼与宿舍之间的联系、宿舍与学生之间的联系方式也是1,同样也将其之间的联系与n端实体宿舍、学生合并,而宿舍物品与学生、学生与楼道工作人员之间的联系方式则是(多对多),这样要把它们之间的联系转化为独立的关系模式,保卫处与学生之间的联系是1(一对多),但是它们之间的联系事故则包含数据结构,为了便于模型优化,将其联系也转化成独立的关系模式,具体的基本图向关系模型的转化如下:
楼道工人:
,,,,);
宿舍楼:
宿舍:
,,,,,,);
宿舍物品:
(,,,,,);
,,,,,);
保卫处:
(,,,,,,
,);
宿舍物品处理包含两个数据结构(宿舍物品损坏信息,宿舍物品损坏赔偿信息),基于表的各个属性都是原子项的考虑,现将宿舍物品处理分解为:
宿舍物品损坏、宿舍损坏物品赔偿,具体如下:
宿舍物品损坏:
(,,,,,
(消除命名冲突)
宿舍物品损坏赔偿:
(,,,,
);
宿舍事故包含三个数据结构(宿舍事故注册信息、宿舍事故调查信息、宿舍事故损失物品赔偿信息),同样基于表的原子性的考虑也将事故分解为:
事故注册、事故调查、
事故赔偿,具体如下:
事故注册:
(,,,,,,,
事故调查:
事故赔偿:
(注:
标有直线下划线的为主属性,标有波浪线下划线的是外键属性,主属性与外键属性一起构成主码)
3.2.2模型优化
关系模式,,,,,,,,,不存在非主属性对主属性的部分函数依赖,也不存在传递函数依赖,已经达到了3,但是宿舍关系模式()中存在着一些不应该有的数据冗余,现将模型优化为:
(,,,,,,,);
虽然中还存在一些数据冗余,但可以提高查询效率。
3.2.3数据库模式定义
表2.1数据库模式定义表
逻辑结构(基本表)定义
完整性和安全性
T-1
(详见附录1-1)
T-2
(详见附录1-2)
T-3
(详见附录1-3)
T-4
(详见附录1-4)
T-5
(详见附录1-5)
T-6
(详见附录1-6)
T-7
(详见附录1-7)
T-8
(详见附录1-8)
T-9
(详见附录1-9)
T-10
(详见附录1-10)
T-11
(详见附录1-11)
T-12
(详见附录1-12)
3.2.4用户子模式设计
表2.2用户子模式设计()列表
用户子模式()
作用(共性:
提供数据保密和安全保护机制)
V-1
便于查询和修改楼道工人的基本信息
V-2
方便宿舍楼的基本信息的查询、更新
V-3
以便于宿舍的基本信息的查询和更新
V-4
用于宿舍楼配备物品的基本信息的查询
V-5
便于查询和更改学生的基本信息
V-6
方便学生查询宿舍保卫处的基本信息
V-7
以便于物品出入的管理和信息的查询、更改
V-8
便于宿舍物品损坏的的登记及处理和信息的查询
V-9
查询损坏物品赔偿的基本信息,便于宿舍物品的管理
V-10
方便学生事故的注册及保卫人员对事故注册的查询
V-11
便于学生查询宿舍事故调查的基本信息
V-12
方便宿舍事故赔偿的信息查询和更新
3.3数据处理
系统功能模块图:
4.物理设计阶段
4.1物理设计阶段的目标与任务
数据库的物理设计就是为逻辑数据模型选取一个最合适应用要求的物理结构的过程,在这个阶段中要完成两大任务:
(1)确定数据库的物理结构,在关系数据库中主要是存取方法和存储结构;
(2)对物理结构进行评价,评价的重点是时间和空间效率。
4.2数据存储方面
为数据库中各基本表建立的索引如下:
1.由于基本表,的主码,经常在查询条件和连接操作的连接条件中出现,且它们的值唯一,考虑在两个属性上建立唯一性索引;
2.的主码,,经常在查询条件中出现,且它们的组合值唯一,考虑在它们之上建立组合索引;
3.基本表的一属性,经常在查询条件中出现,且经常出现在相等的比较条件中,考虑在其之上建立聚簇索引;
4.基本表、的属性值几乎不会有什么变化,更新率很低,可考虑适当建立索引;
5.基本表,,,,,,的属性值经常发生变化,权衡系统为维护索引付出的代价,可考虑不建立索引,也可以适当建立索引。
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宿舍事故基本信息的查询、更新功能模块图
4.3.7宿舍物品处理的查询和更新模块
将完成对宿舍物品处理基本信息的查询、插入、删除、修改等操作,方便于宿舍物品的处理,具体的功能模块图如下所示:
图4.8宿舍物品处理基本信息的查询、更新功能模块图
4.3.8宿舍保卫处基本信息的查询和更新模块
将实现对宿舍保卫处基本信息的查询和更新(包括更改、插入、删除)操作,方便于宿舍意外事故的处理,具体的功能模块图如下:
图4.9宿舍楼保卫处基本信息的查询、更新功能模块图
5.数据库实施阶段
5.1建立数据库、数据表、视图、索引
5.1.1建立数据库
;
5.1.2建立数据表
(1)楼道工人基本信息表的建立:
(
(5),
(10),
(8),
(2),
(12),
(30),
(4),
(),
(,,)(,,),
(>
=0),
(=‘男’=‘女’));
(2)宿舍楼基本信息表的建立:
(>
0<
100));
(3)宿舍基本信息表的建立:
(6),
(10),
(20),
(,,)
(,,));
(4)宿舍楼配备物品基本信息表的建立:
(16),
(4),
(5)宿舍学生基本信息表的建立:
(9),
(20),
(10),
(2),
(10),
(6),
(4),
(4),
(),
()(),
(,,),
(>
=10));
(6)宿舍保卫处基本信息表的建立:
(15),
(12),
(>
0));
(7)宿舍楼物品出入基本信息表的建立:
(16),
()(),
(8)宿舍配备物品损坏基本信息表的建立:
(16),
=0));
(9)宿舍损坏配备物品赔偿基本信息表的建立:
(15),
(10)宿舍事故注册基本信息表的建立:
(30),
0),);
(11)宿舍事故调查基本信息表的建立:
()(),);
(12)宿舍事故赔偿基本信息表的建立:
()());
5.1.3建立视图
(1)用于查询和更新楼道工人基本信息的视图定义如下:
(编号,姓名,工作类型,工资,性别,联系方式,
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 学生宿舍 管理 系统 oracle 数据库 设计