【正文】 提交 編制 提交 編制 提交 編制 圖 53 財務過程數(shù)據(jù)流圖 應付款賬目 修改會計總賬 付款 顧客 核對應收款明細賬 接受并開收據(jù) 收據(jù) 修 改應收款明細賬 應收款明細賬 會計人員 供應商 核對應付款賬目 付款并修改應付款賬目 會計總賬 編制報表 會計報表 銷售分析報表 庫存報表 經(jīng)理 庫存配件 查詢庫存量 第六節(jié) 系統(tǒng)數(shù)據(jù)庫建模 ER 模型分析 1 N 1 N 1 N 1 1 1 1 1 1 N 1 1 1 1 1 N N 1 N N N 1 1 N N 1 N N M M N N 1 1 N 圖 61 ER 圖 銷售 顧客 配件 采購部門 供銷商 經(jīng)理 銷售部門 庫存配件 會計部門 應付款賬目 應收款明細賬 報表 客戶訂單 公司 合作 合作 編輯 接受 屬于 查詢 記錄 屬于 管理 參考 對應 產(chǎn)生 對應 管理 產(chǎn)生 屬于 購買 供應 圖 62 ER 圖 第七節(jié) 系統(tǒng) U/C 矩陣分析 圖 7 U/C 矩陣 顧客數(shù)據(jù) 發(fā)貨單 應收款賬目 銷售歷史 暫存訂單 公司訂單 到貨通知 應付款賬目 收付單據(jù) 會計總賬 報表 庫存 銷售管理 客戶管理 C U 銷售配件 U C U U U 記錄業(yè)務 C C 采購管理 記錄缺貨 U C U 追加訂貨 U C 驗貨入庫 U U C C U 財務管理 收付款 U U U U C 會計核算 U U U C U 編制報表 U U U U U C U 庫存管理 庫存管理 U U U C 監(jiān)督管理 U U U U U 數(shù)據(jù)類 功能 第三章 汽車 銷售 管理信息系統(tǒng)的系統(tǒng)設計 第一節(jié) 功能子系統(tǒng)劃分 根據(jù) U/C 矩陣分析，對汽車配件公司業(yè)務管理信息系統(tǒng)進行功能子系統(tǒng)劃分， 如圖 8 所示。同時，一個模塊還下分了子模塊，如銷售管理子系統(tǒng)下面包含了客戶管理和訂貨管理兩個子模塊。 目 錄 前言 1 第一 部分 項目管理與計劃 1 第二 部分 系統(tǒng)分析 具體如下圖所示。 我們調整貼現(xiàn)率可知，當貼現(xiàn)率為 5%時，系統(tǒng)具有經(jīng)濟上的可行性。 印 第 安 漢 堡 點 餐 系 統(tǒng)顧 客前 臺 / 電 話 接 線 員后 臺 管 理 員送 貨 員訂 單 管 理生 成 訂 單庫 存 控 制餐 品 管 理供 應 訂 貨i n c l u d e查 詢 訂 單i n c l u d e刪 除 訂 單i n c l u d e i n c l u d ei n c l u d e增 加 餐 品修 改 餐 品刪 除 餐 品**************二、 印第安漢堡點餐系統(tǒng)的用例描述 用例名稱 ： 生成訂單 簡要說明： 電話訂餐接線員或者前臺接到顧客的訂單， 生成訂單一式三聯(lián)。 (2) 當后臺管理員接 到顧客的退訂申請時，查詢到相應的 訂 單，進行刪除操作，并及時通知其他有關部門。 庫存量進行管理的用例描述 用例名稱：庫存控制 簡要說明：系統(tǒng)根據(jù)訂單的數(shù)量和內容減少相應的庫存量。 可選操作流程：如果交易不成功的話，送貨員應及時提醒后臺管理員，后臺管理員 應及時刪除相應訂單。 建立概念數(shù)據(jù)模型 綜上所述，我們建立的概念數(shù)據(jù)模型如下圖所示： P r o d u c t P K P r o I dP r o N a m eP r o P r i c eP r o P i c t u r eP r o A b s t r u c t D e r i v e d P r o A m o u n tL i n e i t e mQ u a n t i t yA c t u a l P r i c e D e r i v e L i n e A m o u n t0 . . 1b u y1A d m i n P K A d m i n I dA d m i n N a m e A d m i n P s d A d m i n T y p eO r d e r P K O r d e r I dO r d e r D a t e D e r i v e d S u b T o t a l D e r i v e d T o t a l A m o u n tC u s t o m e r P K C u s t I dC u s t N a m e M u l t i v a l u e d C u s t P h o n ec u s t A d d r e s s10 . . 1o r d e r 實驗六：將概念數(shù)據(jù)模型轉換為對象關系模型 對象關系數(shù)據(jù)模型是帶有面向對象擴充的關系數(shù)據(jù)模型，以關聯(lián)表或關系的形式描繪數(shù)據(jù)。類似的，控制將增加一個項目的責任 傳遞給了 ： LineItem。下圖是“預訂”用例的一個分析類圖： 第三部分 實驗八： 物理 數(shù)據(jù)庫設計 物理數(shù)據(jù) 庫設計 是對系統(tǒng) 存儲結構和存取方法等依賴于具體計算機結構的各項物理設計措施 的 設計 ， 涉及訪問的效率考慮因素比如響應時間和事務吞吐量，本實驗旨在確保用戶在運行查詢時不必等待不合理的時間，從而有效執(zhí)行任務。 “預定”用例的活動圖： 選 擇 餐 點 創(chuàng) 建 預 訂 確 認 預 訂 付 款 顧 客 子流程同步的活動圖 ： 接 受 訂 單 制 造 餐 品 完 成 訂 單 ： 狀 態(tài)圖 通過制定一個對象在自己的生存期間響應時間而經(jīng)歷的狀態(tài)序列以及對這些事件的響應來描述對象的行為。 LineItem（ OrderId ， ProId ， Quantity， ActualPrice， LineAmount） 規(guī)范化關系對象，進一步細化 由于 Customer 允許通過接收 多值 屬性違背了第一范式 ，因而 Customer 不是一個良構關系，而是一個對象關系，又因為我們進一步討論決定接收純粹的關系模型，因此將 Customer 分為關系，為： Customer（ CustId， CustomerName， CustAddress） CustPhone（ CustId， CustPhone） 對象關系模型 經(jīng)過一步步的細化，我們產(chǎn)生了 6 個對象類，導出的對象關系模型如下： Admin（ AdminId， AdminName， AdminPsd， AdminType） Order （ OrderId ， CustId ， AdminId ， OrderDate ， DerivedSubTotal ，DerivedTotalAmount） LineItem（ OrderId ， ProId ， Quantity， ActualPrice， LineAmount） Product （ ProId ， ProName ， ProPrice ， ProPicture ， ProAbstract ，DerivedProAmount） Customer（ CustId， CustomerName， CustAddress） CustPhone（ Cus