高校人事管理系统数据库设计Word文档下载推荐.docx
- 文档编号:22708694
- 上传时间:2023-02-05
- 格式:DOCX
- 页数:45
- 大小:853.25KB
高校人事管理系统数据库设计Word文档下载推荐.docx
《高校人事管理系统数据库设计Word文档下载推荐.docx》由会员分享,可在线阅读,更多相关《高校人事管理系统数据库设计Word文档下载推荐.docx(45页珍藏版)》请在冰豆网上搜索。
1.管理员端:
主要能实现对学生教师的增删改查以及统计。
2.教师端:
能浏览自己的工资和其他个人信息,还可以进行修改。
3.部门主任端:
可以对教师信息进行修改统计。
需求分析阶段的目标与任务
处理对象
1.管理员信息:
用户名,密码,公告
2.教师信息:
教师姓名、教师性别、教师身份证号、密码、教师学历、教师职务、职称、家庭住址、教师密码、部门编号、出生年月、所在部门、用户身份、工资
3.教师工资信息:
教工编号、职称、职务、加班工资、考勤工资、基本工资、总工资、时间、教师姓名
首先从需求分析阶段中,确定了几项基本的处理对象,有可能这些处理对象不完全,需要在后续的各个阶段中不断修改和完善。
处理功能及要求
1.管理员端的处理功能
1)用户管理
1、添加用户
2、修改密码
3、删除用户
2)部门管理
1、查询部门信息
2、修改部门公告
3、增加部门类型
4、删除部门
5、统计部门信息
3)职工管理
1、修改通知信息
2、职工测评
3、修改查询教师信息
2.部门主任功能
1)查看系统公告
2)查看本部门成员
3)修改个人资料
1、修改职工信息
2、修改自己信息
4)查询员工考勤管理
1、修改员工考勤
2、查询员工考勤
3、删除员工考勤
5)管理员工工资
1、合计员工工资
2、查询员工工资
6)员工奖惩管理
3职工功能
1)查看通知
2)申请病假
3)修改个人信息
4)查看个人工资
4.能够提供一定的安全机制,提供数据信息授权访问,防止随意删改、查询。
5.系统界面要友好,系统的健壮性要强,后台要稳定。
安全性和完整性要求
1)安全性要求
系统的安全性也是一个需要重点考虑的问题。
人事管理系统中保存了很多敏感的信息,如教师的基本情况等。
非授权用户不可查询、更改或删除。
本系统所采用的方法是首先在进人系统时检查用户名和口令,因此非系统用户很难进入系统。
即使能够进入系统,所有的涉及数据增加、更改和删除的地方都需要进行权限确认以保证操作合法进行。
当然,数据库本身是加了密的,非法用户很难打开数据库而直接进行修改。
而关于用户名与口令的信息则经过一定的算法加密后保存在数据库中。
系统的安全性得到了较好的保证。
2)完整性要求
系统完整性要求系统中数据的正确性以及相容性。
可通过建立主、外键,确定了每个表中的主码,主码唯一,以及一个表与其他表相关联的外码;
对于一些等级属性和一些确定取值范围的属性使用check约束;
还有一些标志变量,取值范围为0或1代表的意义不同,可以通过使用触发器来实现;
以及要做到视图级联更新;
有的值不能为空,若为空则没有意义整个元组不完整,则需要表示Notnull通过定义实体完整性、参照完整性、用户定义完整性使其满足完整性要求。
利用触发器可以对给出等级的限制,将超出的部分变为合法的范围内数据;
利用触发器进行级联,修改一表中的项,将其他关联表的记录也同时删除。
需求分析阶段成果
体会与收获
系统需求分析主要是通过对已有的人事管理系统功能进行参考,了解了山大等高校人事管理平台的的管理规则和运行机制,并通过上网搜索有关高校人事管理系统的知识。
从许多人事管理的案例以及山大的人事管理中找寻出一些基本的功能,在这些功能的基础上在绘制系统业务流程图,遇到了很多的问题,有的问题没法合理的表示出来,需要在过程中才会反应出来,仍需要继续改进,通过老师的帮助与指导,和组员之间一遍一遍的分析和完善,才逐步把业务各个过程了解清楚,最终顺利完成了需求分析阶段的任务。
高校人事管理系统系统功能模块图
1.管理员功能模块图:
2
.部门主任功能模块图:
2.教师功能模块图:
高校信息管理系统数据流图
1.系统数据流图
2管理员系统流图:
管理员子系统用户管理流图:
管理员子系统部门管理流图:
管理员子系统职工管理:
3部门主任系统流图:
部门主任子系统工资流图:
部门主任子系统个人信息流图:
4职工系统数据流图:
高校人事管路系统数据字典:
(a)数据项:
系统涉及的数据项有39项
表数据项列表
数据项编号
数据项名
数据项含义
所属基本表
存储结构
别名
DL-1
用户名
登录所需
用户权限信息
char(10)
DL-2
密码
char(12)
DL-3
权限
DL-4
公告信息
DL-5
部门编号
部门信息
Char(16)
DL-6
部门名称
Char(8)
DL-7
部门主任名
DL-8
缺课次数
考勤信息
char(20)
DL-9
请假原因
Char(20)
DL-10
是否批准
DL-11
请假日期
Char(14)
DL-12
请假天数
Char(40)
DL-13
奖励
奖惩信息
float
DL-14
处罚原因
DL-15
罚金
DL-16
基本工资
工资信息
DL-17
考勤所扣工资
DL-18
奖金
DL-19
处罚金额
DL-20
税率
Char(12)
DL-21
职工姓名
职工信息
DL-22
职工性别
Char
(2)
DL-23
职工年龄
DL-24
职工职称
等级
DL-25
职工家庭住址
DL-26
职工相片
image
DL-27
职工毕业学校
Char(30)
DL-28
职工教龄
Char(10)
DL-29
职工手机号
Char(11)
(b)数据结构:
数据结构编号
数据结构名
数据结构含义
组成
DS-1
管理员信息
存储管理员基本信息
用户名,密码,邮箱,权限
DS-2
部门主任信息
存储部门主任基本信息
部门主任姓名,部门办公室电话,部门主任联系电话,部门主任性别,部门主任年龄
DS-3
教师职工信息
存储教师职工基本信息
姓名、性别、年龄、职称、职工家庭住址、职工相片、毕业学校、教龄、手机号
DS-4
存储用户权限信息
用户名、密码、权限
DS-5
存储用户工资信息
基本工资、考勤所扣工资、奖金、处罚金、税率
DS-6
存储员工奖惩信息
奖励、处罚
DS-7
存储员工考勤信息
请假天数、请假日期、是否批准、缺课次数、请假原因
DS-8
存储部门信息
部门编号、部门主任名、部门名称
DS-9
存储公告
(c)逻辑描述
管理员端处理逻辑描述
处理编号
处理功能
处理过程
PR-1
判断管理员用户管理所涉及到的功能模块,进行相应的处理
权限信息模块
将权限表传入管理员模块,进行适应的处理之后,再将相应的的数据传入相应的模块
PR-2
判断管理员管理部门涉及到的功能模块
部门主任信息模块、公告信息模块
处理相应的数据,然后将处理结果传入相应模块
PR-3
判断管理员管理员工所涉及到的功能模块
职工信息模块、公告信息模块、职工测评模块处理相应的数据,然后将处理结果传入相应模块
部门主任端处理逻辑描述
判断部门主任查看公告和员工信息所涉及的功能模块然后进行管理操作
公告信息模块,员工信息模块,将公告信息传入公告信息模块,查询员工信息的过程中,将所需要的员工信息一次导入
判断部门主任工资修改涉及的功能模块
工资信息模块,考勤信息模块,奖惩信息模块
确定工资管理所要涉及的功能模块,将消息传入相应的模块中,然后进行相应的操作
判断部门主任管理员工考勤和奖惩涉及到的功能模块
考勤信息模块,奖惩信息模块
确定部门主任所要管理的模块并传入相应的模块
教师职工端处理逻辑描述
判断教职工查看个人信息所涉及的功能模块然后进行管理操作
职工信息模块,奖惩信息模块,考勤信息模块先确定职工查询所要涉及的功能模块,将所要的字段信息传入相应信息模块或进行编辑信息
判断教职工查看公告和工资所要涉及的功能模块
公告信息模块,工资信息模块,
确定员工所要查询信息所要涉及的功能模块,将消息传入相应的模块中,然后进行相应的操作
判断教职工病假申请涉及到的功能模块
考勤信息模块
将考勤相关信息传入考勤信息模块
3.概念设计阶段
系统开发的总体目标是实现高校人事管理系统系统化,实现教师学生的基本需求,基本做到高效、智能化管理。
主要任务是实现增删改查功能,对教师信息和其他信息进行管理和操作。
概念设计阶段主要是将需求分析阶段得到的用户需求抽象为信息结构(概念模型)的过程,它是整个数据库设计的关键。
任务与目标
(1)选择中层数据流为切入点,通常选择实际系统中的子系统;
(2)设计分E-R图,即各子模块的E-R图;
(3)生成初步E-R图,通过合并方法,做到各子系统实体、属性、联系统一;
(4)生成全局E-R图,通过消除冲突等方面。
在本系统中,从三个不同的功能端下手。
分析各子系统的数据流图和数据字典,知道整个系统功能围绕“部门主任”、“教师”和“管理员”的处理。
根据实体与属性间的两条准则:
作为“属性”,不能再具有需要描述的性质。
“属性”不能与其他实体具有联系。
从分层的数据流图中将系统分为三个子系统:
管理员子系统,职工子系统,部门主任子系统。
某一层的数据流图中,每个局部应用都对应了一组数据流图,局部应用涉及的数据都已经收集在数据字典中了。
现在将这些数据从数据字典中抽取出来,根据数据流图,确定实体之间的联系及其类型。
根据管理员数据流图确定了管理端分E-R图;
根据部门主任子系统数据流图确定了部门主任E-R图;
根据职工子系统数据流图确定了职工E-R图。
对于三个分E-R图,通过消除属性冲突,例如将所有的编号都统一为数值型,将所有的用户名和密码统一为字符型,将联系方式统一为字符型;
消除命名冲突,将同名异义的取不同的名称,将异名同义的改为统一名称;
消除结构冲突,将实体的属性统一,对在不同E-R图中相同实体的不同联系进行调整,得到了系统的E-R图。
阶段结果
(1)根据不同的对象,分别画出各分E-R图:
(a)教师E-R图
(b)部门主任E-R图
(c)管理员E-R图
(d)E-R图合并
(3)各E-R图各实体主要属性如下所示:
1.部门主任:
部门名称,主任姓名,主任家庭住址,主任电话,主任办公室电话,主任年龄,主任性别
2.教师职工:
职工姓名,职工编号,职工性别,职工手机号,职工职称,职工教龄,职工住址,职工所在部门,职工工资
3.工资:
基本工资,工资税率,奖金,罚金,总工资
4.管理员:
管理员帐号,密码
4.逻辑设计阶段
逻辑设计的任务和目标
以上的概念设计阶段是独立于任何一种数据模型的,但是逻辑设计阶段就与选用的DBMS产品发生关系了,系统逻辑设计的任务就是将概念设计阶段设计好的基本E-R图转换为选用DBMS产品所支持的数据模型相符合的逻辑结构。
具体内容包括数据组织(将E-R图转换成关系模型、模型优化、数据库模式定义、用户子模式设计)、数据处理(画出系统功能模块图)两大任务。
数据组织
将E-R图转换为关系模型
1、职工与病假(1:
n),公告是(n:
m)的关系,若将这些放在同一个表的话会造成数据冗余,浪费存储空间,所以可以将职工单独列为一个表,病假,公告各做一个表,通过职工号相联系
2、管理员和职工,部门主任,职工评价,公告是(1:
n)的关系,同上可以将管理员单独成表,部门主任和职工评价单独成表,管理员与部门主任通过部门编号联系,管理员和职工可以通过职工号相联系,管理员与公告可以通过公告类型相联系。
3、工资是建立在部门主任和职工之间的联系(n:
m),一个职工和他所对应的部门主任可以确定一个工资信息,所以可以将职工编号作为码,并将工资信息做一表。
4、职工与奖惩之间的联系为(1:
n),可以通过职工编号与奖惩信息表相关联,并将职工编号作为码。
5、职工,部门主任,管理员与权限之间的联系(n:
1)的关系,所以可以建立一个权限表,通过部门编号,职工编号与之联系
综上所述得到如下关系模型:
职工信息(职工姓名,职工编号,职工性别,职工手机号,职工职称,职工教龄,职工住址,职工所在部门,职工工资)
公告信息(公告编号,公告类型,公告内容,公告时间,职工编号)
病假信息(病假编号,请假原因,请假时间,请假多久,职工编号)
奖惩信息(奖惩编号,奖励原因,奖励额度,惩罚原因,惩罚额度,职工编号)
部门主任信息(部门编号,部门名称,主任姓名,主任家庭住址,主任电话,主任办公室电话)
工资信息(工资编号,基本工资,工资税率,奖金,罚金,总工资,职工编号)
权限信息(编号,权限,密码,姓名)
模型优化
根据以上得到的关系模式进行优化:
职工信息:
职工编号职工姓名,职工编号职工性别,职工编号职工手机号,职工编号职工职称,职工编号职工教龄,职工编号职工住址,职工编号职工所在部门,职工编号职工工资。
该关系满足1NF,而且其中除了码职工编号外,其他非主属性都完全依赖于主属性,因为职工编号是码,故也满足BCNF所以已优化。
公告信息:
公告编号公告类型,公告编号公告内容,公告编号公告时间
满足BCFN,故不需要优化。
病假信息:
病假编号请假原因,病假编号请假时间,病假编号请假多久,病假编号职工编号。
满足BCFN,不需优化。
奖惩信息:
奖惩编号奖惩原因,奖惩编号奖励额度,奖惩编号惩罚原因,奖惩编号惩罚额度,奖惩编号职工编号。
满足BCNF,故不需优化。
部门主任信息:
部门编号主任姓名,部门编号主任住址,部门编号主任手机号,部门编号主任办公室电话,部门名称部门编号,部门名称主任姓名,部门名称主任电话,部门名称主任家庭住址。
该关系模式满足2NF,在部门名称存在传递依赖,若把部门编号与部门名称建立一个表,将会满足BCNF,但使用起来比较繁琐,效率降低,一般只用部门名称去得到其他信息而不需要部门编号,所以在这里分表也没有必要。
工资信息:
工资编号基本工资,工资编号奖金,工资编号罚金,工资编号总工资,工资编号职工编号,满足BCNF,已经优化。
权限信息:
编号权限,编号密码,满足BCNF,无需优化。
数据库模式定义
表职工信息表
列名
数据类型
可否为空
说明
职工编号
char
notnull
主码
性别
手机
职称
职工住址
职工工资
总工资
表公告信息表
公告编号
公告类型
职工公告,主任公告
公告内容
内容
公告时间
date
发布时间
表病假信息表
病假编号
Char
Notnull
请假说明
请假时间
请假多久
int
请假多长时间
表奖惩信息表
奖惩编号
Notnull
奖励原因
受奖励说明
奖励额度
奖励等级,奖金等所获奖励
惩罚原因
惩罚说明
惩罚额度
处分程度
表部门主任信息表
主任姓名
主任家庭住址
主任电话
主任办公室电话
办公室电话
表工资信息表
工资编号
不同职工基本工资不同
工资税率
因某些奖励获节日所获得奖金
因某些处罚所扣资金
时间
datetime
每月实获工资
表权限信息表
编号
职工编号和部门编号
不同用户权限不同
登陆密码
姓名
登录账号
用户子模式定义
表用户子模式定义
用户子模式(View)
作用(共性:
提供数据保密和安全保护机制)
V-1
TeacherView
便于查询和修改教师职工的基本信息
V-2
GongziView
便于查询当月职工工资详细
V-3
JisuanView
便于职工工资计算
表教师职工信息视图
职工的唯一标识
职工的名字
职工地址
职工的家庭住址
职工联系方式
职工月工资
表工资信息视图
每个职工的标识
职工的基本工资
当月所受奖励
处罚
当月处罚所扣
当月所领工资
表工资计算信息视图
职工的标识
奖励金额
考勤里请假时间
notn
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 高校 人事管理系统 数据库 设计