人事信息新管理系统后台数据库设计文档格式.docx

人事信息新管理系统后台数据库设计文档格式.docx

《人事信息新管理系统后台数据库设计文档格式.docx》由会员分享，可在线阅读，更多相关《人事信息新管理系统后台数据库设计文档格式.docx（46页珍藏版）》请在冰豆网上搜索。

基本功能与要求：

1.在人事管理过程中，实现信息的自动化管理。

2.实现各种信息的修改、插入、删除功能（对管理员而言）。

3.实现对各种信息的查询、统计，支持模糊查询（对员工和管理员均可）。

4.按照年份月份统计某个员工的出勤情况。

5.按照某年某月某日统计查询某部门的迟到和早退人数。

6.按年统计各部门的调入调出人数信息。

分工任务：

1需求分析

2数据库物理实现

3系统后台功能测试

三、原始资料

1.《数据库管理系统课程设计》指导书

2.数据库系统设计课件

四、要求的设计（调查/论文）成果

1.课程设计报告

2.课程设计作品

五、进程安排

序号

课程设计内容

学时分配

备注

1

选题、需求分析

1天

2

数据库设计

2天

3

数据库表及相关约束、视图实现

4

数据库的存储过程、触发器实现

5

数据库后台功能测试

6

验收答辩、撰写课程设计报告

合计

10天

六、主要参考资料

[1]顾兵.数据库技术与应用（SQLServer）.北京：

清华大学出版社，2010.

[2]马晓梅.SQLServer实验指导.第3版.北京：

清华大学出版社，2009.

[3]范立南等.SQLServer2005实用教程.北京：

[4]李丹.SQLServer2005数据库管理与开发.北京：

机械工业出版社，2010.

指导教师（签名）：

20年月日

1.需求分析…………………………………………………………………………1

1.1系统功能的基本要求………………………………………………………1

1.2系统需求分析………………………………………………………………1

1.3数据字典……………………………………………………………………2

1.4数据流图……………………………………………………………………3

2.概念结构设计……………………………………………………………………4

2.1局部E-R图…………………………………………………………………4

2.2全局E-R图…………………………………………………………………6

3.逻辑结构设计……………………………………………………………………7

3.1E-R图向关系模式转换的原则……………………………………………7

3.2根据E-R图转换关系模式…………………………………………………8

3.3关系模式的优化……………………………………………………………8

4.物理结构设计……………………………………………………………………9

4.1数据库文件的建立…………………………………………………………9

4.2数据表的建立………………………………………………………………9

4.3视图的建立…………………………………………………………………11

4.4索引的建立…………………………………………………………………11

4.5存储过程的建立……………………………………………………………12

4.6触发器的建立………………………………………………………………12

4.6约束的建立…………………………………………………………………12

5.数据库的物理实现………………………………………………………………13

5.1数据库的建立………………………………………………………………13

5.2数据表的建立………………………………………………………………13

5.3视图的建立…………………………………………………………………16

5.4索引的建立…………………………………………………………………22

5.5存储过程的建立……………………………………………………………27

5.6触发器的建立………………………………………………………………29

5.7约束的建立…………………………………………………………………30

6.系统后台功能测试………………………………………………………………34

7.总结…………………………………………………………………………………37

1.需求分析

开发数据库系统的第一步是进行需求分析，需求分析的好坏直接决定者系统能否真正满足用户的需要。

需求分析阶段位于软件开发的前期，它的基本任务是准确地定义未来系统的目标，确定为了满足用户的需求系统必须做什么。

1.1系统功能的基本要求：

（1）管理者进入系统后要能够清晰地看到企业的机构组织形式，并能够很方便地进入到各个管理功能模块中。

管理者能够根据企业的实际来实时地改变系统中机构组织，主要的改变包括：

当有新部门成立时，要将新部门加入到系统中；

当有部门发生变更时，如更名，上级部门改变了等，要将变更信息在系统中及时更新；

（2）员工各种信息的输入，包括员工的基本信息、学历信息、婚姻状况信息、职称等。

（3）员工各种信息的修改和删除。

修改的范围有：

人员的基本信息；

将人员从一个部门下移到另一个部门下。

对于转出、辞职、辞退、退休员工信息的删除；

（4）按照一定的条件，查询、统计符合条件的员工信息；

至少应该包括每个员工详细信息的查询、按婚姻状况查询、按学历查询、按工作岗位查询等，至少应该包括按学历、婚姻状况、岗位、参加工作时间等统计各自的员工信息；

1.2系统需求分析

1.2.1系统功能流程图

1.2.2系统主要功能模块分析

（1）基本信息模块。

主要包括企业员工的基本信息，如姓名、性别、学历、婚姻状况、联系方式等。

职工登录后可以查询个人信息；

管理员可以负责维护职工基本信息和职工流动信息。

（2）员工工作信息模块。

主要显示员工在公司的情况。

（3）部门信息模块。

主要记录企业的组织机构信息。

（4）考勤信息模块。

主要包含员工上下班的出勤情况，如迟到、休假等。

（5）工资信息模块。

主要包括员工的工资信息。

（6）查询统计模块。

主要为实现上述信息的查询和统计，并能够生成相关报表文件。

1.3数据字典

数据字典的用途：

是关于数据库中数据的描述；

在需求分析阶段建立，是下一步进行概念设计的基础

数据字典的内容：

数据项（数据的最小单位）、数据结构（若干数据项有意义的集合）、数据流（表示某一处理过程的输入或输出）、数据存储（处理过程中存取的数据）、处理过程（该过程的功能）等

1.3.1数据项

（1）员工基本情况。

包括的数据项有员工编号，姓名，性别，年龄，名族，入职时间，所属部门，联系电话，身份证号，基本工资。

（2）员工工作信息。

包括的数据项有员工编号、所属部门编号、职称、工龄。

（3）部门信息。

包括的数据项有部门编号、部门名称、部门电话、部门经理。

（4）员工考勤信息。

包括的数据项有员工编号、缺勤、迟到、早退。

（5）员工工资信息。

包括的数据项有员工编号，姓名，底薪，补贴，奖金，加班，代扣养老金，代扣医疗保险，代扣住房公积金，所得税，房贴，房租，实发工资。

1.3.2数据结构

例如说，数据结构名：

员工

含义说明：

是人事信息管理系统的主体数据结构，定义了一个员工的有关信息。

组成：

员工编号、性别、姓名、年龄、民族、身份证号、入职时间、部门编号、联系电话、基本工资。

1.3.3数据流

例如说，数据流名：

变更员工

数据流来源：

员工编号

数据流去向：

员工信息

说明：

变动人员的有关信息

1.3.4数据存储

例如说，数据存储名：

员工信息表单

流入数据流：

来源员工

流出数据流：

去向

存取方式：

随机存取

说明：

记录员工信息的基本情况

1.3.5存储结构

例如工资信息中

处理过程名：

计算工资

输入数据流：

员工，出勤信息

输出数据流：

工资信息表单

计算公司所有员工的工资

处理：

在每个月的最后一天计算出每个员工的工资。

1.4总数据流图

2.概念结构设计

2.1局部E-R图

2.1.1员工基本信息E-R图

2.1.2员工工作信息E-R图

2.1.3部门信息E-R图

2.1.4工资信息E-R图

2.1.5考勤信息E-R图

2.1.6员工调动信息E-R图

2.2全局E-R图

第三章逻辑结构设计

逻辑结构设计的任务是把概念结构设计阶段设计完毕的基本E—R图转化为与选用的具体机器上的DBMS产品所支持的数据模型相符的逻辑结构（包括数据库模式和外模式）。

这些模式在功能性、完整性和一致性约束及数据库的可扩充性等方面应满足用户的各种要求。

E—R图型关系模型的转化要解决的问题是如何将实体和实体间的关系转化为关系模式，如何确定这些关系模式的属性和代码。

3.1E-R图向关系模式转换的原则

（1）一个实体型转换为一个关系模式。

实体的属性就是关系的属性。

实体的码就是关系的码。

（2）一个联系转化为一个关系模式，与该联系相连的各实体的码以及联系的属性转化为关系的属性，该关系的码则有三种情况：

若联系为1：

1，则每个实体的码均是该关系的后选码。

n，则关系的码为n端实体的码。

若联系为m：

n，则关系的码为诸实体码的组合。

联系为1：

一个1:

1联系可以转换为一个独立的关系模式，也可以与任意一端对应的关系模式合并。

如果转换为一个独立的关系模式，则与该联系相连的各实体的码以及联系本身的属性均转换为关系的属性，l每个实体的码均是该关系的候选码。

如果与某一端对应的关系模式合并，则需要在该关系模式的属

n

n联系可以转换为一个独立的关系模式，也可以与n端对应的关系模式合并。

如果转换为一个独立的关系模式，则与该联系相连的各实体的码以及联系本身的属性均转换为关系的属性，而关系的码为n端实体的码。

如果与n端对应的关系模式合并，则在n端实体对应模式中加入1端实体所对应关系模式的码，以及联系本身的属性。

而关系的码为n端实体的码。

联系为m：

一个m:

n联系转换为一个关系模式。

与该联系相连的各实体的码以及联系本身的属性均转换为关系的属性。

而关系的码为各实体码的组合。

例如在我们的例子中，"

选修"

联系是一个m:

n联系，可以将它转换为如下关系模式，其中学号与课程号为关系的组合码：

选修（学号，课程号，成绩）三个或三个以上实体间的一个多元联系转换为一个关系模式。

与该多元联系相连的各实体的码以及联系本身的属性均转换为关系的属性。

三个或三个以上实体间的一个多元联系转换为一个关系模式。

（3）同一实体集的实体间的联系，即自联系，也可按上述1:

1、1:

n和m:

n三种情况分别处理。

（4）具有相同码的关系模式可合并。

为了减少系统中的关系个数，如果两个关系模式具有相同的主码，可以考虑将他们