'कई से दो' संबंध

यह प्रश्न दिखाता है कि आप इकाई संबंधों को पूरी तरह से नहीं समझते हैं (कोई अशिष्टता का इरादा नहीं है)। जिनमें से चार (तकनीकी रूप से केवल 3) प्रकार नीचे हैं:

One to One
One to Many
Many to One
Many to Many

वन टू वन (1:1): इस मामले में सामान्यीकरण, या अधिक सामान्यतः खुले बंद सिद्धांत के अनुपालन के प्रयोजनों के लिए एक तालिका को दो भागों में विभाजित किया गया है।

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

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

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

ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग में यह सबसे नज़दीकी चीज है जिसे आप विरासत में प्राप्त कर सकते हैं। लेकिन यह बिल्कुल समान नहीं है।

एक से अनेक (1:M) / अनेक से एक (M:1): ये दो रिश्ते (इसलिए 4 क्यों 3 बनते हैं), सबसे लोकप्रिय संबंध प्रकार हैं। वे दोनों एक ही तरह के रिश्ते हैं, केवल एक चीज जो बदलती है वह है आपका नजरिया। एक उदाहरण एक ग्राहक के पास कई फ़ोन नंबर होते हैं, या वैकल्पिक रूप से, कई फ़ोन नंबर एक ग्राहक के हो सकते हैं।

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

अनेक से अनेक (एम:एम): वर्तमान तकनीक के साथ इस प्रकार का संबंध असंभव है। इस कारण से हमें इसे "एसोसिएशन" तालिका में शामिल होने के साथ दो एक से कई रिश्तों में तोड़ने की जरूरत है। दो एक से अनेक संबंधों के अनेक पक्ष हमेशा साहचर्य/लिंक टेबल पर होते हैं।

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

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

आपके उदाहरण में विशेष रूप से ऊपर...

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

इस प्रकार के प्रश्नों के लिए, यह वास्तव में इस बात पर निर्भर करता है कि आप उन्हें कैसे वाक्यांश देते हैं। आपको इसके बारे में भ्रमित करने का कारण क्या है, और समाधान को देखने के लिए आप इस भ्रम को कैसे दूर करते हैं, यह सरल है। समस्या को इस प्रकार दोबारा दोहराएं। पूछकर शुरू करें कि क्या यह एक से एक है, अगर उत्तर नहीं है, तो आगे बढ़ें। अगला सवाल यह है कि यह एक से कई लोगों के लिए है, अगर उत्तर आगे नहीं बढ़ रहा है। शेष एकमात्र अन्य विकल्प अनेक से अनेक है। हालांकि सावधान रहें, सुनिश्चित करें कि आपने आगे बढ़ने से पहले पहले 2 प्रश्नों पर ध्यान से विचार किया है। कई अनुभवहीन डेटाबेस वाले लोग अक्सर एक से कई को कई के रूप में परिभाषित करके मुद्दों को जटिल बनाते हैं। एक बार फिर, अब तक का सबसे लोकप्रिय प्रकार का संबंध एक से कई (मैं 90% कहूंगा) कई के साथ कई और एक से एक शेष 10% 7/3 को क्रमशः विभाजित करता है। लेकिन वे आंकड़े सिर्फ मेरे व्यक्तिगत दृष्टिकोण हैं, इसलिए उन्हें उद्योग मानक आंकड़ों के रूप में उद्धृत न करें। मेरा कहना है कि अतिरिक्त अतिरिक्त सुनिश्चित करना है कि यह निश्चित रूप से कई से कई को चुनने से पहले एक से कई नहीं है। यह अतिरिक्त प्रयास के लायक है।

तो अब दोनों के बीच लिंकर टेबल खोजने के लिए, तय करें कि आपकी कौन सी दो मुख्य टेबल हैं, और उनके बीच किन क्षेत्रों को साझा करने की आवश्यकता है। ऐसे में कंपनी और यूजर टेबल दोनों को फोन शेयर करने की जरूरत होती है। इसलिए आपको लिंकर के रूप में एक नई फोन टेबल बनाने की जरूरत है।

जैसे ही आप तय करते हैं कि 3 में से कोई भी आपके लिए काम नहीं कर रहा है, गलतफहमी का चेतावनी अलार्म दिखाना चाहिए। यह आपको यह बताने के लिए पर्याप्त होना चाहिए कि आप रिश्ते के प्रश्न को सही ढंग से नहीं बता रहे हैं। जैसे-जैसे समय बीतता जाएगा आप इसमें बेहतर होते जाएंगे, लेकिन यह एक आवश्यक कौशल है और वास्तव में इसे जल्द से जल्द अपने विवेक के लिए महारत हासिल करनी चाहिए।

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

आशा है कि यह एक उचित उत्तर था। इसे पढ़ने के लिए समय निकालने के लिए धन्यवाद।