Đề tài Thiết kế và xây dựng website Mimes Restaurant

workspace với cấu trúc thư mục đầy đủ. Mặc định khối lệnh MXML hiển thị trong vùng làm việc như hình II-2-5. Trang: 15  Hình II-2-5: Cửa sổ Main Flex Builder • Sửa lại đoạn code MXML lại như sau: • Chọn Run trên menu bar để chạy chương trình. N hấn OK để lưu lại những thay đổi. Kết quả thưc thi chương trình như hình II-2-6. Trang: 16  Hình II-2-6: Kết quả thực thi ứng dụng web HelloWord 3. Vai trò của MXML: • MXML trong ứng dụng Flex cũng tương tự như XHTML trong các trang web thông thường. Cả hai ngôn ngữ markup này đều đảm nhận vai trò làm giao diện người dùng. Bởi vì MXML là biến thể của XML nên cấu trúc của chúng cũng tương tự nhau. Một tài liệu MXML phải đúng dạng (well-formed) của tài liệu XML như sau: ™ Tài liệu MXML phải chứa một hoặc nhiều nút. ™ Tài liệu MXML phải chứa một nút gốc, thường là thẻ . ™ Đóng mở thẻ hợp lệ ™ Thẻ lồng nhau phải hợp lệ ™ Giá trị của Attribute phải nằm trong dấu nháy đơn (‘) hoặc nháy kép (“). • Tất cả tài liệu MXML phải bắt đầu với khai báo XML như sau: • N út gốc của tài liệu MXML thường là thẻ , mặc dù chúng ta có thể dùng những thẻ khác như , ,…. Thẻ gốc đóng vai trò là một Container chứa tất cả các thành phần khác. Trang: 17  • Thẻ gốc được tham chiếu tới namespace www.adobe.com/2006/mxml. Bạn có thể thấy nó xuất hiện như sau: • Chúng có thể đưa vào thêm những custom component, ví dụ như: . Trong trường hợp này chúng ta dùng tiền tố (prefix) là comp để phân biệt với các component có sẵn của Flex. • Đoạn mã lệnh sau là ví dụ đơn giản xây dựng giao diện Flex bằng MXML: Giao diện chỉ là một nút nhấn được tạo bằng thẻ . Gán thuộc tính (properties) cho đối tượng bằng cách dùng thuộc tính (attributes) bên trong thẻ. Lúc biên dịch ứng dụng, thì những thẻ MXML sẽ được dịch ra những class ActionScript tương ứng, trong trường hợp này là tạo button trong file SWF. • Tất cả các thẻ và tên lớp đều bắt đầu bằng ký tự in hoa, và nếu như tên có nhiều hơn một từ thì ký tự đầu tiên của mỗi từ phải viết hoa (vd: ComboBox). • N hư đã đề cập, những thành phần MXML được biên dịch để tạo ra file SWF. Trong quá trình này, những thẻ MXML được phân tích (parse) và được trình biên dịch sinh ra những class ActionScript khi cần thiết. Sau đó những lớp này được compile vào file SWF ở dạng mã nhị phân (bytecode). 4. ActionScript 3.0: • ActionScript 3.0 là phiên bản mới nhất của ngôn ngữ script này và nó là trái tim của Flex framework. Trang: 18  • ActionScript 3.0 chạy trên máy ảo AVM (ActionScript Vitual Machine) bên trong Flash Player 9. Không giống như những phiên bản trước đây, Flash Player 9 bao gồm cả 2 AVM, một cho ActionScript 3.0 (AVM2) và một cho các phiên bản trước đây (AVM1). ActionScript 3.0 thực thi nhanh hơn các phiên bản trước. Flex 3 chỉ làm việc với ActionScript 3.0. • ActionScript 3.0 bao gồm 2 phần chính: phần lõi của ngôn ngữ (core language) và Flash Player API. Phần lõi bao gồm những thành phần cơ bản của ngôn ngữ như kiểu dữ liệu (data type), biểu thức (expression), vòng lặp (loop), và điều kiện (condition). Flash Player API là những lớp tiện ích hỗ trợ lập trình viên viết mã dễ dàng và nhanh chóng hơn. • Chúng ta có thể dùng ActionScript 3.0 trong ứng dụng Flex bằng nhiều cách: ™ Thêm những câu lệnh ActionScript vào ngay trong những thẻ MXML ™ Thêm vào một khối lệnh bằng thẻ trong file MXML ™ Dùng file ActionScript bên ngoài bằng cách chỉ định source cho thẻ hoặc include file trong khối lệnh ActionScript. • Đoạn mã sau đây dùng ActionScript 3.0 để tạo ra giao diện giống như giao diện đã tạo bằng những thẻ MXML ở trên: Trang: 19  • Đoạn mã ActionScript trên đã được bao trong khối CDATA để báo cho trình biên dịch không phân tích (parse) nội dung của nó. N ếu không có khối CDATA thì trình biên dịch sẽ phân tích những lệnh ActionScript như là thành phần XML, như vậy sẽ không đúng dạng (well-form). • Một metadata tag rất thường dùng đó là [Bindable] với vị trí đặt như sau: Chúng ta có thể gán giá trị của nó trực tiếp cho widget (các đối tượng cơ sở) bằng cách: Kiểu gán này được dùng bởi vì khi giá trị biến thay đổi thì giá trị của nó sẽ được tự động cập nhật cho widget. 5. Thành phần xử lý trong ASP.NET: (Giới thiệu mô hình lập trình 3 lớp (3 layers)) Trong phát triển ứng dụng, để dễ quản lý các thành phần của hệ thống, cũng như không bị ảnh hưởng bởi các thay đổi, người ta hay nhóm các thành phần có cùng chức năng lại với nhau và phân chia trách nhiệm cho từng nhóm để công việc không bị chồng chéo và ảnh hưởng lẫn nhau. Ví dụ trong một công ty có từng phòng ban, mỗi phòng ban sẽ chịu trách nhiệm một công việc cụ thể nào đó, phòng này không được can thiệp vào công việc nội bộ của phòng kia như Phòng tài chính thì chỉ phát lương, còn chuyện lấy tiền ở đâu phát cho nhân viên phòng Marketing thì không cần biết. Trong phát triển phần mềm, người ta cũng áp dụng cách phân chia chức năng này. Chúng ta nghe nói đến thuật ngữ kiến trúc đa tầng/nhiều lớp, mỗi lớp sẽ thực hiện một chức năng nào đó, trong đó mô hình 3 lớp là phổ biến nhất. 3 lớp này là gì? Là Presentation, Business Logic, và Data Access. Các lớp này sẽ giao tiếp với nhau thông qua các dịch vụ(services) mà mỗi lớp cung cấp để tạo nên ứng dụng, lớp này cũng Trang: 20  không cần biết bên trong lớp kia làm gì mà chỉ cần biết lớp kia cung cấp dịch vụ gì cho mình và sử dụng nó mà thôi. Hình II-5: Mô hình 3 lớp (Three_tier) [17] 5.1. Tầng thể hiện (Presentation layer): Lớp này làm nhiệm vụ giao tiếp với người dùng cuối để thu thập dữ liệu và hiển thị kết quả/dữ liệu thông qua các thành phần trong giao diện người sử dụng. Lớp này sẽ sử dụng các dịch vụ do lớp Business Logic cung cấp. Trong .N ET thì Trang: 21  dùng Windows Forms, ASP.N ET hay Mobile Forms để hiện thực lớp này. Trong luận văn này dùng Flex làm lớp Presentation. Trong lớp này có 2 thành phần chính là User Interface Components và User Interface Process Components. UI Components là những phần tử chịu trách nhiệm thu thập và hiển thị thông tin cho người dùng cuối. N hững thành phần này có thể là các TextBox, các Button, DataGrid... UI Process Components: là thành phần chịu trách nhiệm quản lý các qui trình chuyển đổi giữa các UI Components. Ví dụ chịu trách nhiệm quản lý các màn hình nhập dữ liệu trong một loạt các thao tác định trước như các bước trong một Wizard... Lưu ý : lớp này không nên sử dụng trực tiếp các dịch vụ của lớp Data Access mà nên sử dụng thông qua các dịch vụ của lớp Business Logic vì khi sử dụng trực tiếp như vậy, có thể bỏ qua các ràng buộc, các logic nghiệp vụ mà ứng dụng cần phải có. 5.2. Tầng xử lý ngiệp vụ (Business Logic layer): Lớp này thực hiện các nghiệp vụ chính của hệ thống, sử dụng các dịch vụ do lớp Data Access cung cấp, và cung cấp các dịch vụ cho lớp Presentation. Lớp này cũng có thể sử dụng các dịch vụ của các nhà cung cấp thứ 3 (3rd parties) để thực hiện công việc của mình(ví dụ như sử dụng dịch vụ của các cổng thanh tóan trực tuyến như VeriSign, Paypal...).Trong lớp này có các thành phần chính là Business Components, Business Entities và Service Interface. Service Interface là giao diện lập trình mà lớp này cung cấp cho lớp Presentation sử dụng. Lớp Presentation chỉ cần biết các dịch vụ thông qua giao Trang: 22  diện này mà không cần phải quan tâm đến bên trong lớp này được hiện thực như thế nào. Business Entities là những thực thể mô tả những đối tượng thông tin mà hệ thống xử lý. Ví dụ trong ứng dụng này có đối tượng là tài khoản (Accounts). Các business entities này cũng được dùng để trao đổi thông tin giữa lớp Presentation và lớp Data Access. Business Components là những thành phần chính thực hiện các dịch vụ mà Service Interface cung cấp, chịu trách nhiệm kiểm tra các ràng buộc logic (constraints), các qui tắc nghiệp vụ (business rules), sử dụng các dịch vụ bên ngoài khác để thực hiện các yêu cầu của ứng dụng. Trong ứng dụng Mimes Restaurant, lớp này sẽ chứa các thành phần là Accounts, Items,… làm nhiệm vụ cung cấp các dịch vụ quản lý tài khoản và các món ăn,…. (thêm, xóa, sửa, xem chi tiết,...). 5.3. Tầng tương tác cơ sở dữ liệu (Data Access layer): Lớp này thực hiện các nghiệp vụ liên quan đến lưu trữ và truy xuất dữ liệu của ứng dụng. Thường lớp này sẽ sử dụng các dịch vụ của các hệ quản trị cơ sở dữ liệu như SQL Server, Oracle,... để thực hiện nhiệm vụ của mình. Trong lớp này có các thành phần chính là Data Access Logic, Data Sources, Servive Agents. Data Access Logic Components (DALC) là thành phần chính chịu trách nhiệm lưu trữ vào và truy xuất dữ liệu từ các nguồn dữ liệu như RDBMS, XML, File systems.... Trong .N ET Các DALC này thường được hiện thực bằng cách sử dụng thư viện ADO.N ET để giao tiếp với các hệ cơ sở dữ liệu hoặc sử dụng các O/R Mapping Frameworks để thực hiện việc ánh xạ các đối tượng trong bộ nhớ thành dữ liệu lưu trữ trong CSDL. Service Agents là những thành phần trợ giúp việc truy xuất các dịch vụ bên ngòai một cách dễ dàng và đơn giản như truy xuất các dịch vụ nội tại. 5.4. Cách hiện thực kiến trúc 3 lớp: Trang: 23  • Lớp Presentation: ™ Do dùng Flex cho lớp này nên muốn ASP.N ET bắt được dữ liệu của giao diện ta phải dùng cơ chế Request . Sau khi xử lý thì trả kết quả về cho Flex bằng cơ chế Response. Ta làm như sau: ™ Flex: //nhận dữ liệu private var params:Object = new Object(); [Bindable] private var login_result:String=null; public function resultHandler(event:ResultEvent):void { login_result = event.result.toString(); if(login_result=="ok") { //các xử lý khi đăng nhập thành công…. ……… } else Alert.show("Sai tên đăng nhập hoặc mật khNu!"); } // gửi dữ liệu public function check():void Trang: 24  { checkUser.removeEventListener(ResultEvent.RESULT,resultHandler); checkUser.addEventListener(ResultEvent.RESULT,resultHandler); checkUser.method = "POST"; params = {"task":"checkLogin","username":txtUsername.text,"password":txtPassword.text}; checkUser.cancel(); checkUser.send(params); } ™ ASP.N ET: string task = Request.Form["task"].ToString(); if (task.Equals("checkLogin")) { string username = Request.Form["username"].ToString(); string password = Request.Form["password"].ToString(); Business.Account a = new Business.Account(); a.Username = username; a.Password = password; a.Role = 0; if (a.checkLogin()) { Response.Write("ok"); } Trang: 25  else Response.Write("login fail"); } • Lớp Business Logic: // mã hóa mật khNu bằng thuật toán MD5 (business component) private string hashPass(String s) { return System.Web.Security.FormsAuthentication.HashPasswordForStoringInConfigFile (s,"MD5"); } /// hàm cung cấp cho Presentation gọi (business interface) public bool checkLogin() { DataAccess.Account a=new DataAccess.Account(); if (a.checkLogin(this.Username,this.hashPass(this.Password),this.Role)) { return true; } return false; } //// getter / setter (business entity) private string username; Trang: 26  private string password; public string Username { set { this.username = value; } get { return this.username; } } public string Password { set { this.password = value; } get { return this.password; } } private int role; public int Role { set { this.role = value; } get { return this.role; } } • Lớp Data Access: // cung cấp phương thức cho lớp Business gọi, có nhiệm vụ tương tác với cơ sở dữ liệu vật lý public bool checkLogin(String username, String password, int role) { try Trang: 27  { SqlConnection cn = ConnectionInfo.Connection(); string s = "select * from Users where UserID=N '" + username + "' and Password=N '" + password + "' and Role='" + role + "'and Banned=0"; SqlCommand cm = new SqlCommand(s, cn); cn.Open(); if (cm.ExecuteScalar() != null) { cn.Close(); return true; } } catch (SqlException) { return false; } return false; } 6. SQL Server 2000 & Bảo mật thông tin: 6.1. Thuật toán MD5: MD để chỉ cho “message digest” (Lấy 2 chữ đầu). MD5 là một thuật tóan lấy một tín hiệu vào có chiều dài bất kỳ và đưa ra một tín hiệu digest có chiều dài cố định (128-bit, 32 ký tự hexa), được làm ra từ 1 giá trị hexa (chú ý : mỗi ký tự Trang: 28  hex là 4 bit, do đó 128bit là 32 ký tự hex). N ói rõ hơn một chút : MD5 là cách căn bản để lấy chùm ký tự ( là digits, alphabeic hay gì khác ), được gọi là string nhập vào, và thay đổi chúng thành một chùm ký tự dài 32 ký tự , được gọi là tín hiệu digest (message digest) hay hashes của chuỗi được nhập vào, chuỗi 32 ký tự này được tạo ra từ các ký tự hexa ( những digits: 0-9 và các chữ a-f). Điều này có nghĩa là, với một chuỗi nhập vào có chiều dài bất kỳ , MD5 sẽ luôn luôn cài đặt “một vài thứ” để thành một chuổi string dài 32 ký tự, mà các ký tự là các ký tự hexa. Tín hiệu digest sẽ không có khỏang trống, hay dấu hoặc kép hay bất cứ thứ gì khác 0-9 và a-f trong tín hiệu hashes được xuất ra. MD5 hashes có tiện dụng là những hashes tạo ra trông khác nhau hòan tòan từ những tín hiệu nhập vào hơi hơi giống nhau. Ví dụ sau sẽ làm rõ hơn về điều này: • Kết quả MD5 hash của chuỗi jim là 5e027396789a18c37aeda616e3d7991b • Kết quả MD5 hash của chuỗi Jim là d54b3c8fcd5ba07e47b400e69a287966 • Kết quả MD5 hash của chuỗi Jimmy là 495b3121d23f5988b133882b36aa7214 N hư đã thấy, có ba tín hiệu nhập vào “hơi hơi giống nhau” nhưng các tín hiệu MD5 hashes xuất ra hòan tòan khác nhau. Ví dụ này cũng chứng minh hai ký tự j và J là 2 ký tự khác nhau. Ở đây cần chú ý thêm là trong ví dụ thứ 3 chỉ thêm vào 2 ký tự (my) ở cuối chuỗi của ví dụ 2 , và hashes của nó đã thay đổi hòan tòan. Vì vậy chúng ta không thể có hashes của chuỗi “Blehlo” từ hashes của chuỗi “Bleh” bằng cách “vá viếu” thêm vài ký tự - thay đổi trong chuỗi nhập vào thì tín hiệu hashes của nó cũng sẽ thay đổi hòan tòan. Và ở đây cũng nên chú ý với 3 chuỗi nhập vào có chiều dài không giống nhau nhưng các hash sinh ra đều có chiều dài là 32 ký tự (bao gồm các số 0-9 và a-f), ở ví dụ sau cùng ta cũng thấy chuỗi nhập vào dài hơn 2 ký tự so với 2 string trước nhưng chuỗi hash của nó cũng chỉ có 32 ký tự chữ số hex. Trang: 29  Điều quan trọng là chúng ta không thể dịch ngược chuỗi MD5 đã hash về lại chuỗi ban đầu được. Em sẽ ứng dụng điều này để mã hóa mật khNu khi đăng nhập vào hệ thống.  6.2. Stored Procedure: Stored Procedure có một số ưu điểm chính như sau: Performance (hiệu năng) : Khi thực thi một câu lệnh SQL thì SQL Server phải kiểm tra quyền (permission) xem user gởi câu lệnh đó có được phép thực hiện câu lệnh hay không đồng thời kiểm tra cú pháp rồi mới tạo ra một execute plan và thực thi. N ếu có nhiều câu lệnh như vậy gởi qua mạng có thể làm giảm đi tốc độ làm việc của server. SQL Server sẽ làm việc hiệu quả hơn nếu dùng stored procedure vì người gởi chỉ gởi một câu lệnh đơn và SQL Server chỉ kiểm tra một lần sau đó tạo ra một execute plan và thực thi. N ếu stored procedure được gọi nhiều lần thì execute plan có thể được sử dụng lại nên sẽ làm việc nhanh hơn. N goài ra cú pháp của các câu lệnh SQL đã được SQL Sever kiểm tra trước khi lưu nên nó không cần kiểm lại khi thực thi. Reuse (tái sử dụng) : Một khi stored procedure được tạo ra nó có thể được sử dụng lại. Ðiều này sẽ làm cho việc bảo trì (maintainability) dễ dàng hơn do việc tách rời giữa business rules (tức là những logic thể hiện bên trong stored procedure) và database. Ví dụ nếu có một sự thay đổi nào đó về mặt logic thì ta chỉ việc thay đổi mã lệnh bên trong stored procedure mà thôi. N hững ứng dụng dùng stored procedure này có thể sẽ không cần phải thay đổi mà vẫn tương thích với business rule mới. Cũng giống như các ngôn ngữ lập trình khác stored procedure cho phép ta đưa vào các input parameters (tham số) và trả về các output parameters đồng thời nó cũng có khả năng gọi các stored procedure khác. Trang: 30  Security (bảo mật) : Giả sử chúng ta muốn giới hạn việc truy xuất dữ liệu trực tiếp của một user nào đó vào một số bảng, ta có thể viết một stored procedure để truy xuất dữ liệu và chỉ cho phép user đó được sử dụng stored procedure đã viết sẵn mà thôi chứ không thể "đụng" đến các bảng đó một cách trực tiếp. N goài ra stored procedure có thể được mã hóa (encrypt) để tăng cường tính bảo mật. Ðể tạo ra một stored procedure ta dùng lệnh CREATE PROCEDURE theo sau là tên của nó. N ếu muốn encrypt thì dùng WITH EN CRYPTION trước chữ AS và các tham số nhập vào(input) hoặc tham số trả về (output). N ếu là output thì thêm keyword OUTPUT đằng sau tham số. Ta có thể cho giá trị mặc định (default) cùng lúc với khai báo kiểu dữ liệu của tham số. Kể từ sau chữ AS là phần thân của stored procedure. Trang: 31  CHƯƠNG 3: Giải Quyết Bài Toán 1. Mô hình hệ thống: 1.1. Mô hình chức năng dành cho người dùng: Hình III-1-1: Mô hình chức năng dành cho người dùng Trang: 32  Mô hình chức năng dành cho Quản trị và Duyệt đơn hàng: Hình III-1-2: Mô hình chức năng dành cho quản trị & người duyệt đơn hàng Trang: 33  1.2. Mô hình thự thể kết hợp - Entities Relation Diagram (ERD): Hình III-1-3: Mô hình thực thể kết hợp Trang: 34  1.3. Mô hình quan hệ - Relationship Diagram: Hình III-1-4: Mô hình quan hệ giữa các bảng Trang: 35  1.4. Cấu trúc các bảng: 1.4..1. Bảng Slideshow (giới thiệu): Tên cột Kiểu dữ liệu Cho phép rỗng Mô tả Ghi chú SlideID Int Không Tự tăng +1 Khóa chính Image_ID N varchar (50) Không Tham chiếu từ bảng Images Khóa ngoại Priority Int Có Thứ tự xuất hiện của ảnh 1: là xuất hiện đầu tiên 1.4..2. Bảng Images (hình ảnh): Tên cột Kiểu dữ liệu Cho phép rỗng Mô tả Ghi chú Image_ID N varchar (50) Không Tên đại diện Khóa chính Path N varchar (50) Có Tên thật của ảnh 1.4..3. Bảng Events (sự kiện): Tên cột Kiểu dữ liệu Cho phép rỗng Mô tả Ghi chú Event_ID Int Không Tự tăng +1 Khóa chính Intro N varchar (500) Không Mô tả ngắn gọn sự kiện Detail N varchar (1000) Không Mô tả đầy đủ sự kiện Image_ID N varchar(50) Không Tham chiếu từ bảng Image Khóa ngoại Date_from Varchar(50) Không N gày bắt đầu Date_to Varchar(50) Không N gày kết thúc HomePage int Có Cho phép hiện lên trang chủ 1: hiện 0: Nn Trang: 36  1.4..4. Bảng MainMenu (thực đơn): Tên cột Kiểu dữ liệu Cho phép rỗng Mô tả Ghi chú MainMenu_ID Int Không Tự tăng +1 Khóa chính N ame N varchar (50) Không Tên thực đơn Priority Int Có Thứ tự xuất hiện của thực đơn 1: là xuất hiện đầu tiên 1.4..5. Bảng SubMenu (thực đơn con): Tên cột Kiểu dữ liệu Cho phép rỗng Mô tả Ghi chú SubMenu_ID Int Không Tự tăng +1 Khóa chính N ame N varchar (50) Không Tên thực đơn Priority Int Có Thứ tự xuất hiện của thực đơn con 1: là xuất hiện đầu tiên MainMenu_ID Int Không Tham chiếu từ bảng MainMenu Khóa ngoại 1.4..6. Bảng Users (tài khoản): Tên cột Kiểu dữ liệu Cho phép rỗng Mô tả Ghi chú UserID N varchar (50) Không Tên đăng nhập Khóa chính Password N varchar (50) Không Mật khNu Role Int Không Quyền người dùng trên trang web 0: khách hàng 1: quản trị 2: duyệt đơn hàng Email N varchar (50) Có Địa chỉ email Fullname N varchar (50) Không Tên họ đầy đủ Address N varchar (50) Có Địa chỉ Phone varchar (20) Có Điện thoại Trang: 37  CellPhone varchar (20) Có Di động Sex N varchar (50) Có Giới tính Banned Int Có Khóa tài khoản 0: bình thường 1: khóa 1.4..7. Bảng Feedback (phản hồi): Tên cột Kiểu dữ liệu Cho phép rỗng Mô tả Ghi chú Fb_ID Int Không Tự tăng +1 Khóa chính Present N varchar (10) Có Cách trình bày Serve N varchar (10) Có Thái độ phục vụ Price N varchar (10) Có Giá tốt chưa Delicious N varchar (10) Có Món ăn ngon không SpaceIn N varchar (10) Có Không gian nhà hàng Month varchar (10) Có Tháng Year varchar (10) Có N ăm 1.4..8. Bảng Items (món ăn): Tên cột Kiểu dữ liệu Cho phép rỗng Mô tả Ghi chú Item_ID Int Không Tự tăng +1 Khóa chính Item_name N varchar (50) Không Tê món Recipe N varchar (1000) Có Thành phần Image_ID N varchar (50) Không Tham chiếu từ bảng Images Khóa ngoại Item_usage N varchar (2000) Có Công dụng, cách dùng SubMenu_ID Int Không Tham chiếu từ bảng Khóa ngoại Trang: 38  SubMenu Price varchar (30) Có Giá Origin N varchar (50) Có Vùng HomePage Int Có Hiện lên trang chủ 1: hiện 0: Nn Invisible Int Có Ẩn món 0: hiện 1: Nn 1.4..9. Bảng BookDetail (chi tiết đơn hàng): Tên cột Kiểu dữ liệu Cho phép rỗng Mô tả Ghi chú BookDetail_ID Int Không Tự tăng +1 Khóa chính BookID Int Không Tham chiếu từ bảng Booked Khóa ngoại Item_ID Int Không Tham chiếu từ bảng Items Khóa ngoại Quantity_Item Int Không Số lượng mỗi món 1.4..10. Bảng Booked (đặt hàng): Tên cột Kiểu dữ liệu Cho phép rỗng Mô tả Ghi chú BookID Int Không Tự tăng +1 Khóa chính UserID N varchar (50) Không Tham chiếu từ bảng Users Book_time varchar (30) Không Giờ khách đến Book_date Datetime Không N gày khách đến Pax int Không Số lượng khách Trang: 39  N ote N varchar (1000) Có Ghi chú Guest_name N varchar (50) Có Tên khách đến Guest_phone N varchar (50) Có Điện thoại khách đến Guest_Email N varchar (50) Có Di động khách đến 1: hiện 0: Nn Status_View varchar (50) Có Trạng thái đơn hàng N ew: chưa duyệt Accepted: đồng ý Waitting: chờ xử lý Deny: không chấp nhận Trang: 40  2. Cấu trúc chương trình: 2.1. Người dùng: 2.1..1. Đăng nhập: Hình III-2-1-1: Sơ đồ xử lý người dùng đăng nhập Trang: 41  2.1..2. Sửa thông tin tài khoản: Hình III-2-1-2: Sơ đồ xử lý người dùng chỉnh sửa thông tin tài khoản Trang: 42  2.1..3. Đổi mật khNu: Hình III-2-1-3: Sơ đồ xử lý người dùng đổi mật khNu 2.1..4. Quên mật khNu: Hình III-2-1-4: Sơ đồ xử lý người dùng lấy lại mật khNu Trang: 43  2.1..5. Xem giới thiệu: Hình III-2-1-5: Sơ đồ xử lý người dùng xem giới thiệu 2.1..6. Xem trang chủ: Hình III-2-1-6: Sơ đồ xử lý người dùng xem trang chủ Trang: 44  2.1..7. Xem món ăn: Hình III-2-1-7: Sơ đồ xử lý người dùng xem thực đơn Trang: 45  2.1..8. Đặt hàng: Hình III-2-1-8: Sơ đồ xử lý người dùng đặt món ăn 2.1..9. Xem sự kiện: Hình III-2-1-9: Sơ đồ xử lý người dùng xem sự kiện Trang: 46  2.1..10. Gửi phản hồi: Hình III-2-1-10: Sơ đồ xử lý người dùng gửi phản hồi Trang: 47  2.2. Quản trị & người duyệt đơn hàng: 2.2..1. Đăng nhập: Hình III-2-2-1: Sơ đồ xử lý Admin/Reviewer đăng nhập Trang: 48  2.2..2. Quản lý SlideShow (giới thiệu): • Xem: Hình III-2-2-2-1: Sơ đồ xử lý admin xem giới thiệu • Thêm: Hình III-2-2-2-2: Sơ đồ xử lý admin thêm giới thiệu Trang: 49  • Xóa: Hình III-2-2-2-3: Sơ đồ xử lý admin xóa giới thiệu • Sửa: Hình III-2-2-2-4: Sơ đồ xử lý admin sửa giới thiệu Trang: 50  2.2..3. Quản lý Accounts (tài khoản): • Ban (khóa tài khoản): Hình III-2-2-3-1: Sơ đồ xử lý admin khóa tài khoản • Grant (cấp quyền duyệt đơn hàng): Hình III-2-2-3-2: Sơ đồ xử lý admin cấp quyền Trang: 51  • ChangePass (đổi mật khNu): Hình III-2-2-3-3: Sơ đồ xử lý Admin/Reviewer đổi mật khNu 2.2..4. Quản lý Events (sự kiện): • Xem: Hình III-2-2-4-1: Sơ đồ xử lý admin xem sự kiện Trang: 52  • Thêm: Hình III-2-2-4-2: Sơ đồ xử lý admin thêm sự kiện • Xóa: Hình III-2-2-4-3: Sơ đồ xử lý admin xóa sự kiện Trang: 53  • Sửa: Hình III-2-2-4-4: Sơ đồ xử lý admin sửa sự kiện Trang: 54  2.2..5. Quản lý Menu (thực đơn): • Xem: Hình III-2-2-5-1: Sơ đồ xử lý admin xem thực đơn • Thêm: Hình III-2-2-5-2: Sơ đồ xử lý admin thêm thực đơn Trang: 55  • Xóa: Hình III-2-2-5-3: Sơ đồ xử lý admin xóa thực đơn • Sửa: Hình III-2-2-5-4: Sơ đồ xử lý admin sửa thực đơn Trang: 56  2.2..6. Quản lý Submenu (thực đơn con): • Xem: Hình III-2-2-6-1: Sơ đồ xử lý admin xem thực đơn con • Thêm: Hình III-2-2-6-2: Sơ đồ xử lý admin thêm thực đơn con Trang: 57  • Xóa: Hình III-2-2-6-3: Sơ đồ xử lý admin xóa thực đơn con • Sửa: Hình III-2-2-6-4: Sơ đồ xử lý admin sửa thực đơn con Trang: 58  2.2..7. Quản lý Items (món ăn): • Xem: Hình III-2-2-7-1: Sơ đồ xử lý admin xem món ăn • Thêm: Hình III-2-2-7-2: Sơ đồ xử lý admin thêm món ăn Trang: 59  • Xóa: Hình III-2-2-7-3: Sơ đồ xử lý admin xóa món ăn • Sửa: Hình III-2-2-7-4: Sơ đồ xử lý admin sửa món ăn Trang: 60  2.2..8. Quản lý Feedback (xem phản hồi): Hình III-2-2-8: Sơ đồ xử lý admin xem thông tin phản hồi Trang: 61  2.2..9. Quản lý Book (duyệt đơn hàng): Hình III-2-2-9: Sơ đồ xử lý reviewer xử lý đơn hàng 2.2..10. Quản lý Images (hình ảnh): • Xem: Hình III-2-2-10-1: Sơ đồ xử lý admin xem hình ảnh Trang: 62  • Thêm: Hình III-2-2-10-2: Sơ đồ xử lý admin thêm hình ảnh • Xóa: Hình III-2-2-10-3: Sơ đồ xử lý admin xóa hình ảnh Trang: 63  • Sửa: Hình III-2-2-10-4: Sơ