Transportasi terintegrasi adalah sesuatu yang sering kita dengar di internet atau di berita. Meskipun ini bukan sesuatu yang baru, ini jelas merupakan proses yang berkelanjutan, dengan perubahan konstan yang diterapkan. Hari ini, kita akan melihat model data yang dapat menangani info zona, penumpang, dan tiket.
Mari gali langsung model data transportasi terintegrasi kami, dimulai dengan ide di balik semuanya.
Ide
Mengintegrasikan transportasi diperlukan untuk memaksimalkan efisiensinya dan, bagi pelanggan, kemudahan penggunaannya. Integrasi tidak hanya terkait dengan biaya tetapi juga waktu, aksesibilitas, kenyamanan, dan keamanan. Ini berlaku untuk kota-kota besar dan juga kota-kota kecil. Idenya adalah untuk menggunakan infrastruktur transportasi yang ada dan mengoptimalkannya untuk hasil yang lebih baik; ini bisa berarti membuat jadwal, notifikasi, jalur, atau stasiun baru. Mungkin hanya dengan memiliki beberapa info saja sudah cukup bagi Anda untuk memutuskan menunggu bus, menyewa sepeda, atau hanya berjalan kaki ke tempat tujuan.
Mari kita jelaskan ini menggunakan dua contoh.
Dalam kasus kota besar, biasanya ada banyak alat transportasi yang tersedia:bus, taksi, trem, kereta api, kereta bawah tanah, dll. Hal ini dapat menyebabkan banyak perusahaan swasta yang berbeda menyediakan berbagai layanan transportasi. Menggabungkan beberapa layanan ini pasti akan menguntungkan penumpang dan perusahaan dengan menurunkan biaya, meningkatkan efisiensi, dan menyediakan lebih banyak layanan per tiket.
Ada juga manfaat serupa untuk kota yang lebih kecil. Mungkin tidak ada jumlah opsi yang sama untuk digabungkan, tetapi mereka dapat diatur untuk mencapai efisiensi maksimum.
Artikel ini terutama akan berfokus pada sistem tiket transportasi terintegrasi. Kami tidak akan fokus pada semua aspek integrasi dan berbagai jenis transportasi; itu akan terlalu rumit.
Dengan mengingat hal ini, mari beralih ke model kita.
Model Data
Model ini terdiri dari dua bidang subjek:
Cities & companiesTickets
Kami akan menjelaskannya sesuai urutan daftarnya.
Kota dan Perusahaan
Di area subjek pertama, kami akan menyimpan semua tabel yang diperlukan untuk menyiapkan zona transportasi di kota.
country tabel berisi daftar country_name UNIK nilai-nilai. Tabel ini hanya digunakan sebagai referensi di city meja. Meskipun kami dapat berharap bahwa model kami akan mencakup transportasi hanya di satu negara, kami ingin memiliki opsi untuk menyertakan beberapa negara. Untuk setiap kota, kami akan menyimpan kombinasi UNIK city_name – country_id .
Kota-kota kecil mungkin hanya memiliki satu zona, sedangkan kota-kota besar akan memiliki banyak zona. Daftar semua zona yang mungkin disimpan di zone meja. Untuk setiap zona, kami akan menyimpan zone_name its dan referensi ke kota yang bersangkutan. Pasangan ini membentuk kunci alternatif dari tabel ini.
Kami dapat mengharapkan bahwa sistem kami akan menyimpan informasi tentang beberapa perusahaan transportasi. Perusahaan akan menerbitkan tiket mereka sendiri, tetapi mereka juga dapat menerbitkan tiket bersama-sama dengan perusahaan lain. Untuk setiap company , kami akan menyimpan kombinasi UNIK dari company_name dan city_id Dimana lokasi nya. Setiap informasi tambahan yang diperlukan dapat disimpan dalam details tekstual lapangan.
Hal terakhir yang perlu kita definisikan adalah bentuk transportasi yang disediakan oleh masing-masing perusahaan. Beberapa nilai yang diharapkan adalah “bus”, “trem”, “bawah tanah”, dan “kereta api”. Untuk setiap nilai dalam transport_form tabel, kami akan menyimpan UNIQUE form_name.
zone_id– Referensizonetabel dan menunjukkan area di mana bentuk transportasi ini disediakan oleh perusahaan ini.company_id– Merujukcompanymenyediakan layanan ini di zona ini.transport_form_id– Merujuk padatransport_formtabel dan menunjukkan jenis layanan yang disediakan.date_fromdandate_to– Periode selama layanan ini disediakan oleh perusahaan ini. Perhatikan bahwadate_todapat berisi nilai NULL jika layanan ini masih tersedia dan/atau tidak memiliki tanggal kedaluwarsa yang diharapkan.details– Semua detail lainnya, dalam format tekstual yang tidak terstruktur.is_active– Apakah layanan ini aktif (sedang berlangsung) atau tidak. Ini adalah sakelar hidup/mati sederhana yang dapat kita gunakan dalam beberapa kasus sebagai gantidate_from–date_tointerval aktivitas layanan. Penggunaan terbaik dari atribut ini adalah untuk menyederhanakan kueri, yaitu dengan menguji nilai ini daripada menguji interval tanggal dan “bermain” dengan nilai NULL.
Tiket
Area subjek sebelumnya hanyalah persiapan untuk hal utama:tiket. Dan itulah yang akan dibahas dalam area subjek ini.
Kami telah menentukan perusahaan, zona, dan formulir transportasi, tetapi kami tidak memiliki ketentuan apa pun untuk penumpang dan tiket – inti dari model ini. Kami akan berasumsi bahwa satu tiket dapat digunakan untuk satu atau beberapa zona yang dicakup oleh satu atau lebih perusahaan.
Oleh karena itu, pertama-tama kita perlu mendefinisikan setiap ticket_type . Dalam tabel ini, kami akan mencantumkan semua kemungkinan jenis tiket yang dijual oleh perusahaan di database kami. Untuk setiap jenis, kami akan menyimpan nilai berikut:
type_name– Nama UNIK yang menunjukkan tipe ini.valid_fromdanvalid_to– Periode ketika jenis tiket ini (atau dulu) valid. Kedua bidang tidak dapat dibatalkan; nilai NULL berarti tidak ada tanggal awal (atau akhir) kapan ini valid.details– Detail apa pun yang diperlukan, dalam format tekstual yang tidak terstruktur.recurring– Bendera yang menunjukkan apakah jenis tiket ini berulang (misalnya tahunan, bulanan) atau tidak.interval_month– Jika jenis tiket berulang, atribut ini akan berisi interval, dalam bulan, kapan tiket berulang (mis. “1” untuk tiket bulanan, “12” untuk tiket tahunan).
Sekarang kami siap untuk menentukan zona yang dicakup oleh setiap jenis tiket. Di service_included tabel, kami hanya akan menyimpan pasangan UNIK ticket_type_id – service_available_id . Yang terakhir juga akan menunjukkan perusahaan dan zona di mana tiket ini dapat digunakan. Tabel ini memungkinkan kita untuk menentukan beberapa zona per tiket; zona bisa milik perusahaan yang berbeda. Karena ini adalah jenis tiket yang telah ditentukan sebelumnya, setiap jenis tiket akan memiliki zona yang ditentukan di sini (bukan untuk setiap penumpang individu).
Kami tidak akan menyimpan terlalu banyak detail penumpang dalam model ini. Untuk setiap passenger , kami hanya akan menyimpan first_name mereka , last_name , address , dan referensi ke kota tempat mereka tinggal. Semua data ini akan ditampilkan di tiket.
Tabel terakhir dalam model kami adalah ticket meja. Kami tidak akan fokus pada tiket sekali pakai di sini; melainkan, kami akan menangani tiket berlangganan dan prabayar. Tiket ini akan memiliki saldo, tanggal validitas, atau keduanya. Ini bisa berbeda secara signifikan, berdasarkan perusahaan dan aturannya. Jika beberapa perusahaan memutuskan untuk mengeluarkan tiket, kami dapat mendukungnya dalam tabel ini – kami akan mengetahui semua detail penting. Untuk setiap tiket, kami akan menyimpan:
serial_number– Penunjukan UNIK untuk setiap tiket. Ini bisa berupa kombinasi angka dan huruf.ticket_type_id– Merujuk pada jenis tiket tersebut.passenger_id– Referensi penumpang, jika ada, yang memiliki tiket itu. Untuk tiket prabayar, tidak mungkin ada pemiliknya.valid_fromdanvalid_to– Menunjukkan periode berlakunya tiket ini. Nilai NULL menunjukkan tidak ada batas bawah atau atas.credits– Kredit (sebagai nilai numerik) saat ini tersedia di tiket itu. Jika itu tiket prabayar, kita dapat berasumsi bahwa penumpang akan membeli kredit tambahan pada tiket. Jika tiket berlaku sepanjang bulan (atau periode waktu lainnya) tanpa batasan penggunaan, nilai ini bisa menjadi NULL.
Peningkatan Model Data Transportasi Terintegrasi
Anda dapat melihat bahwa model ini telah sangat disederhanakan. Itu karena transportasi terintegrasi terlalu besar untuk dibahas dalam satu artikel. Ada beberapa hal yang menurut saya dapat diubah dalam model ini:
- Zona terlalu disederhanakan; kita harus dapat mendefinisikannya secara lebih dinamis.
- Kami tidak mencakup jalur (mis. jalur bus). Bagaimana jika mereka berpindah dari satu zona ke zona lain, dll.?
- Kami tidak menyimpan riwayat penggunaan tiket.
- Tidak ada pendaftaran untuk perusahaan dan penumpang.
Semua ini akan mengarah pada fakta bahwa kami kekurangan data penting dan tidak dapat membuat analisis yang lebih dalam. Jadi apa yang Anda pikirkan? Apa yang dibutuhkan model ini? Apa yang akan Anda tambahkan atau hapus? Bagikan ide Anda di komentar.
