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