Model Basis Data untuk Layanan Taksi

Sebut mereka taksi atau taksi, wahana sewaan yang nyaman ini telah ada selama berabad-abad. Saat ini, menjalankan layanan taksi jauh lebih rumit. Dalam artikel ini, kita akan melihat model database yang dirancang untuk memenuhi kebutuhan perusahaan taksi.

Sejarah "memanggil taksi" dimulai di London abad ke-17. Di sebagian besar tempat, taksi lebih terjangkau dari sebelumnya. Mereka juga menjadi lebih mudah diakses:kita dapat memesan taksi melalui telepon, melalui aplikasi seluler, atau di Web. Atau kita dapat menggunakan teknik yang sama yang telah bekerja selama ratusan tahun – berbaris di stasiun taksi atau menurunkannya di jalan.

Model bisnis taksi sama sekali tidak stagnan. Konsep baru seperti Uber dan Lyft semakin populer dan tentunya akan berdampak pada masa depan layanan taksi. Tentu saja, semua ini mempersulit kehidupan mereka yang menjalankan perusahaan taksi. Mari kita lihat bagian penting dari model data yang dapat digunakan perusahaan taksi untuk tetap teratur.

Apa yang Ingin Kami Capai dengan Model Basis Data Kabin Ini?

Model yang disajikan dalam artikel ini akan dapat:

Buat jadwal pengemudi
Lacak ketersediaan pengemudi secara real time
Beri pengemudi daftar potensi perjalanan
Izinkan pengemudi untuk memilih perjalanan dari daftar
Menghitung jam kerja dan penghasilan pengemudi
Menyimpan berbagai statistik (mis. persentase perjalanan yang dibatalkan, pembayaran per pengemudi per bulan, dll.)

Apa yang Perlu Kita Ketahui Tentang Perusahaan Taksi?

Sebelum merancang model data untuk perusahaan taksi, kita harus dapat menjawab pertanyaan berikut:

Kapan pengemudi bekerja?
Di sebagian besar perusahaan taksi, pengemudi memiliki jadwal yang telah ditentukan sebelumnya. Kami akan mengetahui waktu yang tepat saat pengemudi memulai dan mengakhiri shift. Dalam beberapa kasus, waktu mulai dan berakhir shift tidak ditentukan sebelumnya. Misalnya, anggota asosiasi taksi dapat masuk dan mulai bekerja kapan pun mereka mau. Mereka juga dapat log out dan mengakhiri shift mereka saat mereka memilih. Model kami harus dapat mendukung kedua opsi.
Dapatkah pengemudi bekerja beberapa shift pada hari yang sama?
Jika pengemudi adalah anggota asosiasi taksi, mereka mungkin dapat bekerja di pagi hari, pulang, dan kemudian bekerja lagi pada malam yang sama. Namun, di beberapa daerah (seperti New York City) ada batasan hukum tentang lama shift dan/atau berapa jam pengemudi taksi dapat bekerja setiap hari.
3. Siapa yang memulai perjalanan?
Dalam kebanyakan kasus, pelanggan akan menghubungi call center taksi dan petugas operator akan memasukkan permintaan mereka ke dalam sistem. Skenario lain terjadi ketika pelanggan memesan taksi secara langsung (melalui aplikasi seluler, misalnya) dan tidak ada karyawan call center yang terlibat dalam proses tersebut. Opsi ketiga – yang juga melewati pusat panggilan – terjadi saat pelanggan mendapatkan taksi di stasiun atau memanggil taksi di jalan.

Model Data

Model kami memiliki dua bagian utama dan tiga tabel yang tidak dikategorikan. Kami akan melihat lebih dekat satu per satu.

Bagian 1:Kabin, Pengemudi, dan Shift

Semuanya dimulai dengan taksi dan pengemudi:kami membutuhkan mobil di perusahaan taksi dan kami membutuhkan pengemudi. (Di masa depan, kita mungkin perlu menyesuaikan model kita untuk mobil self-driving. Tapi mari kita tetap di masa sekarang.)

Kami akan memulai eksplorasi model data dengan driver meja. Dalam tabel ini, kami akan menyertakan atribut biasa seperti nama, nama keluarga, dan tanggal lahir. Kami juga akan memiliki beberapa atribut yang cukup spesifik untuk model ini:

driving_licence_number – Ini adalah nomor ID atau kode alfanumerik yang biasanya ditemukan pada lisensi yang dikeluarkan pemerintah. Karena ID ini unik di dunia nyata, ID ini juga unik di database kami. (Di beberapa daerah, pengemudi taksi harus memiliki jenis izin operasi khusus untuk bekerja; kami akan menganggap mereka memilikinya.)
expiry_date – Ini adalah tanggal ketika SIM tidak lagi berlaku secara hukum. Perhatikan bahwa kami tidak akan menyimpan riwayat lisensi, jadi kami hanya akan menimpa driving_licence_number dan expiry_date dengan data baru sesuai kebutuhan. Jika kita ingin menyimpan riwayat lisensi, kita perlu menambahkan tabel lain ke model kita.
working – Ini adalah nilai Boolean yang hanya menyala dan mati saat driver masuk ke sistem. Kami akan menyetel atribut ini secara default ke "Ya" (nilai 1) dan mengubahnya menjadi "Tidak" hanya jika pengemudi tidak diizinkan untuk masuk ke sistem lagi.

Ada banyak detail terkait pengemudi lainnya yang dapat kami simpan di database:nama pengguna dan kata sandi, tanggal setiap pengemudi mulai bekerja, dan jenis pekerjaan masing-masing pengemudi saat ini. Kami tidak akan membahas detail ini sekarang karena tidak secara khusus terkait dengan model ini. Saya akan mengklasifikasikannya di bawah administrasi pengguna, yang sama di sebagian besar sistem.

Sekarang, mari kita beralih ke cab dan car_model tabel. Di sinilah kami akan menyimpan daftar mobil yang dioperasikan perusahaan kami. Kami juga akan menyimpan detail tertentu tentang setiap kendaraan. Atribut terpenting dalam dua tabel ini adalah:

model_description – Ini adalah atribut teks yang menyimpan deskripsi khusus perusahaan tentang jenis mobil tertentu. Misalnya, perusahaan taksi mungkin ingin menyimpan jumlah penumpang yang dapat dibawa oleh mobil, ruang bagasi (boot), dan fakta lainnya.
license_plate – Nomor pada plat nomor (plat nomor kendaraan atau plat nomor) secara unik mendefinisikan sebuah mobil, baik untuk perusahaan maupun untuk keperluan pemerintah. Tentu saja, kita mungkin perlu mengubah informasi plat nomor jika mobil dibeli atau dijual. Di tabel ini, kami hanya akan menyimpan kendaraan perusahaan saat ini; jika kita perlu menyimpan riwayat, kita dapat menambahkan satu tabel lagi ke model kita.
owner_id – Atribut ini adalah referensi ke driver meja. Ini opsional karena kami hanya akan menggunakannya ketika pengemudi memiliki taksi mereka. (Ini biasanya terjadi di asosiasi taksi).
active – Ini adalah nilai Boolean yang menunjukkan apakah perusahaan masih menggunakan mobil.

Terakhir, mari kita lihat tabel terpenting di bagian ini:shift meja. Gagasan di balik tabel ini adalah untuk menyimpan jam kerja aktual dan jadwal shift untuk mobil dan pengemudi. Setiap shift akan memiliki setidaknya satu taksi (cab_id ) dan satu driver (driver_id ). Selain dari kunci utama, yang merupakan nomor ID shift unik, ini adalah satu-satunya atribut wajib dalam tabel ini.

shift_start_time dan shift_end_time atribut adalah momen aktual ketika shift dimulai dan berakhir. Seringkali, ini sudah diatur sebelumnya. Jika tidak ada jadwal, seperti dalam asosiasi taksi, waktu ini akan sama dengan login_time dan logout_time atribut, masing-masing. login_time dan logout_time adalah waktu sebenarnya pengemudi masuk (melalui perangkat seluler di mobil mereka atau metode apa pun yang digunakan perusahaan taksi). Saat pengemudi masuk ke sistem, daftar wahana yang tersedia akan muncul, dan pengemudi akan memilih salah satu. Tentu saja, petugas operator juga akan diberi tahu bahwa pengemudi sekarang bekerja.

Bagian 2:Wahana

Bagian ini hanya terdiri dari dua tabel, tetapi mereka adalah inti sebenarnya dari model ini.

Di cab_ride meja, kami akan menyimpan satu catatan untuk setiap perjalanan potensial. Kami akan memperbarui catatan ini sesuai dengan apa yang terjadi. Mari kita lihat ikhtisar singkat tentang atribut:

shift_id – Ini adalah referensi ke shift meja; ini memberi kami detail pengemudi dan taksi untuk perjalanan tertentu.
ride_start_time dan ride_end_time – Ini diperbarui ketika driver memberi sinyal bahwa mereka sedang sibuk (ride start) dan kemudian tersedia lagi (ride end).
address_starting_point dan address_destination – Ini adalah lokasi di mana perjalanan dimulai dan berakhir. Pengemudi mungkin akan menelusuri kedua lokasi untuk mendapatkan navigasi di tablet atau GPS-nya, jadi kemungkinan besar kami akan memperbarui kedua atribut ini.
GPS_starting_point dan GPS_destination – Ini adalah koordinat GPS dari lokasi awal dan akhir yang dijelaskan di atas. Nilai ini opsional karena kami akan memperbaruinya hanya jika kami memiliki data.
canceled – Ini adalah nilai Ya/Tidak sederhana yang memberi tahu kami jika perjalanan telah dibatalkan. Kami sudah memiliki catatan untuk perjalanan itu di meja kami, jadi kami bisa menandai perjalanan itu sebagai dibatalkan.
payment_type_id dan price – Ini memberikan informasi tentang jumlah yang dibayarkan untuk perjalanan dan metode pembayaran yang digunakan oleh pelanggan.

Sebagian besar atribut di cab_ride tabel dapat berisi nilai NULL. Ada dua alasan untuk ini:

Perjalanan dibatalkan, yang berarti tidak ada data yang akan dimasukkan di kolom ini;
Bahkan jika pada akhirnya kita akan memiliki semua data, kita tidak akan memiliki semuanya saat catatan pertama kali dimasukkan. Kami akan memperbarui setiap catatan beberapa kali – setidaknya, kami akan memperbaruinya saat perjalanan dimulai dan berakhir (atau dibatalkan).

Tabel kedua di bagian ini adalah cab_ride_status meja. Di sini, catatan ditambahkan untuk setiap perubahan yang terkait dengan satu perjalanan. Saat petugas operator memasuki wahana baru dalam sistem, mereka akan menambahkan catatan ke cab_ride tabel, tetapi catatan terkait juga akan dibuat di cab_ride_status tabel (bersama dengan status yang sesuai). Setelah setiap perubahan yang terkait dengan perjalanan itu, satu rekor lagi akan ditambahkan ke tabel ini. Atributnya adalah:

cab_ride_id dan status_id – Ini adalah kunci asing yang terkait dengan atribut id di ride tabel dan atribut id di status tabel (yang akan kita bahas di bawah). Keduanya wajib.
status_time – Ini menyimpan waktu sebenarnya saat catatan dimasukkan. Itu juga wajib.
cc_agent_id dan shift_id – Ini adalah referensi ke karyawan yang memasukkan pembaruan status. Itu bisa berupa petugas operator atau pengemudi. Mungkin petugas operator akan memasukkan status awal dan pengemudi akan memasukkan semua status berikut.
status_details – Ini adalah atribut teks yang dapat digunakan untuk menyimpan informasi tambahan. Misalnya, petugas operator dapat menggunakan atribut ini untuk merekam instruksi khusus tentang perjalanan.

Tabel Tanpa Kategori

Terakhir, mari kita bahas tabel yang belum dikategorikan.

cc_agent tabel berisi daftar agen pusat panggilan atau petugas operator yang dapat menambahkan catatan baru di cab_ride dan cab_ride_status tabel.

Dalam status kamus, kami akan menyimpan daftar semua kemungkinan status yang dapat kami tetapkan untuk perjalanan. Beberapa nilai termasuk “kendaraan baru” , “naik ditugaskan ke pengemudi” , “perjalanan dimulai” , “perjalanan berakhir” , atau “perjalanan dibatalkan” .

Payment_type adalah tabel kamus lainnya. Isinya digunakan untuk memperbarui payment_type_id atribut di cab_ride meja. Nilai umum adalah “uang tunai” dan “kartu kredit” .

Bagaimana Anda Meningkatkan Model Data Taksi?

Model database taksi/taksi yang disajikan dalam artikel ini difokuskan hanya pada fungsi yang paling penting. Ada banyak perbaikan yang bisa kami lakukan. Rute hanyalah salah satu yang dapat saya pikirkan.

Di masa depan, kita mungkin akan memiliki taksi tanpa pengemudi. Dalam hal ini, kami akan menurunkan pengemudi dari model dan mengganti hal-hal seperti pengisian ulang dan waktu perbaikan.

Jangan ragu untuk berkomentar dan menambahkan ide Anda.