Theory
इलाज, एक बार में एक कदम
Meera की गंदी table में तीनों anomalies हैं। इलाज, normalization, एक छलाँग नहीं बल्कि चरणों की एक सीढ़ी है जिन्हें normal forms कहते हैं: 1NF, फिर 2NF, फिर 3NF, फिर BCNF। हर कदम एक ख़ास तरह के ख़राब design को हटाता है जिसे आप अब पहचानते हैं।
आप इन्हें क्रम में चढ़ते हैं, एक table के 2NF में होने से पहले उसे 1NF में होना चाहिए, और इसी तरह। ऊपर तक, anomalies चले जाते हैं और हर तथ्य ठीक एक जगह रहता है। यह Unit 3 का भव्य समापन है, और एक पक्का exam सवाल।
Theory
एक कमरे को passes में साफ़ करना
आप एक गंदे कमरे को एक ही हरकत में साफ़ नहीं करते। पहला pass: हर ढीली चीज़ को उसकी अपनी जगह रखिए, कुछ भी ढेर में नहीं (1NF)। दूसरा pass: वे चीज़ें जो यहाँ सिर्फ आधी हैं उन्हें वहाँ ले जाइए जहाँ वे पूरी तरह से हैं (2NF)। तीसरा pass: उन चीज़ों को हटाइए जो असल में कमरे की किसी और चीज़ के बारे में हैं (3NF)। हर pass एक ख़ास तरह की गंदगी को निशाना बनाता है, और आप उन्हें हमेशा क्रम में करते हैं।
At a glance
normal-form सीढ़ी
| Form | हटाता है | नियम |
|---|---|---|
| 1NF | Multi-valued / composite cells | हर cell एक atomic value रखता है |
| 2NF | Partial dependency | 1NF + कोई non-key किसी composite key के हिस्से पर निर्भर नहीं |
| 3NF | Transitive dependency | 2NF + कोई non-key किसी दूसरे non-key को determine नहीं करता |
| BCNF | बचे determinant anomalies | हर determinant एक super key है |
Theory
सीढ़ियाँ चढ़ना
- 1NF: हर cell एक single atomic value रखता है। Meera का 'एक cell में तीन phone numbers' इसका उल्लंघन करता है; इलाज phones को उनकी अपनी rows/table में बाँटना। कोई repeating groups नहीं।
- 2NF: 1NF में और कोई partial dependency नहीं, कोई non-key attribute किसी composite key के सिर्फ हिस्से पर निर्भर नहीं। सिर्फ तब मायने रखता है जब key composite हो। इलाज: partial attribute को उसकी अपनी table में ले जाइए।
- 3NF: 2NF में और कोई transitive dependency नहीं, कोई non-key attribute किसी दूसरे non-key द्वारा determine नहीं (customer_id के ज़रिए customer_city)। इलाज: श्रृंखला को बाहर बाँटिए।
- BCNF: एक सख़्त 3NF, हर dependency X to Y के लिए, X एक super key होना चाहिए (हर determinant एक key है)।
Quiz
Meera की table एक item का supplier_city store करती है, जो supplier_id (एक non-key column) पर निर्भर है, table की key पर नहीं। कौन सा normal form इसे ठीक करता है, और कैसे?
- 3NF, transitive dependency को एक अलग Supplier table में हटाकर
- 1NF, cells को atomic बनाकर
- 2NF, एक partial dependency हटाकर
- यह पहले से पूरी तरह normalized है
Show the answer
3NF, transitive dependency को एक अलग Supplier table में हटाकर
supplier_city, supplier_id पर निर्भर है, एक non-key attribute, तो यह एक transitive dependency है, ठीक वही जो 3NF हटाता है। इलाज: supplier_id और supplier_city को उनकी अपनी Supplier table में ले जाइए, एक foreign key से वापस जुड़ी। 1NF atomic cells के बारे में है और 2NF एक composite key पर partial dependencies के बारे में, कोई भी एक non-key-determines-non-key श्रृंखला से मेल नहीं खाता।
Think first
2NF को composite key क्यों चाहिए
एक partial dependency का मतलब एक non-key attribute key के सिर्फ हिस्से पर निर्भर है। इसके बारे में सोचिए: अगर एक table की primary key एक अकेला column है, तो क्या एक partial dependency मौजूद भी हो सकती है? यह आपको क्या बताता है कि 2NF कब मायने रखता है?
Show the answer
नहीं, एक single-column key के 'हिस्से' नहीं होते जिन पर partially निर्भर हुआ जाए, तो एक single-column primary key वाली table जो पहले से 1NF में है अपने-आप 2NF में है। Partial dependencies सिर्फ एक composite key के साथ उठ सकती हैं (जैसे order_id + item_id), जहाँ एक column सिर्फ order_id पर निर्भर हो सकता है। तो 2NF सिर्फ तब असली काम करता है जब key composite हो, एक सूक्ष्म बिंदु जिसे examiners टटोलना पसंद करते हैं।
Watch out
Marks कहाँ कटते हैं
कौन सा form क्या ठीक करता है गड्डमड्ड करना: 1NF = atomic values, 2NF = कोई partial dependency नहीं (सिर्फ composite key), 3NF = कोई transitive dependency नहीं, BCNF = हर determinant एक super key है। यह भूलना कि forms संचयी हैं (2NF को 1NF चाहिए, आदि)। और नियम fix के बिना देना (एक जुड़ी table में decompose)। सीढ़ी का क्रम और हर form जो ख़ास dependency हटाता है, exam के मुख्य निशाने हैं।
Formula
Exam recipe: इस table को normalize कीजिए
ऊपर की ओर काम कीजिए, हर कदम दिखाते हुए: 1NF जाँचिए (atomic cells, किसी multi-valued को बाँटिए), फिर 2NF (partial dependencies हटाइए, सिर्फ अगर composite key), फिर 3NF (non-key columns के ज़रिए transitive dependencies हटाइए), हर कदम पर जो dependency आप ख़त्म करते हैं और जो नई table बनाते हैं उसका नाम देते हुए। BCNF अगर एक determinant एक key नहीं। हर चरण पर decomposition दिखाइए, वह किया हुआ प्रगति ही पूरे marks कमाता है।
Theory
Unit 3 पूरा, Meera तैयार है
Meera की अराजक sheet अब tables का एक साफ़ सेट है, Customers, Items, Suppliers, Orders, हर तथ्य एक जगह, anomalies चले गए। यह एक असली relational database design है। Unit 4 आख़िरकार उसे (और आपको) इससे SQL में बात करने देता है: ये tables बनाना, data insert करना, और सवाल पूछना। यहाँ आपने जो design किया वह अगला कुछ बन जाता है जिसे आप type करेंगे। आगे: SQL data types और CREATE statement।
Summary
Key takeaways
- Normal forms एक संचयी सीढ़ी हैं: हर एक को पिछला चाहिए।
- 1NF: हर cell एक single atomic value रखता है (कोई multi-valued या repeating cells नहीं)।
- 2NF: 1NF + कोई partial dependency नहीं (non-key किसी composite key के हिस्से पर निर्भर); सिर्फ composite keys के साथ मायने रखता है।
- 3NF: 2NF + कोई transitive dependency नहीं (non-key किसी दूसरे non-key द्वारा determine)।
- BCNF: सख़्त 3NF, हर determinant एक super key होना चाहिए।
- हर उल्लंघन को एक key से जुड़ी अलग table में decompose करके ठीक कीजिए।
- याद रखने का hook: कमरे को passes में साफ़ कीजिए, atomic, आधा-यहाँ, किसी-और-के-बारे-में।