911/112：緊急通報サービスのデータモデル

911や112のような緊急電話番号に電話をかけることは、私たちが楽しみにしていることではありませんが、必要なときに電話をかけることができてうれしいです。反対に、それはストレスの多い仕事であり、間違いの余地はほとんどありません。すべてが完全に機能する必要があります。

今日は、緊急サービスが着信を処理して応答するために使用できるデータモデルを見ていきます。

アイデア

緊急事態の数は国によって異なります。番号911（北アメリカおよび他のいくつかの国）および112（ヨーロッパおよびアフリカおよびアジアの一部）は広く使用されています。これらの番号は、3つの緊急サービス（警察、救急車、消防救助）すべてに1回の電話で連絡するために使用されます。一部の国では異なる番号を使用しています。他の人は一元化された緊急番号を持っていません。このモデルでは、そのような集中型の番号が存在する状況に焦点を当てます。

主な考え方は、誰かが電話をかけると、オペレーターがその電話を処理し、関連するすべての情報を収集して、この情報を担当者に転送するというものです。一例として、自動車事故が考えられます。電話を受けた後、オペレーターはその事故がどこで発生したか、そしてそれがどれほど深刻であるかを知る必要があります。その後、警察と救急車を送って状況を処理することができます。もう1つの例は、アパートの建物での火災で、3つすべての緊急サービスが必要になる可能性があります。

データモデル

データモデルは、次の3つのサブジェクト領域で構成されています。

Countries & cities
Calls
Actions & services

これらの各主題分野について、記載されている順序で説明します。

国と都市

このサブジェクトエリアはこのモデルに固有のものではありませんが、通話が発信された場所を追跡する必要があります。

このサブジェクトエリアには2つのテーブルしかありません。 country テーブルには、UNIQUE country_nameのリストが含まれています値。緊急サービスは主に国レベルで機能するため、ここには1つの国しかないと予想できます。大国では、このテーブルを使用して州名または州名を保存できます。

すべての都市と村のリストはcity 辞書。都市ごとに、country_idの一意の組み合わせを保存します -city_name 。この表には、特定の国のすべての都市と村のリストが含まれることが期待できます。

通話

このデータモデルに固有の2つのサブジェクト領域があります。Calls およびActions & services 。時間の流れの中で、呼び出しが最初に来て、他のイベントをトリガーします。したがって、最初にこのセクションについて説明します。

Calls サブジェクトエリアは5つのテーブルで構成されています。 call テーブルは明らかに中心的なものです。他の4つのテーブルはすべて呼び出しテーブルで参照されているため、最初に説明します。

ユーザーは、固定電話または携帯電話を使用して通話を開始します。 112または911と呼ばれる各番号を保存する必要があるため、phone_number テーブル。新しい通話が開始されるたびに、その番号がこのテーブルにすでに存在するかどうかを確認します。そうでない場合は、新しい行を挿入します。テーブルレコードごとに、以下を保存します：

phone_number –通話を開始した番号。
number_status_id – number_status 辞書。この値は、番号が「最初の連絡先」であるか、「ブラックリストに登録されている」または「ブロックされている」かなどを示します。この値は、何をすべきかを決定するのに役立ちます。番号がブロックされている場合は新しい通話を作成しない、番号がブラックリストに登録されている場合は警告をスローする、または単にオペレーターの情報を記録しないでください。
notes –任意のオペレーターによって挿入された、その番号に関連するすべてのメモ。これは必須フィールドではなく、ほとんどの場合NULL値が含まれます。

operator テーブルは、呼び出しを受信するすべてのオペレーターのリストを格納するために使用されます。演算子ごとに、一意のoperator_codeを保存します（内部指定）、オペレーターのfirst_name 、およびそれらのlast_name 。ここには、オペレーターの連絡先情報や、オペレーターが現在忙しいかどうかを示すフラグなどの詳細は保存されません。

呼び出しごとに、特定のステータスを割り当てます。そのためには、まずcall_status 辞書。この辞書には、一連のUNIQUE status_nameが含まれています値。期待される値には、「通話が中断された」、「通話が切断された」、「通話が成功した」、「通話が再ルーティングされた」などがあります。

これで、call テーブル。呼び出しは、呼び出し元によって開始されます。番号がデータベースに挿入された後（以前は不明な番号の場合）、通話も挿入されます。通話ごとに、以下を保存する必要があります：

operator_id – operator この電話を受けた人。
phone_number_id –電話をかけた番号。ほとんどの場合、この属性にはphone_number テーブル。それでも、電話番号なしで電話をかけるオプションを残しました。これは、番号が非表示になっている場合、または何らかのネットワークエラーが発生した場合に発生する可能性があります。
call_status_id – call_status 呼び出しの結果を説明する辞書。この値は、通話の最後に挿入されます。
city_id – city 呼び出しが行われた都市を示す辞書。この情報は不明または不要である可能性があるため、これもNULLになる可能性があります。
call_start_time –通話がいつ開始されたかを示します。特殊なケースでは、NULLになる可能性があります。オペレーターは回線の呼び出し音を聞きましたが、実際に通話が確立されることはありませんでした。
call_end_time –通話が終了したとき。この値は、通話が実際に終了したときに更新されます。呼び出しが実際に開始されなかった場合、または呼び出しが開始されたがまだ進行中の場合は、NULL値が含まれます。
notes –この呼び出しに関してオペレーターが挿入した、フリーテキスト形式のすべてのメモ。

アクションとサービス

電話をかけたら、行動を起こしましょう。これらのアクションは、必要な緊急サービスに自動的に警告する必要があります。必要に応じてアラートを挿入または削除できるようにする必要もあります。

これをカバーするために、さらに5つのテーブルを使用します。

emergency_service 表には、利用可能なすべての緊急サービスのリストが保存されます。このテーブルには、UNIQUE service_nameが含まれています連絡先を確立するために必要な情報。連絡先情報は、構造化されたJSONのような形式でcontact_detailsに保存されます属性。予想される緊急サービスには、「警察」、「消防署」、「救急車」などがあります。それでも、「山岳救助」や「市民警備隊」など、他の人も参加することができます。

action_catalog 辞書には、呼び出しの結果として必要になる可能性のあるすべての可能なアクションのリストが含まれています。このテーブルには、そのようなUNIQUE action_nameのリストが含まれています値。ここで期待される値には、「すべてのサービスに警告する」、「救急車に警告する」などがあります。

次に、アクションが呼び出しに割り当てられたときに自動的に発生するすべてのアラートのリストを定義する必要があります。これらの値はalert_service テーブル。 UNIQUEペアaction_catalog_idを保存します – emergency_service_id 、このアクションが割り当てられたときに特定の緊急サービスに連絡する必要があることを示します。それでも、これを修正したい場合があるので、それを行うオプションを残しておきます。フラグがalways_alertの場合 Trueに設定されている場合、手動による監視なしでこのアラートを送信します。それ以外の場合は、オペレーターが介入できます。

呼び出しへのアクションの割り当ては、action_required テーブル。呼び出しごとに複数のアクションが必要になる場合があるため、このテーブルが必要です。 UNIQUEの組み合わせcall_idを保存します – action_id オペレーターが挿入したメモ（ある場合）も同様です。

モデルの最後のテーブルはalerted_service テーブル。 action_required_idの一意のペア – emergency_service_id そのアクション（および呼び出し）に対して開始された実際のアラートを示します。これらはすべて、alert_service.always_alertのレコードになります Trueに設定し、オペレーターが修正した後にすべてのアラートを手動で設定します。

可能な改善

このモデルは、考えられる1つのソリューションのバックボーンにすぎません。私は個人的に多くの改善を提案することができます：

オペレーターのデータの保存方法。
緊急サービスが警告された後に何が起こったかを追跡する可能性を含みます。
オペレーターに通話を開始させる。
データベース内のイベントを関連付けて、特定の呼び出しが別の呼び出し、アクション、またはアラートに関連しているかどうかを定義できるようにします。現時点では、私たちは彼らの順序しか知りません。

そのようなサービスはあなたの国でどのように機能しますか？私たちは何かを逃しましたか？このモデルに何を追加または削除しますか？以下のコメントで教えてください。