911/112:Datový model služby tísňového volání

Volání na tísňové číslo, jako je 911 nebo 112, není něco, na co se těšíme, ale jsme rádi, že ho máme, když ho potřebujeme! Na druhé straně je to stresující práce a je zde malý prostor pro chyby. Vše musí perfektně fungovat.

Dnes se podíváme na datový model, který by tísňová služba mohla použít ke zpracování a reakci na příchozí hovory.

Nápad

Tísňová čísla se v jednotlivých zemích liší. Čísla 911 (Severní Amerika a některé další země) a 112 (Evropa a části Afriky a Asie) jsou široce používána. Tato čísla se používají ke spojení všech tří záchranných služeb (policie, ambulance a hasiči) v rámci jednoho hovoru. Některé země používají jiné číslo; ostatní nemají centralizované tísňové číslo. V tomto modelu se zaměřím na situace, kdy takové centralizované číslo existuje.

Hlavní myšlenkou je, že když někdo zavolá, operátor se o tento hovor postará, shromáždí všechny relevantní informace a předá je odpovědným osobám. Jedním z příkladů může být autonehoda:po přijetí hovoru by měl operátor vědět, kde k nehodě došlo a jak vážná je. Na řešení situace pak mohou poslat policii a záchranku. Dalším příkladem může být požár v bytovém domě, který by mohl vyžadovat všechny tři záchranné služby.

Datový model

Datový model se skládá ze tří tematických oblastí:

• Countries & cities
• Calls
• Actions & services

Každou z těchto oblastí popíšeme v pořadí, v jakém jsou uvedeny.

Země a města

Tato předmětná oblast není specifická pro tento model, ale stále je potřeba ke sledování míst, odkud hovory přicházely.

V této oblasti máme pouze dvě tabulky. country tabulka obsahuje seznam UNIKÁTNÍCH country_name hodnoty. Můžeme očekávat, že zde budeme mít pouze jednu zemi, protože pohotovostní služby většinou fungují na národní úrovni. Ve větší zemi lze tuto tabulku použít k uložení názvů států nebo provincií.

Seznam všech měst a vesnic je uložen v city slovník. Pro každé město uložíme UNIKÁTNÍ kombinaci country_id - city_name . Můžeme očekávat, že tato tabulka bude obsahovat seznam všech měst a vesnic v určité zemi.

Volání

Existují dvě předmětové oblasti, které jsou specifické pro tento datový model:Calls a Actions & services . V proudu času jsou hovory na prvním místě a spouštějí další události. Proto nejprve popíšeme tuto sekci.

Calls obor se skládá z pěti tabulek. Během call tabulka je samozřejmě centrální, nejprve popíšeme ostatní čtyři tabulky, protože na všechny se odkazuje v tabulce volání.

Uživatelé zahajují hovory pomocí pevné linky nebo mobilních telefonů. Potřebujeme uložit každé číslo, které volalo 112 nebo 911, takže budeme potřebovat phone_number stůl. Pokaždé, když je zahájen nový hovor, zkontrolujeme, zda již číslo v této tabulce existuje. Pokud ne, vložíme nový řádek. Pro každý záznam tabulky uložíme:

• phone_number – Číslo, které zahájilo hovor.
• number_status_id – Odkaz na number_status slovník. Tato hodnota udává, zda je číslo uskutečněné jako „první kontakt“, „na černé listině“ nebo „blokováno“ atd. Tato hodnota by nám mohla pomoci při rozhodování, co dělat, např. nevytvářet nový hovor, pokud je číslo blokováno, nevyvolávat varování, pokud je číslo na černé listině, nebo jednoduše zaznamenávat informace pro operátora.
• notes – Všechny poznámky týkající se tohoto čísla vložené jakýmkoli operátorem. Toto pole není povinné a bude většinou obsahovat hodnoty NULL.

operator tabulka slouží k uložení seznamu všech operátorů, kteří přijímají hovory. Pro každého operátora uložíme UNIKÁTNÍ operator_code (interní označení), first_name operátora a jejich last_name . Nebudeme zde ukládat podrobnosti, jako jsou kontaktní údaje operátora nebo vlajka označující, zda je operátor aktuálně zaneprázdněn, nebo ne.

Každému hovoru chceme přiřadit určitý stav. K tomu potřebujeme nejprve call_status slovník. Tento slovník obsahuje sadu UNIKÁTNÍCH status_name hodnoty. Některé očekávané hodnoty jsou:„hovor přerušen“, „hovor přerušen“, „úspěšný hovor“ a „hovor přesměrován“.

Nyní jsme připraveni popsat call stůl. Hovor zahájí volající. Po vložení čísla do databáze (pokud se jedná o dříve neznámé číslo) se vloží i hovor. Pro každý hovor budeme muset uložit:

• operator_id – Odkaz na operator která přijala tento hovor.
• phone_number_id – Číslo, které provedlo hovor. Téměř ve všech případech bude tento atribut obsahovat hodnotu odkazující na phone_number stůl. Přesto jsem nechal možnost vložit hovor bez telefonního čísla. K tomu může dojít, když je číslo skryté, nebo když dojde k nějaké chybě sítě.
• call_status_id – Odkaz na call_status slovník, který popisuje výsledek volání. Tato hodnota bude vložena na konci hovoru.
• city_id – Odkaz na city slovník, označující město, kde byl hovor uskutečněn. Toto může být také NULL, protože tyto informace mohou být neznámé nebo nepotřebné.
• call_start_time – Označuje, kdy hovor začal. V některých speciálních případech může být NULL, např. operátor slyšel zvonění linky, ale hovor nebyl ve skutečnosti nikdy navázán.
• call_end_time – Když hovor skončil. Tato hodnota bude aktualizována ve skutečném čase ukončení hovoru. Bude obsahovat hodnotu NULL, pokud hovor ve skutečnosti nikdy nezačal nebo pokud hovor začal, ale stále probíhá.
• notes – Všechny poznámky ve volném textovém formátu, které operátor vložil k tomuto hovoru.

Akce a služby

Po uskutečnění hovoru je čas jednat. Tyto akce by měly automaticky upozornit požadované pohotovostní služby; měli bychom být také schopni vkládat nebo odstraňovat upozornění podle potřeby.

Abychom to pokryli, použijeme dalších pět tabulek.

V emergency_service tabulky, uložíme seznam všech dostupných pohotovostních služeb. Tato tabulka obsahuje UNIKÁTNÍ service_name a veškeré informace potřebné k navázání kontaktu. Kontaktní informace jsou uloženy ve strukturovaném formátu JSON v contact_details atribut. Některé z očekávaných pohotovostních služeb jsou „policie“, „hasiči“ a „záchranka“. Přesto bychom mohli mít i další, jako je „horská záchrana“, „civilní stráž“ atd.

action_catalog slovník obsahuje seznam všech možných akcí, které mohou být vyžadovány v důsledku volání. Tato tabulka obsahuje seznam takových UNIKÁTNÍCH action_name hodnoty. Některé očekávané hodnoty jsou zde „alert all services“, „alert ambulance“ atd.

Nyní musíme definovat seznam všech upozornění, která by se měla automaticky objevit, když je k hovoru přiřazena akce. Tyto hodnoty jsou uloženy ve službě alert_service stůl. Uložíme UNIKÁTNÍ pár action_catalog_id – emergency_service_id , označující, že při přidělení této akce je třeba kontaktovat určitou pohotovostní službu. Přesto to někdy můžeme chtít revidovat, takže nechám možnost to udělat. Pokud je příznak always_alert je nastaveno na True, toto upozornění odešleme bez ručního dohledu; jinak může zasáhnout operátor.

Přiřazení akce k volání se provádí pomocí action_required stůl. Možná budeme muset mít více než jednu akci pro každé volání, takže potřebujeme tuto tabulku. Uložíme UNIKÁTNÍ kombinaci call_id – action_id stejně jako případné poznámky vložené operátorem.

Poslední tabulkou v našem modelu je alerted_service stůl. UNIKÁTNÍ páry action_required_id – emergency_service_id označují aktuální výstrahy, které byly pro danou akci (a volání) spuštěny. Budou to všechny záznamy s alert_service.always_alert nastavte na True a všechna upozornění se nastaví ručně poté, co je operátor revidoval.

Možná vylepšení

Tento model je pouze páteří jednoho možného řešení. Osobně mohu navrhnout mnoho vylepšení:

• Jak jsou uložena data operátorů.
• Včetně možnosti sledovat, co se stalo poté, co byly pohotovostní služby upozorněny.
• Nechat operátorovi zahájit hovor.
• Vztahování událostí v databázi, abychom mohli definovat, zda určitý hovor souvisel s jiným hovorem, akcí nebo výstrahou. V tuto chvíli známe pouze jejich pořadí.

Jak takové služby u vás fungují? Něco nám uniklo? Co byste přidali nebo odstranili z tohoto modelu? Řekněte nám to prosím v komentářích níže.