Het bellen van een alarmnummer zoals 911 of 112 is niet iets waar we naar uitkijken, maar we zijn blij dat we het hebben wanneer we het nodig hebben! Aan de andere kant van de lijn is het een stressvolle baan en is er weinig ruimte voor fouten. Alles moet perfect werken.
Vandaag bekijken we het datamodel dat een hulpdienst zou kunnen gebruiken om inkomende oproepen te verwerken en erop te reageren.
Idee
Alarmnummers verschillen van land tot land. De nummers 911 (Noord-Amerika en enkele andere landen) en 112 (Europa en delen van Afrika en Azië) worden veel gebruikt. Deze nummers worden gebruikt om in één keer contact op te nemen met alle drie de hulpdiensten (politie, ambulance en brandweer). Sommige landen gebruiken een ander nummer; anderen hebben geen centraal alarmnummer. In dit model zal ik me concentreren op situaties waarin zo'n gecentraliseerd nummer bestaat.
Het belangrijkste idee is dat wanneer iemand belt, een telefoniste die oproep afhandelt, alle relevante informatie verzamelt en deze informatie doorstuurt naar de verantwoordelijken. Een voorbeeld is een auto-ongeluk:na ontvangst van de oproep moet de telefoniste weten waar dat ongeval is gebeurd en hoe ernstig het is. Ze kunnen dan de politie en een ambulance sturen om de situatie af te handelen. Een ander voorbeeld kan een brand zijn in een flatgebouw, waarvoor alle drie de hulpdiensten nodig zijn.
Gegevensmodel
Het datamodel bestaat uit drie vakgebieden:
Countries & citiesCallsActions & services
We zullen elk van deze onderwerpgebieden beschrijven in de volgorde waarin ze worden vermeld.
Landen en steden
Dit onderwerp is niet specifiek voor dit model, maar het is nog steeds nodig om de locaties te volgen waar de oproepen vandaan kwamen.
We hebben slechts twee tabellen in dit onderwerpgebied. Het country tabel bevat een lijst van UNIEKE country_name waarden. We kunnen verwachten dat we hier maar één land hebben, omdat hulpdiensten vooral op nationaal niveau functioneren. In een groter land kan deze tabel worden gebruikt om namen van staten of provincies op te slaan.
Een lijst van alle steden en dorpen wordt opgeslagen in de city woordenboek. Voor elke stad slaan we een UNIEKE combinatie op van country_id - city_name . We kunnen verwachten dat deze tabel een lijst zal bevatten van alle steden en dorpen in een bepaald land.
Oproepen
Er zijn twee onderwerpen die specifiek zijn voor dit datamodel:Calls en Actions & services . In de loop van de tijd komen oproepen op de eerste plaats en activeren ze andere gebeurtenissen. Daarom zullen we dit gedeelte eerst beschrijven.
De Calls onderwerpgebied bestaat uit vijf tabellen. Terwijl de call tabel is uiteraard de centrale, we zullen eerst de andere vier tabellen beschrijven omdat er allemaal naar wordt verwezen in de oproeptabel.
Gebruikers bellen met hun vaste of mobiele telefoon. We moeten elk nummer opslaan dat 112 of 911 heeft gebeld, dus we hebben een phone_number tafel. Elke keer dat er een nieuwe oproep wordt gestart, controleren we of het nummer al bestaat in deze tabel. Zo niet, dan voegen we een nieuwe rij in. Voor elk tafelrecord slaan we op:
phone_number– Het nummer dat een oproep heeft gestart.number_status_id– Een verwijzing naar denumber_statuswoordenboek. Deze waarde geeft aan of het nummer dat het "eerste contact" heeft gemaakt, op de "zwarte lijst" of "geblokkeerd" staat, enz. Deze waarde kan ons helpen te beslissen wat te doen, b.v. om geen nieuwe oproep te maken als een nummer is geblokkeerd, een waarschuwing te geven als een nummer op de zwarte lijst staat, of gewoon informatie voor de telefoniste op te nemen.notes– Alle notities met betrekking tot dat nummer, ingevoegd door een operator. Dit is geen verplicht veld en zal meestal NULL-waarden bevatten.
De operator tabel wordt gebruikt om een lijst op te slaan van alle operators die oproepen ontvangen. Voor elke operator slaan we een UNIEKE operator_code op (een interne aanduiding), de first_name van de operator , en hun last_name . We slaan hier geen details op, zoals contactgegevens van operators of een vlag die aangeeft of de operator momenteel bezet is of niet.
Aan elke oproep willen we een bepaalde status toekennen. Om dat te doen, hebben we eerst een call_status woordenboek. Dit woordenboek bevat een set UNIEKE status_name waarden. Enkele verwachte waarden zijn:"oproep onderbroken", "oproep verbroken", "geslaagde oproep" en "oproep omgeleid".
Nu zijn we klaar om de call tafel. Een oproep wordt gestart door de beller. Nadat het nummer in de database is ingevoegd (als het een voorheen onbekend nummer is), wordt de oproep ook ingevoegd. Voor elke oproep moeten we opslaan:
operator_id– Een verwijzing naar deoperatordie deze oproep heeft ontvangen.phone_number_id– Het nummer dat de oproep heeft gedaan. In bijna alle gevallen bevat dit kenmerk een waarde die verwijst naar hetphone_numbertafel. Toch liet ik een optie om een oproep zonder telefoonnummer in te voegen. Dit kan gebeuren als een nummer verborgen is of als er een netwerkfout is.call_status_id– Een verwijzing naar decall_statuswoordenboek dat de uitkomst van de oproep beschrijft. Deze waarde wordt aan het einde van het gesprek ingevoegd.city_id– Een verwijzing naar decitywoordenboek, dat de stad aangeeft waar de oproep is gedaan. Dit kan ook NULL zijn, omdat deze informatie onbekend of onnodig kan zijn.call_start_time– Geeft aan wanneer het gesprek is gestart. Het kan in sommige speciale gevallen NULL zijn, b.v. de telefoniste hoorde de lijn overgaan, maar de oproep werd nooit echt tot stand gebracht.call_end_time– Wanneer het gesprek is beëindigd. Deze waarde wordt bijgewerkt op het moment dat het gesprek wordt beëindigd. Het bevat een NULL-waarde als het gesprek nooit daadwerkelijk is gestart, of als het gesprek is gestart maar nog steeds bezig is.notes– Alle notities, in vrije tekstvorm, die de telefoniste heeft ingevoegd met betrekking tot deze oproep.
Acties en services
Nadat een oproep is gedaan, is het tijd voor actie. Deze acties moeten automatisch de benodigde hulpdiensten alarmeren; we zouden ook in staat moeten zijn om waarschuwingen in te voegen of te verwijderen als dat nodig is.
Om dit te dekken, gebruiken we nog vijf tabellen.
In de emergency_service tabel, slaan we een lijst op van alle beschikbare hulpdiensten. Deze tabel bevat een UNIEKE service_name en alle informatie die nodig is om een contact tot stand te brengen. Contactgegevens worden opgeslagen in een gestructureerd JSON-achtig formaat in de contact_details attribuut. Sommige van de verwachte hulpdiensten zijn "politie", "brandweer" en "ambulance". Toch zouden we ook anderen kunnen hebben, zoals "bergredding", "civiele garde", enz.
De action_catalog woordenboek bevat een lijst met alle mogelijke acties die nodig kunnen zijn als gevolg van een oproep. Deze tabel bevat een lijst van dergelijke UNIEKE action_name waarden. Enkele verwachte waarden hier zijn "alle diensten waarschuwen", "ambulance waarschuwen", enz.
Nu moeten we een lijst definiëren met alle waarschuwingen die automatisch moeten optreden wanneer een actie aan een oproep wordt toegewezen. Deze waarden worden opgeslagen in de alert_service tafel. We bewaren het UNIEKE paar action_catalog_id – emergency_service_id , wat aangeeft dat er contact moet worden opgenomen met een bepaalde hulpdienst wanneer deze actie wordt toegewezen. Toch willen we dit soms misschien herzien, dus ik laat een optie om dat te doen. Als de vlag always_alert is ingesteld op True, sturen we deze waarschuwing zonder handmatig toezicht; anders kan de operator ingrijpen.
Het toewijzen van een actie aan een oproep gaat via de action_required tafel. We hebben mogelijk meer dan één actie nodig voor elke aanroep, dus we hebben deze tabel nodig. We slaan de UNIEKE combinatie call_id op – action_id evenals de eventuele opmerkingen die door de operator zijn ingevoegd.
De laatste tabel in ons model is de alerted_service tafel. UNIEKE paren van action_required_id – emergency_service_id geven de daadwerkelijke waarschuwingen aan die zijn geïnitieerd voor die actie (en oproep). Dit zijn alle records met de alert_service.always_alert ingesteld op True en alle waarschuwingen handmatig ingesteld nadat de operator ze heeft herzien.
Mogelijke verbeteringen
Dit model is slechts de ruggengraat van een mogelijke oplossing. Ik kan persoonlijk veel verbeteringen voorstellen:
- Hoe gegevens van operators worden opgeslagen.
- Inclusief de mogelijkheid om te volgen wat er gebeurde nadat de hulpdiensten waren gewaarschuwd.
- Een telefoniste een oproep laten starten.
- Gebeurtenissen in de database relateren zodat we konden bepalen of een bepaalde oproep gerelateerd was aan een andere oproep, actie of waarschuwing. Op dit moment kennen we alleen hun bestelling.
Hoe werken dergelijke diensten in uw land? Hebben we iets gemist? Wat zou je toevoegen of verwijderen uit dit model? Vertel het ons in de reacties hieronder.