एक पेट केयर डेटा मॉडल

पालतू जानवरों की देखभाल एक बहुत बड़ा उद्योग है। क्या कोई डेटा मॉडल है जो पालतू जानवरों के मालिकों और पेशेवरों को उनकी गतिविधियों का प्रबंधन करने में मदद कर सकता है? अब है!

बहुत से लोग अपने जीवन को बिल्लियों, कुत्तों, पक्षियों और अन्य जानवरों के साथ साझा करते हैं। (मेरे पास एक समय के लिए एक कबूतर था, जब तक कि उसका पंख ठीक नहीं हो गया।) बहुत सारे पालतू जानवरों के मालिकों को यह एहसास नहीं होता है कि पालतू जानवरों की देखभाल कितनी बड़ी है। संयुक्त राज्य अमेरिका में, पालतू जानवरों के मालिकों ने $66.75 अरब खर्च किए - और वह सिर्फ 2016 में था!

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

पेट केयर डेटा मॉडल में क्या जाता है?

इससे पहले कि हम मॉडल के विवरण का वर्णन करना शुरू करें, आइए कुछ आवश्यकताओं पर चर्चा करें:

1. इस डेटा मॉडल की आवश्यकता किसे होगी?

   हालांकि यह डेटा मॉडल विदेशी लग सकता है, यह वास्तव में असामान्य नहीं है। ज़रा सोचिए कि आप ऊपर बताए गए किसी भी व्यवसाय को चला रहे हैं। कोई फर्क नहीं पड़ता कि ये व्यवसाय मॉडल कितने भिन्न हैं, फिर भी आपको यह करना होगा:

   • संभावित ग्राहकों के साथ संवाद करें
   • अपनी सेवाओं की व्याख्या करें और उनकी कीमतें बताएं
   • अपना शेड्यूल व्यवस्थित करें
   • प्रगति में चल रहे कार्यों और गतिविधियों को ट्रैक करें
   • प्रदान की गई सेवाओं के लिए ग्राहकों से शुल्क लें

   तो हाँ, एक मौका है कि आपको अपने लिए या अपने ग्राहकों के लिए इस मॉडल की आवश्यकता होगी।

   अब हम आगे बढ़ सकते हैं और कुछ तकनीकी सवालों के जवाब दे सकते हैं।

2. इस मॉडल में क्या शामिल किया जाना चाहिए?

   यह कई अलग-अलग स्थितियों को कवर करने के लिए पर्याप्त सामान्य होगा। मैं इस धारणा के साथ जाऊंगा कि हमारे पास एक भौतिक स्थान होगा जहां हम सेवाएं प्रदान करेंगे (जैसे एक पालतू होटल) या जो सेवाएं प्रदान करने के लिए प्रारंभिक बिंदु के रूप में कार्य करता है (यानी कुत्ते के चलने वाले के लिए)।

   हमें अलग-अलग पालतू जानवरों और उनके मालिकों के साथ-साथ हमारे द्वारा प्रदान की जाने वाली सेवाओं के रिकॉर्ड भी स्टोर करने होंगे। इन सभी से संबंधित अधिकांश पालतू-देखभाल मामलों को कवर करना चाहिए।

3. यह मॉडल क्यों महत्वपूर्ण है?

   समझाने के लिए, मैं आपको एक "भविष्यवाणी" के बारे में बताता हूँ जो मुझे लगता है कि सच होगी।

   हम सभी इस बात से अवगत हैं कि कैसे तकनीक व्यवसाय को बदल रही है। हम नौकरियों के बारे में लेख देखते हैं जो अगले 10 या 20 वर्षों में स्वचालन ले लेंगे। इनमें से अधिकतर नौकरियां संभवत:ऐसी होंगी जो मनुष्यों के संपर्क पर निर्भर नहीं हैं। उदाहरण के लिए, कई दुकानों में अब सेल्फ-चेकआउट लेन हैं जहां एक मानव कर्मचारी 5 या 10 चेकआउट की निगरानी कर सकता है। पहले, इनमें से प्रत्येक चेकआउट में एक कैशियर होता। लेकिन अपने किराने के सामान का भुगतान करने के लिए लाइन में इंतजार करना शायद आपके दिन का सबसे अच्छा पल नहीं है। और वह काम भी बहुत थका देने वाला और कम वेतन वाला होता है, इसलिए खजांची वास्तव में आपको देखकर उत्साहित नहीं होते हैं। इस प्रकार की नौकरियां स्वचालित हो सकती हैं और की जा रही हैं।

   नौकरियों का दूसरा सेट जो स्वचालित होगा, बौद्धिक रूप से अधिक चुनौतीपूर्ण है लेकिन कुछ हद तक दोहराव वाला है - उदा। लगभग सभी वित्तीय सेवाएं, अधिकांश कंप्यूटर प्रोग्रामिंग, और यहां तक ​​कि लेखन भी।

   तो, मेरी "भविष्यवाणी" यह है कि जिन नौकरियों के लिए बहुत अधिक मानव (या, इस मामले में, पालतू) संपर्क की आवश्यकता होती है, वे न केवल जीवित रहेंगे बल्कि "भविष्य की नौकरियां" बन जाएंगे; हम बात कर रहे हैं मनोवैज्ञानिकों, हेयर स्टाइलिस्टों, डॉग ग्रूमर्स और पेट सिटर आदि की। लेकिन उन्हें अपना व्यवसाय चलाने के लिए कुछ तकनीक की आवश्यकता होगी। और यहीं से यह मॉडल आता है।

डेटा मॉडल

इस डेटा मॉडल में चार विषय क्षेत्र शामिल हैं:

• Pets
• Facilities & services
• Cases
• Planned & provided

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

अनुभाग 1:पालतू जानवर

मैं Pets से शुरुआत करूंगा विषय क्षेत्र; आखिरकार, यह मॉडल यहां हमारे छोटे दोस्तों की वजह से है, जो उनके फर और पंख पहने हुए हैं। मैं इसे सरल रखूंगा, हालांकि इस विषय क्षेत्र का विस्तार किया जा सकता है। उदाहरण के लिए, हम पालतू जानवरों, उनकी विशेषताओं और पालतू जानवरों के मालिकों (और उनकी विशेषताओं 😊 ) का वर्णन करते हुए कई और विवरण संग्रहीत कर सकते हैं।

पूरे मॉडल में सबसे महत्वपूर्ण तालिका pet टेबल। प्रत्येक पालतू जानवर के लिए, हम स्टोर करेंगे:

• name - मालिक ने अपने पालतू जानवर को जो नाम दिया है।
• species_id - संदर्भ species शब्दकोश और पालतू प्रजातियों को दर्शाता है।
• birth_date - पालतू जानवर की जन्म तिथि, यदि उपलब्ध हो।
• notes - इस पालतू जानवर से संबंधित सभी अतिरिक्त नोट्स, निःशुल्क टेक्स्ट प्रारूप में।

owner तालिका में, हम अपने सभी अतीत, वर्तमान और संभावित ग्राहकों की एक सूची संग्रहीत करेंगे। व्यक्तिगत रूप से, मुझे "मालिक" शब्द पसंद नहीं है, क्योंकि जब आप अपने पालतू जानवरों के साथ रहते हैं तो वे परिवार के सदस्यों की तरह अधिक होते हैं। लेकिन मैं इसे डेटा मॉडल में उपयोग करने के लिए ठीक हूं। इसलिए, प्रत्येक स्वामी के लिए, हम उनका first_name संग्रहित करेंगे और last_name , संपर्क विवरण (जैसा कि हम उन्हें जानते हैं, हम उन सभी को नहीं जानते हैं) और notes में कोई अतिरिक्त विवरण विशेषता।

हम pet_owner टेबल। एक मालिक के पास कई पालतू जानवर हो सकते हैं और एक पालतू जानवर के दो मालिक हो सकते हैं, इसलिए हमें यहां कई-से-अनेक संबंध डालने होंगे। प्रत्येक रिकॉर्ड के लिए, हम एक अद्वितीय pet_id संग्रहित करेंगे - owner_id जोड़ी।

इस विषय क्षेत्र में तीसरी और अंतिम तालिका species शब्दकोश। प्राथमिक कुंजी विशेषता के अलावा id , इसमें केवल UNIQUE species_name . है मूल्य। हम इस शब्दकोश का उपयोग प्रजातियों की जानकारी को व्यवसाय के लिए आवश्यक स्तर पर संग्रहीत करने के लिए करेंगे। हम "बिल्ली", "कुत्ता", "घोड़ा", और "पक्षी" जैसे सरल मूल्यों के एक सेट के साथ जा सकते हैं। या हम "बिल्ली - मेन कून", "बिल्ली - मंचकिन", आदि जैसे अधिक वर्णनात्मक मूल्यों का उपयोग कर सकते हैं। हम एक अधिक जटिल संरचना को नियोजित कर सकते हैं - यानी प्रजातियों के लिए एक टेबल और दूसरी नस्लों के लिए - लेकिन मुझे नहीं लगता कि यह दृष्टिकोण मॉडल में कुछ भी नया लाएगा।

अनुभाग 2:सुविधाएं और सेवाएं

इस मॉडल में दूसरी सबसे महत्वपूर्ण बात वे सेवाएं हैं जो हम प्रदान करेंगे। हमें सुविधाओं की भी आवश्यकता होगी, चाहे हम पालतू जानवरों के मालिकों को कुछ भी दें। यह एक जगह हो सकती है, जैसे कि पालतू जानवरों का होटल, या यह एक ऐसा स्थान हो सकता है जहां हम पालतू जानवरों को उठाते या छोड़ते हैं (जैसे कि एक कुत्ता वॉकर का उपयोग करेगा)। हम इस जानकारी को Facilities & services . में संग्रहित करेंगे विषय क्षेत्र।

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

• service_name - एक ऐसा नाम जो किसी सेवा को विशिष्ट रूप से परिभाषित करता है।
• has_limit - एक मान जो दर्शाता है कि क्या इस सेवा की कोई सीमा है (उदा. पालतू होटल में "बेड" की संख्या)।
• unit_id - वह इकाई जिसका उपयोग हम उस सेवा को मापने के लिए करेंगे। यह हमारे द्वारा प्रदान की जाने वाली सेवा के प्रकार पर निर्भर करता है और यदि इसके लिए समय या सामग्री (या दोनों) की आवश्यकता होती है। ज्यादातर मामलों में, हम समय के बारे में चिंतित होंगे। उदाहरण के लिए, यदि कोई कुत्ता पालतू होटल में रहता है, तो उपयोग की जाने वाली इकाई "दिन" होनी चाहिए। दूसरी ओर, यदि हम कुत्ते को टहला रहे हैं, तो इकाई "घंटा" या "मिनट" होनी चाहिए। समय इकाइयों के अलावा, हम अन्य उपायों का भी उपयोग कर सकते हैं, उदा। अगर हम कुत्ते को "प्रदान" किए जाने वाले व्यवहारों की संख्या को परिभाषित करना चाहते हैं।
• cost_per_unit - उस सेवा के लिए प्रति यूनिट वर्तमान लागत।

unit शब्दकोश का उपयोग UNIQUE की सूची को संग्रहीत करने के लिए किया जाता है unit_name मूल्य। इस शब्दकोश के मान केवल service तालिका, लेकिन वे नियोजन चरण में बहुत महत्वपूर्ण हैं और जब हम प्रदान की गई सेवाओं के लिए ग्राहकों से शुल्क लेते हैं।

प्रत्येक सेवा के लिए, हमें प्रत्येक स्वीकृत प्रजाति को भी परिभाषित करना होगा। उदाहरण के लिए, शायद हम केवल बिल्लियों के लिए पालतू होटल सेवा प्रदान करेंगे, कुत्तों के लिए नहीं। यह इस तथ्य की परवाह किए बिना हो सकता है कि हम कुत्ते को चलने और संवारने की पेशकश करते हैं। हम सभी UNIQUE service_id स्टोर करेंगे - speices_id available_for टेबल।

अपनी सभी सेवाओं और उनके विवरणों का वर्णन करने के बाद, अब हम उन सुविधाओं (स्थानों) का वर्णन करेंगे जहां हम ये सेवाएं प्रदान करेंगे।

इस बात की अच्छी संभावना है कि हम एक से अधिक सुविधाएं संचालित करेंगे और एक से अधिक सेवाएं प्रदान करेंगे। उसके कारण, हमें अपनी सभी सुविधाओं और उनके संबंधित विवरणों को संग्रहीत करने की आवश्यकता होगी। हम facility ट्रैक करने के लिए तालिका:

• facility_name - एक नाम जिसका उपयोग हम आंतरिक रूप से उस सुविधा को विशिष्ट रूप से दर्शाने के लिए करेंगे।
• address , phone , email और contact_person - स्थान और संपर्क जानकारी, जो काफी हद तक आत्म-व्याख्यात्मक हैं।

प्रत्येक सुविधा के लिए, हम यह संग्रहीत करेंगे कि वह कौन-सी सेवाएँ प्रदान करती है। हमारे पास केवल बिल्लियों के लिए एक सुविधा हो सकती है और दूसरी केवल कुत्तों के लिए। या हमारे पास एक सुविधा में एक पशु चिकित्सा तकनीशियन हो सकता है और दूसरे में नहीं। किसी भी स्थिति में, हमें उन सभी सेवाओं को संग्रहीत करने की आवश्यकता होगी जो हम प्रत्येक सुविधा में प्रदान करने में सक्षम हैं। provides तालिका में, हम एक अद्वितीय facility_id संग्रहित करेंगे - service_id जोड़ा। उस मामले में service .has_limit क्योंकि संदर्भित सेवा सत्य है, हमें service_limit . को भी परिभाषित करना होगा उस सुविधा के लिए भी currently_used मात्रा। हर बार जब हम उस सुविधा में एक और पालतू जानवर के लिए वह सेवा प्रदान करना शुरू करते हैं तो उस मूल्य की पुनर्गणना की जानी चाहिए (उदाहरण के लिए पालतू होटल में एक और जगह ली जाती है) या हम इसे पालतू जानवर को प्रदान करना बंद कर देते हैं (उदाहरण के लिए होटल में उपलब्ध पालतू बिस्तरों की संख्या एक से बढ़ गया है)।

धारा 3:मामले

Cases विषय क्षेत्र वह है जहां हम विज़िट या सत्रों से संबंधित सभी डेटा का वर्णन और संग्रह करेंगे (यानी एक विज़िट हमारे कुत्ते के होटल में एक ठहरने, एक सौंदर्य, एक चलना इत्यादि)

case टेबल पालतू जानवरों और सत्रों, कॉलों या यात्राओं से संबंधित सुविधाओं को संग्रहीत करता है। मैंने तालिका के नाम के रूप में "केस" का उपयोग करने का निर्णय लिया है क्योंकि हम यहां केवल विज़िट को संग्रहीत नहीं कर सकते हैं। शायद हम कॉल या अन्य संपर्कों को स्टोर करना चाहते हैं। प्रत्येक मामले के लिए, हम स्टोर करेंगे:

• facility_id - संबंधित सुविधा की आईडी। यह वह जगह हो सकती है जहां पालतू (होटल में) रुका था या वह सुविधा जिसे इस मामले से संबंधित कॉल प्राप्त हुई थी।
• pet_id - शामिल पालतू जानवर की आईडी.
• start_time - वास्तविक टाइमस्टैम्प जब वह मामला शुरू हुआ था।
• end_time - वास्तविक टाइमस्टैम्प जब वह मामला समाप्त हुआ। मामला बंद होने तक यह NULL रहेगा।
• notes - उस मामले से संबंधित कोई भी अतिरिक्त नोट, पाठ्य प्रारूप में।
• closed - यह मामला बंद है या नहीं। end_time . होने पर इसे "True" पर सेट कर दिया जाएगा सेट है।

हम facility_id . के संयोजन का उपयोग करेंगे - pet_id - start_time इस तालिका की अद्वितीय कुंजी के रूप में।

प्रत्येक मामले में एक या अधिक स्थितियाँ निर्दिष्ट होंगी। हम उम्मीद कर सकते हैं कि सौंपी गई पहली स्थिति यह बताएगी कि मामला कब शुरू हुआ। उसके बाद, जब तक मामला सुलझता (बंद) नहीं हो जाता, हम आवश्यकतानुसार नई स्थितियां निर्दिष्ट करेंगे।

यहां पहला शब्दकोश है status_category शब्दकोश। इसमें UNIQUE की एक सूची है status_category_name मूल्य। ये प्रकार के अनुसार समूह स्थिति हैं, उदा. "शारीरिक स्थिति", "भूख", या "सामान्य स्थिति"।

सभी संभावित स्थितियों को status शब्दकोश। प्रत्येक स्थिति के लिए, हम उसका status_name स्टोर करेंगे , उस स्थिति श्रेणी की आईडी जिससे वह संबंधित है, और is_closing_status मूल्य। अगर is_closing_status . है मान "सत्य" है, इसका अर्थ है कि जब हम यह स्थिति निर्दिष्ट करते हैं, तो मामला बंद के रूप में चिह्नित किया जाएगा। status_name - status_category_id जोड़ी इस तालिका की अद्वितीय कुंजी बनाती है।

case_status तालिका में, हम उन सभी स्थितियों को संग्रहीत करेंगे जो वास्तव में मामलों को सौंपी गई थीं। इस तालिका में प्रत्येक रिकॉर्ड के लिए, हम case और status टेबल, कोई भी अतिरिक्त notes , और insert_time उस स्थिति का। उदाहरण के लिए, हम पालतू जानवर की वर्तमान शारीरिक स्थिति और भूख को स्थिति के रूप में स्टोर कर सकते हैं जब पालतू हमारी सुविधा में आता है। इन स्थितियों को बदल दिया जाएगा यदि हमने उनकी स्थिति में कोई परिवर्तन देखा। दूसरी ओर, हम प्रत्येक मामले से संबंधित स्थितियाँ भी संग्रहीत करेंगे (उदा. "कुत्ता चला गया था"); हम उस स्थिति के बारे में कोई भी अतिरिक्त विवरण notes . में डाल देंगे गुण। ये स्थितियां "समापन" स्थिति नहीं होंगी क्योंकि वे ए) उस समय पालतू जानवर की वर्तमान स्थिति, या बी) सत्र या यात्रा के दौरान की गई कार्रवाइयों से संबंधित हैं। "क्लोजिंग" स्थिति का एक उदाहरण हमारे पालतू होटल का "डॉग चेक आउट" हो सकता है।

इस खंड में अंतिम तालिका note टेबल। हम इस तालिका का उपयोग उन मामलों से संबंधित सभी नोटों को संग्रहीत करने के लिए करेंगे जब नई स्थिति सम्मिलित करने की कोई आवश्यकता नहीं होगी। प्रत्येक रिकॉर्ड के लिए, हम note_text स्टोर करेंगे , संबंधित मामले की एक आईडी, और insert_time जब वह नोट बनाया गया था।

अनुभाग 4:नियोजित और प्रदान किया गया

अंतिम विषय क्षेत्र है Planned & provided विषय क्षेत्र। इस विषय क्षेत्र की तीन तालिकाएँ उन सेवाओं के बारे में डेटा संग्रहीत करती हैं जिन्हें हमने प्रदान करने की योजना बनाई है, जो वास्तव में प्रदान की गई हैं, और मामलों से संबंधित सभी चालान।

service_planned तालिका में उन सभी सेवाओं की सूची है जो हमने अपने ग्राहकों को प्रस्तावित की हैं या जिन्हें उन्होंने आरक्षित किया है। प्रत्येक रिकॉर्ड में निम्न शामिल होंगे:

• case_id - संबंधित मामले की आईडी।
• service_id - संबंधित सेवा की आईडी।
• planned_start_time &planned_end_time - जब हम इस सेवा को शुरू करने और खत्म करने की योजना बनाते हैं। प्रारंभ समय परिभाषित किया जाना चाहिए लेकिन समाप्ति समय शून्य हो सकता है।
• planned_units - नियोजित सेवा इकाइयों की संख्या, उदा। पालतू होटल में 3 दिन।
• cost_per_unit - उस समय प्रति यूनिट लागत। इस मान को संग्रहीत करना महत्वपूर्ण है क्योंकि service . में संग्रहीत मान .cost_per_unit आरक्षण किए जाने के समय और इसे किए जाने के समय के बीच बदल सकता है।
• planned_price - उस सेवा के लिए उद्धृत मूल्य। यह planned_units . के बराबर होना चाहिए * cost_per_unit ।
• notes - नियोजित सेवा से संबंधित कोई अतिरिक्त नोट।

service_provided तालिका की संरचना लगभग service_planned टेबल। फर्क सिर्फ इतना है कि units और price_charged विशेषताओं में NULL मान हो सकते हैं। यह इस तथ्य के कारण है कि जब हम सेवा प्रदान करना शुरू करते हैं तो हम इस तालिका में एक रिकॉर्ड डाल सकते हैं (उदाहरण के लिए जब पालतू पालतू होटल में प्रवेश करता है) और जब हम सेवा प्रदान करना बंद कर देते हैं तो हम उन्हें अपडेट कर देंगे (उदाहरण के लिए जब मालिक लेता है पालतू घर)।

हमारे मॉडल में अंतिम तालिका invoice टेबल। यह उन सभी चालानों की एक सूची रखता है जो हमने अपने सभी मामलों के लिए बनाए हैं। प्रत्येक चालान के लिए, हम संग्रहित करेंगे:

• invoice_code - प्रत्येक चालान के लिए उत्पन्न एक आंतरिक अद्वितीय संख्या।
• case_id - संबंधित मामले की आईडी।
• time_generated - जब चालान बनाया गया था।
• invoice_amount - मूल राशि जो हम ग्राहक से वसूल रहे हैं। यह राशि price_charged . में सभी मानों के योग के बराबर होनी चाहिए service_provided . के लिए ।
• discount - क्लाइंट को दी गई छूट (जैसे कूपन, लॉयल्टी कार्ड आदि के कारण। कारण वास्तव में मायने नहीं रखता।)
• time_charged - जब क्लाइंट से वास्तव में उस इनवॉइस के लिए शुल्क लिया गया था। भुगतान किए जाने तक इस विशेषता में एक NULL मान होगा।
• amount_charged - वास्तविक राशि जो उस चालान के लिए क्लाइंट से ली गई थी।
• notes - उस चालान से संबंधित कोई भी अतिरिक्त नोट।

आप क्या जोड़ेंगे?

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