पहचान और गैर-पहचान वाले रिश्तों के बीच अंतर क्या है?


800

मैं मतभेदों को पूरी तरह से समझ नहीं पाया हूं। क्या आप दोनों अवधारणाओं का वर्णन कर सकते हैं और वास्तविक दुनिया के उदाहरणों का उपयोग कर सकते हैं?


11
इस सवाल के जवाब इतने भ्रामक हैं कि यह हास्यास्पद नहीं है
डेनिस

अच्छा सवाल, पहिए को दोबारा नहीं लगाया जाएगा: पीटर चेन। इकाई संबंध मॉडल, डेटा के एकीकृत दृष्टिकोण की ओर, 1976 : 2.3.2: " यदि रिश्तों का उपयोग संस्थाओं की पहचान के लिए किया जाता है, तो हम इसे एक कमजोर इकाई संबंध कहेंगे। यदि रिश्तों का उपयोग संस्थाओं की पहचान के लिए नहीं किया जाता है, तो हम कॉल करेंगे। यह एक नियमित इकाई संबंध है "। ओपी सवाल नीचे उबलता है: कमजोर / नियमित इकाई संबंध क्या हैं?
मिनट्स

जवाबों:


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

    उदाहरण: A Personमें एक या अधिक फ़ोन नंबर हैं। यदि उनके पास सिर्फ एक फोन नंबर होता है, तो हम इसे केवल एक कॉलम में संग्रहीत कर सकते हैं Person। चूंकि हम कई फोन नंबरों का समर्थन करना चाहते हैं, इसलिए हम एक दूसरी तालिका बनाते हैं PhoneNumbers, जिसकी प्राथमिक कुंजी में person_idसंदर्भित Personतालिका शामिल होती है।

    हम एक व्यक्ति से संबंधित फोन नंबर के बारे में सोच सकते हैं, भले ही वे एक अलग तालिका की विशेषताओं के रूप में तैयार किए गए हों। यह एक मजबूत सुराग है कि यह एक पहचान वाला संबंध है (भले ही हम person_idप्राथमिक कुंजी में शाब्दिक रूप से शामिल नहीं हैं PhoneNumbers)।

  • एक गैर-पहचान वाला संबंध तब होता है जब माता-पिता की प्राथमिक प्रमुख विशेषताएं बच्चे की प्राथमिक प्रमुख विशेषता नहीं बनना चाहिए । इसका एक अच्छा उदाहरण एक लुकिंग टेबल है, जैसे Person.stateकि प्राथमिक कुंजी को संदर्भित करने पर एक विदेशी कुंजी States.statePersonसम्मान के साथ एक बच्चे की मेज है States। लेकिन एक पंक्ति को Personउसके stateगुण द्वारा नहीं पहचाना जाता है। Ie stateप्राथमिक कुंजी का हिस्सा नहीं है Person

    एक गैर-पहचान वाला संबंध वैकल्पिक या अनिवार्य हो सकता है , जिसका अर्थ है कि विदेशी कुंजी कॉलम क्रमशः NULL को अनुमति देता है या NULL को अस्वीकार करता है।


गैर-पहचान वाले संबंधों की पहचान के बारे में अभी भी उलझन में मेरा जवाब देखें


9
+1: बिल, "चाइल्ड टेबल के लिए छद्म शब्द बनाने के लिए इन दिनों यह आम बात है, लेकिन बच्चे की प्राथमिक कुंजी के मूल भाग के लिए विदेशी कुंजी न बनाएं" - ऐसा क्यों है? Google मुझे विफल कर रहा है।
होबोडेव

17
ऐसा लगता है कि रिश्तों की पहचान करने में "ठीक से" निर्माण से प्राथमिक रूप से विशाल प्राथमिक कुंजियों का जन्म होगा। उदा। बिल्डिंग में फ़्लोर है और रूम में बेड है। बेड के लिए PK होगा (bed_id, floor_id, room_id, building_id)। यह अजीब लगता है कि मैंने इसे अभ्यास में कभी नहीं देखा है, और न ही इसे कुछ भी करने के तरीके के रूप में सुझाया है। कि पीके में बहुत अधिक अनावश्यक डेटा है।
होबोडव

24
@ होबोडोव: मैंने मल्टी-कॉलम प्राथमिक कुंजी देखी हैं जो और भी बड़ी हैं। लेकिन मैं आपकी बात लेता हूं। इस बात पर विचार करें कि मल्टी-कॉलम प्राथमिक कुंजी अधिक जानकारी देते हैं; आप Bedsबिना किसी जोड़ के किसी विशिष्ट भवन में सभी बिस्तरों के लिए तालिका को क्वेरी कर सकते हैं ।
बिल करविन

2
@ यूजीन, हां मैं उम्मीद करूंगा कि एक गैर-पहचान वाला रिश्ता हो। user_idअपने आप प्राथमिक कुंजी होनी चाहिए, और updated_byएक बहु-स्तंभ प्राथमिक कुंजी का हिस्सा नहीं है।
बिल कार्विन

4
मैं इस मॉडल का उपयोग कभी नहीं करूंगा। सबसे अच्छा जवाब नीचे "अक्सा राओ" से है जो निम्नलिखित बताता है: "एक पहचान रिश्ते का मतलब है कि बच्चे की मेज को माता-पिता के बिना विशिष्ट रूप से पहचाना नहीं जा सकता है।" क्योंकि आपकी परिभाषा में अनावश्यक शब्दार्थ जोड़ा जा रहा है जो लोगों को भ्रमित कर सकता है। यह उन संस्थाओं के बीच निर्भरता नहीं है जिनके कारण आप एक पहचान या गैर-अप्रत्यक्ष संबंध बनाते हैं।
सेबेस्टियन

887

वास्तविक दुनिया से एक और स्पष्टीकरण है:

एक पुस्तक एक मालिक की होती है, और एक मालिक कई पुस्तकों का मालिक हो सकता है। लेकिन, पुस्तक मालिक के बिना भी मौजूद हो सकती है, और इसका स्वामित्व एक मालिक से दूसरे में बदल सकता है। पुस्तक और मालिक के बीच का संबंध एक गैर-पहचान वाला संबंध है।

हालाँकि, एक पुस्तक एक लेखक द्वारा लिखी गई है, और लेखक कई किताबें लिख सकता है। लेकिन, पुस्तक को एक लेखक द्वारा लिखा जाना चाहिए - यह एक लेखक के बिना मौजूद नहीं हो सकता है। इसलिए, पुस्तक और लेखक के बीच का संबंध एक पहचान वाला संबंध है।


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

13
यदि पुस्तक 1 ​​से अधिक लेखक द्वारा लिखी गई हो तो क्या होगा? यह एम: एन प्रकार के रूप में किसी भी अधिक रिश्ते की पहचान नहीं कर रहा है, क्यों?
NGix

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

2
लेकिन वास्तविक उपयोग "पुस्तक लेखक के बिना मौजूद हो सकता है?"। जवाब वास्तव में हां है, क्योंकि लोग सीधे किताब की तलाश करेंगे। इसलिए व्यवहार में, इस मामले के लिए, उन्हें हमेशा "गैर-पहचान वाला संबंध" होना चाहिए।
हवामहमाओ

3
दोस्तों क्या चल रहा है !!, यह एक वैध उदाहरण नहीं है the Identifying relationship !!! हाँ एक किताब एक लेखक बिना लिखा नहीं किया जा सकता लेकिन, किताबें तालिका में लेखक क्षेत्र है पहचान नहीं किताब पंक्ति !!!
लेखाकार م

33

बिल का उत्तर सही है, लेकिन यह देखना चौंकाने वाला है कि अन्य सभी उत्तरों में से कोई भी सबसे महत्वपूर्ण पहलू नहीं है।

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

तो यहाँ असली कारण है:

एक रिश्ते की पहचान का उद्देश्य यह है कि विदेशी कुंजी कभी भी बदल नहीं सकती है , क्योंकि यह प्राथमिक कुंजी का हिस्सा है ... इसलिए पहचान करना !!!


2
+1 के लिए "यह गैर-शून्य होने के लिए विदेशी कुंजी के लिए पर्याप्त होगा, इसे प्राप्त करने के लिए।" यह पर्याप्त होना चाहिए, लेकिन दुर्भाग्य से ऐसा नहीं है जब यह एंटिटी फ्रेमवर्क जैसी किसी चीज़ की बात आती है, जो तब तक सही काम नहीं करता है जब तक कि आप एक पहचान वाले रिश्ते का उपयोग नहीं करते हैं, लेकिन तब एक इकाई का "आईडी" क्षेत्र खो देता है यह सिर्फ होने के परिणामस्वरूप विशिष्टता है एक समग्र कुंजी का एक हिस्सा।
त्रिवेंको

25

एक पहचान संबंध निर्दिष्ट करता है कि मूल वस्तु के बिना एक बच्चा वस्तु मौजूद नहीं हो सकती है

गैर-पहचान वाले संबंध वस्तुओं, 1: 1 या 1: n कार्डिनैलिटी के बीच एक नियमित जुड़ाव निर्दिष्ट करते हैं।

गैर-पहचान वाले रिश्तों को वैकल्पिक के रूप में निर्दिष्ट किया जा सकता है जहां एक माता-पिता की आवश्यकता नहीं है या अनिवार्य है जहां एक माता-पिता को माता-पिता के कार्डिनल सेट की आवश्यकता होती है ...


6
यह एक रिश्ते में कुल भागीदारी के विवरण की तरह लगता है, एक पहचान रिश्ते की तुलना में।
थॉमस पैड्रॉन-मैक्कार्थी

1
आप सचमुच 218k प्रतिष्ठा वाले लड़के के साथ प्रतिस्पर्धा कर रहे हैं। बस इसे बाहर फेंक देना क्योंकि तुम दोनों निश्चित रूप से मैं जितना जानता हूं उससे अधिक जानता हूं।
मार्क डिमिलो

मैं उपरोक्त परिभाषाओं से असहमत हूं। आपके पास एक ऐसी वस्तु हो सकती है जो उसके माता-पिता पर निर्भर करती है और आप चाहते हैं कि उस वस्तु को केवल 1 मूल पंक्ति के साथ जोड़ने के लिए विवश किया जाए। A Houseने Wallएस। आप घर से निकाल देते हैं और आपके पास दीवारें नहीं हैं। लेकिन एक दीवार केवल एक घर की है। इसलिए मजबूत-संबंध बनाने से काम नहीं चलेगा: PK(Wall.id, House.id)आप मॉडल को उसी दीवार से दूसरे घर में डालने की अनुमति देंगे।
सेबेस्टियन

15

यहाँ एक अच्छा वर्णन है:

दो संस्थाओं के बीच संबंधों को "पहचान" या "गैर-पहचान" के रूप में वर्गीकृत किया जा सकता है। रिश्तों की पहचान तब होती है जब मूल इकाई की प्राथमिक कुंजी को बाल इकाई की प्राथमिक कुंजी में शामिल किया जाता है। दूसरी ओर, एक गैर-पहचान वाला संबंध तब मौजूद होता है जब मूल इकाई की प्राथमिक कुंजी को बाल इकाई में शामिल किया जाता है, लेकिन बाल इकाई की प्राथमिक कुंजी के हिस्से के रूप में नहीं। इसके अलावा, गैर-पहचान वाले संबंधों को या तो "अनिवार्य" या "गैर-अनिवार्य" के रूप में वर्गीकृत किया जा सकता है। जब बच्चे की तालिका में मूल्य शून्य नहीं हो सकता है तो एक अनिवार्य गैर-पहचान संबंध मौजूद होता है। दूसरी ओर, एक गैर-अनिवार्य गैर-पहचान संबंध मौजूद है जब बच्चे की तालिका में मूल्य शून्य हो सकता है।

http://www.sqlteam.com/article/database-design-and-modeling-fundamentals

यहाँ एक पहचान रिश्ते का एक सरल उदाहरण है:

Parent
------
ID (PK)
Name

Child
-----
ID (PK)
ParentID (PK, FK to Parent.ID) -- notice PK
Name

यहाँ एक समान गैर-पहचान संबंध है:

Parent
------
ID (PK)
Name

Child
-----
ID (PK)
ParentID (FK to Parent.ID) -- notice no PK
Name

1
आपका जवाब बिल कार्विन द्वारा दिए गए इस अंतर के साथ है कि विदेशी कुंजी "नहीं है" या "नहीं चाहिए" चाइल्ड रो में प्राथमिक कुंजी का हिस्सा है।
निकोल

@Andy व्हाइट लेकिन अभिभावक की प्राथमिक पहचान में प्राथमिक कुंजी गैर-अनिवार्य हो सकती है, अर्थात, जब यह तीन-स्तंभ वाली समग्र प्राथमिक कुंजी का हिस्सा हो?
फ्रेडरिक क्राउटवल्ड

10

user287724 का उत्तर पुस्तक और लेखक के रिश्ते का निम्नलिखित उदाहरण देता है:

एक पुस्तक हालांकि एक लेखक द्वारा लिखी गई है, और लेखक कई किताबें लिख सकता है। लेकिन पुस्तक को एक लेखक द्वारा लिखा जाना चाहिए, यह एक लेखक के बिना मौजूद नहीं हो सकता है। इसलिए पुस्तक और लेखक के बीच का संबंध एक पहचान वाला रिश्ता है।

यह एक बहुत ही भ्रामक उदाहरण है और निश्चित रूप से है एक वैध उदाहरण नहीं एक के लिए identifying relationship

हाँ, एक bookकम से कम एक बिना लिखा नहीं किया जा सकता authorहै, लेकिन author(यह विदेशी कुंजी है) की bookहै पहचान नहींbook में booksतालिका!

आप निकाल सकते हैं authorसे (FK) bookपंक्ति और अभी भी कुछ अन्य क्षेत्र (द्वारा पुस्तक पंक्ति की पहचान कर सकते हैं ISBN, ID... आदि), लेकिन पुस्तक में नहीं लेखक !!

मुझे लगता है कि identifying relationship(उत्पाद तालिका) और (विशिष्ट उत्पाद विवरण तालिका) के बीच संबंध का एक वैध उदाहरण होगा1:1

products table
+------+---------------+-------+--------+
|id(PK)|Name           |type   |amount  |
+------+---------------+-------+--------+
|0     |hp-laser-510   |printer|1000    |
+------+---------------+-------+--------+
|1     |viewsonic-10   |screen |900     |
+------+---------------+-------+--------+
|2     |canon-laser-100|printer|200     |
+------+---------------+-------+--------+

printers_details table
+--------------+------------+---------+---------+------+
|Product_ID(FK)|manufacturer|cartridge|color    |papers|
+--------------+------------+---------+---------+------+
|0             |hp          |CE210    |BLACK    |300   |
+--------------+------------+---------+---------+------+
|2             |canon       |MKJ5     |COLOR    |900   |
+--------------+------------+---------+---------+------+
* please note this is not real data

इस उदाहरण में Product_IDमें printers_detailsमेज एक FK संदर्भ में माना जाता है products.idमेज और भी एक पी में printers_detailsमेज, इस वजह से एक की पहचान रिश्ता है Product_ID(FK) प्रिंटर तालिका में पहचानना है बच्चे तालिका के अंदर पंक्ति है, हम नहीं निकाल सकते product_idबच्चे मेज से क्योंकि हम क्योंकि हम खो यह प्राथमिक कुंजी है किसी भी अधिक पंक्ति पहचान नहीं कर सकते

यदि आप इसे 2 लाइनों में रखना चाहते हैं:

एक पहचान संबंध वह संबंध है जब चाइल्ड टेबल में FK को चाइल्ड टेबल में PK (या आइडेंटिफ़ायर) माना जाता है जबकि अभी भी पेरेंट टेबल को संदर्भित करता है

एक और उदाहरण तब हो सकता है जब आपके पास किसी देश के डेटाबेस के आयात और निर्यात में 3 टेबल (आयात - उत्पाद - देश) हों

importतालिका बच्चे इन क्षेत्रों है कि ( product_id) (FK, country_id) (FK, आयात की मात्रा, मूल्य, इकाइयों आयातित, (वायु, समुद्र) परिवहन के रास्ते) we may use the (product_id , thecountry_id`) प्रत्येक की पहचान के लिए आयातों की पंक्ति "यदि वे एक ही वर्ष में" यहां दोनों कॉलम बाल तालिका (आयात) में एक प्राथमिक कुंजी और साथ ही माता-पिता की तालिकाओं को संदर्भित कर सकते हैं।

कृपया मुझे खुशी मैं अंत में की अवधारणा को समझने हूँ identifying relationshipऔर non identifying relationship, इसलिए कृपया मुझे मत बताओ मैं एक के लिए इन मतदान अप के सभी के साथ गलत हूँ पूरी तरह से अवैध उदाहरण

हां तार्किक रूप से एक पुस्तक एक लेखक के बिना नहीं लिखी जा सकती है लेकिन एक पुस्तक को लेखक के बिना पहचाना जा सकता है, वास्तव में इसे लेखक के साथ नहीं पहचाना जा सकता है!

आप लेखक को पुस्तक पंक्ति से 100% निकाल सकते हैं और फिर भी पुस्तक की पहचान कर सकते हैं!


5
आप सही हैं, यदि आपके पास केवल टेबल बुक और लेखक हैं। वहां कोई पहचान वाला रिश्ता नहीं है। लेकिन यदि आप कई-से-कई संबंधों का प्रतिनिधित्व करने के लिए एक तीसरी तालिका का उपयोग करते हैं, तो उस तीसरी तालिका की प्राथमिक कुंजी में दो विदेशी कुंजियाँ होती हैं, जो पुस्तक तालिका और लेखकों की तालिका का संदर्भ देती हैं। उस तालिका का पुस्तकों और लेखकों दोनों के लिए एक पहचान का रिश्ता है। में मेरी उदाहरण देखें stackoverflow.com/questions/2814469/...
विधेयक Karwin

8

गैर-पहचान संबंध

एक गैर-पहचान वाले रिश्ते का मतलब है कि एक बच्चा माता-पिता से संबंधित है लेकिन इसे अपने आप से पहचाना जा सकता है।

PERSON    ACCOUNT
======    =======
pk(id)    pk(id)
name      fk(person_id)
          balance

ACCOUNT और PERSON के बीच का संबंध गैर-पहचान है।

रिश्ते की पहचान

एक पहचान रिश्ते का मतलब है कि बच्चे को पहचान देने के लिए माता-पिता की जरूरत है। माता-पिता के कारण बच्चा पूरी तरह से मौजूद है।

इसका मतलब यह है कि विदेशी कुंजी एक प्राथमिक कुंजी भी है।

ITEM      LANGUAGE    ITEM_LANG
====      ========    =========
pk(id)    pk(id)      pk(fk(item_id))
name      name        pk(fk(lang_id))
                      name

ITEM_LANG और ITEM के बीच संबंध पहचान रहा है। और ITEM_LANG और LANGUAGE के बीच भी।


2
PERSON और ACCOUNT गैर पहचान कैसे है? PERSON के बिना ACCOUNT कैसे मौजूद हो सकता है?
MrRobot9 15

पिछली टिप्पणी का कोई जवाब क्यों नहीं है? @ MrRobot9
AAEM

4

यदि आप समझते हैं कि माता-पिता के विलोपन के बाद बच्चे के आइटम को हटा दिया जाना चाहिए, तो यह एक पहचान का रिश्ता है।

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

एक उदाहरण के रूप में, मेरे पास प्रशिक्षुओं, प्रशिक्षणों, डिप्लोमा और प्रशिक्षण सत्रों के साथ एक प्रशिक्षण डेटाबेस है:

  • प्रशिक्षण सत्रों के साथ प्रशिक्षुओं का एक अलग संबंध है
  • प्रशिक्षण सत्रों के साथ प्रशिक्षणों की पहचान होती है
  • लेकिन प्रशिक्षुओं का राजनयिकों के साथ एक गैर-पहचान वाला संबंध है

यदि संबंधित प्रशिक्षु, प्रशिक्षण या डिप्लोमा में से एक को हटा दिया जाता है, तो केवल प्रशिक्षण सत्र को हटा दिया जाना चाहिए।


3

पुनर्मिलन की पहचान का मतलब है कि बाल इकाई पूरी तरह से मूल इकाई की मौजूदगी पर निर्भर है। उदाहरण खाता तालिका व्यक्ति तालिका और personaccount। व्यक्ति खाता तालिका केवल खाते और व्यक्ति तालिका की मौजूदगी से पहचानी जाती है।

गैर-पहचान संबंध का मतलब है कि बच्चे की तालिका माता-पिता की तालिका की मौजूदगी से पहचानी नहीं जाती है उदाहरण के लिए खाता है और खाता के रूप में तालिका है। खाता तालिका की मौजूदगी के साथ खाता नहीं है।


2

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

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

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

http://docwiki.embarcadero.com/ERStudioDA/XE7/en/Creating_and_Editing_Relationships


2

क्या माता-पिता से बच्चे में प्रवासित गुण 1 बच्चे की पहचान करने में मदद करते हैं?

  • यदि हां : पहचान-निर्भरता मौजूद है, तो संबंध की पहचान की जा रही है और बाल इकाई "कमजोर" है।
  • यदि नहीं : पहचान-निर्भरता मौजूद नहीं है, तो संबंध गैर-पहचान है और बाल इकाई "मजबूत" है।

ध्यान दें कि पहचान-निर्भरता का अर्थ अस्तित्व-निर्भरता है, लेकिन आसपास का दूसरा तरीका नहीं। प्रत्येक गैर-पूर्ण FK का अर्थ है कि कोई बच्चा माता-पिता के बिना मौजूद नहीं हो सकता है, लेकिन वह अकेले रिश्ते की पहचान नहीं करता है।

इस (और कुछ उदाहरणों) पर अधिक जानकारी के लिए, इरविन मैथड्स गाइड के "आइडेंटिफाईंग रिलेशनशिप" सेक्शन पर एक नज़र डालें ।

PS मुझे एहसास है कि मैं पार्टी के लिए देर से (बहुत) हूँ, लेकिन मुझे लगता है कि अन्य उत्तर या तो पूरी तरह से सटीक नहीं हैं (पहचान-निर्भरता के बजाय अस्तित्व-निर्भरता के मामले में इसे परिभाषित करना), या कुछ हद तक सही है। उम्मीद है कि यह उत्तर अधिक स्पष्टता प्रदान करता है ...


1 बच्चे का FK बच्चे के PRIMARY KEY या (गैर-पूर्ण) UNIQUE बाधा का एक हिस्सा है।


1

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

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

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

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


0

मान लें कि हमारे पास वे टेबल हैं:

user
--------
id
name


comments
------------
comment_id
user_id
text

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


0

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

उदाहरण के लिए: एक विक्रेता और एक पुस्तक के बीच एक संबंध जहां एक पुस्तक एक विक्रेता द्वारा बेची जा रही है, वहां मौजूद हो सकता है जहां विक्रेता की अपनी प्राथमिक कुंजी हो सकती है लेकिन इसकी इकाई केवल तब बनाई जाती है जब कोई पुस्तक बेची जा रही हो

बिल कार्विन पर आधारित संदर्भ


5
यह यहां "मजबूत" और "कमजोर" इकाई द्वारा आपके मतलब के परिभाषित करने में मदद कर सकता है।
अशक्तता
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.