考勤系统数据库课程设计.docx
《考勤系统数据库课程设计.docx》由会员分享，可在线阅读，更多相关《考勤系统数据库课程设计.docx（28页珍藏版）》请在冰点文库上搜索。
考勤系统数据库课程设计
考勤系统数据库课程设计
第一章系统概述
1.1系统开发背景
90年代中期，由于Internet的迅速普及，使Intranet成为Internet技术在企业管理信息系统中的应用和延伸，形成了集计算机，计算机网络、数据库、分布式计算等于一体的信息技术综合体，它打破了时间和地域的界限，使信息交流变得快捷、准确，为建立现代企业管理信息系统提供了充足的条件。
企业信息管理系统在此基础上延伸、扩展，使之上下、内外全面贯通。
酒店考勤管理系统是在适应市场需求的客观前提下，为了满足中小型公司或事业单位管理自己的职员考勤问题而开发的。
该系统的是终目的是要将各位职员的考勤情况放到网络上，以方便员工及时查证。
1.2项目设计基本原理
随着计算机的普及和计算机科学技术的飞速发展，人们开始越来越多地利用计算机解决实际问题。
员工考勤管理是企业信息管理的重要部分面对大量的人事工资信息，采用人力处理将浪费大量的时间、人力和物力，且数据的准确性低。
一个界面友好，易于操作的员工考勤管理软件进行自动化处理就会显得尤为重要。
在数据库系统中，主要的操作是对数据库进行的，根据对不同数据表的操作来划分模块，虽然这并不一定正确，但根据数据来划分模块确实可以使乘隙模块清晰明了。
当然，前提是数据划分正确，不然会使数据处理更加麻烦。
1.3数据库系统设计及范式分析
数据库设计主要是进行数据库的逻辑设计，即将数据按一定的分类、分组系统和逻辑层次组织起来，是面向用户的。
数据库设计时需要综合企业各个部门的存档数据和数据需求，分析各个数据之间的关系，按照DBMS提供的功能和描述工具，设计出规模适当、正确反映数据关系、数据冗余少、存取效率高、能满足多种查询要求的数据模型。
数据库设计的步骤是;
1.数据库结构定义：
目前的数据库管理系统（DBMS）有的是支持联机事务处理CLTP（负责对事务数据进行采集、处理、存储）的操作型DBMS，有的可支持数据仓库、有的联机分析处理CLAP（指为支持决策的制度对数据的一种加工操作）功能的大型DBMS，有的数据库是关系型的，有的可支持面向对象数据库。
针对选择的DBMS，进行数据库结构定义。
2.数据表定义：
数据表定义指定义数据库中数据表的结构，数据表的逻辑结构包括：
属性名称、类型、表示形式、缺省值、效验规则、是否关键字、可否为空等。
关系型数据库要尽量按关系规范化要求进行数据库设计，但为使效率高，规范化程序应根据应用环境和条件来决定。
数据表设计不仅要满足数据存储的要求，还要增加一些如反映有关信息、操作责任、中间数据的字段或临时数据表。
3.存储设备和存储空间组织：
确定数据的存放地点、存储路径、存储设备等，备份方案，对多版本如何保证一致性和数据的完整性。
4.数据使用权限设置：
针对用户的不同使用要求，确定数据的用户使用权限，确保数据安全。
5.数据字典设计：
用数据字典描述数据库的设计，便于维护和修改。
第二章系统需求分析
2.1可行性研究
2.1.1技术可行性
1.系统管理人员可以根据该系统查询员工的相关信息，并且可以通过员工信息管理对员工信息进行添加、删除和修改；
2.系统管理人员可以通过该应用程序对员工的工作时间进行安排；
3.系统管理人员可以通过该系统检查员工的工作情况，了解员工出差和加班等情况并以此对员工的工资发放情况做安排；
4.员工可以通过该系统查询自己的出勤记录、出差记录、加班记录及请假记录，并通过对自己工作情况的查训核算自己的工资发放是否正确；
5.员工可以通过该系统查询工作时间，了解自己的工作日程；
6.内部功能需要通过SQL语言对数据库进行插入、删除、修改和查询等操作。
2.1.2经济可行性
经济可行性主要依据是成本/效益分析，该系统的目标是以最低的成本，在最短的期限内开发出考勤管理系统。
系统能减少很多不必要的资源，不用象以前那样用冗余的纸张式的管理。
我国中小企业信息化水平一直处在比较初级的阶段，有关统计表明，真正具备计算机信息化比较高应用水平的企业在全国1000多万中小企业中所占的比例还不足10%。
然而，随着我国市场经济的不断成熟，企业的竞争也在不断的加剧，同时企业组织管理观念的变革以及业务流程标准化也在不断完善，中小企业信息化建设的热情近几年来有了显著的提高。
因此开发一个高质量的考勤工资系统进行企业管理尤为重要。
2.1.3操作可行性
用户仅需具有基本的电脑操作能力即可。
2.1.4社会因素可行性
从法律因素和安全用正版和免费角度考虑，所有技术参考资料都经授权，所有软件都选。
2.1.5可行性研究结论
依据以上因素，本考勤管理系统开发项目不仅方便快捷、高效，而且社会效益比较好从而使本系统开发者相信该系统开发出来之后将取得成功。
综上所述，此项目在技术、经济、操作和社会效益上是完全可行的。
2.2需求分析
2.2.1系统目的
系统采用模块化程序设计方法，既便于系统功能的各种组合和修改，又便于未参与开发的技术维护人员补充、维护。
员工考勤管理系统能够和考勤机相连接，从而完成自动、高效、科学的考勤信息输入。
该系统具备数据库维护功能，及时根据用户需求进行数据的添加、删除、修改、备份等操作。
考虑到适应性，构建一个考勤系统，所有的员工都通过打卡来进行登录和注销，同时考勤系统需要用户密码才能进入。
在这里假定打卡信息已经转化成数据信息，每次打卡将激活的一个模块。
这些模块可以用手工输入，以备不时之需。
2.2.2系统功能及用户需求分析
根据分析，该考勤系统必须具备如下几个功能：
（1）能够记录各种基本资料和考勤资料；
（2）系统使用者每天每个人都必须进行考勤，能够记录各种考勤信息；
（3）系统使用者能够查询以往考勤信息，以防止不公正情况出现；
（4）系统使用者能够对考勤结果信息进行处理；
（5）系统使用者能够由灵活处理；
（6）保障数据库安全，优化数据库，，可以在程序中实现数据库备份和恢复。
（7）界面的友好性，操作的图形化。
（8）对员工的迟到情况进行统计也可以查询并由系统使用者对其进行修改删除
现在不论哪个企业，都要进行考勤，一些企业在考勤管理方面用了大量的人力和财力，不说准确度和可信度如何，其效率很低，而且容易出错，不利于管理。
所以人工考勤已经很难再满足企业规范化管理的要求，随着数据库技术的发展和企业信息化建设的进行，使用计算机管理考勤成为一种主流趋势，它不仅为企业减少了人力财力的付出，而且也大大减轻了考勤工作人员的工作量。
2.3数据描述
2.3.1数据流图
数据库记录了系统中处理的所有数据和某些操作。
在实际应用中，一个实用的数据库应用系统可能要处理数据量巨大，并且关系复杂的数据。
现实生活中处理的数据，必须经过抽象，然后再将它们反映到数据表的字段中。
数据表中的字段类型和大小要符合使用习惯。
设计的业务流程图如下所示：
员工
正常上班
加班情况
请假
出差
带职人员
命令
部门
部门
申请批准
图2.1考勤系统业务流程图
设计的数据流程图如下所示：
上班表
员工
正常上班
加班
请假
出差
加班表
请假表
出差表
部门其它人员
统计
查询
图2.2考勤系统的数据流程图
2.3.2数据字典
（1）数据项描述
数据项
别名
类型
长度
取值范围
取值含义
含义说明
员工编号
yno
bigint
0000000至
9999999
前三位为部门编号，后四位为顺序编号
唯一标识每个学生
员工性别
ysex
char
2
“男”或“女”
规范化
性别是区分员工的一个大致范围
部门编号
bno
int
000
为顺序编号
唯一标识每个部门
出勤编号
workno
bigint
00000000000000000000
至
2***1231009999999
前八位为当天日期，中间两位设为00，后七位为员工编号
唯一标识每次出勤
加班编号
overtimeno
bigint
00000000110000000000
至
2***1231119999999
前八位为当天日期，中间两位设为11，后七位为员工编号
唯一标识每次加班
出差编号
travelno
bigint
00000000220000000000
至
2***123122999999
前八位为当天日期，中间两位设为22，后七位为员工编号
唯一标识每次出差
请假编号
leaveno
bigint
00000000220000000000
至
2***123133999999
前八位为当天日期，中间两位设为33，后七位为员工编号
唯一标识每次请假
月度考勤编号
mattendno
bigint
00000000220000000000
至
2***123144999999
前八位为当天日期，中间两位设为44，后七位为员工编号
唯一标识每个人的月度考勤信息
工资编号
workno
bigint
00000000000
至
99999999999
前七位为员工编号，后四位为顺序编号
唯一标识每个人的工资情况
表2-1
（2）数据结构描述
数据结构
说明
组成
员工信息
是考勤管理子系统的主体数据结构，定义了一个员工的有关信息
员工编号，员工姓名，员工性别，出生日期，职务，部门编号
部门信息
是考勤管理子系统的主体数据结构，定义了一个部门的有关信息
部门编号，部门名称，部门经理职工号
工资表
是考勤管理子系统的主体数据结构，定义了工资的详细信息
工资编号，基本工资，奖金，实际工资
表2-2
（3）数据流描述
数据流
说明
数据流来源
数据流去向
组成
平均流量
高峰期流量
核对密码
根据不同人员相应的权限
登录时的信息
考勤管理系统
管理员的帐号密码与普通员工的帐号密码
每天传输1000次
1500次
完整的考勤数据
员工的考勤数据
月度考勤统计
工资评估
月度考勤编号、员工编号、日期、累计正常工作时间、累计请假、累计出差、累计加班、迟到次数、早退次数、旷工次数
每月传输1500次
1500次
工资数据
员工相应的工资
工资评估的情况
工资表
工资编号、基本工资、奖金、实际工资
每月传输1500次
1500次
表2-3
（4）数据存储
数据存储
说明
流入数据流
流出数据流
组成
数据量
存取方式
出差记录
记录员工出差的基本情况
录入出差情况，调出出差记录
统计出差记录
出差编号、出差起始时间、出差结束时间、出差描述、补助资金
每月200次
更新，顺序检索
工资表
记录员工工资的情况
工资的评估
工资编号、基本工资、奖金、实际工资
每月1500次
更新
月度考勤统计
记录员工每月的考勤情况
一个月的信息统计
统计好的考勤数据
月度考勤编号、员工编号、日期、累计正常工作时间、累计请假、累计出差、累计加班、迟到次数、早退次数、旷工次数
每月1500次
更新，顺序检索
表2-4
（5）处理过程
处理过程
说明
输入数据流
输出数据流
处理
登录
用正确的账号登录
账号和密码
核对密码
要求密码正确，并且根据账户名来区分管理员和普通员工
录入数据
将准备的数据依次录入
准备的出差，请假，加班，出勤的数据
录入出差，请假，加班，出勤的情况
要求数据根据其内容分别编入不同的记录中
工资评估
根据相应的评估方法来算基本工资，奖金和实际工资
完整的考勤数据
工资表
基本工资加上加班的奖金，补助金减去请假，旷工扣的钱
表2-5
第三章总体设计
3.1总体设计原理
总体设计的基本目的就是回答“系统应该如何实现？
”这个问题。
因此总体设计又称为概要设计或初步设计。
通过这个阶段的工作将划分出组成系统的物理元素—程序、文件、数据库、人工过程和文档等等，但是每个物理元素仍然处于黑盒子级，这些黑盒子里的具体内容将在以后仔细设计。
总体设计阶段的另一项重要任务是设计软件的结构，也就是要确定系统中每个程序是由哪些模块组成的，以及这些模块相互之间的关系。
总体设计工程通常有两个主意阶段组成：
系统设计，确定系统的具体实现方案；结构设计确实软件结构，也就是要确定系统中每个程序拥有哪些模块组成的，以及这些模块之间的关系。
在详细设计之前进行总体设计可以站在全局的高度上，花较少的成本，从中选出最佳方案和最合理的软件结构，从而用较低的成本开发出高质量的软件系统。
3.2运行环境与系统结构
为了保证系统运行的效率和可靠性，系统服务器端应具有较高的软硬件配置，客户端的要求不是很高。
此应用程序可广泛用于内部的局域网。
3.3系统功能模块与设计
（1）用户管理模块
增加一名系统使用用户，同时设置密码和权限，当此用户要更改密码时，可以在修改密码模块中进行。
必须具有一定权限才能进行此项操作。
而当某些职工离职或者因某中缘故，不能再使用考勤系统，可以将该用户删除。
可以更改拥护权限，使其具有访问某些模块的权限或者剥夺其访问某些模块的权限。
所有系统使用用户都可能在此修改密码，以保障系统安全。
（2）基本资料管理模块
设置的时间有上午上、下班时间，下午上、下班时间，这个模块与上下班时间表相对应，以方便考勤操作。
增加和删除请假类型，修改请假类型内容，并将操作结果存在请假类型表内。
增加和删除外出类型，修改外出类型内容，并将操作结果存在外出类型表内。
增加、删除和修改员工基本资料。
（3）考勤操作管理模块
输入员工每天出勤情况，主要为上班和下班时间，这是考勤的依据资料。
对于迟到早退或者旷工情况，可以在这个模块直接判断。
记录员工请假内容，请假时间，将其保存在数据库中。
处理员工外出情况，说明其内容、原因和外出时间。
（4）考勤资料管理模块
根据统计条件统计在一段时间内的出勤情况，如每个月内迟到人数等，查询所有或部分人在某一时间段中的考勤情况，根据考勤结果，进行相应的处理。
（5）数据库管理模块
把系统数据库导出并存放在某一磁盘目录中，相当于备份。
将存放在磁盘中的数据库导入系统时要覆盖原来的数据库，否则会出错。
3.4系统功能模块图
登录考勤系统
用户资料管理
每日考勤管理
请假考勤管理
出差考勤管理
加班考勤管理
修改删除管理
图3.1功能模块图
第四章详细设计
4.1数据库的概念设计
根据对数据流图和数据字典的分析，确定该应用中的实体、属性和实体之间的联系，并画出系统总体的E-R图。
概念设计可分为三步进行：
首先设计局部E-R模式，然后把各局部E-R模式综合成一个全局模式，最后对全局E-R模式进行优化，得到最终的模式，即概念模式。
4.1.1局部E-R模式设计
实体和属性的定义。
E-R模型的“联系”用于刻画实体之间的关联。
一种完整的方式是对局部结构中任意两个实体类型，依据需求分析的结果，考察局部结构中任意两个实体类型之间是否存在联系。
若有联系，进一步确定是1：
N,M:
N,还是1：
1等，还要考察一个实体类型内部是否存在联系，两个实体类型之间是否存在联系，多个实体类型之间是否存在联系等等。
1.局部E-R模式的合并
合并的原则是：
首先进行两两合并，先合并那些现实世界中有联系的局部结构，合并从公共实体类型开始，最后再加入独立的局部结构。
2.消除冲突
冲突分为三类：
属性冲突，结构冲突，命名冲突。
设计全局E-R模式的目的不在于把若干局部E-R模式形式上合并为一个E-R模式，而在于消除冲突，使之成为能够被所有用户共同理解和接受的同一概念模型。
3.全局E-R模式的优化
在得到全局E-R模式后，为了提高数据库系统的效率，还应进一步依据处理需求对E-R模式进行优化，一个好的全局E-R模式，除能准确、全面的反映用户功能需求外，还应满足下列条件：
实体类型的个数要尽可能的少，实体类型所含属性个数尽可能少，实体类型间联系无冗余。
设计的E-R图如下所示
员工
正常上班
加班
请假
出差
考勤表
加班表
请假表
出差表
姓名
密码
进入公司时间
上班时间
下班时间
加班时间
类型
性别
请假时间
请假类型
出差时间
出差类型
上班时间
管理员
记录日期
密码
姓名
上班日期
图4.1考勤系统的E-R流程图
4.1.2E-R图模型转成关系模型
员工（员工编号、员工姓名、员工性别、出生日期、职务、部门编号）；
部门（部门编号、部门名称、部门经理职工号）；
出勤记录（出勤编号、日期、上班时间、下班时间）；
请假记录（请假编号、请假起始时间、请假结束时间、请假原因、扣除奖金）；
加班记录（加班编号、加班时间长度、日期、加班费）；
出差记录（出差编号、出差起始时间、出差结束时间、出差描述、补助资金）；
月度考勤统计（月度考勤编号、员工编号、日期、累计正常工作时间、累计请假、累计出差、累计加班、迟到次数、早退次数、旷工次数）；
工资（工资编号、基本工资、奖金、实际工资）；
4.2数据库实现
图4.2数据库中建立的表
1.数据表的设计
（1）用户表的创建
用户表的创建脚本如下：
createtable用户（
用户名char（30）notnull,
员工号char（30）null,
权限名char（30）null,
用户密码intnotnull,
权限号intnotnull,
constraintPK_用户primarykey（用户名）
）
go
用户表的字段格式说明如下所示：
图4.3用户表的属性
图4.4用户表
（2）权限表的创建
权限表是用来确定某一权限类型所能访问的系统模块。
权限表的创建脚本如下所示：
createtable权限表（
权限名char（30）notnull,
用户管理char
（2）notnull,
基本资料更改char
（2）notnull,
请假管理char
（2）notnull,
外出管理char
（2）notnull,
加班管理char
（2）notnull,
修改考勤资料char
（2）notnull,
数据库操作char
（2）notnull,
日志删除char
（2）notnull,
constraintPK_权限表primarykey（权限名）
）
go
权限表的字段格式说明如下所示：
图4.5权限表的属性
图4.6权限表
（3）出勤资料表的创建
出勤资料表用来记录员工每天实际上下班时间。
这张表保存的数据是考勤的依据。
出勤资料表的创建脚本如下所示：
createtable出勤资料表（
记录号intnotnull,
员工基_员工号char（30）null,
员工号char（40）notnull,
上午上班时间datetimenotnull,
上午下班时间datetimenotnull,
下午上班时间datetimenotnull,
下午下班时间datetimenotnull,
记录日期datetimenotnull,
constraintPK_出勤资料表primarykey（记录号）
）
go
出勤资料表的字段格式说明如下所示：
图4.7出勤资料表的属性
图4.8出勤资料表
（4）员工基本资料表
为了判断某员工是否已经考勤，在员工表中的另一个字段，字段名为“考勤”，每天考勤前，将此字段值都设为0，每考勤一个员工，则将其字段值该为1，以后操作时根据其字段判断其是否已经考勤。
其创建脚本为：
createtable员工基本资料表（
员工号char（30）notnull,
员工名char（30）notnull,
性别tinyintnotnull,
年龄intnotnull,
入公司时间datetimenotnull,
住址char（50）notnull,
联系电话char（20）null,
手机char（20）null,
电子邮箱char（30）null,
考勤tinyintnotnull,
constraintPK_员工基本资料表primarykey（员工号）
）
go
员工基本资料表的年格式如下所示：
图4.9员工基本资料表的属性
图4.10员工基本资料表
（5）加班表的创建
加班表用来保存员工的加班信息。
createtable加班表（
记录号intnotnull,
员工基_员工号char（30）null,
员工号char（20）notnull,
员工名char（30）notnull,
加班类型char（30）notnull,
起始时间datetimenotnull,
结束时间datetimenotnull,
constraintPK_加班表primarykey（记录号）
）
go
加班表的字段格式说明如下所示：
图4.11加班表的属性
图4.12加班表
（6）请假表的创建
请假表是用来保存员工的请假记录。
其创建脚本为：
createtable请假表（
记录号intnotnull,
类型名char（30）null,
员工基_员工号char（30）null,
员工号char（20）notnull,
员工名char（20）notnull,
请假类型char（30）notnull,
起始时间datetimenotnull,
结束时间datetimenotnull,
constraintPK_请假表primarykey（记录号）
）
go
请假表的字段格式如下所示：
图4.13请假表的属性
图4.14请假表
（7）外出表的创建
外出表是用来保存员工的外出记录，数据格式。
外出表的创建脚本如下：
createtable外出表（
记录号intnotnull,
类型名char（30）null,
员工基_员工号char（30）null,
员工号char（20）notnull,
员工名char（30）notnull,
外出类型char（30）notnull,
起始时间datetimenotnull,
结束时间datetimenotnull,
constraintPK_外出表primarykey（记录号）
）
Go
外出表的字段格式如下所示：
图4.15外出表的属性
图4.16外出表
（8）日志表的创建。
每一个实用的数据库应用系统，总是少不了日志管理。
日志是用来记录系统的使用情况，以便当系统遭到非法使用时，能够从日志表中找到使用记录，以便进行处理。
日志表的创建脚本为：
createtable日志表（
记录号binary（8）notnull,
用户名char（30）notnull,
操作char（127）
升级会员 