एक-से-कई और कई-से-एक रिश्ते के बीच अंतर

117

एक-से-कई और कई-से-एक रिश्ते के बीच वास्तविक अंतर क्या है? यह केवल उलटा है, किस तरह का?

मुझे इस विषय के अलावा इस विषय के बारे में कोई 'अच्छा और आसान समझने वाला' ट्यूटोरियल नहीं मिल सकता है: शुरुआती के लिए SQL: भाग 3 - डेटाबेस संबंध

sql  relational-database  relational-algebra 
— Zhaf
स्रोत
1
यह सही स्पष्टीकरण है: en.wikipedia.org/wiki/Many-to-many_(data_model)
— रॉबर्ट 29
@RobertPitt प्रश्न के लिए कई-से-कई लेख कैसे प्रासंगिक है? आप शायद इसका मतलब en.wikipedia.org/wiki/One-to-many_(data_model)
— TMG

जवाबों:

111

हाँ, यह इसके विपरीत है। यह निर्भर करता है कि इकाई किस संबंध में मौजूद है।

उदाहरण के लिए, यदि एक विभाग कई कर्मचारियों के लिए नियोजित कर सकता है, तो कर्मचारी से विभाग कई संबंधों के लिए एक है (1 विभाग कई कर्मचारियों को नियुक्त करता है), जबकि कर्मचारी से विभाग का संबंध एक से कई है (कई कर्मचारी एक विभाग में काम करते हैं)।

संबंधों के प्रकार के बारे में अधिक जानकारी :

डेटाबेस संबंध - आईबीएम DB2 प्रलेखन

— देवेंद्र डी। चव्हाण
स्रोत
2
मुझे डर है कि दृश्य नहीं बनेंगे! ( सुनिश्चित नहीं हैं कि लेकिन ) मैं आदेश निर्भरता का प्रतिनिधित्व करता है लगता है! है ना ?? ईजी, ए यूजर टू रोल 1 से कई हो सकते हैं, लेकिन कई एक से नहीं क्योंकि किसी को उस भूमिका का उपयोग करने वाले उपयोगकर्ता का संदर्भ नहीं मिल सकता है! क्या इसका कोई मतलब है?
— अमानुएल नेगा
— 1
29

इस पृष्ठ से डेटाबेस शब्दावली के बारे में

तालिकाओं के बीच अधिकांश संबंध एक-से-कई हैं।

उदाहरण:

  • एक क्षेत्र कई पाठकों का निवास स्थान हो सकता है।
  • एक पाठक की कई सदस्यताएँ हो सकती हैं।
  • एक समाचार पत्र में कई सदस्यता हो सकती हैं।

ए टू वन रिलेशन एक-से-कई के समान है, लेकिन एक अलग दृष्टिकोण से।

  • एक क्षेत्र में कई पाठक रहते हैं।
  • कई सदस्यताएँ एक और एक ही पाठक की हो सकती हैं।
  • कई सदस्यताएँ एक और एक ही अखबार के लिए हैं।
— नातान गॉन्ज़लेज़
स्रोत
20

एक-से-कई और कई-से-एक रिश्ते के बीच वास्तविक अंतर क्या है?

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

एक में एक-से-कई संबंध, स्थानीय तालिका एक पंक्ति है कि एक और तालिका में कई पंक्तियों के साथ जुड़ा हो सकता है। शुरुआती लोगों के लिए एसक्यूएल से उदाहरण में , एक Customerकई Orderएस से जुड़ा हो सकता है ।

विपरीत कई-से-एक संबंध में, स्थानीय तालिका में कई पंक्तियाँ हो सकती हैं जो किसी अन्य तालिका में एक पंक्ति से संबद्ध हैं। हमारे उदाहरण में, कई Orderएस एक से जुड़े हो सकते हैं Customer। यह वैचारिक अंतर मानसिक प्रतिनिधित्व के लिए महत्वपूर्ण है।

इसके अलावा, संबंध का समर्थन करने वाले स्कीमा को अलग-अलग Customerऔर Orderतालिकाओं में दर्शाया जा सकता है । उदाहरण के लिए, यदि ग्राहक के पास कॉलम idऔर name:

id,name
1,Bill Smith
2,Jim Kenshaw

फिर एक Orderके साथ जुड़े रहने के लिए Customer, कई SQL कार्यान्वयन Orderतालिका में एक कॉलम जोड़ते हैं जो idसंबद्ध Customer(इस स्कीमा में) को संग्रहीत करता है customer_id:

id,date,amount,customer_id
10,20160620,12.34,1
11,20160620,7.58,1
12,20160621,158.01,2

उपरोक्त डेटा पंक्तियों में, यदि हम customer_idid कॉलम को देखते हैं, तो हम देखते हैं कि Bill Smith(customer-id # 1) में उनसे जुड़े 2 आदेश हैं: एक $ 12.34 के लिए और एक $ 7.58 के लिए। Jim Kenshaw(customer-id # 2) में $ 158.01 के लिए केवल 1 ऑर्डर है।

यह जानना महत्वपूर्ण है कि आम तौर पर एक-से-कई संबंध वास्तव में किसी भी स्तंभ को उस तालिका में नहीं जोड़ते हैं जो "एक" है। Customerबिना किसी अतिरिक्त कॉलम जिसके साथ संबंध का वर्णन है Order। वास्तव में Customerहो सकता है यह भी साथ एक एक-से-कई संबंध हैं ShippingAddressऔर SalesCallटेबल और अभी तक कोई अतिरिक्त कॉलम को जोड़ा गया है Customerतालिका।

हालाँकि, कई-से-एक संबंध का वर्णन करने के लिए, अक्सर id"कई" तालिका में एक स्तंभ जोड़ा जाता है जो "एक" तालिका के लिए एक विदेशी-कुंजी है - इस मामले में एक customer_idस्तंभ को जोड़ा जाता है Order। $ 12.34 के लिए # 10 से संबंधित ऑर्डर करने के लिए Bill Smith, हम customer_idकॉलम को Bill Smith's id 1' में असाइन करते हैं ।

हालाँकि, यह भी संभव है कि एक और तालिका हो , जो Customerऔर Orderसंबंधों के बारे में बताए , ताकि तालिका में कोई अतिरिक्त फ़ील्ड जोड़ने की आवश्यकता न हो Order। customer_idफ़ील्ड को Orderतालिका में जोड़ने के बजाय , ऐसी तालिका हो सकती Customer_Orderहै जिसमें दोनों Customerऔर के लिए कुंजियाँ हों Order। 

customer_id,order_id
1,10
1,11
2,12

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

उम्मीद है की यह मदद करेगा।

— धूसर
स्रोत
3
सामान्य मामले को समावेशन निर्भरता कहा जाता है। एक विदेशी कुंजी बाधा समावेशन निर्भरता का सबसे सामान्य प्रकार है, लेकिन सभी समावेश निर्भरता में एक विदेशी कुंजी शामिल नहीं है। सामान्य विशेषता या विशेषताएँ ("संदर्भ") दोनों तालिकाओं में हमेशा मौजूद रहती हैं । "एक" पक्ष पर उन विशेषताओं को एक उम्मीदवार कुंजी कहा जाता है। "कई" पक्ष पर वे एक विदेशी कुंजी हो सकते हैं। "एक-से-कई" या "कई-से-एक" शब्दों को किसी भी समावेशन निर्भरता पर लागू किया जा सकता है, जिसमें आवश्यक रूप से कम से कम एक उम्मीदवार कुंजी शामिल होती है, जो जरूरी है कि कौन सा पक्ष वैकल्पिक हो सकता है।
— nvogel
दिलचस्प @sqlvogel। जावा में से javax.persistence.OneToManyअलग है ManyToOne। क्या आप कह रहे हैं कि वे पर्यायवाची हैं या सिर्फ यह कि यह कार्यान्वयन पर निर्भर करता है? क्या मेरा जवाब गलत है?
— ग्रे
2
सवाल रिलेशनल डेटाबेस और SQL के बारे में है, जावा के बारे में नहीं। शायद आप जावा के बारे में सही हैं।
— nvogel
मैं इसे एक उदाहरण @sqlvogel के रूप में उपयोग कर रहा था। क्या आप कह रहे हैं कि "एक-से-कई" और "कई-से-एक" पर्याय हैं?
— ग्रे
2
मैं यह कह रहा हूं कि वे एक ही रिश्ते का वर्णन करने के दो तरीके हैं, लेकिन विभिन्न दृष्टिकोणों से। उसी तरह से कि "A, B का सबसेट है" का अर्थ "B, A का सुपरसेट है"।
— nvogel
4

इसमें कोई फर्क नही है। यह सिर्फ भाषा और पसंद की बात है कि आप किस तरह से रिश्ते को आगे बढ़ाते हैं।

— nvogel
स्रोत
1
निश्चित रूप से एक अंतर है, दोनों वैचारिक रूप से और साथ ही उत्पन्न स्कीमा। मेरा जवाब देखें: stackoverflow.com/a/37954280/179850
— ग्रे
4
@Gray। नहीं वहाँ नहीं है। आपका उत्तर केवल गलत नहीं है, यह शुरुआती (इस सवाल को पूछने वाले) को भ्रमित करता है।
— प्रदर्शनदिवस
4

आपके पहले प्रश्न का उत्तर है: दोनों समान हैं,

आपके दूसरे प्रश्न का उत्तर है: एक-से-एक -> एक MAN (MAN तालिका) में एक से अधिक पत्नी (WOMEN तालिका) कई-से-एक हो सकती हैं -> एक से अधिक महिलाओं ने एक MAN से विवाह किया है।

अब यदि आप इस संबंध को दो तालिकाओं MAN और WOMEN के साथ जोड़ना चाहते हैं, तो एक MAN तालिका पंक्ति में WOMEN तालिका में पंक्तियों के साथ कई संबंध हो सकते हैं। आशा है कि यह स्पष्ट है।

— दोस्त
स्रोत
3

उदाहरण

एक संबंध के साथ दो तालिकाओं

एसक्यूएल

SQL में, केवल एक प्रकार का संबंध है, इसे एक संदर्भ कहा जाता है। (आपका सामने वाला अंत सहायक या भ्रमित करने वाली चीजें कर सकता है [जैसे कि कुछ उत्तर में], लेकिन यह एक अलग बात है)।

  • एक विदेशी कुंजी एक तालिका में ( referenc ing तालिका)
    संदर्भ
    एक प्राथमिक कुंजी एक और तालिका में ( referenc एड तालिका)

  • SQL के संदर्भ में, बार संदर्भ Foo
    नहीं अन्य तरीके के आसपास

    CREATE TABLE Foo (
    Foo   CHAR(10)  NOT NULL, -- primary key
    Name  CHAR(30)  NOT NULL
    CONSTRAINT PK             -- constraint name
        PRIMARY KEY (Foo)     -- pk
    )  
CREATE TABLE Bar (
    Bar   CHAR(10)  NOT NULL, -- primary key
    Foo   CHAR(10)  NOT NULL, -- foreign key to Foo
    Name  CHAR(30)  NOT NULL
    CONSTRAINT PK                -- constraint name
        PRIMARY KEY (Bar),       -- pk
    CONSTRAINT Foo_HasMany_Bars  -- constraint name
        FOREIGN KEY   (Foo)      -- fk in (this) referencing table
        REFERENCES Foo(Foo)      -- pk in referenced table
    )

  • चूंकि Foo.Fooएक प्राथमिक कुंजी है, यह अद्वितीय है, किसी भी दिए गए मूल्य के लिए केवल एक पंक्ति हैFoo

  • चूंकि Bar.Fooएक संदर्भ है, एक विदेशी कुंजी है, और उस पर कोई अद्वितीय सूचकांक नहीं है, इसलिए किसी भी मूल्य के लिए कई पंक्तियां हो सकती हैंFoo
  • इसलिए संबंध Foo::Barएक-से है
  • अब आप देख सकते हैं (देखो) संबंध दूसरे तरीके से, Bar::Fooकई-से-एक है
    • लेकिन ऐसा न हो कि आपको भ्रमित करें: किसी एक Barपंक्ति के लिए, केवल एक Fooपंक्ति है जिसे वह संदर्भित करता है
  • SQL में, बस इतना ही हमारे पास है। वह सब जरूरी है।

एक से कई और कई से एक रिश्ते में असली अंतर क्या है?

केवल एक ही संबंध है, इसलिए कोई अंतर नहीं है। धारणा (एक "अंत" या दूसरे "अंत" से) या इसे पीछे की ओर पढ़ने से संबंध नहीं बदलता है।

प्रमुखता

कार्डिनलिटी को पहले डेटा मॉडल में घोषित किया जाता है, जिसका अर्थ है तार्किक और भौतिक (इरादा), और फिर कार्यान्वयन में (इरादे का एहसास)।

प्रमुखता


SQL में एक से शून्य से कई कि (ऊपर) सभी आवश्यक है।

वन टू वन-टू रेफरेंसिंग टेबल में आपको लागू करने के लिए
आपको एक लेन-देन की आवश्यकता होती है ।

एक शून्य से एक
आप में की जरूरत है Bar:

CONSTRAINT AK    -- constraint name
    UNIQUE (Foo) -- unique column, which makes it an Alternate Key

एक से एक
आपको रेफ़रिंग टेबल में एक लागू करने के लिए एक लेनदेन की आवश्यकता है ।

बहुत से लोग
भौतिक स्तर पर ऐसी कोई बात नहीं करते हैं (याद रखें, SQL में केवल एक प्रकार का संबंध है)।

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

कई-कई हल किए

— PerformanceDBA
स्रोत
1
@ मर्तिजन पीटर्स। मैं इसे आचार संहिता का पालन करने के लिए संपादित कर सकता हूं। लेकिन आपने (ए) स्पष्टीकरण, और (बी) को वास्तविकता में तथ्यों को हटा दिया है। मैं उनके बारे में क्या करूँ?
— प्रदर्शन
3
बिना किसी की बुद्धि या पेशेवर आचरण के शेख़ी, नाम बुलाना, और आकांक्षाओं का सहारा लेने के बिना उन चीजों को व्यक्त करने का एक अलग तरीका खोजें। तकनीक पर ध्यान दें, उन लोगों पर नहीं जो गलत हो सकते हैं या नहीं।
— मार्टिन पीटर्स
2

एक-से-कई और कई-से-एक गुणन में समान हैं लेकिन पहलू (यानी दिशात्मकता) नहीं।

की मैपिंग संघों इकाई वर्गों और के बीच रिश्ते तालिकाओं के बीच। रिश्तों की दो श्रेणियां हैं:

  1. बहुलता (ईआर शब्द: कार्डिनैलिटी)
    • एक-से-एक रिश्ते : उदाहरण पति और पत्नी
    • एक से कई रिश्ते : उदाहरण माँ और बच्चे
    • कई-कई रिश्ते : उदाहरण छात्र और विषय
  2. दिशात्मकता : मैपिंग पर कोई प्रभाव नहीं पड़ता है, लेकिन इस बात पर फर्क पड़ता है कि हम डेटा का उपयोग कैसे कर सकते हैं।
    • यूनी-दिशात्मक संबंध : एक संबंध क्षेत्र या संपत्ति जो दूसरी इकाई को संदर्भित करता है।
    • द्वि-दिशात्मक संबंध : प्रत्येक इकाई का एक संबंध क्षेत्र या संपत्ति होती है जो दूसरी इकाई को संदर्भित करती है।
— Premraj
स्रोत
एक रिलेशनल डेटाबेस में कोई "दिशात्मकता" नहीं है। प्रत्येक रिश्ते के दो "अंत" होते हैं: संदर्भ (तालिका संदर्भित किया जा रहा है) और संदर्भ (तालिका संदर्भित करना)। SQL / DML किसी भी तालिका को संदर्भित करने की अनुमति देता है, किसी भी तरह से आप चाहते हैं ... एक तरफ ... दूसरी तरफ ... दोनों पक्ष ... कोई पक्ष नहीं।
— प्रदर्शनदिशा
0

कोई व्यावहारिक अंतर नहीं है। बस उस रिश्ते का उपयोग करें जो कि आपकी समस्या को देखते हुए सबसे अधिक समझ में आता है जैसा कि देवेंद्र ने सचित्र किया है।

— टॉम बेल
स्रोत
निश्चित रूप से एक अंतर है, दोनों वैचारिक रूप से और साथ ही उत्पन्न स्कीमा। मेरा जवाब देखें: stackoverflow.com/a/37954280/179850
— ग्रे
3
@Gray। नहीं वहाँ नहीं है। आपका उत्तर केवल गलत नहीं है, यह शुरुआती (इस सवाल को पूछने वाले) को भ्रमित करता है।
— प्रदर्शनदिवस
0
  • --- एक से कई --- एक माता-पिता के दो या दो से अधिक बच्चे हो सकते हैं।

  • --- एक से कई --- उन 3 बच्चों में एक ही माता-पिता हो सकते हैं।

    दोनों समान हैं। यह जरूरत के लिए इस्तेमाल किया जा सकता है। यदि आप एक विशेष माता-पिता के लिए बच्चों को ढूंढना चाहते हैं, तो आप एक-से-कई के साथ जा सकते हैं। वरना, जुड़वा बच्चों के लिए माता-पिता ढूंढना चाहते हैं, तो आप बहुत से लोगों के साथ जा सकते हैं। इसी तरह ....,

— सैमुअल एच
स्रोत
-6

एक से कई माता - पिता वर्ग में बच्चों की संख्या शामिल है, इसलिए यह एक संग्रह मानचित्रण है।

कई-टू-वन में बच्चों की संख्या होती है जिसमें एक माता-पिता होते हैं इसलिए यह एक वस्तु मानचित्रण है

— चन्द्र
स्रोत
यह उत्तर अच्छा है और अतिरिक्त जानकारी नहीं है कि यह समझ में क्यों नहीं आया कि इसे वोट दिया गया था, यूनिडायरेक्शनल संदर्भ में एक से कई और कई एक से यूएक्स के आधार पर समान कोड गुणवत्ता प्रदान नहीं करेंगे: यदि आपको डेटा से संबंधित सेट प्राप्त करने की आवश्यकता है तो कई में से एक समझदार है क्या आपको किसी ऐसे चुनिंदा कथन की आवश्यकता नहीं है जहां कुछ स्थिति ठीक हो क्योंकि सेट मानचित्र में है, हालांकि यदि उपयोगकर्ता को डेटा का सेट प्राप्त करने की आवश्यकता नहीं है और एक अद्वितीय के रूप में प्रत्येक पंक्ति में रुचि रखता है वांछित उदाहरण तो कई एक समझदार विकल्प है
— मोहम्मद हाउससेन तालेब
यह एक अच्छा जवाब हो सकता है, लेकिन वे समान नहीं हैं: कई-टू-वन में माता-पिता वर्ग होते हैं जिनमें एन बच्चों की संख्या होती है, एक-से-कई के पास एक बच्चे के लिए कई माता-पिता होते हैं। एसक्यूएल में यह अंतर नहीं हो सकता है क्योंकि कई-टू-वन रिलेशनशिप ओमनी-दिशात्मक हो सकते हैं लेकिन Django जैसे फ्रेमवर्क में, यह एक प्रमुख मुद्दा है, क्योंकि एक-से-कई रिश्ते और विदेशी कुंजी नहीं है जो कई-से-एक संबंध केवल एक दिशा में स्वाभाविक रूप से काम करता है, यह दूसरे तरीके से उसी तरह से उपयोग नहीं किया जा सकता है।
— iFunction
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.