財務軟件核心數據庫設計探析

[摘 要]本文是繼“財務軟件數據庫設計探析——賬務處理子系統”和“財務軟件數據庫設計探析——固定資產管理子系統”之后，又一篇描述財務軟件核心數據庫設計的文章。本文借助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，在物理模型中生成聯系表憑證明細表，以憑證中的每行分錄為一條記錄?？颇勘砼c其他表(科目類型碼表、科目性質碼表)之間的聯系見賬務處理子系統，此處略。

(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.