Database
 sql >> Cơ Sở Dữ Liệu >  >> RDS >> Database

911/112:Mô hình dữ liệu dịch vụ cuộc gọi khẩn cấp

Gọi một số khẩn cấp như 911 hoặc 112 không phải là điều chúng tôi mong đợi, nhưng chúng tôi rất vui khi có nó khi cần! Ở đầu dây bên kia, đó là một công việc căng thẳng và có rất ít chỗ cho sai lầm. Mọi thứ cần phải hoạt động hoàn hảo.

Hôm nay, chúng ta sẽ xem xét mô hình dữ liệu mà một dịch vụ khẩn cấp có thể sử dụng để xử lý và trả lời các cuộc gọi đến.

Ý tưởng

Số điện thoại khẩn cấp khác nhau giữa các quốc gia. Các số 911 (Bắc Mỹ và một số quốc gia khác) và 112 (Châu Âu và một số khu vực của Châu Phi và Châu Á) được sử dụng rộng rãi. Những số này được sử dụng để liên hệ với cả ba dịch vụ khẩn cấp (cảnh sát, xe cứu thương và cứu hỏa và cứu hộ) trong một cuộc gọi. Một số quốc gia sử dụng một số khác; những người khác không có số điện thoại khẩn cấp tập trung. Trong mô hình này, tôi sẽ tập trung vào các tình huống tồn tại một số tập trung như vậy.

Ý tưởng chính là khi ai đó thực hiện một cuộc gọi, một nhà điều hành sẽ thực hiện cuộc gọi đó, thu thập tất cả thông tin liên quan và chuyển tiếp thông tin này cho những người phụ trách. Một ví dụ có thể là tai nạn xe hơi:sau khi nhận cuộc gọi, người điều hành phải biết tai nạn đó đã xảy ra ở đâu và mức độ nghiêm trọng của nó. Sau đó, họ có thể cử cảnh sát và xe cứu thương để xử lý tình huống. Một ví dụ khác có thể là hỏa hoạn trong một tòa nhà chung cư, có thể yêu cầu cả ba dịch vụ khẩn cấp.

Mô hình dữ liệu

Mô hình dữ liệu bao gồm ba lĩnh vực chủ đề:

  • Countries & cities
  • Calls
  • Actions & services

Chúng tôi sẽ mô tả từng lĩnh vực chủ đề này theo thứ tự chúng được liệt kê.

Quốc gia và Thành phố

Chủ đề này không dành riêng cho mô hình này, nhưng vẫn cần thiết để theo dõi các vị trí nơi các cuộc gọi đến.

Chúng tôi chỉ có hai bảng trong chủ đề này. country bảng chứa danh sách country_name DUY NHẤT các giá trị. Chúng tôi có thể mong đợi rằng chúng tôi sẽ chỉ có một quốc gia ở đây vì các dịch vụ khẩn cấp hầu hết hoạt động ở cấp quốc gia. Ở một quốc gia lớn hơn, bảng này có thể được sử dụng để lưu trữ tên tiểu bang hoặc tỉnh.

Danh sách tất cả các thành phố và làng mạc được lưu trữ trong city từ điển. Đối với mỗi thành phố, chúng tôi sẽ lưu trữ một tổ hợp DUY NHẤT của country_id - city_name . Chúng ta có thể mong đợi rằng bảng này sẽ chứa danh sách tất cả các thành phố và làng mạc ở một quốc gia nhất định.

Cuộc gọi

Có hai lĩnh vực chủ đề cụ thể cho mô hình dữ liệu này:CallsActions & services . Theo dòng thời gian, cuộc gọi đến trước và kích hoạt các sự kiện khác. Do đó, chúng tôi sẽ mô tả phần này trước.

Calls khu vực chủ đề bao gồm năm bảng. Trong khi call bảng rõ ràng là bảng trung tâm, chúng tôi sẽ mô tả bốn bảng còn lại trước vì tất cả chúng đều được tham chiếu trong bảng gọi.

Người dùng thực hiện cuộc gọi bằng điện thoại cố định hoặc điện thoại di động của họ. Chúng tôi cần lưu trữ từng số được gọi là 112 hoặc 911, vì vậy chúng tôi sẽ cần phone_number bàn. Mỗi khi một cuộc gọi mới được bắt đầu, chúng tôi sẽ kiểm tra xem số điện thoại đã tồn tại trong bảng này hay chưa. Nếu không, chúng tôi sẽ chèn một hàng mới. Đối với mỗi bản ghi bảng, chúng tôi sẽ lưu trữ:

  • phone_number - Số đã bắt đầu cuộc gọi.
  • number_status_id - Tham chiếu đến number_status từ điển. Giá trị này sẽ biểu thị nếu số được thực hiện trong “liên hệ đầu tiên”, bị “đưa vào danh sách đen” hoặc “bị chặn”, v.v. Giá trị này có thể giúp chúng tôi quyết định phải làm gì, ví dụ:không tạo cuộc gọi mới nếu một số bị chặn, đưa ra cảnh báo nếu số đó bị đưa vào danh sách đen hoặc chỉ cần ghi lại thông tin cho nhà điều hành.
  • notes - Tất cả các ghi chú liên quan đến số đó, được chèn bởi bất kỳ nhà điều hành nào. Đây không phải là trường bắt buộc và hầu hết sẽ chứa giá trị NULL.

operator bảng được sử dụng để lưu trữ danh sách tất cả các nhà khai thác nhận cuộc gọi. Đối với mỗi toán tử, chúng tôi sẽ lưu trữ một operator_code DUY NHẤT (chỉ định nội bộ), first_name của nhà điều hành và last_name của họ . Chúng tôi sẽ không lưu trữ thông tin chi tiết ở đây, chẳng hạn như thông tin liên hệ của nhà điều hành hoặc cờ biểu thị nhà điều hành hiện đang bận hay không.

Đối với mỗi cuộc gọi, chúng tôi muốn chỉ định một trạng thái nhất định. Để làm điều đó, trước tiên chúng tôi cần một call_status từ điển. Từ điển này chứa một tập hợp các status_name DUY NHẤT các giá trị. Một số giá trị mong đợi là:“cuộc gọi bị gián đoạn”, “cuộc gọi bị gián đoạn”, “cuộc gọi thành công” và “cuộc gọi được định tuyến lại”.

Bây giờ chúng tôi đã sẵn sàng để mô tả call bàn. Một cuộc gọi được bắt đầu bởi người gọi. Sau khi số được chèn vào cơ sở dữ liệu (nếu đó là một số chưa biết trước đó), lệnh gọi cũng sẽ được chèn. Đối với mỗi cuộc gọi, chúng tôi sẽ cần lưu trữ:

  • operator_id - Tham chiếu đến operator đã nhận cuộc gọi này.
  • phone_number_id - Số đã thực hiện cuộc gọi. Trong hầu hết các trường hợp, thuộc tính này sẽ chứa một giá trị tham chiếu đến phone_number bàn. Tuy nhiên, tôi vẫn để lại một tùy chọn để chèn cuộc gọi mà không cần số điện thoại. Điều này có thể xảy ra khi một số bị ẩn hoặc nếu có một số loại lỗi mạng.
  • call_status_id - Tham chiếu đến call_status từ điển mô tả kết quả cuộc gọi. Giá trị này sẽ được chèn vào cuối cuộc gọi.
  • city_id - Tham chiếu đến city từ điển, biểu thị thành phố nơi cuộc gọi được thực hiện. Đây cũng có thể là NULL, vì thông tin này có thể không xác định hoặc không cần thiết.
  • call_start_time - Biểu thị thời điểm cuộc gọi bắt đầu. Nó có thể là NULL trong một số trường hợp đặc biệt, ví dụ:người điều hành đã nghe thấy đường dây đổ chuông, nhưng cuộc gọi chưa bao giờ thực sự được thiết lập.
  • call_end_time - Khi cuộc gọi kết thúc. Giá trị này sẽ được cập nhật vào thời điểm thực tế cuộc gọi kết thúc. Nó sẽ chứa giá trị NULL nếu cuộc gọi chưa bao giờ thực sự bắt đầu hoặc nếu cuộc gọi đã bắt đầu nhưng vẫn đang diễn ra.
  • notes - Tất cả các ghi chú, ở định dạng văn bản miễn phí, mà nhà điều hành đã chèn liên quan đến cuộc gọi này.

Hành động và Dịch vụ

Sau khi một cuộc gọi được thực hiện, đã đến lúc hành động. Những hành động này sẽ tự động cảnh báo các dịch vụ khẩn cấp cần thiết; chúng tôi cũng có thể chèn hoặc xóa cảnh báo nếu cần.

Để đề cập đến vấn đề này, chúng tôi sẽ sử dụng năm bảng nữa.

Trong emergency_service bảng, chúng tôi sẽ lưu trữ danh sách tất cả các dịch vụ khẩn cấp hiện có. Bảng này chứa service_name DUY NHẤT và bất kỳ thông tin nào cần thiết để thiết lập liên hệ. Thông tin liên hệ được lưu trữ ở định dạng giống JSON có cấu trúc trong contact_details thuộc tính. Một số dịch vụ khẩn cấp được mong đợi là “cảnh sát”, “sở cứu hỏa” và “xe cứu thương”. Tuy nhiên, chúng tôi cũng có thể có những người khác, chẳng hạn như “cứu hộ trên núi”, “bảo vệ dân sự”, v.v.

action_catalog từ điển chứa danh sách tất cả các hành động có thể được yêu cầu do kết quả của một cuộc gọi. Bảng này chứa danh sách action_name DUY NHẤT như vậy các giá trị. Một số giá trị mong đợi ở đây là "cảnh báo tất cả các dịch vụ", "cảnh báo xe cứu thương", v.v.

Bây giờ chúng ta cần xác định danh sách tất cả các cảnh báo sẽ tự động xảy ra khi một hành động được chỉ định cho một cuộc gọi. Các giá trị này được lưu trữ trong alert_service bàn. Chúng tôi sẽ lưu trữ cặp DUY NHẤT action_catalog_id - emergency_service_id , biểu thị rằng một dịch vụ khẩn cấp nhất định sẽ được liên hệ khi hành động này được chỉ định. Tuy nhiên, đôi khi chúng tôi có thể muốn sửa đổi điều này, vì vậy tôi sẽ để lại một tùy chọn để làm điều đó. Nếu cờ always_alert được đặt thành Đúng, chúng tôi sẽ gửi cảnh báo này mà không cần giám sát thủ công; nếu không, nhà điều hành có thể can thiệp.

Việc gán một hành động cho một cuộc gọi được thực hiện qua action_required bàn. Chúng tôi có thể cần có nhiều hơn một hành động cho mỗi lệnh gọi, vì vậy chúng tôi cần bảng này. Chúng tôi sẽ lưu trữ kết hợp DUY NHẤT call_id - action_id cũng như các ghi chú, nếu có, được chèn bởi nhà điều hành.

Bảng cuối cùng trong mô hình của chúng tôi là alerted_service bàn. DUY NHẤT cặp action_required_id - emergency_service_id biểu thị các cảnh báo thực tế đã được bắt đầu cho hành động đó (và cuộc gọi). Đây sẽ là tất cả các bản ghi với alert_service.always_alert được đặt thành Đúng và tất cả các cảnh báo được đặt theo cách thủ công sau khi nhà điều hành sửa đổi chúng.

Các cải tiến có thể có

Mô hình này chỉ là xương sống của một giải pháp khả thi. Cá nhân tôi có thể đề xuất nhiều cải tiến:

  • Cách dữ liệu của người vận hành được lưu trữ.
  • Bao gồm khả năng theo dõi những gì đã xảy ra sau khi các dịch vụ khẩn cấp được cảnh báo.
  • Để một nhà điều hành bắt đầu cuộc gọi.
  • Liên quan đến các sự kiện trong cơ sở dữ liệu để chúng tôi có thể xác định xem một lệnh gọi nhất định có liên quan đến một lệnh gọi, hành động hoặc cảnh báo khác hay không. Hiện tại, chúng tôi chỉ biết đơn đặt hàng của họ.

Làm thế nào để những dịch vụ đó hoạt động ở quốc gia của bạn? Chúng ta đã bỏ lỡ điều gì đó? Bạn sẽ thêm hoặc bớt những gì từ mô hình này? Vui lòng cho chúng tôi biết trong phần bình luận bên dưới.


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. Chạy các tác vụ bảo trì cơ sở dữ liệu SQL bằng SQLCMD

  2. Theo dõi cấp độ cột và cấp độ hàng trong sao chép hợp nhất

  3. Mô hình dữ liệu

  4. Kích hoạt trong SQL

  5. Chuyển đổi ngầm bên cột đắt như thế nào?