实例2教室管理系统数据库设计Word格式.docx
- 文档编号:15758909
- 上传时间:2022-11-15
- 格式:DOCX
- 页数:34
- 大小:390.74KB
实例2教室管理系统数据库设计Word格式.docx
《实例2教室管理系统数据库设计Word格式.docx》由会员分享,可在线阅读,更多相关《实例2教室管理系统数据库设计Word格式.docx(34页珍藏版)》请在冰豆网上搜索。
教室管理系统的具体功能包括三个方面:
教室查询子系统,卫生管理子系统,设备管理子系统。
教室查询子系统主要完成空闲教室查询(无课教室),教室使用查询的功能;
卫生管理子系统主要完成值班安排与修改功能和值班情况记录的功能;
设备管理子系统比较麻烦,主要是接收损坏信息,通过检查其有效性,把有效的损坏信息分类并且记录,然后通知维修工,再纪录维修情况的功能。
(3)安全性和完整性要求
在这个系统中涉及到了相关人员的问题,而且同一个职工可能在不同的表中存在,要考虑到,如果辞退或者某职工辞职,那么不仅要在职工信息表中删除相应的信息,还要在其他的相关表中删除信息,这就涉及到了安全性的问题,初步打算用一个触发器来解决这个问题。
完整性也是一个重要的内容,它也涉及安全性上的问题。
1.1.3阶段结果
(1)用户调查
本系统的用户范围比较广,教室查询子系统主要针对学生,通过听取周围学生的看法和意见,以及自身的体会,比较充分的了解了学生的需求;
卫生管理子系统主要针对教室管理的员工及其主任,我直接询问了相关的员工,通过对他们的询问,了解了他们的工作的基本流程,及其需求;
设备管理子系统主要针对,教室管理的员工和维修工,通过对员工的咨询,了解了他们管理的工作流程和具体的需求。
(2)业务流程图
详见附录1
(3)数据流程图
下面是一个设备流程图的底层流程图:
其它的详见附录2
(4)数据字典
数据项:
表1教室信息数据项
数据项名
数据项含义说明
数据类型
长度
取值范围
取值含义
于其他数据项的逻辑关系
数据项之间的联系
Spart
校区
char
10
Rname
教室名称
Position
所在位置
20
Type
教室类型
Room
容量
int
4
Cno
课程号
Cname
课程名称
Ctime
课程学时
Weed
周次
Day
星期
Node
节次
Mno
系号
Mname
系名
cg
班级
Number
人数
表2课程信息数据项
表3职工信息数据项
Pno
职工编号
等于维修工编号
Pname
姓名
等于维修工姓名
Sex
性别
Age
年龄
Jname
职业名称
Addr
住址
40
Tel
联系电话
Week
Ontime
上班时间
Uptime
下班时间
表4损坏信息数据项
Dlevel
损坏程度
Mend
修复难易
维修工编号
维修工姓名
Repair
是否修复
1.1.4数据结构
表5数据结构表
数据结构名
含义说明
组成
Class(T1)
教室信息
校区名,教室名称,所在位置,教室类型,容量
Course(T2)
课程信息
课程号,课程名称,周次,星期,节次,课程学时,教室名称,系号,系名,班级,人数
Worker(D1)
职工信息
职工编号,姓名,职业名称,性别,年龄,住址,联系电话
Duty(D2)
值班
职工编号,姓名,职业名称,星期,上班时间,下班时间
State(D3)
值班情况记录
职工编号,姓名,职业名称,星期,周次
Media(P1)
多媒体设备损坏记录
教室名称,损坏程度,修复难易,维修工编号,维修工姓名,是否修复
Routine(P2)
常规设备损坏记录
教室名称,损坏程度,维修工编号,维修工姓名,是否修复
1.1.5处理逻辑描述
(1)教室查询子系统
输入:
查询条件
输出:
查询结果
处理:
按照条件,在相应的表中,查找相应的数据,然后输出
(1)卫生管理子系统
查询、插入或修改的目标
结果:
输出查询的结果,或者插入成功,或者修改成功
在相应的表中完成相应的操作。
(3)设备管理子系统
插入或修改或查询的条件或目标
输出查询结果或插入成功或修改成功
在相关表中完成相关的操作。
1.2概念设计
1.2.1引言
概念结构的实际是整个数据库设计的关键,这个阶段主要的目标是通过对用户需求进行综合、归纳与抽象,形成一个独立于DBMS的概念模型(E-R图)。
它的主要特点是:
1.能真实、充分地反映现实世界,包括事物与事物之间的联系,能满足用户对数据的处理要求,是对现实世界的一个真实模型;
2.易于理解,因此可以用它和不熟悉计算机的用户交换意见;
3.易于更改,当应用环境和应用要求改变时,容易对概念模型修改和扩充;
4.易于向关系、网状、层次等各种数据模型转换。
1.2.2概念模型设计
(1)设计E-R图
详见附录3
1.2.3实体的属性、联系的属性
主码表示如:
教室名称;
外码表示如:
普通属性如:
教室名称。
教室(校区名,教室名称,所在位置,教室类型,容量);
课程(课程号,教室名称,课程名称,周次,星期,节次,课程学时,系名,班级,人数);
职工(职工编号,姓名,职业名称,性别,年龄,住址,联系电话);
多媒体设备损坏(教室名称,维修工编号,损坏程度,修复难易,维修工姓名,是否修复,备注);
常规设备损坏(教室名称,维修工编号,损坏程度,维修工姓名,是否修复,备注);
值班信息(职工编号,姓名,职业名称,星期,上班时间,下班时间);
值班记录(职工编号,姓名,职业名称,星期,周次);
1.3逻辑设计
1.3.1引言
这个阶段的任务就是把概念结构设计阶段设计好的基本E-R图转换为与DBMS所支持的数据模型相符合的逻辑结构。
在这个阶段里,该系统的目标就是把基本的E-R图转换成关系数据模型。
1.3.2数据组织
(1)将E-R图转换成关系模型:
E-R图转换成关系模型应该遵循以下原则:
1.一个实体型转换为一个关系模式。
2.一个1:
1联系可以转换为一个独立的关系模式,也可以与任意一端对应的关系模式合并。
3.把一个1:
n联系转换为一个独立的关系模式。
4.一个m:
n联系转换为一个关系模式。
5.三个或三个以上实体间的一个多元联系可以转换为一个关系模式。
6.具有相同码的关系模式可合并。
(2)转换的结果:
课程(课程号,教室名称,课程名称,教师编号,周次,星期,节次,课程学时,系名,班级,人数);
该模式没有插入异常,删除异常等操作异常现象,已经达到3NF。
(3)设计用户子模式:
鉴于安全问题,每一个表都应有相应的视图。
建立相关的视图如下:
教室视图:
Class1(校区,教室名称,地点,教室类型,容量);
课程与教室视图:
Course1(校区,教室名称,教室类型,课程名称,周次,星期,节次,容量);
这两个视图包含了允许学生和员工等用户查询的属性,不允许修改,插入和删除。
为职工做视图:
值日视图:
Duty1(职工编号,职工姓名,职业名称,上班时间,下班时间);
清洁工值班记录:
State1(职工编号,职工姓名,职业名称,日期,情况);
员工值班记录:
State2(职工编号,职工姓名,职业名称,日期,情况);
职工视图:
State3(职工编号,职工姓名,职业名称,日期,情况);
常规设备损坏纪录:
Routine1(教室名称,职工编号,职工姓名,描述,是否修复,日期,备注);
多媒体设备损坏:
Media1(教室名称,职工编号,职工姓名,描述,修复难易,是否修复,日期,备注);
职工信息:
Worker1(职工编号,姓名,职业名称,性别,年龄,住址,联系电话);
在这些视图中,值日视图允许各个职工查询,但只允许管理员(主任)进行修改,插入,删除等操作;
清洁工值班记录视图,除维修工外,其他各职工都可查询,员工还可进行修改操作,管理员(主任)可进行各种操作;
员工值班记录只允许员工查询;
常
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 实例 教室 管理 系统 数据库 设计