महत्वपूर्ण तिथियां डेटा मॉडल

क्या आप कुछ भूल रहे हैं? महत्वपूर्ण तिथियों को याद रखने में आपकी मदद करने के लिए एक डेटा मॉडल - होने से पहले।

क्या आप कभी कोई महत्वपूर्ण तारीख भूल गए हैं - आपकी माँ का जन्मदिन या आपकी सालगिरह? या कि आप व्याख्यान दे रहे हैं? जी हां, असल जिंदगी में ऐसी चीजें होती हैं। शायद हम सभी को नहीं, लेकिन हममें से कुछ (मेरे सहित) के लिए, वे निश्चित रूप से करते हैं। ऐसी आपदाओं को रोकने के लिए, हम एक डेटा मॉडल बनाएंगे जिसका उपयोग आप किसी एप्लिकेशन के लिए पृष्ठभूमि के रूप में कर सकते हैं जो आपको सही समय पर सूचित करेगा।

उन सभी निराश और उदास चेहरों को और समय पर नहीं खरीदे गए उपहारों को अलविदा कहने का समय आ गया है। :)

आइए सीधे मॉडल में गोता लगाएँ।

डेटा मॉडल

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

बेशक, हमें इस प्रणाली को वास्तव में उपयोगी बनाने के लिए वेब और मोबाइल एप्लिकेशन विकसित करने की भी आवश्यकता होगी। लेकिन अभी के लिए, डेटा मॉडल पर ध्यान दें।

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

• User accounts & dates
• Events & actions (definition)
• Events & actions (real)

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

अनुभाग 1:उपयोगकर्ता खाते और दिनांक

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

user_account तालिका कई डेटा मॉडल लेखों में वर्णित संरचना के समान है, लेकिन आइए इसे एक बार फिर से दोहराएं। प्रत्येक उपयोगकर्ता के लिए, हम स्टोर करेंगे:

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

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

• user_account_id - उस उपयोगकर्ता की आईडी जिसने यह रिकॉर्ड डाला है।
• date_year , date_month , और date_day - दिनांक भागों (वर्ष, माह और महीने के दिन) का प्रतिनिधित्व करने वाले पूर्णांक मान।
• date_weekday - सप्ताह के दिन की क्रमिक संख्या का एक शाब्दिक प्रतिनिधित्व। हम टेक्स्ट का उपयोग कर रहे हैं क्योंकि यह उपयोगकर्ताओं को अधिक जटिल मानों का चयन करने की अनुमति देता है - वे सप्ताह के दिन और महीने में सप्ताह दोनों को परिभाषित कर सकते हैं, उदा। प्रत्येक माह में दूसरा सोमवार।

कृपया ध्यान दें कि सभी चार दिनांक भाग NULL हो सकते हैं। हम सभी NULL मानों वाले रिकॉर्ड की अनुमति नहीं देंगे, इसलिए हम प्रोग्रामेटिक रूप से जांच करेंगे कि कम से कम एक तारीख का हिस्सा न्यूल नहीं है।

और अब कुछ उदाहरण:

• अगर हम कोई सटीक तारीख चुनना चाहते हैं, उदा. 31.12.2018, हम मानों को date_year . पर सेट करेंगे =2018, date_month =12, और date_day =31. यह कुछ ऐसा परिभाषित करता है जो केवल एक बार, उस एक तारीख को होगा।
• यदि हम संयोजन का उपयोग करते हैं date_year =2019 और date_month =1, शेष दो मानों को शून्य छोड़कर, फिर हम कुछ ऐसा परिभाषित कर रहे हैं जो पूरे जनवरी 2019 के दौरान दोहराएगा।
• संयोजन date_year =2019 और date_day =2 2019 में हर महीने के दूसरे दिन एक इवेंट को ट्रिगर करेगा।
• अगर हम मान डालें <सप्ताह का दिन:0><सप्ताह एक महीने में:2> , हम कुछ ऐसा परिभाषित कर रहे हैं जो हर महीने के दूसरे सोमवार को होगा।

अनुभाग 2:ईवेंट और क्रियाएं (परिभाषा)

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

event तालिका निश्चित रूप से इस विषय क्षेत्र में केंद्रीय तालिका है, लेकिन इसका वर्णन करने से पहले, मैं दो शब्दकोशों का वर्णन करना चाहता हूं, event_catalog और recurrence_interval . उन दोनों की संरचना समान है, ऑटो-इन्क्रीमेंटिंग प्राथमिक कुंजी (id .) के साथ ) और अद्वितीय नाम विशेषता।

event_catalog शब्दकोश "जन्मदिन", "सार्वजनिक अवकाश", "वर्षगांठ" और "अन्य" जैसे मूल्यों को संग्रहीत करेगा। इससे हमें अपने आयोजनों को वर्गीकृत करने में मदद मिलेगी।

दूसरी ओर, recurrence_interval "वर्ष", "महीना", "सप्ताह" और "दिन" जैसे मूल्यों को संग्रहीत करेगा। यह मान उस समय की इकाई को दर्शाता है जो संदर्भित घटना/क्रिया के दोहराने से पहले बीत जाएगा (यदि इसे एक आवर्ती घटना के रूप में परिभाषित किया गया है)। जब वह समयावधि बीत जाएगी, उसी घटना/क्रिया का एक नया उदाहरण उत्पन्न होगा।

अब हम इस विषय क्षेत्र के केंद्र में जाने के लिए तैयार हैं। event तालिका में, उपयोगकर्ता उन सभी घटनाओं को परिभाषित करता है जो उनके लिए महत्वपूर्ण हैं। प्रत्येक ईवेंट के लिए, हम स्टोर करेंगे:

• selected_date_id - दिनांक परिभाषा का संदर्भ देता है।
• event_catalog_id - घटना के प्रकार को दर्शाता है।
• description - उस घटना का एक अतिरिक्त पाठ्य विवरण।
• recurring - एक झंडा यह दर्शाता है कि क्या घटना आवर्ती है।
• recurrence_interval_id - परिभाषित करता है कि घटना कितनी बार दोहराई जाती है (वर्ष, माह, आदि)। selected_date पुनरावृत्ति अंतराल के साथ हम घटना के शुरुआती बिंदु को परिभाषित करने में सक्षम होंगे और उस शुरुआती बिंदु के बाद कितनी घटनाएं स्वचालित रूप से बनाई जाएंगी। इस तरह हम कुछ इस तरह परिभाषित कर सकते हैं:“हर महीने के दूसरे सोमवार से (selected_date तालिका), स्वचालित रूप से दैनिक मीटिंग शेड्यूल करें (event.recurrence_interval विशेषता)" ।
• recurring_frequency - एक संख्या जो कितनी इकाइयों को दर्शाती है (recurrence_interval_id . द्वारा परिभाषित) ) को इस घटना के दोबारा होने से पहले पास करना होगा (यदि यह एक आवर्ती घटना है)। पिछले उदाहरण (दैनिक मीटिंग) के लिए, हम इस मान को 1 के रूप में परिभाषित करेंगे।
• recurring_times - इस घटना के उदाहरणों की संख्या। पिछले उदाहरण के लिए, यह "5" (सोमवार से शुक्रवार तक दैनिक मीटिंग) होगा।

इसके बाद, हमें लोगों (उपयोगकर्ता द्वारा ज्ञात) को ईवेंट से जोड़ना होगा। हमारे उपयोगकर्ताओं द्वारा सम्मिलित किए गए सभी लोगों की सूची person टेबल। प्रत्येक व्यक्ति के लिए, उपयोगकर्ता एक पूरा नाम और कोई अतिरिक्त विवरण (यदि आवश्यक हो) परिभाषित करेगा।

अब, इन व्यक्तियों को उपयोगकर्ता की घटनाओं से संबंधित किया जा सकता है। related_event तालिका में, हम event और person साथ ही कुछ description उस रिश्ते की प्रकृति के बारे में। कृपया ध्यान दें कि एक ही व्यक्ति को एक ही ईवेंट के लिए कई बार जोड़ा जा सकता है। यह समझ में आता है अगर हम विशेष रूप से कुछ विशेष इंगित करने के लिए एक से अधिक रिकॉर्ड रखना चाहते हैं (उदाहरण के लिए "सोफिया को पार्टी में आमंत्रित करें"; सोफिया एक पार्टी अतिथि और पार्टी में बैंड के लिए गायक दोनों है)।

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

कार्रवाई घटना से संबंधित कुछ भी हो सकती है। उदाहरण के लिए, यदि हम खुद को माँ के जन्मदिन की याद दिलाना चाहते हैं, तो यह बहुत अच्छा होगा यदि आवेदन हमें बताता है:"उस उपहार के बारे में सोचना शुरू करें जो आप अपनी माँ को देना चाहते हैं", "माँ के जन्मदिन के लिए एक उपहार खरीदें", "माँ को उसे दें" बी-डे उपहार। और कुछ चुंबन भी" और अंत में "आपने इसे इस साल फिर से सफलतापूर्वक किया है। आपके लिए (और मेरे लिए) ब्रावो!"

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

• event_id - संबंधित घटना की आईडी।
• action_catalog_id - action_catalog शब्दकोश।
• description - उस क्रिया का एक वैकल्पिक विवरण। हर बार जब यह क्रिया शुरू होती है, तो हमारा एप्लिकेशन इस विशेषता को देखेगा, आदेशों को पढ़ेगा और उस क्रिया को करेगा।
• action_code - उस क्रिया की एक संरचित पाठ्य परिभाषा।
• starts_before - परिभाषित करता है कि चयनित घटना के लिए इस क्रिया के शुरू होने से पहले कितनी चयनित समय इकाइयाँ समाप्त हो जाएँगी (यदि यह एक आवर्ती क्रिया है)। यदि यह मान परिभाषित नहीं है (अर्थात NULL पर सेट है), तो क्रियाएँ उसी क्षण शुरू होंगी जब ईवेंट शुरू होगा।
• send_message - एक झंडा यह दर्शाता है कि उपयोगकर्ता को संदेश भेजा जाना चाहिए या नहीं।
• recurring - दर्शाता है कि यह क्रिया आवर्ती है या नहीं।
• recurring_interval_id - पुनरावृत्ति के लिए अंतराल/इकाई को दर्शाता है (यदि यह एक आवर्ती क्रिया है)।
• recurring_frequency - चयनित इकाइयों की संख्या को दर्शाता है जो एक ही क्रिया के दो पुनरावृत्तियों के बीच समाप्त होनी चाहिए (यदि यह एक आवर्ती क्रिया है)।
• recurring_times - हम इस कार्रवाई के कितने उदाहरण बनाएंगे?

क्रिया पुनरावृत्ति घटना पुनरावृत्ति के समान पैटर्न का अनुसरण करती है। यदि कार्रवाई को पुनरावर्ती के रूप में परिभाषित किया गया है, तो हम निर्धारित समयावधि के बाद एक नई क्रिया आवृत्ति उत्पन्न करेंगे।

अनुभाग 3:ईवेंट और क्रियाएं (वास्तविक)

अब तक, हमने एक डेटा मॉडल बनाया है जो हमें घटनाओं को सम्मिलित करने और क्रियाओं को परिभाषित करने में सक्षम करेगा। अब हम मॉडल के एक और दिलचस्प हिस्से की ओर बढ़ेंगे:वास्तविक घटनाएं और क्रियाएं।

event_instance तालिका में उन सभी घटनाओं की एक सूची है जो स्वचालित रूप से उत्पन्न हुई हैं या मैन्युअल रूप से डाली गई हैं। जबकि ऑटो-जेनरेशन बहुत स्पष्ट है - इसलिए हमने यह मॉडल बनाया है - मैन्युअल इवेंट इंसर्शन भी एक संभावना है। हम उम्मीद कर सकते हैं कि किसी ईवेंट को उसके देय समय पर स्वचालित रूप से सम्मिलित किया जाएगा, इसलिए हमारे पास सामान्य रूप से इस तालिका में केवल वास्तविक और पिछले ईवेंट होंगे। फिर भी, ऐसा हो सकता है कि हमने पहले ही किसी भावी घटना का ध्यान रखा हो, उदा. हमने अगले महीने होने वाली बैठक की तैयारी कर ली है। उस स्थिति में, हमें इस तालिका में भविष्य की घटना (घटना के समय को परिभाषित नियमों के अनुसार प्रस्तावित किया जा रहा है) और उस घटना से संबंधित सभी चीजों को मैन्युअल रूप से सम्मिलित करने में सक्षम होना चाहिए। दूसरी ओर, हमारा आवेदन उस घटना को अधिलेखित या डुप्लिकेट नहीं करेगा। यह event_time . का उपयोग करके हमारे द्वारा पहले से सम्मिलित किए गए ईवेंट को पहचान लेगा मूल्य। प्रत्येक घटना उदाहरण के लिए, हम परिभाषित करेंगे:

• event_id - संदर्भ event परिभाषा।
• event_time - वास्तविक घटना समय, संरचित पाठ प्रारूप में।
• insert_ts - वास्तविक टाइमस्टैम्प जब यह ईवेंट डाला गया था।
• event_completed - एक बूलियन मान यह दर्शाता है कि घटना पूरी हुई या नहीं। यदि सभी संबंधित कार्रवाइयाँ पूर्ण हो जाती हैं, तो ईवेंट स्वचालित रूप से 'पूर्ण' पर सेट हो जाता है। इसे उपयोगकर्ता द्वारा मैन्युअल रूप से 'पूर्ण' पर भी सेट किया जा सकता है।

event_id - event_time जोड़ी इस तालिका की वैकल्पिक/अद्वितीय कुंजी है।

इसी तरह के तर्क का उपयोग action_instance टेबल। जब वे देय होंगे तो क्रियाएं भी स्वचालित रूप से उत्पन्न हो जाएंगी। अगर कोई कार्रवाई बार-बार हो रही है, तो हमारे पास एक ही इवेंट इंस्टेंस के लिए एक से ज़्यादा कार्रवाइयां तय होंगी. प्रत्येक क्रिया के लिए, हम परिभाषित करेंगे:

• action_id - संबंधित action ।
• event_instance_id - संबंधित event_instance ।
• action_time - कार्रवाई का वास्तविक समय, संरचित पाठ प्रारूप में।
• insert_ts - एक वास्तविक टाइमस्टैम्प जब इस घटना को सम्मिलित किया गया था।
• action_completed - एक बूलियन मान यह दर्शाता है कि कार्रवाई पूरी हुई या नहीं। उपयोगकर्ता द्वारा कार्रवाई को मैन्युअल रूप से 'पूर्ण' पर सेट किया गया है। यदि क्रिया आवृत्ति 'पूर्ण' पर सेट है, तो नए उदाहरण उत्पन्न नहीं होंगे (भले ही परिभाषा कहती है कि उन्हें होना चाहिए)।

इस तालिका में, वैकल्पिक/अद्वितीय कुंजी action_id . का संयोजन है - event_instance_id - action_time ।

हमारे मॉडल में अंतिम तालिका message टेबल। इसका उपयोग क्रियाओं द्वारा उत्पन्न संदेशों को संग्रहीत करने के लिए किया जाता है। ये मैसेज यूजर्स को भेजे जाते हैं। प्रत्येक संदेश के लिए, हम संग्रहित करेंगे:

• action_instance_id - action_instance जिसने यह संदेश उत्पन्न किया।
• message_title - संदेश का शीर्षक।
• message_text - संदेश पाठ, जिसमें यह वर्णन है कि यह संदेश क्यों उत्पन्न हुआ (अर्थात संबंधित तालिकाओं से पाठ्य क्षेत्र)।
• insert_ts - टाइमस्टैम्प जब यह संदेश जनरेट किया गया था।
• message_read - एक झंडा यह दर्शाता है कि क्या संदेश उपयोगकर्ता द्वारा पढ़ा गया है।

महत्वपूर्ण ईवेंट डेटा मॉडल पर अपने विचार साझा करें

मुझे आशा है कि आपको आज का लेख अच्छा लगा होगा। क्या आप कभी किसी महत्वपूर्ण तारीख के बारे में भूल गए हैं? क्या आपको लगता है कि यह मॉडल आपकी मदद कर सकता है? कृपया हमें नीचे कमेंट्स में बताएं।