年4月19日SQL數據庫課程設計網上訂餐系統設計文檔僅供參考電子商務網絡數據庫課程設計課程名稱：電子商務網絡數據庫及應用作業題目：網上訂餐數據庫系統設計作業時間：1月專業班級：10級電子商務姓名：學號：授課教師：南昌工程學院工商管理學院——年第一學期目錄第一章需求分析 31.1訂餐現狀分析 31.2顧客需求分析 31.3管理員需求分析 31.4性能需求分析 31.5可行性分析 41.6總體設計原則 4第二章數據庫概念結構設計 52.1系統E-R圖 52.2數據流圖 62.3數據字典 6.3.1數據項 62.3.2數據結構 72.3.3處理過程 7第三章數據庫邏輯結構設計 103.1數據庫邏輯結構初步構思 103.2具體邏輯結構設計 11第四章數據庫的物理結構設計 124.1表間關系設計 124.2完整性設計 12第五章數據庫系統的實施 145.1數據庫的建立 145.2數據輸入 14第六章數據庫運行和維護 166.1定義并設置備份策略 166.2啟用數據庫維護計劃任務 16第七章報告總結 18

第一章需求分析1.1訂餐現狀分析現在普遍使用的訂餐方式是進行電話預定，這種預訂方式方便，錯誤率也比較低，可是由此引發的一些不良現象也比較多，主要是訂餐后出現飯店并沒有將信息記錄在案，而且電話里不能看到菜品的圖片，對菜量和菜品樣式沒有直觀的概念。另外這種訂餐方式只是進行電話的預約，很可能會出現訂餐可是不履行訂單也不進行訂餐取消的現象，訂餐人員對訂購的餐桌信息不太了解會進行相關信息的詢問，這樣就在一定程度上造成了時間的浪費，飯店人員會在同一天重復重復相同的信息，造成了人力資源的浪費。這樣開發出圖文并茂，信息能夠及時更新和查看的在線網上訂餐系統就具有了重要的意義。1.2顧客需求分析顧客模塊的功能包括個人信息管理，美食選購，美食評價三大功能。其中，在個人信息管理中能夠對個人信息進行修改、還能夠查閱以往訂過的美食信息；在選購美食中能夠經過購物車直接購買的形式、也可已選擇貨到付款的形式完成交易；美食評價中顧客能夠這對這次服務質量，留下自己相對餐廳說的話，完成用戶與餐廳之間的交互。1.3管理員需求分析管理員模塊的功能包括菜品管理，訂單管理，會員信息管理三大功能。其中，在個菜品管理中能夠對菜品信息進行添加、修改和查詢操作；在訂單管理中能夠經過未確認、已確認、已下單三種形式進行管理、也可查看所有訂單信息；會員信息管理中，能夠添加會員信息和修改會員信息，進而方便顧客網上訂購美食，并享有優惠，這一做法人性化的完成網站的推廣，避免了顧客的抵觸情緒。1.4性能需求分析該系統在性能功能上應達到如下需求：操作簡單、界面友好:完全控件式的頁面布局，使得菜品，資訊，座位等信息的錄入工作更簡便，許多選項包括餐廳信息，桌位，包房信息等只需要點擊鼠標就能夠完成；另外，跟蹤出現的提示信息也讓用戶隨時清楚自己的操作情況。對常見的類似網站的管理的各個方面：基本信息錄入、瀏覽、刪除、修改、搜索等方面都大致實現，顧客對菜品的預定及支付方式；即時可見:對客戶預定餐飲信息的處理（包括錄入、刪除）將立即在主頁的對應欄目顯示出來，達到“即時發布、即時見效”的功能；系統運行應該快速、穩定、高效和可靠；在結構上應具有很好的可擴展性，便于將來的功能擴展和維護。1.5可行性分析隨著經濟的快速發展，B2C電子商務越來越受到人們的關注。網上訂餐類網站，已經如雨后春筍般的出現在了個大城市。特別在公司，企業內部，團體訂餐已經成為了趨勢。同時，隨著全國人民的精神、物質和文化生活高度的提高，人們已經不在僅僅停留在吃飽的程度，不但要吃飽，還要吃好，而且口味也越來越挑刺，正因為如此網絡訂餐業務的出現，正迎合了這些人的口味，她們不但省去了自己做飯的麻煩，而且也能尋找和發現新的菜品，品嘗不同風格的菜品，網絡訂餐業務在中國有著極大的發展空間以及良好的背景。而當代大學生，白領工作人士作為社會中的重要群體，她們對飲食的要求都在不斷提高,飲食在她們生活中起著重要作用。因此，面向大學生和都市白領人士的網絡訂餐網站的設計有著良好的現實意義。1.6總體設計原則開放性、可擴充性、可靠性原則開放系統是生產各種計算機產品普遍遵循的原則，遵循這種標準的產品都符合一些公共的、能夠相互操作的標準，能夠融洽的在一起工作。開放系統使得各種類型的網絡和系統互連簡單、標準統一，容易擴展升級。從而適應廣大用戶需求的多變性和產品的更新換代。良好的用戶操作界面用戶操作界面美觀、方便、實用，使用戶能在較短的時間內掌握其使用方法。3、實用性原則任何系統的設計都要考慮其實用性，系統開發的目的是為了實現業務處理自動化、規范化，提高工作效率，減輕工作人員的勞動強度，減少開支。4、工作平臺設計原則能適應不同的操作平臺，不同的網絡。

第二章概念結構設計階段2.1系統E-R圖經過上面的介紹，我們已近基本的實體有管理員、用戶、訂單和菜譜。實體之間有一個管理員能夠有擁有多個用戶、多個菜譜的管理關系，因此管理員與用戶之間和菜單之間都是一對多的聯系；一個用戶只能屬于管理員，因此用戶與管理員是多對一的聯系；一個訂單只屬于一個用戶，但能夠擁有多個菜譜，因此訂單與菜譜的關系是一對多的聯系。M1M1管理員用戶管理管理生成下單管理員編號名稱用戶編號姓名地址下單時間總金額訂單狀態編號菜名原價菜名的介紹優惠價菜系訂單圖片手機號訂單編號地址密碼登錄IP最后登錄時間注冊時間訂單改變時間會員編號備注創立時間圖2-1網上訂餐系統E-R圖2.2數據流圖圖2-2訂餐系統網上訂餐數據流圖2.3數據字典2.3.1數據項數據項編號數據項名數據項含義說明數據類型長度DI-0用戶編號用戶的唯一標識intDI-1用戶名用戶登陸時的名稱char17DI-2用戶密碼用戶登陸時的密碼char17DI-3用戶姓名用戶的真實姓名char20DI-4用戶性別用戶的性別char2DI-5用戶手機用戶的聯系電話char40DI-6用戶固定電話用戶的聯系電話char40DI-7用戶地址用戶的送貨地址char100DI-8用戶郵箱用戶的個人郵箱char50DI-9用戶年齡用戶的真實年齡intDI-10用戶生日用戶的出生日期dateDI-11餐館編號餐館的唯一標識intDI-12餐館名稱餐館的全稱char50DI-13餐館地址餐館的詳細地址char100DI-14餐館電話餐館的聯系電話char40DI-15餐館聯系人餐館聯系人的姓名char20DI-16菜品編號菜品的唯一標識intDI-17菜名名稱菜品的名稱char40DI-18菜品類別菜品所屬的類別名稱char20DI-19菜品類別編號菜品類別的唯一標識intDI-20菜品價格菜品的單價floatDI-21菜品折扣菜品的折扣率floatDI-22菜品份數菜品的份數intDI-23訂單編號訂單的唯一標識intDI-24訂單日期訂單產生的日期dateDI-25訂單總額訂單所有菜品的總額floatDI-26送餐編號送餐的唯一標識intDI-27送餐地址送餐的詳細地址char100DI-28送餐日期送餐的日期dateDI-29送餐員名稱送餐員的真實姓名char20DI-30送餐員電話送餐員的聯系電話char40DI-31省份編號省份的唯一標識intDI-32省份名稱省份的名稱char20DI-33城市編號城市的唯一標識intDI-34城市名稱城市的名稱char202.3.2數據結構數據結構編號數據結構名含義說明組成DS-1Class菜品分類信息DI-18，DI-19DS-2User用戶信息DI-0至DI-10DS-3Restaurant餐館信息DI-11至DI-15DS-4Meal菜品信息DI-16至DI-22DS-5Order訂單信息DI-23、DI-24、DI-25、DI-27、DI-0DS-6DeliveryNote送餐信息DI-26至DI-30，DI-1、DI-14、DI-152.3.3處理過程處理過程編號處理過程名說明輸入輸出處理P-1注冊所有用戶用戶詳細信息注冊成功信息或失敗信息成功：跳轉到登陸頁面失敗：重新注冊P-2登錄所有用戶用戶名和密碼登陸成功信息或失敗信息成功：跳轉到首頁失敗：重新登陸P-3修改賬號已經登陸的用戶原用戶名、新的用戶名、確認新用戶名、密碼修改成功或失敗信息修改數據庫信息P-4修改密碼已經登陸的用戶原來的密碼、新的密碼、確認新密碼修改成功或失敗信息修改數據庫信息P-5修改常見收貨信息已經登陸的用戶新的收貨地址、新的聯系方式修改數據庫信息P-6添加收獲信息已經登陸的用戶新的收貨信息修改數據庫信息P-7修改用戶信息已經登陸的用戶用戶信息修改數據庫信息P-8添加到購物車所有用戶將用戶所選的菜品添加到購物車P-9修改購物車所有用戶修改購物車信息P-10下訂單已登錄用戶根據購物車和用戶信息自動生成訂單P-11查看并確認訂單已登錄用戶P-12提交訂單已登錄用戶訂餐成功信息修改數據庫信息P-13接收訂單客服人員將訂單信息傳送給相關工作人員P-14信息檢索所有用戶要檢索的內容檢索信息內容P-15發布信息已登錄用戶要發布的信息修改數據庫信息P-16系統維護管理員P-17信息更新管理員需要更新的信息修改數據庫信息P-18用戶投訴與評價已登錄的用戶投訴/評價內容投訴/評價內容修改數據庫信息

第三章數據庫邏輯結構設計階段3.1數據庫邏輯模式初步構思根據ER圖轉換成基本表的思想，即每個實體轉換成基本表，而1對多的聯系根據實際需要能夠轉換或不轉換為基本表，按照圖2-1所示的ER圖，該系統的基本表應為5個，分別為：表3-1管理員表管理員編號姓名密碼登陸IP最后登錄時間主碼表3-2用戶表用戶編號姓名地址手機注冊時間主碼表3-3訂單表訂單編號手機號地址總金額下單時間訂單狀態訂單改變時間備注會員編號主碼外碼表3-4菜譜表編號菜名原價優惠價菜名的介紹圖片創立時間主碼表3-5訂單項表訂單項編號訂單編號姓名狀態主碼3.2具體邏輯模式設計表的具體結構表名字段名字段類型關鍵字約束說明菜譜信息菜譜編號10個字符是菜名20個字符不允許空值原價20個字符優惠價20個字符菜名介紹50個字符圖片創立時間10個字符用戶信息用戶編號10個字符是姓名10個字符地址50個字符手機20個字符注冊時間10個字符管理員信息管理員編號10個字符是姓名10個字符管理員密碼10個字符登錄IP20個字符最后登錄時間10個字符訂單信息訂單編號15個字符是手機號20個字符地址20個字符總金額10個字符下單時間10個字符訂單狀態10個字符訂單改變時間10個字符備注50個字符會員編號10個字符參照用戶信息表的用戶編號，不允許空值訂單項信息訂單項編號10個字符是訂單編號15個字符參照訂單信息表的訂單編號，不允許空值姓名10個字符狀態10個字符

第四章數據庫的物理結構設計4.1設計表間關系在網上訂餐系統中，存在著參照關系和被參照關系。用戶信息表參照關系用戶編號姓名地址手機注冊時間王麗萍山東濟南0910李杜娟江西南昌1231黃大洲廣東佛山0423張子將湖南長沙0814外部關鍵字主關鍵字訂單信息表被參照關系訂單編號用戶編號地址總金額下單時間訂單狀態訂單改變時間手機備注11122301山東濟南28.00122311:23等待付款11122302江西南昌42.00122314:42貨到付款11122303廣東佛山13.00122315:33已付款11122304湖南長沙25.00122317:52貨到付款圖4-1參照關系與被參照關系4.2完整性設計4.2.1主要字段完整性的字段名、完整性約束條件關系模型的完整性約束包括實體完整性、參照完整性和用戶定義完整性。主要字段完整性的字段名、完整性約束條件指的是實體完整性。其中實體完整性的規則如下：實體完整性規則是針對關系而言的，而關系則對應一個現實世界中的實體集。現實世界中的實體是可區分的，它們具有某種標識特征；相應地，關系中的元組也是可區分的，在關系中用主關鍵字作唯一性標識。主關鍵字中的屬性，即主屬性不能取空值。在網上訂餐系統中，管理員表（管理員編號，名稱，密碼，登陸IP，最后登錄時間）中，管理員編號是主關鍵字，不能夠取空值；用戶表（用戶編號，姓名，地址，手機，注冊時間）中，用戶編號是主關鍵字，不能夠取空值；訂單表（訂單編號，手機號，地址，總金額，下單時間，訂單狀態，訂單改變時間，備注，會員編號）中，訂單編號是主關鍵字，不能夠取空值；菜譜表（菜譜編號，菜名，原價，優惠價，菜名的介紹,圖片，創立時間）中，菜譜編號是主關鍵字，不能夠取空值；訂單項表（訂單項編號，訂單編號，姓名，狀態）中，訂單項編號是主關鍵字，不能夠取空值。4.2.2記錄完整性約束及其約束條件除了實體完整性之外還有其它與應用密切相關的數據完整性約束，例如某個屬性的值必須唯一，某個屬性的取值必須在某個范圍內，某些屬性值之間應該滿足一定的函數關系等。類似這些方面的約束不是關系數據模型本身所要求的，而是為了滿足應用方面的語義要求提出來的，這些完整性需求需要用戶來定義，因此稱為用戶定義完整性。數據庫管理系統需提供定義這些數據完整性的功能和手段，以便統一進行處理和檢查，而不是由應用程序去實現這些功能。在用戶定義完整性中最常見的是限定屬性的取值范圍，即對值域的約束，這包括說明屬性的數據類型、精度、取值范圍、是否允許空值等。在網上訂餐系統中，訂單信息表中的訂單編號不允許為空值，用戶表中的用戶編號為唯一值都是用了用戶定義完整性約束。4.2.3參照完整性表用戶編號姓名地址手機注冊時間現實世界中的實體之間存在著某種聯系，而在關系模型中實體是用關系描述的，實體之間的聯系也是用關系描述的，這樣就自然存在著關系和關系之間的參照或引用。網上訂餐系統參照完整性表如下：用戶信息表訂單編號手機號地址總金額下單時間訂單狀態用戶編號n：n訂單項編號訂單編號姓名狀態n:n訂單信息表

訂單項信息表

圖4-2說明關聯和參照關n:n數據庫系統的實現5.1數據庫的建立啟動服務管理器，打開查詢分析器，在調試程序窗口輸入下列語句：Createdatabase網上訂餐系統On（name=網上訂餐系統_dat,Filename='d:\programfiles\lzysql\網上訂餐系統_dat.mdf',Size=5mbMaxsize=100mb,Filegrowth=5mb)Logon(name=網上訂餐系統_log,Filename='d:\programfiles\lzysql\網上訂餐系統_log.ldf',Size=5mbMaxsize=100mb,Filegrowth=5mb)5.2數據載入在網上訂餐系統數據庫中分別新建菜譜信息表、用戶信息表、管理員信息表、訂單信息表、訂單項信息表，再陸續載入數據：菜譜信息表的數據:用戶信息表的數據:管理員信息表的數據訂單信息表的數據：訂單項信息表的數據：

數據庫系統的運行和維護作為網管員，無論其管理的網絡的規模是大還是小，在日常的管理中除了維護網絡平穩運行、及時排除網絡故障、保護網絡安全等工作以外，備份網絡中關鍵數據也是其中的一個非常非常重要的工作環節。網絡中的各種故障無非就分兩種:軟件故障和硬件故障。對于“硬件故障”能夠經過維修或更換硬件設備得到及時解決;對于“軟件故障”則能夠經過重新安裝或升級軟件、重做網絡或應用軟件系統等方法及時解決，而且用此方法來解決網絡故障大多需要一些基礎的、關鍵的數據支持才能得以恢復正常。可是，網絡中諸如此類的關鍵數據(特別是“應用軟件系統”中的關鍵數據)的損壞或丟失，絕大部分是無法恢復和彌補的。6.1定義并設置備份策略：1.

每周1次完全備份，周日晚0點。超過4周清空之前的備份。2.

每天1次差異備份，每天0點。超過1周清空之前的備份。3.

每2小時一次日志備份，超過1天清空之前的備份。6.2啟用維護計劃任務在“管理”－>“數據庫維護計劃”上右鍵彈出菜單，選“新建維護計劃”。如圖6-2-1所示。設置數據庫維護計劃名，并完成向導如圖6-2-2所示。圖6-2-1新建數據庫維護計劃圖6-2-2完成建數據庫維護計劃

報告總結實踐出真知。這句話說得一點也沒錯，在整個數據庫課程設計過程中，只有實踐才能對事物的本質有更深的認識，才能有發言權，一切認識都是建立在認識的基礎上。