Model Data Pesta Anak-anak

Menyelenggarakan pesta anak-anak bukanlah pekerjaan mudah:semuanya harus direncanakan dan dilaksanakan dengan sempurna. Jika tidak, kekacauan terjadi. Terserah orang dewasa – lebih khusus lagi, perencana pesta – untuk mengurus semuanya dan melakukannya dengan benar.

Apakah ada cara yang lebih baik untuk melakukan ini daripada mengatur semuanya dalam database? Kami rasa tidak!

Pesta anak-anak sangat bervariasi. Ada yang sederhana, seperti pesta ulang tahun yang hanya berisi undangan, makanan (snack, minuman, dan kue) dan mungkin badut atau pesulap untuk menghibur anak-anak. Partai lain jauh lebih kompleks. Mereka mungkin memerlukan perjalanan ke luar kota, akomodasi tidur, dan banyak kegiatan lainnya. Semakin rumit pestanya, semakin sedikit ruang untuk kesalahan. Meskipun badut yang terlambat 10 menit bukanlah masalah besar, tidak ada yang mau menunggu dengan sekelompok anak-anak yang bosan untuk bus yang terlambat dua jam!

Mari kita lihat apa yang dapat dilakukan model data untuk membantu perencana pesta tetap teratur.

Apa yang Kita Butuhkan dalam Model Data Kita?

Mari kita asumsikan kita menjalankan bisnis perencanaan pesta. Kami akan memiliki daftar layanan yang kami tawarkan kepada pelanggan. Layanan ini dapat disediakan oleh kami, atau kami dapat menggunakan mitra (misalnya, kami menyewa badut).

Kami menggabungkan layanan ini dan menawarkannya kepada pelanggan sebagai paket pesta. Setiap paket memiliki titik awal dan akhir, atau jadwal. Ini tidak hanya mencakup pesta itu sendiri, tetapi juga menyiapkan pesta dan membersihkannya sesudahnya. Kami mungkin juga memiliki beberapa lokasi (mis. pesta dimulai dengan pizza di restoran, lalu pindah ke pantai untuk berenang).

Kami juga perlu menghubungkan aktivitas dengan karyawan, melacak kemajuan pesta, dan membebankan biaya untuk layanan kami. Mari kita lihat bagaimana ini dilakukan.

Model Data Pesta Anak-anak

Model data pesta anak-anak kami terdiri dari empat bidang subjek:

Countries & cities
Partners & services
Employees & roles
Party

Kami akan menampilkan setiap bidang subjek dalam urutan yang sama dengan yang tercantum.

Bagian 1:Negara dan Kota

Area subjek ini hanya berisi dua tabel. Mereka tidak spesifik untuk model ini, tetapi kami akan menggunakannya di bidang subjek lain.

Kami dapat berharap untuk beroperasi di banyak kota dan bahkan mungkin di beberapa negara. Oleh karena itu, kita perlu merujuk ke berbagai kota. Ini akan membantu kami melacak lokasi pesta dan juga layanan apa yang kami tawarkan di setiap lokasi.

country kamus hanya berisi country_name UNIK nilai. Untuk setiap city , kami akan menyimpan kombinasi UNIK dari postal_code – city_name – country_id .

Bagian 2:Mitra dan Layanan

Selanjutnya, mari kita perinci layanan yang akan kami berikan untuk klien kami.

Daftar semua layanan yang mungkin disimpan di service kamus. Ini hanya berisi service_name UNIK atribut.

Dalam model data ini, semua layanan disediakan oleh mitra. Meskipun perusahaan kami benar-benar menyediakan layanan, kami akan memperlakukannya sebagai partner layanan (dan kami adalah mitra). Kamus mitra akan menyimpan semua mitra yang bekerja sama dengan kami, termasuk kami. Untuk setiap mitra, kami akan menyimpan partner_name yang UNIK . details atribut menyimpan detail tambahan apa pun yang terkait dengan mitra tersebut menggunakan format tidak terstruktur atau terstruktur (misalnya, menggunakan pasangan nama-nilai yang dipisahkan oleh pemisah yang telah ditentukan sebelumnya).

provides tabel adalah tabel terakhir dan paling penting di bagian ini. Untuk setiap catatan, kami akan menyimpan:

partner_id – partner yang menyediakan layanan.
service_id – service mitra ini menyediakan.
city_id – Merujuk city tempat layanan ini disediakan oleh mitra tersebut.
date_from – Tanggal saat mitra mulai menawarkan layanan tersebut.
date_to – Tanggal saat mitra berhenti menawarkan layanan itu. Nilai ini bisa menjadi NULL jika hubungan mitra layanan tersebut masih berlangsung.
details – Semua detail tambahan yang terkait dengan layanan tersebut, seperti deskripsi layanan, harga, dll. Kami dapat mengharapkan semua detail dalam format tekstual terstruktur, menggunakan pasangan nilai kunci.

Kombinasi partner_id – service_id – city_id – date_from membentuk kunci UNIK dalam tabel ini. Saat kita memasukkan record baru, kita harus memeriksa bahwa record tersebut tidak tumpang tindih dengan record yang ada.

Bagian 3:Karyawan dan Peran

Sebelum kita beralih ke bagian utama dan terpenting dari model kita, kita perlu melihat tabel yang terkait dengan karyawan kita dan peran mereka.

Tabel pusat di area subjek ini adalah employee meja. Untuk setiap karyawan, kami akan menyimpan first_name mereka , last_name , user_name dan password . Mereka akan menggunakan dua atribut terakhir ini untuk mengakses aplikasi kita.

Daftar semua kemungkinan peran disimpan di role kamus. Setiap peran secara UNIK ditentukan oleh role_name its . Peran terkait dengan tindakan yang dilakukan setiap karyawan selama pesta. Oleh karena itu, kita dapat mengharapkan nilai seperti "manajer pesta" atau "asisten" di sini.

Peran dapat diberikan kepada karyawan melalui has_role meja. employee_id – role_id pair akan menunjukkan peran aktif yang dimiliki setiap karyawan pada saat itu.

Bagian 4:Pesta

Party area subjek adalah bagian utama dari model ini. Kami akan menggunakannya untuk menghubungkan tabel dari bidang subjek lain, dan kami juga akan memiliki beberapa informasi baru di sini.

Tabel pusat di sini adalah party meja. Untuk setiap pesta, kami akan menyimpan:

city_id – city di mana pesta akan berlangsung.
client_id – client pesta ini diselenggarakan.
details – Deskripsi tekstual rinci tentang pesta.
start_time_planned dan end_time_planned – Waktu yang kami jadwalkan untuk pesta ini, termasuk penyiapan dan pembersihan.
start_time_actual dan end_time_actual – Waktu aktual pesta (dan layanan terkaitnya) berlangsung.
price_offered – Harga yang kami kutip untuk mengatur pesta ini untuk klien ini.
time_offered – Saat penawaran dibuat.
price_paid – Jumlah aktual yang dibayarkan klien untuk pesta ini.
time_paid – Saat pembayaran dilakukan.

Setiap pihak terkait dengan klien. Kami telah mereferensikan client tabel, tapi sekarang kita akan melihat apa yang disimpan di sana. Saya hanya menggunakan data dasar:client_name , detail kontak (address , email , phone , mobile ), dan detail tambahan apa pun dalam format tekstual.

Setiap pihak juga akan memiliki daftar layanan yang terkait dengannya. Daftar itu disimpan di service_included meja. Untuk setiap record, kita membutuhkan:

party_id – Referensi party .
service_id – Merujuk service termasuk dalam pesta.
provides_id – Referensi provider layanan itu, serta layanan itu sendiri. Atribut ini dapat berupa NULL, karena kami akan memperbaruinya saat kami memilih penyedia tertentu.
details – Detail tekstual tambahan apa pun yang terkait dengan layanan tersebut di pihak tersebut.
start_time_planned dan end_time_planned – Waktu yang direncanakan untuk menyediakan layanan selama pesta.

Kami juga perlu melacak kemajuan masing-masing pihak. Kami akan menggunakan dua tabel untuk melakukan ini.

status tabel akan mencantumkan semua kemungkinan status yang dapat ditetapkan ke pesta. Untuk setiap catatan, kami akan menyimpan status_name UNIK dan tiga bendera:

successful - Apakah semuanya berjalan dengan baik? Atau ada masalah dengan layanan kami?
paid – Apakah pestanya sudah dibayar?
final – Apakah ini status terakhir untuk pesta ini?

Kami akan menetapkan status ke layanan dengan menambahkan catatan baru ke party_status meja. Untuk setiap catatan, kami akan menyimpan referensi ke party dan service tabel dan timestamp saat status ini ditetapkan.

Tabel terakhir dalam model kami adalah invoice meja. Ini tidak spesifik untuk model ini, tetapi kami membutuhkan struktur dasar untuk menyimpan faktur. Untuk setiap faktur, kami akan mencatat:

client_name – Nama klien pada saat faktur diterbitkan.
party_id – Party terkait dengan faktur ini.
client_id – ID client sedang ditagih.
invoice_amount , discount , vat_amount , total_amount – Detail keuangan faktur.
time_issued - Saat faktur ini diterbitkan atau ditambahkan ke database.
time_paid - Saat faktur ini dibayar.

Apa yang Akan Anda Lakukan dengan Model Data ini?

Model ini cukup sederhana, tetapi saya melihat beberapa cara untuk memperbaikinya. Perubahan apa yang akan Anda usulkan? Apakah ada sesuatu yang bisa kita atur secara berbeda? Mungkin kita perlu menambah atau menghapus fitur. Tolong beritahu kami di komentar.