इकाई संबंध चित्र के डिजाइन सीखना

नमस्ते यह लेख सबसे लोकप्रिय, साथ ही साथ कई परिचित, डिजाइन मॉडल - ईआर ( एंटिटी रिलेशनशिप ) के लिए समर्पित है, जिसे 1976 में कंप्यूटर विज्ञान - पीटर चेन के क्षेत्र में वैज्ञानिकों द्वारा प्रस्तावित किया गया था।


लेख के पाठ्यक्रम में, सरल भाषा में, जीवन से सरल उदाहरणों का उपयोग करते हुए, हम आरेख के विभिन्न संस्करणों को विकसित करेंगे जो उनके प्रकार के कनेक्शन पर निर्भर करेगा। चलो शुरू हो जाओ!

ऑब्जेक्ट ओरिएंटेड डिज़ाइन

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

जल्दी शुरू करो

इकाई संबंध डिजाइन मॉडल का मुख्य प्लस यह सार्वभौमिक है। आप एक डेटाबेस (डेटाबेस), एक कार्यक्रम के संचालन, बातचीत के सिद्धांतों आदि को डिजाइन कर सकते हैं।

अध्ययन की शुरुआत में आपको क्या जानना चाहिए?

- आपको शुरुआत में यह जानना होगा कि मुख्य काम सार और संचार के संबंधों पर किया जाता है। आसान धारणा के लिए, यह याद रखने योग्य है कि सार एक संज्ञा है जो एक आयत में है, और कनेक्शन एक क्रिया है जो एक रोम्बस में है। यहाँ एक उदाहरण है:



मुझे लगता है कि आप समझते हैं कि क्या है। हमारा प्रोग्रामर पायथन सिखाता है। ऐसा लगता है कि सब कुछ तार्किक है। लेकिन यहाँ, बस, उदाहरण में ये इकाइयाँ क्या हैं?

- यह कनेक्शन के प्रकार का एक संकेतक है! इस उदाहरण में, कनेक्शन प्रकार एक-से-एक है:

$$

$$1: 1$$

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



पुनश्च मुझे आशा है कि आप रुचि रखते हैं। आप आरेख संपादक में इस तरह के आरेख बना सकते हैं - दीया।

गुण

इसलिए, हमारे पास एक प्रोग्रामर है, लेकिन हम उसके बारे में कुछ भी नहीं जानते हैं ... जिसके बिना एक प्रोग्रामर प्रोग्रामर नहीं है?
- बिना किसी विशेषता के!

चलो हमारे उदाहरण के पूरक हैं:



हां, विशेषताएँ वास्तव में हमारे प्रोग्रामर को एक सामान्य व्यक्ति से अलग नहीं करती हैं ... लेकिन भविष्य में हम इसे नई विशेषताओं के साथ ठीक करेंगे! मेरे विचार में, डेटाबेस तालिका में विशेषता COLUMN (स्तंभ) है।

विशेषताएँ खाली हैं

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

विशेषताओं की पहचान करना

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

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

संचार के प्रकार

बहुत बढ़िया। हम यह पता लगाने में सक्षम थे। अब शेष प्रकार के संचार पर विचार करें!

आइए कनेक्शन के प्रकार के साथ जारी रखें - एक से कई:

$$

$$1: एन$$

मैं आपको एक उदाहरण दिखाता हूं:



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

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

अंतिम प्रकार का कनेक्शन बना हुआ है - बहुत से:

$$

$$एम: एन$$

हमेशा की तरह, मैं आपको उदाहरण के साथ दिखाऊंगा, लेकिन प्रोग्रामर के साथ नहीं, बल्कि मूवी देखने के लिए किसी भी सेवा पर मूवी के साथ स्पेक्टेटर के रिश्ते के उदाहरण द्वारा:



दो विवादास्पद मुद्दे हैं। शुरुआत करते हैं।

पहली:
- संचार एक इकाई की तरह अधिक क्यों है?

"कई से कई" प्रकार के संबंधों को सरल बनाने के लिए, मध्यवर्ती संस्थाओं का उपयोग किया जाता है ।

"कोई शाखा क्यों नहीं हैं?"

- दर्शक कई फिल्मों की सदस्यता ले सकता है।
- फिल्मों में कई दर्शक हो सकते हैं जो उनकी सदस्यता लेते हैं।

अब, एक से अधिक रिश्तों को लागू करने का एक और तरीका देखें, जिसे लिखना थोड़ा अधिक कठिन होगा, लेकिन शायद उन लोगों के लिए अधिक समझ में आता है जो मध्यवर्ती संस्थाओं के बारे में नहीं जानते हैं:



जैसा कि आपने देखा होगा, इस उदाहरण में एक प्रकार का कनेक्शन है "एक से कई", और यहां तक ​​कि कई।
यह सच है और समझाने में आसान है। तथ्य यह है, "कई से कई" कनेक्शन प्रकार दो "एक से कई" संचार के बराबर है।

$$

$$M: N = 1: N + N: 1$$

आप शायद इस बात में रुचि रखते हैं कि हम, कनेक्शन और इकाई के बीच, दो किनारे क्यों हैं।
यह समझाने के लिए पहले से ही थोड़ा कठिन है। ध्यान से पढ़िए।
तथ्य यह है कि वैकल्पिक और अनिवार्य कनेक्शन हैं । पहचान याद रखें:

वैकल्पिक कनेक्शन आंशिक भागीदारी बनाते हैं, जबकि अनिवार्य पूर्ण भागीदारी बनाते हैं।

- आंशिक और पूर्ण भागीदारी क्या है?

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

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

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

कमजोर संस्थाएँ

अंतिम अवधारणा पर विचार करें।

कल्पना करें कि आपके पास एक तालिका "अभिभावक" और "बाल" है, क्रमशः आरेख में समान इकाइयां हैं। क्या कोई दूसरे के बिना मौजूद हो सकता है? मुझे नहीं लगता। जैविक और सामान्य तार्किक दोनों में।

कमजोर सार: सेब के पेड़ के बिना कोई सेब नहीं हो सकता

।

इस उदाहरण में, इकाई "बाल" एक कमजोर इकाई है।

कमजोर इकाइयाँ वे संस्थाएँ हैं जो किसी अन्य संस्था के बिना मौजूद नहीं हो सकतीं।

हम इकाई "चाइल्ड" बनाते हैं, इस उम्मीद में कि माता-पिता / माता-पिता के पास एक ही नाम के बच्चे नहीं हैं, अन्यथा, हमारी इकाई, जो डेटाबेस में एक तालिका हो सकती है, को शायद ही सामान्यीकृत कहा जा सकता है (एक तालिका जिसमें डेटा ऑटोमेशन के नियम हैं) एक प्राथमिक कुंजी पहचानकर्ता है), क्योंकि हम बच्चों को अलग नहीं कर सकते।

हालांकि, ऐसे मामले होते हैं, लेकिन आप एक अतिरिक्त विशेषता जोड़कर इसे ठीक कर सकते हैं। इस स्थिति में, "नाम" विशेषता वह है जो एक समान स्थिति बनाता है, और इसे एक कमजोर इकाई का प्रमुख घटक कहा जाता है। अंडाकारों में ऐसी विशेषताओं का नाम एक बिंदीदार रेखा के साथ रेखांकित किया गया है, और सार और कनेक्शन को अतिरिक्त आंकड़ों में रखा गया है, जिसमें वे रचे गए हैं।

मैं इसे एक उदाहरण के रूप में आपके सामने प्रस्तुत करूंगा:

निष्कर्ष

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

सूत्रों का कहना है

- पुस्तक "MySQL गाइड" प्रमाणीकरण:
सीड एम.एम. "सैयद" ताहाघोगी, ह्यूग ई। विलियम्स
- en.wikipedia.org/wiki/Entity -relationship_model