डाटाबेस डिजाइन: Difference between revisions
No edit summary |
No edit summary |
||
| Line 4: | Line 4: | ||
डेटाबेस प्रबंधन प्रणाली तदनुसार डेटा का प्रबंधन करती है। | डेटाबेस प्रबंधन प्रणाली तदनुसार डेटा का प्रबंधन करती है। | ||
डेटाबेस डिज़ाइन में डेटा का वर्गीकरण और अंतर्संबंधों की पहचान करना | डेटाबेस डिज़ाइन में डेटा का वर्गीकरण और अंतर्संबंधों की पहचान करना सम्मिलित है। डेटा के इस सैद्धांतिक प्रतिनिधित्व को ओन्टोलॉजी (सूचना विज्ञान) कहा जाता है। ऑन्कोलॉजी डेटाबेस के डिजाइन के पीछे का सिद्धांत है। | ||
== संग्रहीत किए जाने वाले डेटा का निर्धारण == | == संग्रहीत किए जाने वाले डेटा का निर्धारण == | ||
अधिकांश | अधिकांश स्थितियों में, एक व्यक्ति जो डेटाबेस का डिज़ाइन कर रहा है, वह डोमेन में विशेषज्ञता के अतिरिक्त डेटाबेस डिज़ाइन के क्षेत्र में विशेषज्ञता रखने वाला व्यक्ति है, जिससे संग्रहीत किया जाने वाला डेटा तैयार किया जाता है, जैसे वित्तीय जानकारी, जैविक जानकारी आदि। इसलिए, डेटाबेस में संग्रहीत किए जाने वाले डेटा को उस व्यक्ति के सहयोग से निर्धारित किया जाना चाहिए जिसके पास उस डोमेन में विशेषज्ञता है, और जो इस बात से अवगत है कि प्रणाली के अन्दर कौन सा डेटा संग्रहीत किया जाना चाहिए। | ||
यह प्रक्रिया वह है जिसे | यह प्रक्रिया वह है जिसे सामान्यतः [[आवश्यकताओं के विश्लेषण]] का भाग माना जाता है, और डोमेन ज्ञान वाले लोगों से आवश्यक जानकारी प्राप्त करने के लिए डेटाबेस डिज़ाइनर की ओर से कौशल की आवश्यकता होती है। ऐसा इसलिए है क्योंकि आवश्यक डोमेन ज्ञान वाले लोग अधिकांश स्पष्ट रूप से व्यक्त नहीं कर सकते हैं कि डेटाबेस के लिए उनकी प्रणाली आवश्यकताएं क्या हैं क्योंकि वे असतत डेटा तत्वों के संदर्भ में सोचने के लिए अभ्यस्त नहीं हैं जिन्हें संग्रहित किया जाना चाहिए। संग्रहीत किए जाने वाले डेटा को आवश्यकता विशिष्टता द्वारा निर्धारित किया जा सकता है।<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 19: | Line 19: | ||
== तार्किक रूप से संरचित डेटा == | == तार्किक रूप से संरचित डेटा == | ||
{{Main|तार्किक स्कीमा}} | {{Main|तार्किक स्कीमा}} | ||
बार जानकारी के विभिन्न टुकड़ों के बीच संबंध और निर्भरता निर्धारित हो जाने के बाद, डेटा को तार्किक संरचना में व्यवस्थित करना संभव है, जिसे तब [[डेटाबेस प्रबंधन प्रणाली]] द्वारा समर्थित भण्डारण ऑब्जेक्ट में मैप किया जा सकता है। [[संबंधपरक डेटाबेस]] के | बार जानकारी के विभिन्न टुकड़ों के बीच संबंध और निर्भरता निर्धारित हो जाने के बाद, डेटा को तार्किक संरचना में व्यवस्थित करना संभव है, जिसे तब [[डेटाबेस प्रबंधन प्रणाली]] द्वारा समर्थित भण्डारण ऑब्जेक्ट में मैप किया जा सकता है। [[संबंधपरक डेटाबेस]] के स्थितियों में भण्डारण [[ऑब्जेक्ट डेटाबेस]] सरणी होते हैं जो पंक्तियों और कॉलम में डेटा स्टोर करते हैं। ऑब्जेक्ट डेटाबेस में भण्डारण ऑब्जेक्ट सीधे [[वस्तु-उन्मुख प्रोग्रामिंग भाषा]] द्वारा उपयोग किए जाने वाले ऑब्जेक्ट से संबंधित होते हैं जो डेटा को प्रबंधित और अभिगम करने वाले एप्लिकेशन को लिखने के लिए उपयोग किया जाता है। संबंधों को सम्मिलित वस्तु वर्गों की विशेषताओं के रूप में या वस्तु वर्गों पर संचालित विधियों के रूप में परिभाषित किया जा सकता है। | ||
जिस | जिस प्रकार से यह मैपिंग सामान्यतः किया जाता है वह ऐसा होता है कि संबंधित डेटा का प्रत्येक समुच्चय जो वस्तु पर निर्भर करता है, चाहे वह वास्तविक हो या अमूर्त, तालिका में रखा जाता है। इन निर्भर वस्तुओं के बीच संबंध तब विभिन्न वस्तुओं के बीच शृंखला के रूप में जमा हो जाते हैं। | ||
प्रत्येक तालिका तार्किक वस्तु या या अधिक तार्किक वस्तुओं के या अधिक उदाहरणों में | प्रत्येक तालिका तार्किक वस्तु या या अधिक तार्किक वस्तुओं के या अधिक उदाहरणों में सम्मिलित होने वाले संबंध के कार्यान्वयन का प्रतिनिधित्व कर सकती है। तालिकाओं के बीच संबंधों को माता-पिता के साथ बाल तालिकाओं को जोड़ने वाले शृंखला के रूप में संग्रहीत किया जा सकता है। चूंकि जटिल तार्किक संबंध स्वयं सारणी हैं, इसलिए संभवतः उनके पास से अधिक माता-पिता के शृंखला होंगे। | ||
==ईआर आरेख (इकाई-संबंध मॉडल) == | ==ईआर आरेख (इकाई-संबंध मॉडल) == | ||
[[Image:ER Diagram MMORPG.png|thumb|320px| | [[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>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|डेटाबेस सामान्यीकरण}} | {{main|डेटाबेस सामान्यीकरण}} | ||
[[संबंध का डेटाबेस]] डिज़ाइन के क्षेत्र में, सामान्यीकरण यह सुनिश्चित करने का व्यवस्थित | [[संबंध का डेटाबेस]] डिज़ाइन के क्षेत्र में, सामान्यीकरण यह सुनिश्चित करने का व्यवस्थित विधि है कि डेटाबेस संरचना सामान्य-उद्देश्य क्वेरी के लिए उपयुक्त है और कुछ अवांछनीय विशेषताओं से मुक्त है - सम्मिलन, अद्यतन और विलोपन विसंगतियाँ जो डेटा अखंडता की हानि का कारण बन सकती हैं। | ||
डेटाबेस डिज़ाइन मार्गदर्शन का मानक भाग यह है कि डिज़ाइनर को पूरी तरह से सामान्यीकृत डिज़ाइन बनाना चाहिए; चयनात्मक असामान्यकरण बाद में किया जा सकता है, | डेटाबेस डिज़ाइन मार्गदर्शन का मानक भाग यह है कि डिज़ाइनर को पूरी तरह से सामान्यीकृत डिज़ाइन बनाना चाहिए; चयनात्मक असामान्यकरण बाद में किया जा सकता है, किन्तु केवल [[कंप्यूटर प्रदर्शन]] कारणों से। व्यापार-बंद भंडारण स्थान बनाम प्रदर्शन है। डिज़ाइन जितना अधिक सामान्यीकृत होता है, उतना ही कम डेटा अतिरेक होता है (और इसलिए, यह स्टोर करने के लिए कम स्थान लेता है), चूँकि, सामान्य डेटा पुनर्प्राप्ति पैटर्न को अब जटिल जुड़ने, मर्ज करने और सॉर्ट करने की आवश्यकता हो सकती है - जो अधिक डेटा लेता है पढ़ें, और चक्रों की गणना करें। कुछ मॉडलिंग विषयों, जैसे [[डेटा वेयरहाउस]] डिज़ाइन के लिए [[आयामी मॉडलिंग]] दृष्टिकोण, स्पष्ट रूप से गैर-सामान्यीकृत डिज़ाइनों की अनुशंसा करते हैं, अर्थात् डिज़ाइन जो बड़े हिस्से में 3एनएफ का पालन नहीं करते हैं। | ||
सामान्यीकरण में सामान्य रूप होते हैं जो 1एनएफ, 2एनएफ, 3एनएफ, बोयस-कॉड एनएफ (3.5एनएफ), 4एनएफ और 5एनएफ हैं | सामान्यीकरण में सामान्य रूप होते हैं जो 1एनएफ, 2एनएफ, 3एनएफ, बोयस-कॉड एनएफ (3.5एनएफ), 4एनएफ और 5एनएफ हैं | ||
दस्तावेज़ डेटाबेस अलग दृष्टिकोण लेते हैं। दस्तावेज़ जो ऐसे डेटाबेस में संग्रहीत होता है, | दस्तावेज़ डेटाबेस अलग दृष्टिकोण लेते हैं। दस्तावेज़ जो ऐसे डेटाबेस में संग्रहीत होता है, सामान्यतः से अधिक सामान्यीकृत डेटा इकाई और अधिकांश इकाइयों के बीच संबंध भी होते हैं। यदि सभी डेटा इकाइयां और संबंध अधिकांश साथ पुनर्प्राप्त किए जाते हैं, तो यह दृष्टिकोण पुनर्प्राप्ति की संख्या को अनुकूलित करता है। यह यह भी सरल करता है कि डेटा को कैसे दोहराया जाता है, क्योंकि अब डेटा की स्पष्ट रूप से पहचान योग्य इकाई है जिसकी स्थिरता स्व-निहित है। अन्य विचार यह है कि ऐसे डेटाबेस में ही दस्तावेज़ को पढ़ने और लिखने के लिए ही लेन-देन की आवश्यकता होगी - जो कि [[माइक्रोसर्विसेज]] आर्किटेक्चर में महत्वपूर्ण विचार हो सकता है। ऐसी स्थितियों में, अधिकांश, दस्तावेज़ के कुछ हिस्सों को एपीआई के माध्यम से अन्य सेवाओं से पुनर्प्राप्त किया जाता है और दक्षता कारणों से स्थानीय रूप से संग्रहीत किया जाता है। यदि डेटा इकाइयों को सेवाओं में विभाजित किया जाना था, तो सेवा उपभोक्ता का समर्थन करने के लिए पढ़ने (या लिखने) के लिए से अधिक सेवा कॉल की आवश्यकता हो सकती है, और इसके परिणामस्वरूप कई लेनदेन का प्रबंधन हो सकता है, जिसे प्राथमिकता नहीं दी जा सकती है। | ||
== वैचारिक स्कीमा == | == वैचारिक स्कीमा == | ||
| Line 60: | Line 60: | ||
{{Main|भौतिक डिजाइन}} | {{Main|भौतिक डिजाइन}} | ||
डेटाबेस का भौतिक डिज़ाइन भण्डारण मीडिया पर डेटाबेस के भौतिक विन्यास को निर्दिष्ट करता है। इसमें [[डेटा तत्व|डेटा तत्वों]], [[डेटा प्रकार]], [[सूचकांक (डेटाबेस)]] विकल्प और डीबीएमएस [[डेटा शब्दकोश]] में रहने वाले अन्य पैरामीटर के विस्तृत विनिर्देश | डेटाबेस का भौतिक डिज़ाइन भण्डारण मीडिया पर डेटाबेस के भौतिक विन्यास को निर्दिष्ट करता है। इसमें [[डेटा तत्व|डेटा तत्वों]], [[डेटा प्रकार]], [[सूचकांक (डेटाबेस)]] विकल्प और डीबीएमएस [[डेटा शब्दकोश]] में रहने वाले अन्य पैरामीटर के विस्तृत विनिर्देश सम्मिलित हैं। यह प्रणाली का विस्तृत डिज़ाइन है जिसमें मॉड्यूल और डेटाबेस के हार्डवेयर और प्रणाली के सॉफ़्टवेयर विनिर्देश सम्मिलित हैं। कुछ स्थिति जिन्हें भौतिक स्तर पर संबोधित किया गया है: | ||
* सुरक्षा - एंड-यूज़र, साथ ही प्रशासनिक सुरक्षा। | * सुरक्षा - एंड-यूज़र, साथ ही प्रशासनिक सुरक्षा। | ||
* प्रतिकृति - डेटा के कौन से टुकड़े दूसरे डेटाबेस में और कितनी बार कॉपी किए जाते हैं। क्या कई-स्वामी या एक ही हैं? | * प्रतिकृति - डेटा के कौन से टुकड़े दूसरे डेटाबेस में और कितनी बार कॉपी किए जाते हैं। क्या कई-स्वामी या एक ही हैं? | ||
| Line 67: | Line 67: | ||
* बैकअप और योजनाओं को पुनर्स्थापित करें। | * बैकअप और योजनाओं को पुनर्स्थापित करें। | ||
अनुप्रयोग स्तर पर, भौतिक डिज़ाइन के अन्य | अनुप्रयोग स्तर पर, भौतिक डिज़ाइन के अन्य स्थितियों में संग्रहीत प्रक्रियाओं को परिभाषित करने की आवश्यकता, या भौतिक क्वेरी दृश्य, ऑनलाइन_विश्लेषणात्मक_स्वरूप क्यूब्स आदि सम्मिलित हो सकते हैं। | ||
== यह भी देखें == | == यह भी देखें == | ||
Revision as of 10:35, 22 February 2023
डेटाबेस डिजाइन डेटाबेस मॉडल के अनुसार डेटा का संगठन है। डिज़ाइनर यह निर्धारित करता है कि कौन सा डेटा संग्रहीत किया जाना चाहिए और डेटा तत्व कैसे परस्पर संबंध रखते हैं। इस जानकारी के साथ, वे डेटा को डेटाबेस मॉडल में फिट करना प्रारंभ कर सकते हैं।[1]
डेटाबेस प्रबंधन प्रणाली तदनुसार डेटा का प्रबंधन करती है।
डेटाबेस डिज़ाइन में डेटा का वर्गीकरण और अंतर्संबंधों की पहचान करना सम्मिलित है। डेटा के इस सैद्धांतिक प्रतिनिधित्व को ओन्टोलॉजी (सूचना विज्ञान) कहा जाता है। ऑन्कोलॉजी डेटाबेस के डिजाइन के पीछे का सिद्धांत है।
संग्रहीत किए जाने वाले डेटा का निर्धारण
अधिकांश स्थितियों में, एक व्यक्ति जो डेटाबेस का डिज़ाइन कर रहा है, वह डोमेन में विशेषज्ञता के अतिरिक्त डेटाबेस डिज़ाइन के क्षेत्र में विशेषज्ञता रखने वाला व्यक्ति है, जिससे संग्रहीत किया जाने वाला डेटा तैयार किया जाता है, जैसे वित्तीय जानकारी, जैविक जानकारी आदि। इसलिए, डेटाबेस में संग्रहीत किए जाने वाले डेटा को उस व्यक्ति के सहयोग से निर्धारित किया जाना चाहिए जिसके पास उस डोमेन में विशेषज्ञता है, और जो इस बात से अवगत है कि प्रणाली के अन्दर कौन सा डेटा संग्रहीत किया जाना चाहिए।
यह प्रक्रिया वह है जिसे सामान्यतः आवश्यकताओं के विश्लेषण का भाग माना जाता है, और डोमेन ज्ञान वाले लोगों से आवश्यक जानकारी प्राप्त करने के लिए डेटाबेस डिज़ाइनर की ओर से कौशल की आवश्यकता होती है। ऐसा इसलिए है क्योंकि आवश्यक डोमेन ज्ञान वाले लोग अधिकांश स्पष्ट रूप से व्यक्त नहीं कर सकते हैं कि डेटाबेस के लिए उनकी प्रणाली आवश्यकताएं क्या हैं क्योंकि वे असतत डेटा तत्वों के संदर्भ में सोचने के लिए अभ्यस्त नहीं हैं जिन्हें संग्रहित किया जाना चाहिए। संग्रहीत किए जाने वाले डेटा को आवश्यकता विशिष्टता द्वारा निर्धारित किया जा सकता है।[2]
डेटा संबंधों का निर्धारण
बार डेटाबेस डिज़ाइनर को डेटा के बारे में पता होता है जिसे डेटाबेस में संग्रहीत किया जाना है, तो उन्हें यह निर्धारित करना होगा कि डेटा के अन्दर निर्भरता कहाँ है। कभी-कभी जब डेटा बदला जाता है तो आप दूसरे डेटा को भी बदल सकते हैं जो दिखाई नहीं देता है। उदाहरण के लिए, नामों और पतों की सूची में, ऐसी स्थिति को मानते हुए जहां कई लोगों का ही पता हो सकता है, किन्तु व्यक्ति का से अधिक पता नहीं हो सकता, पता नाम पर निर्भर है। जब नाम और सूची प्रदान की जाती है तो पता विशिष्ट रूप से निर्धारित किया जा सकता है; चूँकि, व्युत्क्रम धारण नहीं करता है - जब पता और सूची दी जाती है, तो नाम विशिष्ट रूप से निर्धारित नहीं किया जा सकता है क्योंकि पते पर कई लोग निवास कर सकते हैं। क्योंकि पता नाम से निर्धारित होता है, पता नाम पर निर्भर माना जाता है।
(नोट: आम ग़लतफ़हमी यह है कि संबंधपरक मॉडल को डेटा तत्वों के बीच संबंधों के कथन के कारण कहा जाता है। यह सच नहीं है। संबंधपरक मॉडल को इसलिए नाम दिया गया है क्योंकि यह गणितीय संरचनाओं पर आधारित है जिसे संबंध (गणित) के रूप में जाना जाता है। .)
तार्किक रूप से संरचित डेटा
बार जानकारी के विभिन्न टुकड़ों के बीच संबंध और निर्भरता निर्धारित हो जाने के बाद, डेटा को तार्किक संरचना में व्यवस्थित करना संभव है, जिसे तब डेटाबेस प्रबंधन प्रणाली द्वारा समर्थित भण्डारण ऑब्जेक्ट में मैप किया जा सकता है। संबंधपरक डेटाबेस के स्थितियों में भण्डारण ऑब्जेक्ट डेटाबेस सरणी होते हैं जो पंक्तियों और कॉलम में डेटा स्टोर करते हैं। ऑब्जेक्ट डेटाबेस में भण्डारण ऑब्जेक्ट सीधे वस्तु-उन्मुख प्रोग्रामिंग भाषा द्वारा उपयोग किए जाने वाले ऑब्जेक्ट से संबंधित होते हैं जो डेटा को प्रबंधित और अभिगम करने वाले एप्लिकेशन को लिखने के लिए उपयोग किया जाता है। संबंधों को सम्मिलित वस्तु वर्गों की विशेषताओं के रूप में या वस्तु वर्गों पर संचालित विधियों के रूप में परिभाषित किया जा सकता है।
जिस प्रकार से यह मैपिंग सामान्यतः किया जाता है वह ऐसा होता है कि संबंधित डेटा का प्रत्येक समुच्चय जो वस्तु पर निर्भर करता है, चाहे वह वास्तविक हो या अमूर्त, तालिका में रखा जाता है। इन निर्भर वस्तुओं के बीच संबंध तब विभिन्न वस्तुओं के बीच शृंखला के रूप में जमा हो जाते हैं।
प्रत्येक तालिका तार्किक वस्तु या या अधिक तार्किक वस्तुओं के या अधिक उदाहरणों में सम्मिलित होने वाले संबंध के कार्यान्वयन का प्रतिनिधित्व कर सकती है। तालिकाओं के बीच संबंधों को माता-पिता के साथ बाल तालिकाओं को जोड़ने वाले शृंखला के रूप में संग्रहीत किया जा सकता है। चूंकि जटिल तार्किक संबंध स्वयं सारणी हैं, इसलिए संभवतः उनके पास से अधिक माता-पिता के शृंखला होंगे।
ईआर आरेख (इकाई-संबंध मॉडल)
डेटाबेस डिज़ाइन में ईआर (इकाई-संबंध मॉडल) डायग्राम भी सम्मिलित होते हैं। ईआर आरेख आरेख है जो डेटाबेस को कुशल विधियों से डिजाइन करने में सहायता करता है।
ईआर आरेखों में विशेषताओं को सामान्यतः विशेषता के नाम के साथ अंडाकार के रूप में तैयार किया जाता है, जो उस इकाई या संबंध से जुड़ा होता है जिसमें विशेषता होती है।
ईआर मॉडल सामान्यतः सूचना प्रणाली डिजाइन में उपयोग किए जाते हैं; उदाहरण के लिए, वे वैचारिक संरचना डिजाइन चरण के समय डेटाबेस में संग्रहीत की जाने वाली सूचना आवश्यकताओं और / या जानकारी के प्रकारों का वर्णन करने के लिए उपयोग किए जाते हैं।[3]
माइक्रोसॉफ्ट अभिगम के लिए डिजाइन प्रक्रिया सुझाव
- डेटाबेस का उद्देश्य निर्धारित करें - यह शेष चरणों के लिए तैयार करने में सहायता करता है।
- आवश्यक जानकारी को ढूँढें और व्यवस्थित करें - डेटाबेस में रिकॉर्ड करने के लिए सभी प्रकार की जानकारी एकत्र करें, जैसे उत्पाद का नाम और क्रम संख्या।
- सूचनाओं को तालिकाओं में विभाजित करें - सूचना वस्तुओं को प्रमुख संस्थाओं या विषयों में विभाजित करें, जैसे उत्पाद या आदेश। प्रत्येक विषय तब तालिका बन जाता है।
- सूचना विषय को कॉलम में बदलें - तय करें कि प्रत्येक तालिका में कौन सी जानकारी संग्रहीत करने की आवश्यकता है। प्रत्येक विषय क्षेत्र बन जाता है, और तालिका में कॉलम के रूप में प्रदर्शित होता है। उदाहरण के लिए, कर्मचारी तालिका में अंतिम नाम और किराया दिनांक जैसे क्षेत्र सम्मिलित हो सकते हैं।
- प्राथमिक कुंजी निर्दिष्ट करें - प्रत्येक तालिका की प्राथमिक कुंजी चुनें। प्राथमिक कुंजी स्तंभ, या स्तंभों का समूह है, जिसका उपयोग प्रत्येक पंक्ति को विशिष्ट रूप से पहचानने के लिए किया जाता है। उदाहरण उत्पाद आईडी या ऑर्डर आईडी हो सकता है।
- तालिका संबंध स्थापित करें - प्रत्येक तालिका को देखें और तय करें कि तालिका का डेटा अन्य तालिकाओं के डेटा से कैसे संबंधित है। आवश्यकतानुसार, संबंधों को स्पष्ट करने के लिए तालिकाओं में क्षेत्र जोड़ें या नई तालिकाएँ बनाएँ।
- डिज़ाइन को परिष्कृत करें - त्रुटियों के लिए डिज़ाइन का विश्लेषण करें। तालिकाएँ बनाएँ और मानक डेटा के कुछ रिकॉर्ड जोड़ें। जाँचें कि क्या परिणाम तालिकाओं से अपेक्षित रूप से आते हैं। आवश्यकतानुसार डिज़ाइन में समायोजन करें।
- डेटाबेस सामान्यीकरण प्रायुक्त करें - यह देखने के लिए कि क्या तालिकाओं को सही रूप से संरचित किया गया है, डेटा सामान्यीकरण नियम प्रायुक्त करें। आवश्यकतानुसार तालिकाओं में समायोजन करें।[4]
सामान्यीकरण
संबंध का डेटाबेस डिज़ाइन के क्षेत्र में, सामान्यीकरण यह सुनिश्चित करने का व्यवस्थित विधि है कि डेटाबेस संरचना सामान्य-उद्देश्य क्वेरी के लिए उपयुक्त है और कुछ अवांछनीय विशेषताओं से मुक्त है - सम्मिलन, अद्यतन और विलोपन विसंगतियाँ जो डेटा अखंडता की हानि का कारण बन सकती हैं।
डेटाबेस डिज़ाइन मार्गदर्शन का मानक भाग यह है कि डिज़ाइनर को पूरी तरह से सामान्यीकृत डिज़ाइन बनाना चाहिए; चयनात्मक असामान्यकरण बाद में किया जा सकता है, किन्तु केवल कंप्यूटर प्रदर्शन कारणों से। व्यापार-बंद भंडारण स्थान बनाम प्रदर्शन है। डिज़ाइन जितना अधिक सामान्यीकृत होता है, उतना ही कम डेटा अतिरेक होता है (और इसलिए, यह स्टोर करने के लिए कम स्थान लेता है), चूँकि, सामान्य डेटा पुनर्प्राप्ति पैटर्न को अब जटिल जुड़ने, मर्ज करने और सॉर्ट करने की आवश्यकता हो सकती है - जो अधिक डेटा लेता है पढ़ें, और चक्रों की गणना करें। कुछ मॉडलिंग विषयों, जैसे डेटा वेयरहाउस डिज़ाइन के लिए आयामी मॉडलिंग दृष्टिकोण, स्पष्ट रूप से गैर-सामान्यीकृत डिज़ाइनों की अनुशंसा करते हैं, अर्थात् डिज़ाइन जो बड़े हिस्से में 3एनएफ का पालन नहीं करते हैं। सामान्यीकरण में सामान्य रूप होते हैं जो 1एनएफ, 2एनएफ, 3एनएफ, बोयस-कॉड एनएफ (3.5एनएफ), 4एनएफ और 5एनएफ हैं
दस्तावेज़ डेटाबेस अलग दृष्टिकोण लेते हैं। दस्तावेज़ जो ऐसे डेटाबेस में संग्रहीत होता है, सामान्यतः से अधिक सामान्यीकृत डेटा इकाई और अधिकांश इकाइयों के बीच संबंध भी होते हैं। यदि सभी डेटा इकाइयां और संबंध अधिकांश साथ पुनर्प्राप्त किए जाते हैं, तो यह दृष्टिकोण पुनर्प्राप्ति की संख्या को अनुकूलित करता है। यह यह भी सरल करता है कि डेटा को कैसे दोहराया जाता है, क्योंकि अब डेटा की स्पष्ट रूप से पहचान योग्य इकाई है जिसकी स्थिरता स्व-निहित है। अन्य विचार यह है कि ऐसे डेटाबेस में ही दस्तावेज़ को पढ़ने और लिखने के लिए ही लेन-देन की आवश्यकता होगी - जो कि माइक्रोसर्विसेज आर्किटेक्चर में महत्वपूर्ण विचार हो सकता है। ऐसी स्थितियों में, अधिकांश, दस्तावेज़ के कुछ हिस्सों को एपीआई के माध्यम से अन्य सेवाओं से पुनर्प्राप्त किया जाता है और दक्षता कारणों से स्थानीय रूप से संग्रहीत किया जाता है। यदि डेटा इकाइयों को सेवाओं में विभाजित किया जाना था, तो सेवा उपभोक्ता का समर्थन करने के लिए पढ़ने (या लिखने) के लिए से अधिक सेवा कॉल की आवश्यकता हो सकती है, और इसके परिणामस्वरूप कई लेनदेन का प्रबंधन हो सकता है, जिसे प्राथमिकता नहीं दी जा सकती है।
वैचारिक स्कीमा
भौतिक डिजाइन
डेटाबेस का भौतिक डिज़ाइन भण्डारण मीडिया पर डेटाबेस के भौतिक विन्यास को निर्दिष्ट करता है। इसमें डेटा तत्वों, डेटा प्रकार, सूचकांक (डेटाबेस) विकल्प और डीबीएमएस डेटा शब्दकोश में रहने वाले अन्य पैरामीटर के विस्तृत विनिर्देश सम्मिलित हैं। यह प्रणाली का विस्तृत डिज़ाइन है जिसमें मॉड्यूल और डेटाबेस के हार्डवेयर और प्रणाली के सॉफ़्टवेयर विनिर्देश सम्मिलित हैं। कुछ स्थिति जिन्हें भौतिक स्तर पर संबोधित किया गया है:
- सुरक्षा - एंड-यूज़र, साथ ही प्रशासनिक सुरक्षा।
- प्रतिकृति - डेटा के कौन से टुकड़े दूसरे डेटाबेस में और कितनी बार कॉपी किए जाते हैं। क्या कई-स्वामी या एक ही हैं?
- उच्च-उपलब्धता - चाहे विन्यास सक्रिय-निष्क्रिय हो, या सक्रिय-सक्रिय, टोपोलॉजी, समन्वय योजना, विश्वसनीयता लक्ष्य, आदि सभी को परिभाषित करना होगा।
- विभाजन - यदि डेटाबेस वितरित किया जाता है, तो इकाई के लिए, डेटाबेस के सभी विभाजनों के बीच डेटा कैसे वितरित किया जाता है, और विभाजन विफलता को कैसे ध्यान में रखा जाता है।
- बैकअप और योजनाओं को पुनर्स्थापित करें।
अनुप्रयोग स्तर पर, भौतिक डिज़ाइन के अन्य स्थितियों में संग्रहीत प्रक्रियाओं को परिभाषित करने की आवश्यकता, या भौतिक क्वेरी दृश्य, ऑनलाइन_विश्लेषणात्मक_स्वरूप क्यूब्स आदि सम्मिलित हो सकते हैं।
यह भी देखें
- डेटाबेस सामान्यीकरण
- संबंध का डेटाबेस
- रिलेशनल मॉडल
- पीओओडी (ओर्थोगोनल डिज़ाइन का सिद्धांत)
- कॉन्सेप्ट मैपिंग
- मॉडलिंग की दिनांक
- एंटिटी-रिलेशनशिप मॉडल
- एंटिटी-एट्रिब्यूट-वैल्यू मॉडल
- ऑब्जेक्ट-रिलेशनशिप मॉडलिंग
- ऑब्जेक्ट-रोल मॉडलिंग
- ज्ञान निरूपण
- तार्किक डेटा मॉडल
- मन में नक्शे बनाना
- भौतिक डेटा मॉडल
- सेमांटिक वेब
- तीन स्कीमा दृष्टिकोण
संदर्भ
- ↑ 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. 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
बाहरी संबंध
- [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 | |
