Pernikahan sering disertai dengan kegembiraan dan perayaan, dengan banyak tamu, makanan, minuman, musik, dan tarian. Namun semua ini tidak dapat terjadi tanpa persiapan dan koordinasi yang baik. Mari kita lihat lebih dekat bagaimana pemodelan data dapat membantu kita mengatur pernikahan dengan lebih baik sehingga semuanya berjalan lancar.
Latar Belakang Awal
Meskipun sebagian besar kita semua mengetahui seperti apa upacara pernikahan pada umumnya, tidak ada salahnya untuk mempertimbangkan secara singkat beberapa aspek yang berpotensi memengaruhi model data kita.
Mitra pernikahan
Meskipun sebagian besar budaya tradisional akan mengadakan upacara antara pria dan wanita, pernikahan sesama jenis juga terjadi di masyarakat lain. Model data kami harus dirancang sedemikian rupa sehingga mengakomodasi semua kemungkinan.
Skala dan kompleksitas
Upacara pernikahan sangat bervariasi dalam ukuran, durasi, dan kerumitannya. Beberapa adalah acara kecil dan sederhana, tetapi yang lain adalah perayaan besar. Di Kroasia, misalnya, Anda dapat mengadakan upacara pernikahan sederhana di mana pasangan menikah di balai kota, bertukar cincin dan sumpah di depan tamu mereka, dan menghadiri makan malam setelah upacara atau pulang. Di negara lain, pernikahan bisa sangat rumit:mereka mungkin melibatkan pesta bujangan, negosiasi, makan malam, beberapa upacara, dan sebagainya. Dalam beberapa kasus, upacara ini dapat berlangsung selama beberapa hari dan terjadi di beberapa lokasi berbeda! Sekali lagi, model data kita harus siap untuk menangani situasi ini.
Hasil akhir dan pengeluaran
Dalam kebanyakan kasus, pasangan menikah setelah perayaan dan menerima tagihan untuk semua biaya (sewa, makanan dan minuman, band, dll). Mereka mungkin memutuskan untuk menyewa agen untuk mengurus semua biaya ini untuk mereka, atau mereka mungkin memilih untuk menangani semuanya sendiri. Bagaimanapun, kita harus memperhitungkan situasi ini.
Model Data:Ikhtisar
Model data kami untuk artikel ini terdiri dari lima bagian:
- Lokasi
- Mitra, Produk, dan Layanan
- Pernikahan
- Peserta
- Faktur
Kami akan membahas secara menyeluruh masing-masing area ini dalam urutan yang tercantum di atas. Saat kami mengembangkan model data kami, kami akan mengambil peran sebagai agensi yang menyelenggarakan pernikahan.
Bagian 1:Lokasi
Locations bagian menampilkan tabel universal yang dapat digunakan di banyak model data lainnya. Seperti yang kami sebutkan sebelumnya, seluruh upacara pernikahan dapat terjadi hanya di satu lokasi, atau berpotensi menjangkau beberapa lokasi. Mari kita bahas tabel bagian ini secara lebih rinci.
country tabel menyimpan informasi tentang negara tempat pernikahan berlangsung. Dalam kebanyakan kasus, negara ini akan cocok dengan lokasi agensi kami, tetapi mungkin tidak demikian jika kami beroperasi secara internasional. Setiap negara dalam tabel ini secara unik ditentukan oleh country_name its .
Selanjutnya, kita perlu menyimpan daftar semua kota dan/atau desa tempat pernikahan akan diselenggarakan. Informasi ini akan disimpan di city meja. Untuk setiap kota, kami akan menyimpan nama dan kode posnya, serta negara tempat kota tersebut berada.
Tabel terakhir di bidang subjek ini adalah location . Lokasi lebih spesifik, seperti balai kota, gereja, taman, dan sebagainya. Untuk setiap lokasi, kami akan menyimpan namanya dan referensi ke ID kota tempatnya berada. Kombinasi kedua atribut ini membentuk kunci unik untuk tabel ini.
Untuk lokasi, perhatikan bahwa kami telah mengambil pendekatan konservatif di sini untuk menghindari meliput kasus yang tidak biasa di mana upacara berlangsung di, katakanlah, kereta api atau pesawat terbang (dalam hal ini, "lokasi" mungkin melibatkan beberapa kota). Jika kita ingin membahas kasus ini, kita perlu membuat beberapa perubahan pada model kita.
Bagian 2:Mitra, Produk, dan Layanan
Sebelum kita beralih ke bagian tengah model data kita, kita perlu menyimpan daftar semua mitra yang bekerja sama dengan kita, serta produk dan layanan yang mereka tawarkan. Untuk mencapai ini, kami akan menggunakan lima tabel.
Pertama, daftar semua mitra yang bekerja sama dengan kami disimpan di partner kamus. Untuk setiap mitra, kami akan menyimpan partner_code unik mereka dan partner_name .
Tentu saja, mitra kami akan menyediakan layanan terkait pernikahan, yang dapat mencakup katering, mengorganisir band, menyiapkan peralatan audio dan video, menyediakan dukungan sewa, dan banyak lagi. Pada dasarnya, apa pun yang dapat Anda pikirkan berpotensi terkait dengan pernikahan dalam beberapa cara. Kami akan menyimpan daftar layanan ini di service kamus. Untuk setiap layanan, kami akan menyimpan:
service_code– nilai yang akan kami gunakan secara internal untuk menunjukkan layanan tertentu secara unik.service_name- nama layanan. Perhatikan bahwa layanan yang berbeda dapat berbagi nama yang sama. Ini akan terjadi jika dua mitra kami menawarkan layanan yang sama, yang sangat mungkin terjadi. Akan lebih baik lagi jika mereka menggunakan nama yang sama untuk jenis layanan yang sama karena itu akan membuat perbandingan harga untuk layanan yang sama menjadi lebih mudah.description– deskripsi tekstual opsional dari layanan.picture– tautan ke lokasi penyimpanan gambar layanan terkait.price– harga saat ini untuk layanan ini. Dapat berisi nilai NULL jika harganya tidak dapat ditentukan tanpa terlebih dahulu mengevaluasi berbagai faktor, seperti berapa banyak orang yang akan menghadiri upacara tersebut.
provides_service tabel menghubungkan mitra dengan daftar layanan yang mereka berikan. Untuk setiap kombinasi unik partner_id dan service_id , kami akan menyimpan deskripsi tekstual mendetail tentang sifat layanan yang disediakan oleh mitra dan apakah layanan tersebut saat ini tersedia.
Kami juga membutuhkan tabel untuk menyimpan informasi tentang produk dan hubungannya dengan mitra. product tabel mengikuti logika yang sama dengan service tabel, kecuali, seperti namanya, ini khusus untuk produk. Di tabel ini, kami akan menyimpan semua kemungkinan produk yang penting untuk sebagian besar upacara pernikahan, seperti cincin, pakaian, dekorasi, bunga, furnitur, dan banyak lagi.
Tabel terakhir di bagian ini adalah provides_product meja. Ini berfungsi seperti provides_service tabel, kecuali itu khusus untuk produk yang bertentangan dengan layanan. Ini menentukan mitra kami yang mana yang menawarkan produk yang dimaksud.
Bagian 3:Pernikahan
Kami akhirnya sampai pada inti model data kami—Weddings bagian. Ini berisi lima tabel baru yang mereferensikan tabel bagian lain. Perhatikan bahwa tabel bagian ini juga akan direferensikan di bagian model kita yang akan datang.
Dalam wedding meja, kami akan menyimpan daftar lengkap semua pernikahan yang kami selenggarakan/ikuti. Setiap pernikahan akan diberi wedding_code uniknya sendiri . Kami juga akan menyimpan waktu mulai dan berakhir yang direncanakan untuk seluruh upacara, dan kami akan memperbarui waktu mulai dan berakhir yang sebenarnya setiap kali informasi ini tersedia. Selain itu, kami akan menyimpan budget_planned nilai jadi kami setidaknya memiliki perkiraan berapa biaya semua ini. Semua detail lain yang terkait dengan pernikahan disimpan di area lain dari model data, jadi hanya ini yang kami butuhkan untuk saat ini.
Idenya di sini adalah untuk memperlakukan setiap pernikahan sebagai rangkaian acara. Acara pada gilirannya akan terkait dengan penawaran untuk produk/layanan yang diinginkan, penawaran yang ditolak dan diterima, dan detail relevan lainnya. Untuk memberi Anda gambaran yang lebih baik tentang bagaimana semua ini bekerja, kami dapat membagi seluruh pernikahan menjadi beberapa acara berikut:fase perencanaan, pesta bujangan/bujangan, upacara, dan setelah pesta/makan malam. Tentu saja, ini hanya beberapa acara pernikahan yang paling umum. Semua acara pernikahan disimpan di tabel acara. Sebuah event akan memiliki id yang unik.
Setiap acara dikaitkan dengan satu pernikahan, dan itu akan terkait dengan satu lokasi atau tidak sama sekali. Kasus terakhir muncul jika acaranya lebih konseptual , seperti fase perencanaan (karena tidak ada satu lokasi pun yang harus dilakukan). Seperti halnya upacara pernikahan itu sendiri, sebuah acara akan memiliki waktu mulai/akhir yang direncanakan dan nyata, serta anggaran yang direncanakan. Perhatikan bahwa kami telah membuat hal-hal sederhana di sini berkaitan dengan lokasi. Jika peristiwa melibatkan beberapa lokasi, kita perlu menyesuaikan model data kita.
Selanjutnya, kami ingin menyimpan semua layanan dan produk yang terkait dengan suatu acara. Untuk melakukannya, kami akan menggunakan tiga tabel:status , product_included , dan service_included .
status tabel adalah kamus yang melacak semua status yang terkait dengan produk dan layanan untuk acara tertentu. Ini termasuk variabel bendera yang menunjukkan apakah suatu produk/jasa telah ditawarkan, diterima, atau ditolak. Untuk setiap record dalam tabel ini, kami akan menyimpan status_name yang unik .
Dua tabel tersisa di bagian ini, berjudul product_included dan service_included , mirip satu sama lain secara struktural dan konseptual. Untuk setiap acara, kami akan menyimpan daftar produk dan layanan yang ditawarkan dan mengubah statusnya jika diterima atau ditolak. Untuk setiap record dalam dua tabel ini, kami akan menyimpan atribut umum berikut:
event_id– referensi ke acara terkait.provides_product_id/provides_service_id– referensi ke tabel dengan produk/layanan yang ditawarkan oleh mitra kami.price– harga yang diusulkan untuk produk/jasa. Harga ini mungkin berbeda dari harga standar yang kami miliki jika kami mengajukan penawaran khusus.current_status_id– referensi kestatuskamus yang menunjukkan apakah catatan ini ditawarkan, diterima, atau ditolak.
Bagian 4:Peserta
Jika Anda menyelenggarakan pernikahan besar, kemungkinan besar Anda mengenal sebagian besar tamu yang berencana untuk hadir. Tentu saja, tamu yang Anda undang—baik itu teman atau kerabat Anda—kemungkinan besar akan membawa orang lain yang tidak Anda kenal secara pribadi, seperti teman atau kolega mereka. Di bagian ini, kami akan menyimpan daftar lengkap tamu yang diundang ke pesta pernikahan, serta peran mereka.
person tabel berisi daftar semua individu yang merupakan bagian dari pernikahan. Untuk setiap individu, kami akan menyimpan person_code unik mereka dan nama depan dan belakang. Kami tentu saja dapat menambahkan lebih banyak detail jika kami mau.
Selanjutnya, kami akan mendefinisikan semua kemungkinan peran yang dapat diambil seseorang selama pernikahan. Peran-peran ini termasuk "tamu", "pria terbaik", "pengiring pria", "pengiring pengantin", "pengantin", "pengantin pria", dan seterusnya. Untuk setiap peran, kami hanya akan menyimpan role_name yang unik dalam tabel ini. Seseorang hanya dapat mengambil satu peran untuk pernikahan tertentu.
Selanjutnya, kami akan menghubungkan pernikahan dengan peserta mereka. Perhatikan bahwa participate tabel hanya berisi referensi ke tabel wedding , person , dan role . Kombinasi wedding_id dan person_id berfungsi sebagai kunci alternatif untuk tabel ini.
Pernikahan akan terdiri dari beberapa acara, tetapi tidak semua peserta akan terlibat di dalamnya. Oleh karena itu, kita perlu menyimpan informasi ini secara terpisah. Di in_event tabel, kami akan menyimpan pasangan unik kunci asing yang merujuk pada tabel event dan participate . Semua informasi tambahan akan disimpan di details teks diatribusikan.
Bagian 5:Faktur
Kami hampir selesai! Bagian terakhir dari model data kami memungkinkan kami untuk melacak pengeluaran yang terkait dengan pernikahan. Menyenangkan, bukan?
Kami biasanya akan membuat satu invoice per pernikahan, tetapi kami juga dapat menghasilkan lebih banyak jika perlu. Mudah-mudahan, jumlah total yang kami tagih kepada pasangan akan sangat sesuai dengan anggaran yang kami rencanakan, tetapi mungkin tidak selalu demikian. Untuk setiap faktur, kami akan menyimpan informasi berikut:
wedding_id– referensi ke pernikahan yang fakturnya diterbitkan.time_created– stempel waktu saat faktur dibuat.due_date– tanggal saat faktur harus dibayar.invoice_amount– jumlah total yang harus dibayar.payment_time– stempel waktu saat pembayaran benar-benar dikeluarkan. Tentu saja, atribut ini akan berisi nilai NULL hingga pembayaran dilakukan.paid– bendera yang menunjukkan apakah faktur telah dibayar. Atribut ini akan disetel ke “True” segera setelahpayment_timediperbarui.
Tabel terakhir dalam model kami menyangkut item yang ditagih itu sendiri. Kami akan menyimpannya di invoice_item meja. Untuk setiap catatan, kami akan menyimpan detail berikut:
item_name– nama pilihan kami untuk item tertentu.item_price– harga yang terkait dengan item tertentu.invoice_id– id faktur terkait.service_included_id– id layanan yang terkait dengan item faktur. Atribut ini dapat disetel ke NULL jika item yang dipermasalahkan sebenarnya tidak terkait dengan layanan apa pun atau jika itu hanya biaya tambahan yang telah kami terapkan ke invoice.product_included_id– id produk yang terkait dengan item faktur. Atribut ini dapat disetel ke NULL jika item yang dipermasalahkan sebenarnya tidak terkait dengan produk apa pun atau hanya sebagai biaya tambahan yang telah kami terapkan ke invoice.
Ringkasan
Itu cukup meringkas untuk model data ini! Sekali lagi, kita melihat betapa bergunanya pemodelan data dalam mengatur informasi perusahaan.
Seperti yang kami catat, ada banyak hal yang kami hilangkan dari model data kami demi kesederhanaan. Misalnya, model kami idealnya harus melacak riwayat penawaran, detail keuangan, dan banyak lagi.
Beri tahu kami di bawah jika Anda memiliki saran. Kami ingin mendengar pendapat Anda!
