स्मार्ट होम डेटा मॉडल

स्मार्ट होम भविष्य में सख्ती से हुआ करते थे; अब वे एक वास्तविकता हैं। हम में से अधिकांश ने उनके बारे में सुना है, लेकिन वे इतने व्यापक नहीं हैं जितने निकट भविष्य में होंगे। अपने घर को 'स्मार्ट' तरीके से प्रबंधित करने से निश्चित रूप से बहुत सारा डेटा तैयार होगा। आज, हम एक डेटा मॉडल का विश्लेषण करेंगे जिसका उपयोग हम स्मार्ट होम डेटा को स्टोर करने के लिए कर सकते हैं।

डेटा मॉडल

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

आइए एक डेटा मॉडल पर एक नज़र डालें जो हमें ऐसी कार्यक्षमताओं को लागू करने की अनुमति देगा। उस डेटा मॉडल के शीर्ष पर, हम एक वेब एप्लिकेशन और एक मोबाइल एप्लिकेशन बना सकते हैं जो पंजीकृत उपयोगकर्ताओं को अपने खातों को प्रबंधित करने, निर्देश भेजने और स्थिति को ट्रैक करने की अनुमति देगा।

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

• Estates & devices
• Users & profiles
• Commands & data

मैं इनमें से प्रत्येक विषय क्षेत्र का वर्णन उसी क्रम में करूँगा जिस क्रम में वे सूचीबद्ध हैं। हालांकि, कुछ और करने से पहले, मैं user_account टेबल।

उपयोगकर्ता_खाता तालिका

हम user_account तालिका क्योंकि इसका उपयोग तीनों विषय क्षेत्रों में किया जाता है। यह हमारे आवेदन के सभी पंजीकृत उपयोगकर्ताओं की एक सूची संग्रहीत करता है।

user_account तालिका में वे सभी मानक विशेषताएँ शामिल हैं जिनकी आप अपेक्षा करते हैं, जिनमें शामिल हैं:

• first_name और last_name - उपयोगकर्ता का पहला और अंतिम नाम।
• user_name - उपयोगकर्ता द्वारा चुना गया एक अद्वितीय उपयोगकर्ता नाम।
• password - उपयोगकर्ता के पासवर्ड का हैश मान।
• email - पंजीकरण प्रक्रिया के दौरान उपयोगकर्ता द्वारा प्रदान किया गया ईमेल पता।
• confirmation_code - पंजीकरण प्रक्रिया के दौरान उत्पन्न कोड।
• confirmation_time - टाइमस्टैम्प जब उपयोगकर्ता ने अपने खाते की पुष्टि की और पंजीकरण प्रक्रिया पूरी की।
• ts - टाइमस्टैम्प जब यह रिकॉर्ड डेटाबेस में डाला गया था।

अनुभाग 1:संपदा और उपकरण

इस डेटाबेस को बनाने के पीछे की पूरी प्रेरणा यह निगरानी करना है कि हमारे सम्पदा (अर्थात घरों या संपत्तियों) के साथ क्या हो रहा है। ये निजी संपत्तियां हो सकती हैं, जैसे अपार्टमेंट या घर, या वे व्यावसायिक संपत्तियां हो सकती हैं, जैसे कार्यालय, गोदाम, आदि। अगर हम वास्तव में अपने सिस्टम को सीमा तक धकेलना चाहते हैं, तो हम इसे वाहनों के लिए भी इस्तेमाल कर सकते हैं।

इस विषय क्षेत्र में केंद्रीय तालिका real_estate टेबल। यह वह जगह है जहाँ हम अपने स्मार्ट होम ऐप से जुड़े सभी अलग-अलग सम्पदाओं या संपत्तियों को संग्रहीत करेंगे। प्रत्येक एस्टेट के लिए, हम स्टोर करेंगे:

• real_estate_name - उपयोगकर्ता द्वारा चुना गया एक नाम, जो एक विशिष्ट संपत्ति को संदर्भित करता है।
• user_account_id - उस उपयोगकर्ता की आईडी जिससे यह संपत्ति संबंधित है। real_estate_name विशेषता के साथ, यह इस तालिका की UNIQUE (वैकल्पिक) कुंजी बनाता है।
• real_estate_type - यह दर्शाता है कि यह संपत्ति किस प्रकार की अचल संपत्ति है।
• address - उस संपत्ति का वास्तविक पता। यह अशक्त है क्योंकि हम इस प्रणाली का उपयोग अन्य प्रकार की संपत्ति (यानी वाहन) के लिए कर सकते हैं।
• details - पाठ्य प्रारूप में सभी अतिरिक्त विवरण।

हमने पहले ही अचल संपत्ति के प्रकारों का उल्लेख किया है। संभावित प्रकारों की पूरी सूची real_estate_type शब्दकोश। इसमें केवल एक अद्वितीय मान होता है, type_name . हम यहां "अपार्टमेंट", "घर" या "गेराज" जैसे मूल्यों की अपेक्षा कर सकते हैं।

अचल संपत्ति के एक टुकड़े को कई क्षेत्रों में विभाजित किया जा सकता है। यह किसी अपार्टमेंट या घर के कमरे हो सकते हैं; हो सकता है कि हम कुछ कमरों को एक साथ समूहित करना चाहते हैं या हम एक समूह में यार्ड या बगीचे से संबंधित सब कुछ चाहते हैं, या शायद हमारे पास कई कार्यालयों के साथ एक औद्योगिक संपत्ति या परिसर है; यदि हमारी संपत्ति वास्तव में बड़ी है, तो विशिष्ट क्षेत्रों का होना बहुत उपयोगी हो सकता है। इसे प्राप्त करने के लिए, हम area टेबल। इसमें real_estate_id . की UNIQUE जोड़ी शामिल है और area_name उपयोगकर्ता द्वारा चुना गया।

इस विषय क्षेत्र में अंतिम दो तालिकाएँ उपकरणों से संबंधित हैं।

device_type तालिका में, हम सभी विशिष्ट डिवाइस प्रकारों की पूरी सूची संग्रहीत करेंगे। प्रत्येक प्रकार के लिए, हम एक अद्वितीय type_name . का उपयोग करेंगे और एक अतिरिक्त details डालें यदि ज़रूरत हो तो। डिवाइस के प्रकार अलग-अलग सेंसर (तापमान, गैस), दरवाजे या खिड़की के ताले, लाइट, एयर कंडीशनिंग और हीटिंग सिस्टम आदि हो सकते हैं।

अब हम मज़ेदार हिस्से के लिए तैयार हैं। हम device विभिन्न स्मार्ट घरों में शामिल सभी उपकरणों की एक सूची संग्रहीत करने के लिए तालिका। इन उपकरणों को उपयोगकर्ता द्वारा मैन्युअल रूप से या स्वचालित रूप से जोड़ा जाता है यदि डिवाइस में वह विकल्प होता है। प्रत्येक डिवाइस के लिए, हमें स्टोर करना होगा:

• real_estate_id - उस रीयल एस्टेट का आईडी जहां यह डिवाइस इंस्टॉल किया गया है।
• area_id - area जहां यह उपकरण लगाया गया है। यह एक वैकल्पिक मान है क्योंकि एक एस्टेट सकता है क्षेत्रों में विभाजित किया जा सकता है, लेकिन इसे या तो विभाजित नहीं किया जा सकता है।
• device_type_id – device_type यह डिवाइस संबंधित है।
• device_parameters - हम इस विशेषता का उपयोग सभी संभावित डिवाइस मापदंडों (जैसे डेटा संग्रहीत करने के लिए अंतराल) को एक संरचित पाठ प्रारूप में संग्रहीत करने के लिए करेंगे। ये पैरामीटर उपयोगकर्ता या डिवाइस के नियमित कार्य के एक हिस्से द्वारा निर्धारित किए जा सकते हैं (जैसे विभिन्न उपाय)।
• current_status - डिवाइस पैरामीटर की वर्तमान स्थिति।
• time_activated और time_deactivated - जब यह उपकरण सक्रिय था तब अंतराल को निरूपित करें। अगर time_deactivated सेट नहीं है, तो डिवाइस सक्रिय है और is_active विशेषता भी सही पर सेट है।

अनुभाग 2:उपयोगकर्ता और प्रोफ़ाइल

हम पहले ही user_account टेबल। हमारे एप्लिकेशन में, उपयोगकर्ताओं को अलग-अलग प्रोफाइल बनाने और अन्य उपयोगकर्ताओं के साथ साझा करने में सक्षम होना चाहिए यदि वे चाहते हैं।

प्रोफाइल मूल रूप से उपयोगकर्ता के स्वामित्व वाली अचल संपत्ति के प्रत्येक टुकड़े में स्थापित उपकरणों के सबसेट हैं। प्रत्येक उपयोगकर्ता के पास एक या अधिक प्रोफ़ाइल हो सकती हैं। विचार यह है कि उपयोगकर्ता अपने स्मार्ट होम उपकरणों को उपयुक्त तरीके से समूहीकृत कर सके। जबकि उपयोगकर्ता के पास अपने सभी उपकरणों के साथ एक प्रोफ़ाइल हो सकती है, उनके पास एक प्रोफ़ाइल भी हो सकती है जो उनकी सभी संपत्तियों के लिए केवल फ्रंट-डोर कैमरे दिखाती है। या शायद उनके अपार्टमेंट के सभी कमरों में स्थापित थर्मामीटर के लिए एक प्रोफ़ाइल।

उपयोगकर्ताओं द्वारा बनाई गई सभी प्रोफ़ाइल profile टेबल। प्रत्येक रिकॉर्ड के लिए, हमारे पास होगा:

• profile_name - प्रोफ़ाइल का नाम, उपयोगकर्ता द्वारा चुना गया।
• user_account_id - इस प्रोफ़ाइल को बनाने वाले उपयोगकर्ता को संदर्भित करता है। यह विशेषता और profile_name विशेषता तालिका की UNIQUE कुंजी बनाती है।
• allow_others - एक ध्वज यह दर्शाता है कि क्या यह प्रोफ़ाइल अन्य उपयोगकर्ताओं के साथ साझा की गई है।
• is_public - एक झंडा यह दर्शाता है कि क्या यह प्रोफ़ाइल सार्वजनिक रूप से दिखाई दे रही है। हालांकि हम उम्मीद कर सकते हैं कि यह ज्यादातर समय गलत पर सेट होगा, ऐसे मामले भी हो सकते हैं जब हम सभी के साथ एक प्रोफ़ाइल साझा करना चाहते हैं।
• is_active - एक झंडा यह दर्शाता है कि यह प्रोफ़ाइल सक्रिय है या नहीं।
• ts - एक टाइमस्टैम्प जब यह रिकॉर्ड डाला गया था।

प्रत्येक प्रोफ़ाइल के लिए, हम इसमें शामिल सभी उपकरणों की एक सूची परिभाषित करेंगे। यह सूची profile_device_list तालिका और इसमें UNIQUE की एक सूची है profile_id - device_id जोड़े। यह विदेशी कुंजी जोड़ी हमारी तालिका की प्राथमिक कुंजी बनाती है।

इस विषय में अंतिम तालिका उपयोगकर्ताओं को अन्य पंजीकृत उपयोगकर्ताओं के साथ अपनी प्रोफाइल साझा करने में सक्षम बनाती है। यह बहुत उपयोगी हो सकता है, उदा। यदि एक व्यक्ति सब कुछ प्रबंधित करता है और अन्य पंजीकृत उपयोगकर्ता (जैसे परिवार के सदस्य) स्वामी द्वारा बनाई गई प्रोफ़ाइल देखना चाहते हैं। shared_with तालिका में, हम profile_id . के सभी अद्वितीय युग्मों की सूची संगृहीत करेंगे - user_account_id . एक बार फिर, यह विदेशी कुंजी जोड़ी तालिका की प्राथमिक कुंजी है। कृपया ध्यान दें कि शेयरिंग तभी काम करेगी जब profile.allow_others विशेषता सही पर सेट है।

अनुभाग 3:आदेश और डेटा

हम उपयोगकर्ताओं और उपकरणों के बीच संचार को संग्रहीत करने के लिए इस अंतिम विषय क्षेत्र की तालिकाओं का उपयोग करेंगे। यह दोतरफा संचार होगा। उपकरण अपने संचालन के दौरान डेटा उत्पन्न करेंगे और हमारा डेटाबेस इसे और साथ ही सिस्टम (या उपकरणों) द्वारा उत्पन्न किसी भी संदेश को संग्रहीत करेगा। उपयोगकर्ता इन संदेशों और उनके उपकरणों द्वारा भेजे गए डेटा को देखना चाहेंगे। इस डेटा के आधार पर, उपयोगकर्ता अपने स्मार्ट होम के लिए प्रोग्राम बना सकते हैं। ये प्रोग्राम मैन्युअल रूप से या स्वचालित रूप से उत्पन्न कमांड या यहां तक ​​कि कमांड की एक श्रृंखला है जो ठीक वही करेगा जो प्रत्येक उपयोगकर्ता चाहता है।

हम उन डेटा उपकरणों से शुरू करेंगे जो हमें देते हैं। device_data तालिका में, हम डिवाइस-जनरेटेड डेटा और डेटा के स्थान (स्थानों) का विवरण संग्रहीत करेंगे। फिर से, डेटा स्वचालित रूप से उपकरणों द्वारा उत्पन्न होता है। यह माप, स्थिति (पाठ्य डेटा), या ऑडियो-विज़ुअल डेटा की एक श्रृंखला हो सकती है। इस तालिका में प्रत्येक रिकॉर्ड के लिए, हम स्टोर करेंगे:

• device_id - इस डेटा को जनरेट करने वाले डिवाइस का आईडी.
• data_description - संग्रहीत डेटा का विवरण, उदा। क्या संग्रहीत है, जब डेटा हमारे सिस्टम में संग्रहीत किया गया था, और किस प्रारूप में।
• data_location - उस स्थान का पूरा पथ जहां यह डेटा संग्रहीत है।
• ts - टाइमस्टैम्प जब यह रिकॉर्ड डाला गया था।

डिवाइस डेटा संग्रहीत किया जाएगा, भले ही डिवाइस ठीक से काम कर रहा हो या डेटा अपेक्षित सीमा से बाहर हो। यह मूल रूप से सब कुछ का एक लॉग है जो उपकरणों द्वारा रिकॉर्ड किया गया था। हम पुरानी डिवाइस डेटा फ़ाइलों को हटाने की रणनीति की उम्मीद कर सकते हैं, लेकिन यह इस लेख के दायरे से बाहर है।

डिवाइस डेटा के विपरीत, हम उम्मीद कर सकते हैं कि संदेश केवल तभी उत्पन्न होंगे जब कुछ अनपेक्षित होता है - उदा। यदि कोई उपकरण माप सामान्य सीमा से बाहर है, यदि सेंसर ने गति का पता लगाया है, आदि। ऐसे मामलों में, डिवाइस संदेश उत्पन्न करता है। ऐसे सभी संदेश auto_message टेबल। प्रत्येक रिकॉर्ड में, हमारे पास होगा:

• device_id - इस संदेश को जनरेट करने वाले डिवाइस का आईडी.
• message_text - डिवाइस द्वारा उत्पन्न पाठ। यह एक पूर्वनिर्धारित पाठ हो सकता है, एक मान जो अपेक्षित सीमा से बाहर है, या इन दोनों का संयोजन हो सकता है।
• ts - इस रिकॉर्ड को संग्रहीत किए जाने का टाइमस्टैम्प।
• read - एक झंडा यह दर्शाता है कि क्या संदेश उपयोगकर्ता द्वारा पढ़ा गया था।

शेष तीन तालिकाओं का उपयोग उपयोगकर्ताओं के आदेशों को संग्रहीत करने के लिए किया जाता है। कमांड उपयोगकर्ताओं को अपने नियंत्रणीय उपकरणों को नियंत्रित करने और अपने स्मार्ट होम के साथ दो-तरफा संचार स्थापित करने की अनुमति देते हैं।

सबसे पहले, हम सभी संभावित कमांड प्रकारों की एक सूची परिभाषित करेंगे। ये "चालू/बंद", "तापमान में वृद्धि/कमी" आदि जैसे मान हो सकते हैं। हमारे पास सशर्त आदेश भी हो सकते हैं, यानी। आदेश जो केवल तभी पूरे होते हैं जब कोई विशिष्ट शर्त सत्य होती है। सभी विशिष्ट कमांड प्रकारों की एक सूची command_type शब्दकोश। प्रत्येक प्रकार के लिए, हम एक अद्वितीय type_name . संग्रहित करेंगे . हम उन सभी मापदंडों की एक सूची भी संग्रहीत करेंगे जिन्हें उस प्रकार के आदेश के लिए परिभाषित किया जाना चाहिए। यह एक संरचित पाठ प्रारूप में सम्मिलित डिफ़ॉल्ट मानों के साथ होगा। उपयोगकर्ता अपने नए आदेश सम्मिलित करते समय इन मानों को सेट करेगा।

एक उपयोगकर्ता सभी recurring_commands सामने। हो सकता है कि हम हर दिन सुबह 7 बजे गर्म पानी चाहते हों या हर दिन शाम 4 बजे हीटिंग/कूलिंग सिस्टम को सक्रिय करना चाहते हों। आवर्ती आदेशों को पूरा करने के लिए नियमों का सेट और सभी आवश्यक विशेषताएँ इस तालिका में संग्रहीत की जाती हैं। हमारे पास होगा:

• user_account_id - इस आवर्ती आदेश को सम्मिलित करने वाले उपयोगकर्ता की आईडी।
• device_id - इस आवर्ती आदेश के लिए प्रासंगिक डिवाइस की आईडी।
• command_type_id - command_type शब्दकोश।
• parameters - सभी पैरामीटर जिन्हें उस कमांड प्रकार के लिए परिभाषित किया जाना चाहिए, साथ में उनके वांछित मान।
• interval_definition - इस आदेश के दो पुनरावृत्तियों के बीच का अंतराल। कमांड पैरामीटर की तरह, यह एक संरचित टेक्स्ट फ़ील्ड होगा।
• active_from और active_to - वह अंतराल जिसके दौरान इस आदेश को दोहराया जाना चाहिए। active_to विशेषता NULL हो सकती है यदि हम चाहते हैं कि वह कमांड हमेशा के लिए दोहराई जाए (या जब तक हम active_to . को परिभाषित नहीं करते हैं तारीख)।
• ts - टाइमस्टैम्प जब यह रिकॉर्ड डाला गया था।

हमारे मॉडल की अंतिम तालिका में एकल कमांड की एक सूची है। इन आदेशों को उपयोगकर्ता द्वारा मैन्युअल रूप से सम्मिलित किया जा सकता है या स्वचालित रूप से उत्पन्न किया जा सकता है (अर्थात आवर्ती आदेशों के भाग के रूप में)। प्रत्येक कमांड के लिए, हम स्टोर करेंगे:

• recurring_command_id - इस कमांड को ट्रिगर करने वाले आवर्ती कमांड की आईडी, यदि कोई हो।
• user_account_id - इस कमांड को डालने वाले यूजर की आईडी।
• device_id - संबंधित डिवाइस की आईडी।
• command_type_id - command_type शब्दकोश।
• parameters - इस कमांड के लिए प्रासंगिक सभी पैरामीटर।
• executed - एक ध्वज यह दर्शाता है कि क्या यह आदेश निष्पादित किया गया है।
• ts - टाइमस्टैम्प जब यह रिकॉर्ड डाला गया था।

स्मार्ट होम डेटा मॉडल के बारे में आप क्या सोचते हैं?

इस लेख में, हमने स्मार्ट घर के प्रबंधन के सबसे महत्वपूर्ण पहलुओं को कवर करने का प्रयास किया है। उनमें से एक निश्चित रूप से उपयोगकर्ता और सिस्टम के बीच दो-तरफ़ा संचार है। अधिकांश "वास्तविक" क्रियाएं टेक्स्ट पैरामीटर के रूप में संग्रहीत की जाती हैं, और विशिष्ट कार्यों को निष्पादित करते समय इन मानों को पार्स किया जाना चाहिए। ऐसा इसलिए किया गया था ताकि हमारे पास कई अलग-अलग डिवाइस प्रकारों के साथ काम करने के लिए पर्याप्त लचीलापन हो।

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