डेटाबेस डिजाइन में कदम क्या हैं?

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

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

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

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

इस बात को ध्यान में रखते हुए, आइए डेटाबेस डिज़ाइन के चरणों को देखें।

चरण 1:व्यावसायिक आवश्यकताओं को इकट्ठा करें

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

• क्या व्यवसाय डेटाबेस में वाहन ट्रैकिंग डेटा चाहता है, भले ही कोई सक्रिय यात्रा हो या नहीं? यदि हाँ, तो फ़ील्ड vehicle_trip_id तालिका में vehicle_trips अशक्त होगा . अन्यथा, यह अशक्त नहीं होगा ।
• क्या व्यवसाय trip_status में परिवर्तनों का इतिहास चाहता है डेटाबेस में संग्रहीत? यदि हाँ, तो हर बार trip_status परिवर्तन, trips टेबल। अन्यथा, हर बार trip_status परिवर्तन, trip_status जगह पर अपडेट किया जाएगा।

जैसा कि इस उदाहरण में दिखाया गया है, व्यवसाय से प्राप्त इनपुट के आधार पर, आप अंत में एक विकल्प को दूसरे के ऊपर चुनना चाहेंगे। इसका परिणाम संबंधित संस्थाओं और उनके संबंधों को बदलना होगा।

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

चरण 2:व्यापार रोडमैप को समझें

व्यवसाय हर समय अपनी प्रक्रियाओं को बदलते हैं; अनुकूलन करने की उनकी क्षमता उनके असफल होने की संभावना कम कर देती है। व्यावसायिक प्रक्रियाओं को बदलने का अर्थ है वर्कफ़्लो और डेटा मॉडल बदलना। हालांकि इन परिवर्तनों को समय से पहले जानना संभव नहीं है, लेकिन व्यापार रोडमैप के साथ अद्यतित होना निश्चित रूप से संभव है।

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

मैं एक और उदाहरण साझा करना चाहता हूं, जो लगातार विकसित हो रही व्यावसायिक प्राथमिकताओं के बारे में है। COVID-19 की शुरुआत में टैक्सी व्यवसाय बुरी तरह प्रभावित हुआ था। एक कैब कंपनी के रूप में, आप लोगों को आश्वस्त करने के लिए पहले से कार्रवाई करना चाहते हैं कि आप यह सुनिश्चित करने के लिए सब कुछ कर रहे हैं कि कैब में आपकी यात्रा यथासंभव सुरक्षित है, कि वाहन हर दिन कीटाणुरहित हो, कि ड्राइवर बिल्कुल भी मास्क पहने बार, और कैब में हैंड सैनिटाइज़र उपलब्ध है। अब, यह सारी जानकारी हासिल करने के लिए, दो इकाइयों में परिवर्तन, drivers और vehicles , की आवश्यकता होगी। कई बूलियन फ़्लैग फ़ील्ड इस व्यावसायिक उपयोग के मामले को पूरा करने के लिए इन संस्थाओं में जोड़े जाने की आवश्यकता है।

चरण 3:संस्थाओं और विशेषताओं की पहचान करें

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

इस चरण का उपयोग यह पहचानने के लिए भी किया जाता है कि कौन सी विशेषताएँ संस्थाओं में पहचानकर्ता के रूप में कार्य करेंगी। पहचानकर्ता भौतिक मॉडल में प्राथमिक कुंजी में अनुवाद करते हैं। इसके अलावा, इस चरण में सभी विशेषताओं के लिए डेटा प्रकार निर्दिष्ट करना भी सामान्य है।

उदाहरण के लिए, टैक्सीकैब बुकिंग मॉडल में, आपको उन विशेषताओं की पहचान करनी होगी जो बुकिंग ऐप से उपयोगकर्ताओं और ड्राइवरों के पंजीकरण के लिए अनिवार्य फ़ील्ड के रूप में कार्य करेंगी। उपयोगकर्ता पंजीकरण user_phone . का उपयोग करके किया जाएगा और ड्राइवर का पंजीकरण driver_phone . का उपयोग करके किया जाएगा ।

इसी तरह, इस चरण के दौरान अन्य संस्थाओं और विशेषताओं की पहचान व्यावसायिक प्रक्रिया वर्कफ़्लो में मैप किए जाने के बाद की जाती है।

चरण 4:संबंधों की पहचान करें

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

1. एक-से-एक → ए में एक रिकॉर्ड बी में अधिकतम एक रिकॉर्ड से मेल खाता है।
2. एक-से-अनेक → A में एक रिकॉर्ड B में कई रिकॉर्ड से मेल खाता है।
3. कई-से-एक → A में कई रिकॉर्ड B में अधिकतम एक रिकॉर्ड के अनुरूप होते हैं।
4. कई-से-अनेक → ए में कई रिकॉर्ड बी में कई रिकॉर्ड के अनुरूप हैं।

टैक्सीकैब बुकिंग मॉडल में, केवल एक प्रकार के संबंध का उपयोग किया गया है, अर्थात एक-से-अनेक। users और trips उदहारण के लिए। मॉडल में, एक धारणा है कि केवल एक उपयोगकर्ता एक यात्रा से संबंधित हो सकता है, जिसका अर्थ है कि कोई साझा या एकत्रित कैब नहीं हैं। लेकिन अगर साझा या एकत्रित कैब होती, तो संभवतः users और trips , यदि कई उपयोगकर्ताओं ने समान trip_id shared साझा किया है ।

चरण 5:एक तार्किक ER आरेख बनाएं

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

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

चरण 6:तार्किक ER आरेख की पुष्टि करें

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

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

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

ये सभी जांच वैकल्पिक हैं और यदि कोई अन्य सत्यापन ढांचा मौजूद है, तो उन्हें छोड़े जाने के लिए कॉन्फ़िगर किया जा सकता है। वर्टाबेलो से उचित सत्यापन आपको न्यूनतम संभव घर्षण के साथ अगले चरण पर जाने में मदद करता है।

चरण 7:एक भौतिक ER आरेख बनाएं

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

भौतिक डेटा मॉडल बनाने के लिए, इन चरणों का पालन करें:

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

इन चरणों को किसी भी डेटा मॉडलिंग टूल का उपयोग करके किया जा सकता है जिसका उपयोग आप स्क्रैच से डेटा मॉडल बनाने के लिए कर सकते हैं। हालांकि, वर्टाबेलो के पास सभी प्रमुख डेटाबेस सिस्टम जैसे MySQL, PostgreSQL, Oracle, Microsoft SQL Server, Amazon Redshift, Google BigQuery, और अधिक के लिए एक तार्किक डेटा मॉडल को एक पूर्ण भौतिक डेटा मॉडल में बदलने का विकल्प है। एक बार जब तार्किक डेटा मॉडल को भौतिक डेटा मॉडल में बदल दिया जाता है, तो आप हमारे द्वारा चर्चा किए गए चार चरणों को जारी रख सकते हैं।

वर्टाबेलो के पास मॉडल के बहुत बारीक स्तर पर किसी भी टिप्पणी के साथ तालिका स्तर पर पूर्व और पोस्ट-तैनाती लिपियों को जोड़ने का विकल्प भी है। जब वर्टाबेलो द्वारा पेश की गई दस्तावेज़ीकरण पीढ़ी की सुविधा का उपयोग किया जाता है, तो टिप्पणियाँ आसान हो जाती हैं। डेटाबेस दस्तावेज़ को निम्नलिखित तीन प्रारूपों में से किसी एक में निर्यात किया जा सकता है:HTML, PDF, या DOCX।

कैब बुकिंग उदाहरण के साथ जारी रखते हुए, वर्टाबेलो द्वारा उत्पन्न भौतिक डेटा मॉडल पर एक नज़र डालते हैं।

चरण 8:भौतिक ER आरेख की पुष्टि करें

जैसे तार्किक ईआर आरेख को मान्य किया गया था, वर्टाबेलो के पास कई अतिरिक्त जांचों के साथ भौतिक ईआर आरेखों को मान्य करने के लिए एक उपकरण है, जैसे कि एफके मौजूद हैं या नहीं और क्या तालिका नाम या कॉलम नाम की लंबाई चयनित डेटाबेस के आधार पर सीमा से अधिक है।

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

चरण 9:भौतिक ER आरेख के साथ समस्याओं को ठीक करें

सत्यापन के परिणाम उन मुद्दों की पहचान कर सकते हैं जिन्हें ठीक करने की आवश्यकता है। कुछ सबसे आम समस्याएं हैं:

• ऐसी विदेशी कुंजियां मौजूद नहीं हैं जहां निकाय संबंधों को परिभाषित किया गया है।
• तालिकाओं से प्राथमिक कुंजियां गायब हैं।
• चयनित डेटाबेस के लिए असमर्थित डेटा प्रकार।

एक बार ये और इसी तरह के अन्य मुद्दों का समाधान हो जाने के बाद, मॉडल चयनित डेटाबेस प्रबंधन प्रणाली के लिए एक परिनियोजन योग्य SQL स्क्रिप्ट में निर्यात करने के लिए तैयार है।

चरण 10:मॉडल को परिनियोजित करने के लिए DDL स्क्रिप्ट जेनरेट करें

डेटाबेस डिजाइन केवल ईआर आरेख बनाने के बारे में नहीं है। ईआर आरेखों का उपयोग करते हुए एक डेटा मॉडलिंग अभ्यास तभी सफल होता है जब इसके परिणामस्वरूप कुछ परिनियोजन योग्य हो। वर्टाबेलो के पास भौतिक मॉडल को तैयार-से-तैनाती SQL स्क्रिप्ट में निर्यात करने का एक सुविधाजनक विकल्प है। एक बार जब यह जनरेट हो जाता है, तो किसी भी लंबित मुद्दे को सीधे SQL स्क्रिप्ट में हल किया जा सकता है।

हालांकि, जेनरेट की गई SQL स्क्रिप्ट को बदलने की अनुशंसा नहीं की जाती है। यह एक बहाव . का कारण बनता है भौतिक डेटा मॉडल और डेटाबेस पर तैनात SQL स्क्रिप्ट के बीच, जिसका अर्थ वास्तविक तालिकाओं और डेटाबेस दस्तावेज़ीकरण के बीच एक बहाव भी हो सकता है।

अब जब हम डेटाबेस डिज़ाइन प्रक्रिया के अंत तक पहुँच चुके हैं, तो आइए वर्टाबेलो द्वारा उत्पन्न SQL कोड पर एक नज़र डालते हैं।

अपने विचार साझा करें

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

हमें यह देखकर खुशी होगी कि डेटाबेस डिजाइन करने में आपके अनुभव क्या रहे हैं। हमें [email protected] पर लिखें।