Database
 sql >> Cơ Sở Dữ Liệu >  >> RDS >> Database

Mô hình dữ liệu giao hàng tại nhà hàng

Đói nhưng bạn không muốn nấu ăn? Gọi một nhà hàng, đặt bữa ăn yêu thích của bạn và đọc về mô hình dữ liệu có thể tổ chức toàn bộ quá trình.

Mặc dù có vô số công nghệ “tiết kiệm thời gian”, chúng ta dường như có ít thời gian hơn để thực hiện các nhu cầu cơ bản - chẳng hạn như ăn uống. Nếu chúng ta muốn ăn một thứ gì đó nhưng chúng ta không có thời gian (hoặc kỹ năng) để tự nấu, chúng ta có thể đặt đồ ăn từ một nhà hàng (tức là mang đi hoặc mang về), nơi sẽ mang bữa ăn của chúng ta đến tận nhà. Tất nhiên, chúng tôi phải trả tiền cho sự tiện lợi này, vì vậy chúng tôi mong muốn đồ ăn phải ngon và nóng hổi!

Rõ ràng, bất kỳ nhà hàng nào cũng có động cơ để giữ cho khách hàng hài lòng. Bạn có thể ngạc nhiên khi biết rằng có bao nhiêu công việc được thực hiện một cách nhanh chóng. Hầu hết sử dụng một số loại hệ thống theo dõi để quản lý đơn đặt hàng và giao hàng. Hãy xem mô hình dữ liệu bên dưới một hệ thống như vậy. Lấy cho mình một món ăn nhẹ, ngồi lại và thưởng thức bài viết.

Chúng ta nên biết gì về kinh doanh nhà hàng?

Làm món ăn và giao cho khách hàng không hề đơn giản. Trước hết, bạn cần có năng khiếu và kiến ​​thức để chuẩn bị những bữa ăn ngon. Bạn cũng cần có tổ chức:mọi thứ cần hoạt động hoàn hảo nếu những bữa ăn này được giao đúng giờ và đúng nơi!

Trước khi bắt đầu giao bất kỳ bữa ăn nào, chúng tôi cần biết:

  • Ai đã đặt bữa ăn
  • Bữa ăn sẽ được giao ở đâu và khi nào
  • Những món ăn nào được bao gồm trong đơn đặt hàng
  • Chúng tôi cần những thành phần nào để hoàn thành đơn đặt hàng
  • Nếu đơn đặt hàng đã được thanh toán cho

Chúng tôi cũng cần theo dõi tình trạng giao hàng và ghi lại phản hồi của khách hàng về bữa ăn của họ và / hoặc quy trình giao hàng của chúng tôi. Thêm vào đó, có thể chúng ta muốn biết bữa ăn nào là phổ biến nhất (hoặc ít nhất). Và chúng ta cũng nên giữ một số thông tin tài chính cho mục đích báo cáo và phân tích.

Giả sử rằng chúng tôi có một ứng dụng mà khách hàng của chúng tôi có thể sử dụng để đặt hàng để giao hàng. Nó cho phép họ chọn các món trong thực đơn, thanh toán cho chúng và chỉ định thời gian và địa chỉ giao hàng. Mô hình dữ liệu bên dưới một ứng dụng như vậy có thể trông như thế nào?

Mô hình dữ liệu




Bạn có thể mở mô hình này trong trình duyệt của mình bằng cách nhấp vào Edit model in your browser cái nút.

Mô hình dữ liệu bao gồm ba lĩnh vực chủ đề:

  • Restaurants & customers
  • Menus
  • Orders

Chúng tôi sẽ trình bày từng lĩnh vực chủ đề theo thứ tự được liệt kê.

Nhà hàng và Khách hàng

Restaurants & customers vùng chủ đề chứa ba bảng lưu trữ thông tin chi tiết về nhà hàng của chúng tôi (có thể có nhiều hơn một), thành phố nơi chúng tôi hoạt động và khách hàng của chúng tôi.

Cả khách hàng và nhà hàng đều nằm ở thành phố (hoặc thị trấn, làng mạc, v.v.). Do đó, chúng tôi cần một city từ điển. Nó chỉ chứa hai thuộc tính, city_namezip_code . Nếu chúng tôi hoạt động ở nhiều quốc gia, chúng tôi cũng sẽ cần một từ điển quốc gia có liên quan đến bảng này, nhưng chúng tôi sẽ không đi sâu vào vấn đề đó ở đây.

Tiếp theo, chúng tôi cần một danh sách tất cả các nhà hàng mà chúng tôi hoạt động. Chúng tôi sẽ sử dụng restaurant bảng cho điều đó. Để đơn giản hóa mọi thứ, chúng tôi sẽ chỉ lưu trữ address của mỗi nhà hàng và tham chiếu đến city nó nằm ở đâu.

Bảng cuối cùng trong chủ đề này là customer bàn. Đây là nơi chúng tôi sẽ lưu trữ danh sách tất cả các khách hàng giao hàng đã đăng ký của chúng tôi. Chúng tôi sẽ sử dụng dữ liệu từ bảng này để liên kết khách hàng với đơn đặt hàng của họ sau này trong mô hình. Tất nhiên, khách hàng không cần phải đăng ký mô hình của chúng tôi để đặt hàng, nhưng chúng tôi vẫn cần danh sách này. Chúng tôi có thể giảm giá cho khách hàng đã đăng ký như một chương trình khách hàng thân thiết. Hoặc có lẽ chúng tôi sẽ sử dụng dữ liệu này để liên hệ với khách hàng với các ưu đãi đặc biệt. Đối với mỗi khách hàng đã đăng ký, chúng tôi sẽ lưu trữ:

  • customer_name - Tên đầy đủ của khách hàng.
  • city_id - Tham khảo city nơi khách hàng sống.
  • address - Địa chỉ của khách hàng.
  • contact_phone - Số điện thoại của khách hàng.
  • email - Địa chỉ email mà khách hàng đã sử dụng trong quá trình đăng ký.
  • confirmation_code - Mã xác nhận được sử dụng trong quá trình đăng ký.
  • password - Mật khẩu do khách hàng chọn cho ứng dụng này.
  • time_joined - Dấu thời gian về thời điểm khách hàng tham gia ứng dụng của chúng tôi.

Thực đơn

Chủ đề này chứa thông tin về thực đơn của các nhà hàng của chúng tôi. Bây giờ, giả sử rằng tất cả các nhà hàng của chúng ta đều sử dụng cùng một thực đơn.

Bảng đầu tiên là category từ điển. Nó chỉ chứa một thuộc tính DUY NHẤT, category_name . Trường này có thể sẽ chứa các danh mục menu thông thường, chẳng hạn như “đồ uống”, “món khai vị”, “salad”, “bánh mì”, “pizza”, v.v.

Tiếp theo, chúng tôi có menu_item bàn. Nó liệt kê tất cả các mục chúng tôi có (hoặc đã có) trên bất kỳ menu nào của chúng tôi. Đối với mỗi mặt hàng, chúng tôi sẽ lưu trữ:

  • item_name - Tên cho mục đó, ví dụ:"Bánh mì gà".
  • category_id - Tham khảo category mà mục đó thuộc về, ví dụ:"Bánh mì".
  • description - Mô tả về mặt hàng đó. Điều này phải giống như trên menu in.
  • ingredients - Các thành phần được sử dụng để sản xuất mặt hàng đó và số lượng của chúng. Trường này thực sự có thể lưu trữ một công thức.
  • price - Giá hiện tại cho một mặt hàng (ví dụ:một bánh mì gà).
  • active - Nếu món được cung cấp trên menu hiện tại.

Nếu chúng ta muốn lưu trữ menu bằng nhiều ngôn ngữ, chúng ta nên sử dụng cách tiếp cận như cách được trình bày trong bài viết này.

Hầu hết các nhà hàng đều có ưu đãi đặc biệt, có giới hạn thời gian. Họ cũng có thể có một số ưu đãi trong khoảng thời gian không giới hạn. Chúng tôi sẽ sử dụng offer bảng cho những. Đối với mỗi cái, chúng tôi sẽ có:

  • date_active_fromdate_active_to - Cùng với nhau, chúng xác định thời điểm ưu đãi này có hiệu lực. Nếu ưu đãi có thời hạn không giới hạn hoặc nếu ưu đãi dựa trên giờ thay vì ngày, thì hai thuộc tính này sẽ chứa giá trị NULL. Ví dụ về loại ưu đãi này là "Trong tháng 3, mua một suất cà ri và được giảm giá 50%".
  • time_active_fromtime_active_to - Xác định thời gian trong ngày một phiếu mua hàng có hiệu lực - ví dụ:“Nhận một ly cà phê miễn phí từ 6-9 giờ sáng mỗi ngày”.
  • offer_price - Giá cho ưu đãi đó.

Tất cả các mục menu có trong phiếu mua hàng được lưu trữ trong in_offer bàn. Bảng này chứa cặp offer_id DUY NHẤT - menu_item_id .

Nếu nhà hàng của chúng ta có nhiều menu khác nhau, chúng ta cần tạo menu riêng cho từng nhà hàng. Sau đó, chúng tôi cần liên hệ thực đơn và ưu đãi với các nhà hàng bằng cách sử dụng khóa ngoại. Điều này sẽ cho phép chúng tôi thay đổi thực đơn và ưu đãi cho bất kỳ nhà hàng nào mà không ảnh hưởng đến những nhà hàng khác. Điều này sẽ không chỉ làm phức tạp cơ sở dữ liệu; mô hình kinh doanh cũng sẽ phức tạp hơn. Đây là lý do tại sao hầu hết các chuỗi nhà hàng chỉ sử dụng một thực đơn và tại sao tôi quyết định không sử dụng phương pháp này trong mô hình này.

Đơn hàng

Chủ đề cuối cùng trong mô hình của chúng tôi là Orders môn học. Đây là nơi chúng tôi sẽ có mọi thứ cần thiết để lưu trữ các đơn đặt hàng và trạng thái của chúng.

Bảng trung tâm ở đây là placed_order bàn. Tốt nhất là không nên chỉ sử dụng “order” làm tên của bảng này:“order” là một từ khóa SQL. Cố gắng tránh sử dụng từ khóa làm tên cho bảng và cột; nếu không, bạn có thể gặp lỗi khi viết truy vấn. Đối với mỗi đơn đặt hàng, chúng tôi sẽ ghi lại:

  • restaurant_id - ID của restaurant liên quan đến đơn đặt hàng đó.
  • order_time - Dấu thời gian về thời điểm đặt hàng.
  • estimated_delivery_time - Dấu thời gian về việc giao hàng theo kế hoạch của đơn đặt hàng này.
  • food_ready - Dấu thời gian biểu thị thời điểm các mặt hàng đặt hàng đã được chuẩn bị. Giá trị này sẽ chứa giá trị NULL cho đến khi thức ăn được chuẩn bị. Chúng tôi có thể sử dụng thuộc tính này để tính toán chênh lệch thời gian giữa thời điểm đặt hàng và thời điểm đồ ăn được chuẩn bị. Chúng tôi cũng có thể sử dụng nó để tìm khoảng thời gian đã trôi qua giữa thời điểm thực phẩm đã sẵn sàng và khi nó được giao. Thông tin này có thể rất hữu ích trong việc tăng hiệu quả của nhân viên.
  • actual_delivery_time - Dấu thời gian về thời điểm đơn hàng này thực sự được giao. Nó sẽ KHÔNG ĐỦ cho đến khi đồ ăn được giao cho khách hàng.
  • delivery_address - Địa chỉ nơi đơn đặt hàng sẽ được giao.
  • customer_id - ID của customer ai đã đặt hàng đó. Thuộc tính này có thể chứa giá trị NULL nếu đơn đặt hàng được đặt bởi một người không phải là người dùng ứng dụng đã đăng ký.
  • price - Giá cho tất cả các mặt hàng có trong đơn đặt hàng đó.
  • discount - Số tiền chiết khấu (ví dụ:phiếu giảm giá hoặc chiết khấu dành cho khách hàng thân thiết) được áp dụng cho giá, nếu có.
  • final_price - Giá đặt hàng trừ chiết khấu.
  • comment - Nhận xét bổ sung của khách hàng khi đặt hàng. Đây có thể là hướng dẫn giao hàng bổ sung hoặc bất kỳ thứ gì khác mà khách hàng thấy quan trọng.
  • ts - Dấu thời gian về thời điểm bản ghi này được chèn vào bảng.

in_order bảng liệt kê tất cả các mặt hàng hoặc ưu đãi đặc biệt có trong một đơn đặt hàng. Đối với mỗi bản ghi trong bảng này, chúng tôi sẽ lưu trữ:

  • placed_order_id - ID của order .
  • offer_id - Tham khảo offer nhưng chỉ khi một hoặc nhiều ưu đãi được bao gồm trong đơn đặt hàng này. Trong trường hợp đó, menu_item_id thuộc tính NULL.
  • menu_item_id - Tham khảo menu_item nhưng chỉ khi bản ghi này liên quan đến một món trong thực đơn chứ không phải một phiếu mua hàng.
  • quantity - Có bao nhiêu ưu đãi hoặc các món trong thực đơn trong đơn đặt hàng này.
  • item_price - Giá của một ưu đãi hoặc một món trong thực đơn.
  • price - Tổng giá cho dòng này, được biểu thị bằng item_price * quantity .
  • comment - Bất kỳ nhận xét nào được khách hàng chèn vào có liên quan cụ thể đến mặt hàng đặt hàng đó, ví dụ:“Hãy cắt bánh pizza thành 8 lát”.

comment bảng cho phép chúng tôi hỗ trợ chèn nhiều bình luận liên quan đến đơn đặt hàng. Đối với mỗi nhận xét, chúng tôi sẽ lưu trữ ID của đơn đặt hàng có liên quan và ID của khách hàng. Chúng tôi cũng sẽ lưu trữ dấu thời gian về thời điểm nhận xét này được nhập. Chúng tôi cũng sẽ đánh dấu xem nhận xét này là một lời phàn nàn hay một lời khen ngợi; chỉ có thể đặt một trong hai cái này cùng một lúc. Nếu không có gì được đặt, thì chúng tôi sẽ coi nhận xét này là trung lập.

Hai bảng cuối cùng trong mô hình của chúng tôi có liên quan đến các trạng thái mà chúng tôi sẽ gán cho các đơn đặt hàng. status_catalog bảng chứa danh sách tất cả status_name DUY NHẤT có thể có các thuộc tính mà chúng tôi có thể gán cho các đơn đặt hàng. order_status bảng chứa tất cả các trạng thái được chỉ định cho các đơn đặt hàng. Đối với mỗi bản ghi trong bảng này, chúng tôi sẽ lưu trữ các khóa ngoại liên quan đến thứ tự và trạng thái cũng như dấu thời gian khi trạng thái này được chỉ định.

Bạn nghĩ gì về Mô hình dữ liệu giao hàng tại nhà hàng?

Hôm nay chúng ta đã thảo luận về một mô hình dữ liệu có thể được sử dụng để tổ chức, quản lý và lưu trữ các đơn đặt hàng giao nhà hàng. Chúng tôi có thể theo dõi trạng thái của từng đơn đặt hàng và một số chi tiết tài chính. Tôi có một vài ý tưởng về cách chúng tôi có thể làm cho mô hình này mạnh mẽ hơn, nhưng tôi rất vui khi nghe ý kiến ​​của bạn. Hãy chia sẻ nó trong phần bình luận!


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. SQL Cheat Sheet:SQL, SQL Commands và SQL Injection là gì

  2. DBMS là gì? - Hướng dẫn Toàn diện về Hệ thống Quản lý Cơ sở dữ liệu

  3. Cách kết nối cơ sở dữ liệu với Amazon VPC

  4. Mô hình Cơ sở dữ liệu cho Hệ thống Đặt chỗ của Trường Lái xe. Phần 2

  5. Cách thực thi SQL thô trong SQLAlchemy