कल्पना कीजिए कि आप एक बहुत बड़े, असंरचित डेटाबेस के साथ काम कर रहे हैं जिसमें बार-बार दोहराई गई, अनावश्यक जानकारी भरी हुई है। हर अपडेट या डिलीशन एक संभावित समस्या बन जाता है, जिसमें त्रुटियों और असंगतियों का जोखिम होता है। थर्ड नॉर्मल फॉर्म (3NF) इस अव्यवस्था से बचने के लिए एक सिद्ध डेटाबेस नॉर्मलाइज़ेशन विधि है। 3NF लागू करने से आपकी डेटा संरचना साफ-सुथरी हो जाती है—कुशल, सुव्यवस्थित और अनावश्यक पुनरावृत्ति से मुक्त।
इस लेख में, हम देखेंगे कि 3NF कैसे काम करता है, यह क्यों महत्त्वपूर्ण है, और आप इसे व्यवहार में कैसे ला सकते हैं। हम 3NF की अन्य फॉर्म्स से तुलना भी करेंगे और जानेंगे कि किस स्थिति में किसका उपयोग करना चाहिए। हर कोई इन संरचनाओं के बारे में अधिक सीखकर लाभ उठा सकता है, लेकिन यदि आप डेटाबेस डिज़ाइनर या डेटा वैज्ञानिक हैं, तो यह ज्ञान खास तौर पर उपयोगी है—यह आपके काम को काफी सरल बना सकता है और आपके डेटाबेस को विश्वसनीय बनाए रखता है। यदि आप समग्र रूप से डेटाबेस डिज़ाइन में रुचि रखते हैं, तो हमारा पूरा Database Design पाठ्यक्रम देखें।
थर्ड नॉर्मल फॉर्म (3NF) की परिभाषा
थर्ड नॉर्मल फॉर्म डेटाबेस नॉर्मलाइज़ेशन की एक प्रमुख अवधारणा है जो अवांछित निर्भरताओं को हटाती है। 3NF, फर्स्ट नॉर्मल फॉर्म (1NF) और सेकंड नॉर्मल फॉर्म (2NF) पर आधारित है, यानी यह उनके नियमों को अपनाता है: 1NF प्रत्येक सेल में एटॉमिक (अविभाज्य) मानों की मांग करता है, और 2NF कॉम्पोज़िट प्राइमरी की पर आंशिक निर्भरताओं को हटाता है। 3NF इसे आगे बढ़ाकर ट्रांज़िटिव निर्भरताओं को हटाता है—ऐसी स्थिति जहाँ नॉन-की एट्रिब्यूट्स, प्राइमरी की पर अप्रत्यक्ष रूप से निर्भर होते हैं।
इस पर ध्यान केंद्रित करके, 3NF सुनिश्चित करता है कि किसी टेबल में प्रत्येक नॉन-की कॉलम सीधे और केवल प्राइमरी की से जुड़ा हो। व्यावहारिक रूप से, 3NF पुनरावृत्ति को न्यूनतम करता है और डेटा डालते, अपडेट करते या डिलीट करते समय आने वाली विसंगतियों से बचने में मदद करता है।
1970 के दशक में, Edgar F. Codd ने पूरी तरह से नॉर्मलाइज़्ड डेटाबेस संरचना प्राप्त करने की शर्तों को औपचारिक रूप देने के लिए 3NF पेश किया। कुछ वर्ष बाद Carlo Zaniolo ने इसका पुनर्प्रस्तुतीकरण दिया, जिसने “क्लासिक” 3NF और अधिक प्रतिबंधात्मक Boyce-Codd नॉर्मल फॉर्म (BCNF) के बीच के अंतर को और स्पष्ट किया। BCNF की चिंता अभी न करें—हम इसे आगे समझेंगे।
थर्ड नॉर्मल फॉर्म की शर्तों को समझना
तो, 3NF हासिल करने के लिए वास्तव में क्या चाहिए? किसी टेबल के योग्य होने के लिए, उसे कुछ शर्तें पूरी करनी होती हैं:
- 2NF में होना: इसका मतलब है कि इसमें पहले से एटॉमिक वैल्यू हैं, कोई रिपीटिंग ग्रुप नहीं है, और किसी भी कॉम्पोज़िट की पर आंशिक निर्भरता नहीं है।

3NF में 2NF और 1NF शामिल हैं। चित्र: लेखक द्वारा
- कोई ट्रांज़िटिव निर्भरता नहीं: यह नियम सबसे महत्वपूर्ण है। 3NF टेबल में, कोई भी नॉन-प्राइमरी-की कॉलम केवल प्राइमरी की पर निर्भर होना चाहिए, न कि किसी अन्य नॉन-की कॉलम के माध्यम से अप्रत्यक्ष रूप से।
आइए देखें कि व्यावहारिक रूप से इसका क्या अर्थ है।
3NF प्राप्त करने के लिए टेबल्स का डीकंपोज़िशन
आइए 3NF तक पहुँचने के लिए टेबल्स को डीकंपोज़ करने की प्रक्रिया पर चलते हैं। हर चरण को समझाने के लिए हम DataCamp कोर्सेज़ के कुछ नमूना डेटा का उपयोग करेंगे।
चरण 1: ट्रांज़िटिव निर्भरताओं की पहचान करें
शुरू करने के लिए, हम टेबल में ऐसे किसी भी एट्रिब्यूट को खोजेंगे जो प्राइमरी की पर अप्रत्यक्ष रूप से निर्भर हो। एक सरल नियम के रूप में, यदि कोई एट्रिब्यूट प्राइमरी की के अलावा किसी और चीज़ पर निर्भर करता है, तो यह एक ट्रांज़िटिव निर्भरता का संकेत है। यह बताता है कि अब आपकी टेबल को विभाजित करने का समय आ सकता है।
नीचे दी गई तीन टेबल्स देखें। इनमें से किसमें ट्रांज़िटिव निर्भरता है?
टेबल 1: Course
टेबल 2: Instructor
| Instructor ID | Instructor Name | Expertise |
|---|
| 1 | Sarah Johnson | Data Science |
| 2 | Tom Williams | Machine Learning |
| 3 | Emily Brown | Python |
टेबल 3: Enrollments
उत्तर है… टेबल 3!
इस टेबल में, Course Name, Course ID पर निर्भर है, लेकिन सीधे तौर पर Enrollment ID (जो प्राइमरी की है) पर नहीं। यह अप्रत्यक्ष निर्भरता, Course Name को ट्रांज़िटिव निर्भरता बनाती है।
चरण 2: डेटा को नई टेबल्स में अलग करें
ट्रांज़िटिव निर्भरता को दूर करने के लिए, हम टेबल 1 को दो टेबल्स में विभाजित करेंगे। हर टेबल सीधे निर्भर डेटा पर केंद्रित होगी।
संशोधित enrollments टेबल
| Enrollment ID | Student Name | Course ID |
|---|
| 1001 | Alice Smith | 201 |
| 1002 | Bob Green | 202 |
| 1003 | Charlie Blue | 201 |
Courses टेबल
अब, प्रत्येक टेबल में केवल वही जानकारी है जो सीधे उसकी प्राइमरी की पर निर्भर करती है: Course ID अब Course Name के लिए Courses टेबल में प्राइमरी की है, और Enrollment ID Enrollments टेबल में प्राइमरी की है।
इस डीकंपोज़िशन के साथ, टेबल्स अब 3NF की आवश्यकताओं को पूरा करती हैं—पुनरावृत्ति समाप्त हो गई है और हर टेबल केवल सीधे सम्बद्ध जानकारी संग्रहीत करती है।
यदि आप स्वयं डेटाबेस बनाकर हाथ आज़माना चाहते हैं, तो हमारा Creating PostgreSQL Databases कोर्स देखें। यदि आप थोड़े उन्नत हैं, तो आप Introduction to Data Modeling in Snowflake आज़मा सकते हैं, जिसमें एंटिटी-रिलेशनशिप और डाइमेंशनल मॉडलिंग जैसी अवधारणाएँ शामिल हैं।
थर्ड नॉर्मल फॉर्म के लाभ और सीमाएँ
तो, 3NF तक पहुँचने के लिए यह सब मेहनत क्यों करें? मुख्य फायदे ये हैं:
- बेहतर डेटा इंटीग्रिटी: ट्रांज़िटिव निर्भरताओं को हटाकर, 3NF यह सुनिश्चित करने में मदद करता है कि अपडेट और डिलीशन के बाद टेबल्स में परस्पर विरोधी या पुराना डेटा न रह जाए।
- कम पुनरावृत्ति: कम पुनरावृत्ति का मतलब रखरखाव आसान होना और स्टोरेज का कम उपयोग है।
- सरल डेटा मेंटेनेंस: समान जानकारी को समर्पित टेबल्स में रखना रिकॉर्ड्स को अपडेट करना आसान बनाता है, बिना डुप्लीकेट प्रविष्टियों का पीछा किए।
यह कहा जा सकता है कि जहाँ 3NF संरचनाएँ डेटा की शुद्धता का समर्थन करती हैं, वहीं डेटा अधिक खंडित भी हो सकता है, जिससे अतिरिक्त टेबल जॉइन्स के कारण जटिल क्वेरीज़ कभी-कभी धीमी पड़ सकती हैं। जिन मामलों में गति की ज़रूरत नॉर्मलाइज़ेशन से अधिक महत्त्वपूर्ण हो, वहाँ BCNF या 4NF अधिक व्यावहारिक विकल्प हो सकते हैं।
तुलना: फर्स्ट, सेकंड, थर्ड और BC नॉर्मल फॉर्म्स
आइए फॉर्म्स के बीच के अंतर देखें।
तुलनात्मक सारणी: फर्स्ट, सेकंड और थर्ड नॉर्मल फॉर्म्स
यहाँ 1NF, 2NF और 3NF की आवश्यकताओं को समझने में मदद के लिए एक तुलना सारणी दी गई है।
| Feature | 1NF | 2NF | 3NF |
|---|
| Atomic data | ✅ | ✅ | ✅ |
| No partial dependencies | ❌ | ✅ | ✅ |
| No transitive dependencies | ❌ | ❌ | ✅ |
थर्ड नॉर्मल फॉर्म बनाम Boyce-Codd नॉर्मल फॉर्म (BCNF)
BCNF, 3NF का एक “कड़ाई वाला” रूप है जो ओवरलैपिंग कैंडिडेट कीज़ के साथ उत्पन्न होने वाली विसंगतियों को और हटाता है। यह विशेष रूप से उन जटिल मामलों में उपयोगी हो सकता है जहाँ केवल 3NF सभी निर्भरताओं को पूरी तरह समाप्त नहीं करता। BCNF तब लागू होता है जब कोई नॉन-प्राइम एट्रिब्यूट, किसी ऐसे एट्रिब्यूट पर निर्भर हो जो किसी कॉम्पोज़िट कैंडिडेट की का हिस्सा हो। यह जटिल लगता है, इसलिए आइए इसे एक उदाहरण से सरल करें।
वर्तमान संरचना (3NF में)
3NF प्राप्त करने हेतु डीकंपोज़िशन के बाद, हमारे पास ये दो टेबल्स थीं:
Enrollments टेबल
| Enrollment ID | Student Name | Course ID |
|---|
| 1001 | Alice Smith | 201 |
| 1002 | Bob Green | 202 |
| 1003 | Charlie Blue | 201 |
Courses टेबल
इस संरचना में, प्रत्येक तालिका 3NF में है, कोई ट्रांजिटिव निर्भरता नहीं है, और डेटा उपयुक्त रूप से सामान्यीकृत है।
एक नई आवश्यकता प्रस्तुत करना
अब, Courses में एक नया गुण जोड़ते हैं: वह Classroom जिसमें प्रत्येक पाठ्यक्रम आयोजित होता है। यह नया गुण ऐसी स्थिति पैदा कर सकता है, जिसके लिए BCNF की आवश्यकता हो।
अद्यतन पाठ्यक्रम तालिका (3NF)
यहाँ, पाठ्यक्रम ID अभी भी प्राथमिक कुंजी है, और अन्य सभी गुण सीधे उसी पर निर्भर हैं। लेकिन मान लीजिए एक नया नियम है कि प्रत्येक कक्षा एक समय में केवल एक विषय ही रख सकती है। यह भी मान लें कि पाठ्यक्रम का नाम "SQL Fundamentals" अलग-अलग पाठ्यक्रम ID (जैसे 201, 204, आदि) के अंतर्गत पेश किया जा सकता है, यदि उन्हें अलग-अलग समय पर निर्धारित किया गया हो। उस स्थिति में, "SQL Fundamentals" की प्रत्येक पेशकश फिर भी "कक्ष 101" में ही आयोजित होगी, भले ही विशिष्ट पाठ्यक्रम ID कुछ भी हो। परिणामस्वरूप, पाठ्यक्रम का नाम भी अद्वितीय रूप से कक्षा को निर्धारित करता है।
इसका मतलब है कि अब हमारे पास दो प्रत्याशी कुंजियाँ हैं:
- पाठ्यक्रम ID
- पाठ्यक्रम का नाम
दोनों प्रत्याशी कुंजियों के साथ, अब हमारे पास एक समस्या है जिसका समाधान 3NF नहीं करता: कक्षा केवल पाठ्यक्रम ID पर नहीं, बल्कि पाठ्यक्रम के नाम पर निर्भर है।
BCNF लागू करना
इस निर्भरता समस्या को समाप्त करने के लिए, हमें Courses तालिका को और विखंडित करके दो अलग-अलग तालिकाओं में बाँटना होगा, जो BCNF के साथ बेहतर मेल खाती हों:
- एक नई Courses तालिका, जिसमें केवल पाठ्यक्रम ID और पाठ्यक्रम का नाम शामिल हों।
- एक CourseDetails तालिका, जो पाठ्यक्रम का नाम और कक्षा के संबंध को संग्रहीत करे।
यह इस प्रकार दिखेगा:
संशोधित पाठ्यक्रम तालिका (BCNF)
CourseDetails तालिका (BCNF)
इस नई संरचना के साथ, प्रत्येक तालिका BCNF की शर्तों को पूरा करती है:
- Courses तालिका में, पाठ्यक्रम ID प्राथमिक कुंजी है, और सभी गुण केवल उसी पर निर्भर हैं।
- CourseDetails तालिका में, पाठ्यक्रम का नाम प्राथमिक कुंजी है, और कक्षा केवल पाठ्यक्रम के नाम पर निर्भर है।
यह सेटअप परस्पर अतिव्यापी प्रत्याशी कुंजियों से पैदा हुई किसी भी निर्भरता समस्या को हटाता है और एक सख्ती से सामान्यीकृत संरचना सुनिश्चित करता है।
निष्कर्ष
थर्ड नॉर्मल फॉर्म उन डेटाबेस डिज़ाइनरों के लिए एक मूल्यवान साधन है जो डेटा को साफ, सुसंगत और समस्याग्रस्त निर्भरताओं से मुक्त रखना चाहते हैं। 3NF के साथ, डेटा अखंडता बेहतर होती है, प्रबंधन सुगम होता है और पुनरावृत्ति कम होती है। ध्यान रखें, जहाँ 3NF अधिकांश स्थितियों में अच्छा काम करता है, वहीं अधिक जटिल डेटाबेस BCNF या 4NF जैसी अतिरिक्त नॉर्मल फॉर्म्स से लाभान्वित हो सकते हैं।
यदि आपको यह लेख उपयोगी लगा, तो हमारा SQL Associate Certification अर्जित करके अगला कदम उठाने पर विचार करें। यह आपके SQL और डेटाबेस प्रबंधन कौशल को मान्य करने और संभावित नियोक्ताओं के सामने अपनी विशेषज्ञता प्रदर्शित करने का एक शानदार तरीका है!
कल्पना कीजिए कि आप एक बहुत बड़े, असंरचित डेटाबेस के साथ काम कर रहे हैं जिसमें बार-बार दोहराई गई, अनावश्यक जानकारी भरी हुई है। हर अपडेट या डिलीशन एक संभावित समस्या बन जाता है, जिसमें त्रुटियों और असंगतियों का जोखिम होता है। थर्ड नॉर्मल फॉर्म (3NF) इस अव्यवस्था से बचने के लिए एक सिद्ध डेटाबेस नॉर्मलाइज़ेशन विधि है। 3NF लागू करने से आपकी डेटा संरचना साफ-सुथरी हो जाती है—कुशल, सुव्यवस्थित और अनावश्यक पुनरावृत्ति से मुक्त।
इस लेख में, हम देखेंगे कि 3NF कैसे काम करता है, यह क्यों महत्त्वपूर्ण है, और आप इसे व्यवहार में कैसे ला सकते हैं। हम 3NF की अन्य फॉर्म्स से तुलना भी करेंगे और जानेंगे कि किस स्थिति में किसका उपयोग करना चाहिए। हर कोई इन संरचनाओं के बारे में अधिक सीखकर लाभ उठा सकता है, लेकिन यदि आप डेटाबेस डिज़ाइनर या डेटा वैज्ञानिक हैं, तो यह ज्ञान खास तौर पर उपयोगी है—यह आपके काम को काफी सरल बना सकता है और आपके डेटाबेस को विश्वसनीय बनाए रखता है। यदि आप समग्र रूप से डेटाबेस डिज़ाइन में रुचि रखते हैं, तो हमारा पूरा Database Design पाठ्यक्रम देखें।
थर्ड नॉर्मल फॉर्म (3NF) की परिभाषा
थर्ड नॉर्मल फॉर्म डेटाबेस नॉर्मलाइज़ेशन की एक प्रमुख अवधारणा है जो अवांछित निर्भरताओं को हटाती है। 3NF, फर्स्ट नॉर्मल फॉर्म (1NF) और सेकंड नॉर्मल फॉर्म (2NF) पर आधारित है, यानी यह उनके नियमों को अपनाता है: 1NF प्रत्येक सेल में एटॉमिक (अविभाज्य) मानों की मांग करता है, और 2NF कॉम्पोज़िट प्राइमरी की पर आंशिक निर्भरताओं को हटाता है। 3NF इसे आगे बढ़ाकर ट्रांज़िटिव निर्भरताओं को हटाता है—ऐसी स्थिति जहाँ नॉन-की एट्रिब्यूट्स, प्राइमरी की पर अप्रत्यक्ष रूप से निर्भर होते हैं।
इस पर ध्यान केंद्रित करके, 3NF सुनिश्चित करता है कि किसी टेबल में प्रत्येक नॉन-की कॉलम सीधे और केवल प्राइमरी की से जुड़ा हो। व्यावहारिक रूप से, 3NF पुनरावृत्ति को न्यूनतम करता है और डेटा डालते, अपडेट करते या डिलीट करते समय आने वाली विसंगतियों से बचने में मदद करता है।
1970 के दशक में, Edgar F. Codd ने पूरी तरह से नॉर्मलाइज़्ड डेटाबेस संरचना प्राप्त करने की शर्तों को औपचारिक रूप देने के लिए 3NF पेश किया। कुछ वर्ष बाद Carlo Zaniolo ने इसका पुनर्प्रस्तुतीकरण दिया, जिसने “क्लासिक” 3NF और अधिक प्रतिबंधात्मक Boyce-Codd नॉर्मल फॉर्म (BCNF) के बीच के अंतर को और स्पष्ट किया। BCNF की चिंता अभी न करें—हम इसे आगे समझेंगे।
थर्ड नॉर्मल फॉर्म की शर्तों को समझना
तो, 3NF हासिल करने के लिए वास्तव में क्या चाहिए? किसी टेबल के योग्य होने के लिए, उसे कुछ शर्तें पूरी करनी होती हैं:
3NF में 2NF और 1NF शामिल हैं। चित्र: लेखक द्वारा
आइए देखें कि व्यावहारिक रूप से इसका क्या अर्थ है।
3NF प्राप्त करने के लिए टेबल्स का डीकंपोज़िशन
आइए 3NF तक पहुँचने के लिए टेबल्स को डीकंपोज़ करने की प्रक्रिया पर चलते हैं। हर चरण को समझाने के लिए हम DataCamp कोर्सेज़ के कुछ नमूना डेटा का उपयोग करेंगे।
चरण 1: ट्रांज़िटिव निर्भरताओं की पहचान करें
शुरू करने के लिए, हम टेबल में ऐसे किसी भी एट्रिब्यूट को खोजेंगे जो प्राइमरी की पर अप्रत्यक्ष रूप से निर्भर हो। एक सरल नियम के रूप में, यदि कोई एट्रिब्यूट प्राइमरी की के अलावा किसी और चीज़ पर निर्भर करता है, तो यह एक ट्रांज़िटिव निर्भरता का संकेत है। यह बताता है कि अब आपकी टेबल को विभाजित करने का समय आ सकता है।
नीचे दी गई तीन टेबल्स देखें। इनमें से किसमें ट्रांज़िटिव निर्भरता है?
टेबल 1: Course
टेबल 2: Instructor
टेबल 3: Enrollments
उत्तर है… टेबल 3!
इस टेबल में, Course Name, Course ID पर निर्भर है, लेकिन सीधे तौर पर Enrollment ID (जो प्राइमरी की है) पर नहीं। यह अप्रत्यक्ष निर्भरता, Course Name को ट्रांज़िटिव निर्भरता बनाती है।
चरण 2: डेटा को नई टेबल्स में अलग करें
ट्रांज़िटिव निर्भरता को दूर करने के लिए, हम टेबल 1 को दो टेबल्स में विभाजित करेंगे। हर टेबल सीधे निर्भर डेटा पर केंद्रित होगी।
संशोधित enrollments टेबल
Courses टेबल
अब, प्रत्येक टेबल में केवल वही जानकारी है जो सीधे उसकी प्राइमरी की पर निर्भर करती है: Course ID अब Course Name के लिए Courses टेबल में प्राइमरी की है, और Enrollment ID Enrollments टेबल में प्राइमरी की है।
इस डीकंपोज़िशन के साथ, टेबल्स अब 3NF की आवश्यकताओं को पूरा करती हैं—पुनरावृत्ति समाप्त हो गई है और हर टेबल केवल सीधे सम्बद्ध जानकारी संग्रहीत करती है।
यदि आप स्वयं डेटाबेस बनाकर हाथ आज़माना चाहते हैं, तो हमारा Creating PostgreSQL Databases कोर्स देखें। यदि आप थोड़े उन्नत हैं, तो आप Introduction to Data Modeling in Snowflake आज़मा सकते हैं, जिसमें एंटिटी-रिलेशनशिप और डाइमेंशनल मॉडलिंग जैसी अवधारणाएँ शामिल हैं।
थर्ड नॉर्मल फॉर्म के लाभ और सीमाएँ
तो, 3NF तक पहुँचने के लिए यह सब मेहनत क्यों करें? मुख्य फायदे ये हैं:
यह कहा जा सकता है कि जहाँ 3NF संरचनाएँ डेटा की शुद्धता का समर्थन करती हैं, वहीं डेटा अधिक खंडित भी हो सकता है, जिससे अतिरिक्त टेबल जॉइन्स के कारण जटिल क्वेरीज़ कभी-कभी धीमी पड़ सकती हैं। जिन मामलों में गति की ज़रूरत नॉर्मलाइज़ेशन से अधिक महत्त्वपूर्ण हो, वहाँ BCNF या 4NF अधिक व्यावहारिक विकल्प हो सकते हैं।
तुलना: फर्स्ट, सेकंड, थर्ड और BC नॉर्मल फॉर्म्स
आइए फॉर्म्स के बीच के अंतर देखें।
तुलनात्मक सारणी: फर्स्ट, सेकंड और थर्ड नॉर्मल फॉर्म्स
यहाँ 1NF, 2NF और 3NF की आवश्यकताओं को समझने में मदद के लिए एक तुलना सारणी दी गई है।
BCNF, 3NF का एक “कड़ाई वाला” रूप है जो ओवरलैपिंग कैंडिडेट कीज़ के साथ उत्पन्न होने वाली विसंगतियों को और हटाता है। यह विशेष रूप से उन जटिल मामलों में उपयोगी हो सकता है जहाँ केवल 3NF सभी निर्भरताओं को पूरी तरह समाप्त नहीं करता। BCNF तब लागू होता है जब कोई नॉन-प्राइम एट्रिब्यूट, किसी ऐसे एट्रिब्यूट पर निर्भर हो जो किसी कॉम्पोज़िट कैंडिडेट की का हिस्सा हो। यह जटिल लगता है, इसलिए आइए इसे एक उदाहरण से सरल करें।
वर्तमान संरचना (3NF में)
3NF प्राप्त करने हेतु डीकंपोज़िशन के बाद, हमारे पास ये दो टेबल्स थीं:
Enrollments टेबल
Courses टेबल
इस संरचना में, प्रत्येक तालिका 3NF में है, कोई ट्रांजिटिव निर्भरता नहीं है, और डेटा उपयुक्त रूप से सामान्यीकृत है।
एक नई आवश्यकता प्रस्तुत करना
अब, Courses में एक नया गुण जोड़ते हैं: वह Classroom जिसमें प्रत्येक पाठ्यक्रम आयोजित होता है। यह नया गुण ऐसी स्थिति पैदा कर सकता है, जिसके लिए BCNF की आवश्यकता हो।
अद्यतन पाठ्यक्रम तालिका (3NF)
यहाँ, पाठ्यक्रम ID अभी भी प्राथमिक कुंजी है, और अन्य सभी गुण सीधे उसी पर निर्भर हैं। लेकिन मान लीजिए एक नया नियम है कि प्रत्येक कक्षा एक समय में केवल एक विषय ही रख सकती है। यह भी मान लें कि पाठ्यक्रम का नाम "SQL Fundamentals" अलग-अलग पाठ्यक्रम ID (जैसे 201, 204, आदि) के अंतर्गत पेश किया जा सकता है, यदि उन्हें अलग-अलग समय पर निर्धारित किया गया हो। उस स्थिति में, "SQL Fundamentals" की प्रत्येक पेशकश फिर भी "कक्ष 101" में ही आयोजित होगी, भले ही विशिष्ट पाठ्यक्रम ID कुछ भी हो। परिणामस्वरूप, पाठ्यक्रम का नाम भी अद्वितीय रूप से कक्षा को निर्धारित करता है।
इसका मतलब है कि अब हमारे पास दो प्रत्याशी कुंजियाँ हैं:
दोनों प्रत्याशी कुंजियों के साथ, अब हमारे पास एक समस्या है जिसका समाधान 3NF नहीं करता: कक्षा केवल पाठ्यक्रम ID पर नहीं, बल्कि पाठ्यक्रम के नाम पर निर्भर है।
BCNF लागू करना
इस निर्भरता समस्या को समाप्त करने के लिए, हमें Courses तालिका को और विखंडित करके दो अलग-अलग तालिकाओं में बाँटना होगा, जो BCNF के साथ बेहतर मेल खाती हों:
यह इस प्रकार दिखेगा:
संशोधित पाठ्यक्रम तालिका (BCNF)
CourseDetails तालिका (BCNF)
यह सेटअप परस्पर अतिव्यापी प्रत्याशी कुंजियों से पैदा हुई किसी भी निर्भरता समस्या को हटाता है और एक सख्ती से सामान्यीकृत संरचना सुनिश्चित करता है।
निष्कर्ष
थर्ड नॉर्मल फॉर्म उन डेटाबेस डिज़ाइनरों के लिए एक मूल्यवान साधन है जो डेटा को साफ, सुसंगत और समस्याग्रस्त निर्भरताओं से मुक्त रखना चाहते हैं। 3NF के साथ, डेटा अखंडता बेहतर होती है, प्रबंधन सुगम होता है और पुनरावृत्ति कम होती है। ध्यान रखें, जहाँ 3NF अधिकांश स्थितियों में अच्छा काम करता है, वहीं अधिक जटिल डेटाबेस BCNF या 4NF जैसी अतिरिक्त नॉर्मल फॉर्म्स से लाभान्वित हो सकते हैं।
यदि आपको यह लेख उपयोगी लगा, तो हमारा SQL Associate Certification अर्जित करके अगला कदम उठाने पर विचार करें। यह आपके SQL और डेटाबेस प्रबंधन कौशल को मान्य करने और संभावित नियोक्ताओं के सामने अपनी विशेषज्ञता प्रदर्शित करने का एक शानदार तरीका है!