डाटाबेस डिजाइन: Difference between revisions

From Vigyanwiki
No edit summary
No edit summary
 
(7 intermediate revisions by 3 users not shown)
Line 1: Line 1:
{{Short description|Designing how data is held in a database}}
{{Short description|Designing how data is held in a database}}
डेटाबेस डिजाइन [[डेटाबेस मॉडल]] के अनुसार डेटा का संगठन है। डिज़ाइनर यह निर्धारित करता है कि कौन सा डेटा संग्रहीत किया जाना चाहिए और डेटा तत्व कैसे परस्पर संबंध रखते हैं। इस जानकारी के साथ, वे डेटा को डेटाबेस मॉडल में फिट करना शुरू कर सकते हैं।<ref name="Teorey, T.J. 2009">Teorey, T.J., Lightstone, S.S., et al., (2009). Database Design: Know it all.1st ed. Burlington, MA.: Morgan Kaufmann Publishers</ref>
डेटाबेस डिजाइन [[डेटाबेस मॉडल]] के अनुसार डेटा का संगठन है। डिज़ाइनर यह निर्धारित करता है कि कौन सा डेटा संग्रहीत किया जाना चाहिए और डेटा तत्व कैसे परस्पर संबंध रखते हैं। इस जानकारी के साथ, वे डेटा को डेटाबेस मॉडल में फिट करना प्रारंभ कर सकते हैं।<ref name="Teorey, T.J. 2009">Teorey, T.J., Lightstone, S.S., et al., (2009). Database Design: Know it all.1st ed. Burlington, MA.: Morgan Kaufmann Publishers</ref>
 
डेटाबेस प्रबंधन प्रणाली तदनुसार डेटा का प्रबंधन करती है।
डेटाबेस प्रबंधन प्रणाली तदनुसार डेटा का प्रबंधन करती है।


डेटाबेस डिज़ाइन में डेटा का वर्गीकरण और अंतर्संबंधों की पहचान करना शामिल है। डेटा के इस सैद्धांतिक प्रतिनिधित्व को ओन्टोलॉजी (सूचना विज्ञान) कहा जाता है। ऑन्कोलॉजी डेटाबेस के डिजाइन के पीछे का सिद्धांत है।
डेटाबेस डिज़ाइन में डेटा का वर्गीकरण और अंतर्संबंधों की पहचान करना सम्मिलित है। डेटा के इस सैद्धांतिक प्रतिनिधित्व को ओन्टोलॉजी (सूचना विज्ञान) कहा जाता है। ऑन्कोलॉजी डेटाबेस के डिजाइन के पीछे का सिद्धांत है।


== संग्रहीत किए जाने वाले डेटा का निर्धारण ==
== संग्रहीत किए जाने वाले डेटा का निर्धारण ==
अधिकांश मामलों में, व्यक्ति जो डेटाबेस का डिज़ाइन कर रहा है, वह डेटाबेस डिज़ाइन के क्षेत्र में विशेषज्ञता वाला व्यक्ति है, न कि उस डोमेन में विशेषज्ञता, जिससे संग्रहीत किया जाने वाला डेटा तैयार किया जाता है। वित्तीय जानकारी, जैविक जानकारी आदि। इसलिए, डेटाबेस में संग्रहीत किए जाने वाले डेटा को उस व्यक्ति के सहयोग से निर्धारित किया जाना चाहिए, जिसके पास उस डोमेन में विशेषज्ञता है, और जो इस बात से अवगत है कि सिस्टम के भीतर कौन सा डेटा संग्रहीत किया जाना चाहिए।
अधिकांश स्थितियों में, एक व्यक्ति जो डेटाबेस का डिज़ाइन कर रहा है, वह डोमेन में विशेषज्ञता के अतिरिक्त डेटाबेस डिज़ाइन के क्षेत्र में विशेषज्ञता रखने वाला व्यक्ति है, जिससे संग्रहीत किया जाने वाला डेटा तैयार किया जाता है, जैसे वित्तीय जानकारी, जैविक जानकारी आदि। इसलिए, डेटाबेस में संग्रहीत किए जाने वाले डेटा को उस व्यक्ति के सहयोग से निर्धारित किया जाना चाहिए जिसके पास उस डोमेन में विशेषज्ञता है, और जो इस बात से अवगत है कि प्रणाली के अन्दर कौन सा डेटा संग्रहीत किया जाना चाहिए।


यह प्रक्रिया वह है जिसे आम तौर पर [[आवश्यकताओं के विश्लेषण]] का हिस्सा माना जाता है, और डोमेन ज्ञान वाले लोगों से आवश्यक जानकारी प्राप्त करने के लिए डेटाबेस डिज़ाइनर की ओर से कौशल की आवश्यकता होती है। ऐसा इसलिए है क्योंकि आवश्यक डोमेन ज्ञान वाले लोग अक्सर स्पष्ट रूप से व्यक्त नहीं कर सकते हैं कि डेटाबेस के लिए उनकी सिस्टम आवश्यकताएं क्या हैं क्योंकि वे असतत डेटा तत्वों के संदर्भ में सोचने के लिए अभ्यस्त नहीं हैं जिन्हें संग्रहित किया जाना चाहिए। संग्रहीत किए जाने वाले डेटा को आवश्यकता विशिष्टता द्वारा निर्धारित किया जा सकता है।<ref>Teorey, T.; Lightstone, S. and Nadeau, T.(2005) ''Database Modeling & Design: Logical Design'', 4th edition, Morgan Kaufmann Press. {{ISBN|0-12-685352-5}}</ref>
यह प्रक्रिया वह है जिसे सामान्यतः [[आवश्यकताओं के विश्लेषण]] का भाग माना जाता है, और डोमेन ज्ञान वाले लोगों से आवश्यक जानकारी प्राप्त करने के लिए डेटाबेस डिज़ाइनर की ओर से कौशल की आवश्यकता होती है। ऐसा इसलिए है क्योंकि आवश्यक डोमेन ज्ञान वाले लोग अधिकांश स्पष्ट रूप से व्यक्त नहीं कर सकते हैं कि डेटाबेस के लिए उनकी प्रणाली आवश्यकताएं क्या हैं क्योंकि वे असतत डेटा तत्वों के संदर्भ में सोचने के लिए अभ्यस्त नहीं हैं जिन्हें संग्रहित किया जाना चाहिए। संग्रहीत किए जाने वाले डेटा को आवश्यकता विशिष्टता द्वारा निर्धारित किया जा सकता है।<ref>Teorey, T.; Lightstone, S. and Nadeau, T.(2005) ''Database Modeling & Design: Logical Design'', 4th edition, Morgan Kaufmann Press. {{ISBN|0-12-685352-5}}</ref>




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


(नोट: आम ग़लतफ़हमी यह है कि [[संबंधपरक मॉडल]] को डेटा तत्वों के बीच संबंधों के कथन के कारण कहा जाता है। यह सच नहीं है। संबंधपरक मॉडल को इसलिए नाम दिया गया है क्योंकि यह गणितीय संरचनाओं पर आधारित है जिसे [[संबंध (गणित)]] के रूप में जाना जाता है। .)
(नोट: आम ग़लतफ़हमी यह है कि [[संबंधपरक मॉडल]] को डेटा तत्वों के बीच संबंधों के कथन के कारण कहा जाता है। यह सच नहीं है। संबंधपरक मॉडल को इसलिए नाम दिया गया है क्योंकि यह गणितीय संरचनाओं पर आधारित है जिसे [[संबंध (गणित)]] के रूप में जाना जाता है। .)


== तार्किक रूप से संरचित डेटा ==
== तार्किक रूप से संरचित डेटा ==
{{Main|Logical schema}}
{{Main|तार्किक स्कीमा}}
बार जानकारी के विभिन्न टुकड़ों के बीच संबंध और निर्भरता निर्धारित हो जाने के बाद, डेटा को तार्किक संरचना में व्यवस्थित करना संभव है, जिसे तब [[डेटाबेस प्रबंधन प्रणाली]] द्वारा समर्थित स्टोरेज ऑब्जेक्ट में मैप किया जा सकता है। [[संबंधपरक डेटाबेस]] के मामले में स्टोरेज [[ऑब्जेक्ट डेटाबेस]] टेबल होते हैं जो पंक्तियों और कॉलम में डेटा स्टोर करते हैं। ऑब्जेक्ट डेटाबेस में स्टोरेज ऑब्जेक्ट सीधे [[वस्तु-उन्मुख प्रोग्रामिंग भाषा]] द्वारा उपयोग किए जाने वाले ऑब्जेक्ट से संबंधित होते हैं जो डेटा को प्रबंधित और एक्सेस करने वाले एप्लिकेशन को लिखने के लिए उपयोग किया जाता है। संबंधों को शामिल वस्तु वर्गों की विशेषताओं के रूप में या वस्तु वर्गों पर संचालित विधियों के रूप में परिभाषित किया जा सकता है।
बार जानकारी के विभिन्न टुकड़ों के बीच संबंध और निर्भरता निर्धारित हो जाने के बाद, डेटा को तार्किक संरचना में व्यवस्थित करना संभव है, जिसे तब [[डेटाबेस प्रबंधन प्रणाली]] द्वारा समर्थित भण्डारण ऑब्जेक्ट में मैप किया जा सकता है। [[संबंधपरक डेटाबेस]] के स्थितियों में भण्डारण [[ऑब्जेक्ट डेटाबेस]] सरणी होते हैं जो पंक्तियों और कॉलम में डेटा स्टोर करते हैं। ऑब्जेक्ट डेटाबेस में भण्डारण ऑब्जेक्ट सीधे [[वस्तु-उन्मुख प्रोग्रामिंग भाषा]] द्वारा उपयोग किए जाने वाले ऑब्जेक्ट से संबंधित होते हैं जो डेटा को प्रबंधित और अभिगम करने वाले एप्लिकेशन को लिखने के लिए उपयोग किया जाता है। संबंधों को सम्मिलित वस्तु वर्गों की विशेषताओं के रूप में या वस्तु वर्गों पर संचालित विधियों के रूप में परिभाषित किया जा सकता है।


जिस तरह से यह मैपिंग आम तौर पर किया जाता है वह ऐसा होता है कि संबंधित डेटा का प्रत्येक सेट जो वस्तु पर निर्भर करता है, चाहे वह वास्तविक हो या अमूर्त, तालिका में रखा जाता है। इन निर्भर वस्तुओं के बीच संबंध तब विभिन्न वस्तुओं के बीच लिंक के रूप में जमा हो जाते हैं।
जिस प्रकार से यह मैपिंग सामान्यतः किया जाता है वह ऐसा होता है कि संबंधित डेटा का प्रत्येक समुच्चय जो वस्तु पर निर्भर करता है, चाहे वह वास्तविक हो या अमूर्त, तालिका में रखा जाता है। इन निर्भर वस्तुओं के बीच संबंध तब विभिन्न वस्तुओं के बीच शृंखला के रूप में जमा हो जाते हैं।


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


==ईआर आरेख (इकाई-संबंध मॉडल) ==
==ईआर आरेख (इकाई-संबंध मॉडल) ==
[[Image:ER Diagram MMORPG.png|thumb|320px|नमूना इकाई-संबंध आरेख]]डेटाबेस डिज़ाइन में ER ([[इकाई-संबंध मॉडल]]) डायग्राम भी शामिल होते हैं। ईआर आरेख आरेख है जो डेटाबेस को कुशल तरीके से डिजाइन करने में मदद करता है।
[[Image:ER Diagram MMORPG.png|thumb|320px|मानक इकाई-संबंध आरेख]]डेटाबेस डिज़ाइन में ईआर ([[इकाई-संबंध मॉडल]]) डायग्राम भी सम्मिलित होते हैं। ईआर आरेख आरेख है जो डेटाबेस को कुशल विधियों से डिजाइन करने में सहायता करता है।


ईआर आरेखों में विशेषताओं को आमतौर पर विशेषता के नाम के साथ अंडाकार के रूप में तैयार किया जाता है, जो उस इकाई या संबंध से जुड़ा होता है जिसमें विशेषता होती है।
ईआर आरेखों में विशेषताओं को सामान्यतः विशेषता के नाम के साथ अंडाकार के रूप में तैयार किया जाता है, जो उस इकाई या संबंध से जुड़ा होता है जिसमें विशेषता होती है।


ईआर मॉडल आमतौर पर सूचना प्रणाली डिजाइन में उपयोग किए जाते हैं; उदाहरण के लिए, वे वैचारिक संरचना डिजाइन चरण के दौरान डेटाबेस में संग्रहीत की जाने वाली सूचना आवश्यकताओं और / या जानकारी के प्रकारों का वर्णन करने के लिए उपयोग किए जाते हैं।<ref>{{Cite journal|last1=Javed|first1=Muhammad|last2=Lin|first2=Yuqing|date=2018|title=Iterative Process for Generating ER Diagram from Unrestricted Requirements|journal=Proceedings of the 13th International Conference on Evaluation of Novel Approaches to Software Engineering|pages=192–204|publisher=SCITEPRESS - Science and Technology Publications|doi=10.5220/0006778701920204|isbn=978-989-758-300-1|doi-access=free}}</ref>
ईआर मॉडल सामान्यतः सूचना प्रणाली डिजाइन में उपयोग किए जाते हैं; उदाहरण के लिए, वे वैचारिक संरचना डिजाइन चरण के समय डेटाबेस में संग्रहीत की जाने वाली सूचना आवश्यकताओं और / या जानकारी के प्रकारों का वर्णन करने के लिए उपयोग किए जाते हैं।<ref>{{Cite journal|last1=Javed|first1=Muhammad|last2=Lin|first2=Yuqing|date=2018|title=Iterative Process for Generating ER Diagram from Unrestricted Requirements|journal=Proceedings of the 13th International Conference on Evaluation of Novel Approaches to Software Engineering|pages=192–204|publisher=SCITEPRESS - Science and Technology Publications|doi=10.5220/0006778701920204|isbn=978-989-758-300-1|doi-access=free}}</ref>


'''माइक्रोसॉफ्ट अभिगम के लिए डिजाइन प्रक्रिया सुझाव'''


== माइक्रोसॉफ्ट एक्सेस == के लिए डिजाइन प्रक्रिया सुझाव
#डेटाबेस का उद्देश्य निर्धारित करें - यह शेष चरणों के लिए तैयार करने में सहायता करता है।
 
# आवश्यक जानकारी को ढूँढें और व्यवस्थित करें - डेटाबेस में रिकॉर्ड करने के लिए सभी प्रकार की जानकारी एकत्र करें, जैसे उत्पाद का नाम और क्रम संख्या।
#डेटाबेस का उद्देश्य निर्धारित करें - यह शेष चरणों के लिए तैयार करने में मदद करता है।
# आवश्यक जानकारी को ढूँढें और व्यवस्थित करें - डेटाबेस में रिकॉर्ड करने के लिए सभी प्रकार की जानकारी इकट्ठा करें, जैसे उत्पाद का नाम और ऑर्डर नंबर।
# सूचनाओं को तालिकाओं में विभाजित करें - सूचना वस्तुओं को प्रमुख संस्थाओं या विषयों में विभाजित करें, जैसे उत्पाद या आदेश। प्रत्येक विषय तब तालिका बन जाता है।
# सूचनाओं को तालिकाओं में विभाजित करें - सूचना वस्तुओं को प्रमुख संस्थाओं या विषयों में विभाजित करें, जैसे उत्पाद या आदेश। प्रत्येक विषय तब तालिका बन जाता है।
# सूचना आइटम को कॉलम में बदलें - तय करें कि प्रत्येक तालिका में कौन सी जानकारी संग्रहीत करने की आवश्यकता है। प्रत्येक आइटम फ़ील्ड बन जाता है, और तालिका में कॉलम के रूप में प्रदर्शित होता है। उदाहरण के लिए, कर्मचारी तालिका में अंतिम नाम और किराया दिनांक जैसे फ़ील्ड शामिल हो सकते हैं।
# सूचना विषय को कॉलम में बदलें - तय करें कि प्रत्येक तालिका में कौन सी जानकारी संग्रहीत करने की आवश्यकता है। प्रत्येक विषय क्षेत्र बन जाता है, और तालिका में कॉलम के रूप में प्रदर्शित होता है। उदाहरण के लिए, कर्मचारी तालिका में अंतिम नाम और किराया दिनांक जैसे क्षेत्र सम्मिलित हो सकते हैं।
# प्राथमिक कुंजी निर्दिष्ट करें - प्रत्येक तालिका की प्राथमिक कुंजी चुनें। प्राथमिक कुंजी स्तंभ, या स्तंभों का समूह है, जिसका उपयोग प्रत्येक पंक्ति को विशिष्ट रूप से पहचानने के लिए किया जाता है। उदाहरण उत्पाद आईडी या ऑर्डर आईडी हो सकता है।
# प्राथमिक कुंजी निर्दिष्ट करें - प्रत्येक तालिका की प्राथमिक कुंजी चुनें। प्राथमिक कुंजी स्तंभ, या स्तंभों का समूह है, जिसका उपयोग प्रत्येक पंक्ति को विशिष्ट रूप से पहचानने के लिए किया जाता है। उदाहरण उत्पाद आईडी या ऑर्डर आईडी हो सकता है।
#तालिका संबंध स्थापित करें - प्रत्येक तालिका को देखें और तय करें कि तालिका का डेटा अन्य तालिकाओं के डेटा से कैसे संबंधित है। आवश्यकतानुसार, संबंधों को स्पष्ट करने के लिए तालिकाओं में फ़ील्ड जोड़ें या नई तालिकाएँ बनाएँ।
#तालिका संबंध स्थापित करें - प्रत्येक तालिका को देखें और तय करें कि तालिका का डेटा अन्य तालिकाओं के डेटा से कैसे संबंधित है। आवश्यकतानुसार, संबंधों को स्पष्ट करने के लिए तालिकाओं में क्षेत्र जोड़ें या नई तालिकाएँ बनाएँ।
# डिज़ाइन को परिष्कृत करें - त्रुटियों के लिए डिज़ाइन का विश्लेषण करें। तालिकाएँ बनाएँ और नमूना डेटा के कुछ रिकॉर्ड जोड़ें। जाँचें कि क्या परिणाम तालिकाओं से अपेक्षित रूप से आते हैं। आवश्यकतानुसार डिज़ाइन में समायोजन करें।
# डिज़ाइन को परिष्कृत करें - त्रुटियों के लिए डिज़ाइन का विश्लेषण करें। तालिकाएँ बनाएँ और मानक डेटा के कुछ रिकॉर्ड जोड़ें। जाँचें कि क्या परिणाम तालिकाओं से अपेक्षित रूप से आते हैं। आवश्यकतानुसार डिज़ाइन में समायोजन करें।
# [[डेटाबेस सामान्यीकरण]] लागू करें - यह देखने के लिए कि क्या तालिकाओं को सही ढंग से संरचित किया गया है, डेटा सामान्यीकरण नियम लागू करें। आवश्यकतानुसार तालिकाओं में समायोजन करें।
# [[डेटाबेस सामान्यीकरण]] प्रायुक्त करें - यह देखने के लिए कि क्या तालिकाओं को सही रूप से संरचित किया गया है, डेटा सामान्यीकरण नियम प्रायुक्त करें। आवश्यकतानुसार तालिकाओं में समायोजन करें।<ref>Database design basics. (n.d.). Database design basics. Retrieved May 1, 2010, from https://support.office.com/en-US/article/Database-design-basics-EB2159CF-1E30-401A-8084-BD4F9C9CA1F5</ref>
<ref>Database design basics. (n.d.). Database design basics. Retrieved May 1, 2010, from https://support.office.com/en-US/article/Database-design-basics-EB2159CF-1E30-401A-8084-BD4F9C9CA1F5</ref>




== सामान्यीकरण ==
== सामान्यीकरण ==
{{main|Database normalization}}
{{main|डेटाबेस सामान्यीकरण}}
[[संबंध का डेटाबेस]] डिज़ाइन के क्षेत्र में, सामान्यीकरण यह सुनिश्चित करने का व्यवस्थित तरीका है कि डेटाबेस संरचना सामान्य-उद्देश्य क्वेरी के लिए उपयुक्त है और कुछ अवांछनीय विशेषताओं से मुक्त है - सम्मिलन, अद्यतन और विलोपन विसंगतियाँ जो डेटा अखंडता की हानि का कारण बन सकती हैं।
[[संबंध का डेटाबेस]] डिज़ाइन के क्षेत्र में, सामान्यीकरण यह सुनिश्चित करने का व्यवस्थित विधि है कि डेटाबेस संरचना सामान्य-उद्देश्य क्वेरी के लिए उपयुक्त है और कुछ अवांछनीय विशेषताओं से मुक्त है - सम्मिलन, अद्यतन और विलोपन विसंगतियाँ जो डेटा अखंडता की हानि का कारण बन सकती हैं।


डेटाबेस डिज़ाइन मार्गदर्शन का मानक भाग यह है कि डिज़ाइनर को पूरी तरह से सामान्यीकृत डिज़ाइन बनाना चाहिए; चयनात्मक असामान्यकरण बाद में किया जा सकता है, लेकिन केवल [[कंप्यूटर प्रदर्शन]] कारणों से। व्यापार-बंद भंडारण स्थान बनाम प्रदर्शन है। डिज़ाइन जितना अधिक सामान्यीकृत होता है, उतना ही कम डेटा अतिरेक होता है (और इसलिए, यह स्टोर करने के लिए कम स्थान लेता है), हालाँकि, सामान्य डेटा पुनर्प्राप्ति पैटर्न को अब जटिल जुड़ने, मर्ज करने और सॉर्ट करने की आवश्यकता हो सकती है - जो अधिक डेटा लेता है पढ़ें, और चक्रों की गणना करें। कुछ मॉडलिंग विषयों, जैसे [[डेटा वेयरहाउस]] डिज़ाइन के लिए [[आयामी मॉडलिंग]] दृष्टिकोण, स्पष्ट रूप से गैर-सामान्यीकृत डिज़ाइनों की अनुशंसा करते हैं, यानी डिज़ाइन जो बड़े हिस्से में 3NF का पालन नहीं करते हैं।
डेटाबेस डिज़ाइन मार्गदर्शन का मानक भाग यह है कि डिज़ाइनर को पूरी तरह से सामान्यीकृत डिज़ाइन बनाना चाहिए; चयनात्मक असामान्यकरण बाद में किया जा सकता है, किन्तु केवल [[कंप्यूटर प्रदर्शन]] कारणों से। व्यापार-बंद भंडारण स्थान बनाम प्रदर्शन है। डिज़ाइन जितना अधिक सामान्यीकृत होता है, उतना ही कम डेटा अतिरेक होता है (और इसलिए, यह स्टोर करने के लिए कम स्थान लेता है), चूँकि, सामान्य डेटा पुनर्प्राप्ति पैटर्न को अब जटिल जुड़ने, मर्ज करने और सॉर्ट करने की आवश्यकता हो सकती है - जो अधिक डेटा लेता है पढ़ें, और चक्रों की गणना करें। कुछ मॉडलिंग विषयों, जैसे [[डेटा वेयरहाउस]] डिज़ाइन के लिए [[आयामी मॉडलिंग]] दृष्टिकोण, स्पष्ट रूप से गैर-सामान्यीकृत डिज़ाइनों की अनुशंसा करते हैं, अर्थात् डिज़ाइन जो बड़े हिस्से में 3एनएफ का पालन नहीं करते हैं।
सामान्यीकरण में सामान्य रूप होते हैं जो 1NF, 2NF, 3NF, BOYCE-CODD NF (3.5NF), 4NF और 5NF हैं
सामान्यीकरण में सामान्य रूप होते हैं जो 1एनएफ, 2एनएफ, 3एनएफ, बोयस-कॉड एनएफ (3.5एनएफ), 4एनएफ और 5एनएफ हैं


दस्तावेज़ डेटाबेस अलग दृष्टिकोण लेते हैं। दस्तावेज़ जो ऐसे डेटाबेस में संग्रहीत होता है, आमतौर पर से अधिक सामान्यीकृत डेटा इकाई और अक्सर इकाइयों के बीच संबंध भी होते हैं। यदि सभी डेटा इकाइयां और संबंध अक्सर साथ पुनर्प्राप्त किए जाते हैं, तो यह दृष्टिकोण पुनर्प्राप्ति की संख्या को अनुकूलित करता है। यह यह भी सरल करता है कि डेटा को कैसे दोहराया जाता है, क्योंकि अब डेटा की स्पष्ट रूप से पहचान योग्य इकाई है जिसकी स्थिरता स्व-निहित है। अन्य विचार यह है कि ऐसे डेटाबेस में ही दस्तावेज़ को पढ़ने और लिखने के लिए ही लेन-देन की आवश्यकता होगी - जो कि [[माइक्रोसर्विसेज]] आर्किटेक्चर में महत्वपूर्ण विचार हो सकता है। ऐसी स्थितियों में, अक्सर, दस्तावेज़ के कुछ हिस्सों को एपीआई के माध्यम से अन्य सेवाओं से पुनर्प्राप्त किया जाता है और दक्षता कारणों से स्थानीय रूप से संग्रहीत किया जाता है। यदि डेटा इकाइयों को सेवाओं में विभाजित किया जाना था, तो सेवा उपभोक्ता का समर्थन करने के लिए पढ़ने (या लिखने) के लिए से अधिक सेवा कॉल की आवश्यकता हो सकती है, और इसके परिणामस्वरूप कई लेनदेन का प्रबंधन हो सकता है, जिसे प्राथमिकता नहीं दी जा सकती है।
दस्तावेज़ डेटाबेस अलग दृष्टिकोण लेते हैं। दस्तावेज़ जो ऐसे डेटाबेस में संग्रहीत होता है, सामान्यतः से अधिक सामान्यीकृत डेटा इकाई और अधिकांश इकाइयों के बीच संबंध भी होते हैं। यदि सभी डेटा इकाइयां और संबंध अधिकांश साथ पुनर्प्राप्त किए जाते हैं, तो यह दृष्टिकोण पुनर्प्राप्ति की संख्या को अनुकूलित करता है। यह यह भी सरल करता है कि डेटा को कैसे दोहराया जाता है, क्योंकि अब डेटा की स्पष्ट रूप से पहचान योग्य इकाई है जिसकी स्थिरता स्व-निहित है। अन्य विचार यह है कि ऐसे डेटाबेस में ही दस्तावेज़ को पढ़ने और लिखने के लिए ही लेन-देन की आवश्यकता होगी - जो कि [[माइक्रोसर्विसेज]] आर्किटेक्चर में महत्वपूर्ण विचार हो सकता है। ऐसी स्थितियों में, अधिकांश, दस्तावेज़ के कुछ हिस्सों को एपीआई के माध्यम से अन्य सेवाओं से पुनर्प्राप्त किया जाता है और दक्षता कारणों से स्थानीय रूप से संग्रहीत किया जाता है। यदि डेटा इकाइयों को सेवाओं में विभाजित किया जाना था, तो सेवा उपभोक्ता का समर्थन करने के लिए पढ़ने (या लिखने) के लिए से अधिक सेवा कॉल की आवश्यकता हो सकती है, और इसके परिणामस्वरूप कई लेनदेन का प्रबंधन हो सकता है, जिसे प्राथमिकता नहीं दी जा सकती है।


== वैचारिक स्कीमा ==
== वैचारिक स्कीमा ==
{{Main|Conceptual schema}}
{{Main|वैचारिक स्कीमा}}




== भौतिक डिजाइन ==
== भौतिक डिजाइन ==
{{Main|Physical schema}}
{{Main|भौतिक डिजाइन}}
डेटाबेस का भौतिक डिज़ाइन स्टोरेज मीडिया पर डेटाबेस के भौतिक कॉन्फ़िगरेशन को निर्दिष्ट करता है। इसमें [[डेटा तत्व]]ों, [[डेटा प्रकार]], [[सूचकांक (डेटाबेस)]] विकल्प और डीबीएमएस [[डेटा शब्दकोश]] में रहने वाले अन्य पैरामीटर के विस्तृत विनिर्देश शामिल हैं। यह सिस्टम का विस्तृत डिज़ाइन है जिसमें मॉड्यूल और डेटाबेस के हार्डवेयर और सिस्टम के सॉफ़्टवेयर विनिर्देश शामिल हैं। कुछ पहलू जिन्हें भौतिक स्तर पर संबोधित किया गया है:
 
डेटाबेस का भौतिक डिज़ाइन भण्डारण मीडिया पर डेटाबेस के भौतिक विन्यास को निर्दिष्ट करता है। इसमें [[डेटा तत्व|डेटा तत्वों]], [[डेटा प्रकार]], [[सूचकांक (डेटाबेस)]] विकल्प और डीबीएमएस [[डेटा शब्दकोश]] में रहने वाले अन्य पैरामीटर के विस्तृत विनिर्देश सम्मिलित हैं। यह प्रणाली का विस्तृत डिज़ाइन है जिसमें मॉड्यूल और डेटाबेस के हार्डवेयर और प्रणाली के सॉफ़्टवेयर विनिर्देश सम्मिलित हैं। कुछ स्थिति जिन्हें भौतिक स्तर पर संबोधित किया गया है:
* सुरक्षा - एंड-यूज़र, साथ ही प्रशासनिक सुरक्षा।
* सुरक्षा - एंड-यूज़र, साथ ही प्रशासनिक सुरक्षा।
* प्रतिकृति - डेटा के कौन से टुकड़े दूसरे डेटाबेस में कॉपी किए जाते हैं, और कितनी बार। क्या कई-स्वामी हैं, या ही?
* प्रतिकृति - डेटा के कौन से टुकड़े दूसरे डेटाबेस में और कितनी बार कॉपी किए जाते हैं। क्या कई-स्वामी या एक ही हैं?
* उच्च-उपलब्धता - चाहे कॉन्फ़िगरेशन सक्रिय-निष्क्रिय हो, या सक्रिय-सक्रिय, टोपोलॉजी, समन्वय योजना, विश्वसनीयता लक्ष्य, आदि सभी को परिभाषित करना होगा।
* उच्च-उपलब्धता - चाहे विन्यास सक्रिय-निष्क्रिय हो, या सक्रिय-सक्रिय, टोपोलॉजी, समन्वय योजना, विश्वसनीयता लक्ष्य, आदि सभी को परिभाषित करना होगा।
* विभाजन - यदि डेटाबेस वितरित किया जाता है, तो इकाई के लिए, डेटाबेस के सभी विभाजनों के बीच डेटा कैसे वितरित किया जाता है, और विभाजन विफलता को कैसे ध्यान में रखा जाता है।
* विभाजन - यदि डेटाबेस वितरित किया जाता है, तो इकाई के लिए, डेटाबेस के सभी विभाजनों के बीच डेटा कैसे वितरित किया जाता है, और विभाजन विफलता को कैसे ध्यान में रखा जाता है।
* बैकअप और योजनाओं को पुनर्स्थापित करें।
* बैकअप और योजनाओं को पुनर्स्थापित करें।


अनुप्रयोग स्तर पर, भौतिक डिज़ाइन के अन्य पहलुओं में संग्रहीत प्रक्रियाओं को परिभाषित करने की आवश्यकता, या भौतिक क्वेरी दृश्य, ऑनलाइन_विश्लेषणात्मक_प्रोसेसिंग क्यूब्स आदि शामिल हो सकते हैं।
अनुप्रयोग स्तर पर, भौतिक डिज़ाइन के अन्य स्थितियों में संग्रहीत प्रक्रियाओं को परिभाषित करने की आवश्यकता, या भौतिक क्वेरी दृश्य, ऑनलाइन_विश्लेषणात्मक_स्वरूप क्यूब्स आदि सम्मिलित हो सकते हैं।


== यह भी देखें ==
== यह भी देखें ==
{{columns-list|colwidth=20em|
{{columns-list|colwidth=20em|*[[डेटाबेस सामान्यीकरण]]
*[[Database normalization]]
*[[संबंध का डेटाबेस]]
*[[Relational database]]
*[[रिलेशनल मॉडल]]
*[[Relational model]]
*[[पीओओडी]] ([[ओर्थोगोनल डिज़ाइन का सिद्धांत]])
*[[POOD]] ([[Principle of orthogonal design]])
*[[कॉन्सेप्ट मैपिंग]]
*[[Concept mapping]]
*[[मॉडलिंग की दिनांक]]
*[[Data modeling]]
*[[एंटिटी-रिलेशनशिप मॉडल]]
*[[Entity-relationship model]]
*[[एंटिटी-एट्रिब्यूट-वैल्यू मॉडल]]
*[[Entity-attribute-value model]]
*[[ऑब्जेक्ट-रिलेशनशिप मॉडलिंग]]
*[[Object-relationship modeling]]
*[[ऑब्जेक्ट-रोल मॉडलिंग]]
*[[Object-role modeling]]
*[[ज्ञान निरूपण]]
*[[Knowledge representation]]
*[[तार्किक डेटा मॉडल]]
*[[Logical data model]]
*[[मन में नक्शे बनाना]]
*[[Mindmap]]
*[[भौतिक डेटा मॉडल]]
*[[Physical data model]]
*[[सेमांटिक वेब]]
*[[Semantic Web]]
*[[तीन स्कीमा दृष्टिकोण]]}}
*[[Three schema approach]]
}}




Line 96: Line 94:
==अग्रिम पठन==
==अग्रिम पठन==
*S. Lightstone, T. Teorey, T. Nadeau, “Physical Database Design: the database professional's guide to exploiting indexes, views, storage, and more”, Morgan Kaufmann Press, 2007. {{ISBN|0-12-369389-6}}
*S. Lightstone, T. Teorey, T. Nadeau, “Physical Database Design: the database professional's guide to exploiting indexes, views, storage, and more”, Morgan Kaufmann Press, 2007. {{ISBN|0-12-369389-6}}
*M. Hernandez, "[http://www.informit.com/store/database-design-for-mere-mortals-a-hands-on-guide-to-9780321884497 Database Design for Mere Mortals]: A Hands-On Guide to Relational Database Design", 3rd Edition, Addison-Wesley Professional, 2013. {{ISBN|0-321-88449-3}}
*M. Hईआरnandez, "[http://www.informit.com/store/database-design-for-mere-mortals-a-hands-on-guide-to-9780321884497 Database Design for Mईआरe Mortals]: A Hands-On Guide to Relational Database Design", 3rd Edition, Addison-Wesley Professional, 2013. {{ISBN|0-321-88449-3}}




Line 112: Line 110:
{{Design}}
{{Design}}


{{DEFAULTSORT:Database Design}}[[Category: डेटाबेस]] [[Category: डेटाबेस प्रबंधन तंत्र]] [[Category: डेटाबेस सिद्धांत]]
{{DEFAULTSORT:Database Design}}
 
 


[[Category: Machine Translated Page]]
[[Category:Articles with Curlie links|Database Design]]
[[Category:Created On 16/02/2023]]
[[Category:Articles with hatnote templates targeting a nonexistent page|Database Design]]
[[Category:Collapse templates|Database Design]]
[[Category:Created On 16/02/2023|Database Design]]
[[Category:Database management systems|Database Design]]
[[Category:Lua-based templates|Database Design]]
[[Category:Machine Translated Page|Database Design]]
[[Category:Multi-column templates|Database Design]]
[[Category:Navigational boxes| ]]
[[Category:Navigational boxes without horizontal lists|Database Design]]
[[Category:Pages using div col with small parameter|Database Design]]
[[Category:Pages with script errors|Database Design]]
[[Category:Short description with empty Wikidata description|Database Design]]
[[Category:Sidebars with styles needing conversion|Database Design]]
[[Category:Template documentation pages|Documentation/doc]]
[[Category:Templates Vigyan Ready|Database Design]]
[[Category:Templates generating microformats|Database Design]]
[[Category:Templates that add a tracking category|Database Design]]
[[Category:Templates that are not mobile friendly|Database Design]]
[[Category:Templates that generate short descriptions|Database Design]]
[[Category:Templates using TemplateData|Database Design]]
[[Category:Templates using under-protected Lua modules|Database Design]]
[[Category:Wikipedia fully protected templates|Div col]]
[[Category:Wikipedia metatemplates|Database Design]]
[[Category:डेटाबेस|Database Design]]
[[Category:डेटाबेस प्रबंधन तंत्र|Database Design]]
[[Category:डेटाबेस सिद्धांत|Database Design]]

Latest revision as of 15:47, 16 March 2023

डेटाबेस डिजाइन डेटाबेस मॉडल के अनुसार डेटा का संगठन है। डिज़ाइनर यह निर्धारित करता है कि कौन सा डेटा संग्रहीत किया जाना चाहिए और डेटा तत्व कैसे परस्पर संबंध रखते हैं। इस जानकारी के साथ, वे डेटा को डेटाबेस मॉडल में फिट करना प्रारंभ कर सकते हैं।[1]

डेटाबेस प्रबंधन प्रणाली तदनुसार डेटा का प्रबंधन करती है।

डेटाबेस डिज़ाइन में डेटा का वर्गीकरण और अंतर्संबंधों की पहचान करना सम्मिलित है। डेटा के इस सैद्धांतिक प्रतिनिधित्व को ओन्टोलॉजी (सूचना विज्ञान) कहा जाता है। ऑन्कोलॉजी डेटाबेस के डिजाइन के पीछे का सिद्धांत है।

संग्रहीत किए जाने वाले डेटा का निर्धारण

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

यह प्रक्रिया वह है जिसे सामान्यतः आवश्यकताओं के विश्लेषण का भाग माना जाता है, और डोमेन ज्ञान वाले लोगों से आवश्यक जानकारी प्राप्त करने के लिए डेटाबेस डिज़ाइनर की ओर से कौशल की आवश्यकता होती है। ऐसा इसलिए है क्योंकि आवश्यक डोमेन ज्ञान वाले लोग अधिकांश स्पष्ट रूप से व्यक्त नहीं कर सकते हैं कि डेटाबेस के लिए उनकी प्रणाली आवश्यकताएं क्या हैं क्योंकि वे असतत डेटा तत्वों के संदर्भ में सोचने के लिए अभ्यस्त नहीं हैं जिन्हें संग्रहित किया जाना चाहिए। संग्रहीत किए जाने वाले डेटा को आवश्यकता विशिष्टता द्वारा निर्धारित किया जा सकता है।[2]


डेटा संबंधों का निर्धारण

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

(नोट: आम ग़लतफ़हमी यह है कि संबंधपरक मॉडल को डेटा तत्वों के बीच संबंधों के कथन के कारण कहा जाता है। यह सच नहीं है। संबंधपरक मॉडल को इसलिए नाम दिया गया है क्योंकि यह गणितीय संरचनाओं पर आधारित है जिसे संबंध (गणित) के रूप में जाना जाता है। .)

तार्किक रूप से संरचित डेटा

Main article: तार्किक स्कीमा

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

जिस प्रकार से यह मैपिंग सामान्यतः किया जाता है वह ऐसा होता है कि संबंधित डेटा का प्रत्येक समुच्चय जो वस्तु पर निर्भर करता है, चाहे वह वास्तविक हो या अमूर्त, तालिका में रखा जाता है। इन निर्भर वस्तुओं के बीच संबंध तब विभिन्न वस्तुओं के बीच शृंखला के रूप में जमा हो जाते हैं।

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

ईआर आरेख (इकाई-संबंध मॉडल)

मानक इकाई-संबंध आरेख

डेटाबेस डिज़ाइन में ईआर (इकाई-संबंध मॉडल) डायग्राम भी सम्मिलित होते हैं। ईआर आरेख आरेख है जो डेटाबेस को कुशल विधियों से डिजाइन करने में सहायता करता है।

ईआर आरेखों में विशेषताओं को सामान्यतः विशेषता के नाम के साथ अंडाकार के रूप में तैयार किया जाता है, जो उस इकाई या संबंध से जुड़ा होता है जिसमें विशेषता होती है।

ईआर मॉडल सामान्यतः सूचना प्रणाली डिजाइन में उपयोग किए जाते हैं; उदाहरण के लिए, वे वैचारिक संरचना डिजाइन चरण के समय डेटाबेस में संग्रहीत की जाने वाली सूचना आवश्यकताओं और / या जानकारी के प्रकारों का वर्णन करने के लिए उपयोग किए जाते हैं।[3]

माइक्रोसॉफ्ट अभिगम के लिए डिजाइन प्रक्रिया सुझाव

  1. डेटाबेस का उद्देश्य निर्धारित करें - यह शेष चरणों के लिए तैयार करने में सहायता करता है।
  2. आवश्यक जानकारी को ढूँढें और व्यवस्थित करें - डेटाबेस में रिकॉर्ड करने के लिए सभी प्रकार की जानकारी एकत्र करें, जैसे उत्पाद का नाम और क्रम संख्या।
  3. सूचनाओं को तालिकाओं में विभाजित करें - सूचना वस्तुओं को प्रमुख संस्थाओं या विषयों में विभाजित करें, जैसे उत्पाद या आदेश। प्रत्येक विषय तब तालिका बन जाता है।
  4. सूचना विषय को कॉलम में बदलें - तय करें कि प्रत्येक तालिका में कौन सी जानकारी संग्रहीत करने की आवश्यकता है। प्रत्येक विषय क्षेत्र बन जाता है, और तालिका में कॉलम के रूप में प्रदर्शित होता है। उदाहरण के लिए, कर्मचारी तालिका में अंतिम नाम और किराया दिनांक जैसे क्षेत्र सम्मिलित हो सकते हैं।
  5. प्राथमिक कुंजी निर्दिष्ट करें - प्रत्येक तालिका की प्राथमिक कुंजी चुनें। प्राथमिक कुंजी स्तंभ, या स्तंभों का समूह है, जिसका उपयोग प्रत्येक पंक्ति को विशिष्ट रूप से पहचानने के लिए किया जाता है। उदाहरण उत्पाद आईडी या ऑर्डर आईडी हो सकता है।
  6. तालिका संबंध स्थापित करें - प्रत्येक तालिका को देखें और तय करें कि तालिका का डेटा अन्य तालिकाओं के डेटा से कैसे संबंधित है। आवश्यकतानुसार, संबंधों को स्पष्ट करने के लिए तालिकाओं में क्षेत्र जोड़ें या नई तालिकाएँ बनाएँ।
  7. डिज़ाइन को परिष्कृत करें - त्रुटियों के लिए डिज़ाइन का विश्लेषण करें। तालिकाएँ बनाएँ और मानक डेटा के कुछ रिकॉर्ड जोड़ें। जाँचें कि क्या परिणाम तालिकाओं से अपेक्षित रूप से आते हैं। आवश्यकतानुसार डिज़ाइन में समायोजन करें।
  8. डेटाबेस सामान्यीकरण प्रायुक्त करें - यह देखने के लिए कि क्या तालिकाओं को सही रूप से संरचित किया गया है, डेटा सामान्यीकरण नियम प्रायुक्त करें। आवश्यकतानुसार तालिकाओं में समायोजन करें।[4]


सामान्यीकरण

Main article: डेटाबेस सामान्यीकरण

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

डेटाबेस डिज़ाइन मार्गदर्शन का मानक भाग यह है कि डिज़ाइनर को पूरी तरह से सामान्यीकृत डिज़ाइन बनाना चाहिए; चयनात्मक असामान्यकरण बाद में किया जा सकता है, किन्तु केवल कंप्यूटर प्रदर्शन कारणों से। व्यापार-बंद भंडारण स्थान बनाम प्रदर्शन है। डिज़ाइन जितना अधिक सामान्यीकृत होता है, उतना ही कम डेटा अतिरेक होता है (और इसलिए, यह स्टोर करने के लिए कम स्थान लेता है), चूँकि, सामान्य डेटा पुनर्प्राप्ति पैटर्न को अब जटिल जुड़ने, मर्ज करने और सॉर्ट करने की आवश्यकता हो सकती है - जो अधिक डेटा लेता है पढ़ें, और चक्रों की गणना करें। कुछ मॉडलिंग विषयों, जैसे डेटा वेयरहाउस डिज़ाइन के लिए आयामी मॉडलिंग दृष्टिकोण, स्पष्ट रूप से गैर-सामान्यीकृत डिज़ाइनों की अनुशंसा करते हैं, अर्थात् डिज़ाइन जो बड़े हिस्से में 3एनएफ का पालन नहीं करते हैं। सामान्यीकरण में सामान्य रूप होते हैं जो 1एनएफ, 2एनएफ, 3एनएफ, बोयस-कॉड एनएफ (3.5एनएफ), 4एनएफ और 5एनएफ हैं

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

वैचारिक स्कीमा

Main article: वैचारिक स्कीमा


भौतिक डिजाइन

Main article: भौतिक डिजाइन

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

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

अनुप्रयोग स्तर पर, भौतिक डिज़ाइन के अन्य स्थितियों में संग्रहीत प्रक्रियाओं को परिभाषित करने की आवश्यकता, या भौतिक क्वेरी दृश्य, ऑनलाइन_विश्लेषणात्मक_स्वरूप क्यूब्स आदि सम्मिलित हो सकते हैं।

यह भी देखें


संदर्भ

  1. ↑ Teorey, T.J., Lightstone, S.S., et al., (2009). Database Design: Know it all.1st ed. Burlington, MA.: Morgan Kaufmann Publishers
  2. ↑ Teorey, T.; Lightstone, S. and Nadeau, T.(2005) Database Modeling & Design: Logical Design, 4th edition, Morgan Kaufmann Press. ISBN 0-12-685352-5
  3. ↑ Javed, Muhammad; Lin, Yuqing (2018). "Iterative Process for Generating ER Diagram from Unrestricted Requirements". Proceedings of the 13th International Conference on Evaluation of Novel Approaches to Software Engineering. SCITEPRESS - Science and Technology Publications: 192–204. doi:10.5220/0006778701920204. ISBN 978-989-758-300-1.
  4. ↑ Database design basics. (n.d.). Database design basics. Retrieved May 1, 2010, from https://support.office.com/en-US/article/Database-design-basics-EB2159CF-1E30-401A-8084-BD4F9C9CA1F5


अग्रिम पठन

  • S. Lightstone, T. Teorey, T. Nadeau, “Physical Database Design: the database professional's guide to exploiting indexes, views, storage, and more”, Morgan Kaufmann Press, 2007. ISBN 0-12-369389-6
  • M. Hईआरnandez, "Database Design for Mईआरe Mortals: A Hands-On Guide to Relational Database Design", 3rd Edition, Addison-Wesley Professional, 2013. ISBN 0-321-88449-3


बाहरी संबंध

Retrieved from ‘https://www.vigyanwiki.in/index.php?title=डाटाबेस_डिजाइन&oldid=110502’