डेटाबेस डिजाइन में बुनियादी कार्य

1.1 परिचय

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

यहां वे कार्य हैं जो एक डेटाबेस को डिजाइन करते समय एक डेवलपर को आमतौर पर सामना करना पड़ता है:

1. यह सुनिश्चित करना कि डेटाबेस में सभी आवश्यक जानकारी संग्रहीत है।
2. सभी आवश्यक अनुरोधों पर डेटा प्राप्त करने की संभावना सुनिश्चित करना।
3. डेटा के अतिरेक और दोहराव को कम करना।
4. डेटाबेस अखंडता सुनिश्चित करना
5. डेटा एक्सेस गति अनुकूलन

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

1. संरचना काफी अच्छी होनी चाहिए।
2. हर चीज में एक लॉजिक होना चाहिए जिसे दूसरे लोग समझ सकें।
3. सभी बुराईयो की जड़ समयपूर्व इष्टतमीकरण है।

आपको दुनिया का सबसे अच्छा डेटाबेस स्ट्रक्चर बनाने की जरूरत नहीं है । वह अब भी बदलेगी। आपका कार्य यह सुनिश्चित करना है कि आपके डेटाबेस की संरचना में 20 परिवर्तनों के बाद, यह पता लगाना काफी आसान है।

सबसे अधिक संभावना है कि आपके काम के पहले वर्षों में, कोई भी आप पर विश्वास नहीं करेगा कि आप खरोंच से आधार तैयार करें। आप किसी मौजूदा स्कीमा में परिवर्तन कर रहे होंगे। आपको यह समझने की कोशिश करने की जरूरत है कि यह किन सिद्धांतों के आधार पर व्यवस्थित है और उनका पालन करता है । अपने चार्टर के साथ, वे किसी और के मठ में नहीं चढ़ते।

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

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

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

1.2 पुस्तकालय डिजाइन

आइए विषय क्षेत्र में थोड़ा गोता लगाएँ और डेटाबेस डिज़ाइन के बारे में सोचें जो एक सामान्य पुस्तक पुस्तकालय के रूप में सरल है।

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

पहले से ही, भविष्य के डेटाबेस की कुछ संस्थाओं और रिश्तों को प्रतिष्ठित किया जा सकता है:

इस दृष्टिकोण के साथ, यह स्पष्ट नहीं है कि पाठक को पुस्तक के साथ कैसे जोड़ा जाए (पाठक के पास "जारी / स्वागत" संबंध में एकता नहीं है। यदि पुस्तक की कई प्रतियां हैं, तो इसे कई पाठकों को जारी किया जा सकता है। यहां तक ​​​​कि इसे जारी किया जा सकता है। यदि किसी पुस्तक को एक प्रति के रूप में समझा जाता है, तो वर्तमान पाठक की पुस्तकों की तालिका में सहेजे जाने पर, यह जानकारी प्राप्त करना असंभव होगा कि इस पुस्तक को पहले किसने (और कितनी बार) लिया था।

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

साहित्य का चयन करते समय, उपयोगकर्ता साहित्य सूची को लेखक, शीर्षक, प्रकाशन के वर्ष द्वारा खोज परिणामों को फ़िल्टर करने की क्षमता के साथ देखता है।

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

विषय क्षेत्र की निम्नलिखित मुख्य संस्थाओं को प्रतिष्ठित किया जा सकता है:

• उपयोगकर्ता (पुस्तकालयाध्यक्ष और प्रशासक);
• पाठक;
• वचनालय;
• किताब;
• पुस्तक जारी करने का कार्ड;
• बुक बुकिंग कार्ड।

डेटाबेस का संशोधित ईआर-आरेख चित्र में दिखाया गया है।

चित्र 1 में दिखाए गए उपयोग के मामलों के अनुसार, डेटाबेस को निम्नलिखित प्रश्नों को लागू करना चाहिए (विस्तृत सूची नहीं):

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

1.3 स्कीमा गठन

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

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

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

इस मामले में, निम्नलिखित आरेख में:

• लिंक के लिए, मार्टिन का संकेतन ("कौवा के पैर" का उपयोग किया जाता है);
• तालिकाओं को 3 खंडों में विभाजित आयतों के रूप में दिखाया गया है:
• तालिका नाम;
• आंतरिक कुंजी (एक मार्कर के साथ चिह्नित);
• शेष फ़ील्ड, जबकि अनिवार्य वाले एक मार्कर के साथ चिह्नित हैं।

इस मॉडल को विकसित करते समय, लाइब्रेरियन तालिका के साथ व्यवस्थापक तालिका में शामिल होने की इच्छा थी - उपयोगकर्ता तालिका जोड़ें, हालाँकि:

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

इस आरेख का निर्माण करते समय, ईआर आरेख में एक दोष पाया गया और उसे ठीक किया गया - एक तालिका जोड़ी गई librarians_roomsजो लाइब्रेरियन और हॉल को एकजुट करती है। यह आवश्यक है क्योंकि एक लाइब्रेरियन कई कमरों में काम कर सकता है, लेकिन कई लाइब्रेरियन एक ही कमरे में काम कर सकते हैं।

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