सामान्यीकरण सुनिश्चित करने में सहायता के लिए ट्रांजिटिव निर्भरता से बचें
डेटाबेस में एक पारस्परिक निर्भरता एक ही तालिका में मानों के बीच अप्रत्यक्ष संबंध है जो कार्यात्मक निर्भरता का कारण बनती है। तीसरे सामान्य फॉर्म (3 एनएफ) के सामान्यीकरण मानक को प्राप्त करने के लिए, आपको किसी भी पारगमन निर्भरता को खत्म करना होगा।
अपनी प्रकृति से, एक संक्रमणीय निर्भरता के लिए तीन या अधिक विशेषताओं (या डेटाबेस कॉलम) की आवश्यकता होती है जिनके बीच एक कार्यात्मक निर्भरता होती है, जिसका अर्थ है कि तालिका में कॉलम ए कॉलम बी पर मध्यवर्ती कॉलम सी के माध्यम से निर्भर करता है।
चलो देखते हैं कि यह कैसे काम कर सकता है।
ट्रांजिटिव निर्भरता उदाहरण
लेखक
| Author_ID | लेखक | किताब | Author_Nationality |
|---|---|---|---|
| Auth_001 | ऑरसन स्कॉट कार्ड | ख़त्म करने वाले का खेल | संयुक्त राज्य अमेरिका |
| Auth_001 | ऑरसन स्कॉट कार्ड | ख़त्म करने वाले का खेल | संयुक्त राज्य अमेरिका |
| Auth_002 | मार्गरेट एटवुड | हस्तनिर्मित कथा | कनाडा |
उपरोक्त लेखक उदाहरण में:
- पुस्तक → लेखक : यहां, पुस्तक विशेषता लेखक विशेषता निर्धारित करती है। यदि आप पुस्तक का नाम जानते हैं, तो आप लेखक का नाम सीख सकते हैं। हालांकि, लेखक पुस्तक निर्धारित नहीं करता है, क्योंकि एक लेखक कई किताबें लिख सकता है। उदाहरण के लिए, सिर्फ इसलिए कि हम लेखक के नाम ऑरसन स्कॉट कार्ड को जानते हैं, हम अभी भी पुस्तक का नाम नहीं जानते हैं।
- लेखक → लेखक_राष्ट्रीयता : इसी तरह, लेखक विशेषता लेखक_राष्ट्रीयता को निर्धारित करती है , लेकिन दूसरी तरफ नहीं; सिर्फ इसलिए कि हम राष्ट्रीयता को जानते हैं इसका मतलब यह नहीं है कि हम लेखक को निर्धारित कर सकते हैं।
लेकिन यह तालिका एक पारस्परिक निर्भरता पेश करती है:
- पुस्तक → लेखक_राष्ट्रीयता: यदि हम पुस्तक का नाम जानते हैं, तो हम लेखक कॉलम के माध्यम से राष्ट्रीयता निर्धारित कर सकते हैं।
ट्रांजिटिव निर्भरता से बचें
तीसरा सामान्य फॉर्म सुनिश्चित करने के लिए, चलिए ट्रांजिटिव निर्भरता को हटा दें।
हम लेखक तालिका से पुस्तक कॉलम को हटाकर और एक अलग पुस्तक तालिका बनाकर शुरू कर सकते हैं:
पुस्तकें
| Book_ID | किताब | Author_ID |
|---|---|---|
| Book_001 | ख़त्म करने वाले का खेल | Auth_001 |
| Book_001 | दिमाग के बच्चे | Auth_001 |
| Book_002 | हस्तनिर्मित कथा | Auth_002 |
लेखक
| Author_ID | लेखक | Author_Nationality |
|---|---|---|
| Auth_001 | ऑरसन स्कॉट कार्ड | संयुक्त राज्य अमेरिका |
| Auth_002 | मार्गरेट एटवुड | कनाडा |
क्या यह ठीक है? आइए अब हमारी निर्भरताओं की जांच करें:
पुस्तकें तालिका :
- Book_ID → पुस्तक: पुस्तक Book_ID पर निर्भर करती है।
- इस तालिका में कोई अन्य निर्भरता मौजूद नहीं है, इसलिए हम ठीक हैं। ध्यान दें कि विदेशी कुंजी Author_ID इस तालिका को अपनी प्राथमिक कुंजी Author_ID के माध्यम से AUTHORS तालिका में लिंक करती है । हमने एक संक्रमणीय निर्भरता, संबंधपरक डेटाबेस का एक प्रमुख डिजाइन से बचने के लिए एक रिश्ता बनाया है।
लेखक तालिका :
- लेखक_आईडी → लेखक: लेखक लेखक_आईडी पर निर्भर करता है।
- लेखक → लेखक_ राष्ट्रीयता : राष्ट्रीयता लेखक द्वारा निर्धारित की जा सकती है।
- लेखक_आईडी → लेखक_राष्ट्रीयता: राष्ट्रीयता को लेखक विशेषता के माध्यम से Author_ID से निर्धारित किया जा सकता है। हमारे पास अभी भी एक पारस्परिक निर्भरता है।
इस डेटा को सामान्य करने के लिए हमें एक तीसरी तालिका जोड़नी होगी:
देशों
| country_id | देश |
|---|---|
| Coun_001 | संयुक्त राज्य अमेरिका |
| Coun_002 | कनाडा |
लेखक
| Author_ID | लेखक | country_id |
|---|---|---|
| Auth_001 | ऑरसन स्कॉट कार्ड | Coun_001 |
| Auth_002 | मार्गरेट एटवुड | Coun_002 |
अब टेबल के बीच लिंक करने के लिए विदेशी कुंजी का उपयोग करने के लिए हमारे पास तीन टेबल हैं:
- पुस्तक तालिका की विदेशी कुंजी Author_ID AUTHORS तालिका में किसी लेखक को एक पुस्तक से लिंक करती है।
- लेखक तालिका की विदेशी कुंजी Country_ID COUNTRIES तालिका में किसी देश के लेखक को लिंक करती है।
- COUNTRIES तालिका में कोई विदेशी कुंजी नहीं है क्योंकि इस डिज़ाइन में किसी अन्य तालिका से लिंक करने की आवश्यकता नहीं है।
क्यों ट्रांजिटिव निर्भरता खराब डेटाबेस डिजाइन हैं
3 एनएफ सुनिश्चित करने में मदद के लिए ट्रांजिटिव निर्भरताओं से बचने का क्या महत्व है? आइए हमारी पहली तालिका दोबारा विचार करें और इसके द्वारा बनाए गए मुद्दों को देखें:
लेखक
| Author_ID | लेखक | किताब | Author_Nationality |
|---|---|---|---|
| Auth_001 | ऑरसन स्कॉट कार्ड | ख़त्म करने वाले का खेल | संयुक्त राज्य अमेरिका |
| Auth_001 | ऑरसन स्कॉट कार्ड | दिमाग के बच्चे | संयुक्त राज्य अमेरिका |
| Auth_002 | मार्गरेट एटवुड | हस्तनिर्मित कथा | कनाडा |
इस प्रकार का डिज़ाइन डेटा विसंगतियों और असंगतताओं में योगदान दे सकता है, उदाहरण के लिए:
- यदि आपने दो पुस्तकें "बच्चों के दिमाग" और "एन्डर गेम" को हटा दिया है, तो आप लेखक "ऑर्सन स्कॉट कार्ड" और उनकी राष्ट्रीयता को पूरी तरह से डेटाबेस से हटा देंगे।
- जब तक आप कोई पुस्तक नहीं जोड़ते तब तक आप डेटाबेस में एक नया लेखक नहीं जोड़ सकते; क्या होगा यदि लेखक अभी तक अप्रकाशित है या आप उस पुस्तक के नाम को नहीं जानते हैं जिसे उसने लिखा है?
- अगर "ऑरसन स्कॉट कार्ड" ने अपनी नागरिकता बदल दी है, तो आपको इसे सभी अभिलेखों में बदलना होगा जिसमें वह प्रकट होता है। एक ही लेखक के साथ कई रिकॉर्ड होने के कारण गलत डेटा हो सकता है: क्या होगा यदि डेटा प्रविष्टि व्यक्ति को यह नहीं पता कि उसके लिए कई रिकॉर्ड हैं और केवल एक रिकॉर्ड में डेटा बदलते हैं?
- आप लेखक को पूरी तरह से हटाए बिना "द हैंडमाइड्स टेल" जैसी पुस्तक को हटा नहीं सकते हैं।
ये सामान्य कारण हैं, और सामान्य निर्भरताओं से परहेज करते हैं, डेटा की रक्षा करते हैं और स्थिरता सुनिश्चित करते हैं।