北京航空航天大學軟件學院工程實踐結題報告課題名稱：利用網絡教育手段有效實現社區居民普及終身教育的模式探討姓名：組別：學號：專業方向：IT項目管理與產業信息化所屬院系：北京航空航天大學軟件學院指導老師：谷衛平實踐起止時間：20**年月至20XX年月摘要21世紀是“知識爆炸”的時代，知識老化加速，社會變化急劇，任何人都不可能一勞永逸地擁有足夠的知識，而是需要終身學習。學習是人類生存和發展的重要手段，終身學習是自身發展和適應社會的必由之路。我國也多次提出要形成終身學習的學習型社會，構建終身教育體系，在計算機網絡技術飛速發展的背景下，利用信息技術，以網絡教育為切入點，實現社區居民普及終身教育是未來教育發展的趨勢。近年來，我國各地在社區教育方面進行了積極探索。至2007年，國家級社區教育實驗區已達114個，覆蓋了30個省、自治區和直轄市。省級社區教育實驗區已達400多個。2007年，在全國65個社區教育實驗區，參加各種教育培訓活動的社區居民2561萬人次，占其總數的50.3%。本論文根據社會現實的需求，通過研究分析國內外社區終身教育的現狀，運用現代計算機網絡相關技術，整合現有資源，構建先進、高效、實用的網絡教育資源服務平臺，以達到有效實現社區居民普及終身教育的目的。關鍵詞：目錄第一章緒論 1.1課題背景及意義 1.2國內外現狀及對比分析 1.3目標及研究內容 1.3.1論文目標 1.3.2論文研究內容 1.4系統的創新性 第二章服務平臺系統需求分析 2.1總體需求 2.2功能模塊需求分析 2.3網絡流量需求分析 2.4非功能性需求分析 2.4.1響應時間 2.4.2安全性 2.4.3易用性 2.4.4擴展性 第三章服務平臺系統總體設計 3.1設計思想 3.2關鍵技術 3.2.1B/S構架 3.2.2ASP 3.2.3MSSQLSERVER 3.3系統功能架構 3.3.1平臺管理模塊 3.3.2人員管理模塊 3.3.3課程模塊 3.3.4教程模塊 3.3.5交流區模塊 3.3系統網絡拓撲圖 第四章系統詳細設計 4.1功能模塊詳細設計 4.1.1平臺管理模塊 4.1.2人員管理模塊 4.1.3課程模塊 4.1.4教程模塊 4.1.5交流區模塊 4.2數據庫總體設計 4.2.1數據庫介紹 4.2.2整體E-R圖 4.2.3數據庫物理結構 第五章系統測試 5.1 測試概述 5.2 測試目的 5.3 測試方法、工具及測試環境 5.3.1 測試方法 5.3.2 測試工具 5.3.3 測試環境 5.4 系統功能測試 5.5 系統性能測試 5.6 測試結果分析 5.7 小結 第六章系統實施 6.1系統實施組織 6.2實施進度計劃 6.3系統實施準備 6.3.1接口準備 6.3.2運行環境準備 6.3.3數據準備 6.4系統界面展示 6.5系統評估 6.6小結 總結與展望 參考文獻 第一章緒論1.1課題背景及意義1965年12月,保爾·朗格朗在聯合國教科文組織第三屆成人教育國際促進會議上,第一次提出了終身教育這一概念。1972年,聯合國教科文組織國際教育發展委員會編著、被譽為當代教育思想發展中里程碑的著名報告《學會生存》特別強調終身教育和學習型社會兩個概念。1999年,國務院批準的教育部《面向21世紀教育振興行動計劃》提出了構建終身教育體系和學習型社會的目標任務和工作思路。進入新世紀,黨中央、國務院對學習型社會建設提出了新的、更高的要求,2001年5月江澤民同志在亞太經合組織人力資源能力建設高峰會議上提出,21世紀的中國要致力于“構建終身教育體系,創建學習型社會”。2002年黨的十六大報告提出要“構建終身教育體系”“,形成全民學習、終身學習的學習型社會,促進人的全面發展”。構建終身教育體系與學習型社會,其根本目的是主動適應經濟全球化對人才的需求,進一步增強教育體系的彈性,發展多種形式的各類教育,為廣大國民創造更多的接受教育的機會,以適應社會各行各業人力資源需求的變化和廣大居民對學習的各種需求。同時,構建終身教育體系和學習型社會可以全方位地提高全社會的學習力和創新能力,從根本上增強我國的國際競爭力。構建終身教育體系已成為教育發展和社會進步的共同要求,終身學習已經成為眾多人的共識。1.2國內外現狀及對比分析1.3目標及研究內容 1.3.1論文目標1.3.2論文研究內容1.4系統的創新性第二章需求分析2.1總體需求本系統是某實體連鎖藥房的網上藥店打造的后臺進銷存系統，該網上藥店致力于建立“中國健康商品第一服務平臺”，為消費者提供優質、價廉、物美、誠信的健康類商品。經營的品種主要涉及“營養保健品、母嬰用品、護理美容品、成人用品、醫療器械、藥膳禮品”等。千余家供應商,數萬個品牌，品種繁多。開展“醫藥零售電子商務”業務的企業或公司，都需要“醫藥零售電子商務網站”與“醫藥零售電子商務進銷存”兩個系統的支撐。醫藥零售電子商務網站系統是對客戶展示醫藥商品信息并提供網上購物的功能系統；醫藥零售電子商務進銷存系統是為了配合“醫藥零售電子商務網站”業務而建設的系統，對網站銷售藥品的實體倉庫與門店“進貨、銷售、存儲”等進行管理的應用系統；“醫藥零售電子商務網站”與“醫藥零售電子商務進銷存”將進行對接，完成藥品數據的實時傳輸與處理，以保證“醫藥零售電子商務”業務的順利實施與執行。醫藥零售電子商務進銷存系統要想符合行業要求，前期的需求分析在系統開發過程中有非常重要的地位，它的好壞直接關系到系統開發成本、系統開發周期及系統質量。它是系統設計的第一步，是整個系統成開發成功的基礎。詳細周全的需求分析，可以減少系統開發中的錯誤，又可降低修復錯誤的費用，從而大大減少系統開發成本，縮短系統開發周期。需求分析的結果是系統開發的基礎，關系到系統的成敗和軟件產品的質量。首先，此系統需要實現商品“進貨、銷售、存儲、退貨、配貨、盤點”等基礎流程與功能；以保證對“實體倉庫或門店”商品庫存的管理、與“醫藥零售電子商務系統”的緊密配合。其次，此系統還需實現“商品信息的登記、供貨渠道的登記、商品庫存異常糾正、商品零售價格設置與維護、商品有效期報警監控、商品在倉庫或門店擺放貨位參數設置與維護”等功能；這些都是此系統的輔助功能，能更好的提升“醫藥零售電子商務進銷存”系統的易用性、適應商品錯綜復雜的異常業務情況的解決與監管。最后，實現此系統與“醫藥零售電子商務網站”的良好結合，才能達到一個“全面、協同”的運營管理平臺標準，才能實現“操作易用性、設置靈活性和功能擴展性”的充分保證。醫藥零售電子商務進銷存系統的業務模式：實現對商品“進貨、存儲、退貨、盤點”的管理；將商品庫存數據傳輸給“醫藥零售電子商務網站”，由其完成商品基礎信息及庫存的展示，在客戶網上購物后將購買商品信息傳輸給本系統；本系統根據“醫藥零售電子商務網站”傳輸的購買商品信息進行配貨處理，并將處理結果反饋給“醫藥零售電子商務網站”系統，由其完成后續的網站售后服務工作。2.2業務流程梳理及優化通過醫藥行業實體零售進銷存系統的市場調研，對本系統的業務流程進行了梳理及優化，具體如下：1．本系統的商品“進貨”業務流程圖1商品“進貨”業務流程圖商品“進貨”業務流程描述：將供貨渠道、商品信息維護到系統；采購人員制定采購計劃，向供貨渠道采購商品；質檢人員在商品到達倉庫后，進行質量核驗；倉儲人員在質檢核驗通過后，進行商品入庫及擺放。2．本系統的商品“退貨”業務流程圖2商品“退貨”業務流程圖商品“退貨”業務流程描述：將供貨渠道、商品信息維護到系統；業務人員提交退貨申請；采購人員與供貨渠道核準退貨信息；倉儲人員根據采購人員核準退貨信息進行商品下架、打包、配送操作。3．本系統的商品“銷售”業務流程圖3網站零售商品業務流程圖圖4門店零售商品業務流程圖商品“銷售”業務流程描述：涉及“網站銷售、門店銷售”兩個流程。網站銷售流程：客戶在網站購買下單后；網站會生成一個銷售訂單；同時，會生成一個商品配送單據；倉儲根據訂單商品進行商品打包、快遞操作。門店銷售流程：倉庫人員將商品配送到門店展示；客戶在門店購買付款；門店會生成一個零售訂單。4．本系統的商品“盤點”業務流程圖5商品“盤點”業務流程圖商品“盤點”業務流程描述：倉儲人員進行盤點工作登記，設定盤點時間周期；系統自動獲取系統庫存數據；倉儲人員登記盤點的實際庫存數據；系統自動將系統庫存數據與盤點庫存數據進行對比，篩選不一致庫存數據；財務人員核查不一致庫存數據，進行報損或報溢操作。2.3功能性需求通過醫藥行業實體零售進銷存系統的市場調研，以及對本系統的業務流程進行了梳理及優化，分析了以下功能需求：1．對商品信息與售價的維護功能：第一步，將商品詳細信息在系統中進行登記，便于采購人員制定采購計劃中選定，使網站能夠詳細、清楚的展示商品信息；數據涉及“便于采購計劃選定的商品名稱、規格、單位、生產企業”等信息，還涉及“便于網站信息展示的化學名稱、商品分類、批準文號、儲存條件、功能療效、說明書、重量”等信息；需要具備“添加、修改、查看”等功能。第二步，分別對“網站售價、門店售價”進行維護，為客戶在“網站、門店”購買環節不可缺少的數據；數據涉及“市場價、限制零售價、零售價、會員價、貴賓價”等信息，需要具備“修改、查看”等功能。圖6商品信息與售價維護的用例圖2．對商品入庫的功能：包括“采購計劃、貨物質檢、驗收入庫”三大部分。第一步，將采購人員與供貨渠道確定的采購數據在系統中進行登記，便于商品到貨后，質檢人員進行核驗與處理；數據涉及“供貨渠道信息、采購商品信息、商品最近入庫進價、本次采購計劃進價/數量”等信息，需要具備“添加、修改、查看”等功能。第二步，根據采購數據對實際到貨商品進行質量與數量核驗，在系統中進行登記，便于商品質檢完畢后，倉儲人員進行入庫與擺放操作；數據涉及“采購計劃信息、驗收商品進價/數量、驗收商品批號/有效期”等信息，需要具備“登記、查看”等功能。第三步，根據質檢驗收數據對實際入庫商品進行質量與數量確認，在系統中進行登記，便于商品庫存的更新存儲操作；數據涉及“驗收單據信息、入庫商品進價/數量、入庫商品批號/有效期、商品預期貨位號”等信息，需要具備“登記、查看”等功能。入庫登記生效以后，系統根據入庫數據自動完成商品庫存的變更存儲。圖7商品入庫的用例圖3．對商品退貨的功能：包括“計劃申請、計劃核準、質檢出庫”三大部分。第一步，業務人員根據商品有效期與積壓情況，對商品提出退貨申請，便于對庫存資金的合理控制；數據涉及“供貨渠道信息、商品基礎信息、商品庫存信息、預期退貨數量”等信息，需要具備“添加、修改、查看”等功能。第二步，采購人員根據商品退貨申請數據與供貨渠道進行洽談與確認，將最終可以退貨數據登記到系統，便于倉庫人員對商品進行下架、打包、配送操作；數據涉及“供貨渠道信息、商品基礎信息、商品庫存信息、核準退貨數量、核準退貨價格”等信息，需要具備“查看、修改”等功能。第三步，倉儲人員根據商品核準退貨數據進行商品下架、打包、配送操作；數據涉及“供貨渠道信息、商品基礎信息、商品庫存信息、核準退貨數量、核準退貨價格、實際退貨數量”等信息，需要具備“查看、生效”等功能。圖8商品退貨的用例圖4．對客戶網站購買信息的記錄功能：第一步，客戶在網站購買商品后，系統自動生成一個購買訂單，記錄客戶的購買信息，便于后續的售后服務工作延續；數據涉及“客戶聯系方式、客戶收貨地址、客戶付款信息、客戶收貨方式、客戶購買商品、客戶優惠數據”等信息，需要具備“查看、修改、刪除、狀態跳轉”等功能。第二步，客戶網站購買訂單生成后，系統自動生成一個精確到商品批號的配送單，同時更新商品庫存數據并保證準確性；數據涉及“商品配送單位、商品基礎信息、商品入庫信息、商品配送數量、商品配送進價”等信息，需要具備“查看、刪除、修改、生效、狀態跳轉”等功能。5．對門店銷售商品的零售管理功能：第一步，倉儲人員根據門店零售需求，將商品提前配送到門店進行展示，便于吸引客戶購買，配送的商品信息在此進行登記；數據涉及“商品配送單位、商品接收單位、商品基礎信息、商品庫存信息、商品配貨數量、商品配貨價格、商品接收貨位”等信息；需要具備“添加、修改、刪除、查看、生效、驗收、狀態跳轉”等功能。第二步，客戶在門店購買商品后，系統自動生成一個購買訂單，記錄客戶的購買信息，便于后續的售后服務工作延續；數據涉及“客戶聯系方式、客戶付款信息、客戶購買商品、客戶優惠數據”等信息，需要具備“查看、修改、刪除、添加”等功能。6．對商品盤點的功能：第一步，倉儲人員在進行盤點前，在系統登記盤點需求，明確盤點開始時間以獲取系統庫存數據，便于與盤點的庫存數據進行對比分析；數據涉及“盤點范圍、盤點方式、盤點周期”等信息，需要具備“添加、修改、刪除、查看、授權”等功能。第二步，倉儲人員在盤點開始后，通過手持設備對實際商品庫存數據進行登記，便于與系統庫存數據進行對比分析；數據涉及“商品基礎信息、商品庫存數量、商品貨位編碼、商品損壞數量”等信息；需要具備“添加、修改、查看、刪除”等功能。第三步，系統自動系統與盤點庫存數據不一致的信息進行報警提示，以保證系統商品庫存數據與實際商品庫存數據的一致性；數據涉及“商品基礎信息、系統商品庫存數量、盤點商品庫存數據、商品貨位編碼、商品損壞數量、商品庫存差異數量”等信息；需要具備“查看、處理”等功能。第四步，財務人員根據庫存差異數據進行核準，對出現的庫存差異進行損溢登記，以實現系統商品庫存數據與實際商品庫存數據的一致性；數據涉及“商品基礎信息、商品庫存信息、損溢類型、損溢數量”等信息；需要具備“添加、修改、查看、刪除、審核”等功能。7．對商品進行停止采購的功能：當商品出現積壓，或者與供貨渠道出現分歧時，對商品進行停止采購操作，禁止采購人員繼續購進此商品；數據涉及“商品基礎信息、商品庫存信息”等信息；需要具備“添加、修改、刪除、查看、審核”等功能。8．對商品進行停止銷售的功能：當商品出現質量問題需要廠家召回，或者運營決定不再銷售此商品時，對商品進行停止銷售操作，禁止“網站、門店”在繼續銷售此商品；數據涉及“商品基礎信息、商品庫存信息”等信息；需要具備“添加、修改、刪除、查看、審核”等功能。9．對供貨渠道的管理功能：將商品供貨渠道在系統中進行登記，便于采購人員制定采購計劃中選定；數據涉及“供貨渠道名稱、地址、聯系人、營業執照、藥品資質”等信息；需要具備“添加、刪除、修改、查看、審核”等功能。10．對在庫商品的有效期監控報警功能：根據“企業運營、供貨渠道”的要求，對商品有效期報警參數進行設置，便于及時發現達到有效期警戒線的商品，及時進行供貨渠道退貨、運營清倉等工作；數據涉及“商品信息、報警類型（按供貨渠道、按企業運營）、報警范圍（單一供貨渠道、全部供貨渠道）、初-中-高報警天數”等信息，需要具備“添加、修改、查看”報警參數的功能，需要具備“查看、處理”報警商品的功能。2.4非功能性需求醫藥零售電子商務進銷存系統滿足用戶業務需求而必須具有且除功能需求以外的特性。非功能性需求包括系統的性能、可靠性、可維護性、可擴充性和對技術和對業務的適應性等等。2.4.1性能指標性能需求部分，主要有兩個方面的指標要求，即響應時間要求和并發能力要求。并發性：因本系統主要是內部運營人員使用，所以在訪問指標上要求可以滿足千兆以太網環境中，可支持系統用戶數1萬人，日活躍用戶數1千人，平均在線使用時間以2小時為基準，平均并發用戶數為80人。響應時間：此用例以多用戶并發查詢為主，以平均并發用戶數80人為例，并發查詢的平均響應時間不能超過3秒，考慮到峰值的浪涌情況，峰值并發人數為100人時，并發查詢的平均響應時間不能超過4秒。2.4.2安全性業務安全性方面，保證系統不會由于自身的故障或失效導致應用系統的其它成份相繼失效甚至崩潰的特性。數據安全性方面，防止外界或內部用戶的非法或惡意訪問本系統。即系統本身應有完善的權限管理功能，通過對權限的配置管理，可實現對于不同操作角色的訪問控制，同時在關鍵業務數據的更新與刪除操作上，應具備操作審核功能以及操作日志。便于追蹤數據操作軌跡，保證數據層面的安全。2.4.3穩定性本系統的運行要為7*24小時的不間斷自動運行，即除必要的少量配置文件的修改之外，日常的業務均由系統自動運行、勿需人工干預。運行操作人員僅在系統報警提示的情況下，進行非正常情況下的人工干預或通知技術人員進行故障維修。2.4.4可維護性系統一旦投入運行就不能間斷。除了要求系統具有良好的維護性外，還應當擁有離線的維護環境以便在不影響正常業務的情況下進行軟件的維護工作。2.4.5可擴展性隨著業務的不斷發展，新的系統也將不斷建設，因此，本項目應具有較好的可擴展性，為應用系統的進一步擴充和升級提供方便。系統應適應業務部門的需求變更及擴展，多采用配置方法功能調整，而不需要對程序做大的修改。系統應能適應后續應用的添加，系統整體框架保持穩定，不需要做大量的程序修改。隨著用戶數的增長及功能應用的增長，軟件系統通過硬件性能的調整而保持相對的穩定性。2.4.6易用性為便于操作人員的人工干預，有關系統配置、運行參數、節目表的修改等，應提供直觀、方便的修改界面，系統可按照配置的參數自動運行，減少操作人員的勞動強度。2.4.7規范性本系統的設計需要采用標準的通信、網絡等協議，嚴格遵循軟件工程規范化的設計原則，不同的設計階段進行嚴格的設計評審及完成相應的設計文檔等，對整個設計過程進行規范化的管理和控制。收集與分發的所有資料應具有規范的文件命名和數據格式。第三章系統總體設計3.1系統技術架構進銷存是一個功能復雜，系統龐大的系統，在進銷存系統里管理著多個操作用戶和多年商業信息的數據。因此技術架構時必須重點考慮整個系統的跨平臺、安全性、穩定性、實用性及可伸縮性，同時技術架構應該有非常好的可擴展能力，采用模塊化、構件化以及面向對象的設計方法，并符合整個項目的建設原則和技術要求。結構選型恰當與否，直接關系到系統的成敗。在結構選型中主要考慮先進性和實用性并重原則、標準化和規范化原則、開放性和兼容性原則、松耦合和粗粒度集成原則、可擴展性和可維護性原則、可擴展性和可維護性原則。基于以上原則，并結合當前業內的成功案例，本系統技術體系上選用J2EE技術，采用B/S/D三層結構進行應用系統的開發。開發采用Srping+webwork2+ibatis+Freemarker+MySQL該系統的技術架構劃分三個層次：展示層/業務邏輯層/數據訪問層。圖9系統技術架構圖展現層英文是PresentationLayer，是實現顯示功能的，在進銷存系統里就是展示給用戶的UI部分，使用戶直接操作的界面，用戶通過展示層獲取信息，并對信息進行管理。系統通過展示層也能獲取用戶的行為信息。這部分一般使用B/S結構來完成，當然你也可以使用專門遠程客戶端來實現;業務邏輯層因為是由大量組件(Components)組成的，也可稱為組件層，組件從不同角度又可分為各種類型，然后又有不同的流派，目前占主要位置的是Model+Service，模型加服務，所以這一層又稱為業務服務層BusinessService；也有稱為Model業務層；持久層是負責對象持久化也就是數據庫操作的層次,英文PersistenceLayer，主要負責把用戶的操作數據，通過分析整理轉化成數據庫語言，最終存儲到數據庫里，在用戶需要使用的時候再讀取使用，例如：用戶增加一個供應商信息，用戶在系統里，填入供應商的名稱，供應商地址，供應商營業執照，聯系人，開戶銀行等信息，在持久層把這些信息存儲導數據庫中的相應的供應商表里。展現層框架在進銷存系統中用戶操作比較頻繁，訪問量也會比較大，所以選擇一個效率高、速度快的展示層是很重要，可以給用戶帶來良好的用戶體驗。用戶在使用系統時，就是在和展示層進行交互，用戶的使用體驗全部來自展示層，展示層的選擇最終影響到用戶的體驗。因此進過調研測試最終選擇了FreeMarker，FreeMarker是一個用Java語言編寫的模板引擎，它基于模板來生成文本輸出。FreeMarker與Web容器無關，即在Web運行時，它并不知道Servlet或HTTP。它不僅可以用作表現層的實現技術，而且還可以用于生成XML，JSP或Java等。FreeMarker允許Javaservlet保持圖形設計同應用程序邏輯的分離，這是通過在模板中密封HTML完成的。模板用servlet提供的數據動態地生成HTML。模板語言是強大的直觀的，編譯器速度快，輸出接近靜態HTML頁面的速度。雖然FreeMarker具有一些編程的能力，但通常由Java程序準備要顯示的數據，由FreeMarker生成頁面，通過模板顯示準備的數據。FreeMarker與容器無關，因為它并不知道HTTP或Servlet；FreeMarker同樣可以應用于非Web應用程序環境，FreeMarker更適合作為Model2框架（如Struts）的視圖組件，可以在模板中使用JSP標記庫，FreeMarker是免費的。業務邏輯層框架進銷存系統是一個復雜而龐大的系統，里面包含非常多而復雜的業務邏輯，例如一個供應商的操作就包括，供應商增加，供應商修改，供應商3級審核，供應商標志等，而且以上每一個操作又對應相應的一系列相關操作，因此為了能盡量降低開發成本和開發過程中的復雜度，就必須選擇一個功能強大，使用方便，學習成本低的框架去實現邏輯層，在經過業內調研和內部的討論后，webwork非常適合我們的進銷存系統的開發，具體分析如下：1.因為webwork簡潔、靈活功能強大，它是一個標準的Command模式框架實現，并且完全從web層脫離出來。2.Xwork提供了很多核心功能：前端攔截機（interceptor），運行時表單屬性驗證，類型轉換，強大的表達式語言（OGNL–theObjectGraphNotationLanguage），IoC（InversionofControl依賴倒轉控制）容器等。WebWork建立在Xwork之上，處理HTTP的請求和響應。所有的請求都會被它的前端控制器（ServletDispatcher，最新版本是FilterDispatcher）截獲。前端控制器對請求的數據進行包裝，初始化上下文數據，根據配置文件查找請求URL對應的Action類，執行Action，將執行結果轉發到相應的展現頁面。3.WebWork2支持多視圖表示，視圖部分可以使用JSP,Velocity,FreeMarker,JasperReports，XML等。數據訪問層框架持久層框架目前有Hibernate和各種JDO產品，當然還有直接寫SQL語句的JDBC。因為進銷存系統本身的復雜程度，就決定持久層的復雜性，只有選擇一個功能強大，使用方便、透明的框架才能給開發人員帶來方便，無論在開發過程和調試過程使用一個能對SQL透明的的框架是非常有好處的！我們選擇iBatis，因為Ibatis的靈活性和透明度的的綜合性要比hibernate和其他的JDO產品要好。持久層框架質量好與壞區分就是是否是O/RMapping，也就是對象和關系數據庫映射，關系數據庫需要實現定義好Schema結構；對象因為字段而變的也有一個自己的結構，如何將對象數據自動持久化到數據庫中，首先我們得定義兩者結構的對應，這實際是數據的元數據定義。因為Hiberante/iBatis這樣O/RMapping工具幫助你實現對象和數據庫轉換，克服了對象和數據庫阻抗現象，O/RMapping總結，所以才使得我們更多的可以對象方式（從模型Model對象）來考慮JavaEE/J2EE系統，可以完全放棄以前那種以數據庫為中心的思維方式。所以，是否選用好的持久層框架，取決于你整個團隊思維是否徹底OO了，是否需要真正OO，當然，對于一些小型項目，有時我們覺得直接使用JDBC模板反而更加輕松快捷一點，這也是Spring的JDBC模板/iBatis的Jdbc模板存在的理由了。從以上可以看出，靈活性/快速性/簡單性/可伸縮性是我們進行架構選擇的主要幾個依據，架構選擇實際就是在這幾個策略之間做一個平衡。當然，還有一個非常重要的因素，因為它不屬于某個層次的技術，性能/緩存是必須和上面因素綜合考慮的因素。3.2系統功能架構根據對進銷存系統目標和業務流程的分析，確定了本系統的七大模塊：供應商管理、商品信息管理、商品進貨管理、商品退貨管理、商品價格管理、商品銷售管理、商品盤點管理。圖10系統功能架構圖3.2.1供應商管理供應商管理：是系統運作的基礎，要實現對供應商信息的動態管理；供應商信息要先于其他信息錄入系統，才能保證正常運行。包括：供應商維護、供應商標志、結算方式維護三個模塊；供應商維護是對供貨渠道基礎信息進行登記與動態管理，供應商標志是根據供貨渠道對企業的重要程度進行分類，結算方式是將供貨渠道存在的各種結算模式進行登記，便于本系統財務資金核算。3.2.2商品信息管理商品信息管理：是系統運作的基礎，要實現對商品信息的動態管理；除供應商信息錄入外，需要先于其他信息錄入系統，才能保證正常運行。包括：商品信息維護、商品類別維護、商品信息標志、商品停止采購；商品信息維護是對商品基礎信息進行登記與動態管理，商品類別維護是根據不同的業務定義進行的屬性劃分，商品信息標志是根據商品對企業的重要程度進行的分類，商品停止采購是在商品出現積壓，或者與供貨渠道出現分歧時，禁止此商品繼續采購。3.2.3商品進貨管理商品進貨管理：采購人員從與供應商洽談采購計劃，到商品到貨信息錄入到系統的整套商品進入業務流程。包括：采購計劃制定、驗收單、入庫單、商品效期報警、商品貨位維護；采購計劃制定是采購人員與供貨渠道確定的采購數據在系統中進行登記；驗收單是質檢人員對實際到貨商品進行質量與數量核驗；入庫單是倉儲人員對實際入庫商品進行質量與數量確認，在系統中進行登記，便于商品庫存的更新存儲操作；商品效期報警是商品有效期報警參數進行設置，便于及時發現達到有效期警戒線的商品，及時進行供貨渠道退貨、運營清倉等工作；商品貨位維護是對庫房貨架進行命名，并將信息登記到本系統。3.2.4商品退貨管理商品退貨管理：業務人員從根據商品積壓或近有效期情況，提交商品退貨申請，到倉儲人員將商品下架、包裝、退還的整套商品出庫業務流程。包括：商品退貨申請、商品退貨調整、商品退貨單；商品退貨申請是業務人員根據商品有效期與積壓情況，對商品提出退貨申請，便于對庫存資金的合理控制；商品退貨調整是采購人員根據商品退貨申請數據與供貨渠道進行洽談與確認，將最終可以退貨數據登記到系統；商品退貨單是倉儲人員根據商品核準退貨數據進行商品下架、打包、配送。3.2.5商品價格管理商品價格管理：是系統開展銷售業務的基礎信息，要實現對商品價格的動態管理；不進行商品價格維護前，是不可以開展銷售業務的。包括：網站價格維護、門店價格維護；網站價格維護是僅針對網站商品零售價格進行動態管理；門店價格維護是僅針對門店商品零售價格進行動態管理。3.2.6商品銷售管理商品銷售管理：網站或門店將銷售信息錄入到系統，同時實現商品的出庫；可以自動計算銷售總額和銷售利潤，可以查商品的銷售明細與匯總等信息。包括：網站訂單維護、門店訂單維護、網站配送維護、門店配送維護、商品停止銷售；網站與門店訂單維護是客戶在網站購買商品后，系統自動生成一個購買訂單，記錄客戶的購買信息，便于后續的售后服務工作延續；網站配送維護是客戶網站購買訂單生成后，系統自動生成一個精確到商品批號的配送單，同時更新商品庫存數據并保證準確性；門店配送維護是倉儲人員根據門店零售需求，將商品提前配送到門店進行展示，便于吸引客戶購買，配送的商品信息在此進行登記與動態管理；商品停止銷售是商品出現質量問題需要廠家召回，或者運營決定不再銷售此商品時，禁止“網站、門店”繼續銷售此商品。3.2.7商品盤點管理商品盤點管理：倉儲人員定期對庫存商品進行清點，以保證系統記錄的商品庫存數據與商品實際庫存數據保持一致。包括：商品盤點登記、系統庫存數據、盤點庫存數據、庫存數據對比表、商品損溢登記；商品盤點登記是倉儲人員在進行盤點前，在系統登記盤點需求，明確盤點開始時間以獲取系統庫存數據；盤點庫存數據是倉儲人員在盤點開始后，通過手持設備對實際商品庫存數據進行登記與動態管理；庫存數據對比表是系統與盤點庫存數據進行對比，對不一致的信息進行報警提示；商品損溢登記是財務人員根據庫存差異數據進行核準，對出現的庫存差異進行損溢登記，以實現系統商品庫存數據與實際商品庫存數據的一致性。3.3系統網絡拓撲圖圖11系統網絡拓撲圖上圖展示的是系統的網絡拓撲結構，整個信息系統建立一個集中的數據中心，共用數據庫服務器、WEB服務器。整個系統運行在基于因特網或局域網之上，核心交換機或互聯網供用戶訪問。通過分級權限管理，各級系統操作用戶都可以在各自范圍內進行業務處理。1．系統部署的安全策略系統部署的安全性是首要問題，由于B／S模式采用點對多點、多點對多點這種開放的結構模式，并采用TCP／IP這一類運用于Internet的開放性協議，其安全性只能靠數據服務器上管理密碼的數據庫來保證。現代企業需要有開放的信息環境，需要加強與外界的聯系，這使得大多數企業將他們的內部網與Internet相連。由于采用TCP／IP，必須采用一系列的安全措施，如構筑防火墻，來防止Internet的用戶對企業內部信息的竊取以及外界病毒的侵入。B／S模式是否安全取決于管理者，加強帳號密碼管理和構筑防火墻是很必要的。在硬件架構中，我們設置防火墻以防止外界的侵入，在軟件層面，則需要對用戶的權限進行控制，以保證系統安全。因此，通過多種安全策略保證了整個系統在網絡環境中的安全運行。2．系統部署的性能保障由于存在著多用戶多業務功能的并發操作，因此性能是系統部署的重要問題。為保證數據的高速訪問，我們在前端部署了兩臺WEB服務器，采用DNS隨機的方式，將用戶的訪問流量分擔到兩臺前端服務器上去，這樣既可以使系統的整體訪問能力提高，用可以實現高可用。3．系統部署的穩定性由于系統的各種業務與運營相關，因此對于系統運行的穩定性提出了較高要求。為保證系統能提供不間斷服務，我們采用了集群技術，在應用服務器和數據庫服務器層面都采用了雙機的高可用架構，大幅度提升了系統和數據的穩定性。第四章系統詳細設計4.1功能模塊詳細設計由于功能模塊中涉及的功能較多，此處以供應商管理、商品管理、采購計劃管理為系統詳細設計用例，詳細展開各項功能需求。4.1.1供應商管理供應商信息“查詢”功能，附帶“創建、修改、刪除”等功能；此頁面可查詢與維護“進銷存系統”中所有的供應商信息。表1通用操作規則表名稱規則創建點擊則新窗口打開“創建供應商”頁面。修改選中某一供應商、此供應商為“創建、正常”時，才可點擊此按鈕；點擊則新窗口打開“修改供應商”頁面。刪除選中某一供應商、此供應商為“創建”時，才可點擊此按鈕；點擊則新窗口打開“刪除供應商”提示層。刪除提交后，此供應商狀態變更為“作廢”。提交審核選中某一供應商、此供應商為“創建、正常”時，才可點擊此按鈕。表2人員權限管理名稱權限規則--特殊權限對供應商進行創建、查看、修改、刪除操作。采購主管審核獨立權限--狀態規則說明定義：包括“創建、正常、作廢”。1、創建定義為“創建供應商信息保存后，系統自動更新為此狀態”；2、正常定義為“提交成功的意思，系統自動更新為此狀態”。6、作廢定義為“此供應商信息已經沒有意義，不能再進行任何操作，如果重新與作廢供應商合作，需要重新創建此供應商信息”。活動圖例說明圖12供應商管理活動圖由以上活動圖，可以得到供貨渠道實現的業務流程如下：采購人員登錄主界面，點擊供貨渠道管理鏈接，進入供貨渠道管理頁面；此時需要對采購人員身份進行驗證，因此系統轉入采購人員身份驗證界面；采購人員輸入身份信息，包括合法的用戶名和密碼，試圖登錄系統。系統將采購人員輸入的身份信息與數據庫中的信息進行比對，若兩者一致，則允許登錄，系統自動跳轉至供貨渠道管理界面。否則，系統給出登錄失敗信息，并重新轉至采購人員身份驗證界面，要求重新輸入身份信息；登錄成功后，采購人員可以對供貨渠道模塊進行相關的操作，包括新建、修改、刪除，或者查詢供貨渠道等；所有這些操作完成之后，需要點擊“提交”按鈕，提交表單，系統通過響應表單的提交，完成相應的操作并返回相應的結果；若在操作過程中，輸入的信息有誤，則系統會提示錯誤，并要求采購人員重新進行操作；信息無誤后，系統將更新后的信息存入數據庫，以備日后查詢或修改；退出系統，此次供貨渠道管理活動結束。時序圖例說明圖13供應商管理時序圖在上圖中，采購人員分別進行新建供貨渠道、修改供貨渠道、刪除供貨渠道以及提交供貨渠道等操作，并在操作完成后提交表單。在表單供貨渠道概要信息提交給項目對象的同時，還需要提交供貨渠道的明細信息給項目對象，由該對象對提交的表單進行處理，處理完畢，返回提交成功信息。4.1.2商品信息管理概述此模塊商品信息管理是針對商品詳細信息進行“創建、修改、刪除”等功能。在進銷存系統中，商品信息數據基礎資料，在供應商管理、商品價格管理、商品采購管理、質量管理、商品庫存管理、商品盤點管理模塊都會應用。關聯商品信息中“批準文號、重量”與“入庫單”存在逆向更新功能。在“入庫單”可以逆向修改商品信息中“批準文號、重量”信息，但商品信息中“批準文號、重量”修改，不會變更“入庫單”中信息；因為“入庫單”屬于工單記錄，需要記錄歷史數據；特別說明“商品庫存信息”中的“批準文號、重量”信息與“此模塊-商品信息管理”的信息保持一致。活動圖例說明圖14商品信息管理活動圖由以上活動圖，可以得到商品信息實現的業務流程如下：商品人員登錄主界面，點擊商品信息管理鏈接，進入商品信息管理頁面；此時需要對商品人員身份進行驗證，因此系統轉入商品人員身份驗證界面；商品人員輸入身份信息，包括合法的用戶名和密碼，試圖登錄系統。系統將商品人員輸入的身份信息與數據庫中的信息進行比對，若兩者一致，則允許登錄，系統自動跳轉至商品信息管理界面。否則，系統給出登錄失敗信息，并重新轉至商品人員身份驗證界面，要求重新輸入身份信息；登錄成功后，商品人員可以對商品信息模塊進行相關的操作，包括新建、修改、刪除，或者查詢商品信息等；所有這些操作完成之后，需要點擊“提交”按鈕，提交表單，系統通過響應表單的提交，完成相應的操作并返回相應的結果；若在操作過程中，輸入的信息有誤，則系統會提示錯誤，并要求商品人員重新進行操作；信息無誤后，系統將更新后的信息存入數據庫，以備日后查詢或修改；退出系統，此次商品信息管理活動結束。時序圖例說明圖15商品信息管理時序圖在上圖中，商品人員分別進行新建商品、修改商品、刪除商品以及提交商品信息等操作，并在操作完成后提交表單。在表單商品概要信息提交給項目對象的同時，還需要提交商品的明細信息給項目對象，由該對象對提交的表單進行處理，處理完畢，返回提交成功信息。4.1.3采購計劃管理概述此頁面是采購員與供應商達成采購協議后，在進銷存系統進行對應供應商的商品采購計劃登記的功能；此頁面的采購計劃是商品到貨后，為“驗收單”商品核驗工作提供基礎數據的作用。關聯1、此頁面獲取“商品信息管理”中商品基礎信息；2、此頁面獲取“商品庫存管理”中商品入庫信息；3、此頁面獲取“庫存上下限設置”計算的“庫存上下限數據”；4、此頁面獲取“供應商管理”中供應商信息；5、此頁面獲取“商品價格管理”中商品價格信息；6、此頁面還會獲取其它的信息，具體可見各個字段說明。范圍1、此頁面僅可選擇“正常”狀態的供應商；2、此頁面不可選擇“作廢狀態、停止采購”屬性的商品；3、“作廢狀態”數據來源于商品信息管理；4、“停止采購”數據來源于停止/恢復采購單。活動圖例說明圖16采購計劃管理活動圖由以上活動圖，可以得到采購計劃實現的業務流程如下：采購人員登錄主界面，點擊采購計劃管理鏈接，進入采購計劃管理頁面；此時需要對采購人員身份進行驗證，因此系統轉入采購人員身份驗證界面；采購人員輸入身份信息，包括合法的用戶名和密碼，試圖登錄系統。系統將采購人員輸入的身份信息與數據庫中的信息進行比對，若兩者一致，則允許登錄，系統自動跳轉至采購計劃管理界面。否則，系統給出登錄失敗信息，并重新轉至采購人員身份驗證界面，要求重新輸入身份信息；登錄成功后，采購人員可以對采購計劃模塊進行相關的操作，包括新建、修改、刪除，或者查詢采購計劃等；所有這些操作完成之后，需要點擊“提交”按鈕，提交表單，系統通過響應表單的提交，完成相應的操作并返回相應的結果；若在操作過程中，輸入的信息有誤，則系統會提示錯誤，并要求采購人員重新進行操作；信息無誤后，系統將更新后的信息存入數據庫，以備日后查詢或修改；退出系統，此次采購計劃管理活動結束。時序圖例說明圖17采購計劃管理時序圖在上圖中，采購人員分別進行新建采購計劃、修改采購計劃、刪除采購計劃以及提交采購計劃等操作，并在操作完成后提交表單。在表單采購計劃概要信息提交給項目對象的同時，還需要提交采購計劃的明細信息給項目對象，由該對象對提交的表單進行處理，處理完畢，返回提交成功信息。4.2數據庫的設計目標進銷存管理系統中的數據庫系統是整個系統的數據支撐，其建設將實現業務數據的集中存儲和管理。數據架構設計的好壞將直接影響到整個工程開發、運行及今后的穩定發展，因此需要規劃和設計一個合理的數據架構，對各類業務數據進行合理布局，從而滿足業務的正常運行及數據交互的需要，并適應新形式下業務流程未來可能的變化，形成系統穩定可靠的數據基礎。數據對于信息化系統有著至關重要的作用，從某種意義上講數據質量決定著信息化系統的成敗，因此，數據架構的重要性也就顯而易見了。權限設計采用細粒度權限管理，根據不同的崗位分配權限，再在崗位里分配角色和模塊，這樣可以給權限管理者減少工作復雜度，只需要把崗位設置完成后，就不用每次都去配置交涉和模塊，只需要把工作內容相同的操作員分配相同的崗位即可。權限的細粒度管理，可以給不同操作員展示不同的操作頁面，而不是根據不同按鈕的隱藏和顯示控制權限。例如：同一個“刪除”按鈕，A有操作權限就會看見此按鈕，B沒有權限就不會看到此按鈕，也不會在頁面的源代碼里看見此按鈕的操作代碼，這樣才能提高系統安全度。4.3數據庫的設計原則基于系統的總體架構以及功能需求，按照統一的共享信息資源標準進行共享數據庫設計時，擬遵循如下原則：1．不應該針對整個系統進行數據庫設計，而應該根據系統架構中的組件劃分，針對每個組件所處理的業務進行組件單元的數據庫設計；不同組件間所對應的數據庫表之間的關聯應盡可能減少，如果不同組件間的表需要外鍵關聯也盡量不要創建外鍵關聯，而只是記錄關聯表的一個主鍵，確保組件對應的表之間的獨立性，為系統或表結構的重構提供可能性。2．采用領域模型驅動的方式和自頂向下的思路進行數據庫設計，首先分析系統業務，根據職責定義對象。對象要符合封裝的特性，確保與職責相關的數據項被定義在一個對象之內，這些數據項能夠完整描述該職責，不會出現職責描述缺失。并且一個對象有且只有一項職責，如果一個對象要負責兩個或兩個以上的職責，應進行分拆。3．根據建立的領域模型進行數據庫表的映射，此時應參考數據庫設計第二范式：一個表中的所有非關鍵字屬性都依賴于整個關鍵字。關鍵字可以是一個屬性，也可以是多個屬性的集合，不論那種方式，都應確保關鍵字能夠保證唯一性。在確定關鍵字時，應保證關鍵字不會參與業務且不會出現更新異常，這時，最優解決方案為采用一個自增數值型屬性或一個隨機字符串作為表的關鍵字。4．由于第一點所述的領域模型驅動的方式設計數據庫表結構，領域模型中的每一個對象只有一項職責，所以對象中的數據項不存在傳遞依賴，所以，這種思路的數據庫表結構設計從一開始即滿足第三范式：一個表應滿足第二范式，且屬性間不存在傳遞依賴。5．同樣，由于對象職責的單一性以及對象之間的關系反映的是業務邏輯之間的關系，所以在領域模型中的對象存在主對象和從對象之分，從對象是從1－N或N－N的角度進一步主對象的業務邏輯，所以從對象及對象關系映射為的表及表關聯關系不存在刪除和插入異常。6．在映射后得出的數據庫表結構中，應再根據第四范式進行進一步修改，確保不存在多值依賴。這時，應根據反向工程的思路反饋給領域模型。如果表結構中存在多值依賴，則證明領域模型中的對象具有至少兩個以上的職責，應根據第一條進行設計修正。7．在經過分析后確認所有的表都滿足二、三、四范式的情況下，表和表之間的關聯盡量采用弱關聯以便于對表字段和表結構的調整和重構。并且，我認為數據庫中的表是用來持久化一個對象實例在特定時間及特定條件下的狀態的，只是一個存儲介質，所以，表和表之間也不應用強關聯來表述業務（數據間的一致性），這一職責應由系統的邏輯層來保證，這種方式也確保了系統對于不正確數據（臟數據）的兼容性。當然，從整個系統的角度來說我們還是要盡最大努力確保系統不會產生臟數據，單從另一個角度來說，臟數據的產生在一定程度上也是不可避免的，我們也要保證系統對這種情況的容錯性。這是一個折中的方案。8．應針對所有表的主鍵和外鍵建立索引，有針對性的（針對一些大數據量和常用檢索方式）建立組合屬性的索引，提高檢索效率。雖然建立索引會消耗部分系統資源，但比較起在檢索時搜索整張表中的數據尤其時表中的數據量較大時所帶來的性能影響，以及無索引時的排序操作所帶來的性能影響，這種方式仍然是值得提倡的。9．盡量少采用存儲過程，目前已經有很多技術可以替代存儲過程的功能如“對象/關系映射”等，將數據一致性的保證放在數據庫中，無論對于版本控制、開發和部署、以及數據庫的遷移都會帶來很大的影響。但不可否認，存儲過程具有性能上的優勢，所以，當系統可使用的硬件不會得到提升而性能又是非常重要的質量屬性時，可經過平衡考慮選用存儲過程。10．當處理表間的關聯約束所付出的代價（常常是使用性上的代價）超過了保證不會出現修改、刪除、更改異常所付出的代價，并且數據冗余也不是主要的問題時，表設計可以不符合四個范式。四個范式確保了不會出現異常，但也可能由此導致過于純潔的設計，使得表結構難于使用，所以在設計時需要進行綜合判斷，但首先確保符合四個范式，然后再進行精化修正是剛剛進入數據庫設計領域時可以采用的最好辦法。11．設計出的表要具有較好的使用性，主要體現在查詢時是否需要關聯多張表且還需使用復雜的SQL技巧。4.4數據庫的邏輯設計4.4.1數據字典分析系統中所設計的部分數據字典如下：采購計劃單{供應商ID、采購計劃編號、結算方式、狀態、地區、倉庫、審核人}驗收單{供應商ID、驗收單編號、地區、倉庫、狀態、結算方式}入庫單{供應商ID、入庫單編號、地區、倉庫、狀態、驗收單編號}配送單{配送單編號、地區、倉庫、狀態、客戶類型、生效人}銷售退回單{銷售退回編號，地區、倉庫、狀態、客戶類型、驗收結論}退貨調整單{退貨調整編號、狀態、地區、倉庫、結算方式、采購員、供應商ID}商品信息{商品編號、名稱、規格、單位、生產企業、重量、批準文號、條形碼、分類、產地、銷項稅率、化學名稱、地區、倉庫、是否處方、狀態}供應商信息{供應商編號、名稱、類型、地址信息、標識、供貨區域、結算銀行、結算方式、經營范圍、審核人、采購員}4.4.2整體E-R圖進銷存的核心內容是商品的庫存，進、銷、存都是圍繞庫存的一個系列操作，進：一個采購計劃對一個供應商，對應這個這個供應商的多個商品，繼而一個采購計劃對應一個驗收單，一個驗收單里對應多個商品，一個驗收單對應一個入庫單，一個入庫單對應多個商品，多個入庫單行程庫存。銷：所謂的銷就是銷售，配送單，一個配送對多個商品，多個商品對應多個供應商，對應多個批號、批次號、貨位號存：有了入庫單，配送單，銷售退回單的對應關系就行程庫存。整體E-R圖如圖所示：圖18系統E-R圖4.5數據庫的物理設計在完成數據庫的邏輯設計后，即可開始數據庫的物理設計。基于以上數據庫的邏輯設計，考慮程序設計的簡易性及通用性，本系統的數據庫采用MySQL5.5開發。以下是進銷存管理系統設計中所用的主要數據表結構4.5.1采購計劃表表5采購計劃表字段名稱類型空值備注CREATE_DTDATEY創建時間ISPASSNUMBER(22)Y是否傳驗收單0-否1-是CREATE_OPTERIDNUMBER(22)Y創建人idLAST_OPTERIDNUMBER(22)Y最后修改人idCHECKED_DTDATEY最后審核時間STOREIDNUMBER(22)Y倉庫idSTATUSNUMBER(22)N審核狀態CHECKED_RECORDVARCHAR2(500)Y審核內容IDNUMBER(22)NPURCHASENOVARCHAR2(20)N采購計劃編號PROVIDERIDNUMBER(22)N供應商idCLOSE_TYPENUMBER(22)Y結算方式AREAIDNUMBER(22)N機構區域1-北京CHECKEDNUMBER(22)N驗收狀態REMARKVARCHAR2(200)Y備注CHECKERNUMBER(22)Y審核人4.5.2驗收單表表6驗收單表字段名稱類型空值備注CLOSE_TYPENUMBER(22)Y結算方式OPERATERIDNUMBER(22)Y采購員idCREATE_DTDATEY創建時間REMARKVARCHAR2(300)Y備注PURCHASEIDNUMBER(22)Y采購計劃idPROVIDERIDNUMBER(22)Y供應商idSTATUS_CHKNUMBER(22)Y驗收狀態STATUSNUMBER(22)Y轉入庫單狀態CHECKNOVARCHAR2(20)Y驗收單號IDNUMBER(22)Nseq_check_idSTOREIDNUMBER(22)Y倉庫idCREATE_OPTERIDNUMBER(22)Y創建人idAREAIDNUMBER(22)Y機構區域1-北京4.5.3入庫單表表7入庫單表字段名稱類型空值備注REMARKVARCHAR2(300)Y備注CHECKIDNUMBER(22)Y驗收單idOPERATERIDNUMBER(22)Y采購員idCREATE_DTDATEN創建時間PROVIDERIDNUMBER(22)Y供應商idAREAIDNUMBER(22)Y機構區域STATUSNUMBER(22)Y入庫單狀態STORENOVARCHAR2(20)Y入庫單編號IDNUMBER(22)Nseq_store_idCONTRACTIDNUMBER(22)Y關聯的采購合同idBATCHIDNUMBER(22)Y關聯批號調整單idSOURCENUMBER(22)Y入庫單來源EFFECT_DTDATEY入庫單生效日期EFFECT_OPTERIDNUMBER(22)Y入庫單生效操作人STOREIDNUMBER(22)Y倉庫idCREATE_OPTERIDNUMBER(22)Y創建人idCLOSE_TYPENUMBER(22)Y結算方式4.5.4配送單表表8配送單表字段名稱類型空值備注STATUSNUMBER(22)N配送單狀態SENDNOVARCHAR2(20)N配送單號REMARKVARCHAR2(300)Y備注CREATE_DTDATEY創建時間OPERATERIDNUMBER(22)Y創建人idORDERNOVARCHAR2(20)Y第三方訂單編號IDNUMBER(22)Nseq_send_idSTOREIDNUMBER(22)Y倉庫idAREAIDNUMBER(22)Y區域idSEND_OPTERIDNUMBER(22)Y配送人idSEND_DTDATEY配送時間EFFECT_OPTERIDNUMBER(22)Y生效人EFFECT_DTDATEY生效時間CUSTOMER_TYPENUMBER(22)Y客戶類型4.5.5銷售退回單表表9銷售退回表字段名稱類型空值備注CUSTOMER_TYPENUMBER(22)Y客戶類型EFFECT_DTDATEY生效時間OPERATERIDNUMBER(22)N創建人idCREATE_DTDATENREMARKVARCHAR2(300)Y備注CHECK_CONTENTVARCHAR2(300)Y驗收結論TYPENUMBER(22)Y退貨類型ORDERNOVARCHAR2(20)Y網站的訂單號STATUSNUMBER(22)Y單據狀態AREAIDNUMBER(22)N機構區域REASONVARCHAR2(300)Y退貨原因SELLBACKNOVARCHAR2(20)N銷售退回單號IDNUMBER(22)Nseq_sell_back_idSTOREIDNUMBER(22)N倉庫idCHECKERIDNUMBER(22)Y驗收人CHECK_DTDATEY驗收時間EFFECT_OPTERIDNUMBER(22)Y生效人4.5.6退貨申請單表表10退貨申請單表字段名稱類型空值備注AREAIDNUMBER(22)Y退貨區域1-北京CLOSEIDNUMBER(22)Y結算方式REMARKVARCHAR2(200)Y備注BUYERIDNUMBER(22)Y采購人員PRIVODERIDNUMBER(22)Y供應商idBACKORDERNOVARCHAR2(20)Y退貨單號STOREIDNUMBER(22)Y倉庫idOPERATERIDNUMBER(22)Y創建人idCREATE_DTDATEN創建時間IDNUMBER(22)Nseq_back_apply_idSTATUSNUMBER(22)Y狀態4.5.7退貨調整單表11退貨調整單字段名稱類型空值備注ADJUSTNOVARCHAR2(20)Y調整單號IDNUMBER(22)Nseq_back_opt_idCHECK_DTDATEY審核時間CHECKERIDNUMBER(22)Y審核人BUYERIDNUMBER(22)Y采購人員AREAIDNUMBER(22)Y出庫單位1-北京CLOSE_TYPENUMBER(22)Y結算方式STOREIDNUMBER(22)Y倉庫idOPERATERIDNUMBER(22)Y操作員idREMARKVARCHAR2(200)Y備份CREATE_DTDATEY創建時間PAY_DTDATEY協議付款時間PROVIDERIDNUMBER(22)Y供應商idSTATUSNUMBER(22)Y狀態4.5.8退貨調整單表表12退貨調整單表字段名稱類型空值備注STATUSNUMBER(22)N退貨單狀態BACK_OPT_IDNUMBER(22)Y退貨調整單idREMARKVARCHAR2(300)Y備注CREATE_DTDATEN創建時間AREAIDNUMBER(22)Y區域dict_area表BACKNOVARCHAR2(20)N退貨單號IDNUMBER(22)Nseq_back_idSTOREIDNUMBER(22)Y倉庫idEFFECT_DTDATEY生效時間EFFECTERIDNUMBER(22)Y生效人CREATE_OPTERIDNUMBER(22)Y創建人PAY_DTDATEY協議付款時間CLOSE_TYPENUMBER(22)Y結算方式CHECK_DTDATEY審核時間STATUS_FNUMBER(22)Y凍結狀態BUYERIDNUMBER(22)Y采購員idPROVIDERIDNUMBER(22)Y供應商id4.5.9地區匯總表表13地區匯總表字段名稱類型空值備注FLAG_NAMEVARCHAR2(100)Y商品標識名字IDNUMBER(22)Nseq_summary_area_idLAST_BUYERVARCHAR2(20)Y最新采購人LAST_BUYERIDNUMBER(22)Y最新采購人idLAST_CLOSTYPEVARCHAR2(40)Y最新結算方式LAST_CLOSTYPEIDNUMBER(22)Y最新結算方式idLAST_PROVIDERNAMEVARCHAR2(100)Y最新供應商名稱LAST_PROVIDERNOVARCHAR2(20)Y最新供應商編碼LAST_PROVIDERIDNUMBER(22)Y最新供應商idLAST_ENDDTDATEY最新效期LAST_BIDNUMBER(22)Y最新進價MIN_BIDNUMBER(22)Y最低進價RATE_SELLNUMBER(22)Y毛利率AMOUNT_SELLNUMBER(22)Y最新售額AMOUNT_NOTAXNUMBER(22)Y無稅金額AMOUNTNUMBER(22)Y庫存金額STORE_MINNUMBER(22)Y庫存下限STORE_MAXNUMBER(22)Y庫存上限GIFT_CNTNUMBER(22)Y贈品數量STORE_CNTNUMBER(22)Y庫存數量UNITVARCHAR2(20)Y單位PRODUCTERVARCHAR2(100)Y生產商NORMSVARCHAR2(20)Y規格GOODSNAMEVARCHAR2(100)Y商品名稱GOODSNOVARCHAR2(20)Y商品編碼GOODSIDNUMBER(22)Y商品idAREAIDNUMBER(22)Y區域idAREAVARCHAR2(20)Y區域CATEIDNUMBER(22)Y分類idCATEVARCHAR2(100)Y分類名字組合FLAG_IDNUMBER(22)Y商品標識id4.5.10倉庫匯總表表14倉庫匯總表字段名稱類型空值備注FLAG_IDNUMBER(22)Y商品標識idLAST_BUYERVARCHAR2(20)Y最新采購人LAST_BUYERIDNUMBER(22)Y最新采購人idLAST_CLOSTYPEVARCHAR2(40)Y最新結算方式LAST_CLOSTYPEIDNUMBER(22)Y最新結算方式idLAST_PROVIDERNAMEVARCHAR2(100)Y最新供應商名稱LAST_PROVIDERNOVARCHAR2(20)Y最新供應商編碼LAST_PROVIDERIDNUMBER(22)Y最新供應商idSTATUS_SELLNUMBER(22)Y銷售狀態ALARM_CLASSNUMBER(22)Y報警級別ENDDTDATEY有效期效期RATE_SELLNUMBER(22)Y毛利率AMOUNT_SELLNUMBER(22)Y最新售額AMOUNT_NOTAXNUMBER(22)Y無稅金額AMOUNTNUMBER(22)Y庫存金額GIFT_CNTNUMBER(22)Y贈品數量STORE_CNTNUMBER(22)Y庫存數量UNITVARCHAR2(20)Y單位PRODUCTERVARCHAR2(100)Y生產商NORMSVARCHAR2(20)Y規格BATNOVARCHAR2(20)Y批號GOODSNAMEVARCHAR2(100)Y商品名稱GOODSNOVARCHAR2(20)Y商品編碼GOODSIDNUMBER(22)Y商品idSTOREIDNUMBER(22)Y倉庫idSTORE_NAMEVARCHAR2(20)Y倉庫名字AREAIDNUMBER(22)Y區域idAREA_NAMEVARCHAR2(20)Y區域CATEIDNUMBER(22)Y分類idCATEVARCHAR2(100)Y分類名字組合FLAG_NAMEVARCHAR2(100)Y商品標識名字IDNUMBER(22)Nseq_summary_area_id4.5.11商品信息表表15商品信息表字段名稱類型空值備注MEDICARENOVARCHAR2(20)Y醫保編碼MEDICARENAMEVARCHAR2(20)Y醫保名稱RXNUMBER(22)Y是否處方藥0-否1-是ISLOCALNUMBER(22)Y是否國產0-否1-是WEIGHTNUMBER(22)Y重量克HIDNUMBER(22)Y網站商品idSTATUS_ISBUYNUMBER(22)Y采購狀態STATUS_ISSELLNUMBER(22)Y銷售狀STATUS_PRICENUMBER(22)Y定價狀態APPROVALNOVARCHAR2(30)Y批準文號EFFECTVARCHAR2(200)Y功能療效STATUS_ISPRICENUMBER(22)Y是否可定價IDNUMBER(22)Nseq_goods_idGOODSNOVARCHAR2(20)Y商品編碼GOODSNAMEVARCHAR2(100)Y商品名稱PRODUCTERVARCHAR2(200)Y生產企業SELLTAXNUMBER(22)Y銷項稅率STATUSNUMBER(22)Y商品狀態PINYINVARCHAR2(200)Y助記碼PRODUCING_AREAVARCHAR2(100)Y商品產地SEPARATENUMBER(22)Y是否可拆零LAST_INDATEY最近入庫時間SELL_TYPENUMBER(22)Y經營方式GOODS_FLAGNUMBER(22)Y個性標識NORMSVARCHAR2(300)Y商品規格UNITVARCHAR2(50)Y單位BAR_CODEVARCHAR2(50)Y條形碼NEARESTNUMBER(22)Y最近失效天數CREATE_OPTERNUMBER(22)Y創建人CREATE_DTDATEN創建日期LAST_OPTERNUMBER(22)Y最近修改人ISMEDICARENUMBER(22)Y是否醫保REMARKVARCHAR2(200)Y備注CHEMICAL_NAMEVARCHAR2(100)Y化學名稱STOREVARCHAR2(100)Y儲存條件ENGLISH_NAMEVARCHAR2(100)Y英文名稱STORAGE_AREANUMBER(22)Y倉庫PRICE_AREANUMBER(22)Y區域1-北京LAST_DTDATEY最近修改日期CATEGORY_GROUP_IDNUMBER(22)Y類別組idCATEGORY_IDNUMBER(22)Y分類id4.5.12供應商表表16供應商表字段名稱類型空值備注IDNUMBER(22)Nseq_provider_idPROVIDERNOVARCHAR2(200)N供應商編碼PROVIDERNAMEVARCHAR2(100)N供應商名稱ADDRESSVARCHAR2(200)Y地址LEGALPERSONVARCHAR2(30)Y法人POSTCODEVARCHAR2(10)Y郵編FUNDNUMBER(22)Y注冊資金（萬元）ONWAYDAYSNUMBER(22)Y在途天數(天)BAD_RECORDVARCHAR2(200)Y不良記錄BUSINESS_TYPENUMBER(22)Y供應商類型PURCHASE_MINVARCHAR2(200)Y最低采購限制PROVIDER_FLAGNUMBER(22)Y供應商標志PROVIDER_TYPENUMBER(22)Y供應商類型SUPPLY_SCOPEVARCHAR2(100)Y供貨區域CREATE_DTDATEN創建時間CREATE_OPTERIDNUMBER(22)Y創建人LASTOPTER_DTDATEY最新修改時間CLOSE_DEPARTMENTVARCHAR2(100)Y結算部門CLOSE_TYPENUMBER(22)Y結算類型OPEN_BANKNUMBER(22)Y開戶行OPEN_BANK_NAMEVARCHAR2(100)Y開戶名稱OPEN_BANK_ACCOUNTVARCHAR2(50)Y銀行帳號TEMPVARCHAR2(200)YLAST_OPTERIDNUMBER(22)Y最新修改人idLAST_OPTERNAMEVARCHAR2(20)Y最新修改人名字PCODEVARCHAR2(50)Y供應商名稱首字母BUSINESS_SCOPTVARCHAR2(100)Y經營范圍CHECKERANUMBER(22)Y最新采購審核人idCHECKA_DTDATEY最新采購審核時間CHECKERBNUMBER(22)Y最新質檢審核人idCHECKB_DTDATEY最新質檢審核時間CHECKERCNUMBER(22)Y最新主管審核人idCHECKC_DTDATEY最新主管審核時間DELCONTENTVARCHAR2(200)Y作廢供應商說明BUYCONTENTVARCHAR2(200)Y采購人意見STATUS_BUYNUMBER(22)Y采購狀態STATUSNUMBER(22)N狀態CHECK_STEPNUMBER(22)N審核步驟4.6系統權限設計用戶權限管理，主要分為用戶管理、功能權限管理、角色管理、數據權限管理等功能模塊。SKIPIF1<01．用戶管理用戶管理用于管理系統本身的相關用戶及其權限，認證本系統各級管理及操作人員的身份以及控制各級用戶的訪問權限。按照業務上分工的不同，合理地把相關人員劃分為不同的類別或者組，以及不同的角色對模塊的訪問權限是本部分的關鍵。具體如圖17所示：圖19用戶、角色、功能映射圖用戶管理用于認證本系統使用者的身份和管理權限。每個用戶有相應的賬號和口令，系統可通過用戶賬號和口令等方式完成對用戶的身份認證。每個用戶有特定的管理權限，系統通過用戶的管理權限完成對用戶管理操作的授權。用戶的管理權限可通過角色等方式來賦予，每類用戶由不同的角色組合而成，系統可以將某一個或幾個角色賦予一個用戶，也可以將一個角色賦予多個用戶。2．功能權限管理對系統的全部服務資源進行注冊，并劃分到成各種模塊，模塊權限負責分配數據瀏覽、添加、修改、刪除、審核、查詢等操作，在系統運行的過程中，不是所有的用戶都會擁有這些權限的，根據需要定義角色權限。3．角色管理將系統中的若干在權限上可以歸并為一類的管理及操作權限制定為一個角色，通過對用戶指定角色的方式，賦予用戶相應的管理和操作權限。通過這種方式，系統對用戶的管理才有可能把針對某個用戶的管理轉變為針對某一類用戶的管理，讓人容易理解，也有層次感，同時保證了用戶管理的一致性、規范性。本系統提供系統級角色和應用級角色，能夠提供靈活的權限模型和實施模式。4．數據權限管理數據權限配置定義根據各類數據不同的特性和安全策略，對不同的用戶提供相應級別的訪問權限控制和分配，以保證數據庫中數據的安全性。數據權限配置定義通過數據權限、模塊權限、角色權限、用戶權限功能來實現。本系統采用基于國際廣泛商用的強制訪問控制模型（MACModel）作為數據權限管理的解決方案基礎模型。傳統的訪問控制模型大多易于自主訪問控制策略，即允許合法用戶以用戶或用戶組的身份訪問系統應用及應用數據，同時阻止非授權用戶的訪問，并且某些用戶還可以把自己所擁有的訪問權限授予其它用戶，并且控制權限的創建與修改通常由特權用戶執行。因此，這樣的訪問控制策略對于安全性較高的應用系統與數據，缺乏可靠的保護機制，并且特權用戶可以獲得全部數據的訪問權限，這也不符合數據權限的分級訪問原則。強制訪問控制模型實現了更為嚴格的訪問控制策略。相對于傳統權限控制模型，強制訪問控制模型最大的不同是多級訪問控制的設計策略，它的主要特點是系統對訪問主體（即訪問用戶）和受控對象（即應用數據）實行強制訪問控制，系統事先給訪問主體和受控對象分配不同的安全級別屬性，在實施訪問控制時，系統先對訪問主體和受控對象的安全級別屬性進行比較，再決定訪問主體能否訪問該受控對象。為了保證數據的完整性，在數據流向的定義方面不允許從級別低的應用到級別高的應用，也就是說用戶只能向比自己安全級別低的數據進行寫入，從而防止非法用戶創建或更新安全級別高的數據，避免越權、篡改等行為的產生。4.7系統安全性設計1．數據安全性針對管理系統需借助網絡資源實現信息共享和通信連接的特點，系統采用的安全手段主要包括：數據訪問控制、防火墻、VPN技術、線路備份等。訪問控制：用于對系統資源的訪問，防止未經授權而利用網絡訪問系統資源，利用已得到的身份認證信息，按統一好的規則實施對訪問的控制。可以采用VLAN的方法，限制用戶訪問權限。防火墻：防火墻在用戶訪問端和系統之間建立起一個安全網關，保護系統內部免受非法入侵者的傷害，但是防火墻會檢查過濾通過的IP包，對傳輸效率會有些許影響，目前系統使用的是首都機場股份公司提供的網絡資源中，在沒有外網干預的情況下，可以適當控制防火墻的開關。線路備份：為保證系統的通信正常，防止因通信線路異常而引起的傳輸錯誤或中斷業務的情況發生，本系統可借