sql >> Database teknologi >  >> RDS >> Database

911/112:En nødopkaldstjenestedatamodel

At ringe til et nødopkaldsnummer som 911 eller 112 er ikke noget, vi ser frem til, men vi er glade for at have det, når vi har brug for det! I den anden ende af stregen er det et stressende job, og der er lidt plads til fejl. Alt skal fungere perfekt.

I dag tager vi et kig på den datamodel, som en nødtjeneste kan bruge til at behandle og besvare indgående opkald.

Idé

Nødnumre varierer fra land til land. Tallene 911 (Nordamerika og nogle andre lande) og 112 (Europa og dele af Afrika og Asien) er meget brugt. Disse numre bruges til at kontakte alle tre beredskabstjenester (politi, ambulance og brand og redning) i ét opkald. Nogle lande bruger et andet nummer; andre har ikke et centraliseret alarmnummer. I denne model vil jeg fokusere på situationer, hvor et sådant centraliseret nummer eksisterer.

Hovedideen er, at når nogen foretager et opkald, tager en operatør sig af det opkald, indsamler alle relevante oplysninger og videresender disse oplysninger til de ansvarlige. Et eksempel kunne være en bilulykke:efter at have modtaget opkaldet, skal operatøren vide, hvor ulykken skete, og hvor alvorlig den er. De kan så sende politiet og en ambulance til at håndtere situationen. Et andet eksempel kunne være en brand i en lejlighedsbygning, som kunne kræve alle tre beredskabstjenester.

Datamodel

Datamodellen består af tre emneområder:

  • Countries & cities
  • Calls
  • Actions & services

Vi vil beskrive hvert af disse emneområder i den rækkefølge, de er anført.

Lande og byer

Dette emneområde er ikke specifikt for denne model, men det er stadig nødvendigt for at spore de steder, hvor opkald kom fra.

Vi har kun to tabeller inden for dette emneområde. country tabel indeholder en liste over UNIQUE country_name værdier. Vi kan forvente, at vi kun vil have ét land her, fordi beredskabstjenester for det meste fungerer på nationalt plan. I et større land kan denne tabel bruges til at gemme stat- eller provinsnavne.

En liste over alle byer og landsbyer er gemt i city ordbog. For hver by gemmer vi en UNIK kombination af country_id - city_name . Vi kan forvente, at denne tabel vil indeholde en liste over alle byer og landsbyer i et bestemt land.

Opkald

Der er to emneområder, som er specifikke for denne datamodel:Calls og Actions & services . I tidens strøm kommer opkald først og udløser andre begivenheder. Derfor vil vi først beskrive dette afsnit.

Calls Fagområdet er sammensat af fem tabeller. Mens call tabellen er åbenbart den centrale, vi vil først beskrive de andre fire tabeller, fordi de alle er refereret til i opkaldstabellen.

Brugere starter opkald ved hjælp af deres fastnet- eller mobiltelefoner. Vi skal gemme hvert nummer, der ringede til 112 eller 911, så vi skal bruge et phone_number bord. Hver gang et nyt opkald påbegyndes, kontrollerer vi, om nummeret allerede findes i denne tabel. Hvis ikke, indsætter vi en ny række. For hver tabelpost gemmer vi:

  • phone_number – Det nummer, der startede et opkald.
  • number_status_id – En reference til number_status ordbog. Denne værdi skal angive, om nummeret, der blev gjort til den "første kontakt", er "sortlistet" eller "blokeret" osv. Denne værdi kan hjælpe os med at beslutte, hvad vi skal gøre, f.eks. ikke at oprette et nyt opkald, hvis et nummer er blokeret, smide en advarsel ud, hvis et nummer er sortlistet, eller blot optage info til operatøren.
  • notes – Alle noter relateret til dette nummer, indsat af enhver operatør. Dette er ikke et obligatorisk felt og vil for det meste indeholde NULL-værdier.

operator tabel bruges til at gemme en liste over alle operatører, der modtager opkald. For hver operatør gemmer vi en UNIK operator_code (en intern betegnelse), operatørens first_name , og deres last_name . Vi gemmer ikke detaljer her, såsom operatørers kontaktoplysninger eller et flag, der angiver, om operatøren i øjeblikket er optaget eller ej.

For hvert opkald ønsker vi at tildele en bestemt status. For at gøre det skal vi først bruge en call_status ordbog. Denne ordbog indeholder et sæt UNIQUE status_name værdier. Nogle forventede værdier er:"opkald afbrudt", "opkald afbrudt", "vellykket opkald" og "opkald omdirigeret".

Nu er vi klar til at beskrive call bord. Et opkald påbegyndes af den, der ringer op. Efter nummeret er indsat i databasen (hvis det er et hidtil ukendt nummer), er opkaldet også indsat. For hvert opkald skal vi gemme:

  • operator_id – En reference til operator der modtog dette opkald.
  • phone_number_id – Nummeret, der foretog opkaldet. I næsten alle tilfælde vil denne attribut indeholde en værdi, der refererer til phone_number bord. Alligevel forlod jeg en mulighed for at indsætte et opkald uden et telefonnummer. Dette kan ske, når et nummer er skjult, eller hvis der er en form for netværksfejl.
  • call_status_id – En reference til call_status ordbog, der beskriver opkaldsresultatet. Denne værdi vil blive indsat i slutningen af ​​opkaldet.
  • city_id – En reference til city ordbog, der angiver den by, hvor opkaldet blev foretaget. Dette kan også være NULL, da disse oplysninger kan være ukendte eller unødvendige.
  • call_start_time – Angiver, hvornår opkaldet startede. Den kan være NULL i nogle særlige tilfælde, f.eks. operatøren hørte linjen ringe, men opkaldet blev faktisk aldrig etableret.
  • call_end_time – Når opkaldet sluttede. Denne værdi vil blive opdateret på det faktiske tidspunkt, hvor opkaldet slutter. Den vil indeholde en NULL-værdi, hvis opkaldet faktisk aldrig startede, eller hvis opkaldet startede, men stadig er i gang.
  • notes – Alle noter, i frit tekstformat, som operatøren har indsat vedrørende dette opkald.

Handlinger og tjenester

Når et opkald er foretaget, er det tid til handling. Disse handlinger bør automatisk alarmere nødvendige nødtjenester; vi bør også være i stand til at indsætte eller fjerne advarsler efter behov.

For at dække dette bruger vi fem tabeller mere.

I emergency_service tabel, gemmer vi en liste over alle tilgængelige nødtjenester. Denne tabel indeholder et UNIKT service_name og alle nødvendige oplysninger for at etablere en kontakt. Kontaktoplysninger gemmes i et struktureret JSON-lignende format i contact_details attribut. Nogle af de forventede beredskaber er "politi", "brandvæsen" og "ambulance". Alligevel kunne vi også have andre, f.eks. "bjergredning", "civilvagt" osv.

action_catalog ordbogen indeholder en liste over alle mulige handlinger, der kan være nødvendige som følge af et opkald. Denne tabel indeholder en liste over sådanne UNIKKE action_name værdier. Nogle forventede værdier her er "alarm alle tjenester", "alarm ambulance" osv.

Nu skal vi definere en liste over alle alarmer, der automatisk skal opstå, når en handling er tildelt et opkald. Disse værdier er gemt i alert_service bord. Vi gemmer det UNIKKE par action_catalog_idemergency_service_id , hvilket angiver, at en bestemt nødtjeneste skal kontaktes, når denne handling er tildelt. Alligevel vil vi nogle gange måske revidere dette, så jeg vil efterlade en mulighed for at gøre det. Hvis flaget always_alert er indstillet til Sand, sender vi denne advarsel uden manuel overvågning; ellers kan operatøren gribe ind.

Tildeling af en handling til et opkald sker via action_required bord. Vi skal muligvis have mere end én handling for hvert opkald, så vi har brug for denne tabel. Vi gemmer den UNIKKE kombination call_idaction_id samt noter, hvis nogen, indsat af operatøren.

Den sidste tabel i vores model er alerted_service bord. UNIKKE par af action_required_idemergency_service_id angive de faktiske alarmer, der blev iværksat for den pågældende handling (og opkald). Disse vil alle være poster med alert_service.always_alert indstillet til Sand, og alle advarsler indstilles manuelt, efter at operatøren har ændret dem.

Mulige forbedringer

Denne model er blot rygraden i én mulig løsning. Jeg kan personligt foreslå mange forbedringer:

  • Hvordan operatørernes data gemmes.
  • Herunder muligheden for at spore, hvad der skete, efter at nødtjenester blev alarmeret.
  • Lad en operatør starte et opkald.
  • Relaterer hændelser i databasen, så vi kunne definere, om et bestemt opkald var relateret til et andet opkald, handling eller alarm. I øjeblikket kender vi kun deres rækkefølge.

Hvordan fungerer sådanne tjenester i dit land? Gik vi glip af noget? Hvad vil du tilføje eller fjerne fra denne model? Fortæl os venligst i kommentarerne nedenfor.


  1. Databasestyring og overvågning for PostgreSQL 12

  2. Sådan ændres en kolonnes datatype i SQL Server (T-SQL)

  3. Deadlocks i PostgreSQL, når du kører UPDATE

  4. Indiske pinkodedatabase med lokationsfinderscript i php og jquery