संबंधपरक डेटाबेस डिज़ाइन गाइड (15 का 7–9) [अनुवाद]

जारी रखा जाए।
पिछले भाग: 1-3 , 4-6

7. एक से कई संचार।

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

एक से कई रिश्तों का एक और उदाहरण एक माँ और उसके बच्चों के बीच का रिश्ता है। एक माँ के कई बच्चे हो सकते हैं, लेकिन प्रत्येक बच्चे की केवल एक माँ हो सकती है।

(तकनीकी रूप से, एक माँ और उसके बच्चों के बजाय एक महिला और उसके बच्चों के बारे में बात करना बेहतर है क्योंकि, एक-से-कई संबंधों के संदर्भ में, एक माँ के 0, 1 या कई वंशज हो सकते हैं, लेकिन 0 बच्चों वाली माँ को माँ नहीं माना जा सकता है। उस पर आँखें, ठीक है? '

जब तालिका ए में एक एकल रिकॉर्ड 0, 1 या टेबल बी के कई रिकॉर्ड से जुड़ा हो सकता है, तो आप एक-से-कई संबंधों के साथ काम कर रहे हैं। संबंधपरक डेटा मॉडल में, एक-से-कई संबंध दो तालिकाओं का उपयोग करते हैं।


एक से कई संबंधों का योजनाबद्ध प्रतिनिधित्व। तालिका ए में प्रविष्टि में 0, 1, या तालिका बी में संबद्ध प्रविष्टियों का सेट है।

एक-से-एक रिश्ते को कैसे पहचानें?

यदि आपके पास दो इकाइयाँ हैं, तो खुद से पूछें:
1) कितनी वस्तुएं और बी वस्तु ए से संबंधित हो सकती हैं?
2) A की कितनी वस्तुएं B से किसी वस्तु से संबंधित हो सकती हैं?

यदि पहले प्रश्न का उत्तर कई है , और दूसरा वाला (या शायद नहीं), तो आप एक-से-कई संबंधों के साथ काम कर रहे हैं।

उदाहरण।

एक-से-कई रिश्तों के कुछ उदाहरण:

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

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

8. कई-कई रिश्ते।

कई-से-कई संबंध एक ऐसा संबंध है जिसमें एक तालिका (ए) से कई रिकॉर्ड दूसरे (बी) से कई रिकॉर्ड के अनुरूप हो सकते हैं। इस तरह के कनेक्शन का एक उदाहरण एक स्कूल है जहां शिक्षक छात्रों को पढ़ाते हैं। अधिकांश स्कूलों में, प्रत्येक शिक्षक कई छात्रों को पढ़ाता है, और प्रत्येक छात्र को कई शिक्षकों द्वारा पढ़ाया जा सकता है।

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

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

कई-कई रिश्तों का निर्माण।

तीन-तालिकाओं का उपयोग करके कई-से-कई संबंध बनाए जाते हैं। दो तालिकाएँ - "स्रोत" और एक कनेक्शन तालिका। सम्मिलित तालिका A_B की प्राथमिक कुंजी समग्र है । इसमें दो फ़ील्ड, दो विदेशी कुंजियाँ होती हैं जो टेबल A और B की प्राथमिक कुंजियों को संदर्भित करती हैं।



सभी प्राथमिक कुंजी अद्वितीय होनी चाहिए। इसका यह भी अर्थ है कि फ़ील्ड A और B का संयोजन तालिका A_B में अद्वितीय होना चाहिए।

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

टेबल्स "बीयर के बारे में"।

उपरोक्त टेबल एक कनेक्शन तालिका का उपयोग करके कई-से-कई संबंधों में आपूर्तिकर्ताओं और बीयर को जोड़ते हैं। कृपया ध्यान दें कि Gentse Tripel Beer (157) की आपूर्ति Horeca Import NL (157, AC001) जानसेन होरेका (157, AB899) और पीटरसन ड्रैनकेन्डेल (157, AC009) द्वारा की जाती है। और इसके विपरीत, पीटरसन ड्रैंकेनहैंडल तालिका से 3 प्रकार की बीयर का आपूर्तिकर्ता है, अर्थात्: गेंटसे त्रिपेल (157, एसी 009), उइलेंसेपेल (158, एसी 009) और जुपाइलर (163, एसी 009)।

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

जानने के लिए एक और महत्वपूर्ण बात है। कई-से-कई संबंधों में दो एक-से-कई संबंध होते हैं । दोनों तालिकाएं: बीयर आपूर्तिकर्ता और बीयर - कनेक्शन तालिका के साथ एक-से-कई संबंध हैं।

कई-कई संबंधों का एक और उदाहरण: एक होटल में टिकट बुक करना।

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


कई-से-कई संचार कनेक्शन तालिका में अतिरिक्त फ़ील्ड हैं।

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

आप अक्सर उन परिस्थितियों से सामना करेंगे जहां दो संस्थाओं का संयोजन एक नई इकाई होगी।

9. एक से एक संचार।

एक-से-एक संबंध में, इकाई A के प्रत्येक ब्लॉक को 0 से जोड़ा जा सकता है। इकाई का एक खंड B. एक कर्मचारी, उदाहरण के लिए, आमतौर पर एक कार्यालय से जुड़ा होता है। या बीयर ब्रांड के मूल में केवल एक देश हो सकता है।

एक टेबल में।

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

अलग-अलग टेबल में।

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

एक-से-एक संचार उदाहरण।

• लोग और उनके पासपोर्ट। देश के प्रत्येक व्यक्ति के पास केवल एक वैध पासपोर्ट है और प्रत्येक पासपोर्ट केवल एक व्यक्ति का है।

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

आपको किस तरह के कनेक्शन की आवश्यकता है?

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

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

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

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