मेरे पास पीएच.डी. सीएस में - डेटाबेस के क्षेत्र में, इसलिए यह उत्तर प्रोग्रामर परिप्रेक्ष्य से थोड़ा अलग होगा। ओलिवर हनाप्पी के संबंध में, एक कुंजी बदल सकती है और कभी-कभी बदल जाती है यदि यह सरोगेट कुंजी नहीं है। उदा. एक प्राकृतिक कुंजी या एक समग्र कुंजी। उदाहरण के लिए। यूएस में अपना एसएसएन बदलना संभव है। लेकिन कई प्रोग्रामर वर्षों से इसे एक अपरिवर्तनीय कुंजी मानते हैं और इसका उपयोग इस तरह करते हैं। विदेशी कुंजियों से बनी समग्र प्राथमिक कुंजी को बदलना बहुत अधिक सामान्य है।
मैं ऐसे डेटाबेस से निपट रहा हूं जिसमें एक टर्नरी रिलेशनशिप है। विशेष रूप से तीन इकाइयां (विदेशी कुंजी उनके संबंधित तालिकाओं में प्राथमिक कुंजी सरोगेट होने के साथ)। हालांकि, तीसरी इकाई को बदलते समय दो संस्थाओं के बीच संबंध बनाए रखने के लिए आवश्यकता प्रतिच्छेदन तालिका का भाग बदलना (जिसे MSDN पर शुद्ध सम्मिलित तालिका भी कहा जाता है) प्राथमिक कुंजी। यह एक मान्य डिज़ाइन है और इसे केवल टर्नरी रिलेशनशिप इंटरसेक्शन टेबल को हटाकर और इसे दो बाइनरी रिलेशनशिप टेबल (जिसमें उनकी अपनी सरोगेट कुंजियाँ हो सकती हैं) के साथ बदलकर सुधार किया जा सकता है। ईएफ इस जुर्माना को संभालेगा। यह डिज़ाइन परिवर्तन एक (कई-> कई) -> कई या माता-पिता 1-अभिभावक 2 -> बाल-पोते मॉडल (यदि यह स्पष्ट नहीं है तो नीचे दिए गए उदाहरण को पढ़ें)। इसके साथ इकाई ढांचा ठीक काम करेगा क्योंकि प्रत्येक संबंध वास्तव में कई संबंधों में से एक है। लेकिन यह एक डीबी परिप्रेक्ष्य से एक पागल डिजाइन है। मैं आपको एक उदाहरण दिखाता हूं क्यों।
विचार करें कि कक्षा में पाठ्यक्रम, कक्षा और प्रशिक्षक एक दूसरे के साथ जुड़े हुए हैं। कक्षा में शामिल हो सकते हैं:कोर्सआईडी, क्लासरूमआईडी, इंस्ट्रक्टरआईडी विदेशी कुंजी के रूप में और तीनों सहित एक समग्र प्राथमिक कुंजी शामिल है। हालांकि एक स्पष्ट, संक्षिप्त टर्नरी मॉडल (3 तरह से संबंध) हम इसे द्विआधारी संबंधों में तोड़ सकते हैं। यह दो चौराहे टेबल देगा। सरोगेट कुंजियाँ जोड़ने से EF इस प्रकार संतुष्ट होगा:
क्लास(सरोगेटकीक्लास , प्रशिक्षक आईडी , पाठ्यक्रम आईडी )
ClassRoomUsed(सरोगेटकीक्लासरूम यूज्ड , सरोगेटकीक्लास , ClassRoomID )
इस डिजाइन के साथ समस्या यह है कि हम एक ही पाठ्यक्रम और प्रशिक्षक को कई बार संबद्ध कर सकते हैं, जिससे पिछला मॉडल बचता है। इस समस्या से बचने के लिए, आप दो आईडी फ़ील्ड की विशिष्टता के लिए डेटाबेस में एक बाधा जोड़ सकते हैं, लेकिन आप ऐसा क्यों करना चाहेंगे जब आप केवल सरोगेट कुंजी के साथ काम कर रहे हों? हालाँकि यह समाधान उतना ही अच्छा काम करेगा जितना मैं बता सकता हूँ। हालांकि यह डीबी में आवश्यक अप्राकृतिक अद्वितीय बाधा के कारण तर्क डेटाबेस डिज़ाइन नहीं है।
लेकिन, यदि आप अपना डेटाबेस नहीं बदलना चाहते हैं या अपना डेटाबेस नहीं बदल सकते हैं, तो यहां एक दूसरा समाधान है :इंटरसेक्शन/एसोसिएशन टेबल बस यही हैं, दो या अधिक संस्थाओं को एक साथ जोड़ने वाले लिंक। यदि कोई परिवर्तन करता है, तो संबद्धता को हटा दें और उपयुक्त विदेशी कुंजियाँ (नेविगेशन गुण) वाली एक नई संबद्धता को फिर से बनाएँ। इसका मतलब है कि आपको किसी भी रिश्ते में बाल संस्थाओं की आवश्यकता नहीं होगी, लेकिन यह बेहद सामान्य है।
मैं सुझाव दूंगा कि एंटिटी फ्रेमवर्क (भविष्य में) हममें से उन लोगों को अनुमति देता है जो जब चाहें चौराहे/एसोसिएशन टेबल में चाबियों के हिस्सों को बदलने के लिए एक सुरुचिपूर्ण डीबी मॉडल तैयार कर सकते हैं!
एक और उदाहरण मुफ्त में:
एक छात्र, पाठ्यक्रम, ग्रेड एसोसिएशन पर विचार करें। छात्र एक ग्रेड के माध्यम से एक पाठ्यक्रम से जुड़े होते हैं। आमतौर पर यह छात्र और एक कोर्स के बीच कई से अधिक जुड़ाव होता है, जिसमें एसोसिएशन टेबल में एक अतिरिक्त क्षेत्र होता है जिसे ग्रेड कहा जाता है (एसोसिएशन टेबल में ग्रेड जैसे पेलोड डेटा होते हैं, इंटरसेक्शन टेबल में पेलोड नहीं होता है और एमएसडीएन में शुद्ध जॉइन टेबल के रूप में संदर्भित किया जाता है। एक ही स्थान पर पट्टे):
छात्र(छात्र आईडी , ....)
पाठ्यक्रम(पाठ्यक्रम आईडी , ...)
लेना(StudentID , पाठ्यक्रम आईडी , ग्रेड)
यदि कोई ड्रॉपडाउन से डेटा प्रविष्टि त्रुटि करता है और किसी छात्र को गलत कक्षा में डालता है, तो आप चाहते हैं कि वे बाद में फिर से ड्रॉपडाउन का चयन करके और एक अलग पाठ्यक्रम का चयन करके इसे बदल दें। पृष्ठभूमि में आपको ईएफ ऑब्जेक्ट को टेकिंग टेबल से हटाना होगा और यदि कोई है तो ग्रेड खोए बिना इसे फिर से बनाना होगा। बस विदेशी कुंजी बदल रही है पाठ्यक्रम आईडी एक बेहतर विकल्प की तरह लगता है। अपने स्वयं के जुड़ाव के साथ आओ अगर यह काल्पनिक लगता है, लेकिन एक प्रोफेसर के रूप में यह मेरे लिए स्वाभाविक था।
निष्कर्ष:जब आपके बीच संबंधों की एक कड़ी होती है, तो बेहतर हो सकता है कि कैस्केडिंग और/या FK को बदलने की अनुमति न दी जाए, लेकिन जहां इसकी आवश्यकता होती है, वहां गूंजने योग्य/तार्किक परिदृश्य मौजूद होते हैं, भले ही सामान्य<में सर्वोत्तम अभ्यास के रूप में अनुशंसित न किया गया हो। /em> .
यह समस्या निम्न अपवादों के साथ प्रकट हो सकती है, इस पर निर्भर करते हुए कि आप क्रमशः मॉडल में नेविगेशन गुण या मुख्य गुण को बदल रहे हैं:
एक संदर्भात्मक अखंडता बाधा उल्लंघन हुआ:एक प्राथमिक कुंजी संपत्ति जो कि संदर्भात्मक अखंडता बाधा का एक हिस्सा है, तब तक नहीं बदला जा सकता जब तक कि आश्रित वस्तु अपरिवर्तित न हो, जब तक कि इसे एसोसिएशन की प्रमुख वस्तु पर सेट नहीं किया जा रहा हो। मुख्य वस्तु को ट्रैक किया जाना चाहिए और हटाने के लिए चिह्नित नहीं किया जाना चाहिए।
संपत्ति 'X' वस्तु की मुख्य जानकारी का हिस्सा है और इसे संशोधित नहीं किया जा सकता है।
