1、內部管理系統詳細設計 方案項目開發背景為了提高公司內部管理的效率，所以需要編制一套完整的用于公司內部管理的系統。這樣一個系統可以在整個公 司范圍內使用，做到了公司資源的整合與共享。項目的可行性研究1. 技術方面：整個系統屬于一個規模比較大的MIS系統。盡管其在組織關系上存在著很大的復雜性，繁瑣性，不確定 性，但是就整個系統的技術構成上來看，它還是屬于一個數據庫應用類的系統。其基本操作還是對存在數據庫進行 添加、刪除、查找、編輯等。所以就單純的數據庫應用來看，暫不存在太大的技術問題。2. 經濟方而：由于系統對公司的正常運行的影響是相當大的，所以必須要設置單獨的服務器來運行這個系統。又考慮到所 有

2、計算機硬件軟件都是存在出錯可能的（具體到這個系統，由于其需要不間斷的運行，所以其出錯的可能就會變得 更大），因此整個系統應該考慮使用雙機熱備份技術。使用兩臺服務器同時運行，一個為主一個作備份，這樣可以 避免服務器故障對整個系統的影響。又考慮到這個系統是為公司內部服務的，而且數據庫設置和調試時候都必須要 直接使用服務器，所以應該將服務器設置在公司內部。縱觀整個系統需要的硬件，我們認為整個項目的投資將可能 是比較巨大的。這方面，提請公司再作詳細討論。3. 法律方而：整個系統由于是自行開發，自行使用，所以系統本身不存在法律上的版權爭議。在服務器軟件方面，應 該使用正版軟件，因為整個系統盡管是開發給內

3、部使用，但它畢竟很多部分還是要依靠Internet的，一旦服務器連接 到Internet上，它的操作系統可能會被Microsoft跟蹤，如果不是 正版軟件，將不得不面臨民事訴訟的風險。4. 目前存在的問題：目前我們覺得最大的問題仍然是數據庫訪問方式上的問題。和一般的MIS系統不同，我們而臨著更廣泛范 圍內的數據庫訪問。這個范圍已經不可能用局域網解決了，但一旦使用Internet網，數據傳輸的有效性和安全 性就會成為嚴重的問題。現在將三種可能數據訪問的方式列舉如下，并逐一作分析：a.使用純單機版的數據庫系 統這是最簡單的數據庫訪問方式。采用這種方式不涉及網絡傳輸，所以無論在哪個部門，也不管其上網

4、設施是如何 的，總能采用這種方法的。采用這種系統后，如果要實現數據同步，必須定期將數據庫全部上傳（注意：這里應 該是上傳整個數據庫，因為采用這種方式操作的系統，它上傳的時間間隔一般是比較大的，如果記錄哪些記錄是更 新的，在實際同步時候，將花費很多時間作整個更新記錄的比對，在記錄量增大時候，這個檢測的時間也會急劇 增加，反而增加了處理時間），服務器在收到整個數據庫后，在服務器端運行一個特殊的軟件，用12總部服務器這段傳輸可以采用任何傳輸方式,包括FTP, Email于數據的同步。然后將處理后的數據庫放在一個特定的區域，客戶端可以將處理后的數據庫收下來，以實現數 據庫同步。整個系統采用的傳輸示意圖

5、如下（僅以市場部為例）：總部服務器上應該運行特定軟件用于數據同步，此過程可能需要人工干預。b. 采用純網絡數據庫的結構：采用這個結構從理想的角度來看，是最適合這個系統的。因為它具有最好的實時性，可以將當前獲得的數據立即傳輸出去，這樣其他部門也就立即可以得知目前的業務情況。而且采用這個結構，從數據庫應用角度來看，對網絡底層的傳輸情況不需要有太多的了解（這部分由SQLServer提供 的網絡傳輸協議保證）。但是就公司目前各市場部上網情況來看，由于 很多市場部采用的仍然是Modem和 ISDN,不能24小時在線，因此再不對目前各市場部上網設備改造的情況下，很難使用這種結構。這種結構還有一個問題是它很

6、大程度上依賴于中心數據庫，對中心數據庫可靠性和穩定性的要求相當高。這種結構的示意圖如下（以市場部為例）:市場部市場部市場部市場部C.采用本地數據庫和網絡數據庫同時使用的結構X這是這個系統最有可能采用的數據庫結構。它的特點是平時數據存儲在本地數據庫，以天為單位，讓本 地數據庫和總部的一個共享數據庫進行交互，以實現數據的同步。這種方式的優點是數據因為在本地和網絡 數據庫上共存，所以可靠性是比較高的。而且就Modem,ISDN和寬帶共存的情況下使用這種結構也是比較現實的。它的缺點是：在每日用于同步的數據量大的情況下 是無法使用的，另外，即使每天用于同步的數據量并不是很大，但是木地數據庫或者網絡共享數

7、據庫的存儲 量已經很大，這樣再搜索用于需要同步的數據的時間也將成倍增加。系統在剛投入使用時候可能速度比較 快，但是存儲量達到一定程序后，系統運行速度將會急劇減慢。（根據實驗，當數據記錄條數達到5萬條以 上時，完整的數據庫搜索花費的時間會很長很長），而在這種系統結構下，為了保持兩者數據庫的完全同步，可能要反復搜索數據庫。 此段時間的開銷是相當大的。除此之外，這個結構最大的問題是：如何保證數據的完整同步。因為諸如Modem等上網設備，其傳輸過程極易由于外界干擾或者線路傳輸速率的突變造成傳輸中斷。重傳這些數據可能會造成數 據的重復。（比如經過檢測，這次需要上傳10條記錄，現在客戶端開始上傳，上傳一半

8、Modem斷線了，所 以實際只傳了五條。客戶端檢測到這一錯誤，開始重傳，但實際上盡管斷線仍然有五條記錄是成功傳送的， 重傳全部必定造成重復，但是要很準確的定位 具體是在那條中斷是相當困難的。這和網絡傳輸協議里錯誤檢 測是類似的）采用這個結構的示意圖如下：介于以上原因，我們認為選用何種數據庫結構需要進行進一步研究。可以作一下實驗，比如使用各種現有的上網設備來進行一下數據庫連接。測試在不同的數量情況下，對性能的影響。特別要對Modem連接SQLServer作更多的 實驗。因為其連接速度比較慢，必須要對數據庫連接超時時間作調整。（此值過小或者過大都會對性能造成影響。過小的值這里的結構和示意圖a）中的

9、結構看上去有些相似。但其原理是完全不同的。圖a）中，需要上傳的是完整的數據庫，它依靠運行在服務器端的程序對數據進行整理以達到同步的目的。而這個結構中，實際上并不存在一個文件上傳的過程，它是依靠數據庫訪問接口 來直接實現數據交互的。數據庫訪問接口屏蔽了很多網絡的細節。在這個結構中，在服務器上不需要再單獨運行管理程序來實現數據同步。可能會使使用Modem的機器無法連 上SQLServer ,過大的值在確實發生錯誤時候，需過很多時間才能檢測到此錯誤）系統的大致模塊劃分由于整個系統最后使用的結構還沒有最后確定，所以這里的模塊劃分只是一個大致的劃分。在經過實驗，確定使用 哪種數據庫結構后，需要對此部分進

10、行進一步修正。1 .市場部從最大的方面市場部管理系統可以劃分成業務管理、人事管理、財務管理、數據統計與備份、系統設置等模塊。其中業務管理模塊包括事件記錄添加、事件記錄修改，事件記錄刪除、事件提醒等功能。這部分側重的是對客戶 服務的，它是以客戶為中心開展的。是整個系統數據的入口處。在人事管理和財務管理等模塊中，有很多數據是要依靠 業務管理模塊的。人事管理模塊指對分公司內部人員的管理，包括用工、退工、員工平時所領取資料、合同等其他憑證的管理與查 詢。這里要注意各種憑證領取時候的記錄；在憑證丟失時候的處理。這些憑 證都是由業務產生的，所以其與業務管理 模塊之間存在很多相互訪問的情況。由于存在這個特性

11、，所以必須要做好數據保護，以防止數據交叉訪問時候對原先 數據的破壞。財務管理模塊是用于市場部內部工資結算的。由于市場部工資很大部分是有業務員的業績決定的，所以其在很大 程度上也是依賴于業務管理模塊的。它就是根據業務管理模塊的統計結果，再利用一定的算法來計算業務員當月的工資 和市場部管理人員當月的工資。這部分繁瑣的地方在工資結算方法和各分公司之間算法的差異上，盡管可以設置一些 可選項，但如果差異過分懸殊則可能需要為有些分公司編寫單獨的處理模塊。數據統計功能依賴于業務管理模塊和財務管理模塊，它按照一定的時限生成各種業務報表供公司內部留存、上 交等。除了打卬出來的報告外，程序應該提供一定的界面供數據

12、查閱（不打卬）。備份是所有MIS系統都應該具備 的，盡管數據安全可靠存儲大部分應該由服務器來保證，但是程序中仍然應該具備數據備份功能，用于數據定時的 導入導處。或者與其他程序交互時候可以使用。系統設置模塊用于對程序進行初始設置。這部分應該盡量考慮到可擴展性。對于能夠進行設置的部分在此處應盡 量設置設置選項。當然，調整只能在一定范圍內進行，一般是數值上或者選項組合上的。由于系統設置對于系統的運行 是起全局影響的，所以再調整前要進行安全性驗證。整個市場部程序模塊示意圖如下:（本圖僅供參考）市場部管理程丿了;系統登陸模塊系統設置模塊業務管理模塊人事管理模塊財務管理模塊2注業務數據存取模塊人事數據存取

13、模塊財務數據存取模塊數據加密與備份模塊遠程數據同步模塊11r1 r這里一個粗的雙箭頭表示這些數據庫訪問之間將有頻繁的交互注：這里的資料票據管理模塊被放在 人事管理模塊下面了，主要是處于 以下考慮：資料票據總是由特定的 業務員領取的，它需要不斷的與人 事數據庫交互，放在人事里面可以減 少交叉訪問帶來的開銷。遠 程 數 據 庫 （運 行SQLServer的服務器）各模塊的功能解釋與數據表之間的對應關系:1. 系統登陸模塊：a. 含義解釋：用于市場部合法身份的驗證，使用加密密碼驗證方式。b 相關數據表：上層數據表仃）C.流程:d.其他說明：密碼信息應進行加密存貯。加密方式不用過于復朵，可以使用ASC

14、II碼移位變換的方法。2. 系統設置模塊：a. 含義解釋：系統設置模塊是對系統的一些運行參數進行調整。它可以分為兩部分，一是為了適應不同的網絡 傳輸而進行的機器系統參數設置，二是對本市場部的一些個性化經營方式進行的設置，它偏向于業務。比如說套餐 價格，限價等。這些數值都會有默認值，并且允許在運行時候，通過其他部分，比如財務管理，人事管理，業務管 理等操作界而里進行分別設置。但由于其代碼的重用性，這里保留了一個入口，可以對這些參數進行全而的調整， 這樣不用分別進入每一個界面調整了。這種調整方式通常只在程序第一次運行時候才需要。b. 相關數據表：市場部數據表仃)(2) (3) (16) (17)

15、(19) (20) (21)c. 其他說明：在具體設計時候，對有邏輯聯系的部分應結合在一起，使界面做到直觀，簡化，并且這些調整數值應該是要立即生效的，所以要采用直接的方式，不然如果需重啟程序甚至重啟windows才能生 效，那么會帶來很多麻煩。3 .事件添加模塊：a.含義解釋：事件添加模塊是整個系統運行的基礎。整個系統的業務數據都是由這里提供的。這里錄入的事件信息包含兩部分，一是業務相關客戶信息，二是業務信息本身。它同時也存在兩種可能性，一 是新客戶，這樣就要同時添加客戶信息與業務信息，二是老客戶新業務，此時只需要對業務信息進行增加就可 以了。但不管是何種方式，這里都提供了一個統計的入口一一從

16、查找客戶開始，以確定客戶信息是否存在。b.相關數據表：市場部數據表(1) ( 2) (3) (4) ( 5) (6) (7) (8)C. 流程：事件添加應該以客戶查詢作為整個事件添加的開始。以查詢結果作為添加或者編輯的依據。整個過程可以用以下流程表示：d.于第一次在我們這里開辦業務的客戶,其他說明：按照這個流程，對 需要同時錄入客戶資料以及事件(業務)資料，而對于老客戶來說,其客戶資料己經存在，所以只要錄入事件這樣比較符合軟件設計慣(業務)資料就可以了，但在錄入前應該將原先資料顯示一遍,例與用戶操作習慣。4 .事件查找編輯：a. 含義解釋：這一模塊實現了對現有事件的查找和對輸入有錯并且己經添加

17、的資料的編輯。查找分為兩種信息的 查找，一是客戶資料的查找，二是業務資料的查找。當然這兩種查找模式會有交叉，比如，查到某一客戶后， 希望查看這個客戶的所有我們對其開展的業務情況，或者，查到某一業務資料后，需要列出這個業務所對應的客戶資料，因此在設計時候，要考慮到這些方 面，在代碼重用和靈活性上要作好調整。另外此處的編輯是出于這樣一種考慮的，在有些數據輸入時候有錯, 但并沒有立即發現，隔了一段時間后，通過查找或者突然記起發現了這個錯誤，那么這里就要提供一個功能, 允許用戶修改原先的客戶資料或者業務資料。b. 相關數據庫：市場部數據表(1) (2) (3) (4) (5) ( 6) (7) (8)

18、 (9)c. 流程：/顯示提示，選擇查找內容是是是顯示提示否流程結束d.其他說明：這里的查找以及顯示流程應該是很清楚的，但要對編輯功能做一下說明。整個流程里而似乎沒 有出現編輯部分，我們的考慮是將編輯功能融合在顯示的時候，顯示的時候用戶就可以進行編輯，顯示界 面下面有一個修改確認按鈕，這樣用戶按下這個按鈕時候，編輯過程就完成了，這樣一個操作方式在其他工程里面已經被普遍采用了，經過幾個項目的考察與用戶那 里得到的反饋來看，這一操作方式被認為是最符合修改這一功能操作習慣的，而且也是最直觀的。對于程 序設計人員來看，它由于將顯示與編輯界面復用了，有效的控制了由于界面過多而帶來的混亂。5 .事件參數設

19、置：a. 含義解釋：通過這個模塊，各市場部可以設置一些關于業務有關的數據，包扌舌市場部能提供的業務，價 格，限價，套餐組合等。b. 相關數據庫：市場部數據庫(1) (2) (3)c. 其他說明：這個功能是整個系統設置功能的一部分。操作人員可以在這里調整業務有關的參數，也可以在一個總的設置里而調整這些數據，具體使用哪種方式，則由操作人員根據自己的習慣決定。6 事件跟蹤模塊a. 含義解釋：這個模塊主要用來跟蹤一筆業務的服務過程。我們可以用它來檢查業務所需資料是否收到，錢款是否收到，票據是否收到，贈品是否給出，合同是否簽訂，是否制作完成等諸如此類的信 息。相對于完整的事件查找而言，它更側重于服務的過

20、程，而不是單純的讓操作人員了解這個事件。事件查找模塊它只能進行一個事件的查找或者編輯，它不帶有對這個事件發展過程進行記錄的過程，而此處的記錄功能則顯得非常重要了。b. 相關數據表：市場部數據表仃)(2) (3) (4) (5) (6) (7) (8) (9) ( 9) (10) (11)上層數據表(2) (6)c. 流程：In put Clie1. 查看某一事件過程(資料，錢款收取情況)Input Client2. 記錄某一事件過程(資料，錢款收取情況)Some module details:DB Search Operat ing1d. 其他說明：總的來說，這個模塊的設置是可以讓操作人員方便

21、的了解到一個事件整個的進展情況(也就是說，它 不僅是業務那里的進展，也有制作的進展，業務員可以通過這里知道是否制作完成或者申請成功等消息)。7 .人事基本管理：a. 含義解釋：人事基本管理模塊包含了人事管理的一些常規操作，包括用工，調動，退工。其中用工，調動和一 般的人事管理系統很類似，但是退工部分，由于要處理資料票據的上交，所以有相當的復雜性。b. 相關數據表：市場部數據表(12) ( 13) (14) (15) (16) (17) (18) (19) ( 20) (21)c. 流程：1在這里引用它是因為如果出現部門d.其他說明：這部分相關數據表里而有幾張是財務部分的,那么的撤并，將牽涉到計

22、算底薪，提成時候部門見的差異(因為有可能有的部門要撤銷了, 財務提成或者底薪計算用到的數據庫就要進行同步更新)&部門參數設置a. 含義解釋：這個功能是比較簡單的。它設置的是某個分公司的部門名稱與編號。在系統第一次運行時候，會要求用戶錄入這些信息(也可能使用某些默認值)，但以后如果需要調整部門設置，可以在這里進行，也可以在總的系統設置里面進行。這個依據操作人員的習慣而定。但這里要強調一 個問題：部門的調整對于這個部門內所有人員來說都是有影響的。調整一個部門的信息，要對涉及這一調整的所有信息做更新，這點非常非常重要。不然很容易岀現系統的不一致。比如部門A被撤銷了，那么原先屬于部門A的所有成員信息就

23、要作同步調整，否則在讀取員工信息的時候，他們仍然指向A,這個數據顯然是無效的。同時，也要注意部門調整對計算工資部分數據的調整。b. 相關數據表：市場部數據表(12) (13) (14) ( 15) (16) (17) (18) (19) (20) (21) 9 資料票據管理a. 含義解釋：這里在資料票據管理指業務員領取資料，發票，合同時候的登記，以及為為了避免遺失而做日常定期檢 查提供依據(它可以指岀哪個業務員何時領取了何種物品票據，是否用掉，如果用掉是用到哪里去了)b. 相關數據庫：市場部數據表(5) (6) ( 7) (9) (10) (11) (12) (13) (14) (15)c.

24、流程描述：因為這個過程很難用流程圖來做完整表述，所以，改用文字表示。首先，資料以及所有票據的來源。市場部的資料，票據來源與總公司。對于實物(比如：書，盤等)可以給它編 號，這樣便于跟蹤。對于票據，其本身就帶有編號，所以這里不再需要自行給它編號。然后，根據業務需要，業務 員領取了書、盤等。這些領取的東西都必須要登記下來，并且記錄領取人的姓名(實際內部操作的是編號)。下而的 部分，要與業務管理模塊互操作了。在業務管理那部分里面，有一個事件跟蹤模塊，它會記錄業務員使用這些票據、資料的情況。 無論票據還是其他實物資料，一旦業務員領取后，那些資料要么 在業務員手里，要么己經給客戶了。通過上而所述 的流程

25、，我們可以很容易的知道業務員用掉的資料或者票據。在定期檢查時候，系統可以自動得出業務員用掉的資 料票據，這樣很容易得出應該在手里的資料票據。只要把這一個清單和業務員手里的資料、票據相比對，就可以了解是否有遺失情況。d.其他說明：這里提供了一種可以跟票據、資料的方法，但這里只是一種方法，它并不能解 決所有的問題。這里很大 部分依賴了事件跟蹤模塊對數據庫操作的結果。但是如何判別業務員是否真的如他中明的那樣把憑證交給客戶了 呢？程序只能按照他所申明的那樣做記錄(換句話說，程序總是認為這個申明是真實的)。所以通過這個系統只能識別非故意的單據實物丟失，而識別故意 隱匿單據則是管理學和法學的范疇，并不是計

26、算機科學的范疇了。另外，這里的票據是指發票、合同、發行憑證、 贈品、其他表單等。對每一種票據的處理方式可以是類似的。都包含查詢與錄入修改等。10. 業務收入統計：a. 含義解釋：這里統計的是每一個市場部業務上面的凈收入，支出等。這些數據是通過業務管理模塊和財務部分的工 資管理模塊得到的。b 相關數據表：市場部數據表(11) (9) (22),上層數據表(7)c. 其他說明：這部分需要提供給我們更多的資料，比如現在公司需要統計些什么，統計表的樣式是怎樣的，如果某些 統計方法不是顯而易見的，則需要給出算法。11. 工資參數設置：& 含義解釋：由于每一個市場部，市場部的每一個部門的工資計算方法都不一

27、樣，所以需要對一些數據進行設置。這些設置將影響到工資計算。和其他設置相比，這里的設置可能進行的更頻繁一些。所以要對它的效率做一個準確的考慮。和其他所有的設置一樣，這里的所有數值都會有一個初始值。b. 相關數據庫：市場部數據表(19) ( 20) (21) (16)12 .員工工資管理：a.含義解釋：市場部的工資計算方法比較特殊，所以在這一塊里而是有一定麻煩的。對于一般業務員需要考慮的是有沒有底薪，有沒有提成，需不需要繳納三金，與之相關的還有底薪計算方法，提成計算方法等；管理人員除了這些基木工資外，還有管理費，但不同部門管理費又是不一樣的， 所以在具體設計時候要把這些問題都考慮進去。b相關數據表

28、：市場部數據表(7) (9) (11) (16) ( 22)c. 流程：這部分因為要涉及提成，所以計算方法比較復雜。以下是提成的計算方法：將此業績記錄計算依據工資項目最后實際工資d 其他說明：更具體的計算方法可以參考最后的數據流圖。在SQLServer里而，木身就有數據加密傳輸 使其在數據庫里面就是加密以后的狀態。當然實際應用時候，可以采用簡單的加數據加密備份模塊:這個模塊屬于為了維護數據安全而設置的模塊。功能。這里只對一些敏感的重要的數據進行再次的加密,（既即使不通過網絡傳輸，也無法直接解讀這些數據）密方法，如ASCII移位等，不要太復朵。而且只對重要的數據，比如財務數據和業務數據進行保護。

29、數據備份可以按 照按H,按月對數據進行備份，以防止數據庫的意外破壞。數據庫管理模塊：數據庫管理模塊完成常規的數據庫錄入查找等功能。它除了數據庫常規操作以外要進行錯誤檢測和可恢復錯誤的處理。將其單獨成為幾個模塊是為了是上層模塊對數據庫的操作更為簡單和靈活，并提供了一定的可靠性保證。遠程數據同步模塊：這一模塊采用何種同步方式是目前需要討論的問題。設計這一模塊的目的是使上層操作可以那么只需要修改此模塊，而在與數據遠程訪問完全分離。將來如果改換了數據遠程訪問的方式, 這一模塊之上的部分，可以不作改動。2.網管部網管部程序主要是用來記錄和查詢中請的域名信箱等的情況。相對于市場部程序來說，網管部程序功能上

30、比較簡 單與單一，需要統計的數據較少。需要完成的功能是從共享數據庫中獲取消息，按照消息內容進行處理（如進行空間設 置，設置郵箱等），將處理結果返回共享數據庫。輔助功能如查詢等。總的模塊示意圖如下：遠程數拯庫（運行SQLServer的服務器）數據添加模塊數據交互模塊流程控制模塊數據查找模塊數據編輯模塊再對這一流程進行一下解釋，網管部的數據都來自于市場部，它是一個被動的執行機構，但它執行的結果又是必須要返回給 市場部的，不然是毫無意義的。比對上面兩張圖，其結構是完全不同的，這是相當自然的，因為一個是模塊圖，而另外一個是業務流程圖。每一個流程環節，需要一些模塊的參與來完成的。簡單的說，流程圖側重了事

31、情的描述或者是編程時候的界面實現，而模塊圖側重于了技術上的模塊劃分，其根木目的是代碼的重用，它只是一個技術層而的劃分。舉個例子，這里“接受本部門信息”就需要數據庫交互模塊的支持，而數據庫交互模塊將調用數據 庫查找模塊來具體實現這件事情。而在整個流程結束需要上傳這條數據的時候，仍然需要數據交互模塊， 此時交互模塊調 用數據查找模塊來定位數據， 用數據編輯模塊來將完成情況添加上去。3.制作部制作部的程序和網管部類似，整個模塊結構也可以參考網管部的，在這里就不再重復。兩者主要的區別體現在流 程控制模塊，這是由兩個部分的業務所決定的。制作部的大致流程如下：對上而的流程圖的說明：首先它仍然是一個業務上的

32、流程，括號里而指出了這個流程時候，對于整個系統所進行的操作。省略號地方省略了制作時候的具體步驟（這部分是需要制作部提供資料的）對上而的模塊圖（不是流程圖）作一個說明：由于制作部和網管部操作都具有被動性和很多確定性，所以這一部分的管理程序是相對比較簡單的。其數據庫操作也是比較簡單的，只要能記錄流程、操作人員和完成的具體工作就可以了。需要說明的是這里的數據添加模塊和數據交互模塊在功能上是有重復的，設計這樣一個結構是從性能考慮上出發的。數據添加功能側重對大批量的直接添加，它側重速度，只提供有限的錯誤控制。數據交互模塊則進行更完整的數據庫操作，它側重應用功能，應該提供更多的可以供上層調用的函數和錯誤檢

33、測。兩個部門最大的差異是在流程控制上。四.數據流圖市場部業務數據流圖業務員在談成一筆業務、接收到一份資料或接收到一筆款項等可以產生單據或可記錄或可對原先記錄進行修改的事情 后，會自動觸發一個事件，接下來就會觸發一連串的動作。業務員將資料交給市場部的文員，文員將此事件資料整理并錄入數據庫后，上傳至數據庫服務器；制作部從數據庫服務器上下載制作資料，然后開始制作；網管部也從數據庫服務器上下載資料，接下來就按照要求申請域名或是設置郵箱；無論是市場部、制作部還是網 管部都應該在相應的工作完成后將完成的結果反饋到數據庫服務器。具體示意圖如下：說明：從軟件工程學的觀點來看，上圖是一個不規范的數據流圖,但是為

34、了理解的方便，就借用了一些不規范的元素。市場部工資數據流圖市場部工資計算比較復雜，各分公司市場部的工資結算方法也不大一樣。一、業務員的工資由兩部分組成第一部分基本工資（若基本工資不存在則設置為零）第二部分業務提成（根據業務員當月業績來計算）第三部分三金的繳納情況（若三金可以不交則設置為零）二、管理人員的工資分為三部分第一部分基本工資（若基木工資不存在則設置為零）第二部分業務提成（如果仍兼做業務員的話）第三部分三金的繳納情況（若三金可以不交則設置為零） 第四部分管理費（按當月業績來計算）。數據流圖如下：說明：針對上圖的說明（1）分公司市場部業務員工資分配情況不盡相同，某些地區市場部的業務員沒有基

35、本工資，則基本工資按零計算。2）管理人員的業務提成設置為零。3）對于業務員來說，未考慮到的工資部分或者某些額外獎勵可以歸入業務提成；對于管理人員來說,未考慮到的工資部分或者某些額外獎勵可以歸入管理費。內部管理系統所需資料:市場部1. 公司的網站套餐清單及價目表2. 套餐清單中，每一種套餐具體服務項目及價目，公司可選服務項目清單及價目3. 市場部內部的部門設置組織圖4. 市場部內部各部分的具體職責5. 發票樣張6. 合同樣張7. 發行憑證樣張8. 贈品清單9. 其它所有表單（如需打印）樣張10. 人事檔案需要錄入的內容11. 工資結算（包括提成的具體計算算法、業績統計方法）12. 各種票據如果丟

36、失處理方法（如需罰款的，具體罰款數額，或票據注銷方法）/針打）13. 各市場部、計算機及打卬機配置情況（具體操作系統、打卬機種類（是否噴墨14. 各市場部上網設施15. 各市場部業務上獨特的地方的清單16. 市場部需打印報表的清單樣張:制作部1. 部門內組織結構圖2. 具體工作流程及工序3. 各統計報表清單及樣張三：網管部1. 部門內組織結構圖2. 具體工作流程及工序3. 各統計報表清單及樣張四：補丁程序現有數據庫的字段定義及各字段含義五：其它資料現有各部門之間遞交表單的樣式內部管理系統硬件需求為了保證內部管理系統的穩定高速運行，必須要增加硬件并對現有的硬件進行改造，特提出以下硬件需求。（注：

37、這里 的硬件指一個完整的硬件系統，其部分的包含了對軟件的需求，這些軟件是為了正常運行管理系統所必須配備的）對服務器的要求1. 服務器的中央處理部件（CPU）建議使用PHI 1G （以上）Xeon處理器芯片。2. 服務器內存必須使用服務器專用ECC內存3. 為了保證數據存儲的絕對可靠，硬盤應使用磁盤冗余陣列（RAID 01 ）4. 為了防止服務器不可預測的故障，或者服務器的定期維護對公司整個業務造成的影響，所有建議使用兩臺服務器。兩臺服務器應構成雙機熱備份。中間使用WatchDog電路。這樣的結構可以保證整個系統的長時間不間斷工作，即使在服務器定期維護的時候也可以使用后備另一臺服務器工作。5.

38、服務器應支持熱插拔電源6. 服務器必須配備UPS （不間斷電源）。7. 服務器應該放在公司內部。不然無法進行程序調試。& 服務器應該必須有固定IP地址。9.其他性能在經濟條件允許的情況下，應該盡量使用高速穩定的配件。服務器上應該配備的軟件1 操作系統：Microsoft Windows 2000 server 或者 Microsoft Windows 2000 Advanced server2. 數據庫：Microsoft SQL Server 2000 （簡體中文版）3. 服務器必須使用專業的防火墻和反病毒軟件。4. 除了為了運行必須配備的程序以外，服務器上建議盡量不要安裝其他無關程序，以減

39、少程序的混亂或者程序的意外 沖突。5. 各其他分公司的操作系統盡量統一。（Windows 9x系列或者Windows 2000系列）。這樣可以避免管理軟件在岀來因為操作系統版本不一致造成的過多的開銷。6. 各分公司的機器必須也安裝反病毒軟件和防火墻。以防止網絡上的蠕蟲病毒在整個網絡范圍內的蔓延。7如果要打卬涉及字段比較多的報表，應該配備針式打卬機。注：建議首先把服務器定下來，不然無法進行數據庫定義了。其他內容可以在編制過程中慢慢配上。如果實在不行，可以 先用臨時的代替一下，在正式使用時候再作更新。內部管理系統上層數據庫設計數據表定義1、安全性驗證：屬性：部門編號（2） 3密碼主鍵：部門編號2、

40、部門編號一名稱數據庫屬性：部門（分公司）編號，主管人員,部門名稱，部門所在地址，聯系電話，Email,備注主鍵：部門編號3、業務員信息數據庫屬性：工號,所屬部門編號（2）,姓名，年齡，職務，報到日期，離開日期，離職原因，日常電話，手機，BP機，地址，郵編，備注主鍵：工號4、部門一業務信息屬性:業務流水號，所屬部門編號（2）,遞交部門編號業務應 2）,業務員姓名，業務類型，業務送達時間，完成時間，備注主鍵：業務流水號5、業務一資料信息3這里的部門對于市場部或分公司來說就是市場部或分公司編屬性：自動編號，業務流水號（4）,資料名稱，送達時間，遞交人，接收人，是否收到，備注主鍵：自動編號6、業務進程

41、信息屬性：自動編號，業務流水號（4）,目前所屬部門編號主鍵：自2）,是否完成，完成時間，備注（反饋信息） 動編號7、公司收入條件屬性：部門編號（2）,日期，總收入,總支岀主鍵：部門編號，日期內部管理系統市場部數據庫設計定義實體集1. 公司服務內容一價格數據表4屬性：編號，業務名稱，業務簡介，價格，最低限價，備注主鍵：編號服務編號（1）,備注2. 上網套餐套餐名一所含內容數據表屬性：自動編號，套餐名,套餐編號,主鍵：自動編號3. 上網套餐最低價格數據表屬性：套餐編號（2），常規價格,最低限價，備注主鍵：套餐編號4. 客戶信息數據表屬性：客戶編號，客戶名稱,聯系人名稱，聯系地址，聯系電話，聯系郵編

42、，備注主鍵：客戶編號5. 客戶-事件數據表屬性：自動編號，客戶編號（4），事件編號（9）,備注主鍵：自動編號事件-服務數據表屬性：自動編號，事件編號（9），服務編號（1） （2）篤是否為上網套餐，備注主鍵：自動編號7. 事件-業務員數據表屬性：自動編號，事件編號（9），業務員編號主鍵： 18），備注自動編號8. 事件-應收資料數據表屬性名：資料編號，事件編號（9），資料名稱，資料預備提交方式（文字，照片等）備注，資料類型, 主鍵：資料編號9. 事件信息數據表：屬性：事件編號，事件簡介,合同價格，合同起始日期，合同終止日期，備注主鍵：事件編號10. 業務員實際收取資料情況數據表屬性：自動編號，事件編號（9）,收到資料編號（8）,收到資料日期，資料是否完整，資料收到形式，經手人 編號，備注主鍵：自動編號11. 業務員收取錢款情況數據表屬性：自動編號，事件編號（9）,收到錢款，收到日期，支付方式，經手人編號，備注按照數據庫設計理論規范，此處不應使用“數據表”這一名稱，實體集并不等同于數據表，但在這里為了表述的方便，仍然使用了 “數據表” 這個名稱,如果選擇“是”，則關聯應為（2