बेहतर डेटाबेस डिजाइन के लिए टिप्स

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

योजना में विफल होना विफल होने की योजना बना रहा है।

एलन लेकिन

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

अनुप्रयोग विकास में, डेटा की प्रकृति को समझना महत्वपूर्ण है।

योजना को अक्सर नजरअंदाज कर दिया जाता है ताकि डेवलपर्स सिर्फ "कोडिंग शुरू कर सकें"। परियोजना शुरू होती है और जब मुद्दे सामने आते हैं, तो उन्हें हल करने के लिए कार्यक्रम में कोई कमी नहीं होती है। डेवलपर्स शॉर्टकट को बाद में ठीक करने के इरादे से लेते हैं लेकिन ऐसा शायद ही कभी होता है।

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

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

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

तो यह एजाइल नहीं है जो डेटाबेस मॉडलर के लिए मुद्दा है, बल्कि ऐसे व्यक्ति हैं जो डेटा की प्रकृति को नहीं समझते हैं। कुछ लोग डेटाबेस विकास को अनुप्रयोग विकास के समान ही देखते हैं। डेटाबेस मॉडलिंग और सॉफ्टवेयर विकास अलग-अलग हैं और इन्हें उचित ध्यान देने की आवश्यकता है।

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

डेवलपर्स को डेटा के महत्व और विकास प्रक्रिया में इसके योगदान को समझना चाहिए। हम सूचना युग में रहते हैं। एप्लिकेशन डेटा प्रदर्शित और हेरफेर करते हैं। यह डेटा में निहित जानकारी है जो एप्लिकेशन को अर्थ देती है।

हर आवश्यकता और हर मुद्दे का पूर्वाभास करना संभव नहीं है, लेकिन सावधानीपूर्वक योजना बनाकर समस्याओं के लिए तैयार रहना महत्वपूर्ण है।

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

नामकरण परंपरा का उपयोग करना प्रभावी दस्तावेज़ीकरण की दिशा में एक कदम है। जब आपको भविष्य में परिवर्तन करना होगा, तो आप किसी भी मौजूदा दस्तावेज़ीकरण की सराहना करेंगे। एक छोटा, सरल दस्तावेज़ जो आपके द्वारा लिए गए निर्णयों का वर्णन करता है और डिज़ाइन का वर्णन करता है, उस समय डिज़ाइन की पसंद को समझाने में मदद करेगा।

आप पर्याप्त दस्तावेज़ीकरण चाहते हैं ताकि डेटाबेस को एक नए व्यवस्थापक द्वारा प्रबंधित किया जा सके और वे स्पष्टीकरण के लिए आपके पास वापस आए बिना इसका अर्थ समझ सकें। यदि डेटा मॉडल और पर्यावरण का दस्तावेजीकरण नहीं किया जाता है, तो इसे बनाए रखना या बदलना मुश्किल होता है क्योंकि आवश्यकताएँ बदलती हैं।

कुछ हद तक, दस्तावेज़ीकरण का डेटा मॉडलिंग से बहुत कम लेना-देना है। दस्तावेज़ीकरण डिजाइन को संप्रेषित करने और भविष्य में इसे समझने योग्य बनाने के बारे में है।

दस्तावेज़ीकरण अक्सर एक बाद का विचार है। जब समय सारिणी कम होती है, तो दस्तावेज़ीकरण को अनदेखा कर दिया जाता है। फिर भी, यह एक उच्च लागत वाला तकनीकी ऋण है। विकास चक्र के दौरान कोनों को काटने से भविष्य में डेटाबेस परिवर्तन, समस्या की पहचान, ट्रैकिंग बग और डेटा मॉडल और डेटा की प्रकृति को समझने के लिए लागत अर्जित होगी।

एक उदाहरण के रूप में, डेटा मॉडल में अक्सर एक "आईडी" फ़ील्ड होता है जो किसी तालिका या कुंजी के नाम के एक हिस्से के लिए प्राथमिक कुंजी के रूप में होता है। यह एक प्राथमिक कुंजी हो सकती है जैसे TransactionID Transaction टेबल। यदि कुछ टेबल कुंजी के नाम के हिस्से के रूप में "नंबर" का उपयोग करते हैं, तो यह दस्तावेज करना अच्छा है कि क्यों। शायद ReferenceNumber संदेश पर प्राथमिक कुंजी के नाम के रूप में प्रयोग किया जाता है क्योंकि व्यावसायिक क्षेत्र में यही संदर्भ कहा जाता है। उदाहरण के लिए, वित्तीय सेवाओं में, वित्तीय संदेशों में आमतौर पर एक संदर्भ संख्या शामिल होती है।

तालिकाओं, स्तंभों और संबंधों की परिभाषा का दस्तावेजीकरण करें ताकि प्रोग्रामर जानकारी तक पहुंच सकें। दस्तावेज़ीकरण को डेटाबेस संरचना की अपेक्षाओं का वर्णन करना चाहिए।

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

खराब या अनुपस्थित दस्तावेज़ीकरण अक्सर अदूरदर्शी सोच के कारण होता है, लेकिन इसके महत्व को नज़रअंदाज़ न करें। यह अभी भी एक मुद्दा है जिसे संबोधित किया जाना है।

नामकरण परंपराएं डिजाइन के दौरान महत्वपूर्ण नहीं लग सकती हैं। वास्तव में, नाम एक मॉडल को समझने की अंतर्दृष्टि प्रदान करते हैं। वे एक परिचय हैं और तार्किक होने चाहिए।

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

जब कुछ कृत्रिम चाबियों के लिए "आईडी" का उपयोग किया जाता है, लेकिन कुछ टेबल एक अलग नामकरण परंपरा (जैसे संख्या) का उपयोग करते हैं, तो डेवलपर्स, विश्लेषक और डीबीए अपवादों को समझने में समय बर्बाद कर सकते हैं। कमजोर नामकरण परंपराएं भी विकास में त्रुटियों का कारण बनती हैं क्योंकि नामकरण संगत नहीं है।

दस्तावेज़ीकरण के साथ हाथ मिलाना, नामकरण परंपरा का उपयोग करना भविष्य में किसी के लिए मॉडल को समझने में मदद करता है। “आईडी” (जैसे CustomerID .) का उपयोग करने के बीच बेतरतीब ढंग से स्विच न करें ) और "नंबर" (AccountNumber ) तालिकाओं के लिए कुंजी के रूप में। सम्मेलनों को केवल तभी अपवाद बनाएं जब वे उचित हों। दस्तावेज़ अपवाद क्या है और सम्मेलन का सम्मान क्यों नहीं किया जाता है।

वही "XRT1" जैसे गुप्त नामों पर लागू होता है - क्या यह विस्तारित संदर्भ तालिका है? तुम्हारा अंदाज़ा मेरी तरह सटीक है। मुझे उम्मीद है कि डिजाइनर को पता था कि उसने ऐसा गुप्त नाम क्यों चुना, लेकिन मुझे संदेह है कि डेटाबेस तक पहुंचने वाला अगला व्यक्ति कारण का अनुमान लगा सकता है।

नामकरण परंपराएं व्यक्तिगत पसंद का मामला हैं। सुनिश्चित करें कि निर्णय सुसंगत और प्रलेखित हैं।

अगर मैं आपको अपने डेटाबेस डिजाइन में नामकरण परंपरा लागू करने के लिए मनाने में सफल रहा, तो बेझिझक मेरा अगला लेख इस विषय पर पूरी तरह से पढ़ें।

कुंजियाँ अक्सर विवाद उत्पन्न करती हैं:प्राथमिक कुंजियाँ, विदेशी कुंजियाँ और कृत्रिम कुंजियाँ। टेबल्स को एक प्राथमिक कुंजी की आवश्यकता होती है जो प्रत्येक पंक्ति की पहचान करती है। कला यह तय करना है कि कौन से कॉलम प्राथमिक कुंजी का हिस्सा होना चाहिए और किन मूल्यों को शामिल करना चाहिए।

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

कुछ डेटा मॉडलर विशिष्टता के लिए कृत्रिम कुंजी पसंद करते हैं। फिर भी कुछ मॉडलर डेटा अखंडता सुनिश्चित करने के लिए एक प्राकृतिक कुंजी पसंद करते हैं।

तो, क्या हमें प्राथमिक कुंजी के रूप में प्राकृतिक कुंजी का उपयोग करना चाहिए? प्राकृतिक कुंजी को बदलने की आवश्यकता होने पर एक चुनौती उत्पन्न होती है। यदि प्राकृतिक कुंजी में कई स्तंभ हैं, तो आपको कई स्थानों पर परिवर्तन करने की आवश्यकता हो सकती है। एक अन्य चुनौती एक टेबल के लिए एकमात्र कुंजी के रूप में एक कृत्रिम कुंजी का उपयोग करना है।

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

5. सत्यनिष्ठा जांच का सावधानी से उपयोग करें

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

अखंडता को लागू करने के लिए डोमेन टेबल प्रभावी हैं। डोमेन टेबल तब अच्छी तरह से काम करते हैं, जब जांच के लिए कई मान होते हैं, या चेक किए जाने वाले मान बार-बार बदलते रहते हैं।

एक मुद्दा यह हो सकता है कि डेवलपर्स यह तय करते हैं कि एप्लिकेशन अखंडता की जांच करेगा। यहां मुद्दा यह है कि कई अनुप्रयोगों द्वारा केंद्रीय डेटाबेस तक पहुंचा जा सकता है। साथ ही, आप आम तौर पर उस डेटा को सुरक्षित रखना चाहते हैं जहां वह है:डेटाबेस में।

यदि संभावित मान सीमित हैं या एक सीमा में हैं, तो एक चेक बाधा बेहतर हो सकती है। मान लीजिए कि संदेशों को इनकमिंग या आउटगोइंग के रूप में परिभाषित किया गया है, इस मामले में विदेशी कुंजी की कोई आवश्यकता नहीं है। लेकिन, वैध मुद्राओं जैसी किसी चीज़ के लिए, जबकि ये स्थिर लग सकती हैं, वे वास्तव में समय-समय पर बदलती रहती हैं। देश एक मुद्रा संघ में शामिल होते हैं और मुद्राएँ बदलती हैं।

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

कुछ इंडेक्सिंग डिज़ाइन डेटाबेस मॉडलिंग के दौरान उपयोगी होते हैं, भले ही इंडेक्स वास्तविक परिनियोजन और उपयोग के दौरान बदल सकते हैं। बेशक, बहुत अधिक अनुक्रमणिकाएँ होना संभव है, ठीक वैसे ही जैसे बहुत कम होना संभव है।

अनुक्रमण एक सतत प्रक्रिया है। डिजाइन के दौरान, आप अपने मॉडल पर प्रक्रिया शुरू करते हैं। डिजाइन का काम प्राथमिक कुंजी और बाधाओं पर है।

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

मैंने अक्सर विशेषता जोड़े के लिए एक सामान्य लुकअप तालिका देखी है। डिज़ाइन को सरल बनाने के लिए एकल, सामान्य डोमेन तालिका को परिभाषित करना माना जाता है। डोमेन तालिका की यह शैली टेक्स्ट रखने के लिए एक सार परिभाषा बनाती है। मैंने सुना है कि इसे "अनुमत मूल्य" या "वैध मान" तालिका कहा जाता है, लेकिन शब्द "MUCK" तालिका 2006 में इस विरोधी पैटर्न के लिए गढ़ी गई थी:व्यापक रूप से एकीकृत कोड-कुंजी।

MUCK टेबल में असंबंधित डेटा होता है।

उदाहरण के लिए, आपके पास एक तालिका हो सकती है जो डोमेन, प्रविष्टि और विवरण को परिभाषित करती है। ऊपर दिए गए संदेश उदाहरण पर विचार करते हुए, दो प्रविष्टियां हो सकती हैं:

अब दूसरे डोमेन के लिए प्रविष्टियां जोड़ें:

यह सिर्फ एक गड़बड़ है। टेबल का क्या मतलब है?

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

MUCK तालिकाओं के साथ, बाधाओं को परिभाषित नहीं किया जा सकता है। MUCK बिना किसी अर्थ के कई पंक्तियाँ बन सकते हैं। जब आपको किसी फ़ील्ड के अर्थ को समझने के लिए किसी अन्य तालिका से पूछताछ करनी होती है, तो यह आदर्श नहीं है।

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

सामान्यीकरण को MUCK तालिकाओं से दूर ले जाना चाहिए। एकल तालिका को एकल डोमेन का प्रतिनिधित्व करना चाहिए; सभी डोमेन का प्रतिनिधित्व करने वाली एकल (MUCK) तालिका के बजाय। MUCK तालिकाओं के बिना, हम विदेशी कुंजी बाधाओं को स्थापित कर सकते हैं।

डोमेन ऑब्जेक्ट्स को एक ही टेबल में समेटने के बजाय अलग-अलग टेबल का उपयोग करें। यह उचित कॉलम प्रकार, बाधाओं और संबंधों की अनुमति देता है। एक "अनुमत मान" तालिका केवल बकवास है और डेटा मॉडल में इसका कोई स्थान नहीं है।

8. संग्रहण कार्यनीति परिभाषित करें

अक्सर, मैंने डेटा प्रतिधारण और संग्रह की उचित रणनीति के बिना बनाए गए डेटाबेस देखे हैं। सक्रिय डेटाबेस तालिकाओं में डेटा को कब तक ऑनलाइन उपलब्ध रखा जाएगा? अधिकांश सिस्टम डेटाबेस में डेटा को "हमेशा के लिए" रखने के लिए बनाए गए हैं। अधिकांश प्रणालियों के लिए, यह एक उचित दीर्घकालिक डेटा प्रतिधारण रणनीति नहीं है। किसी बिंदु पर, सक्रिय डेटा संग्रहीत किया जाना चाहिए।

एक दृष्टिकोण जिसकी मैं वकालत करता हूं, वह है डेटा प्रतिधारण को अपने डिजाइन विचारों के हिस्से के रूप में शामिल करना। क्या आपके पास सक्रिय और ऐतिहासिक तालिकाएँ होंगी ताकि सक्रिय तालिकाओं में नई पंक्तियों का सम्मिलन तेज़ रहे, जबकि ऐतिहासिक डेटा पर खोजों को अनुकूलित किया जा सके?

यह मूल डिज़ाइन के शीर्ष पर आपके डेटाबेस में संग्रह को फिर से डिज़ाइन करने से बचाता है।

9. जल्दी परीक्षण करें, अक्सर परीक्षण करें

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

विकास योजना में परीक्षण हमेशा एक चुनौती है। एजाइल स्प्रिंट के अंत में अक्सर एक परीक्षण चरण होता है और विकास के अंत में सिस्टम परीक्षण होता है। समय कम होने पर परीक्षण आमतौर पर सबसे पहले निचोड़ा जाता है।

डेटाबेस के परीक्षण में, लक्ष्य एक उत्पादन वातावरण का अनुकरण करना होना चाहिए:"डेटाबेस के जीवन में एक दिन"। क्या मात्रा की उम्मीद की जा सकती है? क्या उपयोगकर्ता इंटरैक्शन की संभावना है? क्या सीमा मामलों को संभाला जा रहा है?

इसलिए परीक्षण योजना और उचित परीक्षण डेटा मॉडलिंग और डेटाबेस विकास का एक अभिन्न अंग होना चाहिए।

निष्कर्ष

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

इनमें से किसी भी गतिविधि में बहुत अधिक समय नहीं लगेगा, फिर भी आपके डेटा मॉडल की गुणवत्ता पर बहुत अधिक प्रभाव पड़ेगा।

इन युक्तियों के बारे में आपके क्या विचार हैं?

क्या आपके पास अपनी कोई सलाह है?