食堂管理系統(tǒng)畢業(yè)設(shè)計

1、<p><b>　　一、引言2</b></p><p>　　1.1背景與目的2</p><p>　　1.2后臺數(shù)據(jù)庫為SQL Server 2000簡介2</p><p>　　二、系統(tǒng)需求分析2</p><p>　　2.1系統(tǒng)功能分析3</p><p>　　2.21子模塊功

2、能分析3</p><p>　　2.2系統(tǒng)功能模塊設(shè)計5</p><p>　　2.21系統(tǒng)功能管理模塊6</p><p><b>　　2.3數(shù)據(jù)流圖7</b></p><p>　　2.3.1卡交易數(shù)據(jù)流圖7</p><p>　　2.3.2現(xiàn)金交易數(shù)據(jù)流圖8</p><

3、p>　　2.3.3庫存管理數(shù)據(jù)流圖9</p><p>　　2.3.4整體流圖9</p><p>　　2.4可行性分析11</p><p>　　2.5數(shù)據(jù)字典11</p><p>　　三、概念結(jié)構(gòu)設(shè)計15</p><p>　　3.1構(gòu)思ERD的四條原則15</p><p>　　3

4、.2 設(shè)計E－R圖16</p><p>　　3.2.1分E－R圖16</p><p>　　3.2.2整體E-R圖22</p><p>　　四、邏輯結(jié)構(gòu)設(shè)計23</p><p>　　4.1 一般邏輯模型設(shè)計：23</p><p>　　4.1.1 由ERD導(dǎo)出一般關(guān)系模型的四條原則23</p>

5、<p>　　4.1.2 數(shù)據(jù)庫初步的關(guān)系框架（E-R圖向關(guān)系模型轉(zhuǎn)化）23</p><p>　　4.1.3數(shù)據(jù)模型優(yōu)化25</p><p>　　4.2具體邏輯模型設(shè)計26</p><p>　　4.3設(shè)計用戶子模式35</p><p>　　五、物理結(jié)構(gòu)設(shè)計39</p><p>　　6.1建立索引40

6、</p><p>　　6.2建立觸發(fā)器40</p><p>　　六、數(shù)據(jù)庫結(jié)構(gòu)的實現(xiàn)42</p><p>　　6.1數(shù)據(jù)定義42</p><p>　　6.1.1創(chuàng)建表格SQL語句42</p><p>　　6.1.2創(chuàng)建視圖SQL語句45</p><p>　　6.1.3創(chuàng)建索引SQL語句

7、47</p><p>　　6.3數(shù)據(jù)查詢47</p><p>　　6.4數(shù)據(jù)更新49</p><p>　　6.4.1數(shù)據(jù)添加49</p><p>　　6.4.2數(shù)據(jù)修改49</p><p>　　6.4.3數(shù)據(jù)刪除50</p><p><b>　　七、總結(jié)51</b&

8、gt;</p><p><b>　　引言</b></p><p><b>　　1.1背景與目的</b></p><p>　　隨著高校辦學(xué)規(guī)模的不斷擴大，高校后勤管理工作也日趨繁雜．許多大型高校擁有多個校區(qū)，有十幾個甚至幾十個學(xué)生和教工食堂，這些食堂的地理位置分散，又要實現(xiàn)統(tǒng)一的協(xié)調(diào)管理，就不得不借助現(xiàn)代化的管理模式— —

9、網(wǎng)絡(luò)管理模式</p><p>　　由于當(dāng)前學(xué)校的規(guī)模不斷擴大，學(xué)生數(shù)量不斷增加，學(xué)生信息量也成倍增長，食堂管理工作成為學(xué)校各項管理工作的一個重要部分。面對龐大的信息量，如何有效在提高食堂管理工作的效率是學(xué)校急需解決的問題。</p><p>　　這樣不僅提高了工作效率，也避免了以前手工作業(yè)的麻煩，從而使得管理者能夠準確，有效的管理餐飲。</p><p>　　1.2后臺

10、數(shù)據(jù)庫為SQL Server 2000簡介</p><p>　　SQL全稱是“結(jié)構(gòu)化查詢語言(Structured Query Language)”，最早的是IBM的圣約瑟研究實驗室為其關(guān)系數(shù)據(jù)庫管理系統(tǒng)SYSTEM R開發(fā)的一種查詢語言，它的前身是SQUARE語言。SQL語言結(jié)構(gòu)簡潔，功能強大，簡單易學(xué)，所以自從IBM公司1981年推出以來，SQL語言，得到了廣泛的應(yīng)用。</p><p>

11、;　　SQL是高級的非過程化編程語言，允許用戶在高層數(shù)據(jù)結(jié)構(gòu)上工作。SQL不要求用戶指定對數(shù)據(jù)的存放方法，也不需要用戶了解具體的數(shù)據(jù)存放方式，所以具有完全不同底層結(jié)構(gòu)的不同數(shù)據(jù)庫系統(tǒng)可以使用相同的SQL語言作為數(shù)據(jù)輸入與管理的接口。它以記錄集合作為操縱對象，所有SQL語句接受集合作為輸入，返回集合作為輸出，這種集合特性允許一條SQL語句的輸出作為另一條SQL語句的輸入，所以SQL語言可以嵌套，這使他具有極大的靈活性和強大的功能，在多數(shù)情

12、況下，在其他語言中需要一大段程序?qū)崿F(xiàn)的一個單獨事件只需要一個SQL語句就可以達到目的，這也意味著用SQL語言可以寫出非常復(fù)雜的語句。</p><p><b>　　系統(tǒng)需求分析</b></p><p>　　隨著21世紀的到來，人們更深切地感受到了計算機在生活和工作中的作用越來越重要，越來越多職業(yè)需要具有計算機的應(yīng)用技能。掌握計算機是職業(yè)的雪要，更是事業(yè)發(fā)展的需要。<

13、;/p><p>　　信息在社會和經(jīng)濟的發(fā)展中所起的作用越來越為人們所重視。信息資源的開發(fā)利用水平已成為衡量一個國家綜合國力的重要標(biāo)志之一。在計算機的三大主要應(yīng)用領(lǐng)域（科學(xué)計算、數(shù)據(jù)處理與過程控制）中，數(shù)據(jù)處理的比重占70%左右。計算機作為信息處理的工具，為適應(yīng)數(shù)據(jù)處理需求的迅速提高，滿足各類系統(tǒng)對數(shù)據(jù)處理的要求，在文件系統(tǒng)的基礎(chǔ)上發(fā)展起了數(shù)據(jù)庫系統(tǒng)。</p><p>　　隨著計算機計算機技術(shù)的

14、飛速發(fā)展，計算機在企業(yè)管理中應(yīng)用及普及，利用計算機實現(xiàn)企業(yè)信息管理勢在必行。本課題以高等院校為對象，作為高效要面對大量的課程設(shè)計項目及相關(guān)信息的處理，這就需要一個課程設(shè)計管理系統(tǒng)來提高管理工作的效率。通過本系統(tǒng)，可以做到信息的規(guī)范管理、科學(xué)統(tǒng)計和快速查詢，從而減少管理工作方面的工作量。</p><p>　　數(shù)據(jù)處理技術(shù)已深入到我們工作和生活的方方面面，而數(shù)據(jù)庫技術(shù)是數(shù)據(jù)處理不可缺少的手段。隨著數(shù)據(jù)庫技術(shù)的發(fā)展，面

15、向?qū)ο蟮臄?shù)據(jù)庫、分布式數(shù)據(jù)庫、多媒體數(shù)據(jù)庫、數(shù)據(jù)庫開發(fā)工具的研究方興未艾，這些技術(shù)的發(fā)展使用軟件的開發(fā)速度更快、成本更低、質(zhì)量更好、功能更強。</p><p>　　管理信息系統(tǒng)是一門新興的、集管理科學(xué)、信息科學(xué)、系統(tǒng)科學(xué)及計算機科學(xué)為一體的綜合性學(xué)科，研究的是信息管理活動的全過程，以便有效的管理信息，提供各類管理決策信息，輔助企業(yè)進行現(xiàn)代化管理。管理信息系統(tǒng)它具備數(shù)據(jù)處理、計劃、控制、預(yù)測和輔助決策功能，具體作用

16、如下5點內(nèi)容：</p><p>　?。?）用統(tǒng)一標(biāo)準處理和提供信息，排除使用前后矛盾的不完整的數(shù)據(jù)。</p><p>　　（2）完整、及時提供在管理及決策中需要的數(shù)據(jù)。</p><p>　?。?）利用指定的數(shù)據(jù)關(guān)系分析數(shù)據(jù)，客觀預(yù)測未來。</p><p>　?。?）向各級管理機構(gòu)提供不同詳細程度的報告，縮短分析和解釋的時間。</p>

17、;<p>　?。?）用最低的費用最短的時間提供盡可能精確、可靠的信息，以便使決策者選擇最佳的實施方案，以提高企業(yè)的經(jīng)濟效益。</p><p><b>　　2.1系統(tǒng)功能分析</b></p><p>　　系統(tǒng)開發(fā)的總體任務(wù)是受用 計算機信息管理技術(shù)，實現(xiàn)食堂各種信息的系統(tǒng)化，規(guī)范化，自動化，提高食堂管理的效率。</p><p>　　

18、對應(yīng)用系統(tǒng)項目的開發(fā)，首先要對程序要實現(xiàn)的功能和目標(biāo)進行整體分析和規(guī)劃，確保在后期開發(fā)中不會出現(xiàn)遺漏或重大缺陷。因此在軟件開發(fā)中，要嚴格按照軟件工程的流程進行系統(tǒng)的分析和設(shè)計</p><p>　　系統(tǒng)功能分析是在系統(tǒng)開發(fā)的總體任務(wù)的基本上完成的。</p><p><b>　　主要功能：</b></p><p><b>　　1、消費者信

19、息管理</b></p><p><b>　　2、預(yù)訂信息管理</b></p><p><b>　　3、成本核算管理</b></p><p><b>　　4、庫存管理</b></p><p>　　其中主要任務(wù)為消費者信息管理和結(jié)算信息管理。</p>&l

20、t;p><b>　　總的功能特點：</b></p><p>　　完善、全面的綜合查詢</p><p><b>　　報表翔實，實用性強</b></p><p>　　2.21子模塊功能分析</p><p>　　消費者信息管理：對來自客戶端的不同用戶進行權(quán)限審查，限定對數(shù)據(jù)庫的訪問級別</p&

21、gt;<p>　　預(yù)訂信息管理：各部門向采購部發(fā)出需求申請，預(yù)定用貨；對于采購部已送達的貨物進行電子簽名接收；</p><p>　　預(yù)訂信息管理：訂餐、訂餐信息修改、訂餐信息取消、定金處理、訂餐統(tǒng)計、 訂餐查詢，訂餐報表。</p><p>　　有效的預(yù)訂處理，充分發(fā)揮銷售潛力，這使該系統(tǒng)更實用、全面、方便和快捷。需

22、要有關(guān)包房的詳細情況和全面的咨詢服務(wù)，減少了文件資料的手工整理等繁瑣工作，并能避免處理上的錯誤，從而簡化預(yù)訂房間手續(xù)。</p><p>　　成本核算管理： 對成本利潤的綜合分析。成本包括 固定成本（人員工資、水電、稅等）變動成本（菜、酒、米等的采購成本）。收入指每天的銷售收入。能核算每天、每月、每年、以及任何一段時間的成本，利潤。微機室核計每天各單位、各窗口的收益情況并將結(jié)果送入數(shù)據(jù)庫供管理層查詢；</p&

23、gt;<p>　　成本查詢：用于各個單位查詢各個部門每日每月的成本情況 。</p><p>　　效益查詢：用于各個單位查詢各個部門每日每月的收益情況。</p><p>　　庫存管理：管理各種用品的使用情況，確定用貨來源和送達目的地；對商品的入庫，出庫，結(jié)算的管理。要有明細賬，記載出入庫的詳細情況。</p><p>　　供食堂負責(zé)人員和采購人員還有審查工

24、作，實現(xiàn)對于每天各部門、各食堂中所使用的貨物進行審核和查看現(xiàn)有庫存情況；</p><p>　　2.2系統(tǒng)功能模塊設(shè)計</p><p>　　對上述各項功能進行集中、分塊分析，按照結(jié)構(gòu)化程序設(shè)計的要求，得到如圖所示的這個系統(tǒng)的功能模塊圖</p><p>　　2.21系統(tǒng)功能管理模塊</p><p><b>　　2.3數(shù)據(jù)流圖</b

25、></p><p>　　【注釋：數(shù)據(jù)流圖，簡稱DFD,是SA方法中用于表示系統(tǒng)邏輯模型的一種工具，它以圖形的方式描繪數(shù)據(jù)在系統(tǒng)中流動和處理的過程，由于它只反映系統(tǒng)必須完成的邏輯功能，所以它是一種功能模型】</p><p>　　數(shù)據(jù)流程圖是組織中信息運動的抽象，是管理信息系統(tǒng)邏輯模型的主要形式。它可以綜合的反映出信息在系統(tǒng)中的流動、處理和存儲情況，具有良好的抽象性和概括性。它在調(diào)查的基

26、礎(chǔ)上，從系統(tǒng)的科學(xué)性、管理的合理性、實際運行的可行性角度出發(fā)，將信息處理功能和彼此之間的聯(lián)系自頂向下、逐層分解，從邏輯上精確地描述系統(tǒng)應(yīng)具有的數(shù)據(jù)加工、數(shù)據(jù)輸入、數(shù)據(jù)輸出、數(shù)據(jù)存儲及數(shù)據(jù)來源和去向（外部實體）等項目。數(shù)據(jù)流程圖和系統(tǒng)的物理描述無關(guān)，它所描述的內(nèi)容不涉及技術(shù)細節(jié)，而是面向用戶的，即使完全不懂信息技術(shù)的用戶也容易理解。因此，數(shù)據(jù)流程圖成為系統(tǒng)分析員與用戶進行交流的有效手段，同時也成為系統(tǒng)設(shè)計的主要依據(jù)之一。</p>

27、;<p>　　用戶的需求具體體現(xiàn)在各種信息的提供、保存、更新和查詢等方面，這就要求數(shù)據(jù)庫結(jié)構(gòu)能充分滿足各種信息的輸入和輸出。收集基本數(shù)據(jù)、數(shù)據(jù)結(jié)構(gòu)及數(shù)據(jù)處理的流程，組成一份詳盡的數(shù)據(jù)字典，為數(shù)據(jù)庫的具體設(shè)計打下基礎(chǔ)。</p><p>　　數(shù)據(jù)流圖表達了數(shù)據(jù)和處理之間的關(guān)系。數(shù)據(jù)流圖是有層次之分的，越高層次的數(shù)據(jù)流圖表現(xiàn)的業(yè)務(wù)邏輯越抽象，越底層次的數(shù)據(jù)流圖表現(xiàn)得業(yè)務(wù)邏輯越具體。</p>

28、<p>　　在仔細的分析調(diào)查有關(guān)食堂管理信息需求的基礎(chǔ)上，得到如下圖所示的這個系統(tǒng)所處理的數(shù)據(jù)流程。</p><p>　　根據(jù)以上的分析，我們可以先畫出分流程圖，然后可以綜合分流程圖，畫出整個系統(tǒng)操作的業(yè)務(wù)流程圖</p><p>　　2.3.1卡交易數(shù)據(jù)流圖</p><p>　　2.3.2現(xiàn)金交易數(shù)據(jù)流圖</p><p>　　2.3

29、.3庫存管理數(shù)據(jù)流圖</p><p><b>　　2.3.4整體流圖</b></p><p><b>　　整體流圖簡圖：</b></p><p><b>　　整體流圖整圖</b></p><p><b>　　2.4可行性分析</b></p>

30、<p>　　可行性分析是系統(tǒng)分析階段的重要活動，是對系統(tǒng)進行全面、概要的分析。它的任務(wù)是確定項目開發(fā)是否必要和可行。它的主要目標(biāo)是：進一步明確系統(tǒng)的目標(biāo)、規(guī)模和功能，對系統(tǒng)開發(fā)背景、必要性和意義進行調(diào)查分析，并根據(jù)需要和可能提出擬開發(fā)系統(tǒng)的初步方案和計劃，明確問題，對所提供系統(tǒng)大致規(guī)模和目標(biāo)的幾個有關(guān)約束條件進行論證，并且提出系統(tǒng)的邏輯模型和各種可能的方案，從而為系統(tǒng)開發(fā)項目的決策提供科學(xué)依據(jù)。</p><

31、p>　　其主要從三個方面進行研究：</p><p>　?。?）技術(shù)可行性：對現(xiàn)有技術(shù)進行評價，以明確能否利用現(xiàn)有技術(shù)進行系統(tǒng)開發(fā)及系統(tǒng)實施。計算機網(wǎng)絡(luò)技術(shù)的發(fā)展和計算機硬件性價比的不斷提升，使計算機全面應(yīng)用于醫(yī)院管理的各個環(huán)節(jié)成為可能。C/S開發(fā)模式、COM、DCOM技術(shù)在國內(nèi)各行各業(yè)的信息管理系統(tǒng)開發(fā)中已經(jīng)被廣泛采用，實踐證明這些技術(shù)都非常適合食堂管理系統(tǒng)的開發(fā)。</p><p>

32、　?。?）經(jīng)濟可行性：對組織的經(jīng)濟狀況和投資能力進行分析，對系統(tǒng)建設(shè)、運行和維護費用進行評估，對系統(tǒng)建成后可能取得的社會及經(jīng)濟效益進行估計。連鎖餐飲企業(yè)整體規(guī)模龐大，個體規(guī)模小而營管理相對簡單統(tǒng)一，開發(fā)成本不高，一旦開發(fā)成功，即能直接應(yīng)用在所有同種食堂。</p><p>　?。?）營運可行性：指系統(tǒng)對組織機構(gòu)的影響，對現(xiàn)有人員和機構(gòu)、設(shè)施、環(huán)境等的適應(yīng)性以及進行人員培訓(xùn)補充計劃的可行性。連鎖餐飲企業(yè)整體規(guī)模龐大，

33、個體規(guī)模小而營管理相對簡單統(tǒng)一。所以食堂系統(tǒng)的計算機信息管理人才、計算機硬件設(shè)備、操作員的計算機應(yīng)用能力都為系統(tǒng)的運行過程提供了可靠保證。</p><p><b>　　2.5數(shù)據(jù)字典</b></p><p>　　由于數(shù)據(jù)流程圖只是對數(shù)據(jù)處理及彼此之間的聯(lián)系進行說明，未對數(shù)據(jù)的詳細內(nèi)容及數(shù)據(jù)的加工過程進行說明，而這正是數(shù)據(jù)字典所要表達的。數(shù)據(jù)字典是關(guān)于數(shù)據(jù)信息的集合，也

34、就是對數(shù)據(jù)流程圖中包含的所有元素的定義的集合。它能將數(shù)據(jù)流程圖中全部數(shù)據(jù)流及其組成部分的數(shù)據(jù)元素、數(shù)據(jù)存儲、數(shù)據(jù)加工等描述清楚，便于后續(xù)工作—系統(tǒng)設(shè)計的進行。</p><p>　　數(shù)據(jù)字典是系統(tǒng)中各類數(shù)據(jù)描述的集合，是進行詳細的數(shù)據(jù)收集和數(shù)據(jù)分析所獲得的主要成果。數(shù)據(jù)字典通常包括數(shù)據(jù)項、數(shù)據(jù)結(jié)構(gòu)、數(shù)據(jù)流、數(shù)據(jù)存諸和處理過程5個部分。其中數(shù)據(jù)項是最小組成單位，若干數(shù)據(jù)項組成一個數(shù)據(jù)結(jié)構(gòu)，數(shù)據(jù)字典通過對數(shù)據(jù)項和數(shù)據(jù)結(jié)

35、構(gòu)的定義來描述數(shù)據(jù)流、數(shù)據(jù)存儲和邏輯內(nèi)容。</p><p>　　針對一般食堂管理信息系統(tǒng)的需求，通過對食堂管理工作過程的內(nèi)容和數(shù)據(jù)流程分析，設(shè)計如下所示的數(shù)據(jù)項和數(shù)據(jù)結(jié)構(gòu)：</p><p>　　數(shù)據(jù)結(jié)構(gòu)名稱：卡信息 </p><p>　　含義說明：是消費者這里指的是學(xué)生和教師用來使用付款的工具卡的一系列信息，它記錄了包括它本身以及持卡者的一些信息</p>

36、<p><b>　　包括的數(shù)據(jù)項有：</b></p><p><b>　　卡號</b></p><p>　　（消費者使用的用來付款的卡的編號，與消費者辦卡的先后順序有關(guān)</p><p>　　別名Card_number 字符型 長度6）</p><p><b>　　余額&

37、lt;/b></p><p>　?。ㄏM者卡中所剩的金錢數(shù)量，別名Balance 字符型長度 6）</p><p><b>　　辦卡日期</b></p><p>　?。ㄏM者辦卡的日期，別名Card_date 日期型 長度 8）</p><p><b>　　持卡者姓名</b>&l

38、t;/p><p>　?。〒碛行畔⒖ǖ南M者的名稱，別名 Person_name 字符型 長度 10）</p><p><b>　　花費</b></p><p>　?。ㄏM者所消費的金錢數(shù)量 別名Consume 字符型 長度 20）</p><p>　　數(shù)據(jù)結(jié)構(gòu)名稱：學(xué)生信息</p><p>

39、　　含義說明：消費者群體之一，可以自由選擇消費方式，辦過卡用卡交易或者用現(xiàn)金交易</p><p><b>　　包括的數(shù)據(jù)項有：</b></p><p><b>　　學(xué)號</b></p><p>　?。▽W(xué)生在校所編的號碼 別名 S_number 字符型 長度 6）</p><p>&l

40、t;b>　　系別</b></p><p>　　（學(xué)生所在的系的名稱 別名 S_system 字符型 長度 16）</p><p><b>　　班級</b></p><p>　?。▽W(xué)生所在的班級的班號 別名class 字符型 長度 20）</p><p><b>　

41、　姓名</b></p><p>　?。▽W(xué)生的姓名 別名 S_name 字符型 長度 10）</p><p><b>　　性別</b></p><p>　?。▽W(xué)生的性別 別名 S_sex字符型 長度 4）</p><p><b>　　宿舍</b><

42、/p><p>　?。▽W(xué)生所在宿舍名稱 別名 S_dorm 字符型長度 20）</p><p><b>　　聯(lián)系方式</b></p><p>　　（學(xué)生的手機號碼 別名 S_tel 字符型 長度 20）</p><p>　　數(shù)據(jù)結(jié)構(gòu)名稱：教師信息</p><p>　

43、　含義說明：消費者群體之一，可以自由選擇消費方式，辦過卡用卡交易或者用現(xiàn)金交易</p><p><b>　　包括的數(shù)據(jù)項有：</b></p><p><b>　　教師號</b></p><p>　?。ń處煹木幪杽e名 T_number字符型 長度 6）</p><p><b>

44、;　　系別</b></p><p>　　（教師所在的系的名稱 別名 T_system 字符型 長度 10）</p><p><b>　　姓名</b></p><p>　?。ń處煹男彰麆e名T_name 字符型長度 6）</p><p><b>　　性別</b>

45、;</p><p>　?。ń處煹男詣e別名T_sex字符型長度 4）</p><p><b>　　家庭住址</b></p><p>　?。ń處煹募彝プ≈?別名 Address字符型長度 50）</p><p><b>　　聯(lián)系方式</b></p><p&g

46、t;　?。ń處煹氖謾C號碼 別名 T_tel 字符型長度 20）</p><p>　　數(shù)據(jù)結(jié)構(gòu)名稱：消費者</p><p>　　含義說明：來到食堂消費的人，這里指的是學(xué)生和教師</p><p><b>　　包括的數(shù)據(jù)項有：</b></p><p><b>　　消費序號</b></p

47、><p>　?。ㄏM者來消費的序號 別名 Consumer_number 字符型 長度 6）</p><p><b>　　姓名</b></p><p>　?。ㄏM者的姓名 別名Consumer_name 字符型 長度 10）</p><p><b>　　性別</b><

48、/p><p>　?。ㄏM者的性別 別名Consumer_sex 字符型 長度 10）</p><p><b>　　消費類別</b></p><p>　?。ㄏM者消費的類別，其中包括卡消費和現(xiàn)金消費別名Consume_sort字符型 長度 10）</p><p><b>　　消費者類別<

49、;/b></p><p>　?。ㄏM者的類別，這里指學(xué)生或教師別名 Consumer_sort </p><p>　　字符型 長度 10）</p><p>　　數(shù)據(jù)結(jié)構(gòu)名稱：包房信息</p><p>　　含義說明：消費者訂餐的房間的信息</p><p><b>　　包括的數(shù)據(jù)項有：<

50、/b></p><p><b>　　房間編號</b></p><p>　?。ㄏM者訂餐房間所在的編號 別名 Room_number字符型</p><p><b>　　長度 6）</b></p><p><b>　　房間位置</b></p><p&

51、gt;　　（消費者訂餐房間所在的房間位置 別名 Room_address字符型</p><p><b>　　長度 20）</b></p><p>　　數(shù)據(jù)結(jié)構(gòu)名稱：訂餐信息</p><p>　　含義說明：消費者在訂餐時所需要的信息</p><p><b>　　包括的數(shù)據(jù)項有：</b></p

52、><p><b>　　訂餐編號</b></p><p>　?。ㄏM者訂餐的編號，以便管理 別名 Beat_number 字符型</p><p><b>　　長度 6）</b></p><p><b>　　顧客姓名</b></p><p>　　（消

53、費者的姓名 別名Consumer_name 字符型 長度 10）</p><p><b>　　聯(lián)系方式</b></p><p>　?。ㄏM者的聯(lián)系方式（手機號碼） 別名 Consumer_tel 字符型</p><p><b>　　長度 20）</b></p><p><

54、;b>　　約定時間</b></p><p>　?。ㄏM者訂餐時所約定的吃飯時間 別名Booktime 日期型</p><p><b>　　長度 8）</b></p><p><b>　　備注信息</b></p><p>　?。ㄔ谟啿蜁r其他的信息 別名 Remark_in

55、fo文本型 長度 50）</p><p>　　數(shù)據(jù)結(jié)構(gòu)名稱：消費情況</p><p>　　含義說明：消費者在食堂的消費總體情況，用于管理員的審查工作以及預(yù)算，計算成本利潤的工作。</p><p><b>　　包括的數(shù)據(jù)項有：</b></p><p><b>　　一樓窗口</b></p&g

56、t;<p>　?。ㄒ粯撬写翱谝惶靸?nèi)收入總和 別名 Floor_one 字符型 長度 6）</p><p><b>　　二樓窗口</b></p><p>　?。ǘ撬写翱谝惶靸?nèi)收入總和 別名Floor_two 字符型 長度 6）</p><p><b>　　三樓窗口</b></

57、p><p>　?。ㄈ龢撬写翱谝惶靸?nèi)收入總和 別名Floor_three 字符型 長度 6）</p><p><b>　　一天消費總額</b></p><p>　?。ㄒ惶靸?nèi)在食堂用餐的消費者所花費的總額，它的數(shù)值等于所有樓層的收入與消費者在包房所花費的總額 別名 Total 長整型 長度 6）</p>&

58、lt;p><b>　　日期</b></p><p>　　（記錄的日期 別名 Date 日期型 長度 8）</p><p>　　數(shù)據(jù)結(jié)構(gòu)名稱：管理員信息</p><p>　　含義說明：食堂的主要負責(zé)人以及采購員，管帳人員等的信息</p><p><b>　　包括的數(shù)據(jù)項有：</b>&

59、lt;/p><p><b>　　管理員編號</b></p><p>　?。ü芾韱T在食堂的編號 別名 Manager_number 字符型 長度 6）</p><p><b>　　姓名</b></p><p>　?。ü芾韱T的姓名 別名Manager_name 字符型 長度 6）</p

60、><p><b>　　性別</b></p><p>　　（管理員的性別 別名Manager_sex 字符型 長度 4）</p><p><b>　　家庭住址</b></p><p>　?。ü芾韱T的家庭住址 別名Manager_address 字符型 長度 50）</p&

61、gt;<p><b>　　聯(lián)系方式</b></p><p>　?。ü芾韱T的聯(lián)系方式 別名Manager_tel 字符型長度20）</p><p><b>　　工資</b></p><p>　　（管理員每個月的收入 別名 Income 整型 長度 20）</p><p>　

62、　數(shù)據(jù)結(jié)構(gòu)名稱：庫存信息</p><p>　　含義說明：食堂的庫存中商品的信息</p><p><b>　　包括的數(shù)據(jù)項有：</b></p><p><b>　　商品編號</b></p><p>　?。ㄉ唐返木幪?別名 Trade_no 字符型 長度20）</p><p&g

63、t;<b>　　商品名稱</b></p><p>　?。ㄉ唐返拿Q 別名Trade_name 字符型長度 20）</p><p><b>　　商品價格</b></p><p>　　（商品所入庫時的價格 別名price 整型長度 4）</p><p><b>　　入庫商品數(shù)量

64、</b></p><p>　?。ㄈ霂鞎r商品的數(shù)量 別名Enter_number 整型長度 4）</p><p><b>　　庫存商品數(shù)量</b></p><p>　　（現(xiàn)在庫存的商品的數(shù)量 別名 Stock_number 整型 長度 4）</p><p><b>　　入庫時間

65、</b></p><p>　?。ㄉ唐啡霂斓臅r間 別名 entertime日期型長度 8）</p><p><b>　　出庫時間</b></p><p>　?。ㄉ唐烦鰩斓臅r間 別名 outtime日期型長度 8）</p><p><b>　　三、概念結(jié)構(gòu)設(shè)計</b><

66、;/p><p>　　這一設(shè)計階段是在需求分析的基礎(chǔ)上，設(shè)計出能滿足用戶需求的各種實體，以及它們之間的關(guān)系，為后面的邏輯結(jié)構(gòu)設(shè)計打下基礎(chǔ)。</p><p>　　將需求分析得到的用戶需求抽象為信息結(jié)構(gòu)即概念模型的過程就是概念結(jié)構(gòu)設(shè)計。它是整個數(shù)據(jù)庫設(shè)計的關(guān)鍵。</p><p>　　概念結(jié)構(gòu)設(shè)計的特點是能真實、充分的反映現(xiàn)實世界，包括事物和事物的聯(lián)系，能滿足用戶對數(shù)據(jù)的處理要

67、求，是對現(xiàn)實世界的一個真實的模型。易于理解，從而可以用它和不熟悉計算機的用戶交換意見，用戶的積極參與是數(shù)據(jù)庫設(shè)計成功的關(guān)鍵。易于改正，當(dāng)應(yīng)用環(huán)境和應(yīng)用要求改變時，易于對概念模型修改和擴充。易于向關(guān)系、網(wǎng)狀、層次等各種數(shù)據(jù)模型轉(zhuǎn)換。</p><p>　　概念結(jié)構(gòu)是各種數(shù)據(jù)模型的共同基礎(chǔ)，它比數(shù)據(jù)模型更獨立于機器、更抽象，從而更加穩(wěn)定。概念結(jié)構(gòu)是對現(xiàn)實世界的一種抽象。所謂抽象是對實際的人、物、事和概念進行人為處理，抽

68、取所關(guān)心的共同特性，忽略非本質(zhì)的細節(jié)，并把這些特性用各種概念準確的加以描述。</p><p>　　概念結(jié)構(gòu)設(shè)計通常分為四種方法：自頂向下，即首先定義全局概念結(jié)構(gòu)的框架，然后逐步細化。自底向上，即首先定義各局部應(yīng)用的概念結(jié)構(gòu)，然后將它們集成起來，得到全局概念結(jié)構(gòu)。逐步擴張，首先定義最重要的核心概念結(jié)構(gòu)，然后向外擴張。混合策略，即自頂向下和自底向上結(jié)合，用自頂向下策略設(shè)計一個全局概念結(jié)構(gòu)的框架，以它為骨架集成由自底向

69、上策略中設(shè)計的各局部概念結(jié)構(gòu)。通常分為兩步，第一步是抽象數(shù)據(jù)并設(shè)計局部視圖，第二步是集成局部視圖，得到全局視圖。</p><p>　　下面首先對實體和其屬性加以描述，再寫出系統(tǒng)的分E-R圖，進而合并成為整體的E-R圖。</p><p>　　3.1構(gòu)思ERD的四條原則</p><p>　　原則1：能獨立存在的事物，例如人、物、事、地、團體、機構(gòu)、活動、事項等等，在其有

70、多個由基本項描述的特性需要關(guān)注時，就應(yīng)把它作為實體。</p><p>　　原則2：兩個或多個實體間的關(guān)聯(lián)與結(jié)合，如主管、從屬、組成、占有、作用、配合、協(xié)同等等，當(dāng)需要予以關(guān)注時，應(yīng)作為聯(lián)系。聯(lián)系通常是某類行為動作，ERD中關(guān)注的是其狀態(tài)與結(jié)果而非其過程。</p><p>　　原則3：實體的屬性是實體的本質(zhì)特征。實體應(yīng)有標(biāo)識屬性（能把不同個體區(qū)分開來的屬性組），并指定其中一個作為主標(biāo)識。聯(lián)系

71、的屬性是聯(lián)系的結(jié)果或狀態(tài)。屬性具有如下幾個特點：a.非多值性；b.非復(fù)合性；c.非導(dǎo)出性。而實體的屬性還應(yīng)有非關(guān)聯(lián)性。</p><p>　　原則4（一事一地原則）：所有基本項在同一E-R圖中作為屬性要在僅在一個地方出現(xiàn)</p><p>　　3.2 設(shè)計E－R圖</p><p>　　根據(jù)上面的設(shè)計規(guī)劃出的實體有：卡信息實體、學(xué)生信息實體、教師信息實體、消費者實體、包房

72、信息實體、訂餐信息實體、消費情況實體、管理員信息實體。各個實體具體的描述E-R圖及其之間的關(guān)系描述如下。</p><p>　　3.2.1分E－R圖</p><p>　　圖3-1為卡信息實體E-R圖</p><p>　　圖3-2為學(xué)生信息實體E-R圖</p><p>　　圖3-3為教師信息實體E-R圖</p><

73、p>　　圖3-4為消費者實體E-R圖</p><p>　　圖3-5為包房信息實體E-R圖</p><p>　　圖3-6為訂餐信息實體E-R圖</p><p>　　圖3-7為消費情況實體E-R圖</p><p>　　圖3-8為管理員信息實體E-R圖</p><p>　　圖3-9為庫存信息實體

74、E-R圖</p><p>　　圖3-10 為管理員信息實體和庫存管理實體關(guān)系E-R圖</p><p>　　N 1</p><p>　　圖3-11為管理員信息實體、消費情況實體、消費者實體關(guān)系E-R圖</p><p><b>　　m</b></p><p><

75、b>　　n</b></p><p>　　n 1</p><p>　　圖3-12為訂餐信息實體、包房信息實體、消費者實體關(guān)系E-R圖</p><p><b>　　1 </b></p><p><b>　　1</b></p><p&

76、gt;　　1 n </p><p>　　圖3-13為卡信息實體、學(xué)生信息實體、消費者實體關(guān)系E-R圖</p><p>　　N 1</p><p><b>　　1</b></p><p><b>　　1</b></p>

77、;<p>　　圖3-14為卡信息實體、教師信息實體、消費者實體關(guān)系E-R圖</p><p>　　N 1 </p><p><b>　　1</b></p><p><b>　　1</b></p>

78、<p>　　3.2.2整體E-R圖</p><p>　　由上面的分E-R圖可以得到整體E-R圖，如下圖所示</p><p>　　圖3-15為整體E－R圖</p><p><b>　　n</b></p><p><b>　　1</b></p><p>　　1

79、 1</p><p><b>　　n</b></p><p><b>　　m</b></p><p>　　n 1 </p><p>　　n

80、 1 </p><p><b>　　1</b></p><p><b>　　1 </b></p><p>　　N n</p><p>　　1 1 </p><p>　　1 1</p

81、><p><b>　　四、邏輯結(jié)構(gòu)設(shè)計</b></p><p>　　現(xiàn)在需要把上面設(shè)計好的數(shù)據(jù)庫概念結(jié)構(gòu)轉(zhuǎn)化為SQL Server2000數(shù)據(jù)庫系統(tǒng)所支持的實際數(shù)據(jù)庫模型，也就是數(shù)據(jù)庫的邏輯結(jié)構(gòu)。</p><p>　　4.1 一般邏輯模型設(shè)計：</p><p>　　4.1.1 由ERD導(dǎo)出一般關(guān)系模型的四條原則</

82、p><p>　　原則1：E-R圖中的每一個獨立實體變換為一個關(guān)系，其屬性變?yōu)殛P(guān)系的屬性，其主標(biāo)識變?yōu)殛P(guān)系的主碼。</p><p>　　原則2：E-R圖中的從實體及相應(yīng)的“的”聯(lián)系變換為一個關(guān)系，從實體的屬性加上主體關(guān)系的主碼構(gòu)成這個關(guān)系的屬性。如果“的”聯(lián)系是1：1的，則以主實體關(guān)系的主碼（作為外來碼）為這個關(guān)系的主碼；如果“的”聯(lián)系是1：M的，則以主實體關(guān)系的主碼加上同一主實體個體聯(lián)系的不同

83、從屬實體個體賴以相互區(qū)分的屬性組，組成該關(guān)系的主碼。</p><p>　　原則3：1：M聯(lián)系通過在“多”實體關(guān)系中增加相聯(lián)系的“1”實體關(guān)系的主碼及聯(lián)系本身的屬性來表達。其中“1”實體主碼為外來碼。</p><p>　　原則4：M：M聯(lián)系轉(zhuǎn)換成一個獨立的關(guān)系，被聯(lián)系實體關(guān)系的主碼（作為外來碼）和聯(lián)系本身的屬性作為該關(guān)系的屬性，被聯(lián)系實體關(guān)系的主碼組成其復(fù)合主碼。</p>&l

84、t;p>　　4.1.2 數(shù)據(jù)庫初步的關(guān)系框架（E-R圖向關(guān)系模型轉(zhuǎn)化）</p><p><b>　　最多關(guān)系模型轉(zhuǎn)化</b></p><p><b>　　庫存信息</b></p><p>　?。ㄉ唐肪幪?商品名稱 商品價格 入庫商品數(shù)量 庫存商品數(shù)量 </p><p>

85、　　入庫時間 出庫時間）</p><p><b>　　管理</b></p><p>　?。ㄉ唐访Q 管理員編號）</p><p><b>　　管理員信息</b></p><p>　　（管理員編號 姓名 性別 家庭住址 聯(lián)系方式 工資）</p><p&g

86、t;<b>　　管理查詢</b></p><p>　　（管理員編號 日期）</p><p><b>　　消費情況</b></p><p>　?。ㄈ掌?一樓窗口 二樓窗口 三樓窗口 一天消費總額）</p><p><b>　　消費</b></p>

87、<p>　　（日期 消費序號）</p><p><b>　　消費者</b></p><p>　?。ㄏM序號 姓名 性別 消費類別 消費者類別）</p><p><b>　　訂餐</b></p><p>　?。ㄓ啿途幪?消費序號）</p><p&

88、gt;<b>　　訂餐信息</b></p><p>　?。ㄓ啿途幪?顧客姓名 聯(lián)系方式 約定時間 備注信息）</p><p><b>　　所在</b></p><p>　?。ㄓ啿途幪?房間編號）</p><p><b>　　包房信息</b></p>

89、;<p>　?。ǚ块g編號 房間位置）</p><p><b>　　屬于</b></p><p>　　（學(xué)號 消費序號）</p><p><b>　　組成</b></p><p>　?。ń處熖?消費序號）</p><p><b>　　學(xué)生信

90、息</b></p><p>　?。▽W(xué)號 系別 班級 姓名 性別 宿舍 聯(lián)系方式）</p><p><b>　　使用</b></p><p><b>　?。ㄌ?學(xué)號）</b></p><p><b>　　卡信息</b></p>

91、<p>　?。ㄌ?余額 辦卡日期 持卡者姓名 花費）</p><p><b>　　持有</b></p><p>　?。ㄌ?教師號）</p><p><b>　　教師信息</b></p><p>　?。ń處熖?系別 姓名 性別 家庭住址 聯(lián)系方式）

92、</p><p><b>　　最少關(guān)系模型轉(zhuǎn)化</b></p><p><b>　　庫存信息</b></p><p>　?。ㄉ唐肪幪?商品名稱 商品價格 入庫商品數(shù)量 庫存商品數(shù)量 </p><p>　　入庫時間 出庫時間 管理員編號）</p><p&

93、gt;<b>　　管理員信息</b></p><p>　?。ü芾韱T編號 姓名 性別 家庭住址 聯(lián)系方式 工資）</p><p><b>　　管理查詢</b></p><p>　　（管理員編號 日期）</p><p><b>　　消費情況</b></

94、p><p>　?。ㄈ掌?一樓窗口 二樓窗口 三樓窗口 一天消費總額 消費序號）</p><p><b>　　消費者</b></p><p>　?。ㄏM序號 姓名 性別 消費類別 消費者類別）</p><p><b>　　訂餐信息</b></p><p

95、>　　（訂餐編號 顧客姓名 聯(lián)系方式 約定時間 備注信息 消費序號 房間編號）</p><p><b>　　包房信息</b></p><p>　?。ǚ块g編號 房間位置）</p><p><b>　　學(xué)生信息</b></p><p>　　（學(xué)號 系別 班級

96、 姓名 性別 宿舍 聯(lián)系方式 消費序號）</p><p><b>　　卡信息</b></p><p>　　（卡號 余額 辦卡日期 持卡者姓名 花費 學(xué)號 教師號）</p><p><b>　　教師信息</b></p><p>　?。ń處熖?系別 姓名

97、 性別 家庭住址 聯(lián)系方式 消費序號）</p><p>　　4.1.3數(shù)據(jù)模型優(yōu)化</p><p>　　數(shù)據(jù)庫邏輯設(shè)計的結(jié)果不是唯一的，為了進一步提高數(shù)據(jù)庫應(yīng)用系統(tǒng)的性能，還應(yīng)該根據(jù)應(yīng)用需要適當(dāng)?shù)匦薷?、調(diào)整數(shù)據(jù)模型的結(jié)構(gòu)，這就是數(shù)據(jù)模型的優(yōu)化。關(guān)系數(shù)據(jù)模型的優(yōu)化通常以規(guī)范化理論為指導(dǎo)，方法為：</p><p><b>　　1、確定數(shù)據(jù)依賴&l

98、t;/b></p><p>　　2、對于各個關(guān)系模式之間的數(shù)據(jù)依賴進行極小化處理，消除冗余的聯(lián)系</p><p>　　冗余數(shù)據(jù)和冗余聯(lián)系容易破壞數(shù)據(jù)為的完整性，給數(shù)據(jù)庫維護增加困難，應(yīng)當(dāng)予以消除。經(jīng)過規(guī)范化理論得出，原關(guān)系模式之間的數(shù)據(jù)依賴已經(jīng)達到極小化，沒有冗余的聯(lián)系，消除冗余的E-R圖稱為基本E-R圖</p><p>　　3、按照數(shù)據(jù)依賴的理論對關(guān)系模式逐

99、一進行分析，考察是否存在部分函數(shù)依賴，傳遞函數(shù)依賴，多值依賴等，確定各關(guān)系模式分別屬于第幾范式。</p><p>　　4、按照需求分析階段得到的處理要求，分析對于這樣的應(yīng)用環(huán)境這些模式是否合適，確定是否要對某些模式進行合并或分解。</p><p>　　5、對關(guān)系模式進行必要的分解，提高數(shù)據(jù)操作的效率和存儲空間的利用率。</p><p>　　根據(jù)需求分析階段系統(tǒng)的功能

100、分析，這樣的應(yīng)用環(huán)境，這些模式可以完成包括消費者信息管理，預(yù)訂信息管理，成本核算管理，審查工作，庫存管理這些模塊的要求，分析結(jié)果中可在設(shè)計用戶子模式中對不同級別的用戶定義不同的view。</p><p><b>　　優(yōu)化后的關(guān)系模式：</b></p><p><b>　　庫存信息</b></p><p>　?。ㄉ唐肪幪?

101、 商品名稱 商品價格 入庫商品數(shù)量 庫存商品數(shù)量 </p><p>　　入庫時間 出庫時間 管理員編號）</p><p><b>　　管理員信息</b></p><p>　?。ü芾韱T編號 姓名 性別 家庭住址 聯(lián)系方式 工資）</p><p><b>　　管理查詢&l

102、t;/b></p><p>　?。ü芾韱T編號 日期）</p><p><b>　　消費情況</b></p><p>　　（日期 一樓窗口 二樓窗口 三樓窗口 一天消費總額 </p><p><b>　　消費序號）</b></p><p><

103、b>　　消費者</b></p><p>　?。ㄏM序號 姓名 性別 消費類別 消費者類別）</p><p><b>　　訂餐信息</b></p><p>　?。ㄓ啿途幪?顧客姓名 聯(lián)系方式 約定時間 備注信息 消費序號 </p><p><b>　　房間編

104、號）</b></p><p><b>　　包房信息</b></p><p>　?。ǚ块g編號 房間位置）</p><p><b>　　屬于</b></p><p>　?。▽W(xué)號 消費序號）</p><p><b>　　組成</b><

105、/p><p>　?。ń處熖?消費序號）</p><p><b>　　學(xué)生信息</b></p><p>　?。▽W(xué)號 系別 班級 姓名 性別 宿舍 聯(lián)系方式）</p><p><b>　　使用</b></p><p><b>　?。ㄌ?學(xué)號

106、）</b></p><p><b>　　卡信息</b></p><p>　?。ㄌ?余額 辦卡日期 持卡者姓名 花費）</p><p><b>　　持有</b></p><p>　　（卡號 教師號）</p><p><b>　　教師信

107、息</b></p><p>　?。ń處熖?系別 姓名 性別 家庭住址 聯(lián)系方式 ）</p><p>　　4.2具體邏輯模型設(shè)計</p><p>　　在上面的實體以及實體之間關(guān)系的基礎(chǔ)上，形成數(shù)據(jù)庫中的表格以及各個表格之間的關(guān)系。</p><p>　　食堂管理系統(tǒng)數(shù)據(jù)庫中各個表格的設(shè)計結(jié)果如下面的幾個表格所示

108、。每個表格表示在數(shù)據(jù)庫中的一個表。</p><p>　　表4-1為創(chuàng)建庫存信息表Stock</p><p>　　創(chuàng)建庫存信息表Stock</p><p>　　表4-2為創(chuàng)建管理員信息表Manager</p><p>　　創(chuàng)建管理員信息表Manager</p><p>　　表4-3為創(chuàng)建消費情況表ConsumeSi

109、tuation</p><p>　　創(chuàng)建消費情況表ConsumeSituation</p><p>　　表4-4為創(chuàng)建消費者表Consumer</p><p>　　創(chuàng)建消費者表Consumer</p><p>　　表4-5為創(chuàng)建訂餐信息表book_eat </p><p>　　創(chuàng)建訂餐信息表book_eat<

110、/p><p>　　表4-6為創(chuàng)建包房信息表Roominfo</p><p>　　創(chuàng)建包房信息表Roominfo</p><p>　　表4-7為創(chuàng)建學(xué)生信息表Student</p><p>　　創(chuàng)建學(xué)生信息表Student</p><p>　　表4-8為創(chuàng)建卡信息表Card</p><p>　　

111、創(chuàng)建卡信息表Card</p><p>　　表4-9為創(chuàng)建教師信息表Teacher</p><p>　　創(chuàng)建教師信息表Teacher</p><p>　　表4.10 為創(chuàng)建管理查詢表Manage</p><p>　　創(chuàng)建管理查詢表Manage</p><p>　　表 4.11 為創(chuàng)建屬于表Attribute</

112、p><p>　　創(chuàng)建屬于表Attribute</p><p>　　表 4.12 為創(chuàng)建組成表Compose</p><p>　　創(chuàng)建組成表Compose</p><p>　　表 4.13 為創(chuàng)建使用表Use</p><p><b>　　創(chuàng)建使用表Use</b></p><p>

113、　　表 4.14為創(chuàng)建持有表Hold</p><p><b>　　創(chuàng)建持有表Hold</b></p><p>　　4.3設(shè)計用戶子模式</p><p>　　將概念模型轉(zhuǎn)換為全局邏輯模型后，還應(yīng)該根據(jù)局部應(yīng)用需求，結(jié)合具體DBMS的特點，設(shè)計用戶的外模式。</p><p>　　目前關(guān)系數(shù)據(jù)庫管理系統(tǒng)一般都提供了視圖（Vie

114、w）概念，可以利用這一功能設(shè)計更符合局部用戶需要的用戶外模式。</p><p>　　定義數(shù)據(jù)庫全局模式主要是從系統(tǒng)的時間效率、空間效率、易維護等角度出發(fā)。由于用戶外模式與模式是相對獨立的，因此在定義用戶外模式時可以注重考慮用戶的習(xí)慣與方便。包括：</p><p>　　使用更符合用戶習(xí)慣的別名。</p><p>　　在合并各分E—R圖時，曾做了消除命名沖突的工作，以使

115、數(shù)據(jù)庫系統(tǒng)中同一關(guān)系和屬性具有唯一的名字。這在設(shè)計數(shù)據(jù)庫整體結(jié)構(gòu)時是非常必要的。用View機制可以在設(shè)計用戶View時重新定義某些屬性名，使其與用戶一致，以方便使用。</p><p>　　可以對不同級別的用戶定義不同的View，以保證系統(tǒng)的安全性。 </p><p>　　簡化用戶對系統(tǒng)的使用。</p><p>　　如果某些局部應(yīng)用中經(jīng)常要使用某些很復(fù)雜的查詢，為了方

116、便用戶，可以將這些復(fù)雜查詢定義為視圖，用戶每次只對定義好的視圖進行查詢，大大簡化了用戶的使用</p><p>　　消費者查詢信息所建立的視圖</p><p>　　消費者查詢自己卡中余額</p><p>　　學(xué)生查詢視圖S_Balance</p><p>　　教師查詢視圖T_Balance</p><p>　　消費者查詢

117、自己的訂餐信息</p><p>　　管理員查詢信息所建立的視圖</p><p>　　食堂買商品所需金錢數(shù)量</p><p>　　食堂每個月發(fā)給職工的工資總和</p><p>　　管理員查詢消費者信息</p><p><b>　　查詢學(xué)生的信息</b></p><p><

118、;b>　　查詢教師的信息</b></p><p><b>　　五、物理結(jié)構(gòu)設(shè)計</b></p><p>　　數(shù)據(jù)庫在物理設(shè)備上的存儲結(jié)構(gòu)與存取方法稱為數(shù)據(jù)庫物理的物理結(jié)構(gòu)，它依賴于選定的數(shù)據(jù)庫管理系統(tǒng)。為一個給定的邏輯數(shù)據(jù)模型選取最適合應(yīng)用要求的物理結(jié)構(gòu)的過程，就是數(shù)據(jù)庫的物理設(shè)計。</p><p>　　數(shù)據(jù)庫的物理設(shè)計通常分

119、為兩步：</p><p>　　確定數(shù)據(jù)庫的物理結(jié)構(gòu)，在關(guān)系數(shù)據(jù)庫中主要指存取方法和存儲結(jié)構(gòu)；</p><p>　　對物理結(jié)構(gòu)進行評價，評價的重點是時間和空間效率。</p><p>　　如果評價結(jié)果滿足原設(shè)計要求，則可進入到物理實施階段，否則，就需要重新設(shè)計或修改物理結(jié)構(gòu)，有時甚至要返回邏輯設(shè)計階段修改數(shù)據(jù)模型。</p><p><b&g

120、t;　　6.1建立索引</b></p><p>　　建立索引是加快查詢速度的有效手段。用戶可以根據(jù)應(yīng)用環(huán)境的需要，在基本表上建立一個或多個索引，以提供多種存取路徑，加快查找速度。</p><p>　　一般來說，建立與刪除索引由數(shù)據(jù)庫管理員DBA或表的屬主（owner），即建立表的人，負責(zé)完成。系統(tǒng)在存取數(shù)據(jù)時會自動選擇合適的索引作為存取路徑，用戶不必也不能顯示地選擇索引。<

121、;/p><p>　　索引的選擇方法，一般來說：</p><p>　　1. 如果一個(或一組)屬性經(jīng)常在查詢條件中出現(xiàn),則考慮在這個(或這組)屬性上建立索引(或組合索引)；</p><p>　　2. 如果一個屬性經(jīng)常作為最大值或最小值等聚集函數(shù)的參數(shù)，則考慮在這個屬性上建立索引；</p><p>　　由上所述建立以下索引</p>&l

122、t;p>　　為庫存信息表Stock建立索引</p><p>　　按Trade_name，stock_number，建立聚簇索引，</p><p>　　按entertime升序，建立唯一索引</p><p>　　為消費情況表ConsumeSituation建立索引</p><p>　　按Total建立聚簇索引</p><

123、;p>　　按Date升序，建立唯一索引</p><p>　　為訂餐信息表book_eat建立索引</p><p>　　按Consumer_name，Booktime建立聚簇索引</p><p>　　按Consumer_number升序，建立唯一索引</p><p>　　為卡信息表Card建立索引</p><p>

124、　　按Balance ,Consume建立聚簇索引</p><p>　　按Card_number升序，建立唯一索引</p><p>　　為學(xué)生信息表Student建立索引</p><p>　　按S_name建立聚簇索引</p><p>　　為學(xué)生信息表Teacher建立索引</p><p>　　按T_name建立聚簇索

125、引</p><p><b>　　6.2建立觸發(fā)器</b></p><p>　　觸發(fā)器（Trigger）是用戶定義在表上的一類由事件驅(qū)動的特殊過程。一旦定義，任何用戶對表的增、刪、改操作均由服務(wù)器自動激活相應(yīng)得觸發(fā)器，在DBMS核心層進行集中的完整性控制。觸發(fā)器類似于約束，但是比約束更加靈活，可以實施比FOREIGN KEY約束，CHECK約束更為復(fù)雜的檢查和操作，具

126、有更精細和更強大的數(shù)據(jù)控制能力。觸發(fā)器的執(zhí)行，是由觸發(fā)事件激活的，并由數(shù)據(jù)庫服務(wù)器自動執(zhí)行的。一個數(shù)據(jù)表上可能定義了多個觸發(fā)器，比如BEFORE觸發(fā)器，多個AFTER觸發(fā)器等。同一個表上的多個觸發(fā)器激活時遵循如下執(zhí)行順序：</p><p>　　執(zhí)行該表上的BEFORE觸發(fā)器；</p><p>　　激活觸發(fā)器的SQL語句；</p><p>　　執(zhí)行該表上的AFTER觸

127、發(fā)器。</p><p>　　對于同一個表上的多個BEFORE（AFTER）觸發(fā)器，遵循“誰先創(chuàng)建誰先執(zhí)行”的原則，即按照觸發(fā)器創(chuàng)建的先后順序執(zhí)行。有些RDBMS是按照觸發(fā)器的名稱的字母排序順序執(zhí)行觸發(fā)器。</p><p>　　定義AFTER行級觸發(fā)器，當(dāng)管理員表Manager的工資發(fā)生變化后就自動在工資變化表Inc_log中增加一條相應(yīng)的記錄</p><p>　　首

128、先建立工資變化表Inc_log</p><p>　　CREATE TABLE Inc_log</p><p>　　(Manager_number varchar(6) REFERENCES Manager(Manager_number),</p><p>　　Income int,</p><p>　　Manager_name varchar

129、(6),</p><p>　　Date TIMESTAMP</p><p><b>　　);</b></p><p>　　接著建立觸發(fā)器 Insert_Inc</p><p>　　CREATE TRIGGER Insert_Inc</p><p>　　AFTER INSERT ON Manager