数据库原理与应用课程设计报告-工资管理系统

简介: 数据库原理与应用课程设计报告-工资管理系统

1.概述

随着经济的发展,企业正向着大型化、规模化发展,而对于大中型企业,员工、职称等跟工资管理有关的信息随之急剧增加。在这种情况下单靠人工来处理员工的工资不但显得力不从心,而且极容易出错。如何设计一个小型企业工资的,由计算机代替人工执行一系列诸如增加新员工,删除旧员工,工资查询,统计等操作。这样就使办公人员可以轻松快捷地完成工资管理的任务。

对于企、事业单位的工资发放来说,不需要太大型的。只需要一个操作方便,功能实用,能同时满足财务部门、单位其他相关部门及代发单位三方对数据的管理及需求的系统。

实现工资的集中管理。可供财务人员对本单位的人员以及工资进行增加、删除、修改、查询,对工资发放中的应发工资合计等项目由系统自动进行计算;同时系统还可对员工及工资管理情况进行多角度查询。

基于以上原因,企业工资管理系统使用电脑安全保存、快速计算、全面统计,实现工资管理的系统化、规范化、自动化。企业工资管理系统是典型的信息管理系统(MIS),后台数据库采用MySQL数据库、操作简单、易于使用的优点。

2.需求分析

2.1需求描述

工资管理系统系是为了更好的实现工资各种信息的管理以及各种信息的安全性管理。本系统主要对查看员工的各种工资信息需求所设计的,可以很好的管理数据。本系统的主要功能由以下几个部分组成:

经过调研及分析,工资管理信息系统主要完成以下功能:

(1)员工基本信息模块:员工的基本信息。

(2)工资信息模块:员工每个月度的基本工资、岗位工资、水电费、津贴工资、扣除薪酬、实发金额。

(3)部门信息模块:公司各部门编号、名称、负责人、人数。

(4)考勤模块:记录员工迟到、缺席次数。

(5)津贴模块:记录员工加班情况派发津贴。

(6)员工信息管理模块:管理员对所需要的资料的查询即对员工基本信息的增加、删除、修改、查询操作。

(7)员工工资管理模块:管理员对所需要的资料的查询即对员工工资信息的增加、删除、修改、查询操作。

2.2数据流图

顶层数据流图

2.3数据字典

2.3.1 数据项的描述

1、数据项名:员工编号

别名:w_number

取值范围:0000-9999

含义说明:每位员工的编号

类型:char

长度:4

2、数据项名:员工姓名

别名:w_name

取值范围:1—4

含义说明:每位员工的姓名

类型:varchar

长度:8

3、数据项名:员工性别

别名:sex

取值范围:“男”或“女”

含义说明:每位员工的性别

类型:char

长度:2

4、数据项名:基本工资

别名:basic_wage

取值范围:整数

含义说明:每位员工的基本工资

类型:int

5、数据项名:出生年月

别名:birthday

含义说明:每位员工的出生日期

类型:datetime

2.3.2 数据结构描述

1、名称:员工(Employee)

含义说明:员工信息

组成结构:员工编号+姓名+性别+出生年月+所属部门+文化程度+职称

2、名称:工资(Salary)

含义说明:工资信息

组成结构:员工编号+基本工资+岗位工资+水电费+津贴工资+扣除工资+实

发工资

2.3.3 数据流的描述

1、数据流名称:员工信息添加

简述:新员工信息录入

数据流来源:公司管理者

数据流去向:员工信息

数据流组成:员工编号+姓名+性别+出生年月+所属部门+文化程度+职称

2.3.4 数据流的描述

1、存储名称:员工记录存储

说明:记录着所有员工的所有基本信息

输入:员工基本信息

输出:员工所有信息

数据结构:员工编号+姓名+性别+出生年月+所属部门+文化程度+职称

2.3.5 处理过程的定义

1、处理过程名:员工信息处理

说明:处理员工的基本信息

输入数据流:终端

输出数据流:员工信息入库

3.概念结构设计

3.1概念设计

3.1.1 实体分析描述

从用户角度来说,数据库的需求主要体现在对数据库表的增删改查。因此,数据库结构需同时满足两个要素:输入、输出。在进行数据设计时,首先需收集数据,然后分析数据结构,最后处理数据。根据本系统的需求,设计以下主要的数据项和数据结构:

(1)员工信息实体:员工编号、姓名、性别、所属部门、职称、文化程度、出生年月。

(2)部门信息实体:部门编号、部门名称、部门负责人、部门人数。

(3)工资信息实体:员工编号、基本工资、岗位工资、水电费、津贴工资、扣除工资、实发金额。

(4)考勤信息实体:员工编号、姓名、性别、迟到次数、缺席次数。

(5)津贴信息实体:员工编号、姓名、性别、加班天数、津贴情况、加班类型、加班时间。

3.1.2 实体实体图

员工信息实体如图3.1所示。

用户信息实体图设计

部门信息实体如图3.2所示。

部门信息实体图设计

工资信息实体如图3.3所示。

工资信息实体图设计

考勤信息实体如图3.4所示。

考勤信息实体图设计

津贴信息实体如图3.5所示。

津贴信息实体图设计

3.1.3 E-R图

工资管理系统局部E-R图如图3.6所示。

工资管理系统局部E-R图设计

工资管理系统局部E-R图如图3.7所示。

工资管理系统局部E-R图设计

工资管理系统局部E-R图如图3.8所示。

工资管理系统局部E-R图设计

工资管理系统局部E-R图如图3.9所示。

工资管理系统局部E-R图设计

工资管理系统总E-R图如图3.10所示。

工资管理系统总E-R图设计

4.1逻辑结构设计

4.1关系模式

关系模式:员工信息(员工编号、姓名、性别、出生年月、所属部门、

文化程度、职称)

模式判定:员工信息∈2NF,且每个非主属性都不传递函数依赖于员工信

息的主关系键,所以员工信息∈3NF

关系模式:部门信息(部门编号、部门名称、部门负责人、部门人数)

模式判定:部门信息∈2NF,且每个非主属性都不传递函数依赖于部门信

息的主关系键,所以部门信息∈3NF

关系模式:工资信息(员工编号、基本工资、岗位工资、水电费、津贴

工资、扣除工资、实发金额)

模式判定:工资信息∈2NF,且每个非主属性都不传递函数依赖于工资信

息的主关系键,所以工资信息∈3NF

关系模式:考勤信息(员工编号、姓名、性别、迟到次数、缺勤次数)

模式判定:考勤信息∈2NF,且每个非主属性都不传递函数依赖于考勤信

息的主关系键,所以考勤信息∈3NF

关系模式:津贴信息(员工编号、姓名、性别、加班时间、加班天数、

加班类型、津贴情况)

模式判定:津贴信息∈2NF,且每个非主属性都不传递函数依赖于津贴信

息的主关系键,所以津贴信息∈3NF

5.物理结构设计

5.1定义数据库、表名

数据库名:

wages

数据库表名:

  1. 员工信息表:staff
  2. 部门信息表:dept
  3. 工资信息表:wages
  4. 考勤信息表:attendance
  5. 津贴信息表:allowance

5.2存储引擎

使用mysql数据库,选择InnoDB作为存储引擎。

5.3数据库存储结构设计

为了提高系统的性能,根据应用情况将数据的易变部分与稳定部分、经常

存取部分与不经常存取部分分开存放。

由于现在的计算机都有多个磁盘,将表(如员工信息表)和索引放在不同

的磁盘上,在查询过程中,大大提高I/O读写的效率,而对于较大的分放在两

个磁盘上,可以加快存取速度,在多用户环境下的作用更有效;为了改进系统

的性能,将日志文件与数据库对象(表、索引等)放在了不同的盘上。同时,

考虑到本系统是多用户的,为了提高效率,数据库备份的数据和日志文件将保

存在磁盘中。

在数据库中经常存取的部分包括:

员工(员工编号、姓名、性别、出生年月、所属部门。。..。)

部门(部门编号、部门名称、部门负责人、部门人数...。。)

工资(员工编号、基本工资、岗位工资、水电费.。.。。)

考勤(员工编号、姓名、性别、迟到次数、缺勤次数)

不经常存取部分包括:

基本工资(工资级别、工资金额)

岗位工资(工资级别、工资金额)

在数据库设计初始阶段,为了对以后的数据库进行物理优化,提供了一些

系统配置变量、存储分配系数,并对这些变量赋予合理的缺省值。但这些值不

一定适合每一种应用环境,在进行物理设计时,对这些变量重新赋值,以改善

系统的性能。在选择硬件设备、服务器操作系统、数据库时应该考虑能够逐步

增加和扩展。

在配置系统变量时,要注意同时使用数据库的用户数,同时打开的数据库

对象数,内存分配参数,缓冲区分配参数,时间片大小,数据库的大小,锁的

数目等。这些参数值都会影响数据库的存储时间和存储空间的分配。

5.4数据库存储方法设计

在本系统中,采用顺序查找,平均查找n/2次,建立B+树索引,则平均查找次数为B+树的层数log2 n+1。所以选择B+树作为索引,再设计过程中对关系的码建立索引。

5.5数据库表结构

(1)员工信息表

属性名

字段名

数据类型

长度

是否允许为空

是否主键

员工编号

employee_No

char

4

不允许

是

姓名

name

varchar

8

不允许

否

性别

sex

char

2

允许

否

出生年月

birthday

datetime

允许

否

所属部门

dept

varchar

20

不允许

否

文化程度

education_level

varchar

20

允许

否

职称

title

char

12

允许

否

(2)部门信息表

属性名

字段名

数据类型

长度

是否允许为空

是否主键

部门编号

code

char

4

不允许

是

部门名称

name

varchar

20

不允许

否

部门负责人

manager

varchar

20

不允许

否

部门人数

sum

int

10

不允许

否

(3)工资信息表

属性名

字段名

数据类型

长度

是否允许为空

有无索引

员工编号

code

char

4

不允许

是

基本工资

baseWages

varchar

20

不允许

否

岗位工资

postWages

varchar

20

不允许

否

水电费

money

float

10

不允许

否

津贴工资

subsidy

varchar

10

不允许

否

扣除薪酬

deduction

varchar

10

不允许

否

实发金额

fact

varchar

10

不允许

否

(4)考勤信息表

属性名

字段名

数据类型

长度

是否允许为空

有无索引

员工编号

code

char

4

不允许

是

姓名

name

varchar

8

不允许

否

性别

sex

char

2

不允许

否

迟到次数

delaysum

int

10

不允许

否

缺席次数

misssum

int

10

不允许

否

(5)津贴信息表

属性名

字段名

数据类型

长度

是否允许为空

有无索引

员工编号

code

char

4

不允许

是

姓名

name

varchar

8

不允许

否

性别

sex

char

2

不允许

否

加班时间

overtime

varchar

10

允许

否

加班天数

overday

float

10

允许

否

加班类型

overtype

varchar

10

允许

否

津贴情况

allowance

int

10

允许

否

5.6数据库模型

数据库模型

6.数据库实施

6.1数据库的创建

CREATE DATABASE wages CHARACTER SET utf8;

6.2数据库的表创建

(1)员工信息表

CREATE TABLE `staff`  (

 `employee_No` char(4) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NOT NULL,

 `name` varchar(8) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NULL DEFAULT NULL,

 `sex` char(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NULL DEFAULT NULL,

 `birthday` datetime(0) NULL DEFAULT NULL,

 `dept` varchar(20) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NULL DEFAULT NULL,

 `education_level` varchar(20) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NULL DEFAULT NULL,

 `title` char(12) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NULL DEFAULT NULL,

 PRIMARY KEY (`employee_No`) USING BTREE

) ENGINE = InnoDB CHARACTER SET = utf8mb4 COLLATE = utf8mb4_unicode_ci ROW_FORMAT = Dynamic;

基础数据初始化:

INSERT INTO `staff` VALUES ('001', '张三', '女', '1999-01-21 00:00:00', '部门', '本科', '无');

INSERT INTO `staff` VALUES ('002', '张三', '女', '1999-01-21 00:00:00', '部门', '本科', '无');

INSERT INTO `staff` VALUES ('003', '张三', '女', '1999-01-21 00:00:00', '部门', '本科', '无');

INSERT INTO `staff` VALUES ('004', '张三', '女', '1999-01-21 00:00:00', '部门', '本科', '无');

效果图:

图6.1 员工信息表运行效果

(2)部门信息表

CREATE TABLE `dept`  (

 `code` char(4) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NOT NULL,

 `name` varchar(20) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NULL DEFAULT NULL,

 `manager` varchar(20) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NULL DEFAULT NULL,

 `sum` int(0) NULL DEFAULT NULL,

 PRIMARY KEY (`code`) USING BTREE

) ENGINE = InnoDB CHARACTER SET = utf8mb4 COLLATE = utf8mb4_unicode_ci ROW_FORMAT = Dynamic;

数据初始化:

INSERT INTO `dept` VALUES ('001', '部门1', '张三', 10);

INSERT INTO `dept` VALUES ('002', '部门2', '张三', 10);

INSERT INTO `dept` VALUES ('003', '部门2', '张三', 10);

效果图:

图6.2 部门信息表运行效果

(3)工资信息表

DROP TABLE IF EXISTS `wages`;

CREATE TABLE `wages`  (

 `code` char(4) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NOT NULL,

 `baseWages` varchar(20) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NULL DEFAULT NULL,

 `postWages` varchar(20) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NULL DEFAULT NULL,

 `money` float(10, 0) NULL DEFAULT NULL,

 `subsidy` varchar(10) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NULL DEFAULT NULL,

 `deduction` varchar(10) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NULL DEFAULT NULL,

 PRIMARY KEY (`code`) USING BTREE

) ENGINE = InnoDB CHARACTER SET = utf8mb4 COLLATE = utf8mb4_unicode_ci ROW_FORMAT = Dynamic;

数据初始化:

INSERT INTO `wages` VALUES ('001', '2000', '1000', 1000, '1000', '');

INSERT INTO `wages` VALUES ('002', '2000', '1000', 1000, '1000', '');

INSERT INTO `wages` VALUES ('003', '2000', '1000', 1000, '1000', '');

INSERT INTO `wages` VALUES ('004', '2000', '1000', 1000, '1000', '');

效果图:

图6.3 工资信息表运行效果

(4)考勤信息表

CREATE TABLE `attendance`  (

 `code` char(4) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NOT NULL,

 `name` varchar(8) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NULL DEFAULT NULL,

 `sex` varchar(2) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NULL DEFAULT NULL,

 `delaysum` varchar(10) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NULL DEFAULT NULL,

 `misssum` varchar(10) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NULL DEFAULT NULL,

 PRIMARY KEY (`code`) USING BTREE

) ENGINE = InnoDB CHARACTER SET = utf8mb4 COLLATE = utf8mb4_unicode_ci ROW_FORMAT = Dynamic;

数据初始化:

INSERT INTO `attendance` VALUES ('001', '张三', '女', '11', '0');

INSERT INTO `attendance` VALUES ('002', '张三', '女', '11', '0');

INSERT INTO `attendance` VALUES ('003', '张三', '女', '11', '0');

INSERT INTO `attendance` VALUES ('004', '张三', '女', '11', '0');

INSERT INTO `attendance` VALUES ('005', '张三', '女', '11', '0');

效果图:

图6.4 考勤信息表运行效果

(5)津贴信息表

CREATE TABLE `allowance`  (

 `code` char(4) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NOT NULL,

 `name` varchar(4) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NULL DEFAULT NULL,

 `sex` char(8) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NULL DEFAULT NULL,

 `overtime` varchar(10) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NULL DEFAULT NULL,

 `allowance` int(0) NULL DEFAULT NULL,

 `overday` float(10, 0) NULL DEFAULT NULL,

 `overtype` varchar(10) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NULL DEFAULT NULL,

 PRIMARY KEY (`code`) USING BTREE

) ENGINE = InnoDB CHARACTER SET = utf8mb4 COLLATE = utf8mb4_unicode_ci ROW_FORMAT = Dynamic;

数据初始化:

INSERT INTO `allowance` VALUES ('001', '张三', '女', '0', 0, 0, '0');

INSERT INTO `allowance` VALUES ('002', '张三', '女', '0', 0, 0, '0');

INSERT INTO `allowance` VALUES ('003', '张三', '女', '0', 0, 0, '0');

INSERT INTO `allowance` VALUES ('004', '张三', '女', '0', 0, 0, '0');

INSERT INTO `allowance` VALUES ('005', '张三', '女', '0', 0, 0, '0');

运行效果图:

图6.5 津贴信息表运行效果

 

相关文章
|
12月前
|
存储 人工智能 NoSQL
AI大模型应用实践 八:如何通过RAG数据库实现大模型的私有化定制与优化
RAG技术通过融合外部知识库与大模型,实现知识动态更新与私有化定制,解决大模型知识固化、幻觉及数据安全难题。本文详解RAG原理、数据库选型(向量库、图库、知识图谱、混合架构)及应用场景,助力企业高效构建安全、可解释的智能系统。
|
存储 关系型数据库 数据库
附部署代码|云数据库RDS 全托管 Supabase服务:小白轻松搞定开发AI应用
本文通过一个 Agentic RAG 应用的完整构建流程,展示了如何借助 RDS Supabase 快速搭建具备知识处理与智能决策能力的 AI 应用,展示从数据准备到应用部署的全流程,相较于传统开发模式效率大幅提升。
附部署代码|云数据库RDS 全托管 Supabase服务:小白轻松搞定开发AI应用
|
存储 弹性计算 Cloud Native
云原生数据库的演进与应用实践
随着企业业务扩展,传统数据库难以应对高并发与弹性需求。云原生数据库应运而生,具备计算存储分离、弹性伸缩、高可用等核心特性,广泛应用于电商、金融、物联网等场景。阿里云PolarDB、Lindorm等产品已形成完善生态,助力企业高效处理数据。未来,AI驱动、Serverless与多云兼容将推动其进一步发展。
611 8
|
安全 关系型数据库 数据管理
阿里云数据库:构建高性能与安全的数据管理系统
阿里云数据库提供RDS、PolarDB、Tair等核心产品,具备高可用、弹性扩展、安全合规及智能运维等技术优势,广泛应用于电商、游戏、金融等行业,助力企业高效管理数据,提升业务连续性与竞争力。
|
存储 弹性计算 安全
现有数据库系统中应用加密技术的不同之处
本文介绍了数据库加密技术的种类及其在不同应用场景下的安全防护能力,包括云盘加密、透明数据加密(TDE)和选择列加密。分析了数据库面临的安全威胁,如管理员攻击、网络监听、绕过数据库访问等,并通过能力矩阵对比了各类加密技术的安全防护范围、加密粒度、业务影响及性能损耗。帮助用户根据安全需求、业务改造成本和性能要求,选择合适的加密方案,保障数据存储与传输安全。
|
存储 人工智能 数据库
视图是什么?为什么要用视图呢?数据库视图:定义、特点与应用
本文三桥君深入探讨数据库视图的概念与应用,从定义特点到实际价值全面解析。视图作为虚拟表具备动态更新、简化查询、数据安全等优势,能实现多角度数据展示并保持数据库重构的灵活性。产品专家三桥君还分析了视图与基表关系、创建维护要点及性能影响,强调视图是提升数据库管理效率的重要工具。三桥君通过系统讲解,帮助读者掌握这一常被忽视却功能强大的数据库特性。
2859 0
|
SQL 监控 安全
数据库安全审计系统
Next-DBM数据库审计系统助力企业解决数据安全难题,提供统一身份管理、全方位监控、智能风险识别、完整审计追溯及精细化权限管控,有效防范数据泄露与内部威胁,保障企业核心资产安全,满足合规要求,提升运维效率。
|
缓存 关系型数据库 BI
使用MYSQL Report分析数据库性能(下)
使用MYSQL Report分析数据库性能
688 158
|
关系型数据库 MySQL 数据库
自建数据库如何迁移至RDS MySQL实例
数据库迁移是一项复杂且耗时的工程,需考虑数据安全、完整性及业务中断影响。使用阿里云数据传输服务DTS,可快速、平滑完成迁移任务,将应用停机时间降至分钟级。您还可通过全量备份自建数据库并恢复至RDS MySQL实例,实现间接迁移上云。

热门文章

最新文章