财务软件核心数据库设计探析

刘梅玲　张　涛　朱学义　屈　巍

[摘要]本文利用Power Designer，结合用友U8的数据库特征，提出了一个完整的账务处理子系统的数据库设计模型。[关键词]财务软件；数据库；账务处理

[中图分类号]F232[文献标识码]A[文章编号]1673-0194(2009)11-0007-05

一个成功的财务软件，是由50％的业务+50％的软件所组成，而50％的成功软件又由25％的数据库+25％的程序所组成，数据库设计的好坏是一个关键。这里的数据库设计就是对于一个给定的应用环境，构造最优的数据库模式，建立数据库及其应用系统，使之能够有效地存储数据，满足各种用户的应用需求。财务软件是一个复杂而又庞大的信息处理系统，其数据库的优化设计尤为重要。

本文借助Sybase公司的CASE工具Power Designer 6.0，结合当前国内流行的财务软件用友U8的数据库特征，给出了一个完整的账务处理子系统的数据库设计模型，包括描述E—R图的概念模型(.CDM)、由概念模型直接转换而成的物理模型(.PDM)，以及直接生成的基于Access的物理数据库，供财务软件数据库分析人员和设计人员参考。

一、财务软件数据库设计的原则

1存储空间与运行效率的矛盾

伴随用友ERP不断升级，其考虑的因素日渐增多，导致其生成的数据库也日渐庞大。笔者在“电算化会计”课程的U852实验过程中，只处理了4笔总账日常业务的账套备份文件达到16.4MB，包含6个财务子系统的实验备份账套竟然达到328MB，收缴电子档作业成为一个不小的难题。U870安装时建立数据库的时间也长达半小时。尽管电子科技的发展带给我们日趋扩大的硬盘空间，但我们在存储及备份财务数据时，总感觉存储空间紧张，这不得不让我们把眼光重新聚集到数据库设计的优化问题上。

在数据库的设计过程中，存储空间和运行效率是一对永远解不开的矛盾。或许用友的软件工程师们当初为了提高财务软件的运行效率，没有太多考虑存储空间的节省，如客户、供应商、项目、存货等辅助核算的所有相关信息都存储在“凭证及明细账表(GL_ae—cvouch)”中，致使该表中的大量字段空白，因为只有少数科目涉及辅助核算，造成数据库空间的较大浪费；再如U870的一张采购单就有上百个字段，其实用户用到的仅有10个字段左右，其他字段皆为占据空间的空白字段，致使财务数据账套成为庞然大物。

本文的账务处理子系统数据库的设计，借鉴用友u8的数据库设计原理，以提高存储空间的利用率、减少冗余数据为前提，得出便于维护、节省空间、符合第三范式要求的优化数据库。本文之后还会相继推出关于固定资产、工资、销售与应收、采购与应付、库存与存货等5个子系统数据库优化设计的文章。

2.PowerDesigner 6.0中E—R图转换为物理模型的原则

在PowerDes培ner6.0中，E—R图中的实体转换成表，E—R图中联系的转换结果依赖于联系的基数和类型。在一对一的联系中，只对dominant(强制规定)的一端生成表；在一对多的联系中，为“一”的一端实体中的关键字就转换为“多”的一端的表的外码，在多对多的联系中，则产生一个新表，新表的关键字由两个实体中的关键字组合而成，可以添加联系表的属性。

二、账务处理子系统的数据库设计

按存储空间最优、兼顾运行效率的原则设计出的符合第三范式的账务处理子系统的E—R图见图1，图中共17个实体、33对实体间的联系；图2为账务处理子系统的物理模型，由PowerDesigner 6.0从图1转换而来，自动生成20个联系表及联系表的关键字，并添加了联系表的相关属性；图3为基于Access的账务处理子系统的物理数据库，共计37个表，由P0werDesigller 6.0从图2直接生成。

三、账务处理子系统E—R图及物理模型分析

因账务处理子系统E—R图及物理模型较为复杂，本文把实体表问的联系拆分为3个部分(与“账套表”相关、与“科目表”相关及其他)，分别表述如下：

1与“账套表”相关的E—R图及物理模型分析

一个账套只能保存一个公司或一个独立核算单位的会计资料。在实际工作中可以根据需要建立多个账套，通过合理组织账套文件，及时掌握各子公司或下属独立核算单位的财务状况，为加强企业管理和经济核算提供必要的信息。

(1)账套表一币别码表：一个账套中只涉及一种记账本位币，一种币别可以成为多个账套的记账本位币，因此币别码表和账套表之间的联系为1：n，生成物理模型后，币别码表的关键字成为账套表的外码。

(2)账套表一行业码表：一个账套中所记录的内容只属于一个行业，一个行业可以有多个账套，因此行业码表和账套表之间的联系为1：n，生成物理模型后，行业码表的关键字成为账套表的外码。

(3)账套表一凭证类型码表：一个账套中可以有多个凭证类型(如收、付、转)，一种凭证类型也可以隶属多个账套，因此凭证类型码表和账套表之间的联系为m：n，在物理模型中生成联系表凭证类型表，存储该账套中各种凭证类型的科目限制信息，如收款凭证的借方必须有“1001”或“1002”。

(4)账套表一科目表：一个账套中可有多个科目，一个科目可为多个账套所用，因此账套表和科目表之间的联系为m：n，在物理模型中生成联系表科目余额表，存储该账套中的科目余额信息，包括科目的期初余额和方向、借贷方发生额、借贷方累计发生额及期末余额和方向，每月一条记录。

(5)账套表一部门码表：一个账套中可有多个部门，一个具体的部门只能属于一个账套，因此账套表和部门码表之间的联系为1：n，生成物理模型后，账套表的关键字成为部门码表的外码。

(6)账套表一存货码表：其设计原理基本同“账套表一部门码表”，联系为l：n，生成物理模型后，账套表的关键字成为存货码表的外码。

(7)账套表一项目码表：其设计原理基本同“账套表一部门码表”，联系为l：n，生成物理模型后，账套表的关键字成为项目码表的外码。

(8)账套表一凭证主表：一个账套中可有多张凭证，一张具体的凭证只能属于一个账套，因此账套表和凭证主表之间的联系为1：n，生成物理模型后，账套表的关键字成为账套主表的外码。

(9)账套表一银行码表：一个账套中可有多家开户行，一家银行可为多个账套服务，因此账套表和银行码表之间的联系为m：n，在物理模型中生成联系表——银行余额表，存储该账套中的银行方的银行余额信息，包括银行的期初余额和方向、借贷方发生额、借贷方累计发生额及期末余额和方向，每月一条记录。

2与“科目表”相关的E—R图及物理模型分析

(1)科目表一科目类别码表：科目类别需要根据科

目编码首位判断，确定该科目属于资产、负债、所有者权益，还是成本和损益。一种科目类别中可有多个科目，一个科目只能属于一种科目类别，因此科目类别码表和科目表之间的联系为l：n，生成物理模型后，科目类别码表的关键字成为科目表的外码。

(2)科目表一科目性质码表：科目性质主要是指科目所带的辅助核算，包括部门、个人往来、供应商往来、客户往来、项目核算等。一种科目性质可针对多个科目，如供应商往来一般可包括应付账款、应付票据和预付账款等科目，而一个科目只能带一种辅助核算(用友U8中一个科目最多允许带两种辅助核算，本文设计的数据库为简单起见，不考虑此种情况)，因此科目类别码表和科目表之间的联系为1：n，生成物理模型后，科目性质码表的关键字成为科目表的外码。

(3)科目表一部门码表：一个科目(如“管理费用”)的辅助核算可能涉及多个部门，一个部门可能参与多个科目的辅助核算，因此科目表和部门码表之间的联系为m：n，在物理模型中生成联系表——部门核算表和部门余额表，分别存储该账套中部门辅助核算的日常核算信息和累计信息，其中部门核算表是以一张凭证为一条分录，而部门余额表是一个月为一条记录。在用友U8中，把所有的日常辅助核算信息均存储于凭证及明细账表(GL_accvouch)，而把所有的辅助核算余额信息均存储于辅助总账表(GL_access)中，虽然提高了查询效率，但却以占用大量存储空间为代价。

(4)科目表一职员表：其设计原理基本同“科目表一部门码表”，联系为m：n，在物理模型中生成联系表——个人核算表和个人余额表。

(5)科目表一往来码表：其设计原理基本同“科目表一部门码表”，联系为m：n，在物理模型中生成联系表——往来核算表和往来余额表。

(6)科目表一项目码表：其设计原理基本同“科目表一部门码表”，联系为m：n，在物理模型中生成联系表——项目核算表和项目余额表。

(7)科目表一存货码表：其设计原理基本同“科目表一部门码表”，联系为m：n，在物理模型中生成联系表——存货核算表和存货余额表。

(8)科目表一银行码表：其设计原理基本同“科目表一部门码表”，联系为m：n，在物理模型中生成联系表——银行核算表和企业银行余额表。除此之外，为单独存储企业的未达账项，单独设置了联系表——企业未达账项表。

(9)科目表一凭证主表：凭证主表是存储凭证信息的表，每张凭证为一条记录。一个科目可以在多张凭证中出现，一张凭证中也可以涉及多个科目，因此科目表与凭证主表之间的联系为m；n，在物理模型中生成联系表一凭证明细表，以凭证中的每行分录为一条记录。

3其他E—R图及物理模型分析

(1)部门码表一职员表：一个部门中可能有多个职员，一个职员只能属于一个部门，因此部门码表和职员表之间的联系为1：n，生成物理模型后，部门码表的关键字成为职员表的外码。

(2)职员表一角色码表：一个职员可以充当多个角色，一个角色可由多个职员充当，因此职员表和角色码表之间的联系为m：n，在物理模型中生成联系表——用户角色表，存储该账套中的用户角色对应关系。

(3)角色码表一模块码表：一个角色对多个模块拥有权限(如总账会计拥有总账系统的所有模块权限)，一个模块可以隶属多种角色(如多种角色都能进行凭证查询)，因此角色码表和模块码表之间的联系为m：n，在物理模型中生成联系表——角色权限表，存储该账套中的角色和模块的对应关系。

(4)银行码表一结算方式码表：一个银行可提供多种结算方式，一种结算方式可以为多家银行所用，因此银行码表和结算方式码表之间的联系为m：n，在物理模型中生成联系表——银行对账单表，存储该账套中的银行对账单信息。

四、账务处理子系统数据库设计评价

虽然本文设计的账务处理子系统数据库便于维护、节省空间、符合第三范式的要求，但其运行效率有一定欠缺，如我们在基于本数据库的账务处理系统中输入一张带有客户往来核算的凭证，此时需要更新的数据表包括凭证主表、凭证明细表及往来核算表；而在用友U8中，因为所有的辅助核算信息均处于“凭证及明细账”表中，因此录人凭证后仅在该表中添加记录。表1和表2～表4分别表示在u8和本文设计的账务处理子系统数据库中录入以下凭证时，数据库相应表中的记录形式。

凭证：借：应收账款——甲公司585 000

贷：主营业务收入500 000

应交税费一应交增值税(销项税额)

85000

从表1和表2～表4中我们很容易看出，u8的数据库设计中，将凭证主表和凭证明细表放在一起，而且将所有辅助核算信息也放在“凭证和明细账”表中，录入该销售凭证时，大量字段空白，造成存储空间的一定浪费，但由于其所有凭证信息均存储于一个表中，因此添加、修改凭证及凭证查询等运行效率比较高；而本文中的账务处理系统数据库设计仅一张凭证就比u8的数据存储少62(=86 24)个字段，可节约大量存储空间；若考虑字段长度及大量凭证，则可大大减少数据库的存储空间。

数据库的设计方案并不唯一，希望本文的账务子系统数据库设计能够为广大财务软件的分析人员和设计人员提供借鉴，在使我国的财务软件功能不断强大的同时，也能不断提高存储空间的利用效率。

主要参考文献

[1]刘梅玲，朱学义，黄岩CASE工具在电算化会计实验教学中的应用[J]，中国管理信息化。2008(11)

[2]陈旭，毛华杨，会计信息系统分析、设计与开发[M]，北京：清华大学出版社，2006

[3]刘自伟管理信息系统开发技术[M]，武汉：武汉理工大学出版社，2003