इस बात की बहुत अधिक संभावना नहीं है कि आपने साझा अर्थव्यवस्था के पूरे विचार को याद किया है - चाहे आप इसे पसंद करें या नहीं। Airbnb, Uber, Lyft, और कई अन्य कंपनियों द्वारा लोकप्रिय, यह लोगों को अपने अप्रयुक्त सामान को किराए पर देकर कुछ नकद कमाने देता है। आइए ऐसे एप्लिकेशन के पीछे डेटा मॉडल देखें।
एक अतिरिक्त कमरा मिला? Airbnb के साथ साइन अप करें और इसे किराए पर देकर कुछ अतिरिक्त पैसे कमाएँ। एक कार और कुछ खाली समय मिला? एक उबेर ड्राइवर बनें। और इसलिए यह जाता है - इन कंपनियों और उनके जैसे कई और लोगों के पीछे का विचार लगभग एक जैसा है। यह (ज्यादातर) अजनबियों के साथ एक संसाधन साझा करने के बारे में है, दोनों पक्षों के लिए एक लाभ के साथ। मालिक को उनकी अप्रयुक्त संपत्ति के लिए पैसा मिलता है, जबकि ग्राहक को आमतौर पर एक अच्छा सौदा मिलता है; यह एक जीत की स्थिति होनी चाहिए।
बेशक, हमें मालिकों को ग्राहकों से जोड़ने और महत्वपूर्ण विवरणों पर नज़र रखने के लिए एक मंच की आवश्यकता है। आज, हम एक डेटा मॉडल पेश करेंगे जो कार्य का प्रबंधन कर सकता है। अपनी कुर्सी पर वापस बैठें और साझा अर्थव्यवस्था डेटा मॉडल के माध्यम से सवारी का आनंद लें।
हमें अपने डेटा मॉडल में क्या चाहिए?
जब हम इसका उपयोग नहीं कर रहे हों तो संपत्ति को किराए पर देने का विचार बहुत बुद्धिमानी भरा लगता है। सबसे पहले, संपत्ति का उपयोग उसके इच्छित उद्देश्य के लिए किया जाता है; दूसरा, किराये से किसी प्रकार की अतिरिक्त आय उत्पन्न होगी। यह नकद हो सकता है, लेकिन एक एक्सचेंज भी हो सकता है (उदाहरण के लिए न्यूयॉर्क में कोई व्यक्ति पेरिस में किसी के साथ एक सप्ताह के लिए अपार्टमेंट की अदला-बदली कर रहा है)।
कैशलेस मॉडल वास्तव में अच्छे हैं और वे आम तौर पर आपसी समझ, सद्भावना और ईमानदारी पर निर्भर करते हैं। हालांकि, यह लेख उन अर्थव्यवस्था मॉडल को साझा करने पर ध्यान केंद्रित करेगा जिनके लिए भुगतान की आवश्यकता होती है। यह कैशलेस मॉडल जितना रोमांटिक नहीं है, लेकिन भुगतान मॉडल काफी प्रभावी है।
बड़ी संख्या में संपत्ति के मालिकों के लिए बड़ी संख्या में इच्छुक ग्राहकों तक पहुंचने के लिए और इसके विपरीत हमें एक बहुत ही सरल तरीके की आवश्यकता है। यह हमारे डेटा मॉडल के लिए पहली आवश्यकता है। हमारे पास उपयोगकर्ता खाते और कम से कम दो अलग-अलग भूमिकाएँ होंगी - मालिक और ग्राहक।
अगली चीज़ जो हमें चाहिए वह है हमारे ऐप के लिए सभी उपलब्ध संपत्तियों को सूचीबद्ध करना। Airbnb के लिए, यह अपार्टमेंट होगा; उबेर के लिए, यह कार होगी। यह लेख अपार्टमेंट किराए पर लेने पर अधिक ध्यान केंद्रित करेगा (एक Airbnb जैसा डेटा मॉडल) लेकिन मैं मॉडल को इतना सामान्य रखूंगा कि इसे आसानी से किसी अन्य वांछित साझा-अर्थव्यवस्था सेवा में परिवर्तित किया जा सके।
प्रत्येक संपत्ति के मालिक के लिए, हमें उस स्थान को परिभाषित करना होगा जहां वे काम करते हैं। अपार्टमेंट के लिए, यह बहुत स्पष्ट है (वह शहर जहां अपार्टमेंट स्थित है)। परिवहन सेवाओं के लिए, यह कार और/या उसके मालिक के वर्तमान स्थान पर निर्भर करेगा।
प्रत्येक संपत्ति या संसाधन के लिए, हमें उपयोग अवधियों और अनुरोधों/आरक्षणों को ट्रैक करना होगा। यह हमें एक नया अनुरोध किए जाने पर उपलब्ध संपत्तियों को खोजने और अधिभोग दर और कीमत की गणना करने की अनुमति देगा। हम इस डेटा का विश्लेषण करने और अन्य आंकड़े तैयार करने के लिए अन्य कार्यक्रमों का उपयोग करने में भी सक्षम होंगे।
डेटा मॉडल
डेटा मॉडल में पांच विषय क्षेत्र होते हैं:
देश और शहरउपयोगकर्ता और भूमिकाएंसेवाएं और दस्तावेज़अनुरोधप्रदान की गई सेवाएं
हम प्रत्येक विषय क्षेत्र को उसी क्रम में प्रस्तुत करेंगे जिस क्रम में यह सूचीबद्ध है।
अनुभाग 1:देश और शहर
हम देशों और शहरों से शुरुआत करेंगे विषय क्षेत्र। हालांकि इस डेटा मॉडल के लिए विशिष्ट नहीं है, ये टेबल बहुत महत्वपूर्ण हैं। संपत्ति से संबंधित सेवाएं आमतौर पर भौगोलिक दृष्टि से उन्मुख होती हैं। हमारा मॉडल किसी प्रकार के आवास को किराए पर देने से निकटता से संबंधित है, इसलिए यहां भौतिक स्थान महत्वपूर्ण है। बेशक, वह स्थान आमतौर पर नहीं बदलेगा। कुछ बहुत ही विशेष मामले हैं जिनके परिणामस्वरूप संपत्ति का स्थान बदल सकता है, लेकिन मैं उस आवास को उसके नए स्थान पर पूरी तरह से नई संपत्ति के रूप में मानूंगा।
उबर जैसे कार और/या ड्राइवर ऐप्स के लिए, कार और ड्राइवर का वर्तमान स्थान भी बहुत महत्वपूर्ण है। Airbnb-शैली के अपार्टमेंट रेंटल के विपरीत, ये संपत्ति स्थान बार-बार बदल सकते हैं।
देश तालिका में उन देशों के अद्वितीय नामों की सूची है जहां हम काम करते हैं। शहर तालिका में उन सभी शहरों की सूची है जहां हम काम करते हैं। इस तालिका के लिए अद्वितीय संयोजन postal_code . का संयोजन है , शहर_नाम , और देश_आईडी गुण।
इन दोनों तालिकाओं में कई अतिरिक्त विशेषताएं हो सकती हैं, लेकिन मैंने जानबूझकर उन्हें छोड़ दिया है क्योंकि वे इस मॉडल में कोई मूल्य नहीं जोड़ेंगे।
अनुभाग 2:उपयोगकर्ता और भूमिकाएं
अगली चीज़ जो हमें करने की ज़रूरत है वह है हमारे एप्लिकेशन में उपयोगकर्ताओं और उनके व्यवहार या भूमिकाओं को परिभाषित करना। ऐसा करने के लिए, हम उपयोगकर्ताओं और भूमिकाओं . में तीन तालिकाओं का उपयोग करेंगे विषय क्षेत्र।
सभी उपयोगकर्ताओं की सूची user_account . में है टेबल। प्रत्येक उपयोगकर्ता के लिए, हम निम्नलिखित विवरण संग्रहीत करेंगे:
user_name- अद्वितीय नाम जिसे उपयोगकर्ता ने हमारे एप्लिकेशन तक पहुंचने के लिए चुना है।पासवर्ड- उपयोगकर्ता द्वारा चुने गए पासवर्ड का हैश मान।प्रथम_नामऔरlast_name- उपयोगकर्ता का पहला और अंतिम नाम।city_id-शहर . का संदर्भजहां उपयोगकर्ता आमतौर पर स्थित होता है।current_city_id-शहर . का संदर्भजहां उपयोगकर्ता वर्तमान में स्थित है।ईमेल- उपयोगकर्ता का ईमेल पता।time_insert- टाइमस्टैम्प जब यह रिकॉर्ड तालिका में डाला गया था।confirmation_code- उपयोगकर्ता के ईमेल पते की पुष्टि के लिए पंजीकरण प्रक्रिया के दौरान उत्पन्न एक कोड।time_confirmed- टाइमस्टैम्प जब ईमेल पते की पुष्टि की गई थी। पुष्टि होने तक इस विशेषता में एक NULL मान होता है।
उपयोगकर्ता के पास उनकी भूमिका के अनुसार आवेदन में अलग-अलग अधिकार होंगे। यह भी संभव है कि एक उपयोगकर्ता की एक ही समय में एक से अधिक सक्रिय भूमिकाएँ हो सकती हैं, उदा. वे एक संपत्ति के मालिक और दूसरी संपत्ति के ग्राहक हो सकते हैं। उस स्थिति में, उपयोगकर्ता उसी लॉगिन विवरण का उपयोग करेगा और उसके पास भूमिकाओं के बीच स्विच करने का विकल्प होगा। ऐप में प्रत्येक भूमिका की अपनी स्क्रीन होगी।
सभी संभावित भूमिकाओं की सूची भूमिका . में संगृहीत है शब्दकोश। प्रत्येक भूमिका को उसके role_name . द्वारा विशिष्ट रूप से परिभाषित किया जाता है . सादगी के लिए, हम केवल दो भूमिकाओं की अपेक्षा कर सकते हैं:"संपत्ति स्वामी" और "ग्राहक"।
एक उपयोगकर्ता को एक ही भूमिका अलग-अलग अवधियों के दौरान कई बार सौंपी जा सकती है। ऐसा ही एक मामला होगा यदि उपयोगकर्ता अपने अप्रयुक्त अपार्टमेंट को किराए पर ले रहा था और फिर अपने अपार्टमेंट को किराए पर नहीं लेने का फैसला किया क्योंकि उन्हें इसकी आवश्यकता थी। हालांकि, कुछ महीनों के बाद, उसी उपयोगकर्ता ने अपने अपार्टमेंट को फिर से किराए पर लेने का फैसला किया। इस मामले में, हम उनकी भूमिका को निष्क्रिय कर देंगे और फिर उसे फिर से सक्रिय कर देंगे।
उन सभी भूमिकाओं की सूची जो कभी उपयोगकर्ताओं को सौंपी गई थीं, has_role . में संगृहीत की जाती हैं टेबल। इस तालिका में प्रत्येक रिकॉर्ड के लिए हम स्टोर करेंगे:
user_account_id- संबंधितउपयोगकर्ता . की आईडी।role_id- संबंधितभूमिका . की आईडी।time_from- टाइमस्टैम्प जब यह भूमिका सिस्टम में डाली गई थी।time_to- वह टाइमस्टैम्प जब यह भूमिका निष्क्रिय की गई थी। जब तक भूमिका सक्रिय रहेगी तब तक इसमें NULL मान रहेगा।is_active- किसी भी कारण से भूमिका के निष्क्रिय होने पर गलत पर सेट हो जाता है।
इस तालिका में एक नया रिकॉर्ड डालते समय, हमें अतिव्यापी रिकॉर्ड की जांच करनी चाहिए। यह हमें एक ही अवधि के दौरान एक ही भूमिका को दो बार वैध बनाने से बचने की अनुमति देता है।
धारा 3:सेवाएं और दस्तावेज़
अगली चीज़ जिसे हमें परिभाषित करने की आवश्यकता है वह है उपयोगकर्ताओं द्वारा प्रदान की जाने वाली सेवाएँ। हमें किसी भी संबंधित दस्तावेज़ पर नज़र रखने की भी आवश्यकता होगी। ऐसा करने के लिए, हमें सेवाओं और दस्तावेज़ों . में तालिकाओं की आवश्यकता होगी विषय क्षेत्र।
आइए प्रॉपर्टी . से शुरू करते हैं टेबल। गुण वे हैं जो हमारी सेवा के उद्देश्य होते हैं:आवास, कार, बाइक, आदि। हम उम्मीद कर सकते हैं कि उपयोगकर्ता अपनी संपत्तियों की देखभाल करेंगे। प्रत्येक संपत्ति के लिए, हमें परिभाषित करने की आवश्यकता होगी:
property_name- उस संपत्ति के लिए स्क्रीन नाम, उपयोगकर्ता द्वारा चुना गया। ऐप पर संभावित ग्राहकों को संपत्ति प्रदर्शित करते समय इस नाम का उपयोग किया जाता है। यह संक्षिप्त और वर्णनात्मक होना चाहिए और उस संपत्ति को अन्य संपत्तियों से अलग करना चाहिए।property_description- असंरचित प्रारूप में अतिरिक्त पाठ्य विवरण। हम यहां विवरणों के एक समूह की उम्मीद कर सकते हैं - मूल रूप से अपार्टमेंट के आकार से लेकर ग्राहकों के आने पर उन्हें स्वागत पेय मिलेगा या नहीं। परिवहन सेवाओं में स्वागत पेय होने की संभावना बहुत कम है।active_fromऔरactive_to- वह समयावधि जब वह संपत्ति हमारे सिस्टम में सक्रिय थी।active_toविशेषता के निष्क्रिय होने तक विशेषता में NULL मान होगा।है_उपलब्ध- एक झंडा यह दर्शाता है कि यह संपत्ति किसी विशिष्ट समय पर उपलब्ध है या नहीं।is_active- एक झंडा यह दर्शाता है कि क्या वह संपत्ति अभी भी हमारे सिस्टम में सक्रिय है। इस विशेषता का मान उसी क्षण गलत पर सेट कर दिया जाएगाactive_toसेट है।
अब हम सेवा की ओर बढ़ेंगे शब्दकोश। यह वह जगह है जहां हम "दीर्घकालिक किराया", "अल्पकालिक किराया", "परिवहन" इत्यादि जैसी सभी संभावित सेवाओं को परिभाषित करेंगे। इसमें सेवा प्रकार का अद्वितीय नाम और एक अतिरिक्त विवरण , यदि आवश्यक हो।
हम संबंधित संपत्तियों, सेवाओं और उपयोगकर्ताओं को प्रदान करते हैं . में रखेंगे टेबल। यह उस अवधि को संग्रहीत करेगा जब कोई संपत्ति उपलब्ध थी। परिवहन के मामले में, यह हमें बताएगा कि एक कार और ड्राइवर वास्तव में हमारी कंपनी के लिए कब काम कर रहे थे। अपार्टमेंट किराए के मामले में, यह हमें बताएगा कि संपत्ति कब उपलब्ध थी। यहां प्रत्येक रिकॉर्ड के लिए, हमारे पास होगा:
user_account_id- उस सेवा को प्रदान करने वाले उपयोगकर्ता की आईडी।service_id-सेवा . की आईडीप्रकार प्रदान किया गया।property_id- संदर्भसंपत्तिइस्तेमाल किया।time_fromऔरtime_to- जब इस संपत्ति का उपयोग इस सेवा को प्रदान करने के लिए किया गया था।time_toइस रिकॉर्ड के निष्क्रिय होने तक विशेषता में एक NULL मान होगा।is_active- एक बार इस संपत्ति का उपयोग नहीं किया जाएगा या जब यह उपयोगकर्ता इस सेवा को प्रदान करना बंद कर देगा, तो इसे गलत पर सेट कर दिया जाएगा। यह उसी समय सेट किया जाता है जबtime_toसेट है।
इस विषय क्षेत्र में शेष दो तालिकाएं दस्तावेजों से संबंधित हैं। (user_account तालिका मूल की एक प्रति है, जिसका उपयोग यहां संबंधों को अतिव्यापी होने से बचाने के लिए किया जाता है।) हमारी कंपनी कई संपत्ति मालिकों के साथ काम करेगी और व्यक्तिगत रूप से सब कुछ जांचने का लगभग कोई मौका नहीं होगा। सेवा की गुणवत्ता सुनिश्चित करने का एक तरीका यह है कि सब कुछ अच्छी तरह से प्रलेखित हो।
दस्तावेज़ों से संबंधित पहली तालिका है दस्तावेज़_प्रकार टेबल। इस सरल शब्दकोश में UNIQUE की एक सूची है type_name मूल्य। हम यहां "संपत्ति चित्र" और "स्वामी आईडी" जैसे मूल्यों की अपेक्षा कर सकते हैं।
सभी दस्तावेज़ों की सूची दस्तावेज़ . में संग्रहीत है टेबल। ये दस्तावेज़ उपयोगकर्ता खातों, संपत्तियों या दोनों से संबंधित हो सकते हैं। प्रत्येक दस्तावेज़ के लिए, हम स्टोर करेंगे:
दस्तावेज़_स्थान- उस दस्तावेज़ का पूरा पथ।document_type_id-दस्तावेज़_प्रकार . का संदर्भशब्दकोश।user_account_id-user_account . का संदर्भटेबल। यह विशेषता केवल तभी मान रखेगी जब दस्तावेज़ उपयोगकर्ता से संबंधित हो या यदि दस्तावेज़ संपत्ति से संबंधित है लेकिन उपयोगकर्ता भी उस संपत्ति का मालिक है।property_id- संबंधित संपत्ति . का संदर्भ ।is_active- यह दर्शाता है कि यह दस्तावेज़ अभी भी सक्रिय (वैध) है या नहीं।
अनुभाग 4:अनुरोध
इससे पहले कि हम कोई सेवा प्रदान कर सकें, हमें कुछ उपयोगकर्ता अनुरोध प्राप्त करने होंगे। अपार्टमेंट रेंटल में, ग्राहक वांछित संपत्ति के लिए अपना अनुरोध तब करेंगे जब उन्होंने लिस्टिंग की खोज की और उन्हें वह आवास मिल गया जो वे चाहते हैं। परिवहन सेवाओं के मामले में, ग्राहकों द्वारा मोबाइल एप्लिकेशन के माध्यम से अनुरोध किए जाते हैं (उदाहरण के लिए वे हवाई अड्डे पर हैं और उन्हें 20 मिनट में सवारी की आवश्यकता है)। हम अगले भाग में इस बारे में बात करेंगे कि हम अनुरोधों को कैसे संसाधित करते हैं; अभी के लिए, देखते हैं कि हम उन्हें कैसे प्रबंधित करते हैं।
इस विषय क्षेत्र में केंद्रीय तालिका अनुरोध . है टेबल। प्रत्येक अनुरोध के लिए, हम स्टोर करेंगे:
has_role_id- उपयोगकर्ता के लिए एक संदर्भ (और उसकी वर्तमान भूमिका,has_role . के माध्यम सेतालिका) जिसने यह अनुरोध किया था।request_status_id- उस अनुरोध की वर्तमान स्थिति का संदर्भ।status_time- टाइमस्टैम्प जब उस स्थिति को सौंपा गया था।service_id-सेवा . की आईडीउस अनुरोध के साथ आवश्यक है।city_id-शहर . का संदर्भजहां यह सेवा आवश्यक है।request_details- सभी अतिरिक्त अनुरोध विवरण, असंरचित पाठ्य प्रारूप में।is_processed- एक ध्वज यह दर्शाता है कि क्या यह अनुरोध संसाधित किया गया है (यानी सेवा प्रदाता को सौंपा गया है)।is_active- अगर ग्राहक ने अपना अनुरोध रद्द कर दिया है या किसी कारण से ऐप द्वारा अनुरोध रद्द कर दिया गया है, तो यह ध्वज गलत पर सेट किया जाएगा।
सभी संभावित स्थितियों की सूची request_status . में संगृहीत है status_name . के साथ शब्दकोश अद्वितीय (और केवल) मान के रूप में। हम "अनुरोध किया गया", "संपत्ति आरक्षित", "ड्राइवर को सौंपा गया", "ड्राइव प्रगति पर है", और "पूर्ण" जैसे मूल्यों की अपेक्षा कर सकते हैं।
request_status_history तालिका अनुरोधों से संबंधित सभी स्थितियों का इतिहास संग्रहीत करेगी। इस तालिका में प्रत्येक रिकॉर्ड के लिए, हम संबंधित अनुरोध की आईडी संग्रहीत करेंगे (request_id ), स्थिति आईडी (request_status_id ), उपयोगकर्ता खाता आईडी और उस स्थिति को सेट करते समय उपयोगकर्ता की भूमिका (has_role_id ) हम यह भी रिकॉर्ड करेंगे कि प्रत्येक स्थिति कब असाइन की गई थी (status_time )।
अनुभाग 5:प्रदत्त सेवाएं
अनुरोध रखे जाने के बाद, हमें इसे संसाधित करने की आवश्यकता है। एक अनुरोध या तो स्वचालित रूप से उपयुक्त सेवा प्रदाता को सौंपा जाएगा (अनुरोधित सेवा प्रकार, स्थान, आदि के आधार पर) या इसे सेवा प्रदाता द्वारा मैन्युअल रूप से स्वीकार किया जाएगा। इसे संभालने के लिए हमें केवल दो और तालिकाओं की आवश्यकता है।
पहला है प्रदत्त_सेवा टेबल। प्रत्येक रिकॉर्ड के लिए, हम शामिल करेंगे:
request_id- संबंधितअनुरोध . की आईडी।provides_id-प्रदान करता है . का संदर्भतालिका जो सेवा प्रदाता और इस कार्रवाई में शामिल संपत्ति को दर्शाती है।विवरण- सभी अतिरिक्त विवरण, संरचित पाठ प्रारूप में। इस संरचना में टैग और मान शामिल हो सकते हैं जो अनुरोध विवरण का वर्णन करते हैं। एक सवारी के लिए, इसका मतलब होगा आरंभ और समाप्ति बिंदु, तय की गई दूरी, आदि।प्रारंभ_समयऔरend_time- वह अवधि जिसके दौरान यह सेवा प्रदान की गई थी। ये दोनों मान तब सेट किए जाएंगे जब सेवा अभी शुरू और समाप्त होगी।grad_customerऔरग्रेड_प्रदाता- उस सेवा के लिए ग्राहक और सेवा प्रदाता द्वारा दिए गए ग्रेड।
हमारे मॉडल में अंतिम तालिका चालान . है टेबल। हम ग्राहकों से शुल्क लेंगे (customer_name ) प्रदान की गई सेवाओं के लिए (provided_service_id ) प्रत्येक चालान के लिए, हमें total_amount जानना होगा , भुगतान किया गया कोई भी शुल्क (fee_amount ), जब चालान जारी किया गया था (time_issued ), और इसका भुगतान कब किया गया था (time_paid ) भुगतान किया गया फ़ील्ड एक ध्वज के रूप में कार्य करता है जो दर्शाता है कि चालान का भुगतान किया गया है या नहीं।
आप हमारे साझा अर्थव्यवस्था डेटा मॉडल के बारे में क्या सोचते हैं?
आज हमने एक डेटा मॉडल पर चर्चा की जिसका उपयोग Airbnb या Uber जैसी कंपनी द्वारा किया जा सकता है। ऐसे व्यवसाय मॉडल की रीढ़ ग्राहक और सेवा प्रदाता हैं। मैं इस मॉडल में कई विवरण जोड़ सकता हूं। फिर भी, मैंने ऐसा नहीं करने का फैसला किया क्योंकि मॉडल जल्दी से बहुत बड़ा हो जाएगा। क्या आपको लगता है कि मुझे कुछ जोड़ना चाहिए था? अगर ऐसा है, तो कृपया मुझे नीचे कमेंट्स में बताएं।
