911/112:एक आपातकालीन कॉल सेवा डेटा मॉडल

911 या 112 जैसे किसी आपातकालीन नंबर पर कॉल करना कोई ऐसी चीज़ नहीं है जिसकी हम प्रतीक्षा कर रहे हैं, लेकिन जब हमें इसकी आवश्यकता होती है, तो हमें खुशी होती है! लाइन के दूसरे छोर पर, यह एक तनावपूर्ण काम है, और गलतियों के लिए बहुत कम जगह है। सब कुछ पूरी तरह से काम करने की जरूरत है।

आज, हम उस डेटा मॉडल पर एक नज़र डालेंगे जिसका उपयोग आपातकालीन सेवा इनकमिंग कॉलों को संसाधित करने और उनका जवाब देने के लिए कर सकती है।

विचार

आपातकालीन नंबर अलग-अलग देशों में अलग-अलग होते हैं। संख्या 911 (उत्तरी अमेरिका और कुछ अन्य देश) और 112 (यूरोप और अफ्रीका और एशिया के कुछ हिस्सों) का व्यापक रूप से उपयोग किया जाता है। इन नंबरों का उपयोग एक कॉल में तीनों आपातकालीन सेवाओं (पुलिस, एम्बुलेंस, और आग और बचाव) से संपर्क करने के लिए किया जाता है। कुछ देश भिन्न संख्या का उपयोग करते हैं; दूसरों के पास केंद्रीकृत आपातकालीन नंबर नहीं है। इस मॉडल में, मैं उन स्थितियों पर ध्यान केंद्रित करूंगा जहां ऐसी केंद्रीकृत संख्या मौजूद है।

मुख्य विचार यह है कि जब कोई कॉल करता है, तो एक ऑपरेटर उस कॉल का ख्याल रखता है, सभी प्रासंगिक जानकारी एकत्र करता है, और यह जानकारी प्रभारी लोगों को अग्रेषित करता है। एक उदाहरण कार दुर्घटना हो सकती है:कॉल प्राप्त करने के बाद, ऑपरेटर को पता होना चाहिए कि वह दुर्घटना कहाँ हुई और यह कितनी गंभीर है। फिर वे स्थिति को संभालने के लिए पुलिस और एक एम्बुलेंस भेज सकते हैं। एक अन्य उदाहरण एक अपार्टमेंट इमारत में आग लग सकती है, जिसके लिए तीनों आपातकालीन सेवाओं की आवश्यकता हो सकती है।

डेटा मॉडल

डेटा मॉडल में तीन विषय क्षेत्र होते हैं:

• Countries & cities
• Calls
• Actions & services

हम इनमें से प्रत्येक विषय क्षेत्र का वर्णन उनके सूचीबद्ध क्रम में करेंगे।

देश और शहर

यह विषय क्षेत्र इस मॉडल के लिए विशिष्ट नहीं है, लेकिन अभी भी उन स्थानों को ट्रैक करने की आवश्यकता है जहां से कॉल आए थे।

इस विषय क्षेत्र में हमारे पास केवल दो टेबल हैं। country तालिका में UNIQUE की एक सूची है country_name मूल्य। हम उम्मीद कर सकते हैं कि हमारे यहां केवल एक ही देश होगा क्योंकि आपातकालीन सेवाएं ज्यादातर राष्ट्रीय स्तर पर काम करती हैं। एक बड़े देश में, इस तालिका का उपयोग राज्य या प्रांत के नामों को संग्रहीत करने के लिए किया जा सकता है।

सभी शहरों और गांवों की सूची city शब्दकोश। प्रत्येक शहर के लिए, हम country_id . का एक अद्वितीय संयोजन संग्रहित करेंगे - city_name . हम उम्मीद कर सकते हैं कि इस तालिका में एक निश्चित देश के सभी शहरों और गांवों की सूची होगी।

कॉल

दो विषय क्षेत्र हैं जो इस डेटा मॉडल के लिए विशिष्ट हैं:Calls और Actions & services . समय की धारा में, कॉल पहले आती हैं और अन्य घटनाओं को ट्रिगर करती हैं। इसलिए, हम पहले इस अनुभाग का वर्णन करेंगे।

Calls विषय क्षेत्र पाँच तालिकाओं से बना है। जबकि Calls तालिका स्पष्ट रूप से केंद्रीय है, हम पहले अन्य चार तालिकाओं का वर्णन करेंगे क्योंकि वे सभी कॉल तालिका में संदर्भित हैं।

उपयोगकर्ता अपने लैंडलाइन या मोबाइल फोन का उपयोग करके कॉल शुरू करते हैं। हमें 112 या 911 नामक प्रत्येक नंबर को संग्रहीत करने की आवश्यकता है, इसलिए हमें एक phone_number टेबल। हर बार जब कोई नई कॉल शुरू की जाती है, तो हम जांचेंगे कि क्या नंबर इस तालिका में पहले से मौजूद है। यदि नहीं, तो हम एक नई पंक्ति सम्मिलित करेंगे। प्रत्येक टेबल रिकॉर्ड के लिए, हम स्टोर करेंगे:

• phone_number - वह नंबर जिसने कॉल शुरू की थी।
• number_status_id - number_status शब्दकोश। यह मान इंगित करेगा कि क्या नंबर "पहला संपर्क", "ब्लैक लिस्टेड" या "अवरुद्ध", आदि है। यह मान हमें यह तय करने में मदद कर सकता है कि क्या करना है, उदा। यदि कोई नंबर ब्लॉक किया गया है तो एक नया कॉल न करें, यदि कोई नंबर ब्लैकलिस्ट किया गया है तो चेतावनी दें, या ऑपरेटर के लिए केवल जानकारी रिकॉर्ड करें।
• notes - उस नंबर से संबंधित सभी नोट, किसी भी ऑपरेटर द्वारा डाले गए। यह एक आवश्यक फ़ील्ड नहीं है और इसमें अधिकतर NULL मान होंगे।

operator तालिका का उपयोग कॉल प्राप्त करने वाले सभी ऑपरेटरों की सूची को संग्रहीत करने के लिए किया जाता है। प्रत्येक ऑपरेटर के लिए, हम एक UNIQUE 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 है और संपर्क स्थापित करने के लिए आवश्यक कोई भी जानकारी। संपर्क जानकारी contact_details . में एक संरचित JSON जैसे प्रारूप में संग्रहीत की जाती है गुण। कुछ अपेक्षित आपातकालीन सेवाएं "पुलिस", "अग्निशमन विभाग" और "एम्बुलेंस" हैं। फिर भी, हमारे पास अन्य भी हो सकते हैं, जैसे "पहाड़ बचाव", "सिविल गार्ड", आदि।

action_catalog डिक्शनरी में उन सभी संभावित कार्रवाइयों की सूची होती है जिनकी कॉल के परिणामस्वरूप आवश्यकता हो सकती है। इस तालिका में ऐसे UNIQUE की सूची है action_name मूल्य। यहां कुछ अपेक्षित मान हैं "सभी सेवाओं को अलर्ट करें", "एम्बुलेंस को अलर्ट करें", आदि।

अब हमें उन सभी अलर्ट की एक सूची को परिभाषित करने की आवश्यकता है जो किसी कॉल को कोई कार्रवाई सौंपे जाने पर स्वचालित रूप से होनी चाहिए। ये मान alert_service टेबल। हम UNIQUE जोड़ी को स्टोर करेंगे action_catalog_id - emergency_service_id , यह दर्शाता है कि जब यह कार्रवाई सौंपी जाती है तो एक निश्चित आपातकालीन सेवा से संपर्क किया जाना चाहिए। फिर भी, कभी-कभी हम इसे संशोधित करना चाहेंगे, इसलिए मैं ऐसा करने के लिए एक विकल्प छोड़ूंगा। यदि ध्वज always_alert है सही पर सेट है, हम यह अलर्ट बिना मैन्युअल पर्यवेक्षण के भेज देंगे; अन्यथा, ऑपरेटर हस्तक्षेप कर सकता है।

किसी कॉल पर कार्रवाई असाइन करना action_required टेबल। हमें प्रत्येक कॉल के लिए एक से अधिक क्रियाओं की आवश्यकता हो सकती है, इसलिए हमें इस तालिका की आवश्यकता है। हम UNIQUE संयोजन call_id . स्टोर करेंगे - action_id साथ ही नोट, यदि कोई हो, जो ऑपरेटर द्वारा डाला गया हो।

हमारे मॉडल में अंतिम तालिका है alerted_service टेबल। action_required_id . के अद्वितीय जोड़े - emergency_service_id उस कार्रवाई (और कॉल) के लिए शुरू किए गए वास्तविक अलर्ट को निरूपित करें। ये सभी रिकॉर्ड alert_service.always_alert . के साथ होंगे सही पर सेट किया गया है और ऑपरेटर द्वारा संशोधित किए जाने के बाद सभी अलर्ट मैन्युअल रूप से सेट किए गए हैं।

संभावित सुधार

यह मॉडल सिर्फ एक संभावित समाधान की रीढ़ है। मैं व्यक्तिगत रूप से कई सुधार सुझा सकता हूं:

• ऑपरेटरों का डेटा कैसे संग्रहीत किया जाता है।
• आपातकालीन सेवाओं को अलर्ट करने के बाद जो हुआ उसे ट्रैक करने की संभावना सहित।
• ऑपरेटर को कॉल करने देना।
• डेटाबेस में घटनाओं से संबंधित ताकि हम परिभाषित कर सकें कि क्या एक निश्चित कॉल किसी अन्य कॉल, क्रिया या अलर्ट से संबंधित थी। फिलहाल, हम केवल उनका आदेश जानते हैं।

आपके देश में ऐसी सेवाएं कैसे काम करती हैं? क्या हमें कुछ याद आया? आप इस मॉडल में क्या जोड़ेंगे या हटाएंगे? कृपया हमें नीचे कमेंट्स में बताएं।