911/112:Ein Notrufdienst-Datenmodell

Wir freuen uns nicht, eine Notrufnummer wie 911 oder 112 anzurufen, aber wir sind froh, sie zu haben, wenn wir sie brauchen! Am anderen Ende der Leitung ist es ein stressiger Job, und es gibt wenig Raum für Fehler. Alles muss perfekt funktionieren.

Heute werfen wir einen Blick auf das Datenmodell, das ein Notdienst verwenden könnte, um eingehende Anrufe zu verarbeiten und zu beantworten.

Idee

Notrufnummern sind von Land zu Land unterschiedlich. Die Nummern 911 (Nordamerika und einige andere Länder) und 112 (Europa und Teile von Afrika und Asien) sind weit verbreitet. Diese Nummern werden verwendet, um alle drei Notdienste (Polizei, Krankenwagen und Feuerwehr und Rettung) in einem Anruf zu kontaktieren. Einige Länder verwenden eine andere Nummer; andere haben keine zentrale Notrufnummer. In diesem Modell konzentriere ich mich auf Situationen, in denen eine solche zentralisierte Nummer vorhanden ist.

Die Grundidee ist, dass wenn jemand einen Anruf tätigt, sich ein Operator um diesen Anruf kümmert, alle relevanten Informationen sammelt und diese Informationen an die Verantwortlichen weiterleitet. Ein Beispiel könnte ein Autounfall sein:Nach Erhalt des Anrufs sollte der Operator wissen, wo sich dieser Unfall ereignet hat und wie schwer er ist. Sie können dann die Polizei und einen Krankenwagen schicken, um die Situation zu bewältigen. Ein weiteres Beispiel könnte ein Brand in einem Wohnhaus sein, der alle drei Rettungsdienste erfordern könnte.

Datenmodell

Das Datenmodell besteht aus drei Themenbereichen:

• Countries & cities
• Calls
• Actions & services

Wir beschreiben jeden dieser Themenbereiche in der Reihenfolge, in der sie aufgeführt sind.

Länder und Städte

Dieser Themenbereich ist nicht spezifisch für dieses Modell, wird aber dennoch benötigt, um die Standorte zu verfolgen, von denen Anrufe kamen.

Wir haben nur zwei Tabellen in diesem Themenbereich. Das country Tabelle enthält eine Liste von UNIQUE country_name Werte. Wir können davon ausgehen, dass wir hier nur ein Land haben werden, da die Rettungsdienste meist auf nationaler Ebene funktionieren. In einem größeren Land könnte diese Tabelle verwendet werden, um Staats- oder Provinznamen zu speichern.

Eine Liste aller Städte und Dörfer ist im city Wörterbuch. Für jede Stadt speichern wir eine EINZIGARTIGE Kombination aus country_id - city_name . Wir können erwarten, dass diese Tabelle eine Liste aller Städte und Dörfer in einem bestimmten Land enthält.

Anrufe

Es gibt zwei Themenbereiche, die für dieses Datenmodell spezifisch sind:Calls und Actions & services . Im Strom der Zeit kommen Anrufe zuerst und lösen andere Ereignisse aus. Daher beschreiben wir diesen Abschnitt zuerst.

Die Calls Themenbereich besteht aus fünf Tabellen. Während der call Tabelle offensichtlich die zentrale ist, werden wir zuerst die anderen vier Tabellen beschreiben, da sie alle in der Aufruftabelle referenziert werden.

Benutzer initiieren Anrufe über ihre Festnetz- oder Mobiltelefone. Wir müssen jede Nummer speichern, die 112 oder 911 angerufen hat, also brauchen wir eine phone_number Tisch. Bei jedem neuen Anruf prüfen wir, ob die Nummer bereits in dieser Tabelle vorhanden ist. Wenn nicht, fügen wir eine neue Zeile ein. Für jeden Tabellendatensatz speichern wir:

• phone_number – Die Nummer, die einen Anruf initiiert hat.
• number_status_id – Ein Verweis auf den number_status Wörterbuch. Dieser Wert gibt an, ob die Nummer, die den „ersten Kontakt“ hergestellt hat, „auf der schwarzen Liste“ oder „gesperrt“ ist usw. Dieser Wert kann uns bei der Entscheidung helfen, was zu tun ist, z. keinen neuen Anruf zu tätigen, wenn eine Nummer blockiert ist, eine Warnung auszugeben, wenn eine Nummer auf der schwarzen Liste steht, oder einfach Informationen für den Operator aufzuzeichnen.
• notes – Alle Notizen zu dieser Nummer, die von einem beliebigen Bediener eingefügt wurden. Dies ist kein Pflichtfeld und enthält meistens NULL-Werte.

Der operator Tabelle wird verwendet, um eine Liste aller Operatoren zu speichern, die Anrufe erhalten. Für jeden Operator speichern wir einen EINZIGARTIGEN operator_code (eine interne Bezeichnung), der first_name des Betreibers , und deren last_name . Wir speichern hier keine Details wie die Kontaktinformationen des Operators oder eine Markierung, die angibt, ob der Operator derzeit beschäftigt ist oder nicht.

Wir wollen jedem Anruf einen bestimmten Status zuweisen. Dazu benötigen wir zunächst einen call_status Wörterbuch. Dieses Wörterbuch enthält einen Satz EINZIGARTIGER status_name Werte. Einige erwartete Werte sind:„Anruf unterbrochen“, „Anruf abgebrochen“, „Anruf erfolgreich“ und „Anruf umgeleitet“.

Jetzt können wir den call Tisch. Ein Anruf wird vom Anrufer initiiert. Nachdem die Nummer in die Datenbank eingefügt wurde (falls es sich um eine zuvor unbekannte Nummer handelt), wird auch der Anruf eingefügt. Für jeden Anruf müssen wir Folgendes speichern:

• operator_id – Ein Verweis auf den operator die diesen Anruf erhalten haben.
• phone_number_id – Die Nummer, die den Anruf getätigt hat. In fast allen Fällen enthält dieses Attribut einen Wert, der auf phone_number Tisch. Trotzdem habe ich eine Option gelassen, um einen Anruf ohne Telefonnummer einzufügen. Dies kann passieren, wenn eine Nummer verborgen ist oder wenn ein Netzwerkfehler vorliegt.
• call_status_id – Ein Verweis auf den call_status Wörterbuch, das das Anrufergebnis beschreibt. Dieser Wert wird am Ende des Anrufs eingefügt.
• city_id – Ein Verweis auf die city Wörterbuch, das die Stadt angibt, in der der Anruf getätigt wurde. Dies könnte auch NULL sein, da diese Informationen unbekannt oder nicht benötigt werden.
• call_start_time – Gibt an, wann der Anruf gestartet wurde. Es kann in einigen Sonderfällen NULL sein, z. der Operator hat das Klingeln der Leitung gehört, aber der Anruf wurde nie wirklich hergestellt.
• call_end_time – Wenn der Anruf beendet wurde. Dieser Wert wird zum tatsächlichen Ende des Anrufs aktualisiert. Es enthält einen NULL-Wert, wenn der Anruf nie wirklich begonnen hat oder wenn der Anruf begonnen hat, aber noch im Gange ist.
• notes – Alle Notizen in freiem Textformat, die der Betreiber zu diesem Aufruf eingefügt hat.

Aktionen und Dienste

Nachdem ein Anruf getätigt wurde, ist es Zeit zu handeln. Diese Aktionen sollten automatisch die erforderlichen Notfalldienste alarmieren; wir sollten auch in der Lage sein, Benachrichtigungen nach Bedarf einzufügen oder zu entfernen.

Um dies abzudecken, verwenden wir fünf weitere Tabellen.

Im emergency_service Tabelle speichern wir eine Liste aller verfügbaren Notdienste. Diese Tabelle enthält einen EINZIGARTIGEN service_name und alle Informationen, die zur Kontaktaufnahme benötigt werden. Kontaktinformationen werden in einem strukturierten JSON-ähnlichen Format in den contact_details gespeichert Attribut. Einige der erwarteten Rettungsdienste sind „Polizei“, „Feuerwehr“ und „Krankenwagen“. Aber wir könnten auch andere haben, wie „Bergrettung“, „Zivilschutz“ usw.

Der action_catalog Wörterbuch enthält eine Liste aller möglichen Aktionen, die als Ergebnis eines Anrufs erforderlich sein könnten. Diese Tabelle enthält eine Liste solcher UNIQUE action_name Werte. Einige erwartete Werte hier sind „Alle Dienste alarmieren“, „Krankenwagen alarmieren“ usw.

Jetzt müssen wir eine Liste aller Alarme definieren, die automatisch auftreten sollen, wenn einem Anruf eine Aktion zugewiesen wird. Diese Werte werden im alert_service Tisch. Wir speichern das UNIQUE-Paar action_catalog_id – emergency_service_id , was bedeutet, dass ein bestimmter Notdienst kontaktiert werden sollte, wenn diese Aktion zugewiesen wird. Trotzdem möchten wir dies manchmal überarbeiten, also lasse ich eine Option, dies zu tun. Wenn das Flag always_alert auf True gesetzt ist, senden wir diese Warnung ohne manuelle Überwachung; andernfalls kann der Bediener eingreifen.

Die Zuordnung einer Aktion zu einem Anruf erfolgt über den action_required Tisch. Möglicherweise müssen wir für jeden Anruf mehr als eine Aktion haben, also brauchen wir diese Tabelle. Wir speichern die EINZIGARTIGE Kombination call_id – action_id sowie die ggf. vom Betreiber eingefügten Notizen.

Die letzte Tabelle in unserem Modell ist alerted_service Tisch. EINZIGARTIGE Paare von action_required_id – emergency_service_id bezeichnen die tatsächlichen Warnungen, die für diese Aktion (und diesen Anruf) initiiert wurden. Dies sind alle Datensätze mit dem alert_service.always_alert auf True gesetzt und alle Warnungen manuell gesetzt, nachdem der Bediener sie überarbeitet hat.

Mögliche Verbesserungen

Dieses Modell ist nur das Rückgrat einer möglichen Lösung. Ich persönlich kann viele Verbesserungen vorschlagen:

• Wie die Daten der Betreiber gespeichert werden.
• Einschließlich der Möglichkeit, nachzuverfolgen, was passiert ist, nachdem die Rettungsdienste alarmiert wurden.
• Lassen Sie einen Operator einen Anruf tätigen.
• Verknüpfung von Ereignissen in der Datenbank, damit wir definieren können, ob ein bestimmter Anruf mit einem anderen Anruf, einer anderen Aktion oder einem anderen Alarm in Verbindung steht. Im Moment kennen wir nur ihre Reihenfolge.

Wie funktionieren solche Dienste in Ihrem Land? Haben wir etwas verpasst? Was würden Sie diesem Modell hinzufügen oder daraus entfernen? Bitte teilen Sie uns dies in den Kommentaren unten mit.