Database
 sql >> Teknologi Basis Data >  >> RDS >> Database

911/112:Model Data Layanan Panggilan Darurat

Memanggil nomor darurat seperti 911 atau 112 bukanlah sesuatu yang kami nantikan, tetapi kami senang memilikinya saat kami membutuhkannya! Di sisi lain, ini adalah pekerjaan yang membuat stres, dan hanya ada sedikit ruang untuk kesalahan. Semuanya perlu bekerja dengan sempurna.

Hari ini, kita akan melihat model data yang dapat digunakan layanan darurat untuk memproses dan menanggapi panggilan masuk.

Ide

Nomor darurat berbeda di setiap negara. Angka 911 (Amerika Utara dan beberapa negara lain) dan 112 (Eropa dan sebagian Afrika dan Asia) banyak digunakan. Nomor-nomor ini digunakan untuk menghubungi ketiga layanan darurat (polisi, ambulans, dan pemadam kebakaran dan penyelamatan) dalam satu panggilan. Beberapa negara menggunakan nomor yang berbeda; yang lain tidak memiliki nomor darurat terpusat. Dalam model ini, saya akan fokus pada situasi di mana nomor terpusat seperti itu ada.

Ide utamanya adalah ketika seseorang melakukan panggilan, operator menangani panggilan itu, mengumpulkan semua informasi yang relevan, dan meneruskan informasi ini kepada mereka yang bertanggung jawab. Salah satu contoh bisa kecelakaan mobil:setelah menerima panggilan, operator harus tahu di mana kecelakaan itu terjadi dan seberapa seriusnya. Mereka kemudian dapat mengirim polisi dan ambulans untuk menangani situasi tersebut. Contoh lain adalah kebakaran di gedung apartemen, yang membutuhkan ketiga layanan darurat.

Model Data

Model data terdiri dari tiga bidang subjek:

  • Countries & cities
  • Calls
  • Actions & services

Kami akan menjelaskan masing-masing bidang subjek ini dalam urutan daftarnya.

Negara dan Kota

Area subjek ini tidak spesifik untuk model ini, tetapi masih diperlukan untuk melacak lokasi asal panggilan.

Kami hanya memiliki dua tabel di bidang subjek ini. country tabel berisi daftar country_name UNIK nilai-nilai. Kita dapat berharap bahwa kita hanya akan memiliki satu negara di sini karena layanan darurat sebagian besar berfungsi di tingkat nasional. Di negara yang lebih besar, tabel ini dapat digunakan untuk menyimpan nama negara bagian atau provinsi.

Daftar semua kota dan desa disimpan di city kamus. Untuk setiap kota, kami akan menyimpan kombinasi UNIK dari country_id - city_name . Kita dapat berharap bahwa tabel ini akan berisi daftar semua kota dan desa di negara tertentu.

Panggilan

Ada dua bidang subjek yang khusus untuk model data ini:Calls dan Actions & services . Dalam aliran waktu, panggilan didahulukan dan memicu peristiwa lain. Oleh karena itu, kami akan menjelaskan bagian ini terlebih dahulu.

Calls mata pelajaran terdiri dari lima tabel. Sementara call tabel jelas yang utama, kami akan menjelaskan empat tabel lainnya terlebih dahulu karena semuanya direferensikan dalam tabel panggilan.

Pengguna memulai panggilan menggunakan telepon rumah atau ponsel mereka. Kita perlu menyimpan setiap nomor yang disebut 112 atau 911, jadi kita memerlukan phone_number meja. Setiap kali panggilan baru dimulai, kami akan memeriksa apakah nomor tersebut sudah ada di tabel ini. Jika tidak, kami akan menyisipkan baris baru. Untuk setiap catatan tabel, kami akan menyimpan:

  • phone_number – Nomor yang memulai panggilan.
  • number_status_id – Referensi ke number_status kamus. Nilai ini akan menunjukkan jika nomor yang melakukan "kontak pertama", adalah "daftar hitam" atau "diblokir", dll. Nilai ini dapat membantu kita dalam memutuskan apa yang harus dilakukan, mis. tidak membuat panggilan baru jika ada nomor yang diblokir, memberikan peringatan jika ada nomor yang masuk daftar hitam, atau sekadar merekam info untuk operator.
  • notes – Semua catatan yang terkait dengan nomor itu, dimasukkan oleh operator mana pun. Ini bukan bidang wajib dan sebagian besar akan berisi nilai NULL.

operator table digunakan untuk menyimpan daftar semua operator yang menerima panggilan. Untuk setiap operator, kami akan menyimpan operator_code UNIK (sebutan internal), first_name operator , dan last_name their . Kami tidak akan menyimpan detail di sini, seperti informasi kontak operator atau bendera yang menunjukkan apakah operator sedang sibuk atau tidak.

Untuk setiap panggilan, kami ingin menetapkan status tertentu. Untuk melakukannya, pertama-tama kita memerlukan call_status kamus. Kamus ini berisi satu set UNIK status_name nilai-nilai. Beberapa nilai yang diharapkan adalah:“panggilan terputus”, “panggilan terputus”, “panggilan berhasil”, dan “panggilan dialihkan”.

Sekarang kami siap menjelaskan call meja. Panggilan dimulai oleh penelepon. Setelah nomor tersebut dimasukkan ke dalam database (jika nomor yang sebelumnya tidak dikenal), panggilan akan dimasukkan juga. Untuk setiap panggilan, kita harus menyimpan:

  • operator_id – Referensi ke operator yang menerima panggilan ini.
  • phone_number_id - Nomor yang melakukan panggilan. Dalam hampir semua kasus, atribut ini akan berisi nilai yang merujuk pada phone_number meja. Namun, saya meninggalkan opsi untuk memasukkan panggilan tanpa nomor telepon. Ini bisa terjadi saat nomor disembunyikan atau jika ada semacam kesalahan jaringan.
  • call_status_id – Referensi ke call_status kamus yang menjelaskan hasil panggilan. Nilai ini akan dimasukkan di akhir panggilan.
  • city_id – Referensi ke city kamus, yang menunjukkan kota tempat panggilan dilakukan. Ini juga bisa NULL, karena info ini mungkin tidak diketahui atau tidak dibutuhkan.
  • call_start_time – Menandakan saat panggilan dimulai. Itu bisa NULL dalam beberapa kasus khusus, mis. operator mendengar telepon berdering, tetapi panggilan itu tidak pernah benar-benar dibuat.
  • call_end_time – Saat panggilan berakhir. Nilai ini akan diperbarui pada saat panggilan berakhir. Ini akan berisi nilai NULL jika panggilan tidak pernah benar-benar dimulai, atau jika panggilan dimulai tetapi masih berlangsung.
  • notes – Semua catatan, dalam format tekstual gratis, yang dimasukkan operator terkait panggilan ini.

Tindakan dan Layanan

Setelah panggilan dibuat, saatnya untuk bertindak. Tindakan ini harus secara otomatis mengingatkan layanan darurat yang diperlukan; kita juga harus dapat menyisipkan atau menghapus peringatan sesuai kebutuhan.

Untuk membahas ini, kami akan menggunakan lima tabel lagi.

Di emergency_service tabel, kami akan menyimpan daftar semua layanan darurat yang tersedia. Tabel ini berisi service_name UNIK dan informasi apa pun yang diperlukan untuk menjalin kontak. Info kontak disimpan dalam format mirip JSON terstruktur di contact_details atribut. Beberapa layanan darurat yang diharapkan adalah "polisi", "pemadam kebakaran", dan "ambulans". Namun, kita juga bisa memiliki orang lain, seperti “penyelamat gunung”, “penjaga sipil”, dll.

action_catalog kamus berisi daftar semua tindakan yang mungkin diperlukan sebagai akibat dari panggilan. Tabel ini berisi daftar action_name yang UNIK tersebut nilai-nilai. Beberapa nilai yang diharapkan di sini adalah “peringatan semua layanan”, “peringatan ambulans”, dll.

Sekarang kita perlu menentukan daftar semua peringatan yang akan muncul secara otomatis ketika suatu tindakan ditetapkan ke panggilan. Nilai-nilai ini disimpan di alert_service meja. Kami akan menyimpan pasangan UNIK action_catalog_idemergency_service_id , yang menunjukkan bahwa layanan darurat tertentu harus dihubungi saat tindakan ini ditetapkan. Namun, terkadang kami mungkin ingin merevisi ini, jadi saya akan meninggalkan opsi untuk melakukannya. Jika bendera always_alert disetel ke Benar, kami akan mengirimkan lansiran ini tanpa pengawasan manual; jika tidak, operator dapat melakukan intervensi.

Menetapkan tindakan ke panggilan dilakukan melalui action_required meja. Kita mungkin perlu memiliki lebih dari satu tindakan untuk setiap panggilan, jadi kita memerlukan tabel ini. Kami akan menyimpan kombinasi UNIK call_idaction_id serta catatan, jika ada, yang disisipkan oleh operator.

Tabel terakhir dalam model kami adalah alerted_service meja. Pasangan UNIK dari action_required_idemergency_service_id menunjukkan peringatan aktual yang dimulai untuk tindakan itu (dan panggilan). Ini akan menjadi semua catatan dengan alert_service.always_alert disetel ke Benar dan semua peringatan disetel secara manual setelah operator merevisinya.

Kemungkinan Peningkatan

Model ini hanyalah tulang punggung dari satu solusi yang mungkin. Saya pribadi dapat menyarankan banyak perbaikan:

  • Bagaimana data operator disimpan.
  • Termasuk kemungkinan untuk melacak apa yang terjadi setelah layanan darurat diperingatkan.
  • Membiarkan operator memulai panggilan.
  • Menghubungkan peristiwa dalam database sehingga kami dapat menentukan apakah panggilan tertentu terkait dengan panggilan, tindakan, atau peringatan lain. Saat ini, kami hanya mengetahui urutannya.

Bagaimana cara kerja layanan semacam itu di negara Anda? Apakah kami melewatkan sesuatu? Apa yang akan Anda tambahkan atau hapus dari model ini? Tolong beri tahu kami di komentar di bawah.


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. Membuat Database di Situs Cloud

  2. Keluarga Prosesor AMD Baru Bandingkan Dengan Prosesor Intel Baru

  3. Menghubungkan ke Sage dari Jawa

  4. Kejutan dan Asumsi Kinerja :DATEDIFF

  5. Menggunakan Wizard Reorg Offline