1.1 परिचय
डेटाबेस डिझाइन करणे हे जावा प्रकल्पाच्या आर्किटेक्चरच्या डिझाइनसारखेच आहे. तुम्ही सर्व डेटा दोन टेबल्समध्ये ठेवू शकता किंवा तुम्ही स्कीमा आणि डझनभर टेबल्समधून एक सुंदर डेटा स्ट्रक्चर तयार करू शकता.
डेटाबेस डिझाइन करताना विकासकाला सहसा सामोरे जावे लागते ती कार्ये येथे आहेत:
- सर्व आवश्यक माहिती डेटाबेसमध्ये संग्रहित असल्याची खात्री करणे.
- सर्व आवश्यक विनंत्यांवर डेटा मिळविण्याची शक्यता सुनिश्चित करणे.
- डेटाची रिडंडंसी आणि डुप्लिकेशन कमी करणे.
- डेटाबेस अखंडता सुनिश्चित करणे
- डेटा ऍक्सेस स्पीड ऑप्टिमायझेशन
लक्षात ठेवण्याची मुख्य गोष्ट अशी आहे की आपण एक आदर्श डेटाबेस संरचना बनवू शकत नाही, कारण. ते, तुमच्या कोडप्रमाणे, सतत बदलत जाईल. तुमची डेटाबेस रचना तयार करताना तुम्ही तीन गोष्टी लक्षात ठेवल्या पाहिजेत:
- रचना पुरेशी चांगली असणे आवश्यक आहे.
- इतर लोकांना समजेल अशा प्रत्येक गोष्टीत तर्क असायला हवा.
- अकाली ऑप्टिमायझेशन हे सर्व वाईटाचे मूळ आहे.
तुम्हाला जगातील सर्वोत्तम डेटाबेस स्ट्रक्चर बनवण्याची गरज नाही . ती अजूनही बदलेल. तुमचे कार्य हे सुनिश्चित करणे आहे की तुमच्या डेटाबेसच्या संरचनेत 20 बदल केल्यानंतर, ते शोधणे पुरेसे सोपे आहे.
बहुधा तुमच्या कामाच्या पहिल्या वर्षांत, सुरवातीपासून बेस डिझाइन करण्यासाठी कोणीही तुमच्यावर विश्वास ठेवणार नाही. तुम्ही विद्यमान स्कीमामध्ये बदल कराल. ते कोणत्या तत्त्वांच्या आधारे मांडले आहे हे समजून घेण्याचा आणि त्यांचे पालन करण्याचा प्रयत्न करणे आवश्यक आहे . त्यांच्या सनदीसह, ते दुसऱ्याच्या मठात चढत नाहीत.
डेटाबेस आवश्यक होईपर्यंत ऑप्टिमाइझ करू नका. जर टेबलमध्ये फक्त दोनशे पंक्ती असतील, तर बहुधा डीबीएमएस ते मेमरीमध्ये ठेवेल आणि त्यावर प्रश्न कॅशे करेल.
दुसरीकडे, तुम्ही महत्त्वाच्या विनंत्यांच्या कामाची गती दहापट किंवा शेकडो वेळा वाढवू शकता. आणि हे कसे करायचे हे आपल्याला माहित असल्यास ते छान होईल. ते हायस्कूलमध्ये पहिल्या वर्षी कसे म्हणतात? "शाळेत शिकवलेलं सगळं विसरा..."
डेटाबेस सामान्यीकरण म्हणजे काय हे तुम्हाला माहिती असल्यास, मी तुम्हाला संतुष्ट करण्यासाठी घाई करतो, तुमच्या कामात तुम्ही बहुधा डी-नॉर्मलायझेशनला सामोरे जाल . डेटाबेसच्या गतीपेक्षा प्रकल्पाच्या अभयारण्यांसाठी काहीही महत्त्वाचे नाही. आणि जर, डेटाबेसमधून डेटाच्या निवडीची गती वाढवण्यासाठी, तुम्हाला 200 (!) टेबल्स एका (राक्षसी रिडंडंसीसह) एकत्र करणे आवश्यक आहे, तुम्हाला हे करावे लागेल.
1.2 लायब्ररी डिझाइन
चला विषय क्षेत्रामध्ये थोडं डुबकी मारूया आणि सामान्य पुस्तक लायब्ररीसारखे काहीतरी वापरून डेटाबेस डिझाइनबद्दल विचार करूया.
कोणत्याही ग्रंथालयाचे मुख्य कार्य म्हणजे पुस्तक निधीची प्रक्रिया करणे. सिस्टम वापरकर्त्यांचे तीन मुख्य गट वेगळे करणे सोपे आहे: वाचक, ग्रंथपाल, प्रशासक . प्रत्येकाची क्रिया वापर केस आकृतीमध्ये दर्शविली आहे.
आधीच आता, भविष्यातील डेटाबेसमधील काही संस्था आणि संबंध ओळखले जाऊ शकतात:
या दृष्टीकोनातून, वाचकाला पुस्तकाशी कसे जोडायचे हे स्पष्ट नाही (वाचकाला “जारी/स्वागत” नातेसंबंधात काही फरक पडत नाही. जर पुस्तकाच्या अनेक प्रती असतील, तर त्या अनेक वाचकांना दिल्या जाऊ शकतात. अगदी जर एखादे पुस्तक एक प्रत समजले असेल, तर वर्तमान वाचकांच्या पुस्तकांच्या तक्त्यामध्ये जतन केल्यावर, हे पुस्तक कोणी (आणि किती वेळा) घेतले याबद्दल माहिती मिळवणे अशक्य होईल.
अतिरिक्त घटकाचा परिचय हा उपाय असू शकतो - पुस्तक जारी करण्यासाठी कार्ड. जेव्हा पुस्तक वाचकाला दिले जाते, तेव्हा एक कार्ड तयार केले जाते आणि जेव्हा पुस्तक सुपूर्द केले जाते तेव्हा त्यावर एक चिन्ह लावले जाते. या कार्डांच्या मदतीने, प्रत्येक वापरकर्त्याची कर्जे निश्चित केली जातात आणि पुस्तकांच्या वापराची आकडेवारी काढली जाते. वाचकांकडून साहित्य बुक करताना, एक कार्ड देखील सुरू केले जाते; बुक केलेले साहित्य वाचकाने ठराविक कालावधीत न घेतल्यास, कार्ड नष्ट केले जाते. वाचक किती पुस्तके बुक करू शकतो यावर मर्यादा आहे.
साहित्य निवडताना, वापरकर्ता लेखक, शीर्षक, प्रकाशनाचे वर्ष यानुसार शोध परिणाम फिल्टर करण्याच्या क्षमतेसह साहित्य कॅटलॉग पाहतो.
ग्रंथालयातील सर्व पुस्तकांची आकडेवारी मोजणे शक्य आहे, तर दिलेल्या कालावधीसाठी पुस्तकाच्या जारी केलेल्या प्रतींची संख्या. तुम्ही पुस्तक उदाहरणांची किमान संख्या देखील सेट करू शकता ज्यासाठी गणना केली जाते. या आकडेवारीच्या आधारे, वाचनालयातून न वापरलेली पुस्तके लिहिली जातात.
विषय क्षेत्रातील खालील मुख्य घटक ओळखले जाऊ शकतात:
- वापरकर्ता (ग्रंथपाल आणि प्रशासक);
- वाचक
- वाचन कक्ष;
- पुस्तक;
- पुस्तक जारी करण्याचे कार्ड;
- बुक बुकिंग कार्ड.
डेटाबेसचा सुधारित ईआर-आकृती आकृतीमध्ये दर्शविला आहे.
आकृती 1 मध्ये दर्शविलेल्या वापर प्रकरणांनुसार, डेटाबेसने खालील क्वेरी लागू केल्या पाहिजेत (संपूर्ण यादी नाही):
- निर्दिष्ट अटींशी जुळणारी पुस्तके प्रदर्शित करा;
- वेळेवर बंद न झालेली पुस्तके जारी करण्यासाठी कार्ड असलेले वापरकर्ते प्रदर्शित करा (ग्रंथपाल कर्जदार शोधत आहे);
- दिलेल्या वापरकर्त्याच्या बुक लेंडिंग कार्ड्सशी संबंधित असलेली सर्व पुस्तके प्रदर्शित करा जी वेळेत बंद झाली नाहीत (वापरकर्ता नवीन पुस्तकांसाठी लायब्ररीत आला - तो कर्जदार आहे की नाही हे पाहणे आणि त्याबद्दल त्याला माहिती देणे आवश्यक आहे);
- N सेकंदांपूर्वी तयार केलेली सर्व बुकिंग कार्ड हटवा;
- निर्दिष्ट वापरकर्त्याच्या बंद न केलेल्या पुस्तक आरक्षण कार्डाशी संबंधित सर्व पुस्तके प्रदर्शित करा (वाचकाने पुस्तकांची मागणी केली आणि त्यांच्यासाठी लायब्ररीत आले - ग्रंथपालाने ती देण्यासाठी ही यादी मिळवणे आवश्यक आहे).
1.3 स्कीमा निर्मिती
डेटा स्कीमा तयार करण्यासाठी, तुम्ही प्रथम ER आकृतीला घटकांच्या तपशीलांसह पूरक केले पाहिजे (ते परिष्कृत करा). काहीवेळा, त्याच वेळी, ईआर आकृती तयार करताना त्रुटी शोधणे शक्य आहे - या कार्यात, असे आढळले की पुस्तक "कसे तरी" लायब्ररी हॉलशी जोडलेले असणे आवश्यक आहे.
हे पुस्तकात आवश्यक "हॉल नंबर" ठेवून केले जाऊ शकते, तथापि, या दृष्टिकोनासह, त्याच पुस्तकाचे डेटाबेसमध्ये अनेक वेळा वर्णन करावे लागेल (जर ते वेगवेगळ्या हॉलमध्ये असेल तर). एक अधिक योग्य दृष्टीकोन म्हणजे अतिरिक्त घटक "बुक प्लेसमेंट" सादर करणे. आकृती जोडलेली संस्था आणि प्रॉप्ससह ER आकृती दर्शवते.
वरील ER आकृती मुख्य सारण्या, नातेसंबंध आणि गुणधर्म दर्शवते; त्याच्या आधारावर, आपण डेटाबेस मॉडेल तयार करू शकता. ER आकृतीसाठी कोणतेही मानक नाही, परंतु तेथे अनेक नोटेशन्स आहेत (चेन, IDEFIX, मार्टिन इ.), परंतु डोमेन मॉडेलसाठी मानक किंवा नोटेशन्स सापडले नाहीत. तथापि, असा आराखडा तयार करताना, मुख्य फील्ड (बाह्य आणि अंतर्गत) आवश्यकपणे हायलाइट केले जातात, कधीकधी अनुक्रमणिका आणि डेटा प्रकार.
या प्रकरणात, खालील चित्रात:
- लिंक्ससाठी, मार्टिनचे नोटेशन ("कावळ्याचे पाय" वापरले जाते);
- सारण्या 3 विभागांमध्ये विभागलेल्या आयतांप्रमाणे दर्शविल्या जातात:
- टेबल नाव;
- अंतर्गत की (मार्करसह चिन्हांकित);
- उर्वरित फील्ड, तर अनिवार्य फील्ड मार्करने चिन्हांकित आहेत.
हे मॉडेल विकसित करताना, लायब्ररीयन टेबलसह प्रशासक टेबलमध्ये सामील होण्याची इच्छा होती - वापरकर्ते टेबल जोडा, तथापि:
- प्रशासक विशिष्ट खोलीशी संबंधित नाही (तुम्हाला शून्य मूल्यांसह संबंधित फील्ड भरावे लागेल);
- हे कदाचित प्रवेश अधिकारांचे वितरण गुंतागुंतीचे करेल - आता फक्त डेटाबेस प्रशासक (जो विशेष DBMS पॅनेलद्वारे कार्य करतो आणि विकसित होत असलेल्या सिस्टममध्ये खाते नाही) प्रशासक टेबलवर प्रवेश करू शकतो. तथापि, सारण्यांमध्ये सामील होताना, वापरकर्त्याच्या प्रश्नांना नवीन सारणीमध्ये प्रवेश आवश्यक असेल.
हा आराखडा तयार करताना, ER आकृतीमध्ये एक त्रुटी आढळून आली आणि ती दुरुस्त करण्यात आली - librarians_roomsग्रंथपाल आणि सभागृहांना एकत्र करणारी एक टेबल जोडली गेली. हे आवश्यक आहे कारण एक ग्रंथपाल अनेक खोल्यांमध्ये काम करू शकतो, परंतु अनेक ग्रंथपाल एकाच खोलीत काम करू शकतात.
डेटाबेस डिझाइन करताना, तुम्ही किमान वरील उदाहरणाप्रमाणे तर्क करण्यास सक्षम असावे. जर तुम्हाला वाटत असेल की तुम्ही यशस्वी झालात, तर पुढे जाऊया: आणखी सिद्धांत.