Jika ada cara untuk memesan bahan makanan secara online, mengapa tidak menggunakannya? Artikel ini membahas model data di balik sistem pengiriman toko kelontong.
Kami masih mendapatkan perasaan khusus dari memetik sesuatu dari kebun dan kemudian menyiapkannya segera – tetapi itu bukan sesuatu yang sering kami lakukan. Langkah cepat hari ini tidak memungkinkan. Bahkan, terkadang kita tidak diizinkan untuk pergi ke toko untuk “memilih” belanjaan kita. Jadi masuk akal untuk menghemat waktu dan menggunakan aplikasi untuk memesan apa yang kita butuhkan. Pesanan kami hanya akan muncul di rumah kami. Mungkin kita tidak akan mendapatkan perasaan segar yang istimewa itu, tetapi akan ada makanan di meja kita.
Model data di balik aplikasi semacam itu adalah topik artikel hari ini.
Apa yang Kita Butuhkan untuk Model Data Pengiriman Bahan Makanan?
Ide dari model ini adalah bahwa aplikasi (web, mobile, atau keduanya) akan memungkinkan pelanggan terdaftar untuk membuat pesanan (terdiri dari produk dari toko kami). Kemudian pesanan ini akan dikirimkan ke pelanggan. Kami jelas akan menyimpan data pelanggan dan daftar semua produk yang tersedia untuk mendukung ini.
Pelanggan dapat menempatkan beberapa pesanan yang mencakup item yang berbeda dalam jumlah yang berbeda. Ketika pesanan pelanggan diterima, karyawan toko harus diberitahu sehingga mereka dapat menemukan dan mengemas barang-barang yang dibutuhkan. (Ini mungkin memerlukan satu atau lebih kontainer.) Terakhir, kontainer akan dikirim, baik bersama-sama atau terpisah.
Dalam aplikasi itu sendiri, pelanggan dan karyawan harus dapat memasukkan catatan dan menilai pihak lain setelah pengiriman dilakukan.
Model Data
Model data terdiri dari tiga bidang subjek:
Items & unitsCustomers & employeesOrders
Kami akan menampilkan setiap bidang subjek sesuai urutannya.
Bagian 1:Item dan Unit
Kita akan mulai dengan Items & units bidang studi. Meskipun ini adalah bagian kecil dari model kami, ini berisi dua tabel yang sangat penting.
unit tabel menyimpan informasi tentang unit yang akan kami tetapkan untuk item apa pun di inventaris kami. Untuk setiap nilai dalam tabel ini, kami akan menyimpan dua nilai UNIK:unit_name (mis. “kilogram”) dan unit_short (misalnya "kg"). Perhatikan bahwa unit_short adalah singkatan dari unit_name .
Tabel kedua di area subjek ini adalah item . Ini mencantumkan semua item yang kami miliki dalam inventaris. Untuk setiap item, kami akan menyimpan:
item_name– Nama UNIK yang akan kami gunakan untuk item tersebut.price– Harga barang tersebut saat ini.item_photo– Tautan ke foto item ini.description– Deskripsi tekstual tambahan dari item tersebut.unit_id– Merujuk padaunitkamus dan menunjukkan unit yang digunakan untuk mengukur item tersebut.
Harap dicatat bahwa saya telah menghilangkan beberapa hal di sini. Yang paling penting adalah bendera yang menunjukkan jika item inventaris saat ini sedang ditawarkan untuk dijual. Mengapa kita tidak memiliki ini? Ini akan membutuhkan setidaknya satu bidang tambahan (bendera) serta tabel lain (untuk menyimpan perubahan historis untuk setiap item). Untuk mempermudah, saya berasumsi bahwa semua barang yang kami miliki dalam inventaris juga tersedia untuk dijual.
Hal penting kedua yang saya abaikan adalah melacak status gudang. Asumsi saya adalah bahwa kami mengirimkan semuanya dari satu gudang pusat dan kami akan selalu memiliki barang yang tersedia. Jika kami tidak memiliki item, kami hanya akan memberi tahu pelanggan dan menawarkan mereka item serupa sebagai pengganti.
Bagian 2:Pelanggan dan Karyawan
Customers & employees area subjek berisi semua tabel yang diperlukan untuk menyimpan data pelanggan dan karyawan. Kami akan menggunakan informasi ini di bagian tengah model kami.
employee tabel berisi daftar semua karyawan yang relevan (misalnya pengepakan bahan makanan dan petugas pengiriman). Untuk setiap karyawan, kami akan menyimpan first_name mereka dan last_name dan employee_code UNIK nilai. Meskipun kolom id juga UNIK (dan kunci utama tabel ini), lebih baik menggunakan nilai dunia nyata lainnya (misalnya nomor PPN) sebagai pengenal karyawan. Jadi kita memiliki employee_code lapangan.
Perhatikan bahwa saya belum menyertakan detail login karyawan, peran karyawan, dan cara melacak riwayat peran. Ini dapat dengan mudah ditambahkan, seperti yang dijelaskan dalam artikel ini.
Sekarang kami akan menambahkan pelanggan ke model kami. Ini akan membutuhkan dua tabel lagi.
Pelanggan akan disegmentasikan secara geografis, jadi kami memerlukan city kamus. Untuk setiap kota tempat kami menawarkan pengiriman bahan makanan, kami akan menyimpan city_name dan postal_code . Bersama-sama, ini membentuk kunci alternatif dari tabel ini.
Pelanggan jelas merupakan bagian terpenting dari model ini; merekalah yang memulai seluruh proses. Kami akan menyimpan daftar lengkap pelanggan kami di customer meja. Untuk setiap pelanggan, kami akan menyimpan yang berikut ini:
first_name– Nama depan pelanggan.last_name– Nama belakang pelanggan.user_name– Nama pengguna yang dipilih pelanggan saat menyiapkan akun mereka.password– Kata sandi yang dipilih pelanggan saat mengatur akun mereka.time_inserted– Saat ketika catatan ini dimasukkan ke dalam database.confirmation_code– Kode yang dihasilkan selama kode registrasi. Kode ini akan digunakan untuk memverifikasi alamat email mereka.time_confirmed– Saat konfirmasi email terjadi.contact_email– Alamat email pelanggan, yang juga digunakan sebagai email konfirmasi.contact_phone– Nomor telepon pelanggan.city_id– IDcitytempat tinggal pelanggan.address– Alamat rumah pelanggan.delivery_city_id– IDcitytempat pesanan pelanggan harus dikirimkan.delivery_address– Alamat pengiriman yang diinginkan. Perhatikan bahwa ini bisa (tetapi tidak harus) sama dengan alamat rumah pelanggan.
Bagian 3:Pesanan
Bagian utama dan terpenting dari model ini adalah Orders bidang studi. Di sini kami akan menemukan semua tabel yang diperlukan untuk melakukan pemesanan dan melacak item hingga dikirimkan ke pelanggan.
Seluruh proses dimulai ketika pelanggan melakukan pemesanan. Daftar setiap pesanan yang pernah dilakukan ada di placed_order meja. Saya sengaja menggunakan nama ini dan bukan "pesanan" karena pesanan adalah kata kunci yang dicadangkan SQL. Untuk setiap pesanan, kami akan menyimpan:
customer_id– IDcustomeryang memesan ini.time_placed– Stempel waktu saat pesanan ini dilakukan.details– Semua detail yang terkait dengan urutan itu, dalam format tekstual tidak terstruktur.delivery_city_id– Referensi kecitydi mana pesanan ini harus dikirimkan.delivery_address– Alamat tujuan pengiriman pesanan ini.grade_customer&grade_employee– Nilai yang diberikan oleh karyawan dan pelanggan setelah pesanan selesai. Sampai saat itu, atribut ini berisi nilai NULL. Nilai pelanggan menunjukkan betapa senangnya mereka dengan layanan kami; nilai seorang karyawan memberi kami info tentang apa yang diharapkan saat pelanggan melakukan pemesanan berikutnya.
Selama proses menempatkan pesanan, pelanggan akan memilih satu atau lebih item. Untuk setiap item, mereka akan menentukan jumlah yang diinginkan. Daftar semua item yang terkait dengan setiap pesanan disimpan di order_item meja. Untuk setiap catatan dalam tabel ini, kami akan menyimpan ID untuk pesanan terkait (placed_order_id ), barang (item_id ), jumlah yang diinginkan, dan price ketika pesanan ini dilakukan.
Selain apa mereka ingin dikirimkan, pelanggan juga akan menentukan waktu pengiriman yang mereka inginkan . Untuk setiap pesanan, kami akan membuat satu catatan di delivery meja. Ini akan merekam delivery_time_planned dan masukkan catatan tekstual tambahan. placed_order_id atribut juga akan ditentukan ketika catatan ini dimasukkan. Dua atribut yang tersisa akan ditentukan saat kami menetapkan pengiriman itu ke karyawan (employee_id ) dan kapan pesanan dikirim (delivery_time_actual ).
Meskipun sepertinya kami hanya memiliki satu pengiriman per pesanan, itu mungkin tidak selalu terjadi. Kami mungkin perlu melakukan dua atau lebih pengiriman per pesanan, dan itulah alasan utama saya memilih untuk menempatkan data pengiriman di tabel baru.
Saat kami mulai memproses pesanan, karyawan akan mengemas barang dalam satu kotak atau lebih. Setiap box akan didefinisikan secara UNIK oleh box_code its dan akan ditugaskan ke pengiriman (delivery_id ). Kami juga akan menyimpan ID karyawan yang menyiapkan kotak itu.
Setiap kotak akan berisi satu atau lebih item. Oleh karena itu, di item_in_box tabel, kita perlu menyimpan referensi ke box tabel (box_id ) dan item tabel (item_id ), serta jumlah yang ditempatkan di kotak itu. Atribut terakhir, is_replacement , menunjukkan jika suatu barang merupakan pengganti barang lain. Kita dapat mengharapkan bahwa seorang karyawan akan menghubungi pelanggan sebelum memasukkan barang pengganti ke dalam kotak. Salah satu hasil dari tindakan itu adalah pelanggan setuju dengan barang pengganti; lain bisa menjadi pembatalan seluruh pesanan.
Tiga tabel yang tersisa dalam model terkait erat dengan status dan komentar.
Pertama, kami akan menyimpan semua kemungkinan status di status_catalog . Setiap status secara UNIK ditentukan oleh status_name its . Kami dapat mengharapkan status seperti "pesanan dibuat", "pesanan ditempatkan", "barang dikemas", "dalam perjalanan" dan "terkirim".
Status akan diberikan ke pesanan baik secara otomatis (setelah beberapa bagian dari proses selesai) atau, dalam beberapa kasus, secara manual (misalnya jika ada masalah dengan pesanan). Semua status pesanan yang tersedia disimpan di order_status meja. Selain kunci asing dari dua tabel (status_catalog dan placed_order ), kami akan menyimpan stempel waktu aktual saat status ini ditetapkan (status_time ) dan details tambahan lainnya dalam format tekstual.
Tabel terakhir dalam model ini adalah notes meja. Ide di balik tabel ini adalah untuk memasukkan semua komentar tambahan yang terkait dengan pesanan yang diberikan (placed_order_id ). Komentar dapat disisipkan oleh karyawan atau pelanggan. Untuk setiap record, hanya satu dari employee_id atau customer_id bidang akan berisi nilai; yang lain akan NULL. Kami akan menyimpan momen saat catatan ini dimasukkan ke dalam sistem (note_time ) dan note_text .
Perubahan Apa yang Akan Anda Buat pada Model Data Pengiriman Bahan Makanan?
Hari ini kita membahas model data yang dapat mendukung aplikasi pengiriman bahan makanan web dan seluler – baik dari perspektif pelanggan maupun karyawan. Seperti yang telah disebutkan dalam artikel ini, ada banyak cara untuk meningkatkan model ini. Jangan ragu untuk menambahkan saran Anda. Beri tahu kami apa yang akan Anda tambahkan ke model ini atau hapus darinya. Atau mungkin Anda akan mengatur struktur ini sama sekali berbeda. Beri tahu kami di bagian komentar!
