商店商場等進銷存管理系統(tǒng).doc

7 實例7.1 超市進銷存管理系統(tǒng)7.1.1 需求分析（1）背景說明隨著企業(yè)生產模式逐漸從勞動密集型向技術密集型轉變，建立在真實數(shù)據(jù)基礎上的科學理性的現(xiàn)代管理方式將會使企業(yè)在市場競爭中立于不敗之地。信息管理系統(tǒng)能及時為超市企業(yè)提供所需的真實數(shù)據(jù)，成為超市管理者進行決策的依據(jù)。任何一個超市都離不開商品的流通，離不開貨品的采購、庫存管理和商品銷售。因此，進銷存業(yè)務是超市的基礎業(yè)務。此次數(shù)據(jù)庫設計簡單模仿中等規(guī)模的超市管理系統(tǒng)，并將其抽象成一個由四部門組成、實現(xiàn)四大功能的系統(tǒng)。（2）各部門功能的劃分l 采購管理部門該部門負責跟蹤供應商的所有報價信息，降低庫存和采購成本；建立采購單及其明細表，動態(tài)掌握采購單的執(zhí)行情況；建立采購入庫單和采購退貨單，確保采購入庫和退貨及時、準確，實現(xiàn)對采購全過程的有效控制?？呻S時了解采購業(yè)務的付款和應付款情況；可實時跟蹤供應商的報價信息，掌握采購的入庫狀況，降低庫存成本和采購成本；可為財務管理部門提供采購成本核算。l 庫存管理部門該部門按分類、分級的模式對倉庫進行全面的管理和監(jiān)控，縮短了庫存信息流轉時間，使超市的物料管理層次分明、井然有序，為采購、銷售和生產提供依據(jù)；智能化的預警功能可自動提示存貨的短缺、超儲等異常狀況。完善的庫存管理功能，對超市的存貨進行全面的控制和管理，降低庫存成本。l 銷售管理部門銷售管理部門提供了銷售訂單管理，動態(tài)掌握銷售訂單的執(zhí)行情況；通過銷售出貨管理和銷售退貨管理，隨時掌握各類銷售數(shù)據(jù)，便于超市了解銷售相關信息。能提供銷售帳分析，實時統(tǒng)計銷售應收款回籠情況；能掌握銷售出庫狀況；能為財務部門提供銷售成本。l 財務管理部門財務管理部門根據(jù)銷售部門提供的銷售單計算付款金額，根據(jù)采購部門提供的進貨單計算支付金額，并根據(jù)需要定期進行各種類型的帳目統(tǒng)計，為企業(yè)銷售計劃的制定提供決策依據(jù)。（3）各子系統(tǒng)的功能分析及數(shù)據(jù)流圖根據(jù)各部門的不同功能，將該系統(tǒng)劃分為四個子系統(tǒng)，分別是：采購管理子系統(tǒng)、庫存管理子系統(tǒng)、銷售管理子系統(tǒng)和財務管理子系統(tǒng)，該系統(tǒng)的一層數(shù)據(jù)流圖如圖7.1所示：圖7.1 系統(tǒng)一層數(shù)據(jù)流圖 采購管理子系統(tǒng)采購管理子系統(tǒng)數(shù)據(jù)流圖細化如圖7.2。圖7.2 二層DFD 采購管理細化A. 對采購員提供的采購計劃生成采購訂單B. 對采購訂單進行管理（刪除、修改、查找）C. 將采購訂單發(fā)送給指定的供貨商，通知其訂貨D. 供貨商交付貨物時，系統(tǒng)根據(jù)采購訂單進行驗貨處理，若符合訂單內容，則填寫進貨單發(fā)送給倉庫管理系統(tǒng)；若不符合訂單內容，則生成退貨單發(fā)送給供應商 庫存管理子系統(tǒng)庫存管理子系統(tǒng)數(shù)據(jù)流圖細化如圖7.3。A. 倉庫管理員根據(jù)銷售管理部門提供的進貨單，對貨物進行驗收，若合格則入庫，生成入庫單記錄入庫商品的詳細信息，倉庫管理員同時修改庫存商品信息；若驗收不合格則進行退貨處理，系統(tǒng)生成退貨單B. 從倉庫提取貨物時，系統(tǒng)根據(jù)銷售部門提供的缺貨單，進行出庫管理，生成出庫單，并修改庫存商品信息C. 超市的高級管理人員如經(jīng)理，可以隨時對庫存信息進行查詢圖7.3 二層DFD 庫存管理細化 銷售管理子系統(tǒng)A. 根據(jù)顧客銷售的商品和商品信息，進行收銀處理，生成商品銷售記錄B. 對銷售記錄打印，生成銷售單據(jù)給顧客C. 在收銀處理過程中，可以對銷售信息進行修改、添加和刪除操作；收銀處理結束后，若銷售信息出現(xiàn)了錯誤，只能將該次銷售記錄取消，重新進行錄入D. 根據(jù)超市的銷售情況，實時檢測貨物數(shù)量，在貨物短缺前生成缺貨單，并將缺貨信息傳給庫存管理子系統(tǒng)。圖7.4 二層DFD 銷售管理細化 財務管理子系統(tǒng)A. 根據(jù)庫存管理部門的進貨單，計算每筆業(yè)務的應付款和應付款明細B. 根據(jù)銷售管理部門的銷售單，計算每筆業(yè)務的應收款和應收款明細C. 財務人員根據(jù)各種查詢需要對帳目進行查詢和統(tǒng)計D. 超市的高級管理人員如經(jīng)理，可以隨時對財務信息進行查詢圖7.5 二層DFD 財務管理細化（4）數(shù)據(jù)字典舉例名字：退貨單別名：退貨報表描述：退貨的依據(jù)定義：退貨單退貨單編號訂單編號負責人編號商品條碼商品類別商品數(shù)量金額供應商名稱退貨原因位置：采購退貨管理名字：入庫單別名： 描述：商品入庫時必須開具入庫單，表明商品已經(jīng)入庫定義：入庫單入庫單編號進貨單編號倉庫管理員編號入庫時間位置：庫存管理系統(tǒng)中使用名字：采購訂單別名：采購訂單描述：根據(jù)采購計劃生成的采購商品列表定義：采購訂單采購訂單編號采購開始日期負責人編號商品名稱商品數(shù)量供應商名稱位置：采購管理模塊名字：商品信息別名：商品檔案描述：所有商品的信息保存在商品檔案表中定義：商品檔案表條形碼商品名稱類別編號庫存上限庫存下限現(xiàn)有庫存量現(xiàn)價原價備注位置：庫存管理，銷售管理名字：銷售單別名：銷售信息，銷售發(fā)票描述：銷售的記錄，并打印給客戶作為收據(jù)定義：銷售單流水號銷售日期收銀員編號機號應收款實收款找回銷售明細位置：前臺銷售管理名字：銷售明細別名：銷售記錄描述：詳細的商品銷售信息定義：銷售明細流水號條形碼數(shù)量單價位置：銷售發(fā)票名字：編號別名：描述：所有的編號定義：編號1字母|數(shù)字10位置：系統(tǒng)名字：權限別名：描述：用戶使用本系統(tǒng)的權限級別，防止非授權的用戶更改系統(tǒng)的數(shù)據(jù)資料定義：編號1經(jīng)理等領導2采購員 3會計4倉庫管理員8銷售員位置：整個系統(tǒng)7.1.2 概念結構設計（1）繪制分E-R圖概念設計過程采用自底向上的設計方法,即首先定義各局部應用的概念結構,然后將它們集成起來,得到全局概念結構。根據(jù)需求分析給出的數(shù)據(jù)流圖,參照數(shù)據(jù)字典中的詳細描述,下面給出各個子系統(tǒng)的分E-R圖的設計及對其進行的各項調整。采購管理子系統(tǒng) 圖7.6 采購管理子系統(tǒng)E_R圖 實體屬性定義:l 職員（職員編號、姓名、權限、口令）l 商品（條形碼、商品名稱、類別編號、庫存上限、庫存下限、現(xiàn)有庫存量、現(xiàn)價、原價、備注）l 供貨商（供貨商編號、供貨商名稱、公司地址、聯(lián)系電話、Email）l 訂單（訂單編號、商品條碼、商品名稱、采購數(shù)量、采購開始日期、負責人編號、供應商名稱）l 進貨單（進貨單編號、訂單編號、商品條碼、商品名稱、商品類別、進貨數(shù)量、進貨日期、負責人編號）l 退貨單（退貨單編號、訂單編號、商品條碼、商品名稱、退貨數(shù)量、退貨原因、倉庫管理員編號、退貨時間） 實體間聯(lián)系：l 一個采購員可以填寫多份采購訂單，但是一份訂單只能由一個采購員負責；l 一份采購訂單中可以包含多種商品，一種商品也可以被多個訂單采購；l 一個供貨商可以供應多份采購訂單的采購要求，但是每份采購訂單只能交給一個供貨商處理；l 一張采購定單中的貨物可以分多次到貨，因此可以生成多張進貨單和退貨單。 說明：l 采購訂單也可以表示為“采購員供貨商商品”三個實體集之間的多對多聯(lián)系；l 由于采購員是職員的一種，為了操作簡便，將采購員抽象為職員實體集，用“權限”屬性來表示職員不同的身份。庫存管理子系統(tǒng)圖7.7 庫存管理子系統(tǒng)E_R圖 實體屬性定義:l 采購進貨單（采購進貨單編號、訂單編號、負責人編號）l 缺貨單（缺貨單編號、缺貨日期、負責人編號）l 職員（職員編號、姓名、權限、口令）l 入庫單（入庫單編號、進貨單編號、倉庫管理員編號、入庫時間）l 出庫單（出庫單編號、缺貨單編號、倉庫管理員編號、出庫時間）l 退貨單（退貨單編號、進貨單編號、倉庫管理員編號、退貨時間） 實體間聯(lián)系：l 一張進貨單中的商品可以由多個倉庫管理員在不同的時間分多次進行入庫處理，每次入庫時檢查合格的商品要生成入庫單入庫；檢查不合格的商品要生成退貨單退回給供貨商；l 一張缺貨單中的商品可以由多個倉庫管理員在不同的時間分多次進行出庫處理； 說明：l 由于在入庫單、出庫單中只涉及到倉庫管理員的編號，所以把倉庫管理員作為屬性而不是實體集處理；銷售管理子系統(tǒng)圖7.8 銷售管理子系統(tǒng)E_R圖 實體屬性定義:l 商品（條形碼、商品名稱、類別編號、庫存上限、庫存下限、現(xiàn)有庫存量、現(xiàn)價、原價、備注）l 銷售單（流水號、銷售日期、收銀員編號、機號、應收款、實收款、找回）l 缺貨單（缺貨單編號、缺貨日期、負責人編號） 實體間聯(lián)系：l 一張銷售單中可以包含多種商品，而一種商品也可以被包含在多個銷售單中，某個銷售單銷售的具體商品信息用銷售明細表示。l 一張缺貨單中可以包含多種商品，而一種商品也可以被包含在多個銷售單中，某個缺貨單銷售的具體商品信息用缺貨單明細表示。 說明：l 由于在銷售單中只涉及到收銀員的編號，所以把收銀員作為屬性而不是實體集處理。財務管理子系統(tǒng)圖7.9 財務管理子系統(tǒng)E_R圖 實體屬性定義:l 進貨單（進貨單編號、訂單編號、負責人編號、商品條碼、商品類別、商品數(shù)量、供應商名稱）l 銷售單（流水號、銷售日期、收銀員編號、機號、應收款、實收款、找回）l 商品（條形碼、商品名稱、類別編號、庫存上限、庫存下限、現(xiàn)有庫存量、現(xiàn)價、原價、備注）l 應付款（進貨單編號、付款日期、應付金額、會計）l 應收款（銷售單編號、收款日期、應收金額、會計） 實體間聯(lián)系：l 應付款記錄和進貨單一一對應；應收款記錄和銷售單一一對應l 每筆應付款記錄中可以包含多個商品，而每個商品可以包含在多個應付款記錄中，每筆應付款記錄中的具體付款信息由應付款明細表示l 每筆應收款記錄中可以包含多個商品，而每個商品可以包含在多個應收款記錄中，每筆應收款記錄中的具體付款信息由應收款明細表示（2）視 圖 集 成以上是四個子系統(tǒng)的分E-R圖設計及其調整的整個過程，接著要做的就是將所有的分E-R圖進行綜合,合成一個系統(tǒng)的總E-R圖。分兩步進行：第一步：合并。解決各分E-R圖之間的沖突，將各分E-R圖合并起來生成初步E-R圖。各分E-R圖之間的沖突主要有三類： 屬性沖突：l 屬性域沖突，即屬性值的類型、取值范圍或取值集合不同。由于本系統(tǒng)較簡單，所以并不存在這種沖突；l 屬性取值單位沖突。由于本系統(tǒng)較簡單，不存在這類沖突； 命名沖突：l 同名異義：由于本系統(tǒng)較簡單，所以不存在這類沖突；l 異名同義：采購管理子系統(tǒng)中的進貨單和庫存管理子系統(tǒng)中的采購進貨單命名不同但結構相同，因此統(tǒng)一名稱為進貨單； 結構沖突：l 同一對象在不同應用中具有不同的抽象：如職員實體，在各子系統(tǒng)中職員有不同的只能，本系統(tǒng)利用“權限”屬性將其統(tǒng)一成一個實體集。l 同一實體在不同分E-R圖中所包含的屬性個數(shù)和屬性排列次序不完全相同：由于本系統(tǒng)較簡單，所以并不存在這種沖突；第二步：修改和重構。消除不必要的冗余，生成總E-R圖，由于本系統(tǒng)在子系統(tǒng)設計階段就去掉了冗余，因此不存在這類問題，只需要將各分E-R圖直接進行合并即可。下面給出總E-R圖，如圖7.10。圖7.10 系統(tǒng)總E_R圖7.1.3 邏輯結構設計（1）與總E-R圖對應的關系模式 實體所對應的關系模式：職員（職員編號、姓名、權限、口令）商品（條形碼、商品名稱、類別編號、庫存上限、庫存下限、現(xiàn)有庫存量、現(xiàn)價、原價、備注）供貨商（供貨商編號、供貨商名稱、公司地址、聯(lián)系電話、Email）訂單（訂單編號、商品條碼、商品名稱、采購數(shù)量、采購開始日期、負責人編號、供應商名稱）進貨單（進貨單編號、訂單編號、商品條碼、商品名稱、商品類別、進貨數(shù)量、進貨日期、負責人編號）退貨單（退貨單編號、訂單編號、商品條碼、商品名稱、退貨數(shù)量、退貨原因、倉庫管理員編號、退貨時間）缺貨單（缺貨單編號、缺貨日期、負責人編號）入庫單（入庫單編號、進貨單編號、倉庫管理員編號、入庫時間）出庫單（出庫單編號、缺貨單編號、倉庫管理員編號、出庫時間）銷售單（流水號、銷售日期、收銀員編號、機號、應收款、實收款、找回）應付款（編號、進貨單編號、付款日期、應付金額、會計）應收款（編號、銷售單編號、收款日期、應收金額、會計） 聯(lián)系所對應的關系模式：l m：n聯(lián)系的轉換采購單明細（采購訂單編號、商品條碼、數(shù)量、類型、單價、金額）進貨單明細（進貨單編號、商品條碼、數(shù)量、類型）缺貨單明細（缺貨單編號、商品條碼、缺貨數(shù)量）退貨單明細（退貨單編號、商品條碼、退貨數(shù)量、原因）入庫明細（入庫單編號、商品條碼、數(shù)量）出庫明細（出庫單編號、商品條碼、數(shù)量）銷售明細（流水號、商品條碼、數(shù)量、單價、金額）應付款明細（進貨單編號、商品編號、商品單價、商品數(shù)量、單價、應付金額）應收款明細（銷售單編號、商品編號、商品單價、商品數(shù)量、單價、應收金額）l 1：n聯(lián)系的轉換供貨商和采購訂單之間的1：n聯(lián)系并入采購訂單關系；職員和采購訂單之間的1：n聯(lián)系并入采購訂單關系；采購訂單和進貨單之間的1：n聯(lián)系并入進貨單關系；采購訂單和退貨單之間的1：n聯(lián)系并入退貨單關系；進貨單和入庫單之間的1：n聯(lián)系并入入庫單關系；缺貨單和出庫單之間的1：n聯(lián)系并入出庫單關系； 關系模式的優(yōu)化：l 采購訂單（采購訂單編號、商品條碼、商品名稱、采購數(shù)量、采購開始日期、負責人編號、供應商名稱）該關系模式的主碼為K（采購訂單編號、商品條碼），存在的函數(shù)依賴集F包括：（采購訂單編號、商品條碼）采購數(shù)量采購訂單編號采購開始日期，負責人編號，供應商名稱商品條碼商品名稱所以，該關系模式屬于2NF。將原關系模式分解得到滿足3NF的關系模式集為：R1采購訂單（采購訂單編號、采購開始日期、負責人編號、供應商編號）R2商品信息（商品條碼、商品名稱）R3采購訂單詳細信息（采購訂單編號、商品條碼、采購數(shù)量）將R2和R3與關系模式商品和采購單明細合并。關系模式“進貨單”和“采購退貨單”與“采購訂單”的優(yōu)化過程相同。l 銷售單（流水號、銷售日期、收銀員編號、機號、應收款、實收款、找回）該關系模式中的 “找回”屬性值可以由“實收款”和“應收款”的差計算得到，因此不必存儲在數(shù)據(jù)庫中；l 采購單明細（采購訂單編號、商品條碼、數(shù)量、類型、單價、金額）優(yōu)化說明：“金額”沒有刪除, 因為在這一項上查詢比較頻繁, 如果每次查詢都計算, 必然使系統(tǒng)計算增加，性能降低。保留下來雖然造成了一定的冗余, 但提高了查詢的效率，利大于弊。應付款明細和應收款明細也作同樣的優(yōu)化。（2）用戶子模式設計 采購管理系統(tǒng)用戶子模式商品（條形碼、商品名稱、類別編號、現(xiàn)有庫存量、備注）采購單（采購訂單編號、采購開始日期、負責人編號、商品條碼、數(shù)量、類型、單價、金額、供貨商名稱、職員編號）供貨商（供貨商編號、供貨商名稱、公司地址、聯(lián)系電話、Email）因為采購部門對于超市的其他情況不會也不必關注，經(jīng)常使用的只有以上各項，所以在采購管理子系統(tǒng)上設立以上關系。 庫存管理系統(tǒng)用戶子模式進貨單（進貨單編號、訂單編號、商品條碼、數(shù)量、類型、負責人編號）采購退貨單（退貨單編號、訂單編號、倉庫管理員編號、商品條碼、數(shù)量、類型、退貨時間）入庫單（入庫單編號、進貨單編號、倉庫管理員編號、入庫時間、商品條碼、數(shù)量、類型）出庫單（出庫單編號、缺貨單編號、倉庫管理員編號、出庫時間、商品條碼、數(shù)量、類型）因為庫存管理部門對于超市的其他情況不會也不必關注，經(jīng)常使用的只有以上各項，所以在庫存管理子系統(tǒng)上設立以上關系。 銷售管理系統(tǒng)用戶子模式缺貨單（缺貨單編號、缺貨日期、負責人編號、商品條碼、缺貨數(shù)量）銷售單（流水號、銷售日期、收銀員編號、機號、應收款、實收款、找回、商品條碼、數(shù)量、單價）因為銷售管理部門對于超市的其他情況不會也不必關注，經(jīng)常使用的只有以上各項，所以在銷售管理子系統(tǒng)上設立以上關系。 財務管理系統(tǒng)用戶子模式應付款明細（進貨單編號、商品編號、商品單價、商品數(shù)量、單價、付款日期、應付金額、會計）應收款明細（銷售單編號、商品編號、商品單價、商品數(shù)量、單價、付款日期、應收金額、會計）7.1.4 物理結構設計（1） 存儲結構設計經(jīng)過分析可知,該超市進銷存管理系統(tǒng)中信息處理有以下特點：l 銷售部門的數(shù)據(jù)不僅經(jīng)常需要查詢,而且更新速度快。l 各個部門信息要求共享的信息較多。例如員工信息,商品信息等。但財務信息一般不共享。l 經(jīng)理部門有一定的特殊職能：匯總財務信息；制定采購計劃；安排貨物的入庫和出庫工作。針對這些特點，設計如下: 確定數(shù)據(jù)庫的存放位置為了提高系統(tǒng)性能，現(xiàn)根據(jù)應用情況將數(shù)據(jù)按照易變部分和穩(wěn)定部分、經(jīng)常存取部分和存取頻率較低的部分分別在兩個磁盤上存放。同時，考慮到本系統(tǒng)是多用戶的，為了提高效率，數(shù)據(jù)庫的備份的數(shù)據(jù)和日志文件將保存在磁帶中。l 經(jīng)常存取部分：職員（職員編號、姓名、權限、口令）商品（條形碼、商品名稱、類別編號、庫存上限、庫存下限、現(xiàn)有庫存量、現(xiàn)價、原價、備注）銷售單（流水號、銷售日期、收銀員編號、機號、應收款、實收款、找回）應收款（編號、銷售單編號、收款日期、應收金額、會計）銷售明細（流水號、商品條碼、數(shù)量、單價、金額）應收款明細（銷售單編號、商品編號、商品單價、商品數(shù)量、單價、應收金額）l 存取頻率較低的部分：供貨商（供貨商編號、供貨商名稱、公司地址、聯(lián)系電話、Email）采購訂單（采購訂單編號、采購開始日期、負責人編號、供貨商名稱、職員編號）缺貨單（缺貨單編號、缺貨日期、負責人編號）進貨單（進貨單編號、訂單編號、負責人編號）采購退貨單（退貨單編號、訂單編號、倉庫管理員編號、退貨時間）入庫單（入庫單編號、進貨單編號、倉庫管理員編號、入庫時間）出庫單（出庫單編號、缺貨單編號、倉庫管理員編號、出庫時間）應付款（編號、進貨單編號、付款日期、應付金額、會計）采購單明細（采購訂單編號、商品條碼、數(shù)量、類型、單價、金額）進貨單明細（進貨單編號、商品條碼、數(shù)量、類型）缺貨單明細（缺貨單編號、商品條碼、缺貨數(shù)量）退貨單明細（退貨單編號、商品條碼、退貨數(shù)量、原因）入庫明細（入庫單編號、商品條碼、數(shù)量）出庫明細（出庫單編號、商品條碼、數(shù)量）應付款明細（進貨單編號、商品編號、商品單價、商品數(shù)量、單價、應付金額） 確定系統(tǒng)配置本系統(tǒng)針對于一個中等規(guī)模的超市進行管理系統(tǒng)的設計，因此選擇的微機數(shù)量和規(guī)模都不必太大，但在系統(tǒng)設計時應考慮到超市的發(fā)展需求，在選擇硬件設備、服