Model Data Pengiriman Restoran

Lapar tapi gak mau masak? Menelepon restoran, memesan makanan favorit Anda, dan membaca tentang model data yang dapat mengatur seluruh proses.

Meskipun banyak teknologi “penghemat waktu”, kita tampaknya memiliki lebih sedikit waktu untuk memenuhi kebutuhan dasar – seperti makan. Jika kita ingin makan sesuatu tetapi kita tidak punya waktu (atau keterampilan) untuk memasaknya sendiri, kita dapat memesan makanan dari restoran (yaitu takeaway atau takeout), yang akan membawa makanan kita langsung ke rumah kita. Tentu saja, kita harus membayar untuk kenyamanan ini, jadi kita berharap makanannya enak dan panas!

Jelas, setiap restoran termotivasi untuk menjaga kepuasan pelanggannya. Anda mungkin terkejut mengetahui berapa banyak pekerjaan yang harus dilakukan untuk menjalankan takeaway. Sebagian besar menggunakan beberapa jenis sistem pelacakan untuk mengelola pesanan dan pengiriman. Mari kita lihat model data di bawah salah satu sistem tersebut. Ambil camilan sendiri, duduk, dan nikmati artikelnya.

Apa yang Harus Kita Ketahui Tentang Bisnis Restoran?

Membuat makanan dan mengantarkannya ke pelanggan bukanlah hal yang mudah. Pertama-tama, Anda perlu memiliki bakat dan pengetahuan untuk menyiapkan makanan lezat. Anda juga perlu diatur:semuanya harus berfungsi sempurna jika makanan ini akan dikirimkan tepat waktu dan ke tempat yang tepat!

Sebelum kita mulai mengantarkan makanan, kita perlu tahu:

Siapa yang memesan makanan
Di mana dan kapan makanan harus diantar
Hidangan apa yang termasuk dalam pesanan
Bahan apa yang kita butuhkan untuk memenuhi pesanan
Jika pesanan sudah dibayar

Kami juga perlu melacak status pengiriman dan mencatat umpan balik pelanggan tentang makanan mereka dan/atau proses pengiriman kami. Plus, mungkin kita ingin tahu makanan mana yang paling (atau paling tidak) populer. Dan kita juga harus menyimpan beberapa informasi keuangan untuk tujuan pelaporan dan analisis.

Mari kita asumsikan bahwa kita memiliki aplikasi yang dapat digunakan pelanggan kita untuk melakukan pemesanan pengiriman. Ini memungkinkan mereka untuk memilih item menu, membayarnya, dan menentukan waktu dan alamat pengiriman. Seperti apa model data di bawah aplikasi semacam itu?

Model Data

Anda dapat membuka model ini di browser Anda dengan mengklik Edit model in your browser tombol.

Model data terdiri dari tiga bidang subjek:

Restaurants & customers
Menus
Orders

Kami akan menampilkan setiap bidang subjek sesuai urutannya.

Restoran dan Pelanggan

Restaurants & customers area subjek berisi tiga tabel yang menyimpan detail tentang restoran kami (bisa lebih dari satu), kota tempat kami beroperasi, dan pelanggan kami.

Baik pelanggan dan restoran berlokasi di kota (atau kota kecil, desa, dll). Oleh karena itu, kami membutuhkan city kamus. Ini hanya berisi dua atribut, city_name dan zip_code . Jika kami beroperasi di lebih dari satu negara, kami juga memerlukan kamus negara yang terkait dengan tabel ini, tetapi kami tidak akan membahasnya di sini.

Selanjutnya, kami memerlukan daftar semua restoran yang kami operasikan. Kami akan menggunakan restaurant meja untuk itu. Untuk mempermudah, kami hanya akan menyimpan address setiap restoran dan referensi ke city di mana lokasinya.

Tabel terakhir di bidang subjek ini adalah customer meja. Di sinilah kami akan menyimpan daftar semua pelanggan pengiriman terdaftar kami. Kami akan menggunakan data dari tabel ini untuk menautkan pelanggan ke pesanan mereka nanti dalam model. Tentu saja, pelanggan tidak harus terdaftar di model kami untuk memesan, tetapi kami masih membutuhkan daftar ini. Kami dapat menawarkan diskon kepada pelanggan terdaftar sebagai program loyalitas. Atau mungkin kami akan menggunakan data ini untuk menghubungi pelanggan dengan penawaran khusus. Untuk setiap pelanggan terdaftar, kami akan menyimpan:

customer_name – Nama lengkap pelanggan.
city_id – Merujuk city tempat tinggal pelanggan.
address – Alamat pelanggan.
contact_phone – Nomor telepon pelanggan.
email – Alamat email yang digunakan pelanggan selama proses pendaftaran.
confirmation_code – Kode konfirmasi yang digunakan selama proses pendaftaran.
password – Kata sandi yang dipilih oleh pelanggan untuk aplikasi ini.
time_joined – Stempel waktu saat pelanggan bergabung dengan aplikasi kami.

item_name – Nama untuk item tersebut, mis. “sandwich ayam”.
category_id – Merujuk pada category milik barang tersebut, mis. “sandwich”.
description - Deskripsi barang itu. Ini harus sama dengan menu yang dicetak.
ingredients – Bahan-bahan yang digunakan untuk memproduksi barang itu dan jumlahnya. Kolom ini sebenarnya bisa menyimpan resep.
price – Harga saat ini untuk satu item (misalnya satu sandwich ayam).
active – Jika item ditawarkan pada menu saat ini.

Jika kita ingin menyimpan menu dalam berbagai bahasa, kita harus menggunakan pendekatan seperti yang disajikan dalam artikel ini.

Sebagian besar restoran memiliki penawaran khusus dengan waktu terbatas. Mereka mungkin juga memiliki beberapa penawaran untuk waktu yang tidak terbatas. Kami akan menggunakan offer meja untuk ini. Untuk masing-masing, kita akan memiliki:

date_active_from dan date_active_to – Bersama-sama, ini menentukan kapan penawaran ini aktif. Jika penawaran memiliki durasi tidak terbatas atau jika didasarkan pada jam daripada hari, kedua atribut ini akan berisi nilai NULL. Contoh dari jenis penawaran ini adalah “Selama bulan Maret, beli satu kari dan dapatkan diskon 50%”.
time_active_from dan time_active_to – Menentukan waktu validitas penawaran – mis. “Dapatkan kopi gratis dari pukul 6-9 pagi setiap hari”.
offer_price – Harga untuk penawaran itu.

Semua item menu yang disertakan dalam penawaran disimpan di in_offer meja. Tabel ini berisi pasangan UNIK dari offer_id – menu_item_id .

Jika restoran kami memiliki menu yang berbeda, kami perlu membuat menu terpisah untuk setiap restoran. Kami kemudian perlu menghubungkan menu dan penawaran dengan restoran menggunakan kunci asing. Ini akan memungkinkan kami untuk mengubah menu dan penawaran untuk restoran mana pun tanpa memengaruhi yang lain. Ini tidak hanya akan memperumit database; model bisnis juga akan menjadi lebih kompleks. Inilah sebabnya mengapa sebagian besar rantai restoran hanya menggunakan satu menu dan mengapa saya memutuskan untuk tidak menggunakan metode ini dalam model ini.

Pesanan

Area subjek terakhir dalam model kami adalah Orders bidang studi. Di sinilah kami memiliki semua yang diperlukan untuk menyimpan pesanan dan statusnya.

Tabel pusat di sini adalah placed_order meja. Sebaiknya jangan hanya menggunakan "pesanan" sebagai nama tabel ini:"pesanan" adalah kata kunci SQL. Cobalah untuk menghindari penggunaan kata kunci sebagai nama untuk tabel dan kolom; jika tidak, Anda mungkin mendapatkan kesalahan saat menulis kueri. Untuk setiap pesanan, kami akan mencatat:

restaurant_id – ID restaurant terkait dengan pesanan itu.
order_time – Stempel waktu saat pemesanan dilakukan.
estimated_delivery_time – Stempel waktu pengiriman yang direncanakan untuk pesanan ini.
food_ready – Stempel waktu yang menunjukkan kapan item pesanan disiapkan. Ini akan berisi nilai NULL sampai makanan disiapkan. Kita dapat menggunakan atribut ini untuk menghitung perbedaan waktu antara saat pemesanan dilakukan dan saat makanan disiapkan. Kami juga dapat menggunakannya untuk mengetahui berapa lama waktu yang berlalu antara saat makanan siap dan saat diantar. Informasi ini dapat sangat membantu dalam hal meningkatkan efisiensi staf.
actual_delivery_time – Stempel waktu kapan pesanan ini benar-benar dikirim. Ini akan menjadi NULL sampai makanan dikirim ke pelanggan.
delivery_address – Alamat tujuan pengiriman pesanan.
customer_id – ID customer yang memesan itu. Atribut ini dapat berisi nilai NULL jika pesanan dilakukan oleh seseorang yang bukan pengguna aplikasi terdaftar.
price – Harga untuk semua item yang termasuk dalam pesanan tersebut.
discount – Jumlah diskon (misalnya kupon atau diskon loyalitas) yang diterapkan pada harga, jika ada.
final_price – Harga pesanan dikurangi diskon.
comment – Komentar tambahan disisipkan oleh pelanggan saat melakukan pemesanan. Ini bisa berupa petunjuk pengiriman tambahan atau hal lain yang dianggap penting oleh pelanggan.
ts – Stempel waktu saat catatan ini dimasukkan ke dalam tabel.

in_order tabel mencantumkan semua item atau penawaran khusus yang termasuk dalam pesanan. Untuk setiap record dalam tabel ini, kita akan menyimpan:

placed_order_id – ID dari order .
offer_id – Merujuk pada offer tabel, tetapi hanya jika satu atau lebih penawaran disertakan dalam pesanan ini. Dalam hal ini, menu_item_id atribut akan menjadi NULL.
menu_item_id – Referensi menu_item tabel, tetapi hanya jika catatan ini terkait dengan item menu dan bukan penawaran.
quantity – Berapa banyak penawaran atau item menu yang termasuk dalam pesanan ini.
item_price – Harga satu penawaran atau item menu.
price – Harga total untuk baris ini, dinyatakan sebagai item_price * quantity .
comment – Setiap komentar yang dimasukkan oleh pelanggan yang berhubungan secara khusus dengan item pesanan tersebut, mis. “Tolong potong pizza menjadi 8 bagian”.

comment tabel memungkinkan kami mendukung penyisipan beberapa komentar yang terkait dengan pesanan. Untuk setiap komentar, kami akan menyimpan ID pesanan terkait dan ID pelanggan. Kami juga akan menyimpan stempel waktu saat komentar ini dimasukkan. Kami juga akan menandai apakah komentar ini merupakan keluhan atau pujian; hanya satu dari keduanya yang dapat disetel pada satu waktu. Jika tidak ada yang disetel, komentar ini akan kami anggap netral.

Dua tabel terakhir dalam model kami terkait dengan status yang akan kami tetapkan untuk pesanan. status_catalog tabel berisi daftar semua kemungkinan status_name UNIK atribut yang bisa kita tetapkan untuk pesanan. order_status tabel berisi semua status yang ditetapkan untuk pesanan. Untuk setiap record dalam tabel ini, kami akan menyimpan kunci asing yang terkait dengan pesanan dan status serta stempel waktu saat status ini ditetapkan.

Bagaimana Pendapat Anda Tentang Model Data Pengiriman Restoran?

Hari ini kita telah membahas model data yang dapat digunakan untuk mengatur, mengelola, dan menyimpan pesanan pengiriman restoran. Kami dapat melacak status setiap pesanan dan beberapa detail keuangan. Saya punya beberapa ide tentang bagaimana kita bisa membuat model ini lebih kuat, tapi saya akan senang mendengar pendapat Anda. Silakan bagikan di bagian komentar!