Theory
नियमों के नीचे का नियम
पिछले lesson में आपने क्यों normalization मायने रखती है यह महसूस किया। पर इसे असल में करने को, सही से बाँटने को, आपको एक सटीक idea चाहिए: कौन सा column कौन सा तय करता है।
अगर आप एक student का roll number जानते हैं, आप उनका name जानते हैं, roll number name को determine करता है। यह एक functional dependency है, और हर normalization नियम उन्हें पहचानने पर बना है।
एक चालाक किस्म भी है, transitive dependency, जो छिपी redundancy पैदा करती है, और एक छोटी नियम-पुस्तिका, Armstrong's axioms, उनके बारे में सोचने को। यह lesson normal forms के पीछे की मशीनरी है।
Theory
एक चीज़ जानना आपको दूसरी बताता है
मुझे अपना PIN code बताइए और मैं आपको आपका city बता सकता हूँ, pincode city को determine करता है (एक pincode, एक city)। पर मुझे अपना city बताइए और मैं आपका pincode नहीं बता सकता (एक city के कई)। तो dependency की एक दिशा है: pincode city को determine करता है, उल्टा नहीं। Functional dependency ठीक यही है: बाईं तरफ की value जानना आपको दाईं तरफ ठीक एक value बताता है।
Theory
Functional dependency, औपचारिक रूप से
एक functional dependency को X to Y लिखा जाता है, 'X, Y को determine करता है' पढ़ा जाता है: X की हर value के लिए ठीक एक value of Y होती है।
roll_no to name (roll number जानना एक name देता है)
X determinant है (तय करने वाली तरफ)। एक primary key का पूरा मक़सद यह है कि यह अपनी row के हर दूसरे column को determine करती है।
एक partial dependency तब है जब एक column सिर्फ एक composite key के हिस्से पर निर्भर हो, एक समस्या जिसे 2NF ठीक करेगा। दिशा सही करना ही सब कुछ है: roll_no to name, कभी name to roll_no नहीं (names दोहराते हैं)।
Theory
Transitive dependency: छिपी श्रृंखला
एक transitive dependency एक non-key attribute के ज़रिए एक श्रृंखला है:
X to Y और Y to Z, तो X to Z अप्रत्यक्ष रूप से
Meera के orders में उदाहरण: order_id to customer_id (हर order का एक customer) और customer_id to customer_city (हर customer का एक city)। तो order_id to customer_city transitively, city order पर सिर्फ customer के ज़रिए निर्भर है।
यह बुरा है: city हर order पर redundantly store होता है। Third normal form (3NF) ठीक transitive dependencies हटाने के लिए मौजूद है।
Quiz
एक table में: roll_no to department, और department to hod (head of department)। कौन सी dependency roll_no को hod से जोड़ती है?
- Transitive dependency, roll_no, hod को सिर्फ department के THROUGH determine करता है
- बिना किसी समस्या के एक सीधी functional dependency
- एक composite key पर एक partial dependency
- कोई dependency ही नहीं
Show the answer
Transitive dependency, roll_no, hod को सिर्फ department के THROUGH determine करता है
roll_no, department को determine करता है, और department, hod को determine करता है, तो roll_no, hod को अप्रत्यक्ष रूप से, non-key attribute department के ज़रिए determine करता है: एक transitive dependency। यह HOD को department के हर student के लिए redundantly store कराता है। 3NF इसे department और उसके HOD को उनकी ख़ुद की table में बाँटकर हटाता है। A to B to C श्रृंखला पहचानना 3NF सवालों का मूल कौशल है।
Think first
Armstrong's तीन axioms
Armstrong's axioms dependencies के बारे में सोचने की नियम-पुस्तिका हैं। तीन प्राथमिक हैं Reflexivity, Augmentation, और Transitivity। क्या आप अंदाज़ा लगा सकते हैं कि Transitivity क्या कहती है, यह देखते हुए कि आपने इसे अभी ऊपर इस्तेमाल किया?
Show the answer
Transitivity: अगर X to Y और Y to Z, तो X to Z, ठीक roll_no to department to hod श्रृंखला। बाकी दो: Reflexivity (एक set अपने किसी भी subset को determine करता है, तुच्छ रूप से, अगर Y, X का हिस्सा है तो X to Y) और Augmentation (अगर X to Y, तो आप दोनों तरफ वही column जोड़ सकते हैं: XZ to YZ)। साथ में ये तीन (जमा union और decomposition जैसे derived नियम) sound और complete हैं: वे हर valid functional dependency निकाल सकते हैं। वे normalization के पीछे का औपचारिक engine हैं।
Watch out
Marks कहाँ कटते हैं
FD की दिशा गलत करना: X to Y का मतलब X, Y को determine करता है (determinant बाईं तरफ है)। transitive (X to Y to Z एक non-key attribute के ज़रिए) को एक सादी dependency से गड्डमड्ड करना, transitive वह ख़ास श्रृंखला है जो 3NF हटाता है। और जब पूछा जाए, Armstrong's तीन प्राथमिक axioms नाम दीजिए: reflexivity, augmentation, transitivity। इन्हें गड्डमड्ड करना, या एक dependency का arrow उल्टा करना, वहाँ है जहाँ marks चुपचाप गायब होते हैं।
Theory
अब normal forms समझ आते हैं
आप पूरी तरह लैस हैं। Partial dependency 2NF का दुश्मन है; transitive dependency 3NF का दुश्मन है; और आप जो भी split करते हैं वह एक functional dependency से justified होता है। अगला lesson 1NF से BCNF तक चलता है, और आप हर form को एक ख़ास तरह की बुरी dependency हटाते देखेंगे जिसे आप अब पहचानते हैं। यह theory वह वजह है कि normal forms बेतरतीब नहीं हैं। आगे: 1NF, 2NF, 3NF, BCNF।
Summary
Key takeaways
- एक functional dependency X to Y का मतलब X, Y को determine करता है (हर X के लिए एक Y); X determinant है, बाईं तरफ।
- Primary key अपनी row के हर दूसरे column को functionally determine करती है।
- Partial dependency: एक column सिर्फ एक composite key के हिस्से पर निर्भर (2NF का निशाना)।
- Transitive dependency: X to Y to Z एक non-key attribute के ज़रिए, तो X to Z अप्रत्यक्ष (3NF का निशाना)।
- Armstrong's axioms (reflexivity, augmentation, transitivity) FDs निकालने की sound, complete नियम-पुस्तिका हैं।
- याद रखने का hook: pincode, city को determine करता है (एक दिशा); A to B to C छिपी श्रृंखला पर नज़र रखिए।