डेटाबेस मॉडलिंग पर ब्लॉग पोस्ट लिखते समय, आपको तैयार रहना चाहिए कि आपका सार मॉडल अधिकांश पाठकों की जरूरतों को पूरा नहीं करता है। वजह साफ है। वास्तविक जीवन डेटाबेस मॉडल आमतौर पर विशिष्ट व्यवसाय और विकास आवश्यकताओं के निकट संबंध में बनाए जाते हैं जबकि ब्लॉग मॉडल नहीं होते हैं।
पिछले कुछ हफ्तों से, मैं डेटाबेस मॉडल बनाने के बारे में ब्लॉग पोस्ट लिख रहा हूँ। विषय एक सामान्य ऑनलाइन फ़ोरम के माध्यम से डेटाबेस मॉडलिंग के लिए एक सामान्य दृष्टिकोण से लेकर अधिक जटिल ऑनलाइन सर्वेक्षण के लिए एक मॉडल तक थे।
मेरे द्वारा बनाए गए प्रत्येक डेटाबेस मॉडल के लिए, मैं व्यवसाय डोमेन को स्पष्ट रूप से समझने की कोशिश करता हूं और मेरे दिमाग में मॉडल की बड़ी तस्वीर तैयार करता हूं।
अमूर्त डेटाबेस विकास की चुनौती
आम तौर पर, समाधान के रूप में वास्तुकार , मैं विशिष्ट व्यावसायिक आवश्यकताओं को लेता हूं और उन्हें तकनीकी विवरण में परिवर्तित करता हूं जिसे तकनीकी पक्ष से बनाने की आवश्यकता है:अनुवाद व्यावसायिक भाषा से तकनीकी भाषा में - एल्गोरिदम को उच्च स्तर पर डिजाइन करना और एल्गोरिदम के लिए डेटा आवश्यकताओं को मॉडलिंग करना।
दुर्भाग्य से, मैं वास्तविक विश्व डेटाबेस मॉडल के बारे में ब्लॉग नहीं कर सकता जो मैं काम पर बनाता हूं। एक बात के लिए, वे व्यवसाय डोमेन के लिए बहुत विशिष्ट हैं और दूसरे के लिए मैं गोपनीयता समझौतों द्वारा प्रतिबंधित हूं। ब्लॉग के लिए, मैं पूरी तरह से सार बना देता हूं बिना किसी विशिष्ट व्यावसायिक आवश्यकताओं वाली अवधारणा, सिवाय उन लोगों के जिनकी मैं कल्पना करता हूं कि व्यवसाय डोमेन के भीतर मौजूद हैं। अब, यह ठीक है; मेरे पास एक बहुत अच्छी कल्पना है और मैं बार-बार इंगित करता हूं कि जब मैं अपने द्वारा किए जा रहे विकल्पों का वर्णन करता हूं तो आपकी आवश्यकताएं भिन्न हो सकती हैं। लेकिन इस ब्लॉगिंग प्रक्रिया ने मुझे सोचने पर मजबूर कर दिया कि यह प्रक्रिया वास्तविक प्रोजेक्ट में मॉडल बनाने से कितनी अलग है।
वास्तविक जीवन विकास प्रक्रिया
एक वास्तविक स्थिति में, मैं एक इंटरैक्टिव में उच्च स्तरीय समाधान और तकनीकी डिजाइन तैयार करने के बाद विकास टीम के साथ मिलकर काम करूंगा। ताकि मॉडल विकास की जरूरतों को पूरा कर सके।
डेवलपर्स शिकायत कर सकते हैं कि उच्च-प्रदर्शन का समर्थन करने के लिए डेटा मॉडल बहुत सामान्यीकृत है, या वे कुछ क्षेत्रों में अतिरिक्त सामान्यीकरण के लिए कह सकते हैं। यदि कोई वैकल्पिक कुंजी गायब थी, तो डेवलपर्स बहुत जल्दी शिकायत करेंगे और हम इसे डेटाबेस के प्रदर्शन परीक्षण के दौरान भी देखेंगे।
हम इस बात पर विचार करेंगे कि संग्रहीत किए जाने वाले डेटा की अधिकतम लंबाई और डेटा के इनपुट और प्रदर्शन के लिए स्क्रीन के डिज़ाइन पर आधारित सटीक फ़ील्ड लंबाई क्या होनी चाहिए। बेशक, एक वैचारिक डेटाबेस मॉडल में सटीक फ़ील्ड लंबाई महत्वपूर्ण नहीं है।
हम उदाहरणों के माध्यम से काम करेंगे कि कौन सा डेटा तालिकाओं में संग्रहीत किया जाएगा और एप्लिकेशन द्वारा इसका उपयोग कैसे किया जाएगा, और एप्लिकेशन के यूनिट परीक्षण के लिए तालिकाओं को पूर्व-पॉप्युलेट करने के लिए स्क्रिप्ट बनाएं। इस तरह, हम यह सुनिश्चित करने के लिए कोने के मामलों को पकड़ लेंगे कि मॉडल आवेदन की सीमाओं का समर्थन करता है।
इसलिए, मूल रूप से, हम मॉडल की तब तक मालिश करेंगे जब तक कि यह वास्तव में एक पुनरावृत्त प्रक्रिया का उपयोग करके सिस्टम की व्यावसायिक और गैर-कार्यात्मक आवश्यकताओं का समर्थन नहीं करता है, जब तक कि हम एक मॉडल को किसी ऐसी चीज़ में विकसित नहीं कर लेते हैं जिसे हम सभी इसमें अंतर्निहित समझौतों के बावजूद स्वीकार कर सकते हैं।
जैसा कि मैंने कहा, यह एक बहुत ही चलने वाली प्रक्रिया होगी जो कई महीनों तक जारी रह सकती है, जबकि एप्लिकेशन कोड, यूजर इंटरफेस और एप्लिकेशन इंटरफेस विकसित किए जा रहे हैं।
सुविचारित फ़ीडबैक की सीमाएं
वर्तमान ब्लॉगिंग स्थिति में, जबकि मेरे पाठकों की सीमित संख्या मुझे उन मुद्दों और चुनौतियों पर प्रतिक्रिया प्रदान करती है जो वे मॉडल के साथ देखते हैं, यह अनिवार्य रूप से सतही है। मुझे संदेह है कि कोई भी पाठक एप्लिकेशन बनाने के लिए सीधे मॉडल का उपयोग कर रहा है और यह पता लगाता है कि वास्तव में क्या काम करता है और कहां समस्याएं हैं।
तो "मॉडल अच्छी तरह से सोचा नहीं गया" जैसी टिप्पणियां लगभग निश्चित रूप से सही हैं। दूसरी ओर, "वहाँ FK गायब हैं" काफी सटीक हैं, लेकिन उम्मीद है कि मैंने लेख के पाठ में समझाया है कि मैं एक विदेशी कुंजी क्यों शामिल कर रहा हूं या नहीं।
निष्कर्ष
अब, कृपया इस पोस्ट को शिकायत के रूप में या पाठकों द्वारा की जा रही प्रतिक्रिया के बारे में टिप्पणी के रूप में न पढ़ें, बल्कि मैं एक डेटाबेस मॉडल बनाने की कठिनाई पर विचार कर रहा हूं जब आप ऐसे वातावरण में नहीं हैं जो एक पुनरावृत्ति के साथ एक इंटरैक्टिव एक्सचेंज की अनुमति देता है। विकास प्रक्रिया।
शायद ऐसी और भी स्थितियां हैं जहां डेटाबेस मॉडलर विकास प्रक्रिया से कट गए हैं, लेकिन अब मुझे एहसास हुआ है कि यह कितना खतरनाक होगा और वे कितनी समस्याओं से ग्रस्त होंगे।
क्या आप एक ऐसे डेटाबेस मॉडल की कल्पना कर सकते हैं जो कभी नहीं बदला जाता है? कभी भी एक कॉलम का एक भी समायोजन नहीं, कभी भी एक विदेशी कुंजी का अतिरिक्त नहीं, कभी भी एक नई तालिका की आवश्यकता नहीं होती है। ईमानदारी से, मैं इस तरह की एकमात्र स्थिति की कल्पना कर सकता हूं जब डेटाबेस का उपयोग करने वाला एप्लिकेशन अब विकसित नहीं हो रहा है और एक मृत अंत तक पहुंच गया है:जीवन का अंत।
