मुझे एक ड्राइविंग स्कूल के लिए आरक्षण प्रणाली के लिए एक डेटा मॉडल तैयार करने की आवश्यकता है। विषय क्षेत्र काफी सीधा दिखता है, लेकिन जटिलताएं अभी भी शामिल हैं। आपको ग्राहकों के सभी अनुरोधों को ट्रैक करना होगा और पाठों के दौरान खर्च किए गए संसाधनों (वाहन, समय और प्रशिक्षक) का ट्रैक रखना होगा।
परिचय
मुझे डोमेन संचालित दृष्टिकोण का उपयोग करना पसंद है डेटा मॉडल डिजाइन करने के लिए। यह मुझे प्रौद्योगिकी जुनून को एक तरफ रख देता है और मुख्य रूप से संबंधित संस्थाओं और आपस में संबंधों के इर्द-गिर्द घूमने वाले विषय क्षेत्र की मॉडलिंग पर ध्यान केंद्रित करता है।
आवश्यकताएं संक्षेप में
पहले मैं इस आवश्यकता को पहले सादे अंग्रेजी में लिख दूं।
ग्राहकों . को अनुमति देने के लिए मुझे ड्राइविंग स्कूल के लिए एक डेटा मॉडल चाहिए आरक्षण . करने के लिए सबक . के लिए ऑनलाइन। ड्राइविंग स्कूल में एक से अधिक प्रशिक्षक . हो सकते हैं और एक से अधिक वाहन . प्रशिक्षक को आरक्षण पर पाठ के लिए सौंपा गया है। सिस्टम को ग्राहकों को निर्धारित दिन से पहले किसी भी समय आरक्षण रद्द करने की अनुमति देनी चाहिए। यदि पाठ होता है तो पाठ को सौंपे गए वाहन को भी रिकॉर्ड किया जाना चाहिए।
शामिल निकाय और संबंध
जब मैं इस विषय के बारे में सोचता हूं, तो मेरे दिमाग में सबसे पहले जो संस्थाएं आती हैं, वे हैं “ग्राहक” , “प्रशिक्षक” , “ड्राइविंग सबक” , “आरक्षण अनुरोध” और “वाहन” . मैं इस मॉडल के लिए अपनी पहली तालिका से शुरू करता हूं, और वह है customer . यह ग्राहकों के लिए मास्टर डेटा स्टोर करना है। मुझे शायद प्रशिक्षक के विवरण को संग्रहीत करने के लिए एक और तालिका की आवश्यकता होगी, लेकिन प्रशिक्षक के नाम से एक तालिका बनाने के बजाय, मैं staff कर्मचारियों के विवरण के लिए और "प्रशिक्षक" को नौकरी के शीर्षक के रूप में रखें। यह मेरे डेटा मॉडल को ड्राइविंग स्कूल के प्रशासनिक और कानूनी कार्य जैसे अन्य सेवा क्षेत्रों को पूरा करने के लिए एक्स्टेंसिबल बना देगा।
मैं “ड्राइविंग कोर्स” . पर विचार करता हूं सेवाओं में से एक के रूप में, इस प्रकार मैं service . एक सेवा, “ड्राइविंग कोर्स” इस मामले में, कई सबक हो सकते हैं। इस आवश्यकता को पूरा करने के लिए, मुझे निश्चित रूप से एक और मास्टर टेबल की आवश्यकता है, जिसका नाम है lesson , और एक संबंध तालिका, अर्थात् service_lesson , इन दोनों मास्टर संस्थाओं के बीच कई से कई संबंधों को प्रबंधित करने के लिए, अर्थात एक सेवा में निश्चित रूप से कई पाठ हो सकते हैं, लेकिन दूसरी ओर, एक पाठ एक से अधिक सेवाओं का हिस्सा भी हो सकता है।
जब कोई आरक्षण अनुरोध जमा करता है, तो उसे अपना विवरण और प्रारंभिक प्राथमिकताएं भरने के लिए कहा जाता है जैसे कि वह किस प्रकार की सेवा चाहता है, वाहन के लिए विकल्प और प्रारंभ तिथि। ग्राहक का विवरण ग्राहक तालिका में संग्रहीत किया जाता है। इसके बाद, request तालिका, और सभी प्राथमिकताओं को एक ही तालिका में अनुरोध के विरुद्ध संग्रहीत किया जाता है। प्रत्येक अनुरोध से जुड़ी कुछ स्थितियां होती हैं, जैसे "सबमिट", "इन-प्रोसेस", "रद्द करें" और "पूर्ण"। मैं इसके लिए एक सहायक तालिका बनाऊंगा जिसे request_status .
अनुरोध जमा करने के समय, वाहन, यानी वाहन के प्रकार के लिए वरीयता दी जाती है। हालांकि, वाहन को वास्तव में एक सबक के लिए सौंपा जाएगा जब यह होता है। इसलिए मैं vehicle_type_id रखता हूं request अभी के लिए तालिका।
जब कोई अनुरोध संसाधित किया जाता है, तो सेवा अनुरोध के प्रत्येक पाठ के लिए आरक्षण किया जाता है। इसके अलावा, प्रत्येक पाठ के लिए प्रशिक्षकों और वाहनों को प्रशिक्षकों की उपलब्धता और वाहनों के लिए ग्राहकों की प्राथमिकताओं के आधार पर सौंपा गया है। पाठ भविष्य की तारीखों के लिए "खुला" स्थिति के साथ निर्धारित हैं। ये सभी विवरण reservation . मैंने सभी लेन-देन तालिकाओं को सभी मास्टर तालिकाओं की तुलना में एक अलग रंग के साथ हाइलाइट किया है।
एक मास्टर टेबल, reservation_status , "खुले", "इन-प्रोसेस", "रद्द करें" और "पूर्ण" जैसी आरक्षण स्थितियों के लिए सभी संभावित मानों को संग्रहीत करने के लिए बनाया गया है।
यह मॉडल ग्राहक को व्यक्तिगत पाठ के साथ-साथ सेवा अनुरोध को समग्र रूप से रद्द करने की अनुमति देता है। यदि ग्राहक सेवा अनुरोध को रद्द कर देता है, तो शेष सभी पाठ, जो ग्राहक के लिए निर्धारित हैं, आरक्षण तालिका में रद्द कर दिए जाते हैं।
कृपया इन सभी तालिकाओं के कॉलम स्तर के विवरण के लिए वर्टाबेलो का उपयोग करके मेरे द्वारा बनाए गए डेटा मॉडल को देखें। स्तंभ निर्माण के संबंध में कुछ बिंदु:
- एक ध्वज स्तंभ जिसका नाम
is_activeहै रिकॉर्ड्स को सॉफ्ट डिलीट करने में सक्षम बनाने के लिए सभी मास्टर टेबल में जोड़ा जाता है। उदाहरण के लिए, यदि कोई प्रशिक्षक स्कूल छोड़ देता है, तो हम उसका रिकॉर्ड निष्क्रिय करने के लिए ध्वज को "N" पर फ़्लिप कर देंगे। - कुछ कॉलम जैसे
created_date,created_by,last_modified_dateऔरlast_modified_byरिकॉर्ड में बदलाव के लिए ऑडिट ट्रेल को सक्षम करने के लिए सभी ट्रांजेक्शन टेबल में जोड़े जाते हैं। Vertabelo में बनाए गए डेटा मॉडल में लेन-देन तालिकाओं को नीले रंग में हाइलाइट किया गया है। - आप सोच रहे होंगे कि
address_id. क्या हैstaffतालिका के लिए है। मैंने जानबूझकर इस कॉलम कोstaffतालिका ताकि मैं अपने डेटा मॉडल का विस्तार एक स्वचालित प्रक्रिया का समर्थन करने के लिए कर सकूं ताकि प्रशिक्षक को उसके स्थान के आधार पर अनुरोध करने के लिए असाइन किया जा सके। उदाहरण के लिए, मान लीजिए कि न्यूयॉर्क शहर में, व्हाइट प्लेन्स से एक अनुरोध आता है। मेरे सिस्टम को पहले उसी या निकटतम क्षेत्र में उपलब्ध प्रशिक्षक की तलाश करनी चाहिए। मेरे सिस्टम को मैनहट्टन में रहने वाले प्रशिक्षक को कभी भी नियुक्त नहीं करना चाहिए, जो अनुरोधकर्ता के स्थान से लगभग 50 मील दूर है।
इस मॉडल की मुख्य विशेषताएं
- यह मॉडल ग्राहकों को प्रारंभ तिथि और वाहन के लिए उनकी प्राथमिकताओं के अनुसार आरक्षण अनुरोध करने की अनुमति देता है।
- इससे वे अपने पाठ्यक्रम के एक या अधिक पाठों को या स्वयं पूरे पाठ्यक्रम को रद्द कर सकते हैं।
- यह मॉडल प्रत्येक पाठ के लिए प्रशिक्षक और वाहन के विवरण को कैप्चर करता है।
- यह मॉडल ड्राइविंग स्कूल द्वारा प्रदान की जाने वाली सभी संभावित सेवाओं को संभालने के लिए एक्स्टेंसिबल है।
- यह हमें प्रशिक्षण पाठ्यक्रम तैयार करने और प्रभावी ढंग से पाठों की योजना बनाने में सक्षम बनाता है।
डेटाबेस मॉडल
यहाँ हमारे आरक्षण प्रणाली के लिए डेटाबेस डिज़ाइन है। मॉडल Oracle डेटाबेस के लिए Vertabelo में बनाया गया था लेकिन समान डिज़ाइन को अन्य डेटाबेस इंजनों के लिए महत्वपूर्ण परिवर्तनों के बिना लागू किया जा सकता है।
निष्कर्ष
कुछ ऐसे विषय क्षेत्र हैं जिन्हें हमने इस लेख में शामिल नहीं किया है, जैसे:
- क्या हम पाठों के लिए वाहनों और प्रशिक्षकों को आवंटित करने के लिए एक स्वचालित दृष्टिकोण बना सकते हैं?
- ग्राहकों का चालान कैसे करें? क्या होगा यदि कोई ग्राहक पूरे पाठ्यक्रम के लिए भुगतान नहीं करना चाहता है, लेकिन इसके कुछ पाठों के लिए? क्या हम ये पाठ उसे उपलब्ध करा सकते हैं?
क्या हमारा मौजूदा मॉडल ऐसी सुविधाओं का समर्थन करता है? जवाब न है। मैं शायद अपने अगले लेख में इन विषय क्षेत्रों को कवर करूंगा।
