डेटाबेस में एक-से-अनेक संबंध क्या है? उदाहरणों के साथ एक स्पष्टीकरण

एक-से-अनेक संबंध सबसे सामान्य डेटाबेस संबंधों में से एक हैं। यदि आप सीखना चाहते हैं कि कब और कैसे एक-से-अनेक संबंधों का उपयोग करना है, तो यह लेख एक महान प्रारंभिक बिंदु है।

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

रिलेशनल मॉडल का संक्षिप्त परिचय

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

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

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

रिश्ते क्या हैं और हमें उनकी आवश्यकता क्यों है?

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

ऑर्डर डेटा स्टोर करने के लिए इस डिज़ाइन को पूरा करने के लिए हमें क्या करना चाहिए? क्या हमें ग्राहक और उत्पाद जानकारी को आदेश . में जोड़ना चाहिए? टेबल? इसके लिए ग्राहक के नाम, कर पहचानकर्ता, पते आदि के लिए नए कॉलम (विशेषताएं) जोड़ने की आवश्यकता होगी जैसा कि नीचे दिखाया गया है:

अगर हम ऐसा करते हैं, तो हम जल्द ही समस्याओं में पड़ जाएंगे। अधिकांश ग्राहक एक से अधिक ऑर्डर देते हैं, इसलिए यह सिस्टम प्रत्येक ग्राहक के प्रत्येक ऑर्डर के लिए एक बार ग्राहक जानकारी को कई बार संग्रहीत करेगा। यह कोई समझदारी भरा कदम नहीं लगता।

इसके अलावा, जब कोई ग्राहक अपना फ़ोन नंबर बदलता है तो क्या होता है? यदि किसी को ग्राहक को कॉल करने की आवश्यकता होती है, तो वे पिछले ऑर्डर पर पुराना नंबर ढूंढ सकते हैं - जब तक कि कोई व्यक्ति नई जानकारी के साथ मौजूदा ऑर्डर के सैकड़ों (या यहां तक ​​कि हजारों) अपडेट नहीं करता है। और किसी भी अन्य परिवर्तन के लिए भी यही होगा।

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

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

• एक कार निर्माता कई अलग-अलग मॉडल बनाता है, लेकिन एक विशेष कार मॉडल केवल एक कार निर्माता द्वारा बनाया जाता है।
• एक ग्राहक कई खरीदारी कर सकता है, लेकिन प्रत्येक खरीदारी एक ही ग्राहक द्वारा की जाती है।
• एक कंपनी के कई फ़ोन नंबर हो सकते हैं, लेकिन एक फ़ोन नंबर एक कंपनी का होता है।

तालिकाओं के बीच अन्य प्रकार के संबंध भी हैं; यदि आप उनके बारे में अधिक जानना चाहते हैं, तो कई-से-अनेक संबंधों के बारे में यह लेख देखें।

हमारे प्रारंभिक आदेश उदाहरण पर वापस जा रहे हैं, Customer तालिका मूल तालिका होगी और Order बच्चे को टेबल दें; एक ग्राहक के पास कई ऑर्डर हो सकते हैं, जबकि एक ऑर्डर एक ही ग्राहक का हो सकता है।

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

ईआर आरेख में एक से अनेक संबंध दिखाना

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

यह एक अधिक यथार्थवादी डिजाइन है। आप देखेंगे कि आरेख में नई इकाइयां (टेबल) हैं, जिनमें अब टेबल शामिल हैं Customer , Order , Order Detail , और Product . हालांकि, सबसे महत्वपूर्ण बात जो आपने नोटिस की वह यह है कि अब रिश्ते . हैं टेबल के बीच ।

एक डेटाबेस मॉडल में, रिश्तों को दो संस्थाओं को जोड़ने वाली रेखाओं द्वारा दर्शाया जाता है। इन संबंधों की विशेषताओं को विभिन्न कनेक्टर्स द्वारा दर्शाया जाता है:

• जब एक ही लंबवत रेखा होती है, तो उस कनेक्टर के निकटतम निकाय की केवल एक पंक्ति संबंध से प्रभावित होती है। यह एक-से-अनेक में 'एक' है।
• जब एक बहु-पंक्ति कनेक्टर होता है जो क्रो फ़ुट जैसा दिखता है, तो उस कनेक्टर के निकटतम निकाय में संबंध से प्रभावित कई पंक्तियाँ होती हैं; यह 'अनेक' है।

छवि को देखते हुए और संकेतन जानने के लिए, यह समझना आसान है कि आरेख परिभाषित करता है कि प्रत्येक Order कई Order Detail हो सकते हैं और यह कि प्रत्येक Order Detail एक ही Order के अंतर्गत आता है ।

तालिकाओं के बीच एक-से-अनेक संबंध लागू करना

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

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

नोट: संदर्भित कॉलम का नाम संदर्भित (पैरेंट) तालिका के समान रखना एक अच्छा अभ्यास है। इससे रिश्ते को समझना और भी आसान हो जाता है।

2. एक विदेशी कुंजी जोड़ें बच्चे की मेज पर बाधा। यह इंगित करता है कि इस नए कॉलम में संग्रहीत प्रत्येक मान मूल तालिका पर एक पंक्ति को संदर्भित करता है।

विदेशी कुंजी बाधाएं रिलेशनल डेटाबेस पर उपलब्ध एक विशेषता है जो इसे लागू करती है:

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

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

विदेशी कुंजी बनाना

विदेशी कुंजी सिंटैक्स आमतौर पर लक्ष्य डेटाबेस इंजन पर निर्भर करता है। एक बार जब आप अपने तार्किक मॉडल को परिभाषित कर लेते हैं, तो आप अपने (डेटाबेस अज्ञेयवादी) मॉडल को अपने डेटाबेस प्रदाता से मेल खाने वाले भौतिक मॉडल में बदलने के लिए वर्टाबेलो लॉजिकल आरेखों पर "भौतिक मॉडल उत्पन्न करें ..." सुविधा का उपयोग कर सकते हैं। Vertabelo आवश्यक SQL स्क्रिप्ट भी उत्पन्न करेगा जो आपको अपने लक्षित डेटाबेस में तालिकाएँ और संबंध बनाने की अनुमति देगा।

1:N संबंधों के कुछ व्यावहारिक उदाहरण

आइए अब वास्तविक दुनिया के एक-से-अनेक-संबंधों के कुछ उदाहरणों की समीक्षा करें।

प्राथमिक कुंजियों का उपयोग करते हुए एक-से-अनेक संबंध

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

यह उदाहरण एक बुनियादी ऑनलाइन स्ट्रीमिंग सेवा का वर्णन करता है। आइए देखें कि प्रत्येक तालिका में क्या संग्रहीत है और वे हमारे मॉडल में अन्य तालिकाओं से कैसे संबंधित हैं:

1. प्रत्येक ServiceType परिभाषित करता है कि कोई खाता 'व्यवहार' कैसे करता है (उदाहरण के लिए, कितने उपयोगकर्ता एक ही समय में सिस्टम से जुड़ सकते हैं, यदि खाते में पूर्ण HD सक्षम है, आदि)। इसका अन्य संस्थाओं के साथ एक संबंध है:
   • एक-से-अनेक संबंध Account . के साथ , जिसका अर्थ है कि प्रत्येक सेवा प्रकार में उस प्रकार के कई खाते हो सकते हैं।
2. प्रत्येक Account एक ग्राहक के बारे में जानकारी संग्रहीत करता है। अन्य संस्थाओं के साथ इसके दो सीधे संबंध हैं:
   • प्रत्येक खाता एक ही ServiceType से संबंधित है , जैसा कि ऊपर बताया गया है।
   • इस तालिका का Profile . के साथ एक-से-अनेक संबंध है तालिका, जिसका अर्थ है कि एक से अधिक उपयोगकर्ता एक ही खाते का उपयोग करके हमारे सिस्टम से जुड़ सकते हैं।
3. प्रत्येक Profile हमारे सिस्टम में एक उपयोगकर्ता का प्रतिनिधित्व करता है। अन्य संस्थाओं के साथ इसके दो संबंध हैं:
   • प्रत्येक प्रोफ़ाइल एक Account से संबंधित है . यह सभी परिवार के सदस्यों (या शायद दोस्तों के समूह) को एक ही खाता साझा करने की अनुमति देता है, जबकि प्रत्येक की अपनी व्यक्तिगत विशेषताएं होती हैं (उदाहरण के लिए एक प्रोफ़ाइल नाम)।
   • प्रत्येक प्रोफ़ाइल का एक अद्वितीय Avatar होता है ।
4. प्रत्येक Avatar एक छवि है जो हमें प्रत्येक खाता उपयोगकर्ता को शीघ्रता से पहचानने की अनुमति देती है। इसका एक अन्य इकाई के साथ एक संबंध है:
   • Profile के साथ एक-से-अनेक संबंध , जिसका अर्थ है कि अलग-अलग खातों के प्रोफाइल को एक ही अवतार सौंपा जा सकता है।

प्राकृतिक या सरोगेट अद्वितीय कुंजियों के साथ एक-से-अनेक संबंध

सरोगेट प्राथमिक कुंजियों का उपयोग मॉडलिंग तालिकाओं का व्यापक रूप से स्वीकृत तरीका है। (सरोगेट प्राथमिक कुंजी डेटाबेस द्वारा उत्पन्न की जाती हैं और उनका कोई वास्तविक व्यावसायिक मूल्य नहीं होता है।) यह विधि उन कुंजियों का उत्पादन करती है जो उपयोग में आसान होती हैं और जब परिवर्तन की आवश्यकता होती है तो कुछ लचीलापन जोड़ता है।

हालाँकि, ऐसी स्थितियाँ हैं - उदा। जब हमें बाहरी सिस्टम के साथ बातचीत करने की आवश्यकता होती है - जहां हमारे डेटाबेस में उत्पन्न की का उपयोग करना एक खराब तरीका है। उन परिदृश्यों के लिए, आमतौर पर प्राकृतिक कुंजियों का उपयोग करना बेहतर होता है, जो अद्वितीय मान होते हैं जो संग्रहीत किए जा रहे निकाय का हिस्सा होते हैं और हमारे डेटाबेस द्वारा स्वचालित रूप से उत्पन्न नहीं होते हैं।

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

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

SQL सर्वर के लिए इस तार्किक आरेख का भौतिक कार्यान्वयन यहाँ उपलब्ध है:

एक-से-अनेक संबंध एक ही टेबल पर

पिछले उदाहरण दो या दो से अधिक तालिकाओं के बीच संबंधों पर केंद्रित थे, लेकिन ऐसे परिदृश्य भी हैं जहां एक ही तालिका की पंक्तियों के बीच संबंध होता है। इस तरह के एक-से-अनेक संबंध को पदानुक्रमित संबंध भी कहा जाता है; इसका उपयोग कई प्रणालियों में पेड़ जैसी संरचनाओं, यानी एक संगठन चार्ट, एक सामान्य खाता बही, या एक उत्पाद और उसके घटक भागों का प्रतिनिधित्व करने के लिए किया जाता है।

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

इस दृष्टिकोण में कई समस्याएं हैं:

• सभी तालिकाएं लगभग समान हैं और समान जानकारी संग्रहीत करती हैं।
• यदि आपका संगठन एक नया स्तर जोड़ता है, तो आपको डेटा मॉडल को संशोधित करना होगा और एक नई तालिका, नई विदेशी कुंजी, आदि जोड़ना होगा।
• यदि किसी कर्मचारी को पदोन्नति मिलती है, तो आपको उन्हें एक तालिका से हटाकर दूसरी तालिका में सम्मिलित करना होगा।

इसलिए, इस तरह की संरचना को मॉडल करने का सबसे अच्छा तरीका एक एकल तालिका का उपयोग करना है जो स्वयं को संदर्भित करती है, जैसा कि इस आरेख में दिखाया गया है:

यहां हम एक ही Employee देखते हैं EmployeeID_Manager . नामक तालिका और एक स्तंभ . वह कॉलम उसी संगठन के किसी अन्य कर्मचारी का संदर्भ देता है जो वर्तमान कर्मचारी का पर्यवेक्षक/प्रबंधक है।

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

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

आगे क्या है?

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

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