कोर्स
डेटाबेस डिज़ाइन
4 घंटा
130.8K
डेटाबेस के साथ काम करते समय अनावश्यक दोहराव और असंगत अपडेट जैसी समस्याएँ आम हैं। सेकंड नॉर्मल फॉर्म डेटाबेस सामान्यीकरण का एक चरण है, जो फर्स्ट नॉर्मल फॉर्म (1NF) पर आधारित होकर तालिकाओं को अधिक स्वच्छ और कुशल बनाता है।
2NF को समझना डेटाबेस डिज़ाइन या डेटा प्रबंधन में काम करने वाले किसी भी व्यक्ति के लिए महत्वपूर्ण है, और यह थर्ड नॉर्मल फॉर्म (3NF) जैसी उच्चतर सामान्यीकरण अवस्थाओं की नींव रखता है। इस लेख में, हम देखेंगे कि 2NF कैसे काम करता है और व्यावहारिक उदाहरणों के साथ तालिकाओं को 2NF आवश्यकताओं के अनुरूप कैसे बदला जा सकता है। हम 2NF के लाभ, सीमाएँ और उपयुक्त उपयोग मामलों पर भी चर्चा करेंगे।
सेकंड नॉर्मल फॉर्म को समझना
सेकंड नॉर्मल फॉर्म डेटाबेस सामान्यीकरण का एक चरण है जो आंशिक निर्भरताओं को हटाने पर केंद्रित है। इसे रिलेशनल डेटाबेस के अग्रदूत एडगर एफ. कॉड ने सामान्यीकरण पर अपने कार्य के हिस्से के रूप में प्रस्तुत किया था।
किसी तालिका के 2NF में होने से पहले, उसे फर्स्ट नॉर्मल फॉर्म के नियमों को पूरा करना चाहिए:
- एटॉमिकिटी: प्रत्येक सेल में एक ही मान होना चाहिए (कोई दोहराए जाने वाले समूह या एरे नहीं)।
- अद्वितीय पंक्तियाँ: तालिका में स्पष्ट प्राइमरी की होनी चाहिए।
2NF एक अतिरिक्त नियम के साथ एक कदम और आगे जाता है: आंशिक निर्भरताओं को हटाएँ.
आंशिक निर्भरता तब होती है जब कोई नॉन-प्राइम विशेषता (ऐसा कॉलम जो किसी भी कैंडिडेट की का हिस्सा न हो) पूर्ण की के बजाय किसी कॉम्पोज़िट की के केवल एक हिस्से पर निर्भर होती है। 2NF का नियम सुनिश्चित करता है कि सभी नॉन-प्राइम विशेषताएँ पूरी प्राइमरी की पर निर्भर हों, केवल उसके हिस्से पर नहीं। यदि तालिका में आंशिक निर्भरताएँ बनी रहती हैं, तो डेटाबेस में दोहराव घुस सकता है, जिससे अक्षम्यता और अपडेट या डिलीट करते समय संभावित असंगतियाँ पैदा हो सकती हैं।
सिर्फ़ सिद्धांत थोड़ा रूखा लग सकता है, तो आइए एक व्यावहारिक उदाहरण देखते हैं।
नीचे कोर्स एनरोलमेंट की Datacamp छात्रों की तालिका दी गई है।
| Student ID | Course ID | Course Name | Instructor Name |
|---|---|---|---|
| 1001 | 201 | SQL Fundamentals | Ken Smith |
| 1002 | 202 | Introduction to Python | Merlin O’Donnell |
| 1001 | 202 | Introduction to Python | Merlin O’Donnell |
यहाँ, प्राइमरी की Student ID और Course ID का कॉम्पोज़िट है। लेकिन नॉन-प्राइम विशेषताएँ Course Name और Course Fee केवल Course ID पर निर्भर हैं, पूरी की पर नहीं। यह 2NF का उल्लंघन है।
2NF पाने के लिए तालिकाओं को डिकम्पोज़ करने के चरण
यह सुनिश्चित करने के लिए कि कोई तालिका 2NF के नियमों का पालन करती है, आपको ये करना होगा:
- सभी कैंडिडेट की पहचानें: उन न्यूनतम विशेषताओं के सेट का निर्धारण करें जो तालिका में पंक्तियों की अनूठी पहचान करते हैं। यही आपके कैंडिडेट की हैं।
- फंक्शनल डिपेंडेंसी निर्धारित करें: तालिका में सभी फंक्शनल डिपेंडेंसी की पहचान करें। विशेष रूप से, ऐसी निर्भरताएँ ढूँढें जिनमें नॉन-प्राइम विशेषताएँ (जो किसी भी कैंडिडेट की का हिस्सा नहीं हैं) कॉम्पोज़िट की के केवल एक हिस्से पर निर्भर हों।
- आंशिक निर्भरताएँ हटाएँ: हर आंशिक निर्भरता के लिए:
- निर्भर विशेषताओं को उस की के हिस्से के साथ नई तालिका में ले जाएँ, जिस पर वे निर्भर हैं।
- सुनिश्चित करें कि नई तालिका में एक अद्वितीय प्राइमरी की हो।
- दोहराएँ जब तक कोई आंशिक निर्भरता न रहे: पुष्टि करें कि सभी तालिकाओं में हर नॉन-प्राइम विशेषता अपनी संबंधित प्राइमरी की पर पूर्णतः निर्भर है।
व्यवहार में सेकंड नॉर्मल फॉर्म के उदाहरण
अब दो उदाहरण देखते हैं।
उदाहरण 1: कोर्स एनरोलमेंट तालिका
पहले, हमने निम्नलिखित कोर्स एनरोलमेंट तालिका देखी थी:
| Student ID | Course ID | Course Name | Instructor Name |
|---|---|---|---|
| 1001 | 201 | SQL Fundamentals | Ken Smith |
| 1002 | 202 | Introduction to Python | Merlin O’Donnell |
| 1001 | 202 | Introduction to Python | Merlin O’Donnell |
आइए, पिछले खंड में बताए गए चरणों का पालन करें।
1. हमारे कैंडिडेट की की पहचान करें।
इस मामले में, कैंडिडेट की Student ID और Course ID की कॉम्पोज़िट की है। यह अनूठा संयोजन तालिका की हर पंक्ति की पहचान करता है।
2. हमारी फंक्शनल डिपेंडेंसी निर्धारित करें
Course Name और Instructor Name पूरी कॉम्पोज़िट की (Student ID, Course ID) पर नहीं बल्कि Course ID पर निर्भर हैं। यह आंशिक निर्भरता है क्योंकि ये विशेषताएँ कॉम्पोज़िट की के केवल एक हिस्से पर निर्भर हैं।
3. आंशिक निर्भरताएँ हटाएँ
हमें उन विशेषताओं को, जो की के केवल एक हिस्से पर निर्भर हैं (Course Name और Instructor Name), एक नई तालिका में स्थानांतरित करना होगा जो केवल Course ID पर आधारित हो।
डिकम्पोज़िशन के बाद, हमारी नई तालिकाएँ इस प्रकार दिखती हैं:
कोर्स एनरोलमेंट तालिका
| Student ID | Course ID |
|---|---|
| 1001 | 201 |
| 1002 | 202 |
| 1001 | 202 |
कोर्स विवरण तालिका
| Course ID | Course Name | Instructor Name |
|---|---|---|
| 201 | SQL Fundamentals | Ken Smith |
| 202 | Introduction to Python | Merlin O’Donnell |
यदि आप खुद से अभ्यास करना चाहते हैं और अपने डेटाबेस बनाना चाहते हैं, तो हमारे PostgresQL कोर्स को देखें। यदि आप कुछ अधिक उन्नत हैं, तो आप यह Introduction to Data Modeling in Snowflake आज़मा सकते हैं, जिसमें एंटिटी-रिलेशनशिप और डायमेंशनल मॉडलिंग जैसे विचार शामिल हैं।
उदाहरण 2: ऑर्डर्स तालिका
हम इस ऑर्डर्स तालिका से शुरू करेंगे। ऊपर बताए गए चरणों का पालन करने की कोशिश करें और इस तालिका को स्वयं डिकम्पोज़ करें!
| Order ID | Product ID | Order Date | Product Name | Supplier Name |
|---|---|---|---|---|
| 1 | 201 | 2024-11-01 | Laptop | TechSupply |
| 1 | 202 | 2024-11-01 | Mouse | TechSupply |
| 2 | 201 | 2024-11-02 | Laptop | TechSupply |
| 3 | 203 | 2024-11-03 | Keyboard | KeyMasters |
1. हमारे कैंडिडेट की की पहचान करें
Order ID और Product ID का संयोजन हर पंक्ति की अनूठी पहचान करता है, जिससे (Order ID, Product ID) एक कॉम्पोज़िट कैंडिडेट की बनती है। कोई एकल कॉलम पंक्तियों की अनूठी पहचान नहीं कर सकता क्योंकि:
- Order ID अकेले अद्वितीय नहीं है, क्योंकि एक ही ऑर्डर में कई प्रोडक्ट हो सकते हैं।
- Product ID अकेले अद्वितीय नहीं है, क्योंकि वही प्रोडक्ट अलग-अलग ऑर्डर्स में आ सकता है।
इसका मतलब है कि (Order ID, Product ID) हमारी प्राइमरी की भी है।
2. हमारी फंक्शनल डिपेंडेंसी निर्धारित करें
Order Date पूरी कॉम्पोज़िट की पर नहीं बल्कि Order ID पर निर्भर है। यह आंशिक निर्भरता है।
Product Name और Supplier Name पूरी कॉम्पोज़िट की पर नहीं बल्कि Product ID पर निर्भर हैं। ये भी आंशिक निर्भरताएँ हैं।
3. आंशिक निर्भरताएँ हटाएँ
हमें तालिका को छोटे-छोटे भागों में बाँटना होगा, जिनमें से प्रत्येक एक तार्किक निर्भरता को संबोधित करे।
पहले, हम ऑर्डर संबंधी जानकारी के लिए एक तालिका बनाएँगे, जिसमें Order ID से संबंधित जानकारी होगी।
ऑर्डर्स तालिका
| Order ID | Order Date |
|---|---|
| 1 | 2024-11-01 |
| 2 | 2024-11-02 |
| 3 | 2024-11-03 |
फिर, हम एक ऐसी तालिका बनाएँगे जिसमें Product ID से संबंधित जानकारी होगी।
ऑर्डर्स तालिका
| Product ID | Product Name | Supplier Name |
|---|---|---|
| 201 | Laptop | TechSupply |
| 202 | Mouse | TechSupply |
| 203 | Keyboard | KeyMasters |
मूल तालिका अब केवल कॉम्पोज़िट की और ऑर्डर्स व प्रोडक्ट्स के बीच के संबंधों तक सीमित हो गई है।
| Order ID | Product ID |
|---|---|
| 1 | 201 |
| 1 | 202 |
| 2 | 201 |
| 3 | 203 |
अब हमारा डेटाबेस 2NF में है क्योंकि 1) सभी आंशिक निर्भरताएँ हटा दी गई हैं, और 2) नॉन-प्राइम विशेषताएँ अपनी संबंधित प्राइमरी की पर पूरी तरह निर्भर हैं।
सेकंड नॉर्मल फॉर्म कब लागू करें
तो, आपको अपना डेटाबेस 2NF में क्यों रीफ़ैक्टर करना चाहिए? क्या यह अपने आप में पर्याप्त है या आपको एक कदम आगे बढ़कर 3NF का लक्ष्य रखना चाहिए?
सेकंड नॉर्मल फॉर्म के लाभ और सीमाएँ
सेकंड नॉर्मल फॉर्म कई लाभ प्रदान करता है, जिससे यह डेटाबेस सामान्यीकरण प्रक्रिया में उपयोगी चरण बनता है:
- डेटा अखंडता में वृद्धि: आंशिक निर्भरताएँ हटाकर, 2NF इन्सर्शन, अपडेट और डिलीट विसंगतियों को कम करता है, जिससे डेटाबेस अधिक विश्वसनीय बनता है।
- दोहराव में कमी: 2NF डेटा दोहराव घटाता है, स्टोरेज उपयोग को अनुकूलित करता है और रखरखाव को सरल बनाता है।
- डेटा संरचना में सुधार: यह आगे के सामान्यीकरण, जैसे थर्ड नॉर्मल फॉर्म की ओर बढ़ने, के लिए स्वच्छ और अधिक कुशल डिज़ाइन तैयार करता है।
लेकिन इसकी कुछ सीमाएँ भी हैं:
- जटिलता में वृद्धि: 2NF पाने के लिए तालिकाओं का डिकम्पोज़िशन डिज़ाइन प्रक्रिया को अधिक जटिल बना सकता है, खासकर कॉम्पोज़िट की और निर्भरताओं के साथ।
- अतिरिक्त जोइन: तालिकाओं के विभाजन से क्वेरी में अधिक जोइन की आवश्यकता हो सकती है, जिससे बड़े डेटा सेट या जटिल क्वेरियों वाले सिस्टम में प्रदर्शन प्रभावित हो सकता है — नीचे इस पर और जानकारी है।
- अवशिष्ट दोहराव: 2NF आंशिक निर्भरताएँ घटाता है, लेकिन ट्रांज़िटिव निर्भरताओं को संबोधित नहीं करता; उन्हें 3NF में सुलझाया जाता है।
सेकंड नॉर्मल फॉर्म के साथ प्रदर्शन संबंधी विचार
आंशिक निर्भरताएँ हटाने के लिए तालिकाओं का डिकम्पोज़िशन सीधे डेटाबेस प्रदर्शन को प्रभावित कर सकता है। एक ओर, 2NF हासिल करने से डेटा दोहराव कम होता है और संगति बेहतर होती है, जिससे इन्सर्ट, अपडेट, या डिलीट के दौरान कम विसंगतियाँ होती हैं। दूसरी ओर, सामान्यीकरण तालिकाओं की संख्या बढ़ा सकता है, यानी संबंधित डेटा प्राप्त करते समय अतिरिक्त जोइन आवश्यक हो सकते हैं। बड़े डेटा सेट में इससे क्वेरी प्रदर्शन प्रभावित हो सकता है।
यह सुनिश्चित करने के लिए कि आपका सामान्यीकृत डेटाबेस तेज़ बना रहे, इन सर्वोत्तम प्रथाओं का पालन करें:
- इंडेक्सिंग: डिकम्पोज़्ड तालिकाओं के बीच जोइन को तेज़ करने के लिए इंडेक्स का उपयोग करें।
- क्वेरी अनुकूलन: अतिरिक्त जोइन की लागत कम करने के लिए क्वेरियों को अनुकूलित करें।
- हाइब्रिड दृष्टिकोण: जहाँ प्रदर्शन महत्वपूर्ण हो, जैसे रिपोर्टिंग तालिकाएँ, वहाँ सामान्यीकरण को डी-नॉर्मलाइज़ेशन के साथ मिलाएँ।
- नियमित निगरानी: प्रोफाइलिंग टूल्स के साथ अपने डेटाबेस प्रदर्शन का निरंतर मूल्यांकन करें ताकि संभावित समस्याएँ पकड़ में आएँ।
क्या 2NF सिर्फ़ थर्ड नॉर्मल फॉर्म तक पहुँचने का संक्रमणकालीन चरण है?
अधिकांश मामलों में, डेटाबेस डिज़ाइनर तीसरे नॉर्मल फॉर्म तक पहुँचने की कोशिश करते हैं क्योंकि यह दोहराव को और कम करता है और समग्र डेटा अखंडता में सुधार करता है। हालाँकि, 3NF हासिल करने में अक्सर अधिक तालिकाएँ और संबंध बनाना जैसे अतिरिक्त कार्य शामिल होते हैं, जो क्वेरी निष्पादन में जटिलता और प्रदर्शन-सम्बंधी समझौते ला सकते हैं।
ऐसे मामले भी हैं जहाँ केवल सेकंड नॉर्मल फॉर्म का उपयोग पर्याप्त हो सकता है। यदि सरलता और त्वरित कार्यान्वयन प्राथमिकताएँ हैं, जैसे छोटे प्रोजेक्ट्स, प्रोटोटाइपिंग, या जहाँ डेटा दोहराव न्यूनतम है, वहाँ 2NF पर्याप्त हो सकता है। उदाहरण के लिए, ऐसे सिस्टम में जहाँ सभी विशेषताएँ पहले से ही एक सरल प्राइमरी की पर पूरी तरह निर्भर हैं, 2NF हासिल करना आंशिक निर्भरता घटाने के प्राथमिक लक्ष्य को पूरा कर सकता है, आगे सामान्यीकरण की आवश्यकता के बिना।
सेकंड नॉर्मल फॉर्म से आगे: थर्ड नॉर्मल फॉर्म की ओर
यदि आप अपने डेटाबेस को और सामान्यीकृत करना चाहते हैं, तो आप तालिकाओं को रीफ़ैक्टर करते हुए थर्ड नॉर्मल फॉर्म तक पहुँचना जारी रख सकते हैं।
3NF 2NF पर आधारित है और ट्रांज़िटिव निर्भरताओं को संबोधित करता है — ऐसी स्थितियाँ जहाँ नॉन-की विशेषताएँ प्राइमरी की के बजाय अन्य नॉन-की विशेषताओं पर निर्भर होती हैं। यह प्रगति सुनिश्चित करती है कि हर विशेषता सीधे प्राइमरी की पर ही निर्भर हो।
उदाहरण के लिए, कोर्स एनरोलमेंट को ट्रैक करने वाली तालिका में:
- 2NF: सुनिश्चित करता है कि कोर्स नाम और छात्र नाम जैसी विशेषताएँ अपनी संबंधित प्राइमरी की (जैसे, Student ID और Course ID) पर पूरी तरह निर्भर हों। यह आंशिक निर्भरताएँ खत्म करता है, जहाँ नॉन-की विशेषताएँ कॉम्पोज़िट की के केवल एक हिस्से पर निर्भर होती हैं।
- 3NF: सुनिश्चित करता है कि इंस्ट्रक्टर विवरण या विभाग संबंधी जानकारी अलग तालिकाओं में संग्रहित हो, जिससे ट्रांज़िटिव निर्भरताएँ समाप्त हों।
3NF अधिक जटिल सिस्टम के लिए उपयुक्त है जहाँ डेटा अखंडता और दक्षता अत्यंत महत्वपूर्ण हैं, खासकर जैसे-जैसे डेटा की मात्रा बढ़ती है। यदि आप 3NF और उसकी अधिक प्रतिबंधात्मक अवस्था BCNF के बारे में और जानना चाहते हैं, तो हमारा थर्ड नॉर्मल फॉर्म क्या है? लेख देखें।
निष्कर्ष
सेकंड नॉर्मल फॉर्म डेटाबेस सामान्यीकरण का एक आवश्यक चरण है, जो 1NF और 3NF जैसी उच्चतर अवस्थाओं के बीच की दूरी को पाटता है। आंशिक निर्भरताएँ हटाकर, 2NF दोहराव घटाता है और आपके डेटा की विश्वसनीयता बढ़ाता है। यद्यपि यह कुछ जटिलता जोड़ सकता है, पर बेहतर डेटा अखंडता और सरल रखरखाव के लाभ इसे प्रभावी डेटाबेस डिज़ाइन का महत्वपूर्ण हिस्सा बनाते हैं।
यदि आप अपनी क्षमताएँ आगे बढ़ाने के लिए तैयार हैं, तो हमारे Database Design कोर्स को एक्सप्लोर करें, जिससे सामान्यीकरण तकनीकों और उनके व्यावहारिक अनुप्रयोगों की आपकी समझ गहरी होगी। आप हमारे SQL Associate Certification के साथ अपने SQL और डेटाबेस प्रबंधन कौशल को मान्य कर सकते हैं और संभावित नियोक्ताओं के सामने अपनी विशेषज्ञता प्रदर्शित कर सकते हैं!
अंत में, मैं यह कहना चाहता हूँ कि यदि आप किसी व्यवसाय में निर्णयकर्ता हैं और आपको पता है कि आपको और स्वच्छ, अधिक कुशल डेटाबेस बनाने पर काम करना है, तो DataCamp for Business डेमो का अनुरोध करने पर विचार करें। हम आपकी टीम की क्षमताओं को रूपांतरित करने में मदद कर सकते हैं ताकि आप ऐसे स्केलेबल डेटाबेस सिस्टम बना सकें जो व्यावसायिक दक्षता और नवाचार को आगे बढ़ाएँ। हम अनुकूलित लर्निंग पाथ और कस्टम ट्रैक्स भी बना सकते हैं।
Author
Marie Fayard
मैं एक प्रोडक्ट-उन्मुख टेक लीड हूं, जो शुरुआती चरण के स्टार्टअप्स को पहले प्रोटोटाइप से लेकर प्रोडक्ट–मार्केट फिट और उससे आगे तक बढ़ाने में विशेषज्ञता रखता/रखती हूं। मुझे यह जानने में गहरी दिलचस्पी है कि लोग तकनीक का उपयोग कैसे करते हैं, और मुझे संस्थापकों व क्रॉस-फ़ंक्शनल टीमों के साथ मिलकर साहसिक विचारों को साकार करना पसंद है। जब मैं प्रोडक्ट नहीं बना रहा/रही होता/होती, तब मैं दुनिया के नए कोनों में प्रेरणा की तलाश में रहता/रहती हूं या योग स्टूडियो में जाकर मन हल्का करता/करती हूं।
2NF से जुड़े सामान्य प्रश्न
क्या सेकंड नॉर्मल फॉर्म (2NF) को बिना कॉम्पोज़िट की वाले डेटाबेस पर लागू किया जा सकता है?
हाँ! यद्यपि 2NF में अक्सर कॉम्पोज़िट की शामिल होती हैं, सिंगल-की तालिकाएँ भी 2NF के सिद्धांतों का पालन कर सकती हैं, बशर्ते सभी नॉन-प्राइम विशेषताएँ प्राइमरी की पर पूरी तरह निर्भर हों।
क्या 2NF प्राप्त करने से डेटाबेस में सभी दोहराव समाप्त हो जाते हैं?
नहीं। 2NF आंशिक निर्भरताएँ हटाता है, लेकिन ट्रांज़िटिव निर्भरताओं को संबोधित नहीं करता। इसके लिए आपको थर्ड नॉर्मल फॉर्म (3NF) तक बढ़ना होगा।
क्या ऐसे हालात हैं जहाँ 1NF पर्याप्त होता है और 2NF तक बढ़ने की ज़रूरत नहीं पड़ती?
हाँ। बहुत सरल सिस्टमों या प्रोटोटाइप में, जहाँ डेटा दोहराव न्यूनतम होता है, 1NF पर्याप्त हो सकता है। सामान्यतः मैं 1NF पर रुकने की सलाह नहीं दूँगा/दूँगी जब तक आपके पास बहुत विशिष्ट और उचित कारण न हो।
2NF और थर्ड नॉर्मल फॉर्म (3NF) में क्या अंतर है?
2NF आंशिक निर्भरताएँ हटाता है, यह सुनिश्चित करते हुए कि विशेषताएँ पूरी की पर निर्भर हों। 3NF इससे आगे जाकर ट्रांज़िटिव निर्भरताएँ हटाता है, यह सुनिश्चित करते हुए कि विशेषताएँ सीधे प्राइमरी की पर निर्भर हों, अन्य नॉन-की विशेषताओं पर नहीं।
मैं कैसे जाँचूँ कि मेरा मौजूदा डेटाबेस पहले से 2NF में है या नहीं?
आप इसे उन सभी तालिकाओं की समीक्षा करके जाँच सकते हैं जिनमें कॉम्पोज़िट की हैं, और यह सत्यापित कर सकते हैं कि सभी नॉन-प्राइम विशेषताएँ पूरी कॉम्पोज़िट की पर निर्भर हैं, केवल किसी हिस्से पर नहीं।