【文章內(nèi)容簡介】 統(tǒng) 條件 描述 數(shù)據(jù)項 轉(zhuǎn)去主事件流 步驟號 備注 A1 4 系統(tǒng) 完成供貨商信息查詢 返回成功信息 查詢的供貨商信息 2 A2 4 系統(tǒng) 沒有完成供貨商信息查詢 返回失敗信息 查詢失敗的信息提示 2 供貨商信息修改用例概述 （ 1） 供貨商信息修改主事件流，如表 37 所示 。 表 37供貨商信息修改用例主事件流概述 步驟 角色 /系統(tǒng) 描述 數(shù) 據(jù)項 備注 7. 角色 進入修改界面 8. 系統(tǒng) 顯示修改界面 9. 角色 輸入所需 修改 的 供貨商信息 10. 系統(tǒng) 修改是否成功 修改成功 如果修改成功轉(zhuǎn)到 A1 如果修改不成功轉(zhuǎn)到 A2 （ 2） 供貨商信息修改用例概述 ,主要就是介紹有關供貨商信息的修改用例，同時介紹有關的主題領域、用例的定義以及業(yè)務的觸發(fā)事件、前置條件、和一些輸出概述，其中包括供應商信息的添加、主題領域是 供貨商信息修改 用例包、角色是 倉庫管理人員，并且介紹了事件產(chǎn)生的前置條件為有需要 修改 的 供貨商信息 記錄，還有就是在供應商信息修改的時候 需要所需 修改 的 供貨商信息，能夠?qū)绦畔⑦M行一些修改，根據(jù)以上 31 的系統(tǒng)總體用例圖，設計了系統(tǒng)的供應商信息修改用例概述，內(nèi)含供應商信息修改的介紹條件，如果是成功則是供應商信息修改成功，如果是不成功那就是未能對供應商信息進行修改，還有就是能夠?qū)绦畔⑦M行查詢修改，是 如表 38 所示。 12 信息科學與技術學院學士學位論文 表 38供貨商信息修改用例概述 用例名稱 供貨商信息修改 主題領域 供貨商信息修改 用例包 用例定義 供貨商信息修改 角色 倉庫管理人員 業(yè)務觸發(fā)事件 進行 供貨商信息修改 前置條件 有需要 修改 的 供貨商信息 記錄 結 束條件 1． 成功條件 查詢到需要 修改 的供貨商信息 2． 失敗條件 未查詢到需要 修改 的供貨商信息 相關用例 輸入概述 所需 修改 的 供貨商信息 輸出概述 修改結果 使用性備注 用例備注 （ 3） 供貨商信息修改分支事件流，如表 39 所示 。 表 39供貨商信息修改用例分支事件流概述 編號 主事件流步驟號 角色 /系統(tǒng) 條件 描述 數(shù)據(jù)項 轉(zhuǎn)去主事件流 步驟號 備注 A1 4 系統(tǒng) 完成供貨商信息修改 返回成功信息 修改的供貨商信息 2 A2 4 系統(tǒng) 沒有完成供貨商信息修改 返回失敗信息 修改失敗的 信息提示 2 供貨商信息添加用例概述 （ 1）供貨商信息添加用例概述 ,如表 310 所示 。 13 信息科學與技術學院學士學位論文 表 310供貨商信息添加用例概述 用例名稱 供貨商信息添加 主題領域 供貨商信息添加 用例包 用例定義 供貨商信息 角色 倉庫管理人員 業(yè)務觸發(fā)事件 進行 供貨商信息添加 前置條件 有需要添加的 供貨商信息 記錄 結束條件 3． 成功條件 查詢到需要添加的供貨商信息 4． 失敗條件 未查詢到需要添加的供貨商信息 相關用例 輸入概述 所需添加的 供貨商信息 輸出概述 添加結果 使用性備注 用例備 注 （ 2） 供貨商信息添加主事件流，如表 311 所示 。 表 311供貨商信息添加主事件流概述 步驟 角色 /系統(tǒng) 描述 數(shù)據(jù)項 備注 11. 角色 進入添加界面 12. 系統(tǒng) 顯示添加界面 13. 角色 輸入所需添加的 供貨商信息 14. 系統(tǒng) 添加是否成功 添加成功 如果添加成功轉(zhuǎn)到 A1 如果添加不成功轉(zhuǎn)到 A2 （ 3） 供貨商信息添加分支事件流， 主要就是介紹了系統(tǒng)中供貨商信息添加的一些分支時間流的編號、事件流產(chǎn)生的條件，同時還在其中介紹了分支事件流的數(shù)據(jù)項信息以及分支事件流觸發(fā)之后所專區(qū)主事件流的 步驟， 如表 312 所示。 表 312 供貨商信息添加分支事件流概述 編號 主事件流步驟號 角色 /系統(tǒng) 條件 描述 數(shù)據(jù)項 轉(zhuǎn)去主事件流 步驟號 備注 14 信息科學與技術學院學士學位論文 A1 4 系統(tǒng) 完成供貨商信息添加 返回成功信息 添加的供貨商信息 2 A2 4 系統(tǒng) 沒有完成供貨商信息添加 返回失敗信息 添加失敗的信息提示 2 ER 圖設計 ER 圖就是實體關系圖，主要完成了對系統(tǒng)中數(shù)據(jù)部分設計 [7]。 ER 圖為實體 聯(lián)系圖，提供了表示實體型、屬性和聯(lián)系的方法，用來描述現(xiàn)實世界的概念模型。構成 ER 圖的基本要素是實體 型、屬性和聯(lián)系。以下是系統(tǒng)的整個 ER 如圖 32 所示。 1 M M 1 1 M 1 M 圖 32 系統(tǒng)整體 ER圖 供應商 供應商名稱 簡稱 地址 聯(lián)系方式 倉庫 提供 商品 庫存 管理 操作員 屬于 管理員 商品名 簡稱 規(guī)格 產(chǎn)地 用戶名 密碼 用戶名 密碼 15 信息科學與技術學院學士學位論文 功能模塊設計圖 這一小節(jié)主要是介紹一下系統(tǒng)的一些功能模塊。 （ 1）食堂倉庫管理系統(tǒng)功能模塊包括： ①進貨管理模塊，主要功能是添加商品到庫房，同時將庫房需要退貨的商品進行退貨操作如上圖 33 所示 。 圖 33 進貨管理功能模塊圖 ②出庫管理模塊，主要功能是為管理員提供商品出庫的管理，如圖 34 所示。 圖 34出庫管理功能模塊圖 ③系統(tǒng)管理模塊，主要功能是對系統(tǒng)的用戶進行管理，包括增加用戶、修改用出庫管理模塊 出庫單 出庫退貨 進貨單 進貨退貨 進貨管理 16 信息科學與技術學院學士學位論文 戶密碼以及添加、刪除用戶等信息，如圖 35所示 。 圖 35系統(tǒng)管理模塊圖 ④查詢統(tǒng)計模塊，主要功能是對食堂信息查詢、商品查詢、供應商查詢、出庫查詢、出庫退貨查詢、入庫查詢等信息，如圖 36所示。 圖 36查詢統(tǒng)計模塊圖 ⑤基 礎信息管理模塊，主要功能是為管理員提供實現(xiàn)對食堂信息、供貨商信息、商品信息的管理維護，包括對信息查詢、添加、修改和刪除等一系列操作，如圖 37 系統(tǒng)管理 操作員操作 更改密碼 權限管理 查詢統(tǒng)計模塊 食堂查詢 商品查詢 供應商查詢 出庫退貨查詢 入庫查詢 17 信息科學與技術學院學士學位論文 所示。 圖 37基礎信息管理模塊圖 數(shù)據(jù)庫設計 （ 1） 數(shù)據(jù)庫設計 (Database Design)是指根據(jù)用戶的需求，在某一具體的數(shù)據(jù)庫管客戶信息管理 商品信息管理 供應商信息管理 食堂信息添加 食堂信息添加或刪除 商品信息添加 商品信息添加活刪除 供應商信息添加 供應商信息添加貨刪除 基礎信息管理 18 信息科學與技術學院學士學位論文 理系統(tǒng)上，設計數(shù)據(jù)庫的結構和建立數(shù)據(jù)庫的過程。一般，數(shù)據(jù)庫的設計過程大致可分數(shù)據(jù)庫設計為 6 個步驟： ① 需求分析 :調(diào)查和分析用戶的業(yè)務活 動和數(shù)據(jù)的使用情況，弄清所用數(shù)據(jù)的種類、范圍、數(shù)量以及它們在業(yè)務活動中交流的情況，確定用戶對數(shù)據(jù)庫系統(tǒng)的使用要求和各種約束條件等，形成用戶需求規(guī)約 [8]。 ② 概念設計 :對用戶要求描述的現(xiàn)實世界 (可能是一個工廠、一個商場或者一個學校等 )，通過對其中住處的分類、聚集和概括，建立抽象的概念數(shù)據(jù)模型。這個概念模型應反映現(xiàn)實世界各部門的信息結構、信息流動情況、信息間的互相制約關系以及各部門對信息儲存、查詢和加工的要求等。所建立的模型應避開數(shù)據(jù)庫在計算機上的具體實現(xiàn)細節(jié)，用一種抽象的形式表示出來。以擴充的實體 — （ ER 模型）聯(lián)系模型方法為例，第一步先明確現(xiàn)實世界各部門所含的各種實體及其屬性、實體間的聯(lián)系以及對信息的制約條件等，從而給出各部門內(nèi)所用信息的局部描述 (在數(shù)據(jù)庫中稱為用戶的局部視圖 )。第二步再將前面得到的多個用戶的局部視圖集成為一個全局視圖，即用戶要描述的現(xiàn)實世界的概念數(shù)據(jù)模型 [9]。 ③ 邏輯設計 :主要工作是將現(xiàn)實世界的概念數(shù)據(jù)模型設計成數(shù)據(jù)庫的一種邏輯模式，即適應于某種特定數(shù)據(jù)庫管理系統(tǒng)所支持的邏輯數(shù)據(jù)模式。與此同時，可能還需為各種數(shù)據(jù)處理應用領域產(chǎn)生相應的邏輯子模式。這一步設計的結果就是所謂“ 邏輯數(shù)據(jù)庫 ” [10]。 ④ 物理設計 :根據(jù)特定數(shù)據(jù)庫管理系統(tǒng)所提供的多種存儲結構和存取方法等依賴于具體計算機結構的各項物理設計措施，對具體的應用任務選定最合適的物理存儲結構 (包括文件類型、索引結構和數(shù)據(jù)的存放次序與位邏輯等 )、存取方法和存取路徑等。這一步設計的結果就是所謂 “ 物理數(shù)據(jù)庫 ” [11]。 ⑤ 驗證設計 :在上述設計的基礎上，收集數(shù)據(jù)并具體建立一個數(shù)據(jù)庫，運行一些典型的應用任務來驗證數(shù)據(jù)庫設計的正確性和合理性。一般，一個大型數(shù)據(jù)庫的設計過程往往需要經(jīng)過多次循環(huán)反復。當設計的某步發(fā)現(xiàn)問題時，可 能就需要返回到前面去進行修改。因此，在做上述數(shù)據(jù)庫設計時就應考慮到今后修改設計的可能性和方便性 [12]。 19 信息科學與技術學院學士學位論文 ⑥數(shù)據(jù)庫的完整性是指數(shù)據(jù)的正確性和有效性，是為防止數(shù)據(jù)庫中存在不符合語義規(guī)定的數(shù)據(jù)和防止因錯誤信息的輸入輸出造成無效操作或錯誤信息而提出的。數(shù)據(jù)庫的完整性包括 ：實體完整性、參照完整性和用戶定義完整性 。 實體完整性(Entity Integrity) ：現(xiàn)實世界的實體是可區(qū)分的，即它們具有某種唯一性標識。相應地，關系模型中主鍵應作為唯一性標識。因此實體完整性規(guī)則規(guī)定基本關系的所有主鍵 (Primary Key)都不能取空值 (NULL)。參照完整性（ Referential Integrity）：參照完整性維護表與表之間的相關性，通常用 “ 主鍵 (Primary Key)/外鍵 (Foreign Key)”保證，其中 Foreign Key 可以 取 NULL 值，或取其參照表中 Primary Key 的取值。用戶定義的完整性 (User_defined Integrity )：針對某一具體數(shù)據(jù)的約束條件，由應用環(huán)境決定。 數(shù)據(jù)庫完整性約束能夠防止合法用戶使用數(shù)據(jù)庫時向數(shù)據(jù)庫中添加不合語義的數(shù)據(jù) [13]。 數(shù)據(jù)庫的邏輯設計如下： （ 2）倉庫管理系統(tǒng)所用的數(shù)據(jù)庫是 SQL Server 2021，下面主要介紹數(shù)據(jù)庫的表。 如下是表 tb_gysinfo 的結構在數(shù)據(jù)庫的邏輯表示，供應商信息表包括的字段主要供應商的 ID、供應商的名稱、簡稱、地址、編碼、聯(lián)系方式，其中有些字段是為了后面設計商品信息進行關聯(lián)視圖的字段，如表 313 所示。 表 313供應商信息表 列名 數(shù)據(jù)類型 長度 允許空 Id varchar 50 name varchar 100 √ jc varchar 50 √ address varchar 100 √ bianma varchar 50 √