Обаждането на номер за спешни случаи като 911 или 112 не е нещо, което очакваме с нетърпение, но се радваме, че го имаме, когато имаме нужда! От другата страна на линията това е стресираща работа и има малко място за грешки. Всичко трябва да работи перфектно.
Днес ще разгледаме модела на данни, който службата за спешни случаи може да използва, за да обработва и отговаря на входящи повиквания.
Идея
Номерата за спешни повиквания се различават в различните държави. Числата 911 (Северна Америка и някои други страни) и 112 (Европа и части от Африка и Азия) са широко използвани. Тези номера се използват за връзка с трите служби за спешна помощ (полиция, линейка и пожарна и спасителна служба) с едно обаждане. Някои държави използват различен номер; други нямат централизиран номер за спешни повиквания. В този модел ще се съсредоточа върху ситуации, в които съществува такъв централизиран номер.
Основната идея е, че когато някой се обади, операторът се грижи за това обаждане, събира цялата необходима информация и препраща тази информация на отговорните. Един пример може да се случи автомобилна катастрофа:след като получи обаждането, операторът трябва да знае къде се е случил инцидентът и колко сериозен е той. След това могат да изпратят полиция и линейка, за да се справят със ситуацията. Друг пример може да бъде пожар в жилищна сграда, който може да изисква и трите служби за спешна помощ.
Модел на данни
Моделът на данни се състои от три предметни области:
Countries & citiesCallsActions & services
Ще опишем всяка от тези тематични области в реда, в който са изброени.
Държави и градове
Тази тематична област не е специфична за този модел, но все пак е необходима за проследяване на местоположенията, откъдето идват обажданията.
Имаме само две таблици в тази област. country таблицата съдържа списък с УНИКАЛНИ country_name стойности. Можем да очакваме, че тук ще имаме само една държава, защото службите за спешна помощ работят предимно на национално ниво. В по-голяма държава тази таблица може да се използва за съхраняване на имена на щати или провинции.
Списък с всички градове и села се съхранява в city речник. За всеки град ще съхраняваме УНИКАЛНА комбинация от country_id - city_name . Можем да очакваме, че тази таблица ще съдържа списък на всички градове и села в дадена държава.
Обаждания
Има две предметни области, които са специфични за този модел на данни:Calls и Actions & services . В потока от време обажданията идват първи и предизвикват други събития. Затова първо ще опишем този раздел.
Calls предметната област се състои от пет таблици. Докато call таблицата очевидно е централната, първо ще опишем останалите четири таблици, защото всички те са посочени в таблицата за повиквания.
Потребителите започват разговори, като използват своите стационарни или мобилни телефони. Трябва да съхраняваме всеки номер, който се е обадил на 112 или 911, така че ще ни трябва phone_number маса. Всеки път, когато бъде инициирано ново обаждане, ние ще проверяваме дали номерът вече съществува в тази таблица. Ако не, ще вмъкнем нов ред. За всеки запис на таблица ще съхраняваме:
phone_number– Номерът, който инициира обаждане.number_status_id– Препратка къмnumber_statusречник. Тази стойност ще означава дали номерът, осъществил „първия контакт“, е „в черен списък“ или „блокиран“ и т.н. Тази стойност може да ни помогне да решим какво да правим, напр. да не създавате ново обаждане, ако номер е блокиран, да извеждате предупреждение, ако номерът е в черен списък, или просто да записвате информация за оператора.notes– Всички бележки, свързани с този номер, въведени от всеки оператор. Това не е задължително поле и ще съдържа предимно NULL стойности.
operator таблицата се използва за съхраняване на списък с всички оператори, които получават повиквания. За всеки оператор ще съхраняваме УНИКАЛЕН operator_code (вътрешно обозначение), first_name на оператора и тяхното last_name . Тук няма да съхраняваме подробности, като информация за контакт на оператора или флаг, обозначаващ дали операторът в момента е зает или не.
За всяко обаждане искаме да присвоим определен статус. За да направим това, първо ще ни трябва call_status речник. Този речник съдържа набор от UNIQUE status_name стойности. Някои очаквани стойности са:„обаждането е прекъснато“, „повикването е прекратено“, „успешно обаждане“ и „пренасочено повикване“.
Сега сме готови да опишем call маса. Повикване се инициира от обаждащия се. След като номерът бъде вмъкнат в базата данни (ако е неизвестен преди това номер), повикването също се вмъква. За всяко обаждане ще трябва да съхраняваме:
operator_id– Препратка къмoperatorкойто получи това обаждане.phone_number_id– Номерът, който е извършил обаждането. В почти всички случаи този атрибут ще съдържа стойност, отнасяща се доphone_numberмаса. Все пак оставих опция за вмъкване на обаждане без телефонен номер. Това може да се случи, когато номер е скрит или ако има някаква мрежова грешка.call_status_id– Препратка къмcall_statusречник, който описва резултата от обаждането. Тази стойност ще бъде вмъкната в края на разговора.city_id– Препратка къмcityречник, обозначаващ града, където е направено обаждането. Това също може да е NULL, тъй като тази информация може да е неизвестна или ненужна.call_start_time– Означава кога е започнало повикването. Тя може да бъде NULL в някои специални случаи, напр. операторът е чул звъненето на линията, но повикването така и не е било установено.call_end_time– Когато разговорът приключи. Тази стойност ще бъде актуализирана в момента, в който разговорът приключи. Той ще съдържа стойност NULL, ако повикването никога не е започнало или ако повикването е започнало, но все още е в ход.notes– Всички бележки в свободен текстов формат, въведени от оператора във връзка с това обаждане.
Действия и услуги
След обаждането е време за действие. Тези действия трябва автоматично да предупреждават необходимите служби за спешна помощ; също така трябва да можем да вмъкваме или премахваме сигнали, ако е необходимо.
За да покрием това, ще използваме още пет таблици.
В emergency_service таблица, ще съхраняваме списък с всички налични услуги за спешна помощ. Тази таблица съдържа УНИКАЛНО service_name и всякаква информация, необходима за установяване на контакт. Информацията за контакт се съхранява в структуриран формат, подобен на JSON, в contact_details атрибут. Някои от очакваните служби за спешна помощ са „полиция“, „пожарна служба“ и „линейка“. Все пак бихме могли да имаме и други, като „планински спасители“, „гражданска охрана“ и т.н.
action_catalog речникът съдържа списък с всички възможни действия, които биха могли да се изискват в резултат на повикване. Тази таблица съдържа списък с такива УНИКАЛНИ action_name стойности. Някои очаквани стойности тук са „предупреди всички услуги“, „предупреди линейка“ и т.н.
Сега трябва да дефинираме списък с всички сигнали, които трябва да се появяват автоматично, когато дадено действие е присвоено на повикване. Тези стойности се съхраняват в alert_service маса. Ще съхраняваме УНИКАЛНАТА двойка action_catalog_id – emergency_service_id , което означава, че трябва да се свърже с определена спешна служба, когато е възложено това действие. Все пак понякога може да искаме да преразгледаме това, така че ще оставя опция да го направя. Ако флагът always_alert е зададено на True, ние ще изпратим този сигнал без ръчен надзор; в противен случай операторът може да се намеси.
Присвояването на действие към повикване се извършва чрез action_required маса. Може да се наложи да имаме повече от едно действие за всяко обаждане, така че имаме нужда от тази таблица. Ще съхраним УНИКАЛНАТА комбинация call_id – action_id както и бележките, ако има такива, въведени от оператора.
Последната таблица в нашия модел е alerted_service маса. УНИКАЛНИ двойки action_required_id – emergency_service_id обозначават действителните сигнали, които са били инициирани за това действие (и повикване). Това ще бъдат всички записи с alert_service.always_alert зададете на True и всички сигнали се задават ръчно, след като операторът ги е преразгледал.
Възможни подобрения
Този модел е само гръбнакът на едно възможно решение. Аз лично мога да предложа много подобрения:
- Как се съхраняват данните на операторите.
- Включително възможността за проследяване на случилото се след сигнала на службите за спешна помощ.
- Позволяване на оператор да започне обаждане.
- Свързване на събития в базата данни, за да можем да дефинираме дали определено обаждане е свързано с друго обаждане, действие или предупреждение. В момента знаем само техния ред.
Как работят подобни услуги във вашата страна? Пропуснахме ли нещо? Какво бихте добавили или премахнали от този модел? Моля, кажете ни в коментарите по-долу.
