Wywołanie numeru alarmowego, takiego jak 911 lub 112, nie jest czymś, na co czekamy, ale cieszymy się, że możemy go mieć, gdy go potrzebujemy! Po drugiej stronie jest to stresująca praca i nie ma miejsca na błędy. Wszystko musi działać idealnie.
Dzisiaj przyjrzymy się modelowi danych, z którego służby ratunkowe mogą korzystać do przetwarzania i odpowiadania na połączenia przychodzące.
Pomysł
Numery alarmowe różnią się w zależności od kraju. Liczby 911 (Ameryka Północna i kilka innych krajów) i 112 (Europa oraz część Afryki i Azji) są powszechnie używane. Numery te służą do skontaktowania się ze wszystkimi trzema służbami ratunkowymi (policją, pogotowiem ratunkowym oraz strażą pożarną i ratownictwem) w ramach jednego połączenia. Niektóre kraje używają innego numeru; inni nie mają scentralizowanego numeru alarmowego. W tym modelu skupię się na sytuacjach, w których istnieje taka scentralizowana liczba.
Główną ideą jest to, że gdy ktoś wykonuje połączenie, operator zajmuje się tym połączeniem, zbiera wszystkie istotne informacje i przekazuje je osobom odpowiedzialnym. Jednym z przykładów może być wypadek samochodowy:po odebraniu połączenia operator powinien wiedzieć, gdzie ten wypadek się wydarzył i jak poważny jest. Następnie mogą wysłać policję i karetkę pogotowia, aby zajęły się sytuacją. Innym przykładem może być pożar w budynku mieszkalnym, który może wymagać wszystkich trzech służb ratunkowych.
Model danych
Model danych składa się z trzech obszarów tematycznych:
Countries & citiesCallsActions & services
Opiszemy każdy z tych obszarów tematycznych w kolejności, w jakiej są wymienione.
Kraje i miasta
Ten obszar tematyczny nie jest specyficzny dla tego modelu, ale nadal jest potrzebny do śledzenia lokalizacji, z których nadeszły połączenia.
W tej dziedzinie mamy tylko dwie tabele. country tabela zawiera listę UNIKATOWYCH country_name wartości. Możemy się spodziewać, że będziemy mieli tu tylko jeden kraj, ponieważ służby ratunkowe działają głównie na poziomie krajowym. W większym kraju ta tabela może służyć do przechowywania nazw stanów lub prowincji.
Lista wszystkich miast i wiosek jest przechowywana w city słownik. Dla każdego miasta będziemy przechowywać UNIKALNĄ kombinację country_id - city_name . Możemy się spodziewać, że ta tabela będzie zawierać listę wszystkich miast i wsi w danym kraju.
Połączenia
Istnieją dwa obszary tematyczne, które są specyficzne dla tego modelu danych:Calls oraz Actions & services . W strumieniu czasu telefony przychodzą pierwsze i wywołują inne zdarzenia. Dlatego najpierw opiszemy tę sekcję.
Calls obszar tematyczny składa się z pięciu tabel. Podczas call tabela jest oczywiście centralną, najpierw opiszemy pozostałe cztery tabele, ponieważ wszystkie są przywoływane w tabeli wywołań.
Użytkownicy inicjują połączenia za pomocą telefonów stacjonarnych lub komórkowych. Musimy zapisać każdy numer, który dzwonił 112 lub 911, więc będziemy potrzebować phone_number stół. Za każdym razem, gdy inicjowane jest nowe połączenie, sprawdzamy, czy numer już istnieje w tej tabeli. Jeśli nie, wstawimy nowy wiersz. Dla każdego rekordu tabeli przechowujemy:
phone_number– Numer, który zainicjował połączenie.number_status_id– Odniesienie donumber_statussłownik. Wartość ta będzie oznaczać, czy numer nawiązujący „pierwszy kontakt”, jest „na czarnej liście” czy „zablokowany” itp. Ta wartość może nam pomóc w podjęciu decyzji, np. co zrobić. nie tworzyć nowego połączenia, jeśli numer jest zablokowany, rzucać ostrzeżenie, jeśli numer jest na czarnej liście, lub po prostu rejestrować informacje dla operatora.notes– Wszystkie notatki związane z tym numerem, wstawione przez dowolnego operatora. To nie jest wymagane pole i będzie zawierało głównie wartości NULL.
operator tabela służy do przechowywania listy wszystkich operatorów odbierających połączenia. Dla każdego operatora będziemy przechowywać UNIKALNY operator_code (oznaczenie wewnętrzne), first_name operatora i ich last_name . Nie będziemy tutaj przechowywać szczegółów, takich jak dane kontaktowe operatora lub flaga wskazująca, czy operator jest obecnie zajęty, czy nie.
Każdemu połączeniu chcemy przypisać określony status. Aby to zrobić, najpierw potrzebujemy call_status słownik. Ten słownik zawiera zestaw UNIKALNYCH status_name wartości. Niektóre oczekiwane wartości to:„połączenie przerwane”, „połączenie odrzucone”, „połączenie udane” i „połączenie przekierowane”.
Teraz jesteśmy gotowi do opisania call stół. Połączenie jest inicjowane przez dzwoniącego. Po wpisaniu numeru do bazy danych (jeśli jest to numer wcześniej nieznany) wprowadzane jest również połączenie. Dla każdego połączenia musimy zapisać:
operator_id– Odniesienie dooperatorktóry otrzymał to wezwanie.phone_number_id– Numer, z którego wykonano połączenie. W prawie wszystkich przypadkach ten atrybut będzie zawierał wartość odwołującą się dophone_numberstół. Mimo to zostawiłem opcję wstawienia połączenia bez numeru telefonu. Może się to zdarzyć, gdy liczba jest ukryta lub występuje jakiś błąd sieci.call_status_id– Odniesienie docall_statussłownik opisujący wynik połączenia. Ta wartość zostanie wstawiona na końcu połączenia.city_id– Odniesienie docitysłownik, oznaczający miasto, z którego wykonano połączenie. Może to być również NULL, ponieważ te informacje mogą być nieznane lub niepotrzebne.call_start_time– Wskazuje, kiedy rozpoczęło się połączenie. Może być NULL w niektórych szczególnych przypadkach, np. operator usłyszał dzwonek linii, ale połączenie nigdy nie zostało nawiązane.call_end_time– Kiedy rozmowa się zakończyła. Ta wartość zostanie zaktualizowana w momencie zakończenia połączenia. Będzie zawierać wartość NULL, jeśli połączenie nigdy się nie rozpoczęło lub jeśli połączenie rozpoczęło się, ale nadal trwa.notes– Wszystkie notatki w dowolnym formacie tekstowym, które operator wstawił w związku z tym połączeniem.
Działania i usługi
Po wykonaniu połączenia nadszedł czas na działanie. Działania te powinny automatycznie zaalarmować wymagane służby ratunkowe; powinniśmy również być w stanie w razie potrzeby wstawiać lub usuwać alerty.
Aby to omówić, użyjemy jeszcze pięciu tabel.
W emergency_service tabeli, przechowamy listę wszystkich dostępnych służb ratunkowych. Ta tabela zawiera UNIKALNĄ service_name oraz wszelkie informacje potrzebne do nawiązania kontaktu. Informacje kontaktowe są przechowywane w ustrukturyzowanym formacie JSON w contact_details atrybut. Niektóre z oczekiwanych służb ratunkowych to „policja”, „straż pożarna” i „pogotowie ratunkowe”. Mimo to moglibyśmy mieć też inne, takie jak „ratownictwo górskie”, „straż cywilna” itp.
action_catalog słownik zawiera listę wszystkich możliwych działań, które mogą być wymagane w wyniku połączenia. Ta tabela zawiera listę takich UNIKALNYCH action_name wartości. Niektóre oczekiwane wartości to „alert all services”, „alarm ambulance” itp.
Teraz musimy zdefiniować listę wszystkich alertów, które powinny wystąpić automatycznie, gdy akcja zostanie przypisana do połączenia. Te wartości są przechowywane w alert_service stół. Przechowamy UNIKALNĄ parę action_catalog_id – emergency_service_id , co oznacza, że po przypisaniu tej akcji należy skontaktować się z określoną służbą ratunkową. Mimo to czasami możemy chcieć to zmienić, więc zostawię opcję, aby to zrobić. Jeśli flaga always_alert jest ustawiona na True, wyślemy ten alert bez ręcznego nadzoru; w przeciwnym razie operator może interweniować.
Przypisanie akcji do połączenia odbywa się za pomocą action_required stół. Możemy potrzebować więcej niż jednej akcji dla każdego wywołania, więc potrzebujemy tej tabeli. Przechowamy UNIKALNĄ kombinację call_id – action_id jak również notatki, jeśli są, wstawione przez operatora.
Ostatnia tabela w naszym modelu to alerted_service stół. UNIKALNE pary action_required_id – emergency_service_id oznaczają rzeczywiste alerty, które zostały zainicjowane dla tej akcji (i połączenia). Będą to wszystkie rekordy z alert_service.always_alert ustawione na Prawda, a wszystkie alerty ustawione ręcznie po ich poprawieniu przez operatora.
Możliwe ulepszenia
Ten model to tylko podstawa jednego z możliwych rozwiązań. Mogę osobiście zaproponować wiele ulepszeń:
- Jak przechowywane są dane operatorów.
- W tym możliwość śledzenia, co się stało po powiadomieniu służb ratunkowych.
- Pozwól operatorowi na nawiązanie połączenia.
- Powiązanie zdarzeń w bazie danych, dzięki czemu możemy określić, czy dane połączenie było powiązane z innym połączeniem, działaniem lub alertem. W tej chwili znamy tylko ich kolejność.
Jak takie usługi działają w Twoim kraju? Czy coś przegapiliśmy? Co byś dodał lub usunął z tego modelu? Powiedz nam w komentarzach poniżej.
