1、網上餐廳系統 商家開店模塊摘要 隨著社會經濟的發展，人們日常生活的壓力不斷增大，親自到餐廳用餐讓人們感覺到是浪費時間的行為了。取而代之的則是網上訂餐，既可以節省大量的時間，也可以買到物美價廉的美食。該項目根據對網上餐廳的實際需求分析，并通過可行性分析之后，運用UML建模的思想對系統進行建模，采用自頂向下的原則對系統進行詳細的設計與實現。該項目采用三層架構來對程序中不同的功能進行分類，程序后臺采用ADO.NET技術實現對數據庫的操作，獲取數據庫的數據。前臺則是采用了jQuery技術使得頁面的前臺效果得到大量的提升，也提升了頁面的友好性，更加可以吸引住用戶的眼球。關鍵詞： 網上訂餐 ADO.NET

2、 jQuery 三層架構Online restaurant system -Meal inquiry / purchase，ShopCar，Order submissionABSTRACT With the development of social economy, the pressure of people's daily life increases, and the dining room dining room makes people feel like a waste of time. Replace sb. is online meal ordering,

3、which can save a lot of time, also can buy high quality and inexpensive Food. The project according to the actual needs of the dining - room on the net analysis, and after the feasibility analysis, the use of UML modeling concept to the system modeling, detailed design and implementation of the syst

4、em by using the top-down design principle. The project uses three layers of structure to classify the different functions of the program. The program background uses ADO.NET technology to realize the operation of the database and get the database data. Front desk is the use of jQuery technology

5、 makes the front effect of the page to get a lot of promotion, but also enhance the page's friendliness, more can attract the user's eye. Key words: Online meal ordering ADO.NET jQuery Three tier architecture目 錄第一章 緒論1 1.1 背景1 1.2 國內外現狀1 1.3 選題目的及意義1 1.4 本系統主要工作2 1.5 可行性分析2 1.5.1 經濟可行性2 1.5.

6、2 技術可行性2 1.5.3 社會可行性2第二章 開發環境3 2.1 開發工具介紹3 2.1.1 Visual studio 20133 2.1.2 SQL Server 20123 2.2 主要技術3 2.2.1 技術3 2.2.2 ADO.NET 技術3 2.2.3 三層架構技術4 2.2.4 jQuery 技術4 2.3本章小結4第三章 需求分析5 3.1 功能模塊劃分5 3.2 用例分析7 3.2.1 商家開店注冊模塊7 3.2.2 商家信息管理模塊7 3.2.3 商家餐品管理模塊8 3.3 數據流圖9 3.3.1 商家開店注冊管理9 3.3.2 商家信息管理9 3.3.3 商家餐品管

7、理10 3.4 數據字典10 3.5 本章小結13第四章 概念設計14 4.1 E-R圖14 4.2 本章小結 17第五章 邏輯設計18 5.1 關系模式18 5.2 本章小結20第六章 物理設計21 6.1 物理表設計21 6.2 數據表關系25 6.3 本章小結26第七章 詳細設計27 7.1 設計及實現27 7.1.1 商家開店注冊27 7.1.2 商家餐廳登錄28 7.1.3 商家餐品添加30 7.2 本章小結35第八章 測試與實現36 8.1 測試的目的36 8.2 測試的過程36 8.2.1 網站系統首頁部分36 8.2.2 網站登錄功能37 8.2.3 商家開店注冊模塊38 8.

8、2.4 商家信息塊39 8.2.5 商家餐品模塊40 8.3 本章小結43參考文獻44致謝45天津理工大學2012級本科專業設計第一章 緒論1.1 背景隨著社會經濟的發展，人們日常生活的壓力不斷增大，親自到餐廳用餐讓人們感覺到是浪費時間的行為了，取而代之的則是網上訂餐。網上訂餐既可以節省大量的時間，也可以買到物美價廉的美食。而一個網上訂餐系統，則包括了很多不同的功能。最普遍的是要對餐品信息的管理，因為有大量的餐品信息需要保存，所以對數據的管理也是非常重要的，一點數據的偏差，都會引起消費者的誤會，小則影響一些小規模的收入情況，大則甚至會影響到公司整個的業務情況。一些別的功能則包括了一些其他餐廳想

9、要在這個網上訂餐網站上面開店面、顧客對餐廳的評價、餐品購買加入購物車的功能、餐品訂餐后的賬單提交功能以及后臺中網站管理員對網站的整個信息的一個掌控情況。所有功能的齊全，才能保證網上訂餐系統的運營正常。1.2 國內外現狀 對于網上訂餐這種新興的產業來說，外國的起步確實要比國內的起步要早一些。這種產業對于我們現實中的生活來說，確實有著很大的幫助。通過這種方法，可以節省我們大量的時間。因此，進行網上訂餐確實是一種更新型的訂餐方法。 在國外，人們通過電腦上網或者是手機上網的方式進行餐品的預訂。網上訂餐一般都是通過互聯網技術，在網絡上面開設一家“網上餐廳”。除此之外，商家還需要為自己配備良好的物流系統，

10、為餐品的配送過程提供了堅實的保障。所以，網上訂餐在國外有著非常廣泛的人群支持，所以進而使得網上訂餐這項服務得到廣泛的應用，并且也得到了人們普遍的認可。 而在國內的現狀來看，網上訂餐在網絡的安全性和系統的各項更新這些方面中，都存在著不同程度的不足。正是這些不足，使得顧客的數量得不到保障；而網站系統的推廣也受到了阻礙。人們依舊過著去餐廳進餐的生活方式。 因此，網上訂餐系統的更新應受到更大的重視，在不斷的改善和推廣之后。我相信這項產業將會成為人們日常生活當中不可或缺的一項功能了。研究出更加完善的網上訂餐系統框架，也會方便以后的開發、更新。1.3 選題目的及意義 為了使我國的餐飲服務體系更加完善，開發

11、一個網上訂餐系統對我們的現實生活是非常有必要的。不僅僅可以使顧客節省大量的時間，使顧客品嘗到優質的美食也是網上餐飲系統的主要功能之一。本課題研究的意義包括: （1）網上訂餐的主流地位：隨著我國的經濟發展速度不斷增加，人們的工作壓力也在不斷地上升,網上訂餐已經成為人們節省時間的主流方式之一。隨著菜品的數量不斷增加,對菜品數據的保存也顯得非常的至關重要，如果菜品數據有偏差的話，將會對餐廳的生意造成一些相應的影響。 （2）作為現代社會新興的產業，網上餐廳的訪問量將會不斷地得到提升，影響力也會越來越大。 （3）網上餐廳的創建，一定要建立一個網站作為介紹自己餐廳的平臺，所以我們這次研究這個項目就是針對這

12、樣的用戶來設計的，以此來滿足他們的要求。1.4 本系統主要工作本系統的設計主要是設計一個網上訂餐平臺，而本子系統完成了外來商家的餐品查詢、購買，以及對這些商家餐廳的評論功能管理，還有用戶購買完餐品之后，對訂單的一個提交的過程。本網站平臺包括的餐廳包括了一個主餐廳和外來附加的一些其他餐廳。其他餐廳需要在網站平臺上面進行注冊之后才可以進行開店，而其他餐廳的餐品信息就是本子系統要做的主要功能之一。顧客通過對這些餐廳的餐品信息表進行查詢之后，可以進行一個購買的操作。當然，顧客不僅僅可以進行餐品購買的操作，還可以進行一個對餐廳評價的操作，這個小小的功能卻可以讓顧客感覺出來網站的友好性，找出餐廳的優點和缺

13、點進行分享。最后顧客在這個網上訂餐系統購買完所有的餐品之后，將會把購買的餐品加入到購物車中，填寫完訂餐信息表之后進行提交，提交過后，購物車的信息將會清空，而個人的購買歷史則會加上顧客剛剛的購買情況。1.5 可行性分析1.5.1 經濟可行性本子系統是由我們的研究小組自己進行設計以及開發、測試，并不會在資金方面有過大的要求。當本研究項目完成，投入市場進行使用的時候，將會帶來不少的經濟回報，所以在經濟這方面，該項目可行。1.5.2 技術可行性我們設計的該網上訂餐系統，主要采用了，jQuery,ADO.NET,三層架構技術，所要求的技術水平不高，可以很容易地掌握好這幾項技術，但是這幾項技術卻非常具有實

14、用性，開發效率也非常高，節省了不少的開發周期，所以，在技術方面，該項目可行。1.5.3 社會可行性網上餐廳的項目在當今社會中非常的熱門，隨著社會經濟的發展，人們工作壓力的不斷增大，網上訂餐必將成為社會的主要趨勢之一。并且該項目的開發完全遵守了相關法律法規的要求。所以，在社會方面，該項目可行。綜上所述，通過對網上訂餐系統的可行性分析，本系統開發目標明確，在技術、經濟、社會等方面都可行，因此本系統的開發是完全可行的。第2章 開發環境2.1 開發工具介紹2.1.1 Visual studio 2013 作為新一代C#語言編輯器、編譯器。在我們的項目制作過程中必不可少。通過這個工具，將開發出

15、各種應用軟件來提供給人們使用。除此之外，還有Visual studio 2008/2010/2012不同的版本進行使用。強大的差錯機制和簡單的注釋功能將給人們帶來更方便的開發過程，而TFS2012更適合團隊的項目開發，通過TFS2012的簽入、簽出等功能確實可以方便開發團隊的協作能力。而作為最新一代的編程工具，Visual studio 2013擁有了更加強大的網頁設計工具，更加方便了網頁的開發過程。2.1.2 SQL Server 2012新一代的數據存儲工具，SQL Server 2012不僅擁有了更強大的數據處理平臺，也將支持云技術的發展。大量的數據存儲能力使得這個工具使用起來更加的得心

16、應手。除此之外，數據的查詢能力也得到了相應的改善，而觸發器，存儲過程等常用功能當然也會延續到這個版本當中。SQL Server 2012的發布，可以幫助更多的企業用戶快速實現各種數據的體驗功能，也將完全釋放對企業的一種洞察力。而快速的數據發現，可擴展的自助數據處理能力，可靠、一致的數據，全方位的企業數據解決方案將會是這個版本數據庫的特色之處。2.2 主要技術2.2.1 技術作為網頁開發的一項新技術，技術是對網頁開發的一項技術支持。而ASP.NET也是在公共語言運行庫上面的一種新型的編程框架。而與傳統的桌面程序不相同的是，ASP.NET所開發的程序包含了許多的Web頁面，用戶可以直接訪問到不同的

17、頁面，使用的隨意程度也將大大提升。當然也可以通過點擊在頁面中的一個超鏈接來訪問到不同的頁面。ASP.NET應用程序的標準定義是：文件、頁面、處理器、模塊和可執行代碼的組合，并且他們能夠從服務器上的一個虛擬目錄中被引用。總體來說，這項技術就是為網頁開發而生的，使用起來也將更加的方便。2.2.2 ADO.NET技術 ADO.NET技術是訪問數據庫的一項技術，獲取數據庫的數據將包括兩種方式：一種是不斷開程序與數據庫的連接，實時地交互數據信息；另一種方式是將數據獲取到之后，存儲到DataSet中，然后斷開與數據庫的連接，程序將會到DataSet中進行數據的獲取。總體而言，后一種的數據獲取方式更為流行，

18、因為連接到數據庫將會使用到大量的內存。 獲取數據一般有EF,Linq To SQL和ADO.NET，作為其中之一，這項技術發展到現在也是變得非常的成熟，但不是最先進的一項技術了。但是對于小程序來說，這種技術的使用還是最好、最方便的方式。2.2.3 三層架構技術 三層架構技術是一種新型的開發方式，通過將程序中代碼的不同功能分為了界面UI層，業務邏輯層BLL和數據訪問層DAL。 雖然看起來更復雜了，但是將程序內容進行分類之后，你會發現程序代碼之間的調用將會變得更加方便了。數據訪問層DAL，主要是與數據庫之間數據的交互，并不會關心前臺界面的情況和數據的依賴關系等。業務邏輯層BLL將會調用數據訪問層所

19、獲取到的數據和方法，對數據進行一個一般的處理過程。界面UI層主要是對網頁的前臺頁面需要獲取的數據信息進行一個整理的過程，獲取到的數據信息將會在這里進行歸納和整理，之后將會呈現到前臺頁面當中。2.2.4 jQuery技術 jQuery技術主要就是一個包含了大量JavaScript代碼的程序庫，通過指定的代碼語句進行方法的調用過程。而過濾器、選擇器的使用將會使頁面中控件的獲取變得更加容易了。 此外jQuery提供的特效也是頁面中的一大特色和亮點。2.3 本章小結 本章主要介紹了在我們的開發過程中采用的技術。正是有了這些技術的支持，我們才可以順利地進行項目的開發，此外還介紹了這些技術主要內容。第三章

20、 需求分析隨著社會經濟的不斷發展，人們的生活節奏也會不斷加快，生活壓力也會不斷增大，為了節省時間，人們的生活方式也會發生相應的改變來適應這樣的生活。而網上訂餐就是其中的一種，人們生活中經常會因為吃一頓飯而會遇到：等車、馬路堵塞、買飯排隊等不同的狀況，這些狀況都會耽誤顧客不少的寶貴時間，人們常常也會因為這些原因而感到頭疼。所以，網上訂餐系統就變得非常有必要了，成為了人品日常生活中非常需要的一項功能了。人們只需要在網站上面選取自己需要的餐品，之后就可以等待送餐員將餐品送到顧客的手中了。該網上訂餐系統包括了前臺餐品展示和后臺數據管理的功能，而本子系統的主要是創建了對餐品信息的展示、對餐品的購買、對餐

21、廳的評價，以及最后訂單提交的功能。本網站平臺包括的餐廳包括了一個主餐廳和外來附加的一些其他餐廳。其他餐廳需要在網站平臺上面進行注冊之后才可以進行開店，而其他餐廳的餐品信息就是本子系統要做的主要功能之一。顧客通過對這些餐廳的餐品信息表進行查詢之后，可以進行一個購買的操作。當然，顧客不僅僅可以進行餐品購買的操作，還可以進行一個對餐廳評價的操作，這個小小的功能卻可以讓顧客感覺出來網站的友好性，找出餐廳的優點和缺點進行分享。最后顧客在這個網上訂餐系統購買完所有的餐品之后，將會把購買的餐品加入到購物車中，填寫完訂餐信息表之后進行提交，提交過后，購物車的信息將會清空，而個人的購買歷史則會加上顧客剛剛的購買

22、情況。3.1 功能模塊劃分本網上訂餐系統采用自頂向下，逐步分解的原則將系統劃分為用戶管理，餐品信息管理，評論管理，購物車管理，訂單管理，商家開店，后臺數據操作管理七大功能模塊。其中商家子模塊功能模塊圖如下3.1功能劃分。 圖3.1 商家開店模塊功能圖 Figure 3.1 Merchant shop management module function diagram其中商家餐品管理包括餐品信息信息添加，餐品信息修改，餐品信息刪除，在添加餐品的同時，餐品會顯示在前臺的頁面上，供用戶選擇訂餐 圖3.2 商家餐品管理管理模塊功能圖 Figure 3.1 Business meal manageme

23、nt module function diagram 商家信息管理包括商家信息修改、商家信息添加、刪除商家，其中刪除商家是根據同商家商量，商家主動退出網上訂餐平臺或商家餐品惡劣者強制把商家開除。 圖3.3 商家信息管理模塊功能圖 Figure 3.3 Business information management module function 3.2 用例分析3.2.1商家開店注冊模塊商家開店注冊模塊，商家填寫基本信息，選擇餐飲店類型，然后向管理員提交申請。本模塊的用例圖如圖3.4所示： 圖3.4 商家開店注冊用例圖 Figure 3.4 Use case diagram Merchant

24、shop management 3.2.2商家信息管理模塊 當商家注冊開店審批通過了后，商家信息就會被記錄下來，其中商家信息管理包括后期管理員對商家信息的一些更改與通過訂餐用戶的評論反饋對商家的一些建議，或者采取一些措施。本模塊的用例圖如圖3.5所示: 圖3.5 商家信息管理用例圖 Figure 3.5 Business information management use case diagram 3.2.3 商家餐品管理模塊網站管理員負責編輯餐品的信息，然后在網站前臺進行展示。顧客查看完餐品信息之后對餐品進行購買操作，將餐品添加到購物車當中。本模塊的用例圖如圖3.6所示: 圖3.6 商家餐

25、品管理用例圖 Figure 3.6 Use case diagram Business meal management 圖3.7 商家信譽管理用例圖 Figure 3.7 Use case diagram Business reputation management 3.3 數據流圖 數據流圖(Data Flow Diagram):簡稱DFD，它從數據傳遞和加工角度，以圖形方式來表達系統的邏輯功能、數據在系統內部的邏輯流向和邏輯變換過程，是結構化系統分析方法的主要表達工具及用于表示軟件模型的一種圖示方法。3.3.1 商家開店注冊管理 商家開店注冊管理數據流圖 商家首先申請注冊開店，然后填寫基本

26、信息與選擇開店類型，系統驗證信息是否符合要求，最后提交后臺給管理員審批。如圖3.7是商家開店注冊管理的數據流圖，圖中的輸入為商家申請，輸出給管理員。 圖3.7 商家開店管理數據流圖 Figure 3.7 Merchant shop management data flow diagrams 3.3.2 商家餐品管理 商家餐品管理數據流圖管理員從餐廳表和餐廳餐品表中得到餐品的相應信息，在前臺頁面進行餐品信息的展示，讓顧客有一個對信息的掌握，然后可以對餐品進行一個購買的操作。如圖3.8是餐品信息管理的數據流圖。 圖3.8 商家餐品管理數據流圖 Figure 3.9 Business meal ma

27、nagement data flow diagrams 3.3.3 商家評價管理 商家評價數據流圖 顧客在訂餐后可以得到一定的售后服務，同時可以對商家餐廳以及餐品進行評價與建議，同時也可以進行顧客的權利維護，在顧客對商家的評價后，系統也將對商家的信譽度進行統計與整理，對于一些不良好的餐廳進行整頓，對一些信譽度高的餐廳給予一定的獎勵措施 圖3.9 商家信譽管理數據流圖 Figure 3.9 Business reputation manage data flow diagram 3.4 數據字典數據字典其實就是對數據的各種屬性進行的一個描述過程。其主要的目的就是要對數據流程圖中的各個元素進行一個

28、詳細說明的作用。數據字典是一種用戶可以訪問的記錄數據庫和應用程序源數據的目錄。主動數據字典是指在對數據庫或應用程序結構進行修改時，其內容可以由DBMS自動更新的數據字典。被動數據字典是指修改時必須手工更新其內容的數據字典。模塊名稱商家信息管理編號D1名稱商家信息表組織形式：按照商家編號進行排序關鍵字：商家編號，商家名記錄組成：商家信息簡要說明：記錄所有商家的信息 表3.1 商家信息數據流存儲 Table 3.1 Business information data flow 表3.2 商家餐品數據流存儲 Table 3.2 Storage products information data fl

29、ow 模塊名稱商家餐品管理編號D2名稱商家餐品信息表組織形式：按照餐品的編號進行排序關鍵字：餐品編號，餐品名,商家名記錄組成：餐品信息簡要說明：記錄所有的餐品信息 表3.3 商家注冊數據流存儲 Table 3.3 ShopCar the data flow 模塊名稱商家注冊管理編號D3名稱商家注冊表組織形式：按照商家評價的編號進行排序關鍵字：商家評價編號，用戶名，注冊餐廳類型記錄組成：商家注冊信息簡要說明：將商家注冊信息錄入 表3.4 餐品評價數據流存儲 Table 3.4 Restaurant order data storage 模塊名稱餐品評價管理編號D4名稱餐品評價表組織形式：按照餐品

30、評價編號進行排序關鍵字：餐品評價編號，用戶名，評價星級，評價內容記錄組成：訂單信息簡要說明：收集訂餐人的信息，向后臺進行提交。 表3.5 商家信息管理數據流 Table 3.5 Restaurants, food product data flow 模塊名稱商家信息管理編號F1名稱商家信息來源：餐品表，餐廳表去處：顧客數據流結構：基本信息=餐廳編號，餐廳名稱，餐品編號，餐品名稱簡要說明：記錄所有的餐品場信息 表3.6 餐品信息管理數據流 Table 3.6 Shopping cart data flow 模塊名稱餐品信息管理編號F2名稱餐品信息來源：商家提供的餐品去處：顧客數據流結構：基本信息

31、=用戶名，餐品名稱，價格，數量，餐廳名稱簡要說明：將用戶的購物車信息添加到此處 表3.7 商家注冊數據流 Table 3.7 Restaurant order data flow 模塊名稱商家注冊管理編號F3名稱商家注冊信息來源：顧客訂單表去處：送餐人送餐信息表數據流結構：基本信息=商家編號，商家名，選擇餐飲類型簡要說明：記錄商家注冊信息3.5 本章小結需求分析的任務是通過詳細調查現實世界要處理的對象，充分了解原系統工作概況，明確用戶的各種需求然后在此基礎上確定新系統的功能。 一、確定對系統的綜合要求雖然功能需求是對軟件系統的一項基本需求，但卻并不是唯一的需求，通常對軟件系統有下述幾方面的綜合

32、要求：1.功能需求2.性能需求3.可靠性和可用性需求4.出錯處理需求5.接口需求6.約束7.逆向需求8.將來可能提出的要求第4章 概念設計4.1 E-R圖大部分數據庫設計產品使用實體-聯系模型（ER模型）幫助用戶進行數據庫設計。ER數據庫設計工具提供了一個“方框與箭頭”的繪圖工具，幫助用戶建立ER圖來描繪數據。E-R圖是一種概念模型，用矩形表示實體型，矩形框內寫明實體名；橢圓表示實體的屬性。本子系統模塊涉及到的實體有：餐品、餐廳、顧客、購物車、訂單。餐品擁有的屬性為：餐廳名稱、餐品名稱、價格。如圖4.1是餐品的E-R圖。餐廳擁有的屬性為：編號、登錄名、密碼、餐廳名、地址、電話。如圖4.2是餐廳

33、的E-R圖。顧客擁有的屬性為：編號、登陸名、密碼、電子郵箱。如圖4.3是顧客的E-R圖。購物車擁有的屬性為：用戶名，餐品名稱，價格，數量，餐廳名稱。如圖4.4是購物車的E-R圖。訂單的屬性為：訂單編號、送餐員、送餐地址、餐品名稱、餐品數量、餐品價格、訂餐人姓名、訂餐人電話。如圖4.5是訂單的E-R圖。 圖4.1 商家的E-R圖 Figure 4.1 Products of the E-R diagram 圖4.2 餐廳的E-R圖 Figure 4.2 The restaurant's E-R diagram 圖4.3 顧客的E-R圖 Figure 4.3 Customers of e-

34、r diagram 圖4.4 餐品的E-R圖 Figure 4.4 Shopping cart e-r diagram 現在將全部的E-R圖的實體聯系在一起，得到如圖4.6所示的初步E-R圖。 圖4.6 子系統模塊的初步E-R圖 Figure 4.6 Preliminary E - R diagram of subsystem module 由圖4.6可知，餐廳表只保存了餐廳的信息，餐品表只保存了餐品表，把餐廳表和餐品表聯系在一起，可以使每件餐品都有所屬的餐廳的信息了。顧客查看完餐品信息之后，將餐品添加到購物車當中，購物車就包含了餐品的詳細信息。顧客與購物車的關系是一一對應的，并且顧客可以對購

35、物車信息進行修改。顧客在確認完購物車信息之后，可以進行一個訂單提交的操作，顧客與餐品是一對多的關系。總體E-R圖詳細信息如圖4.7所示： 圖4.7 子系統模塊的全局E-R圖 Figure 4.7 Subsystem module of global E - R diagram 4.2 本章小結 該子系統模塊采用e-r圖來進行系統的概念設計，e-r圖并且也提供了表示實體類型、屬性以及聯系的不同方法，以此用來描述現實世界的概念模型，更好的將系統中所涉及到的實體聯系起來，消除了冗余，使系統在表的設計上更加合理。第5章 邏輯設計 進行邏輯設計的時候，將現實世界中的概念數據模型設計為適于特定數據庫系統的

36、邏輯數據模式。關系數據庫的數據模式是關系模式。5.1 關系模式為了使數據庫結構更加合理、緊湊，消除不必要的一些存儲異常，使數據庫內數據的冗余盡量減小，便于數據的插入、刪除和更新等操作。更需要對關系模式進行規范化的操作。當關系模式進行規范化的時候，也需要遵從概念單一化 "一事一地"的原則，也就是說一個關系模式去描述一個實體或這些實體間的一種必要聯系。規范的本質就是要追求概念的單一化。關系模式進行規范化的方法：把一個關系模式的投影分解成為兩個或更多的關系模式來操作。分解之后的關系模式集合應該與最初的關系模式進行"等價"，也就是說經過了自然聯接就可以恢復原關系

37、而可以不丟失重要信息，并且可以保持屬性間合理的聯系。現在概念設計的基礎上可以得到如下的初步關系模式：（1） 餐廳（餐廳編號，餐廳名稱，餐廳登陸名，餐廳密碼，餐廳地址，餐廳電話）（2） 餐品（餐廳名稱，餐品名稱，價格）（3） 顧客（顧客編號，顧客登錄名，顧客密碼，顧客電子郵箱）（4） 購物車（顧客登錄名，餐品名稱，價格，數量，餐廳名稱）（5） 在線支付賬單（賬單編號，送餐員編號，送餐地址，送餐名稱，餐品數量，訂餐人姓名，訂餐人電話）（6） 餐到付款賬單（賬單編號，送餐員編號，送餐地址，送餐名稱，餐品數量，餐品單價，餐品總價，訂餐人姓名，訂餐人電話）（7） 送餐員（送餐員編號，送餐員姓名，送餐員登

38、錄名，送餐員密碼，送餐類型）關系范式的證明： （1）餐廳（餐廳編號，餐廳名稱，餐廳登陸名，餐廳密碼，餐廳地址，餐廳電話） 證明：因為餐廳編號->(餐廳名稱，餐廳登陸名，餐廳密碼，餐廳地址，餐廳電話),所以，餐廳編號是候選碼；又因為餐廳名稱->（餐廳編號，餐廳登錄名，餐廳密碼，餐廳地址，餐廳電話），所以，餐廳名稱是候選碼；所以，餐廳編號、餐廳名稱是主屬性，餐廳登錄名、餐廳密碼、餐廳地址、餐廳電話是非主屬性；因為不存在非主屬性對主屬性的部分函數依賴，所以該范式屬于第二關系范式；又因為不存在非主屬性對主屬性的傳遞函數依賴，所以該范式屬于第三關系范式；又因為所有非主屬性對每一個碼都是完全函

39、數依賴，沒有任何屬性完全函數依賴于非碼的任何一組屬性，所以此范式屬于BC范式。 （2）餐品（餐廳名稱，餐品名稱，價格）該表即不存在主鍵又不存在外鍵，所以不存在函數依賴，范式。（3）顧客（顧客編號，顧客登錄名，顧客密碼，顧客電子郵箱）證明：因為顧客編號->（顧客登錄名，顧客密碼，顧客電子郵箱），所以，顧客編號是候選碼； 因為顧客登錄名->（顧客編號，顧客密碼，顧客電子郵箱），所以，顧客登錄名是候選碼；因為不存在非主屬性對主屬性的部分函數依賴，所以該范式屬于第二關系范式；又因為不存在非主屬性對主屬性的傳遞函數依賴，所以該范式屬于第三關系范式；又因為所有非主屬性對每一個碼都是完全函數依賴

40、，沒有任何屬性完全函數依賴于非碼的任何一組屬性，所以此范式屬于BC范式。（4）購物車（顧客登錄名，餐品名稱，價格，數量，餐廳名稱）證明：因為顧客登錄名->（餐品名稱，價格，數量，餐廳名稱），所以，顧客登錄名是候選碼；因為不存在非主屬性對主屬性的部分函數依賴，所以該范式屬于第二關系范式； （5）在線支付賬單（賬單編號，送餐員編號，送餐地址，送餐名稱，餐品數量，訂餐人姓名，訂餐人電話）證明：因為賬單編號->（送餐員編號，送餐地址，送餐名稱，餐品數量，訂餐人姓名，訂餐人電話），所以，賬單編號是候選碼。又因為送餐員編號->（賬單編號，送餐地址，送餐名稱，餐品數量，訂餐人姓名，訂餐人電

41、話），所以，送餐員編號是候選碼。因為不存在非主屬性對主屬性的部分函數依賴，所以該范式屬于第二關系范式；又因為不存在非主屬性對主屬性的傳遞函數依賴，所以該范式屬于第三關系范式；又因為所有非主屬性對每一個碼都是完全函數依賴，沒有任何屬性完全函數依賴于非碼的任何一組屬性，所以此范式屬于BC范式。（6）餐到付款賬單（賬單編號，送餐員編號，送餐地址，送餐名稱，餐品數量，餐品單價，餐品總價，訂餐人姓名，訂餐人電話） 證明：因為賬單編號->（送餐員編號，送餐地址，送餐名稱，餐品數量，餐品單價，餐品總價，訂餐人姓名，訂餐人電話），所以，賬單編號是候選碼。 又因為送餐員編號->（賬單編號，送餐地址，

42、送餐名稱，餐品數量，餐品單價，餐品總價，訂餐人姓名，訂餐人電話），所以，送餐員編號是候選碼。因為不存在非主屬性對主屬性的部分函數依賴，所以該范式屬于第二關系范式；又因為不存在非主屬性對主屬性的傳遞函數依賴，所以該范式屬于第三關系范式；又因為所有非主屬性對每一個碼都是完全函數依賴，沒有任何屬性完全函數依賴于非碼的任何一組屬性，所以此范式屬于BC范式。（7）送餐員（送餐員編號，送餐員姓名，送餐員登錄名，送餐員密碼，送餐類型） 證明：因為送餐員編號->（送餐員姓名，送餐員登錄名，送餐員密碼，送餐類型），所以，送餐員編號是候選碼。因為不存在非主屬性對主屬性的部分函數依賴，所以該范式屬于第二關系范

43、式；5.2 本章小結數據庫邏輯設計是將還沒有設計出來的數據庫，即還處在概念意義上面的數據庫模型設計為更適合自己系統程序的一種設計模式。而設計更全面、更規范的關系模式將會設計出更高效率、更符合自己程序系統的數據庫系統。邏輯設計比物理設計更理論化和抽象化，關注對象之間的邏輯關系，提供了更多系統和子系統的詳細描述。第6章 物理設計數據庫物理設計是后半段。將一個給定邏輯結構實施到具體的環境中時，邏輯數據模型要選取一個具體的工作環境，這個工作環境提供了數據存儲結構與存取方法，這個過程就是數據庫的物理設計。物理結構依賴于給定的DBMS和和硬件系統，因此設計人員必須充分了解所用RDBMS的內部特征、存儲結構

44、、存取方法。數據庫的物理設計通常分為兩步，第一，確定數據庫的物理結構，第二，評價實施空間效率和時間效率。6.1 物理表設計 該子模塊系統使用到的表有：餐廳表，餐品表，顧客表，顧客購物車表，訂單表（包括在線支付訂單表和餐到付款訂單表）和送餐員表。 餐廳表主要收錄了所有在網站系統上面注冊過的餐廳信息，包括了主鍵餐廳編號和外鍵餐廳名稱。表6.1 餐廳表Table6.1 Dining room table列名數據類型是否允許為空說明 CompanyIdIntNot Null餐廳編號 主鍵CompanyLoginNameVarchar(50)Not Null餐廳登錄名CompanyPasswordVar

45、char(50)Not Null餐廳密碼CompanyNameNvarchar(50)Not Null餐廳名稱 外鍵CompanyAddressNvarchar(50)Not Null餐廳地址CompanyTelVarchar(50)Not Null餐廳電話餐品表主要收錄了所有餐品的信息，通過餐廳名稱來進行分類。表6.2 餐品表Table6.2 Table of Products 列名數據類型是否允許為空說明CompanyNameNvarchar(50)Not Null餐廳名稱FoodNameNvarchar(50)Not Null餐品名稱PriceVarchar(50)Not Null價格顧

46、客表主要記錄了在網站系統上面注冊的顧客的個人信息，包括了主鍵用戶編號和外鍵顧客登錄名。表6.3 顧客表Table6.3 Table of Custoemr列名數據類型是否允許為空說明CustomerIdIntNot Null顧客編號 主鍵CustomerLoginNameNvarchar(50)Not Null顧客登錄名 外鍵CustomerPasswordVarchar(50)Not Null顧客密碼CustomerEmailNvarcar(50)Null顧客電子郵箱 購物車表主要收錄了用戶在網站上面購買的商品臨時添加容器，一邊接下來的結賬操作的簡易型。表6.4 購物車表Table6.4 Table of ShopCar列名數據類型是否允許為空說明CustomerLoginNameNvarchar(50)Not Null顧客用戶名FoodNameNvarchar(50)Not Null餐品名稱PriceVarchar(50)Not Null價格NumberVarchar(50)Not Null數量CompanyNameNvarchar(50)Not Null餐廳名