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

[摘要]本文利用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