论文部分内容阅读
[摘 要]本文是继“财务软件数据库设计探析——账务处理子系统”和“财务软件数据库设计探析——固定资产管理子系统”之后,又一篇描述财务软件核心数据库设计的文章。本文借助Sybase公司的CASE工具PowerDesigner6.0,结合当前国内流行的财务软件用友U8的数据库特征,给出了一个完整的工资管理子系统的数据库设计模型,包括描述E-R图的概念模型(.CDM)、由概念模型直接转换而成的物理模型(.PDM),以及直接生成的基于Access的物理数据库。
[关键词]财务软件;核心数据库;工资管理子系统;设计
doi:10.3969/j.issn.1673-0194.2009.16.001
[中图分类号]F232[文献标识码]A[文章编号]1673-0194(2009)16-0005-03
一、PowerDesigner6.0中E-R图转换为物理模型的原则
在PowerDesigner6.0中,E-R图中的实体转换成表,E-R图中联系的转换结果依赖于联系的基数和类型。在一对一的联系中,只对dominant(强制规定)的一端生成表;在一对多的联系中,为“一”的一端实体中的关键字就转换为“多”的一端的表的外码,在多对多的联系中,则产生一个新表,新表的关键字由两个实体中的关键字组合而成,可以添加联系表的属性。
二、工资管理子系统的数据库设计
按存储空间最优、兼顾运行效率的原则设计出的,符合第三范式的工资管理子系统的E-R图见图1,图中共12个基本实体、10对实体间的联系;图2为工资管理子系统的物理模型,由PowerDesigner6.0从图1转换而来,自动生成2个联系表及联系表的关键字,并添加了联系表的相关属性;图3为基于Access的工资管理子系统的物理数据库,共计14个表,由PowerDesigner 6.0从图2直接生成。
三、工资管理子系统E-R图及物理模型分析
因工资管理子系统E-R图及物理模型较为复杂,本文把实体表间的联系拆分为3个部分(与“职工类别表”相关、与“职员表”相关及其他),分别表述如下:
1.与“职工类别表”相关的E-R图及物理模型分析
职工类别,一般来讲包括企业管理人员、经营人员、车间管理人员和生产工人。工资管理过程中,按照工资类别考虑将公司职员的工资和福利费分配计入不同的会计科目。
(1)职工类别表—职员表:一个职工类别(如企业管理人员)包括多名职员,一个职员只能对应一个职工类别,因此职工类别表和职员表之间的联系为1∶n,生成物理模型后,职工类别表的关键字成为职员表的外码。
(2)职工类别表—奖惩项目表:一个职工类别(如企业管理人员)对应不同奖惩项目的一种奖惩额度,一种奖惩额度只能对应一个职工类别,因此职工类别表和奖惩项目表之间的联系为1∶1,生成物理模型后,职工类别表的关键字成为奖惩项目表的外码;此处也可将考勤项目设为简单的码表(仅包含奖惩项目编号和奖惩项目名称),则职工类别表和奖惩项目表之间的联系为m∶n,在物理模型中生成联系表奖惩额度表,存储各工资类别对应的不同奖惩项目的金额信息。
(3)职工类别表—科目表:一个职工类别(如企业管理人员)发生的不同费用(如工资、福利费等)对应不同的科目,一个会计科目在不同会计期间对应职工类别不同的费用金额,因此职工类别表和科目表之间的联系为m∶n,在物理模型中生成联系表工资费用分配表,存储不同工资类别不同会计期间的应发工资信息。
2.与“职员表”相关的E-R图及物理模型分析
(1)部门表—职员表:一个部门中可能有多个职员,一个职员只能属于一个部门,因此部门码表和职员表之间的联系为1∶n,生成物理模型后,部门码表的关键字成为职员表的外码。
(2)职称码表—职员表:拥有同一个职称的职员有若干个,而每个职员在某个会计期间只能有一个职称,因此职称码表和职员表之间的联系为1∶n,生成物理模型后,职称码表的关键字成为职员表的外码。
(3)岗位码表—职员表:拥有同一个岗位的职员有若干个,而每个职员在某个会计期间只能有一个岗位,因此岗位码表和职员表之间的联系为1∶n,生成物理模型后,岗位码表的关键字成为职员表的外码。
(4)职员表—考勤表:一个职员在不同的会计期间拥有不同的考勤记录,而一条考勤记录只能对应一个职员,因此职员表和考勤表之间的联系为1∶n,生成物理模型后,职员表的关键字成为考勤表的外码。
(5)职员表—基本工资表:一个职员在不同的会计期间拥有不同的基本工资记录,而一条基本工资记录只能对应一个职员,因此职员表和基本工资表之间的联系为1∶n,生成物理模型后,职员表的关键字成为基本工资表的外码。
(6)职员表—变动工资表:一个职员在不同的会计期间拥有不同的变动工资记录,而一条变动工资记录只能对应一个职员,因此职员表和变动工资表之间的联系为1∶n,生成物理模型后,职员表的关键字成为变动工资表的外码。
3.其他E-R图及物理模型分析
(1)科目表—凭证主表:凭证主表是存储凭证信息的表,每张凭证为一条记录。一个科目可以在多张凭证中出现,一张凭证中也可以涉及多个科目,因此科目表与凭证主表之间的联系为m∶n,在物理模型中生成联系表凭证明细表,以凭证中的每行分录为一条记录。科目表与其他表(科目类型码表、科目性质码表)之间的联系见账务处理子系统,此处略。
(2)用户表:本工资管理子系统中简单地设了一个用户表,用以存储用户名和密码等信息。当然,也可以参考账务处理子系统给出用户和角色及模块之间的联系。
四、工资管理子系统数据库设计与U8比较评价
在用友U8的工资管理子系统中,最具特色的地方就是可以根据单位的具体情况设置单个或多个工资类别,这主要取决于单位职工的工资项目和计算公式是否相同,若相同则选单个工资类别,若不同则选多个工资类别。如单位的工资类别可分为在岗人员和退休人员。工资项目可以根据不同的工资类别分别设置,除了应发合计、扣款合计和实发合计3个工资项目外,在岗人员的工资项目还包括基本工资、职务补贴、福利补贴、交通补贴、奖金、缺勤扣款、住房公积金等,而退休人员仅有基本工资和住房公积金两个工资项目。
U8工资管理子系统的特色之二是不同工资类别中的工资项目相互独立,可以为不同工资类别中的同一个工资项目设置不同的计算公式,如在岗人员的住房公积金=(基本工资 职务补贴 福利补贴 交通补贴 奖金)×0.08,而退休人员的住房公积金=基本工资×0.08。
用友工资管理子系统虽然节省了存储空间(退休人员的工资表中项目极少),但却增加了操作的复杂性,每次操作前先要选择工资类别。本文设计的工资管理子系统数据库同样可以实现不同工资类别的工资管理,只需要在职工类别表中添加一条退休人员的记录,并把工资项目住房公积金的公式统一设为应发合计×0.08即可。这种做法尽管操作简单,但却浪费了一定的存储空间(退休人员的工资项目和在岗人员一样,但很多项目的值均为0,如职务补贴、福利补贴、交通补贴、奖金、缺勤扣款等)。
本文设计的工资管理子系统数据库为独立运行的子系统,若与账务子系统合并,只需将基本表凭证主表、科目表、部门表、用户表,以及联系表凭证明细表共享即可。
主要参考文献
[1] 刘梅玲,朱学义,黄岩.CASE工具在电算化会计实验教学中的应用[J]. 中国管理信息化,2008(22).
[2] 陈旭,毛华杨.会计信息系统分析、设计与开发[M].北京:清华大学出版社,2006.[3] 刘自伟,等.管理信息系统开发技术[M].武汉: 武汉理工大学出版社,2003.
[4] 王新玲,房玲玲. 用友ERP财务管理系统实验教程[M].北京:清华大学出版社,2006.
[关键词]财务软件;核心数据库;工资管理子系统;设计
doi:10.3969/j.issn.1673-0194.2009.16.001
[中图分类号]F232[文献标识码]A[文章编号]1673-0194(2009)16-0005-03
一、PowerDesigner6.0中E-R图转换为物理模型的原则
在PowerDesigner6.0中,E-R图中的实体转换成表,E-R图中联系的转换结果依赖于联系的基数和类型。在一对一的联系中,只对dominant(强制规定)的一端生成表;在一对多的联系中,为“一”的一端实体中的关键字就转换为“多”的一端的表的外码,在多对多的联系中,则产生一个新表,新表的关键字由两个实体中的关键字组合而成,可以添加联系表的属性。
二、工资管理子系统的数据库设计
按存储空间最优、兼顾运行效率的原则设计出的,符合第三范式的工资管理子系统的E-R图见图1,图中共12个基本实体、10对实体间的联系;图2为工资管理子系统的物理模型,由PowerDesigner6.0从图1转换而来,自动生成2个联系表及联系表的关键字,并添加了联系表的相关属性;图3为基于Access的工资管理子系统的物理数据库,共计14个表,由PowerDesigner 6.0从图2直接生成。
三、工资管理子系统E-R图及物理模型分析
因工资管理子系统E-R图及物理模型较为复杂,本文把实体表间的联系拆分为3个部分(与“职工类别表”相关、与“职员表”相关及其他),分别表述如下:
1.与“职工类别表”相关的E-R图及物理模型分析
职工类别,一般来讲包括企业管理人员、经营人员、车间管理人员和生产工人。工资管理过程中,按照工资类别考虑将公司职员的工资和福利费分配计入不同的会计科目。
(1)职工类别表—职员表:一个职工类别(如企业管理人员)包括多名职员,一个职员只能对应一个职工类别,因此职工类别表和职员表之间的联系为1∶n,生成物理模型后,职工类别表的关键字成为职员表的外码。
(2)职工类别表—奖惩项目表:一个职工类别(如企业管理人员)对应不同奖惩项目的一种奖惩额度,一种奖惩额度只能对应一个职工类别,因此职工类别表和奖惩项目表之间的联系为1∶1,生成物理模型后,职工类别表的关键字成为奖惩项目表的外码;此处也可将考勤项目设为简单的码表(仅包含奖惩项目编号和奖惩项目名称),则职工类别表和奖惩项目表之间的联系为m∶n,在物理模型中生成联系表奖惩额度表,存储各工资类别对应的不同奖惩项目的金额信息。
(3)职工类别表—科目表:一个职工类别(如企业管理人员)发生的不同费用(如工资、福利费等)对应不同的科目,一个会计科目在不同会计期间对应职工类别不同的费用金额,因此职工类别表和科目表之间的联系为m∶n,在物理模型中生成联系表工资费用分配表,存储不同工资类别不同会计期间的应发工资信息。
2.与“职员表”相关的E-R图及物理模型分析
(1)部门表—职员表:一个部门中可能有多个职员,一个职员只能属于一个部门,因此部门码表和职员表之间的联系为1∶n,生成物理模型后,部门码表的关键字成为职员表的外码。
(2)职称码表—职员表:拥有同一个职称的职员有若干个,而每个职员在某个会计期间只能有一个职称,因此职称码表和职员表之间的联系为1∶n,生成物理模型后,职称码表的关键字成为职员表的外码。
(3)岗位码表—职员表:拥有同一个岗位的职员有若干个,而每个职员在某个会计期间只能有一个岗位,因此岗位码表和职员表之间的联系为1∶n,生成物理模型后,岗位码表的关键字成为职员表的外码。
(4)职员表—考勤表:一个职员在不同的会计期间拥有不同的考勤记录,而一条考勤记录只能对应一个职员,因此职员表和考勤表之间的联系为1∶n,生成物理模型后,职员表的关键字成为考勤表的外码。
(5)职员表—基本工资表:一个职员在不同的会计期间拥有不同的基本工资记录,而一条基本工资记录只能对应一个职员,因此职员表和基本工资表之间的联系为1∶n,生成物理模型后,职员表的关键字成为基本工资表的外码。
(6)职员表—变动工资表:一个职员在不同的会计期间拥有不同的变动工资记录,而一条变动工资记录只能对应一个职员,因此职员表和变动工资表之间的联系为1∶n,生成物理模型后,职员表的关键字成为变动工资表的外码。
3.其他E-R图及物理模型分析
(1)科目表—凭证主表:凭证主表是存储凭证信息的表,每张凭证为一条记录。一个科目可以在多张凭证中出现,一张凭证中也可以涉及多个科目,因此科目表与凭证主表之间的联系为m∶n,在物理模型中生成联系表凭证明细表,以凭证中的每行分录为一条记录。科目表与其他表(科目类型码表、科目性质码表)之间的联系见账务处理子系统,此处略。
(2)用户表:本工资管理子系统中简单地设了一个用户表,用以存储用户名和密码等信息。当然,也可以参考账务处理子系统给出用户和角色及模块之间的联系。
四、工资管理子系统数据库设计与U8比较评价
在用友U8的工资管理子系统中,最具特色的地方就是可以根据单位的具体情况设置单个或多个工资类别,这主要取决于单位职工的工资项目和计算公式是否相同,若相同则选单个工资类别,若不同则选多个工资类别。如单位的工资类别可分为在岗人员和退休人员。工资项目可以根据不同的工资类别分别设置,除了应发合计、扣款合计和实发合计3个工资项目外,在岗人员的工资项目还包括基本工资、职务补贴、福利补贴、交通补贴、奖金、缺勤扣款、住房公积金等,而退休人员仅有基本工资和住房公积金两个工资项目。
U8工资管理子系统的特色之二是不同工资类别中的工资项目相互独立,可以为不同工资类别中的同一个工资项目设置不同的计算公式,如在岗人员的住房公积金=(基本工资 职务补贴 福利补贴 交通补贴 奖金)×0.08,而退休人员的住房公积金=基本工资×0.08。
用友工资管理子系统虽然节省了存储空间(退休人员的工资表中项目极少),但却增加了操作的复杂性,每次操作前先要选择工资类别。本文设计的工资管理子系统数据库同样可以实现不同工资类别的工资管理,只需要在职工类别表中添加一条退休人员的记录,并把工资项目住房公积金的公式统一设为应发合计×0.08即可。这种做法尽管操作简单,但却浪费了一定的存储空间(退休人员的工资项目和在岗人员一样,但很多项目的值均为0,如职务补贴、福利补贴、交通补贴、奖金、缺勤扣款等)。
本文设计的工资管理子系统数据库为独立运行的子系统,若与账务子系统合并,只需将基本表凭证主表、科目表、部门表、用户表,以及联系表凭证明细表共享即可。
主要参考文献
[1] 刘梅玲,朱学义,黄岩.CASE工具在电算化会计实验教学中的应用[J]. 中国管理信息化,2008(22).
[2] 陈旭,毛华杨.会计信息系统分析、设计与开发[M].北京:清华大学出版社,2006.[3] 刘自伟,等.管理信息系统开发技术[M].武汉: 武汉理工大学出版社,2003.
[4] 王新玲,房玲玲. 用友ERP财务管理系统实验教程[M].北京:清华大学出版社,2006.