社會保險財務管理信息系統的設計與實現

摘 要：社會保險基金財務系統，實現了社會保險基金財務的會計電算化，建成了一個實用、規范的系統，實現對勞動保障基金財務的管理，形成有效的基金監控體系，建成與社會保險業務系統無縫銜接，信息完全共享的財務系統。

關鍵詞：財務管理系統 社會保險管理信息系統 無縫銜接 信息完全共享

中圖分類號：F842.6 文獻標識碼：A 文章編號：1672-3791（2012）12（a）-0248-05

1 社會保險業務的現狀和信息系統的目的

社會保險制度是我國社會保障體系的重要組成部分，是我國經濟發展、社會穩定、人民安居樂業的重要保障制度。隨著社會保險制度改革的深入，城鄉居民生活水平的不斷提高，和人們保險意識的增強，社會保險的業務量呈現急劇增長的趨勢。建立社會保險信息系統可以大大提高工作效率，輕松應對日益增長的保險業務量，更好的為社會服務，更可為科學決策提供依據。

加強社保財務信息系統的建設，意義十分重大，財務信息系統是決定社保事業能否健康發展，以及如何發展的關鍵一環。這是因為，社保財務信息系統是社保體系的重要組成部分，是社保業務系統的主要技術支持，而建設一個完善的、運行良好的社保財務信息系統需要從資金到技術等各方面的投入。

1.1 社保財務信息系統的業務基礎

社保財務信息系統的業務基礎是社保財務會計核算，它包括五方面的內容：一是會計核算主體是社保基金，而不是經辦社保機構。會計核算的這一特點是由社保基金的性質所決定的，表明社保基金既不屬于政府，也不屬于社保經辦機構，而是屬于全體參保人員；二是社保基金的安全管理及保障支付能力順理成章的成為政府和社會各界關注的焦點；三是社保財務會計工作首先要對所有參保人負責；四是社保財務會計信息必須具備開放性；五是社保財務會計核算的對象是海量的數據。由此決定了社保財務信息系統的建設，首先必須做到：明細核算到個人賬戶（養老保險和醫療保險）的收入、支出、結余信息；滿足參保人繳費情況、待遇享受等情況的查詢需要；安全、快捷、甚至實時的處理海量數據；隨時為政府部門制定社保政策提供預測、決策支持；接受各方監督社保會計核算的這些要求，決定了社保財務信息系統不能是一個信息的孤島，而應是一個綜合化和集成化的支持預測、決策的信息化管理系統。

1.2 社保財務信息系統的主要內容

在網絡化的條件下，社保財務信息系統與業務信息管理系統之間實現無縫連接、資源共享、互相支持、互相監督的一體化管理；通過外部接口，收發和處理外部數據，形成一個綜合化、集成化的信息化管理系統，從而為決策管理提供支持。

（1）實現與業務系統無縫連接、數據共享和標準統一。在網絡運行環境下，財務信息系統不應是一個封閉的信息孤島，而應與業務系統有著緊密關系。二者通過共用一個中心數據庫，實現無縫連接、數據共享及標準統一。

（2）與外部關聯單位實現電子數據交換。社保基金財務管理的全過程涉及財政部門、勞動保障部門及其經辦機構，以及稅務機關、銀行、郵政、醫院等眾多部門。不但數據處理的環節眾多，而且數據量十分龐大。在社保事業不斷發展，數據不斷增加的情況下，必須實現與外部關聯單位的電子數據交換。其中，關鍵的一環就是在社保管理部門的協調下，制定統一的數據格式和數據交換標準。至于電子數據交換的方式可視具體條件進行。例如，醫療保險的個人賬戶及時的實賬注資，社會保險、失業保險及時的實賬計算等都需要時實、分布式處理。

（3）實現業務系統支持和監督。加強內控管理是基金管理監督機制的基礎環節，各級社保經辦機構作為基金收支管理的主體，必須有健全的規章制度和監督約束機制，其中重要的一點就是在機構內部實現財務和業務相聯通。內控制度實施的重點、難點在于如何實現財務會計的實收實付金額、到賬標識、到賬時間與業務經辦部門應收應付金額、到賬標識、到賬時間保持一致，防止出現重復，甚至虛假收入和待遇支付的情況發生。

通過常設會計記賬憑證金額與業務數據應收、應付的唯一性的確認，可以堵塞收、支業務的漏洞，實現嚴格的系統內部控制。一方面，財務信息系統在進行應收、應付數據到賬確認處理時，直接自動生成常設會計記賬憑證。另一方面，由紙質會計原始憑證生成電子化會計原始憑證。即，凡是涉及基金正常收付（指有業務應收、應付臺賬）的會計記賬憑證，都必須附有一張電子原始憑證，并能夠在電腦中直接詳細查詢到組成該張會計記賬憑證的所有明細資料，而且這些資料是電腦直接在共享數據庫取數生成，沒有人工介入。因此，如果會計主管要審核某張會計記賬憑證金額的真實性，只要點擊出該張會計記賬憑證的電子原始憑證查看便可辨別出來。再一方面，會計記賬的信息也會同時反饋到共享數據庫中，業務部門可以看到會計部門在何時做實收實付處理和進行會計核算，或者收付不成功的原因，并對會計部門的處理結果進行監督。

2 開發環境和開發工具簡介

用ORACLE系統提供的軟件工具開發的社會保險信息系統是社會保險行業整體信息系統，承擔著社會保險機構的業務處理，內部管理和社會服務等功能。

目前大多數社會保險信息系統的建設都在起步階段，因此，正確的選擇設計原則和整體架構對整個系統的成功實施和未來發展都是至關重要的。

本系統的數據庫服務器是ORACLE 11G企業版，操作系統為AIX，采用ORACLE 11G技術建立數據庫，使用基于ORACLE數據庫的專用開發工具Developer/2000 Forms Designer技術建立與ORACLE數據源的鏈接，并且實現了財務管理系統的管理功能。

Developer/2000 Forms Designer是ORACLE系統提供的軟件開發工具，是為程序員提供用來開發基于表格的應用軟件的一個通用軟件生成工具。它采用原型法為開發方法，采用軟件自動生成技術、重用技術、動態定義技術等當代計算機軟件發展的高新技術。

ORACLE Forms 是Developer/2000 R2.0的主要產品，也是最復雜的一個開發工具，利用form可以開發出基于Form的Client/Server應用系統。

Form是一個應用界面，是將數據以動態表格的形式顯示在屏幕上，通過這個界面用戶可以和數據庫進行交互，完成對數據庫中數據的插入、更新、刪除。

在Form中，還可以進行Form之間的集成，設計出菜單以及畫布、窗口、標簽等，構成復雜的應用系統。Form應用包含的對象如下。

Form：是由相關Block（數據塊）組成的集合，每個Block可與數據庫相連接；

Block：所有Item（數據項）都包含在一個Block中，數據塊有基表塊和控制塊；

Item：是界面對象，Item邏輯的組成了Block。

所以，Form是Block和Item的集合。

從以上分析可以知道，Form是Block組成，Block由 Item組成，而Item還有下一層，就是觸發器（Trigger），這是項級觸發器。此外，Block有塊級觸發器，Form有表格級觸發器。組成一個Form往往有多個Block，而Block中又包含多個Item。

通過“菜單選擇”和“表格填寫”的用戶界面使你可迅速的開發出基于表格的錄入、查詢、修改等等操作的應用軟件。它所特有的非過程化方法使得你能非常高效的構造應用“原型”并可在“原則”上對應用軟件進行優化。你的設計重點是放在“原型設計”上，而不是“編程”上。當“原型設計”完成后，應用軟件的開發便基本告成。

Form不同于其他開發工具可以把好多功能集中在一個模塊中，在Form中一個功能使用一個模塊，也就是可以生成一個執行文件，到最后運用菜單技術把所有的執行文件上傳到總的運行環境。Form開發的基金財務子系統能夠和業務很好的結合起來，可以從業務通用接口中取得數據進行財務處理然后在返回業務接口，使財務系統與財務系統無縫銜接。

3 社會保險財務管理系統基金財務子系統總體規劃

3.1 社保信息系統設計原則

社會保險行業在機構設置上屬于的域分布式，在業務處理上屬于典型的聯機事務處理（OLTP）類型，具有與金融行業類似的特征，借鑒國內外金融、保險系統的發展思路和經驗、社保信息系統的建設應當遵守以下幾個設計原則。

（1）堅持標準。要堅持標準，一個含義是堅持技術標準和潮流，這樣使得系統開放靈活，從而延長了生命周期，同時具有堅實的繼續開發的基礎；另一個含義是要采納行業通行的業務模式和業務處理方法。（2）采用開放技術。開放技術是業界的主流技術，采用開放式系統平臺成為社會保險信息系統的開發商、集成商和用戶的共識。（3）高可靠性與可用性。由于社保業務的關鍵性，社保信息系統對可靠性有著很高的要求。一方面要強調整個系統高可靠性，確保在意外情況故障或重負載情況下系統的穩定性，一方面要保證在業務高峰期間的系統響應能力。整個系統應采用多網備份、多機備份結構，在經濟條件允許的條件下，應當考慮容災中心的建設。（4）高擴展能力。在發展迅速的IT領域，應用環境，系統的硬件或軟件都會不斷的加以更新，因此，系統的可擴充性以及前后兼容一致性好壞決定著系統的發展步伐。（5）安全與管理。如果想管理好并利用好計算機系統和網絡的資源，就必須建立一個安全實用、全面的計算機網絡管理系統。（6）服務與支持保障。

根據財務管理系統的功能需求可以把財務管理系統大致分為幾個模塊：財務初始化設置管理、基金支付管理、帳務處理管理、出納管理、財務綜合查詢管理、基金報表管理。

3.2 需求分析

（1）需求描述與分析。設計一個性能良好的數據庫系統，明確應用環境對系統的要求是首要的和最基本的。特別是數據應用非常廣泛，非常復雜，要是事先沒有對信息進行充分和細致的分析，這種設計就很難取得成功。所要開發的系統是江寧區的社會保險財務管理系統，對于社會保險，應該與國家政策緊密相結合，系統要具有可擴展性，這樣對日后的升級和增加功能減少了不必要的開銷。通過需求分析階段對財務管理系統的整個應用情況作全面的、詳細的調查，確定財務管理的目標，收集支持系統總的設計目標的基礎數據和對這些數據的要求，確定用戶的需求，并把這些寫成用戶和數據庫設計者都能夠接受的文檔。

（2）需求分析的步驟。需求分析大致可分為三步來完成，即需求信息的收集、分析整理和評審通過。

①需求信息的收集。

需求信息的收集又稱為系統調查。為了充分的了解用戶可能提出的要求，在調查研究之前，要做好充分的準備工作，要了解調查的目的、調查的內容和調查的方式。

調查的目的：首先，要了解組織的機構設置，主要管理活動和職能。其次，要確定組織的目標，大致管理流程和任務范圍劃分。項目組接受江寧區勞動局委托在江寧區原來的社會保險財務系統上進行升級和開發，因此，財務管理系統主要是通過對現有的財務管理系統進行考察、研究。并且通過和財務管理以及操作人員交流來完善管理功能。

調查的內容：外部要求：信息的性質，響應的時間、頻度和如何發生的規則，以及財務管理的要求，安全性及完整性要求。管理的現狀：即財務管理信息的種類，信息流程，信息的處理方式，各種流程工作過程。組織機構：了解財務管理機構的作用、現狀、存在的問題，及是否適應計算機管理。

調查方式：在系統開發的需求分析階段調研小組通過對財務管理人員的訪問、交談可獲得財務管理高層的、內部的管理需求，以及財務管理的管理目標、變化趨勢和長遠規劃的有關信息。并且，還可通過現場具體實踐，對財務管理系統有一個深刻得了解。

②需求信息的分析整理。

要想把收集到的信息（如文件、圖表、票據、筆記）轉化為下一階段設計工作可用的形式信息，必須對需求信息做分析整理的工作。

社會保險財務管理系統基金財務子系統的數據流圖如圖1所示。

分析結果的描述：除了數據流圖以外，還要用一些規范表格進行補充描述。近年來許多設計輔助工具的出現，已使設計人員可利用計算機的數據字典和需求分析語言來進行這一步工作。為了清楚的描述需求分析的結果，分類編寫，以供設計階段使用，并可作為驗收的依據。數據項清單：列出每個數據項的名稱、含義、來源、類型和長度等。管理活動清單：列出最基本的管理任務，包括任務的定義、操作類型、執行頻度、所屬部門及涉及的數據項等。

評審通過：評審的目的在于確認某一階段的任務是否全部完成，以避免重大的疏漏或錯誤。財務管理數據庫的評審要保證評審工作的客觀性和質量。評審常常導致設計過程的回溯與反復，即需要根據評審意見修改所提交的階段設計成果，有時甚至要回溯到前面的某一階段，進行部分乃至重新設計，然后在重新評審，直至達到全部財務管理數據庫系統的預期目標為止。

3.3 概念設計

3.3.1 概念設計的必要性

在概念設計階段中，設計人員從用戶的角度看待數據及處理要求和約束，產生一個反映用戶觀點的概念模式。然后再把概念模式轉化成邏輯模式。將概念設計從設計過程中獨立開來，至少有以下幾個好處。

各階段的任務相對單一化，設計復雜程度大大降低，便于組織管理。

不受特定的DBMS所限制，也獨立存儲安排和效率方面的考慮因而比邏輯模式更穩妥。

概念模式不含具體的DBMS所附加的技術細節，更容易為用戶所理解，因而才有可能準確的反映用戶的信息需求。

3.3.2 概念模型

概念模型是表達概念設計結果的工具。

社會保險財務管理系統基金財務子系統的概念模型圖如圖2所示。

3.3.3 概念設計的主要步驟

概念設計的任務一般可分為三步來完成：進行數據抽象，設計局部概念模式；將局部概念模式綜合成全局概念模式；評審。

（1）進行數據抽象，設計局部概念模式。局部用戶的信息需求是構造全局概念模式的基礎。因此，需要先從個別用戶的需求出發，為每個用戶或每個對數據的觀點與使用方式相似的用戶建立一個相應的局部概念結構。在建立局部概念結構時，要對需求分析的結果進行細化、補充和修改，如有的數據項要分為若干子項，有的數據的定義要重新核實等。

設計概念結構時，常用的數據抽象方法是“聚集”和“概念”。聚集是將若干對象和它們之間的聯系組合成一個新對象。概括是將一組具有某些共同特性的對象合并成更高一層意義上的對象。

（2）將局部概念模式綜合成全局概念模式。綜合各局部概念結構就可得到反映所有用戶需求的全局概念結構。在綜合過程中，主要處理各局部模式對各種對象定義的不一致問題，包括同名異議、異名同義和同一事物再不同模式中被抽象為不同類型的對象等問題。把各個局部結構合并，還會產生冗余問題，或導致對信息需求的再調整與分析，以確定確切的含義。

（3）評審。消除了所有沖突后，就可把全局結構提交評審。評審分為用戶評審與DBA及應用開發人員評審兩部分。用戶評審的重點放在確認全局概念模式是否準確完整的反映了用戶的信息需求和現實世界事物的屬性間的固有聯系；DBA和應用開發人員評審則側重于確認全局結構是否完整，各種成分劃分是否合理，是否存在不一致性，以及文擋是否齊全等。

3.4 邏輯設計

邏輯設計的結果是得到一個與DBMS無關的概念模型。邏輯設計的目的是把概念設計階段設計的基本ER圖轉換為與選用的具體機器上的DBMS所支持的數據模型相符合的邏輯結構。這些模式在功能上、完整性和一致性約束及數據庫的可擴充性等方面均應滿足用戶的要求。

3.4.1 邏輯設計環境

在邏輯設計階段主要輸入下列信息。

（1）獨立于DBMS的概念模式：這是概念設計階段產生的所有局部和全局概念模式。（2）處理需求：需求分析階段產生的業務活動分析結果。這里包括數據庫的規模和應用頻率，用戶或用戶集團的需求。（3）約束條件：即完整性、一致性、安全性要求及響應時間要求等等。（4）DBMS特性：即特定的所支持的模式、程序語法的形式規則。

3.4.2 邏輯設計的步驟

邏輯設計主要是把概念模式轉換成DBMS能處理的模式。轉換過程中要對模式進行評價和性能測試，以便獲得較好的模式設計。

（1）初始模式的形成。這一步是形成初始的DBMS模式。根據概念模式以及DBMS的記錄類型特點，將模式的實體類型或聯系類型轉換成記錄類型，在比較復雜的情況下，實體可能分裂或合并成新的記錄類型。

（2）應用程序設計梗概。在設計完整的應用程序之前，先設計出應用程序的草圖，對每個應用程序設計出數據存取功能的梗概，提供程序上的邏輯接口。

（3）模式評價。這一步的工作就是對數據庫模式進行評價。評價數據庫結構的方法通常有定量分析和性能測量等方法。

（4）修正模式。修正模式的目的是為了使模式適應信息的不同表示。此時，可利用DBMS的性能，如索引或散列功能。但數據庫的信息內容不能修改。如果信息內容不修改，模式就不能進一步求精，那么就要停止設計，返回概念設計或分析階段重新設計。

3.5 物理設計

3.5.1 物理設計的步驟

物理設計首先要確定數據庫的物理結構，然后，對物理結構進行評價。如果評價結果滿足原設計要求，則轉向物理實施，否則，就從新設計或修改物理結構，有時甚至要返回邏輯設計階段修改數據模型。具體的說，物理設計可分為五步來完成，前三步涉及物理數據庫結構的設計，后兩步涉及到約束和具體的程序設計。

（1）存儲記錄結構設計。設計存儲記錄結構，包括記錄的組成、數據項的類型和長度，以及邏輯記錄到存儲記錄的映射。在設計存儲記錄結構中，邏輯數據庫結構并不改變，但可能要進行“記錄”分割工作。（2）確定數據存儲安排。從提高系統性能方面考慮，將存儲記錄作為一個整體合理的分配物理區域。利用記錄聚簇技術，在可能的情況下充分利用物理順序特點，將不同類型的記錄分配到物理群中去。（3）訪問方法的設計。訪問方法是給存儲在物理設備上的數據提供存儲和檢索機構兩部分。存儲結構限定了可能訪問的路徑和存儲記錄；檢索機構定義了每個應用的訪問路徑，但不涉及存儲結構的設計和設備分配。數據庫系統通常是多用戶共享系統，對同一數據存儲，要建立多條路徑，才能滿足多用戶的多種應用要求。（4）程序設計。邏輯數據庫結構確定以后，應用程序設計就可隨著開始。從理論上說，數據庫的物理數據獨立性的目的是消除由于物理結構設計決策而引起的對應用程序的修改。但是，物理數據獨立性未得到保證時，可能會發生對程序的修改。

3.5.2 物理設計的環境和性能

數據庫的物理設計是對邏輯數據庫結構進一步求精的過程。從邏輯設計階段得到的邏輯數據庫結構確定了物理設計的工作框架，在物理設計階段，一般不必對邏輯結構作修改。如果在物理設計中查出了重大的失誤，或者處理需求在某些方面有重大改變，那么必須返回到邏輯設計階段，作必要的修改。

物理設計階段的輸出是物理數據庫結構說明書，包括存儲記錄格式、存儲記錄位置分布及訪問方法。它能滿足所有的操作需求并給出對硬件、軟件系統的約束。

在設計過程中，效率問題只能在各種約束得到滿足且獲得可行方案之后進行。

在物理設計過程中，不能把單個性能作為唯一標準，而要對一組性能進行評價、需要對時間、空間、效率、維護開銷和各種用戶要求進行權衡。我們假定數據庫系統性能用術語“開銷”描述。在不同的時候，開銷可由時間、空間及貨幣值給出。

在數據庫系統生存期中，生存期的總開銷可表示為下列幾項：規劃開銷；設計開銷；實現與測試開銷；操作開銷。

數據庫設計者在設計數據庫時應該知道物理數據庫在實現時，用戶的使用和計算機資源的操作開銷是多少，這些是評價數據庫設計優劣的重要標準之一。

3.6 數據庫的建立

（1）建庫。

數據庫的名稱和標識符要么由初始化參數DB_NAME指定的，要么由CREATE DATABASE語句指定的。在ORACLE系統中，可以使用兩種方法創建數據庫。一種是使用DATABASECONFIGURATION ASSISTANT向導工具，另一種方法是使用CREATEDATABASE語句。前者是基于JAVA的圖形工具，可以在任何平臺上使用，并且是創建數據庫的最簡單的方法。后者是PL/SQL語句，它可以最靈活的創建數據庫。如果使用ORACLE DATEBASE CONFIGURATION ASSISTANT向導來創建數據庫，可以按照提示一步步完成即可；如果希望使用PL/SQL語句。那么可以使用CREATE DATABASE語句。數據庫創建完成以后，除了創建數據庫的各種文件之外，ORACLE服務器還在數據庫的文件內創建了結構，如數據字典、動態的性能表等。

（2）建立表空間。

如果是一個比較小的數據庫，那么該數據庫可能只需要一個SYSTEM表空間。但是，ORACLE系統建議用戶創建多個表空間來存儲用戶的數據、索引、回退段和臨時段，并且把這些存儲的內容與數據字典分開。這樣，在數據庫管理操作中就可以更加靈活，并且可以降低數據字典對象和方案對象在同一個數據文件中掙搶空間。

表空間是指組成ORACLE數據庫的邏輯空間區域。每一個表空間都由一個或多個操作系統文件構成，這些操作系統文件稱為數據文件。管理表空間就是創建表空間、設置表空間的特性、修改表空間的大小和管理數據文件等。

在使用表空間之前，必須創建表空間。可以使用兩種方法來創建表空間。一種方法是使用DBA STUDIO的存儲管理器工具，另一種方法是使用PL/SQL語句。前一種方法比較簡單、直觀，容易掌握，適合于初學者用戶使用。后一種方法比較靈活，語法清晰，適用于有經驗的數據庫用戶。

（3）建立用戶。

可以有兩種方法創建用戶，一種方法是從DBA Studio工具中啟動Oracle Security Manager工具，另一種方法是使用CREATE USER語句。

Create user bysb identified by bysb default tablespace by sb_ts；

用戶建立以后要對用戶進行授權。

grant connect，dba to bysb；

（4）創建表。

在ORACLE系統中，表是數據庫中的主要對象，是真正存儲各種各樣信息的對象。從持久時間和使用是否廣泛來看，表可以分為永久性表和臨時性表。數據庫中的數據一般存儲在永久性的表中。通常所說的數據庫表，就是永久性表。在永久性表創建之后，這些表就存儲在數據庫文件中，并且一直存在，直到它們被刪除為止。在數據庫中的表可以被數據庫中的用戶使用，當然，這些用戶應該具有使用表的相應的權限。用戶還可以創建臨時表，臨時表的使用與永久表類似，只是臨時表存儲在內存中，當它們不再被使用時，會被自動刪除。表具有這些特征：代表實體、表名在數據庫中是唯一的、由行和列組成、行的順序是任意的、列的順序是任意的、列名在表中是唯一的。列名在一個表中的唯一性是由ORACLE系統強制實現的，即在一個表中，應該沒有相同的兩行同時出現。在一個數據庫中，對某一個所有者來說，表名必須是唯一的，這是由系統強制性實現的，但是，如果為表指定了不同的用戶，那么可以創建多個具有相同名稱的表。使用這些表時，區分這些表的方法是在表名前面加上所有者名稱作為前綴。在ORACLE系統中，即可以使用DBA Studio工具來創建表，也可以使用創建表的向導工具來創建，還可以使用CREATE TABLE 語句來創建表。

3.7 數據庫的實現（表1）

3.8 財務管理系統其它設計工作

（1）財務管理數據庫的重新組織設計。對財務管理數據庫的概念模式，邏輯結構或物理結構的改變稱作重新組織，其中改變概念模式或邏輯結構又稱為重新構造，改變物理結構則稱為重新格式化。重新組織通常是由于環境、需求的變化或性能原因而進行的，如信息定義的改變，增加新的數據類型，對原有的數據提出了新的使用要求，改用具有不同物理特性的新存儲設備以及數據庫性能下降等都要求進行數據庫重新組織。（2）安全性考慮。在設計財務管理應用程序時，要考慮系統安全性問題，例如所設置密碼的保密程度，也可以為不同級別的用戶建立不同的view。（3）事物控制。為保證多用戶環境中數據的完整性和一致性，許多數據庫管理系統都支持事物概念。事物控制通常有系統控制和人工控制兩種方式。系統控制通常都是以一個語句為單位。人工控制則以事物的開始和結束語句顯示實現。一般有經驗的應用開發人員采用人工控制方式。人工控制方式用幾條完成同一目的語句構成一個事物，可減少一個語句所導致的較多的系統開銷。

3.9 財務管理系統調試

財務管理數據庫建立后，應裝入大量記錄，進入試運行階段。

業務界面包括對繳納費用人員記錄的添加、刪除、修改、查詢等功能的調試。最主要的是增加模塊的調試。

財務界面包括對憑證庫的查詢、修改、打印情況等功能的調試。最主要的也是查詢模塊的調試。

用戶的反饋信息也非常重要，我們在自己調試的同時也要相應的指導用戶對相關模塊的測試，定期的進行交流，對于測試中的問題及時處理，以避免不必要的開銷。

在前一階段，雖然也作了性能預測，但是僅僅估計了性能估計，且在估計過程中，我們做了許多簡化和假設，忽略了許多次要因素，因而估計是粗糙的，并可能失真。在試運行階段，必須進行實際測量和評價，測試數據盡可能覆蓋現實世界的各種情況。

如果實際測試結果不符合設計目標，則需返回物理設計階段，修改參數。有時也許還需要返回邏輯設計階段，調整邏輯階段。

3.10 財務管理系統運行與維護

財務管理數據庫正式投入運行標志著數據庫運行與維護的開始，但并不標志著財務管理數據庫設計工作的結束。財務管理數據庫維護工作不僅僅是維持其正常運行，而是設計工作的繼續和提高。

運行維護階段的主要工作如下。

（1）數據庫的安全性與完整性控制及系統的轉儲和恢復。按照系統提供的安全規范和故障恢復規范，經常檢查系統安全性是否受到侵犯，及時調整授權，實施系統轉儲與后備，發生故障后及時恢復。（2）性能的監督、分析與改進。利用系統提供的性能分析工具，經常對數據庫的存儲空間及響應時間進行分析、評價，并結合用戶意見確定改進措施，實施重新構造或重新格式化。（3）增加新功能。根據用戶的意見，在不損害原系統功能和性能的情況下，對原有功能進行擴充。（4）發現錯誤，修改錯誤。及時發現系統運行中的錯誤，并修改錯誤，保證系統正常運行。由于數據庫應用環境發生變化，需要增加新的功能或實體，實體與實體的聯系也會發生相應的變化，原設計不能很好的滿足新的需求，不得不適當調整數據庫的模式和內模式。當然，數據庫重新構造的程序功能是有限的，只能作部分的修改和調整，若應用變化太大，重新構造也無能為力了，則表明原數據庫應用系統生存期的結束，應該重新設計數據庫，開始一個新的數據庫應用系統的設計周期。

參考文獻

[1]（美）laors bo vanting.oracle企業管理器基礎教程[M].2版.機械工業出版社.

[2] 藤永昌，孟凡民.oracle developer/2000 r2.0開發技巧與應用教程[M].2版.北京：清華大學出版社，2002：55-73.

[3]勞動和社會保障部信息中心.勞動和社會保障信息化建設文件資料集（2000～2003）.北京：中國勞動社會出版社，2003：43-46.

[4]趙伯山.Oracle 9i中文版實用培訓教程.北京：清華大學出版社，2001：103-151.

[5]陳思國，殷巍.SQL*FORM與軟件開發的研究[J].計算機應用研究，1995（5）：45-46.