डाटाबेस डिजाइन: Difference between revisions
(Created page with "{{Short description|Designing how data is held in a database}} डेटाबेस डिजाइन एक डेटाबेस मॉडल के अनुसार...") |
No edit summary |
||
| 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> | ||
डेटाबेस प्रबंधन प्रणाली तदनुसार डेटा का प्रबंधन करती है। | डेटाबेस प्रबंधन प्रणाली तदनुसार डेटा का प्रबंधन करती है। | ||
| Line 6: | Line 6: | ||
== संग्रहीत किए जाने वाले डेटा का निर्धारण == | == संग्रहीत किए जाने वाले डेटा का निर्धारण == | ||
अधिकांश मामलों में, | अधिकांश मामलों में, व्यक्ति जो डेटाबेस का डिज़ाइन कर रहा है, वह डेटाबेस डिज़ाइन के क्षेत्र में विशेषज्ञता वाला व्यक्ति है, न कि उस डोमेन में विशेषज्ञता, जिससे संग्रहीत किया जाने वाला डेटा तैयार किया जाता है। वित्तीय जानकारी, जैविक जानकारी आदि। इसलिए, डेटाबेस में संग्रहीत किए जाने वाले डेटा को उस व्यक्ति के सहयोग से निर्धारित किया जाना चाहिए, जिसके पास उस डोमेन में विशेषज्ञता है, और जो इस बात से अवगत है कि सिस्टम के भीतर कौन सा डेटा संग्रहीत किया जाना चाहिए। | ||
यह प्रक्रिया वह है जिसे आम तौर पर [[आवश्यकताओं के विश्लेषण]] का हिस्सा माना जाता है, और डोमेन ज्ञान वाले लोगों से आवश्यक जानकारी प्राप्त करने के लिए डेटाबेस डिज़ाइनर की ओर से कौशल की आवश्यकता होती है। ऐसा इसलिए है क्योंकि आवश्यक डोमेन ज्ञान वाले लोग अक्सर स्पष्ट रूप से व्यक्त नहीं कर सकते हैं कि डेटाबेस के लिए उनकी सिस्टम आवश्यकताएं क्या हैं क्योंकि वे असतत डेटा तत्वों के संदर्भ में सोचने के लिए अभ्यस्त नहीं हैं जिन्हें संग्रहित किया जाना चाहिए। संग्रहीत किए जाने वाले डेटा को आवश्यकता विशिष्टता द्वारा निर्धारित किया जा सकता है।<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> | ||
| Line 12: | Line 12: | ||
== डेटा संबंधों का निर्धारण == | == डेटा संबंधों का निर्धारण == | ||
बार डेटाबेस डिज़ाइनर को डेटा के बारे में पता होता है जिसे डेटाबेस में संग्रहीत किया जाना है, तो उन्हें यह निर्धारित करना होगा कि डेटा के भीतर निर्भरता कहाँ है। कभी-कभी जब डेटा बदला जाता है तो आप दूसरे डेटा को भी बदल सकते हैं जो दिखाई नहीं देता है। उदाहरण के लिए, नामों और पतों की सूची में, ऐसी स्थिति को मानते हुए जहां कई लोगों का ही पता हो सकता है, लेकिन व्यक्ति का से अधिक पता नहीं हो सकता, पता नाम पर निर्भर है। जब नाम और सूची प्रदान की जाती है तो पता विशिष्ट रूप से निर्धारित किया जा सकता है; हालाँकि, व्युत्क्रम धारण नहीं करता है - जब पता और सूची दी जाती है, तो नाम विशिष्ट रूप से निर्धारित नहीं किया जा सकता है क्योंकि पते पर कई लोग निवास कर सकते हैं। क्योंकि पता नाम से निर्धारित होता है, पता नाम पर निर्भर माना जाता है। | |||
(नोट: | (नोट: आम ग़लतफ़हमी यह है कि [[संबंधपरक मॉडल]] को डेटा तत्वों के बीच संबंधों के कथन के कारण कहा जाता है। यह सच नहीं है। संबंधपरक मॉडल को इसलिए नाम दिया गया है क्योंकि यह गणितीय संरचनाओं पर आधारित है जिसे [[संबंध (गणित)]] के रूप में जाना जाता है। .) | ||
== तार्किक रूप से संरचित डेटा == | == तार्किक रूप से संरचित डेटा == | ||
{{Main|Logical schema}} | {{Main|Logical schema}} | ||
बार जानकारी के विभिन्न टुकड़ों के बीच संबंध और निर्भरता निर्धारित हो जाने के बाद, डेटा को तार्किक संरचना में व्यवस्थित करना संभव है, जिसे तब [[डेटाबेस प्रबंधन प्रणाली]] द्वारा समर्थित स्टोरेज ऑब्जेक्ट में मैप किया जा सकता है। [[संबंधपरक डेटाबेस]] के मामले में स्टोरेज [[ऑब्जेक्ट डेटाबेस]] टेबल होते हैं जो पंक्तियों और कॉलम में डेटा स्टोर करते हैं। ऑब्जेक्ट डेटाबेस में स्टोरेज ऑब्जेक्ट सीधे [[वस्तु-उन्मुख प्रोग्रामिंग भाषा]] द्वारा उपयोग किए जाने वाले ऑब्जेक्ट से संबंधित होते हैं जो डेटा को प्रबंधित और एक्सेस करने वाले एप्लिकेशन को लिखने के लिए उपयोग किया जाता है। संबंधों को शामिल वस्तु वर्गों की विशेषताओं के रूप में या वस्तु वर्गों पर संचालित विधियों के रूप में परिभाषित किया जा सकता है। | |||
जिस तरह से यह मैपिंग आम तौर पर किया जाता है वह ऐसा होता है कि संबंधित डेटा का प्रत्येक सेट जो | जिस तरह से यह मैपिंग आम तौर पर किया जाता है वह ऐसा होता है कि संबंधित डेटा का प्रत्येक सेट जो वस्तु पर निर्भर करता है, चाहे वह वास्तविक हो या अमूर्त, तालिका में रखा जाता है। इन निर्भर वस्तुओं के बीच संबंध तब विभिन्न वस्तुओं के बीच लिंक के रूप में जमा हो जाते हैं। | ||
प्रत्येक तालिका | प्रत्येक तालिका तार्किक वस्तु या या अधिक तार्किक वस्तुओं के या अधिक उदाहरणों में शामिल होने वाले संबंध के कार्यान्वयन का प्रतिनिधित्व कर सकती है। तालिकाओं के बीच संबंधों को माता-पिता के साथ बाल तालिकाओं को जोड़ने वाले लिंक के रूप में संग्रहीत किया जा सकता है। चूंकि जटिल तार्किक संबंध स्वयं सारणी हैं, इसलिए संभवतः उनके पास से अधिक माता-पिता के लिंक होंगे। | ||
==ईआर आरेख (इकाई-संबंध मॉडल) == | ==ईआर आरेख (इकाई-संबंध मॉडल) == | ||
[[Image:ER Diagram MMORPG.png|thumb|320px| | [[Image:ER Diagram MMORPG.png|thumb|320px|नमूना इकाई-संबंध आरेख]]डेटाबेस डिज़ाइन में ER ([[इकाई-संबंध मॉडल]]) डायग्राम भी शामिल होते हैं। ईआर आरेख आरेख है जो डेटाबेस को कुशल तरीके से डिजाइन करने में मदद करता है। | ||
ईआर आरेखों में विशेषताओं को आमतौर पर विशेषता के नाम के साथ | ईआर आरेखों में विशेषताओं को आमतौर पर विशेषता के नाम के साथ अंडाकार के रूप में तैयार किया जाता है, जो उस इकाई या संबंध से जुड़ा होता है जिसमें विशेषता होती है। | ||
ईआर मॉडल आमतौर पर सूचना प्रणाली डिजाइन में उपयोग किए जाते हैं; उदाहरण के लिए, वे वैचारिक संरचना डिजाइन चरण के दौरान डेटाबेस में संग्रहीत की जाने वाली सूचना आवश्यकताओं और / या जानकारी के प्रकारों का वर्णन करने के लिए उपयोग किए जाते हैं।<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> | ||
== माइक्रोसॉफ्ट एक्सेस == के लिए | == माइक्रोसॉफ्ट एक्सेस == के लिए डिजाइन प्रक्रिया सुझाव | ||
#डेटाबेस का उद्देश्य निर्धारित करें - यह शेष चरणों के लिए तैयार करने में मदद करता है। | #डेटाबेस का उद्देश्य निर्धारित करें - यह शेष चरणों के लिए तैयार करने में मदद करता है। | ||
# आवश्यक जानकारी को ढूँढें और व्यवस्थित करें - डेटाबेस में रिकॉर्ड करने के लिए सभी प्रकार की जानकारी इकट्ठा करें, जैसे उत्पाद का नाम और ऑर्डर नंबर। | # आवश्यक जानकारी को ढूँढें और व्यवस्थित करें - डेटाबेस में रिकॉर्ड करने के लिए सभी प्रकार की जानकारी इकट्ठा करें, जैसे उत्पाद का नाम और ऑर्डर नंबर। | ||
# सूचनाओं को तालिकाओं में विभाजित करें - सूचना वस्तुओं को प्रमुख संस्थाओं या विषयों में विभाजित करें, जैसे उत्पाद या आदेश। प्रत्येक विषय तब | # सूचनाओं को तालिकाओं में विभाजित करें - सूचना वस्तुओं को प्रमुख संस्थाओं या विषयों में विभाजित करें, जैसे उत्पाद या आदेश। प्रत्येक विषय तब तालिका बन जाता है। | ||
# सूचना आइटम को कॉलम में बदलें - तय करें कि प्रत्येक तालिका में कौन सी जानकारी संग्रहीत करने की आवश्यकता है। प्रत्येक आइटम | # सूचना आइटम को कॉलम में बदलें - तय करें कि प्रत्येक तालिका में कौन सी जानकारी संग्रहीत करने की आवश्यकता है। प्रत्येक आइटम फ़ील्ड बन जाता है, और तालिका में कॉलम के रूप में प्रदर्शित होता है। उदाहरण के लिए, कर्मचारी तालिका में अंतिम नाम और किराया दिनांक जैसे फ़ील्ड शामिल हो सकते हैं। | ||
# प्राथमिक कुंजी निर्दिष्ट करें - प्रत्येक तालिका की प्राथमिक कुंजी चुनें। प्राथमिक कुंजी | # प्राथमिक कुंजी निर्दिष्ट करें - प्रत्येक तालिका की प्राथमिक कुंजी चुनें। प्राथमिक कुंजी स्तंभ, या स्तंभों का समूह है, जिसका उपयोग प्रत्येक पंक्ति को विशिष्ट रूप से पहचानने के लिए किया जाता है। उदाहरण उत्पाद आईडी या ऑर्डर आईडी हो सकता है। | ||
#तालिका संबंध स्थापित करें - प्रत्येक तालिका को देखें और तय करें कि | #तालिका संबंध स्थापित करें - प्रत्येक तालिका को देखें और तय करें कि तालिका का डेटा अन्य तालिकाओं के डेटा से कैसे संबंधित है। आवश्यकतानुसार, संबंधों को स्पष्ट करने के लिए तालिकाओं में फ़ील्ड जोड़ें या नई तालिकाएँ बनाएँ। | ||
# डिज़ाइन को परिष्कृत करें - त्रुटियों के लिए डिज़ाइन का विश्लेषण करें। तालिकाएँ बनाएँ और नमूना डेटा के कुछ रिकॉर्ड जोड़ें। जाँचें कि क्या परिणाम तालिकाओं से अपेक्षित रूप से आते हैं। आवश्यकतानुसार डिज़ाइन में समायोजन करें। | # डिज़ाइन को परिष्कृत करें - त्रुटियों के लिए डिज़ाइन का विश्लेषण करें। तालिकाएँ बनाएँ और नमूना डेटा के कुछ रिकॉर्ड जोड़ें। जाँचें कि क्या परिणाम तालिकाओं से अपेक्षित रूप से आते हैं। आवश्यकतानुसार डिज़ाइन में समायोजन करें। | ||
# [[डेटाबेस सामान्यीकरण]] लागू करें - यह देखने के लिए कि क्या तालिकाओं को सही ढंग से संरचित किया गया है, डेटा सामान्यीकरण नियम लागू करें। आवश्यकतानुसार तालिकाओं में समायोजन करें। | # [[डेटाबेस सामान्यीकरण]] लागू करें - यह देखने के लिए कि क्या तालिकाओं को सही ढंग से संरचित किया गया है, डेटा सामान्यीकरण नियम लागू करें। आवश्यकतानुसार तालिकाओं में समायोजन करें। | ||
| Line 47: | Line 47: | ||
== सामान्यीकरण == | == सामान्यीकरण == | ||
{{main|Database normalization}} | {{main|Database normalization}} | ||
[[संबंध का डेटाबेस]] डिज़ाइन के क्षेत्र में, सामान्यीकरण यह सुनिश्चित करने का | [[संबंध का डेटाबेस]] डिज़ाइन के क्षेत्र में, सामान्यीकरण यह सुनिश्चित करने का व्यवस्थित तरीका है कि डेटाबेस संरचना सामान्य-उद्देश्य क्वेरी के लिए उपयुक्त है और कुछ अवांछनीय विशेषताओं से मुक्त है - सम्मिलन, अद्यतन और विलोपन विसंगतियाँ जो डेटा अखंडता की हानि का कारण बन सकती हैं। | ||
डेटाबेस डिज़ाइन मार्गदर्शन का | डेटाबेस डिज़ाइन मार्गदर्शन का मानक भाग यह है कि डिज़ाइनर को पूरी तरह से सामान्यीकृत डिज़ाइन बनाना चाहिए; चयनात्मक असामान्यकरण बाद में किया जा सकता है, लेकिन केवल [[कंप्यूटर प्रदर्शन]] कारणों से। व्यापार-बंद भंडारण स्थान बनाम प्रदर्शन है। डिज़ाइन जितना अधिक सामान्यीकृत होता है, उतना ही कम डेटा अतिरेक होता है (और इसलिए, यह स्टोर करने के लिए कम स्थान लेता है), हालाँकि, सामान्य डेटा पुनर्प्राप्ति पैटर्न को अब जटिल जुड़ने, मर्ज करने और सॉर्ट करने की आवश्यकता हो सकती है - जो अधिक डेटा लेता है पढ़ें, और चक्रों की गणना करें। कुछ मॉडलिंग विषयों, जैसे [[डेटा वेयरहाउस]] डिज़ाइन के लिए [[आयामी मॉडलिंग]] दृष्टिकोण, स्पष्ट रूप से गैर-सामान्यीकृत डिज़ाइनों की अनुशंसा करते हैं, यानी डिज़ाइन जो बड़े हिस्से में 3NF का पालन नहीं करते हैं। | ||
सामान्यीकरण में सामान्य रूप होते हैं जो 1NF, 2NF, 3NF, BOYCE-CODD NF (3.5NF), 4NF और 5NF हैं | सामान्यीकरण में सामान्य रूप होते हैं जो 1NF, 2NF, 3NF, BOYCE-CODD NF (3.5NF), 4NF और 5NF हैं | ||
दस्तावेज़ डेटाबेस | दस्तावेज़ डेटाबेस अलग दृष्टिकोण लेते हैं। दस्तावेज़ जो ऐसे डेटाबेस में संग्रहीत होता है, आमतौर पर से अधिक सामान्यीकृत डेटा इकाई और अक्सर इकाइयों के बीच संबंध भी होते हैं। यदि सभी डेटा इकाइयां और संबंध अक्सर साथ पुनर्प्राप्त किए जाते हैं, तो यह दृष्टिकोण पुनर्प्राप्ति की संख्या को अनुकूलित करता है। यह यह भी सरल करता है कि डेटा को कैसे दोहराया जाता है, क्योंकि अब डेटा की स्पष्ट रूप से पहचान योग्य इकाई है जिसकी स्थिरता स्व-निहित है। अन्य विचार यह है कि ऐसे डेटाबेस में ही दस्तावेज़ को पढ़ने और लिखने के लिए ही लेन-देन की आवश्यकता होगी - जो कि [[माइक्रोसर्विसेज]] आर्किटेक्चर में महत्वपूर्ण विचार हो सकता है। ऐसी स्थितियों में, अक्सर, दस्तावेज़ के कुछ हिस्सों को एपीआई के माध्यम से अन्य सेवाओं से पुनर्प्राप्त किया जाता है और दक्षता कारणों से स्थानीय रूप से संग्रहीत किया जाता है। यदि डेटा इकाइयों को सेवाओं में विभाजित किया जाना था, तो सेवा उपभोक्ता का समर्थन करने के लिए पढ़ने (या लिखने) के लिए से अधिक सेवा कॉल की आवश्यकता हो सकती है, और इसके परिणामस्वरूप कई लेनदेन का प्रबंधन हो सकता है, जिसे प्राथमिकता नहीं दी जा सकती है। | ||
== वैचारिक स्कीमा == | == वैचारिक स्कीमा == | ||
| Line 60: | Line 60: | ||
== भौतिक डिजाइन == | == भौतिक डिजाइन == | ||
{{Main|Physical schema}} | {{Main|Physical schema}} | ||
डेटाबेस का भौतिक डिज़ाइन स्टोरेज मीडिया पर डेटाबेस के भौतिक कॉन्फ़िगरेशन को निर्दिष्ट करता है। इसमें [[डेटा तत्व]]ों, [[डेटा प्रकार]], [[सूचकांक (डेटाबेस)]] विकल्प और डीबीएमएस [[डेटा शब्दकोश]] में रहने वाले अन्य पैरामीटर के विस्तृत विनिर्देश शामिल हैं। यह | डेटाबेस का भौतिक डिज़ाइन स्टोरेज मीडिया पर डेटाबेस के भौतिक कॉन्फ़िगरेशन को निर्दिष्ट करता है। इसमें [[डेटा तत्व]]ों, [[डेटा प्रकार]], [[सूचकांक (डेटाबेस)]] विकल्प और डीबीएमएस [[डेटा शब्दकोश]] में रहने वाले अन्य पैरामीटर के विस्तृत विनिर्देश शामिल हैं। यह सिस्टम का विस्तृत डिज़ाइन है जिसमें मॉड्यूल और डेटाबेस के हार्डवेयर और सिस्टम के सॉफ़्टवेयर विनिर्देश शामिल हैं। कुछ पहलू जिन्हें भौतिक स्तर पर संबोधित किया गया है: | ||
* सुरक्षा - एंड-यूज़र, साथ ही प्रशासनिक सुरक्षा। | * सुरक्षा - एंड-यूज़र, साथ ही प्रशासनिक सुरक्षा। | ||
* प्रतिकृति - डेटा के कौन से टुकड़े दूसरे डेटाबेस में कॉपी किए जाते हैं, और कितनी बार। क्या कई-स्वामी हैं, या | * प्रतिकृति - डेटा के कौन से टुकड़े दूसरे डेटाबेस में कॉपी किए जाते हैं, और कितनी बार। क्या कई-स्वामी हैं, या ही? | ||
* उच्च-उपलब्धता - चाहे कॉन्फ़िगरेशन सक्रिय-निष्क्रिय हो, या सक्रिय-सक्रिय, टोपोलॉजी, समन्वय योजना, विश्वसनीयता लक्ष्य, आदि सभी को परिभाषित करना होगा। | * उच्च-उपलब्धता - चाहे कॉन्फ़िगरेशन सक्रिय-निष्क्रिय हो, या सक्रिय-सक्रिय, टोपोलॉजी, समन्वय योजना, विश्वसनीयता लक्ष्य, आदि सभी को परिभाषित करना होगा। | ||
* विभाजन - यदि डेटाबेस वितरित किया जाता है, तो | * विभाजन - यदि डेटाबेस वितरित किया जाता है, तो इकाई के लिए, डेटाबेस के सभी विभाजनों के बीच डेटा कैसे वितरित किया जाता है, और विभाजन विफलता को कैसे ध्यान में रखा जाता है। | ||
* बैकअप और योजनाओं को पुनर्स्थापित करें। | * बैकअप और योजनाओं को पुनर्स्थापित करें। | ||
Revision as of 09:29, 22 February 2023
डेटाबेस डिजाइन डेटाबेस मॉडल के अनुसार डेटा का संगठन है। डिज़ाइनर यह निर्धारित करता है कि कौन सा डेटा संग्रहीत किया जाना चाहिए और डेटा तत्व कैसे परस्पर संबंध रखते हैं। इस जानकारी के साथ, वे डेटा को डेटाबेस मॉडल में फिट करना शुरू कर सकते हैं।[1] डेटाबेस प्रबंधन प्रणाली तदनुसार डेटा का प्रबंधन करती है।
डेटाबेस डिज़ाइन में डेटा का वर्गीकरण और अंतर्संबंधों की पहचान करना शामिल है। डेटा के इस सैद्धांतिक प्रतिनिधित्व को ओन्टोलॉजी (सूचना विज्ञान) कहा जाता है। ऑन्कोलॉजी डेटाबेस के डिजाइन के पीछे का सिद्धांत है।
संग्रहीत किए जाने वाले डेटा का निर्धारण
अधिकांश मामलों में, व्यक्ति जो डेटाबेस का डिज़ाइन कर रहा है, वह डेटाबेस डिज़ाइन के क्षेत्र में विशेषज्ञता वाला व्यक्ति है, न कि उस डोमेन में विशेषज्ञता, जिससे संग्रहीत किया जाने वाला डेटा तैयार किया जाता है। वित्तीय जानकारी, जैविक जानकारी आदि। इसलिए, डेटाबेस में संग्रहीत किए जाने वाले डेटा को उस व्यक्ति के सहयोग से निर्धारित किया जाना चाहिए, जिसके पास उस डोमेन में विशेषज्ञता है, और जो इस बात से अवगत है कि सिस्टम के भीतर कौन सा डेटा संग्रहीत किया जाना चाहिए।
यह प्रक्रिया वह है जिसे आम तौर पर आवश्यकताओं के विश्लेषण का हिस्सा माना जाता है, और डोमेन ज्ञान वाले लोगों से आवश्यक जानकारी प्राप्त करने के लिए डेटाबेस डिज़ाइनर की ओर से कौशल की आवश्यकता होती है। ऐसा इसलिए है क्योंकि आवश्यक डोमेन ज्ञान वाले लोग अक्सर स्पष्ट रूप से व्यक्त नहीं कर सकते हैं कि डेटाबेस के लिए उनकी सिस्टम आवश्यकताएं क्या हैं क्योंकि वे असतत डेटा तत्वों के संदर्भ में सोचने के लिए अभ्यस्त नहीं हैं जिन्हें संग्रहित किया जाना चाहिए। संग्रहीत किए जाने वाले डेटा को आवश्यकता विशिष्टता द्वारा निर्धारित किया जा सकता है।[2]
डेटा संबंधों का निर्धारण
बार डेटाबेस डिज़ाइनर को डेटा के बारे में पता होता है जिसे डेटाबेस में संग्रहीत किया जाना है, तो उन्हें यह निर्धारित करना होगा कि डेटा के भीतर निर्भरता कहाँ है। कभी-कभी जब डेटा बदला जाता है तो आप दूसरे डेटा को भी बदल सकते हैं जो दिखाई नहीं देता है। उदाहरण के लिए, नामों और पतों की सूची में, ऐसी स्थिति को मानते हुए जहां कई लोगों का ही पता हो सकता है, लेकिन व्यक्ति का से अधिक पता नहीं हो सकता, पता नाम पर निर्भर है। जब नाम और सूची प्रदान की जाती है तो पता विशिष्ट रूप से निर्धारित किया जा सकता है; हालाँकि, व्युत्क्रम धारण नहीं करता है - जब पता और सूची दी जाती है, तो नाम विशिष्ट रूप से निर्धारित नहीं किया जा सकता है क्योंकि पते पर कई लोग निवास कर सकते हैं। क्योंकि पता नाम से निर्धारित होता है, पता नाम पर निर्भर माना जाता है।
(नोट: आम ग़लतफ़हमी यह है कि संबंधपरक मॉडल को डेटा तत्वों के बीच संबंधों के कथन के कारण कहा जाता है। यह सच नहीं है। संबंधपरक मॉडल को इसलिए नाम दिया गया है क्योंकि यह गणितीय संरचनाओं पर आधारित है जिसे संबंध (गणित) के रूप में जाना जाता है। .)
तार्किक रूप से संरचित डेटा
बार जानकारी के विभिन्न टुकड़ों के बीच संबंध और निर्भरता निर्धारित हो जाने के बाद, डेटा को तार्किक संरचना में व्यवस्थित करना संभव है, जिसे तब डेटाबेस प्रबंधन प्रणाली द्वारा समर्थित स्टोरेज ऑब्जेक्ट में मैप किया जा सकता है। संबंधपरक डेटाबेस के मामले में स्टोरेज ऑब्जेक्ट डेटाबेस टेबल होते हैं जो पंक्तियों और कॉलम में डेटा स्टोर करते हैं। ऑब्जेक्ट डेटाबेस में स्टोरेज ऑब्जेक्ट सीधे वस्तु-उन्मुख प्रोग्रामिंग भाषा द्वारा उपयोग किए जाने वाले ऑब्जेक्ट से संबंधित होते हैं जो डेटा को प्रबंधित और एक्सेस करने वाले एप्लिकेशन को लिखने के लिए उपयोग किया जाता है। संबंधों को शामिल वस्तु वर्गों की विशेषताओं के रूप में या वस्तु वर्गों पर संचालित विधियों के रूप में परिभाषित किया जा सकता है।
जिस तरह से यह मैपिंग आम तौर पर किया जाता है वह ऐसा होता है कि संबंधित डेटा का प्रत्येक सेट जो वस्तु पर निर्भर करता है, चाहे वह वास्तविक हो या अमूर्त, तालिका में रखा जाता है। इन निर्भर वस्तुओं के बीच संबंध तब विभिन्न वस्तुओं के बीच लिंक के रूप में जमा हो जाते हैं।
प्रत्येक तालिका तार्किक वस्तु या या अधिक तार्किक वस्तुओं के या अधिक उदाहरणों में शामिल होने वाले संबंध के कार्यान्वयन का प्रतिनिधित्व कर सकती है। तालिकाओं के बीच संबंधों को माता-पिता के साथ बाल तालिकाओं को जोड़ने वाले लिंक के रूप में संग्रहीत किया जा सकता है। चूंकि जटिल तार्किक संबंध स्वयं सारणी हैं, इसलिए संभवतः उनके पास से अधिक माता-पिता के लिंक होंगे।
ईआर आरेख (इकाई-संबंध मॉडल)
डेटाबेस डिज़ाइन में ER (इकाई-संबंध मॉडल) डायग्राम भी शामिल होते हैं। ईआर आरेख आरेख है जो डेटाबेस को कुशल तरीके से डिजाइन करने में मदद करता है।
ईआर आरेखों में विशेषताओं को आमतौर पर विशेषता के नाम के साथ अंडाकार के रूप में तैयार किया जाता है, जो उस इकाई या संबंध से जुड़ा होता है जिसमें विशेषता होती है।
ईआर मॉडल आमतौर पर सूचना प्रणाली डिजाइन में उपयोग किए जाते हैं; उदाहरण के लिए, वे वैचारिक संरचना डिजाइन चरण के दौरान डेटाबेस में संग्रहीत की जाने वाली सूचना आवश्यकताओं और / या जानकारी के प्रकारों का वर्णन करने के लिए उपयोग किए जाते हैं।[3]
== माइक्रोसॉफ्ट एक्सेस == के लिए डिजाइन प्रक्रिया सुझाव
- डेटाबेस का उद्देश्य निर्धारित करें - यह शेष चरणों के लिए तैयार करने में मदद करता है।
- आवश्यक जानकारी को ढूँढें और व्यवस्थित करें - डेटाबेस में रिकॉर्ड करने के लिए सभी प्रकार की जानकारी इकट्ठा करें, जैसे उत्पाद का नाम और ऑर्डर नंबर।
- सूचनाओं को तालिकाओं में विभाजित करें - सूचना वस्तुओं को प्रमुख संस्थाओं या विषयों में विभाजित करें, जैसे उत्पाद या आदेश। प्रत्येक विषय तब तालिका बन जाता है।
- सूचना आइटम को कॉलम में बदलें - तय करें कि प्रत्येक तालिका में कौन सी जानकारी संग्रहीत करने की आवश्यकता है। प्रत्येक आइटम फ़ील्ड बन जाता है, और तालिका में कॉलम के रूप में प्रदर्शित होता है। उदाहरण के लिए, कर्मचारी तालिका में अंतिम नाम और किराया दिनांक जैसे फ़ील्ड शामिल हो सकते हैं।
- प्राथमिक कुंजी निर्दिष्ट करें - प्रत्येक तालिका की प्राथमिक कुंजी चुनें। प्राथमिक कुंजी स्तंभ, या स्तंभों का समूह है, जिसका उपयोग प्रत्येक पंक्ति को विशिष्ट रूप से पहचानने के लिए किया जाता है। उदाहरण उत्पाद आईडी या ऑर्डर आईडी हो सकता है।
- तालिका संबंध स्थापित करें - प्रत्येक तालिका को देखें और तय करें कि तालिका का डेटा अन्य तालिकाओं के डेटा से कैसे संबंधित है। आवश्यकतानुसार, संबंधों को स्पष्ट करने के लिए तालिकाओं में फ़ील्ड जोड़ें या नई तालिकाएँ बनाएँ।
- डिज़ाइन को परिष्कृत करें - त्रुटियों के लिए डिज़ाइन का विश्लेषण करें। तालिकाएँ बनाएँ और नमूना डेटा के कुछ रिकॉर्ड जोड़ें। जाँचें कि क्या परिणाम तालिकाओं से अपेक्षित रूप से आते हैं। आवश्यकतानुसार डिज़ाइन में समायोजन करें।
- डेटाबेस सामान्यीकरण लागू करें - यह देखने के लिए कि क्या तालिकाओं को सही ढंग से संरचित किया गया है, डेटा सामान्यीकरण नियम लागू करें। आवश्यकतानुसार तालिकाओं में समायोजन करें।
सामान्यीकरण
संबंध का डेटाबेस डिज़ाइन के क्षेत्र में, सामान्यीकरण यह सुनिश्चित करने का व्यवस्थित तरीका है कि डेटाबेस संरचना सामान्य-उद्देश्य क्वेरी के लिए उपयुक्त है और कुछ अवांछनीय विशेषताओं से मुक्त है - सम्मिलन, अद्यतन और विलोपन विसंगतियाँ जो डेटा अखंडता की हानि का कारण बन सकती हैं।
डेटाबेस डिज़ाइन मार्गदर्शन का मानक भाग यह है कि डिज़ाइनर को पूरी तरह से सामान्यीकृत डिज़ाइन बनाना चाहिए; चयनात्मक असामान्यकरण बाद में किया जा सकता है, लेकिन केवल कंप्यूटर प्रदर्शन कारणों से। व्यापार-बंद भंडारण स्थान बनाम प्रदर्शन है। डिज़ाइन जितना अधिक सामान्यीकृत होता है, उतना ही कम डेटा अतिरेक होता है (और इसलिए, यह स्टोर करने के लिए कम स्थान लेता है), हालाँकि, सामान्य डेटा पुनर्प्राप्ति पैटर्न को अब जटिल जुड़ने, मर्ज करने और सॉर्ट करने की आवश्यकता हो सकती है - जो अधिक डेटा लेता है पढ़ें, और चक्रों की गणना करें। कुछ मॉडलिंग विषयों, जैसे डेटा वेयरहाउस डिज़ाइन के लिए आयामी मॉडलिंग दृष्टिकोण, स्पष्ट रूप से गैर-सामान्यीकृत डिज़ाइनों की अनुशंसा करते हैं, यानी डिज़ाइन जो बड़े हिस्से में 3NF का पालन नहीं करते हैं। सामान्यीकरण में सामान्य रूप होते हैं जो 1NF, 2NF, 3NF, BOYCE-CODD NF (3.5NF), 4NF और 5NF हैं
दस्तावेज़ डेटाबेस अलग दृष्टिकोण लेते हैं। दस्तावेज़ जो ऐसे डेटाबेस में संग्रहीत होता है, आमतौर पर से अधिक सामान्यीकृत डेटा इकाई और अक्सर इकाइयों के बीच संबंध भी होते हैं। यदि सभी डेटा इकाइयां और संबंध अक्सर साथ पुनर्प्राप्त किए जाते हैं, तो यह दृष्टिकोण पुनर्प्राप्ति की संख्या को अनुकूलित करता है। यह यह भी सरल करता है कि डेटा को कैसे दोहराया जाता है, क्योंकि अब डेटा की स्पष्ट रूप से पहचान योग्य इकाई है जिसकी स्थिरता स्व-निहित है। अन्य विचार यह है कि ऐसे डेटाबेस में ही दस्तावेज़ को पढ़ने और लिखने के लिए ही लेन-देन की आवश्यकता होगी - जो कि माइक्रोसर्विसेज आर्किटेक्चर में महत्वपूर्ण विचार हो सकता है। ऐसी स्थितियों में, अक्सर, दस्तावेज़ के कुछ हिस्सों को एपीआई के माध्यम से अन्य सेवाओं से पुनर्प्राप्त किया जाता है और दक्षता कारणों से स्थानीय रूप से संग्रहीत किया जाता है। यदि डेटा इकाइयों को सेवाओं में विभाजित किया जाना था, तो सेवा उपभोक्ता का समर्थन करने के लिए पढ़ने (या लिखने) के लिए से अधिक सेवा कॉल की आवश्यकता हो सकती है, और इसके परिणामस्वरूप कई लेनदेन का प्रबंधन हो सकता है, जिसे प्राथमिकता नहीं दी जा सकती है।
वैचारिक स्कीमा
भौतिक डिजाइन
डेटाबेस का भौतिक डिज़ाइन स्टोरेज मीडिया पर डेटाबेस के भौतिक कॉन्फ़िगरेशन को निर्दिष्ट करता है। इसमें डेटा तत्वों, डेटा प्रकार, सूचकांक (डेटाबेस) विकल्प और डीबीएमएस डेटा शब्दकोश में रहने वाले अन्य पैरामीटर के विस्तृत विनिर्देश शामिल हैं। यह सिस्टम का विस्तृत डिज़ाइन है जिसमें मॉड्यूल और डेटाबेस के हार्डवेयर और सिस्टम के सॉफ़्टवेयर विनिर्देश शामिल हैं। कुछ पहलू जिन्हें भौतिक स्तर पर संबोधित किया गया है:
- सुरक्षा - एंड-यूज़र, साथ ही प्रशासनिक सुरक्षा।
- प्रतिकृति - डेटा के कौन से टुकड़े दूसरे डेटाबेस में कॉपी किए जाते हैं, और कितनी बार। क्या कई-स्वामी हैं, या ही?
- उच्च-उपलब्धता - चाहे कॉन्फ़िगरेशन सक्रिय-निष्क्रिय हो, या सक्रिय-सक्रिय, टोपोलॉजी, समन्वय योजना, विश्वसनीयता लक्ष्य, आदि सभी को परिभाषित करना होगा।
- विभाजन - यदि डेटाबेस वितरित किया जाता है, तो इकाई के लिए, डेटाबेस के सभी विभाजनों के बीच डेटा कैसे वितरित किया जाता है, और विभाजन विफलता को कैसे ध्यान में रखा जाता है।
- बैकअप और योजनाओं को पुनर्स्थापित करें।
अनुप्रयोग स्तर पर, भौतिक डिज़ाइन के अन्य पहलुओं में संग्रहीत प्रक्रियाओं को परिभाषित करने की आवश्यकता, या भौतिक क्वेरी दृश्य, ऑनलाइन_विश्लेषणात्मक_प्रोसेसिंग क्यूब्स आदि शामिल हो सकते हैं।
यह भी देखें
- 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
संदर्भ
- ↑ Teorey, T.J., Lightstone, S.S., et al., (2009). Database Design: Know it all.1st ed. Burlington, MA.: Morgan Kaufmann Publishers
- ↑ Teorey, T.; Lightstone, S. and Nadeau, T.(2005) Database Modeling & Design: Logical Design, 4th edition, Morgan Kaufmann Press. ISBN 0-12-685352-5
- ↑ 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.
- ↑ 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. Hernandez, "Database Design for Mere Mortals: A Hands-On Guide to Relational Database Design", 3rd Edition, Addison-Wesley Professional, 2013. ISBN 0-321-88449-3
बाहरी संबंध
- [1]
- [2]
- Database Normalization Basics by Mike Chapple (About.com)
- Database Normalization Intro, Part 2
- "An Introduction to Database Normalization". Archived from the original on 2011-06-06. Retrieved 2012-02-25.
- "Normalization". Archived from the original on 2010-01-06. Retrieved 2012-02-25.
- डाटाबेस डिजाइन at Curlie
| Main | |
|---|---|
| Languages | |
| Security | |
| Design |
|
| Programming | |
| Management | |
| See also | |
| Types | |
|---|---|
| Concepts | |
| Objects | |
| Components | |
| Functions | |
| Related topics | |
