Saya perlu merancang model data untuk sistem reservasi untuk sekolah mengemudi. Area subjek terlihat cukup mudah, tetapi kompleksitas masih terlibat. Anda harus melacak semua permintaan dari klien dan melacak sumber daya (kendaraan, waktu, dan instruktur) yang digunakan selama pelajaran.
Pengantar
Saya suka menggunakan pendekatan berbasis domain untuk merancang model data. Itu membuat saya mengesampingkan obsesi teknologi dan berkonsentrasi terutama pada pemodelan area subjek yang berputar di sekitar entitas terkait dan hubungan di antara mereka sendiri.
Singkatnya
Izinkan saya menuliskan persyaratan dalam bahasa Inggris terlebih dahulu.
Saya memerlukan model data untuk sekolah mengemudi untuk memungkinkan pelanggan untuk membuat reservasi untuk pelajaran on line. Sekolah mengemudi mungkin memiliki lebih dari satu instruktur dan lebih dari satu kendaraan . Instruktur ditugaskan untuk pelajaran setelah reservasi. Sistem harus mengizinkan pelanggan untuk membatalkan reservasi kapan saja sebelum hari yang dijadwalkan. Kendaraan yang ditugaskan untuk pelajaran juga harus direkam jika pelajaran berlangsung.
Entitas dan Hubungan yang Terlibat
Ketika saya memikirkan subjeknya, entitas yang pertama kali muncul di benak saya adalah, “Pelanggan” , “Instruktur” , “Pelajaran Mengemudi” , “Permintaan Reservasi” dan “Kendaraan” . Mari saya mulai dengan tabel pertama saya untuk model ini, dan itu adalah customer . Ini untuk menyimpan data master untuk pelanggan. Saya mungkin memerlukan tabel lain untuk menyimpan detail Instruktur, tetapi alih-alih membuat tabel dengan nama instruktur, saya akan membuat tabel generik bernama staff untuk rincian staf dan pertahankan "Instruktur" sebagai jabatan pekerjaan. Ini akan membuat model data saya dapat diperluas untuk melayani area layanan lain juga, seperti pekerjaan administrasi dan hukum, dari sekolah mengemudi.
Saya menganggap “kursus mengemudi” sebagai salah satu layanan, maka saya membuat tabel lain yang disebut service . Layanan, “kursus mengemudi” dalam hal ini, dapat memiliki beberapa pelajaran. Untuk menangani persyaratan ini, saya tentu membutuhkan tabel master lain, yaitu lesson , dan satu tabel hubungan, yaitu service_lesson , untuk mengelola hubungan banyak ke banyak antara kedua entitas master ini, yaitu satu layanan pasti dapat memiliki beberapa pelajaran, tetapi di sisi lain, satu pelajaran juga dapat menjadi bagian dari lebih dari satu layanan.
Ketika seseorang mengajukan permintaan reservasi, dia diminta untuk mengisi rinciannya dan preferensi awal seperti jenis layanan yang dia inginkan, pilihan kendaraan dan tanggal mulai. Detail pelanggan disimpan di tabel pelanggan. Selanjutnya, satu permintaan dibuat di request tabel, dan semua preferensi disimpan terhadap permintaan di tabel yang sama. Ada status tertentu yang terkait dengan setiap permintaan, seperti "kirim", "sedang diproses", "batal", dan "selesai". Saya akan membuat satu tabel pendukung untuk itu yang disebut request_status .
Pada saat pengajuan permintaan, seseorang menempatkan preferensi untuk kendaraan, yaitu jenis kendaraan. Namun, kendaraan sebenarnya akan ditugaskan untuk pelajaran ketika itu terjadi. Oleh karena itu saya menyimpan vehicle_type_id sebagai salah satu kolom di request tabel untuk saat ini.
Saat permintaan diproses, reservasi dibuat untuk setiap pelajaran dari permintaan layanan. Selain itu, instruktur dan kendaraan ditugaskan untuk setiap pelajaran berdasarkan ketersediaan instruktur dan preferensi pelanggan untuk kendaraan. Pelajaran dijadwalkan untuk tanggal mendatang dengan status "Buka". Semua detail ini ditangkap di tabel transaksi lain yang disebut reservation . Saya telah menyorot semua tabel transaksi dengan warna yang berbeda dari semua tabel master.
Satu tabel master, reservation_status , dibuat untuk menyimpan semua nilai yang mungkin untuk status reservasi seperti “terbuka”, “sedang diproses”, “batal”, dan “selesai”.
Model ini memungkinkan pelanggan untuk membatalkan pelajaran individu serta permintaan layanan secara keseluruhan. Jika pelanggan membatalkan permintaan layanan, maka semua pelajaran yang tersisa, yang dijadwalkan untuk pelanggan, dibatalkan di tabel reservasi.
Silakan lihat model data yang saya buat menggunakan Vertabelo untuk detail level kolom dari semua tabel ini. Beberapa poin tentang pembuatan kolom:
- Kolom bendera bernama
is_activeditambahkan ke semua tabel master untuk memungkinkan penghapusan catatan secara perlahan. Jadi misalnya, jika ada instruktur yang meninggalkan sekolah, kami akan mengibarkan bendera ke “N” untuk membuat catatannya tidak aktif. - Kolom tertentu seperti
created_date,created_by,last_modified_datedanlast_modified_byditambahkan di semua tabel transaksi untuk mengaktifkan jejak audit untuk perubahan catatan. Tabel transaksi disorot dengan warna biru pada model data yang dibuat di Vertabelo. - Anda mungkin bertanya-tanya apa
address_idkolom distaffmeja adalah untuk. Saya sengaja menempatkan kolom ini distafftabel sehingga saya dapat memperluas model data saya untuk mendukung proses otomatis untuk menetapkan instruktur ke permintaan berdasarkan lokasinya. Misalnya, di New York City, permintaan dari White Plains masuk. Sistem saya pertama-tama harus mencari instruktur yang tersedia di sekitar yang sama atau terdekat. Sistem saya tidak boleh menugaskan seorang instruktur yang tinggal di Manhattan, yang jaraknya hampir 50 mil dari tempat pemohon.
Fitur Penting Model Ini
- Model ini memungkinkan pelanggan untuk memasukkan permintaan reservasi sesuai preferensi mereka untuk tanggal mulai dan kendaraan.
- Ini memungkinkan mereka untuk membatalkan satu atau beberapa pelajaran dari kursus mereka, atau seluruh kursus itu sendiri.
- Model ini menangkap detail instruktur dan kendaraan untuk setiap pelajaran.
- Model ini dapat dikembangkan untuk menangani semua kemungkinan layanan yang disediakan oleh sekolah mengemudi.
- Ini memungkinkan kami merancang kursus pelatihan dan merencanakan pelajaran secara efektif.
Model Basis Data
Berikut adalah desain database untuk sistem reservasi kami. Model dibuat di Vertabelo untuk database Oracle tetapi desain yang sama dapat diimplementasikan untuk mesin database lain tanpa perubahan signifikan.
Kesimpulan
Ada area subjek tertentu yang tidak kami bahas dalam artikel ini, seperti:
- Dapatkah kita membangun pendekatan otomatis untuk mengalokasikan kendaraan dan instruktur ke pelajaran?
- Bagaimana dengan menagih pelanggan? Bagaimana jika pelanggan tidak ingin membayar seluruh kursus tetapi untuk beberapa pelajaran? Bisakah kita membuat pelajaran ini tersedia untuknya?
Apakah model kami yang ada mendukung fitur tersebut? Jawabannya adalah tidak. Saya mungkin akan membahas bidang subjek ini di artikel saya berikutnya.
