911/112:Un modello di dati del servizio di chiamata di emergenza

Chiamare un numero di emergenza come il 911 o il 112 non è qualcosa che non vediamo l'ora, ma siamo felici di averlo quando ne abbiamo bisogno! Dall'altra parte, è un lavoro stressante e c'è poco spazio per gli errori. Tutto deve funzionare perfettamente.

Oggi daremo un'occhiata al modello di dati che un servizio di emergenza potrebbe utilizzare per elaborare e rispondere alle chiamate in arrivo.

Idea

I numeri di emergenza variano da paese a paese. I numeri 911 (Nord America e alcuni altri paesi) e 112 (Europa e parti dell'Africa e dell'Asia) sono ampiamente utilizzati. Questi numeri vengono utilizzati per contattare tutti e tre i servizi di emergenza (polizia, ambulanza e vigili del fuoco e soccorso) in un'unica chiamata. Alcuni paesi utilizzano un numero diverso; altri non hanno un numero di emergenza centralizzato. In questo modello, mi concentrerò su situazioni in cui esiste un numero così centralizzato.

L'idea principale è che quando qualcuno effettua una chiamata, un operatore si prende cura di quella chiamata, raccoglie tutte le informazioni rilevanti e le inoltra ai responsabili. Un esempio potrebbe essere un incidente stradale:dopo aver ricevuto la chiamata, l'operatore dovrebbe sapere dove è avvenuto l'incidente e quanto è grave. Possono quindi inviare la polizia e un'ambulanza per gestire la situazione. Un altro esempio potrebbe essere un incendio in un condominio, che potrebbe richiedere tutti e tre i servizi di emergenza.

Modello di dati

Il modello di dati si compone di tre aree tematiche:

• Countries & cities
• Calls
• Actions & services

Descriveremo ciascuna di queste aree tematiche nell'ordine in cui sono elencate.

Paesi e città

Questa area tematica non è specifica per questo modello, ma è comunque necessaria per tenere traccia delle località da cui provengono le chiamate.

Abbiamo solo due tabelle in questa area tematica. Il country la tabella contiene un elenco di UNIQUE country_name valori. Possiamo aspettarci di avere un solo paese qui perché i servizi di emergenza funzionano principalmente a livello nazionale. In un Paese più grande, questa tabella potrebbe essere utilizzata per memorizzare i nomi di stati o province.

Un elenco di tutte le città e villaggi è memorizzato nella city dizionario. Per ogni città, memorizzeremo una combinazione UNICA di country_id - city_name . Possiamo aspettarci che questa tabella contenga un elenco di tutte le città e villaggi in un determinato paese.

Chiamate

Esistono due aree tematiche specifiche per questo modello di dati:Calls e Actions & services . Nel flusso del tempo, le chiamate vengono prima e attivano altri eventi. Pertanto, descriveremo prima questa sezione.

Le Calls l'area tematica è composta da cinque tabelle. Mentre il call table è ovviamente quella centrale, descriveremo prima le altre quattro tabelle perché sono tutte referenziate nella tabella delle chiamate.

Gli utenti avviano le chiamate utilizzando il proprio telefono fisso o mobile. Dobbiamo memorizzare ogni numero che ha chiamato il 112 o il 911, quindi avremo bisogno di un phone_number tavolo. Ogni volta che viene avviata una nuova chiamata, verificheremo se il numero esiste già in questa tabella. In caso contrario, inseriremo una nuova riga. Per ogni record della tabella, memorizzeremo:

• phone_number – Il numero che ha avviato una chiamata.
• number_status_id – Un riferimento al number_status dizionario. Questo valore denota se il numero effettuato il "primo contatto", è "nella lista nera" o "bloccato", ecc. Questo valore potrebbe aiutarci a decidere cosa fare, ad es. non creare una nuova chiamata se un numero è bloccato, lanciare un avviso se un numero è nella lista nera o semplicemente registrare informazioni per l'operatore.
• notes – Tutte le note relative a quel numero, inserite da qualsiasi operatore. Questo non è un campo obbligatorio e conterrà principalmente valori NULL.

L'operator La tabella viene utilizzata per memorizzare un elenco di tutti gli operatori che ricevono le chiamate. Per ogni operatore, memorizzeremo un operator_code UNICO (una designazione interna), il first_name dell'operatore e il loro last_name . Non memorizzeremo qui i dettagli, come le informazioni di contatto degli operatori o un contrassegno che indica se l'operatore è attualmente occupato o meno.

Per ogni chiamata, vogliamo assegnare un determinato stato. Per farlo, avremo prima bisogno di un call_status dizionario. Questo dizionario contiene un insieme di UNIQUE status_name valori. Alcuni valori previsti sono:"chiamata interrotta", "chiamata interrotta", "chiamata riuscita" e "chiamata reindirizzata".

Ora siamo pronti per descrivere la call tavolo. Una chiamata viene avviata dal chiamante. Dopo che il numero è stato inserito nel database (se è un numero precedentemente sconosciuto), viene inserita anche la chiamata. Per ogni chiamata, dovremo memorizzare:

• operator_id – Un riferimento all'operator che ha ricevuto questa chiamata.
• phone_number_id – Il numero che ha effettuato la chiamata. In quasi tutti i casi, questo attributo conterrà un valore che fa riferimento al phone_number tavolo. Tuttavia, ho lasciato un'opzione per inserire una chiamata senza un numero di telefono. Questo potrebbe accadere quando un numero è nascosto o se c'è un qualche tipo di errore di rete.
• call_status_id – Un riferimento al call_status dizionario che descrive l'esito della chiamata. Questo valore verrà inserito al termine della chiamata.
• city_id – Un riferimento alla city dizionario, che indica la città in cui è stata effettuata la chiamata. Potrebbe anche essere NULL, poiché queste informazioni potrebbero essere sconosciute o non necessarie.
• call_start_time – Indica quando è iniziata la chiamata. Può essere NULL in alcuni casi speciali, ad es. l'operatore ha sentito squillare la linea, ma la chiamata non è mai stata effettivamente stabilita.
• call_end_time – Quando la chiamata è terminata. Questo valore verrà aggiornato al momento effettivo del termine della chiamata. Conterrà un valore NULL se la chiamata non è mai stata effettivamente avviata o se la chiamata è iniziata ma è ancora in corso.
• notes – Tutte le note, in formato testuale libero, che l'operatore ha inserito in merito a questa chiamata.

Azioni e servizi

Dopo aver effettuato una chiamata, è tempo di agire. Queste azioni dovrebbero allertare automaticamente i servizi di emergenza richiesti; dovremmo anche essere in grado di inserire o rimuovere avvisi secondo necessità.

Per coprire questo, useremo altre cinque tabelle.

Nel emergency_service tabella, memorizzeremo un elenco di tutti i servizi di emergenza disponibili. Questa tabella contiene un service_name UNICO e tutte le informazioni necessarie per stabilire un contatto. Le informazioni di contatto sono archiviate in un formato strutturato simile a JSON in contact_details attributo. Alcuni dei servizi di emergenza previsti sono "polizia", ​​"vigili del fuoco" e "ambulanza". Tuttavia, potremmo averne anche altri, come “soccorso alpino”, “guardia civile”, ecc.

Il action_catalog dizionario contiene un elenco di tutte le possibili azioni che potrebbero essere richieste a seguito di una chiamata. Questa tabella contiene un elenco di tali action_name UNIQUE valori. Alcuni valori previsti qui sono "avvisa tutti i servizi", "avvisa ambulanza", ecc.

Ora dobbiamo definire un elenco di tutti gli avvisi che dovrebbero verificarsi automaticamente quando un'azione viene assegnata a una chiamata. Questi valori sono memorizzati nel alert_service tavolo. Conserveremo la coppia UNICA action_catalog_id – emergency_service_id , indicando che un determinato servizio di emergenza deve essere contattato quando viene assegnata questa azione. Tuttavia, a volte potremmo voler rivedere questo, quindi lascerò un'opzione per farlo. Se il flag always_alert è impostato su True, invieremo questo avviso senza supervisione manuale; in caso contrario, l'operatore può intervenire.

L'assegnazione di un'azione a una chiamata avviene tramite action_required tavolo. Potrebbe essere necessario avere più di un'azione per ogni chiamata, quindi abbiamo bisogno di questa tabella. Conserveremo la combinazione UNICA call_id – action_id nonché le eventuali note inserite dall'operatore.

L'ultima tabella nel nostro modello è il alert_service tavolo. Coppie UNICHE di action_required_id – emergency_service_id denotano gli avvisi effettivi che sono stati avviati per quell'azione (e chiamata). Questi saranno tutti i record con alert_service.always_alert impostato su Vero e tutti gli avvisi impostati manualmente dopo che l'operatore li ha rivisti.

Possibili miglioramenti

Questo modello è solo la spina dorsale di una possibile soluzione. Personalmente posso suggerire molti miglioramenti:

• Come vengono archiviati i dati degli operatori.
• Compresa la possibilità di tenere traccia di ciò che è accaduto dopo che i servizi di emergenza sono stati allertati.
• Consentire a un operatore di avviare una chiamata.
• Eventi correlati nel database in modo da poter definire se una determinata chiamata era correlata a un'altra chiamata, azione o avviso. Al momento, conosciamo solo il loro ordine.

Come funzionano questi servizi nel tuo paese? Ci siamo persi qualcosa? Cosa aggiungeresti o rimuoveresti da questo modello? Per favore, dicci nei commenti qui sotto.