汽車銷售管理信息系統(tǒng)的系統(tǒng)規(guī)劃

1、77/77汽車銷售治理信息系統(tǒng)的系統(tǒng)規(guī)劃一、汽車銷售治理信息系統(tǒng)的系統(tǒng)規(guī)劃 項(xiàng)目開發(fā)背景隨著經(jīng)濟(jì)的進(jìn)展和中國(guó)汽車市場(chǎng)的不斷擴(kuò)大，某汽車配件公司也隨著進(jìn)展的浪潮不斷擴(kuò)大規(guī)模，隨之，訂單成倍增加，各項(xiàng)業(yè)務(wù)更加細(xì)化，各部門工作量增加，以往的人工處理方式就顯得力不從心，勞動(dòng)強(qiáng)度大而且容易出錯(cuò)。 項(xiàng)目開發(fā)目的 本課程設(shè)計(jì)的具體任務(wù)確實(shí)是設(shè)計(jì)一個(gè)企業(yè)內(nèi)部業(yè)務(wù)治理信息系統(tǒng)，利用現(xiàn)代計(jì)算機(jī)和數(shù)據(jù)庫(kù)開發(fā)技術(shù)來(lái)代替人工處理，從而減輕企業(yè)各部門工作人員的勞動(dòng)強(qiáng)度，提高工作質(zhì)量和效率，提高信息資源的利用率和企業(yè)治理水平。 可行性分析 現(xiàn)在企業(yè)的業(yè)務(wù)流程治理方式為手工處理，重復(fù)勞動(dòng)多，勞動(dòng)強(qiáng)度大，而且容易出錯(cuò)，新系統(tǒng)的

2、使用將有以下幾個(gè)方面的優(yōu)勢(shì)：從技術(shù)上考察處理速度快，準(zhǔn)確；通過(guò)權(quán)限的設(shè)置，數(shù)據(jù)的安全性好；方便查詢；操縱精度或生產(chǎn)能力的提高從經(jīng)濟(jì)上考察系統(tǒng)建設(shè)不需要專門大的投入；可縮減人員編制，減少人力費(fèi)用；人員利用率的改進(jìn)；從各種社會(huì)因素來(lái)考察可降低工作人職員作強(qiáng)度，提高效率，會(huì)得到企業(yè)上下職員的一致同意的；可引進(jìn)先進(jìn)的治理系統(tǒng)開發(fā)方案，從而達(dá)到充分利用企業(yè)現(xiàn)有資源綜上所述，本系統(tǒng)的開發(fā)立項(xiàng)是可行的。企業(yè)內(nèi)部業(yè)務(wù)治理信息系統(tǒng)的系統(tǒng)分析組織結(jié)構(gòu)與功能分析 圖1 組織結(jié)構(gòu)圖第二節(jié) 組織/業(yè)務(wù)關(guān)系圖業(yè)務(wù)聯(lián)系 組織業(yè)務(wù)程度銷售部會(huì)計(jì)部采購(gòu)部倉(cāng)庫(kù)經(jīng)理銷售活動(dòng)*財(cái)務(wù)治理*采購(gòu)活動(dòng)*庫(kù)存治理*行政監(jiān)督治理* 圖2 組織

3、/業(yè)務(wù)關(guān)系圖第三節(jié) 業(yè)務(wù)功能一覽表經(jīng)營(yíng)主管銷售主管經(jīng)營(yíng)主管銷售主管倉(cāng)庫(kù)主管采購(gòu)主管財(cái)務(wù)主管業(yè)務(wù)員倉(cāng)庫(kù)采購(gòu)員財(cái)務(wù)會(huì)計(jì)銷售員治理應(yīng)收款明細(xì)賬治理應(yīng)付款賬目治理會(huì)計(jì)總賬編制報(bào)表收款發(fā)出訂貨單驗(yàn)收物資入庫(kù)接收發(fā)貨單修改庫(kù)存量治理物資入庫(kù)出庫(kù)檢索庫(kù)存驗(yàn)證訂貨單修改訂貨單開發(fā)貨單檢查暫存訂貨單確定顧客訂貨 圖3 業(yè)務(wù)功能一覽表 第四節(jié) 業(yè)務(wù)流程圖銷售歷史銷售歷史公司檔案存檔會(huì)計(jì)人員暫定訂單核對(duì)驗(yàn)收入庫(kù)檢查暫存訂貨單應(yīng)收款明細(xì)賬核對(duì)應(yīng)收款明細(xì)賬采購(gòu)人員供應(yīng)商經(jīng)理訂貨配件匯總訂貨單填寫發(fā)貨單發(fā)貨單修改會(huì)計(jì)總賬會(huì)計(jì)總賬應(yīng)付款賬目同意并開收據(jù)修改應(yīng)收款明細(xì)賬編制報(bào)表查詢庫(kù)存量顧客銷售部門訂貨單庫(kù)存配件發(fā)貨單驗(yàn)證訂

4、貨單確定顧客訂貨檢索庫(kù)存開發(fā)貨單并修改庫(kù)存產(chǎn)生暫定訂單登錄新客戶數(shù)據(jù)客戶數(shù)據(jù)到貨通知修改庫(kù)存量付款業(yè)務(wù)員收據(jù)收據(jù) 圖4 業(yè)務(wù)流程圖 第五節(jié) 數(shù)據(jù)流程圖1.1.51.1.5登錄新顧客數(shù)據(jù)采購(gòu)人員業(yè)務(wù)人員1.1.1驗(yàn)證訂貨單1.1.4產(chǎn)生暫定訂單1.1.2確定顧客訂貨1.1.3開發(fā)貨單修改庫(kù)存暫定訂單應(yīng)收款明細(xì)賬庫(kù)存配件顧客數(shù)據(jù)銷售歷史顧客糾正錯(cuò)誤不合格訂單發(fā)訂單合格訂單不滿足訂貨 檢索滿足訂貨有新顧客 修改 開發(fā)貨單通知記錄記錄圖5-1 銷售過(guò)程數(shù)據(jù)流圖供貨商供貨商銷售部門采購(gòu)人員1.1.1訂貨配件匯總訂貨單1.1.2訂貨1.1.3填寫發(fā)貨單發(fā)貨單1.1.4核對(duì)驗(yàn)收入庫(kù)1.1.6辦理銷售業(yè)務(wù)發(fā)貨

5、單到貨通知庫(kù)存配件應(yīng)收款明細(xì)賬1.1.5通知銷售部門顧客確定給采購(gòu)人員發(fā)貨單發(fā)出到貨 通知記錄對(duì)比暫存訂單記錄產(chǎn)生 開出發(fā)貨圖5-2 采購(gòu)過(guò)程數(shù)據(jù)流圖應(yīng)付款賬目應(yīng)付款賬目1.1.5修改會(huì)計(jì)總賬1.1.1付款顧客1.1.2核對(duì)應(yīng)收款明細(xì)賬1.1.3同意并開收據(jù)收據(jù)1.1.4修改應(yīng)收款明細(xì)賬應(yīng)收款明細(xì)賬會(huì)計(jì)人員供應(yīng)商1.1.6核對(duì)應(yīng)付款賬目1.1.7付款并修改應(yīng)付款賬目會(huì)計(jì)總賬1.1.8編制報(bào)表會(huì)計(jì)報(bào)表銷售分析報(bào)表庫(kù)存報(bào)表經(jīng)理庫(kù)存配件1.1.9查詢庫(kù)存量給顧客收據(jù)開出現(xiàn)金支票轉(zhuǎn)賬無(wú)誤給會(huì)計(jì)發(fā)貨單無(wú)誤 修改 提供依據(jù) 提供依據(jù)提交編制提交編制提交編制圖5-3 財(cái)務(wù)過(guò)程數(shù)據(jù)流圖 銷售顧客配件采購(gòu)部門供

6、銷商銷售顧客配件采購(gòu)部門供銷商經(jīng)理銷售部門庫(kù)存配件會(huì)計(jì)部門應(yīng)付款賬目應(yīng)收款明細(xì)賬報(bào)表客戶訂單公司合作合作編輯同意屬于查詢記錄屬于治理參考對(duì)應(yīng)產(chǎn)生對(duì)應(yīng)治理產(chǎn)生屬于購(gòu)買供應(yīng)1N1N1N111111N11111NN1NNN11NN1 NNMMNN11N圖6-1 E-R圖圖6-2 E-R圖第七節(jié) 系統(tǒng)U/C矩陣分析功能數(shù)據(jù)類 功能數(shù)據(jù)類顧客數(shù)據(jù)發(fā)貨單應(yīng)收款賬目銷售歷史暫存訂單公司訂單到貨通知應(yīng)付款賬目收付單據(jù)會(huì)計(jì)總賬報(bào)表庫(kù)存銷售治理客戶治理CU銷售配件UCUUU記錄業(yè)務(wù)CC采購(gòu)治理記錄缺貨UCU追加訂貨UC驗(yàn)貨入庫(kù)UUCCU財(cái)務(wù)治理收付款UUUUC會(huì)計(jì)核算UUUCU編制報(bào)表UUUUUCU庫(kù)存治理庫(kù)存治

7、理UUUC監(jiān)督治理UUUUU 圖7 U/C矩陣汽車銷售治理信息系統(tǒng)的系統(tǒng)設(shè)計(jì)功能子系統(tǒng)劃分依照U/C矩陣分析，對(duì)汽車配件公司業(yè)務(wù)治理信息系統(tǒng)進(jìn)行功能子系統(tǒng)劃分， 如圖8所示。本系統(tǒng)只要花分為四個(gè)功能子系統(tǒng)：企業(yè)業(yè)務(wù)治理系統(tǒng)企業(yè)業(yè)務(wù)治理系統(tǒng)庫(kù)存治理財(cái)務(wù)治理采購(gòu)治理銷售治理會(huì)計(jì)賬目治理會(huì)計(jì)報(bào)表治理訂貨治理客戶治理采購(gòu)配件治理供應(yīng)商治理庫(kù)存量治理庫(kù)存查詢治理圖8 系統(tǒng)功能子系統(tǒng)圖銷售治理子系統(tǒng)：對(duì)客戶數(shù)據(jù)、訂貨處理等銷售業(yè)務(wù)進(jìn)行治理；財(cái)務(wù)治理子系統(tǒng)：負(fù)責(zé)各種報(bào)表和賬目的治理工作； 采購(gòu)治理子系統(tǒng)：治理供應(yīng)商信息，進(jìn)行采購(gòu)、收貨、驗(yàn)貨等采購(gòu)業(yè)務(wù)；庫(kù)存治理子系統(tǒng)：對(duì)倉(cāng)庫(kù)存貨進(jìn)行治理和監(jiān)督。層次化模塊結(jié)構(gòu)

8、圖汽車配件公司業(yè)務(wù)治理信息系統(tǒng)中，模塊劃分和處理過(guò)程設(shè)計(jì)是特不關(guān)鍵的一步，因此，我本著對(duì)系統(tǒng)可修改性、易讀性、易查錯(cuò)性等方面進(jìn)行設(shè)計(jì)。差不多思想是：1、模塊化；2、圖表文字解講。其中，HIPO圖是一種強(qiáng)有力的描述系統(tǒng)機(jī)構(gòu)和模塊內(nèi)部處理功能的工具，它要緊包括層次結(jié)構(gòu)圖和IPO圖兩個(gè)部分。層次結(jié)構(gòu)圖描述了整個(gè)系統(tǒng)的設(shè)計(jì)結(jié)構(gòu)以及各類模塊之間的關(guān)系；IPO圖則描述了在某個(gè)特定模塊內(nèi)部的輸入（I）、處理過(guò)程（P）、輸出（O）思想。企業(yè)業(yè)務(wù)治理系統(tǒng)企業(yè)業(yè)務(wù)治理系統(tǒng)庫(kù)存治理財(cái)務(wù)治理采購(gòu)治理銷售治理會(huì)計(jì)賬目治理會(huì)計(jì)報(bào)表治理訂貨治理客戶治理采購(gòu)配件治理供應(yīng)商治理庫(kù)存量治理庫(kù)存查詢治理 圖9-1 層次化結(jié)構(gòu)模塊圖

9、層次化結(jié)構(gòu)模塊圖是從結(jié)構(gòu)化設(shè)計(jì)的角度提出的一種工具。汽車配件公司業(yè)務(wù)治理信息系統(tǒng)的模塊化分為若干子系統(tǒng)，如銷售治理子系統(tǒng)、采購(gòu)治理子系統(tǒng)等，它們之間是平級(jí)關(guān)系，同時(shí)，相互之間也不交叉。同時(shí)，一個(gè)模塊還下分了子模塊，如銷售治理子系統(tǒng)下面包含了客戶治理和訂貨治理兩個(gè)子模塊。如此，從整體上來(lái)劃分，形成從全局來(lái)進(jìn)行治理的格局。訂貨治理訂貨治理A.1訂單輸入A.2.1訂單處理A.2.2開發(fā)貨單A.2.3圖9-2 層次化訂貨治理模塊結(jié)構(gòu)圖輸入部分輸入部分 I處理描述 P輸出部分 O1. 利用權(quán)限打開數(shù)據(jù)庫(kù)2. 輸入定貨單的顧客信息：名 稱、地址、電話、開戶行、賬號(hào)3. 輸入定貨單的各類信息：配 件名稱、規(guī)

10、格、編號(hào)核對(duì)用戶賬號(hào)和新建用賬號(hào)2. 核查定單信息3. 處理過(guò)程出錯(cuò)信息 定單不合格新建用戶合格定單處理老用戶合格定單處理將合格標(biāo)志送回上一級(jí)調(diào)用模式2. 將核對(duì)的記錄記入文件3. 修改顧客記錄4. 將合格的定單信息以標(biāo)準(zhǔn)格式輸出模塊名稱：定單輸入系統(tǒng)使用單位：銷售部圖10-1 訂單輸入IPO圖 訂單輸入IPO圖表示了訂單輸入模塊，講述了如何輸入客戶訂單，檢查其正確性，核對(duì)建立新的賬號(hào)等功能。模塊名稱：定單處理系統(tǒng)模塊名稱：定單處理系統(tǒng)使用單位：銷售部和采購(gòu)部輸入部分 I處理描述 P輸出部分 O1. 利用權(quán)限打開數(shù)據(jù)庫(kù)2. 上組模塊送入的合格的定單信息3. 輸入當(dāng)前各配件庫(kù)存量1. 將定單的配

11、件信息與配件當(dāng)前 存量核對(duì)2. 處理過(guò)程出錯(cuò)信息庫(kù)存量滿足定單要求處理庫(kù)存量暫缺處理零庫(kù)存量定單處理部分滿足庫(kù)存量處理1. 將合格標(biāo)志送回上一級(jí)調(diào)用模式2. 將核對(duì)的記錄記入文件3. 完全滿足定單要求輸動(dòng)身貨單4. 暫缺配件庫(kù)存量的暫存定貨單文件圖10-2 訂單處理IPO圖訂單處理IPO圖表示了訂單處理模塊，講述了如何核對(duì)處理訂單，對(duì)庫(kù)存量和訂單進(jìn)行比較處理等功能。模塊名稱：庫(kù)存量查詢系統(tǒng)模塊名稱：庫(kù)存量查詢系統(tǒng)使用單位：銷售部和經(jīng)理輸入部分 I處理描述 P輸出部分 O1. 利用權(quán)限打開數(shù)據(jù)庫(kù)2. 輸入查詢的配件編號(hào)、規(guī)格、名稱等信息3. 讀取近期銷售記錄4. 讀取原有配件庫(kù)存量1. 核對(duì)配件

12、信息和原有配件庫(kù)存量2. 核查近期銷售記錄情況 3. 處理過(guò)程出錯(cuò)信息當(dāng)前零庫(kù)存量配件處理當(dāng)前庫(kù)存量詳細(xì)處理1. 將合格標(biāo)志送回上一級(jí)調(diào)用模式2. 將核對(duì)的記錄記入文件3. 輸出銷售庫(kù)存的當(dāng)前查詢結(jié)果文件圖10-3 庫(kù)存查詢IPO圖庫(kù)存查詢IPO圖表示了庫(kù)存查詢治理模塊，講述了如何核對(duì)配件信息和原有配件庫(kù)存量，核查近期銷售記錄情況以及對(duì)出錯(cuò)信息的處理。暫存訂單輸入暫存訂單輸入C.2.1C.2配件采購(gòu)治理C.2.2暫存訂單處理C.2.3配件入庫(kù)圖9-3 層次化配件采購(gòu)治理模塊結(jié)構(gòu)圖模塊名稱：暫存訂單處理系統(tǒng)模塊名稱：暫存訂單處理系統(tǒng)使用單位：采購(gòu)部輸入部分 I處理描述 P輸出部分 O1. 利用權(quán)

13、限打開數(shù)據(jù)庫(kù)2. 輸入暫存訂貨單配件信息： 編號(hào)、規(guī)格、名稱、暫缺數(shù)量等3. 讀取供應(yīng)商列表信息1. 核查暫存訂貨單配件匯總信息2. 核對(duì)暫存配件和相應(yīng)的供應(yīng)商列表3. 處理過(guò)程1. 將合格標(biāo)志送回上一級(jí)調(diào)用模式2. 將核對(duì)的記錄記入文件3. 修改供應(yīng)商列表信息4. 輸出以供應(yīng)商分類的采購(gòu)訂貨單出錯(cuò)信息按配件匯總處理按供應(yīng)商匯總處理圖10-4 暫存訂單處理IPO圖暫存訂單處理IPO圖表示了暫存訂單治理模塊，講述了如何核查暫存訂單配件匯總信息，核對(duì)暫存配件和相應(yīng)的供應(yīng)商的列表等處理過(guò)程。模塊名稱：配件入庫(kù)處理系統(tǒng)模塊名稱：配件入庫(kù)處理系統(tǒng)使用單位：采購(gòu)部輸入部分 I處理描述 P輸出部分 O1.

14、利用權(quán)限打開數(shù)據(jù)庫(kù)2. 上組中輸出的采購(gòu)訂貨單信息3. 輸入供應(yīng)商發(fā)貨信息4. 讀取原庫(kù)存量信息5. 讀取標(biāo)準(zhǔn)配件質(zhì)量信息1. 核對(duì)采購(gòu)訂貨單和發(fā)貨單信息2. 核對(duì)發(fā)貨配件質(zhì)量信息和標(biāo)準(zhǔn)配件 質(zhì)量信息3. 處理過(guò)程出錯(cuò)信息核對(duì)出錯(cuò)質(zhì)量不合格不合格配件處理合格配件入庫(kù)處理1. 將合格標(biāo)志送回上一級(jí)調(diào)用模式2. 將核對(duì)記錄記入文件3. 修改庫(kù)存量信息4. 修改應(yīng)付款明細(xì)帳圖10-5 配件入庫(kù)處理IPO圖配件入庫(kù)處理IPO圖表示了配件治理模塊，講述了如何核對(duì)采購(gòu)訂貨單合法貨單信息，核對(duì)發(fā)貨配件質(zhì)量信息和標(biāo)準(zhǔn)配件質(zhì)量信息等功能。第五章 系統(tǒng)設(shè)計(jì)總結(jié)項(xiàng)目實(shí)施中各個(gè)工作流程及時(shí)刻分布項(xiàng)目開發(fā)的編寫 1天業(yè)

15、務(wù)流程圖設(shè)計(jì) 2天數(shù)據(jù)流程圖設(shè)計(jì) 1天E-R圖設(shè)計(jì) 1天U/C矩陣設(shè)計(jì) 2天HIPO圖設(shè)計(jì) 2天文檔修改、定稿 1天本人系統(tǒng)設(shè)計(jì)特點(diǎn)優(yōu)點(diǎn)：本系統(tǒng)具有較強(qiáng)的直觀性，設(shè)計(jì)完整，能較好的體現(xiàn)系統(tǒng)的設(shè)計(jì)構(gòu)思；缺點(diǎn)：設(shè)計(jì)的有些方面有點(diǎn)簡(jiǎn)單，有專門多地點(diǎn)還需進(jìn)一步分析改進(jìn)。 目 錄前言1第一部分 項(xiàng)目治理與打算1實(shí)驗(yàn)1 制定項(xiàng)目打算1實(shí)驗(yàn)2 項(xiàng)目可行性分析1第二部分 系統(tǒng)分析1實(shí)驗(yàn)3 項(xiàng)目需求收集1實(shí)驗(yàn)4 用例建模1實(shí)驗(yàn)5 通過(guò)用例獵取概念數(shù)據(jù)模型1實(shí)驗(yàn)6 將概念數(shù)據(jù)模型轉(zhuǎn)換為對(duì)象關(guān)系模型1實(shí)驗(yàn)7 分析類圖建模（序列圖、交互圖、狀態(tài)圖、活動(dòng)圖）1實(shí)驗(yàn)8 確定設(shè)計(jì)方案（*）1第三部分 系統(tǒng)設(shè)計(jì)1實(shí)驗(yàn)9 物理

16、數(shù)據(jù)庫(kù)設(shè)計(jì)1實(shí)驗(yàn)10 確定系統(tǒng)構(gòu)架等設(shè)計(jì)元素、設(shè)計(jì)類圖建模1實(shí)驗(yàn)11 界面設(shè)計(jì)1第四部分 系統(tǒng)實(shí)現(xiàn)1實(shí)驗(yàn)12 系統(tǒng)實(shí)現(xiàn)代碼（*）1附錄：項(xiàng)目成員分工情況1備注：*為選做實(shí)驗(yàn)。第一部分實(shí)驗(yàn)一：制定項(xiàng)目打算實(shí)驗(yàn)二：制定項(xiàng)目打算從經(jīng)濟(jì)上分析項(xiàng)目的可行性投資成本印第安漢堡餐品預(yù)定系統(tǒng)在投資成本上包括兩方面，一次性成本和續(xù)生成本。一次性成本包括基建投資和其他一次性投資，具體是指與項(xiàng)目活動(dòng)、系統(tǒng)開發(fā)和系統(tǒng)啟用有關(guān)的費(fèi)用，包括在該信息系統(tǒng)開發(fā)過(guò)程中全部一次性投入，如系統(tǒng)開發(fā)、新硬件和軟件的采購(gòu)，用戶培訓(xùn)、站點(diǎn)預(yù)備、數(shù)據(jù)或系統(tǒng)轉(zhuǎn)化。依照搜集到的資料顯示，印第安漢堡的餐品預(yù)定系統(tǒng)的一次性成本如下所示：PC機(jī)：2

17、臺(tái)，5000*2=10000元Microsoft SQL Server 2005（1套）：5000元Microsoft Server2008（1套）：10000元打印機(jī)1臺(tái)：1000元人員培訓(xùn)：7人/2000元，合計(jì)14000元總計(jì)：本系統(tǒng)開發(fā)的一次性投入為40000元，同時(shí)新系統(tǒng)需在6個(gè)月內(nèi)實(shí)現(xiàn)。經(jīng)常性支出是指由于正在進(jìn)行的系統(tǒng)演化和使用而產(chǎn)生的費(fèi)用，例如應(yīng)用軟件維護(hù)、逐漸增加的數(shù)據(jù)存儲(chǔ)費(fèi)用、增加的溝通、新軟件和硬件租借以及消費(fèi)用品和其他支出等。依照搜集到的資料顯示，在印第安漢堡的餐品預(yù)定系統(tǒng)中，這種經(jīng)常性投入表現(xiàn)為續(xù)生成本，同時(shí)需要連續(xù)投資5年，具體如下所示：預(yù)定系統(tǒng)的維護(hù)：1000元/年

18、*5年=5000元每年增加的數(shù)據(jù)存儲(chǔ)費(fèi)用：5000元/年*5年=25000元消費(fèi)用品支出：800元/年*5年=4000元其他支出：1000元/年*5年=5000元綜上可得，印第安漢堡的餐品預(yù)定系統(tǒng)為15000美元/年，折算為現(xiàn)值為96862元。具體如下圖所示。（貼現(xiàn)率為10%時(shí)）投資收益由于我們的系統(tǒng)結(jié)構(gòu)較為簡(jiǎn)單，功能單一，初期投入后利潤(rùn)也可不能有太多。我們同樣將系統(tǒng)運(yùn)行后的投資收益分為一次性收益和經(jīng)常性收益。依照預(yù)測(cè)，印第安漢堡的餐品預(yù)定系統(tǒng)的投資收益如下所示：1 一次性收益：無(wú)。2 經(jīng)常性收益：（1）由于系統(tǒng)的改進(jìn)而增加的收益：2000元/年*5=10000元（2）市場(chǎng)占有率的提高而增加的

19、收益（假設(shè)市場(chǎng)占有率以每年10%增加）1000+1000*（1+10%）1+1000*（1+10%）2+1000*（1+10%）3+1000*（1+10%）4+1000*（1+10%）5=7716元（3）效率的提高：1000元/年*5=5000元（4）不可定量的其他收益：5年共2284元開發(fā)該訂餐系統(tǒng)，當(dāng)其投入運(yùn)行后，每年的凈收益為25000元，再考慮貨幣的時(shí)刻價(jià)值，系統(tǒng)每年的凈收益如下所示。（貼現(xiàn)率為10%時(shí)）綜上可知，五年內(nèi)系統(tǒng)的總收益為94770美元。成本/收益分析通過(guò)上述成本收益的分析可知，當(dāng)貼現(xiàn)率為10%時(shí)，新開發(fā)的信息系統(tǒng)總成本為96862元，總收益為94770元。由于總成本是大于

20、總收益的，因此系統(tǒng)越運(yùn)行，越虧損，該信息系統(tǒng)不具備經(jīng)濟(jì)上的可行性。我們調(diào)整貼現(xiàn)率可知，當(dāng)貼現(xiàn)率為5%時(shí)，系統(tǒng)具有經(jīng)濟(jì)上的可行性。（貼現(xiàn)率為5%）總成本為104942美元?？偸找鏋?08237美元。（貼現(xiàn)率為5%）成本收益分析投資回收期為第4.58年。投資回報(bào)率為3.14%凈收益108237美元-104942美元=3295美元。從經(jīng)濟(jì)上考慮，當(dāng)貼現(xiàn)率為5%是，新系統(tǒng)在經(jīng)濟(jì)上具有可行性。第二部分實(shí)驗(yàn)三：項(xiàng)目需求收集我們選擇訪談的形式進(jìn)行需求收集，分不對(duì)顧客、服務(wù)員、廚師進(jìn)行提問(wèn)，以下是我們?cè)O(shè)計(jì)的問(wèn)題針對(duì)顧客：1 您更偏重哪種口味的漢堡 飲料 冰淇淋2 能講一下漢堡 飲料 冰淇淋與季節(jié)的關(guān)系嗎3 您

21、希望多長(zhǎng)時(shí)刻拿到您的定餐4 您一般什么時(shí)候來(lái)店里消費(fèi)5 您希望我們店通過(guò)什么方法實(shí)現(xiàn)個(gè)性化推舉，發(fā)傳單 貼海報(bào) 咨詢服務(wù)員針對(duì)服務(wù)員：1 一天中什么時(shí)候是消費(fèi)的最高峰2 你覺(jué)得什么樣的界面操作比較方面3 你覺(jué)得系統(tǒng)存在什么樣的問(wèn)題4 您對(duì)系統(tǒng)有什么樣的改進(jìn)意見(jiàn)5 您覺(jué)得訂餐系統(tǒng)對(duì)企業(yè)帶了的效益體現(xiàn)在哪里針對(duì)廚師：1 您希望多長(zhǎng)時(shí)刻來(lái)預(yù)備漢堡 飲料 冰淇淋2 現(xiàn)在一天大約做多少漢堡 飲料 冰淇淋 （庫(kù)存的要求）3 對(duì)那個(gè)系統(tǒng)您最不喜愛(ài)的是什么4 您對(duì)訂餐系統(tǒng)在缺貨處理上有如何樣的評(píng)價(jià)5 您覺(jué)得訂餐系統(tǒng)對(duì)你的工作有何關(guān)心最可能得到的文檔是訪談?dòng)涗洠畈豢赡艿玫降奈臋n是觀看筆記實(shí)驗(yàn)四：用例建模我們?yōu)?/p>

22、印第安漢堡構(gòu)建的信息系統(tǒng)要緊是為了方便客戶點(diǎn)餐以及治理員及時(shí)進(jìn)行庫(kù)存操縱，以減少顧客在點(diǎn)餐和取餐時(shí)的時(shí)刻開銷，為印第安漢堡贏取更大的利益。一、印第安漢堡點(diǎn)餐系統(tǒng)的用例圖如下所示。二、印第安漢堡點(diǎn)餐系統(tǒng)的用例描述1.顧客通過(guò)印第安漢堡的點(diǎn)餐系統(tǒng)生成訂單的用例描述用例名稱：生成訂單簡(jiǎn)要講明：電話訂餐接線員或者前臺(tái)接到顧客的訂單，生成訂單一式三聯(lián)。參與者：電話訂餐接線員或者前臺(tái)前置條件：顧客的訂餐需求是有效的后置條件：生成正確的訂單，包括顧客的姓名、電話、住址以及訂單編號(hào) 等基礎(chǔ)內(nèi)容。假設(shè)條件：電話訂餐接線員或者前臺(tái)差不多成功登錄訂餐系統(tǒng)差不多操作流程：（1）接線員或者前臺(tái)接收到顧客的有效訂餐（2）

23、在訂餐系統(tǒng)中輸入顧客需求的餐品名稱進(jìn)行查詢，比對(duì)顧客對(duì)餐品的需求量和庫(kù)存量。（3）在庫(kù)存充足的條件下，點(diǎn)擊進(jìn)入目標(biāo)餐品的預(yù)訂頁(yè)面，要求顧客報(bào)送姓名、電話及住址信息，點(diǎn)擊“確認(rèn)按鈕”生成訂單，此項(xiàng)操作只針對(duì)電話訂餐接線員，如為前臺(tái)訂餐，直接在庫(kù)存充足的情況下，點(diǎn)擊“確定”按鈕生成訂單一式三聯(lián)即可。（4）系統(tǒng)將顧客的訂單信息寫入數(shù)據(jù)庫(kù)，以進(jìn)行庫(kù)存治理?？蛇x操作流程：（1）顧客有信息輸入錯(cuò)誤的，前臺(tái)人員不予以確認(rèn)原錯(cuò)誤訂單，再按照顧客的正確信息重新生成訂單即可。（2）顧客在訂餐過(guò)程中臨時(shí)決定退訂的，操作如“顧客信息輸入有誤”同樣處理。2.治理員對(duì)數(shù)據(jù)庫(kù)中的訂單進(jìn)行治理的用例描述用例名稱：訂單治理簡(jiǎn)要

24、講明：由后臺(tái)治理員對(duì)差不多生成的訂單進(jìn)行查詢和刪除參與者：后臺(tái)治理員前置條件：點(diǎn)餐系統(tǒng)中存在業(yè)已生成的訂單后置條件：顯示訂單信息、刪除相應(yīng)的訂單假設(shè)條件：后臺(tái)治理員使用專門賬號(hào)正確登錄到點(diǎn)餐系統(tǒng)差不多操作流程：(1) 后臺(tái)治理員輸入需要查詢的訂單編號(hào)，也能夠通過(guò)顧客名稱、電話號(hào)碼等進(jìn)行訂單查詢。(2) 當(dāng)后臺(tái)治理員接到顧客的退訂申請(qǐng)時(shí)，查詢到相應(yīng)的訂單，進(jìn)行刪除操作，并及時(shí)通知其他有關(guān)部門。(3) 后臺(tái)治理員實(shí)時(shí)查詢庫(kù)存量，向有關(guān)部門報(bào)告，進(jìn)行有效的庫(kù)存操縱?？蛇x操作流程：關(guān)于餐品差不多送出后接到顧客退訂申請(qǐng)的，及時(shí)刪除相應(yīng)的訂單。3.后臺(tái)治理員對(duì)餐品進(jìn)行治理用例描述用例名稱：餐品治理簡(jiǎn)要講明

25、：后臺(tái)治理員依照公司業(yè)務(wù)進(jìn)展的需要對(duì)點(diǎn)餐系統(tǒng)中供應(yīng)的餐品進(jìn)行增、刪、該操作。參與者：后臺(tái)治理員前置條件：點(diǎn)餐系統(tǒng)中確實(shí)存在需要修改的餐品信息后置條件：顯示更新后的餐品信息假設(shè)條件：后臺(tái)治理員使用專門賬號(hào)正確登錄到點(diǎn)餐系統(tǒng)差不多操作流程：(1) 后臺(tái)治理員在主頁(yè)面上點(diǎn)擊“增加餐品”按鈕，進(jìn)入增加餐品的二級(jí)頁(yè)面，填寫相應(yīng)信息，完成餐品增加操作。(2) 后臺(tái)治理員在主頁(yè)上輸出查詢條件，選擇出需要修改的餐品（一般是餐品價(jià)格的修改），點(diǎn)擊餐品圖片進(jìn)入二級(jí)頁(yè)面， 完 成對(duì)餐品的修改操作。(3) 后臺(tái)治理員在主頁(yè)上輸出查詢條件，選擇出需要?jiǎng)h除的餐品，點(diǎn)擊餐品圖片右下方的“刪除，”完成對(duì)餐品的刪除操作?？蛇x操

26、作流程：增加餐品的前提是庫(kù)存不為零，庫(kù)存超過(guò)一定數(shù)量的餐品系統(tǒng)顯示不能刪除餐品信息。4.印第安漢堡點(diǎn)餐系統(tǒng)對(duì)庫(kù)存量進(jìn)行治理的用例描述用例名稱：庫(kù)存操縱簡(jiǎn)要講明：系統(tǒng)依照訂單的數(shù)量和內(nèi)容減少相應(yīng)的庫(kù)存量。參與者：后臺(tái)治理員前置條件：系統(tǒng)中存在一些差不多生成的訂單后置條件：庫(kù)存量作相應(yīng)的變動(dòng)假設(shè)條件：后臺(tái)治理員使用專門賬號(hào)正確登錄到點(diǎn)餐系統(tǒng)差不多操作流程：(1) 系統(tǒng)依照差不多確認(rèn)的訂單中餐品名稱和餐品數(shù)量做相應(yīng)庫(kù)存量的減少。每銷售出去一個(gè)餐品，庫(kù)存數(shù)據(jù)庫(kù)中對(duì)應(yīng)餐品的庫(kù)存量相應(yīng)的減一。(2) 系統(tǒng)顯示每種餐品剩余庫(kù)存量以便治理員及時(shí)同有關(guān)部門協(xié)調(diào)，增加相應(yīng)餐品的供給?？蛇x操作流程：庫(kù)存量為零時(shí)，系

27、統(tǒng)提示不能進(jìn)行相應(yīng)的庫(kù)存減少的操作。5送貨員向顧客供應(yīng)訂貨的用例描述用例名稱：供應(yīng)訂貨簡(jiǎn)要講明：送貨員憑借其中一份訂單與顧客鈔票貨兩清，完成整個(gè)訂餐過(guò)程參與者： 送貨員前置條件：顧客完成“點(diǎn)餐”用例，且餐品未送達(dá)。后置條件：交易完成，刪除相應(yīng)訂單假設(shè)條件：顧客提交了有效的點(diǎn)餐需求差不多操作流程： (1) 送貨員憑借訂單與顧客完成交易后，向有關(guān)治理部門提示“送貨成功”。(2) 系統(tǒng)依照訂單中的餐品名稱和餐品數(shù)量作相應(yīng)庫(kù)存量的減少。可選操作流程：假如交易不成功的話，送貨員應(yīng)及時(shí)提醒后臺(tái)治理員，后臺(tái)治理員應(yīng)及時(shí)刪除相應(yīng)訂單。實(shí)驗(yàn)五：通過(guò)用例獵取概念數(shù)據(jù)模型概念數(shù)據(jù)模型是對(duì)組織數(shù)據(jù)的描繪，它以一種獨(dú)立

28、于現(xiàn)實(shí)的方式講明了數(shù)據(jù)的結(jié)構(gòu)和數(shù)據(jù)之間的相互關(guān)系。本次實(shí)驗(yàn)通過(guò)對(duì)前面用例進(jìn)行分析，并結(jié)合我們訂餐系統(tǒng)的功能和需求，建立概念數(shù)據(jù)模型，具體步驟如下：1、標(biāo)識(shí)用例中的類通過(guò)觀看用例并結(jié)合實(shí)際分析，我們能夠抽象出以下幾個(gè)類：Admin（治理員），Order（訂單），Customer（顧客），Product（產(chǎn)品），以及關(guān)聯(lián)類Lineitem（訂單行項(xiàng)目）。2、確定每一個(gè)類的屬性 用例中沒(méi)有提供關(guān)于屬性的所有詳細(xì)資料，因此我查看了與“訂單”用例相關(guān)文檔，并結(jié)合本系統(tǒng)的功能需求，將屬性分配到類。Admin（治理員）：AdminId（治理員號(hào)），AdminName（治理員姓名），AdminPsd（治理員密

29、碼），AdminType（治理員類型）Order（訂單）：OrderId（訂單號(hào)），OrderDate（訂單時(shí)刻），SubTotal（小計(jì)），TotalAmount（總數(shù)量），Customer（顧客）：CustId（顧客號(hào)），CustomerName（顧客姓名），CustPhone（顧客電話）CustAddress（顧客地址）Product（產(chǎn)品）：ProId（產(chǎn)品號(hào)），ProName（產(chǎn)品名稱）， ProPrice（產(chǎn)品單價(jià)），ProPicture（產(chǎn)品圖片），ProAbstract（產(chǎn)品介紹），ProAmount（產(chǎn)品庫(kù)存）LineItem（訂單行項(xiàng)目）：Quantity（數(shù)量），Actu

30、alPrice（實(shí)際價(jià)格），LineAmount（項(xiàng)目總數(shù)量）3、確定標(biāo)識(shí)符即選擇一個(gè)屬性作為那個(gè)類的唯一標(biāo)識(shí)符。在此我們選擇AdminId（治理員號(hào)）、OrderId（訂單號(hào)、CustId（顧客號(hào)）、ProId（產(chǎn)品號(hào)）為標(biāo)識(shí)符4、考慮屬性的性質(zhì)在此，除了一般的屬性以外，我們認(rèn)為顧客聯(lián)系方式應(yīng)除了常用的一個(gè)以外，至少一個(gè)備用，因此CustPhone（顧客電話）為多值屬性，訂單的ubTotal（小計(jì)），TotalAmount（總數(shù)量），產(chǎn)品的ProAmount（產(chǎn)品庫(kù)存）可由其他數(shù)據(jù)確定，應(yīng)為導(dǎo)出屬性。5、屬性與屬性之間的關(guān)系通過(guò)分析我們能夠明白，一個(gè)顧客能夠下多個(gè)訂單，一個(gè)訂單只能對(duì)應(yīng)一個(gè)顧

31、客購(gòu)買；一個(gè)治理員（前臺(tái)）能夠處理多個(gè)訂單，但每個(gè)訂單對(duì)應(yīng)一個(gè)治理員，因此Customer和Order，Asmin和Order的關(guān)系是一對(duì)一的。每個(gè)訂單可包含多種產(chǎn)品，每個(gè)產(chǎn)品能夠包括在不同的訂單里，因此Product和Order為多對(duì)多的關(guān)系，用關(guān)聯(lián)類LineItem來(lái)表示。6、建立概念數(shù)據(jù)模型 綜上所述，我們建立的概念數(shù)據(jù)模型如下圖所示：實(shí)驗(yàn)六：將概念數(shù)據(jù)模型轉(zhuǎn)換為對(duì)象關(guān)系模型對(duì)象關(guān)系數(shù)據(jù)模型是帶有面向?qū)ο髷U(kuò)充的關(guān)系數(shù)據(jù)模型，以關(guān)聯(lián)表或關(guān)系的形式描繪數(shù)據(jù)。本次實(shí)驗(yàn)基于前面概念數(shù)據(jù)模型的建立，將其轉(zhuǎn)化為對(duì)象關(guān)系，接著將所有關(guān)系合并為最終的、綜合的一組關(guān)系，其步驟如下：1、將類轉(zhuǎn)化為對(duì)象關(guān)系類

32、的標(biāo)識(shí)符成為該對(duì)象關(guān)系的主鍵，類的其他屬性成為該對(duì)象關(guān)系的非主鍵屬性。則對(duì)象關(guān)系如下：Admin（AdminId，AdminName，AdminPsd，AdminType）Order（OrderId，OrderDate，SubTotal，TotalAmount）Customer（CustId，CustomerName，CustPhone，CustAddress）Product（ProId，ProName， ProPrice，ProPicture，ProAbstract，ProAmount）2、為1：n關(guān)系安排外鍵在此系統(tǒng)中，有兩個(gè)一對(duì)多的關(guān)系，依照將1方的主鍵增加為n方的外鍵，則order關(guān)系

33、將被修改為包含CustId 和AdminId，作為外鍵。Order（OrderId，CustId，AdminId，OrderDate，SubTotal，TotalAmount）3、最后轉(zhuǎn)化關(guān)聯(lián)類 在Order和Product之間有一關(guān)聯(lián)類LineItem，其可映像為對(duì)象關(guān)系，并用兩個(gè)類的主鍵OrderId 和ProId的組合作為他的主鍵。LineItem（OrderId ，ProId ，Quantity，ActualPrice，LineAmount）4、規(guī)范化關(guān)系對(duì)象，進(jìn)一步細(xì)化由于Customer同意通過(guò)接收多值屬性違背了第一范式，因而Customer不是一個(gè)良構(gòu)關(guān)系，而是一個(gè)對(duì)象關(guān)系，又因

34、為我們進(jìn)一步討論決定接收純粹的關(guān)系模型，因此將Customer分為關(guān)系，為：Customer（CustId，CustomerName， CustAddress）CustPhone（CustId，CustPhone）5、對(duì)象關(guān)系模型 通過(guò)一步步的細(xì)化，我們產(chǎn)生了6個(gè)對(duì)象類，導(dǎo)出的對(duì)象關(guān)系模型如下：Admin（AdminId，AdminName，AdminPsd，AdminType）Order（OrderId，CustId，AdminId，OrderDate，SubTotal，TotalAmount）LineItem（OrderId ，ProId ，Quantity，ActualPrice，Lin

35、eAmount）Product（ProId，ProName， ProPrice，ProPicture，ProAbstract，ProAmount）Customer（CustId，CustomerName， CustAddress）CustPhone（CustId，CustPhone）實(shí)驗(yàn)七：分析類圖建模這一部分通過(guò)圖對(duì)系統(tǒng)進(jìn)行描述1.順序圖：交互圖是關(guān)心在一個(gè)用例的分析類之間分配責(zé)任并講明類對(duì)象之間的相互交互的圖，常用的交互圖的類型是順序圖，它以時(shí)刻順序的方式講明類的對(duì)象之間的交互。下圖為按照指導(dǎo)原則描繪的“預(yù)訂”用例的順序圖：圖中詳細(xì)描述了“預(yù)定”用例的順序圖：參與者：Customer選擇一

36、個(gè)或多個(gè)產(chǎn)品調(diào)用該用例，那個(gè)消息/select item（選擇產(chǎn)品項(xiàng)）表明，它被傳給：OrderForm。表單將信息傳遞給操縱對(duì)象：OrderControl，因此創(chuàng)建訂單。操縱對(duì)象將創(chuàng)建新訂單的責(zé)任傳給了：Order，：Order創(chuàng)建一個(gè)新訂單。類似的，操縱將增加一個(gè)項(xiàng)目的責(zé)任傳遞給了：LineItem。它來(lái)創(chuàng)建一個(gè)新的項(xiàng)目。或者，：Order對(duì)象能夠負(fù)責(zé)增加：LineItem對(duì)象。2.活動(dòng)圖： 活動(dòng)圖和順序圖相似，但兩個(gè)圖的重點(diǎn)不同，順序圖在于講明一個(gè)程序中的操縱流，而活動(dòng)圖講明系統(tǒng)中活動(dòng)到活動(dòng)的操縱流，什么活動(dòng)能夠并行進(jìn)行，和任何通過(guò)流的可選路徑。 “預(yù)定”用例的活動(dòng)圖： 子流程同步的活動(dòng)

37、圖： 3.狀態(tài)圖： 狀態(tài)圖通過(guò)制定一個(gè)對(duì)象在自己的生存期間響應(yīng)時(shí)刻而經(jīng)歷的狀態(tài)序列以及對(duì)這些事件的響應(yīng)來(lái)描述對(duì)象的行為。一個(gè)對(duì)象的狀態(tài)是在對(duì)象生存期間的一個(gè)條件或情況，在那個(gè)時(shí)刻它滿足某些條件，執(zhí)行某些活動(dòng)或等待某些事件。能夠認(rèn)為對(duì)象的活動(dòng)圖是狀態(tài)圖的一個(gè)特例。 例如， 對(duì)象訂單的狀態(tài)經(jīng)歷創(chuàng)建、供應(yīng)、完成，它的狀態(tài)圖如下： 4.分析類圖： 分析類圖講明分析類和這些類之間的關(guān)系，有兩種關(guān)系結(jié)構(gòu)關(guān)系和行為關(guān)系，結(jié)果方面從數(shù)據(jù)建模中能夠獲得，分析類圖的行為方面能夠從順序圖或通信圖導(dǎo)出。下圖是“預(yù)訂”用例的一個(gè)分析類圖：OrderOrderOrderIdOrderDateSubTotalTotalAm

38、ount/create order()/get order info()/update order info()CustomerCustIdCustomerNameCustPhoneCustPhone/get customer info()/charge customer()ProductProIdProNameProPrice/get products info()/update inventoryLineItemQuantityActualPriceLineAmount/add item()/get lineitems()/write order lineitems()BUYOrderCo

39、ntrol/select item()/confirm order()/calc total()OrdertForm/select item()/confirm order()第三部分實(shí)驗(yàn)八：物理數(shù)據(jù)庫(kù)設(shè)計(jì) 物理數(shù)據(jù)庫(kù)設(shè)計(jì)是對(duì)系統(tǒng)存儲(chǔ)結(jié)構(gòu)和存取方法等依靠于具體計(jì)算機(jī)結(jié)構(gòu)的各項(xiàng)物理設(shè)計(jì)措施的設(shè)計(jì)，涉及訪問(wèn)的效率考慮因素比如響應(yīng)時(shí)刻和事務(wù)吞吐量，本實(shí)驗(yàn)旨在確保用戶在運(yùn)行查詢時(shí)不必等待不合理的時(shí)刻，從而有效執(zhí)行任務(wù)。1、關(guān)系對(duì)象屬性特性描述 在實(shí)驗(yàn)六中，我們的到如下的對(duì)象關(guān)系A(chǔ)dmin（AdminId，AdminName，AdminPsd，AdminType）Order（OrderId，CustId

40、，AdminId，OrderDate，SubTotal，TotalAmount）LineItem（OrderId ，ProId ，Quantity，ActualPrice，LineAmount）Product（ProId，ProName， ProPrice，ProPicture，ProAbstract，ProAmount）Customer（CustId，CustomerName， CustAddress）CustPhone（CustId，CustPhone） 依照上述對(duì)象關(guān)系，結(jié)合邏輯數(shù)據(jù)模型以及實(shí)際情況，分析了各個(gè)屬性的特征，如數(shù)據(jù)類型、設(shè)計(jì)域、數(shù)據(jù)的完整性（默認(rèn)值、是否為空、操縱范圍、參照

41、完整性）等，具體涉及如下表所示：Customer字段名數(shù)據(jù)類型是否同意為空鍵或索引講明CustIDInt（20）否主鍵唯一；系統(tǒng)自動(dòng)給予CustTomerNameNvarchar（30）否CustAddresNvarchar（30）否CustPhone字段名數(shù)據(jù)類型是否同意為空鍵或索引講明CustIDInt（20）否主鍵參照顧客表CustPhoneNvarchar（30）否主鍵唯一Admin字段名數(shù)據(jù)類型是否同意為空鍵或索引講明AdminIDInt(20)否主鍵唯一；系統(tǒng)自動(dòng)給予AdminPsdInt(30)否唯一；長(zhǎng)度大于6AdminNameNvarchar（30）否AdminTypeNue

42、m否分為前臺(tái)治理員、電話預(yù)定員、系統(tǒng)治理員Order字段名數(shù)據(jù)類型是否同意為空鍵或索引講明OrderIDInt(20)否主鍵唯一；系統(tǒng)自動(dòng)給予CustIDInt（20）否參照顧客表AdminIDInt(20)否參照治理員表 OrderDatedatetime否系統(tǒng)自動(dòng)生成SubTotalNumeric(18,2)否依照LineItem表生成TotalAmountInt是依照LineItem表生成LineItem字段名數(shù)據(jù)類型是否同意為空鍵或索引講明OrderIDInt(10)否主鍵參照訂單表ProIdInt(20)否主鍵參照產(chǎn)品表QuantityInt（10）否ActualPrice Nume

43、ric(18,2)否LineAmountNumeric(18,2)否系統(tǒng)自動(dòng)生成Product 字段名數(shù)據(jù)類型是否同意為空鍵或索引講明ProIdInt(20)否主鍵唯一；系統(tǒng)自動(dòng)給予ProNameNvarchar(50)否唯一ProPrice Numeric(8,2)否ProPicturImage否唯一ProAbstractNtest否唯一；非空ProAmountNtest是參照留言表2、物理數(shù)據(jù)庫(kù)文件組織及索引設(shè)計(jì)依照實(shí)際情況和需求分析，我們可能了表的行的大小和數(shù)目如下圖所示。表名行對(duì)象數(shù)目每個(gè)行對(duì)象的字節(jié)數(shù)Admin2000200Order5000000100LineItem1000000

44、040Product4000200Customer500000200CustPhone100000050我們假設(shè)選擇的塊大小是由4000個(gè)可用字節(jié)的4k（4096個(gè)字節(jié)）。在Admin表的例子中，分塊因子4000/200。Admin表的大小是2000/20。Admin表的掃描時(shí)刻是100*2.5ms為0.25s。類似的能夠算出其余幾個(gè)表的計(jì)算如下圖表名行對(duì)象數(shù)目每行字節(jié)數(shù)分塊因子（BF）塊數(shù)掃描時(shí)刻（秒）是否需要索引Admin2000200201000.25否Order500000010040125000312.5是LineItem1000000040100100000250是Product4

45、000200202000.5否Customer5000002002025000625是CustPhone100000050801250031.25是上面的計(jì)算表明索引這六個(gè)表的6個(gè)主鍵AdminId、OrderId、（OrderId ，ProId）、ProId、CustId、（CustId，CustPhone）。主鍵一般是最常被訪問(wèn)的屬性?？蓪dmin和Product存儲(chǔ)在數(shù)據(jù)庫(kù)服務(wù)器的高速緩沖去。即使沒(méi)有被緩存，掃描時(shí)刻也只只是0.25s和5s，沒(méi)有必要索引除了主鍵之外的任何屬性。3）Order、LineItem、Customer和CustPhone是大表，同時(shí)需要索引來(lái)加快查詢的速度。能

46、夠通過(guò)索引具有大量不同值的外鍵提高檢索速度。專門明顯AdminId、OrderId、ProId、CustId差不多上專門好的索引候選。4）索引被頻繁訪問(wèn)并具有相對(duì)大量不同質(zhì)的非屬性鍵如CustomerName也可作為索引。數(shù)據(jù)九：確定系統(tǒng)構(gòu)架等設(shè)計(jì)元素、設(shè)計(jì)類圖建模實(shí)驗(yàn)十：界面設(shè)計(jì)印第安漢堡點(diǎn)餐系統(tǒng)是基于提高點(diǎn)餐周轉(zhuǎn)速率以及更好地進(jìn)行庫(kù)存操縱而開發(fā)的，在界面設(shè)計(jì)上我們也充分考慮到快餐店的經(jīng)營(yíng)特點(diǎn)，盡可能地提供便捷的頁(yè)面操作方式，提高漢堡店的經(jīng)營(yíng)效率。1.印第安系統(tǒng)界面設(shè)計(jì)是遵循的原則（1）通用原則 界面色彩要求：計(jì)算機(jī)屏幕的發(fā)光成像和一般視覺(jué)成像有專門大的不同，應(yīng)該注意這種差不作出恰當(dāng)?shù)纳蚀钆?。例如輕松的淡彩為主配色，灰色系為主配色等等。我們的點(diǎn)餐系統(tǒng)采納橙黃的為基調(diào)，旨在提供一種溫馨、熱情的界面感受。（2）界面平面版式要求：系統(tǒng)樣式排版整齊劃一，盡可能劃分不同的功能區(qū)域于固定位置，固定的格式，方便用戶導(dǎo)航使用；排版不宜過(guò)于密集，保留一定的“留白”區(qū)域，減輕查看時(shí)的視覺(jué)疲勞。 （3）數(shù)據(jù)顯示集中原則：各種列表在頁(yè)面中往往是傳遞信息的核心，盡量集中的表現(xiàn)出來(lái)，并提供必要的關(guān)聯(lián)數(shù)據(jù)、表等恰當(dāng)?shù)慕M織起來(lái)，同時(shí)在視覺(jué)上使用戶專門容易察覺(jué)數(shù)據(jù)之間的關(guān)系，并方便查看、編輯等。（4）主次分明原則：頁(yè)面中同時(shí)分布較多欄目的情況下，按照頁(yè)面的伸展方向，即由上到下，有左到右