एक उदाहरण के साथ 2NF बनाम 3NF की व्याख्या करना

Question

मुझे दूसरे सामान्य रूप (2NF) की समस्या है और मैं Google का उपयोग करके इसे हल करने में असमर्थ हूं। यह मुझे पागल बना रहा है क्योंकि मैं एक शिक्षक हूं और मैं अपने छात्रों को गलत चीजें नहीं सिखाना चाहता।

चलो 5 क्षेत्रों के साथ एक तालिका है।

ग्रेडिंग = {स्टूडेंटनाम, सब्जेक्टकोड, सब्जेक्टनेम, # एक्जाम, ग्रेड}

निर्भरताएं इस प्रकार हैं:

स्टूडेंटनेम, सब्जेक्टकोड, # एक्जाम -> ग्रेड

विषय -> विषय

विषय -> विषय

इसलिए, उम्मीदवार कुंजी 1 {StudentName, SubjectCode, #Exam} और उम्मीदवार कुंजी 2 है {StudentName, SubjectName, #Exam} ।

मुख्य विशेषताएँ {StudentName, SubjectCode, SubjectName, #Exam} और गैर-प्रमुख विशेषताएँ ग्रेड हैं

दूसरे सामान्य रूप की परिभाषा के अनुसार, एक गैर-प्रमुख विशेषता उम्मीदवार कुंजी के एक भाग पर निर्भर नहीं कर सकती है। एकमात्र गैर-प्रधान विशेषता (ग्रेड) एक उम्मीदवार कुंजी के एक भाग पर निर्भर नहीं करती है, इसलिए यह तालिका 2NF में लगती है।

समस्या यह है कि मुझे लगता है कि कुछ गलत है (और मैं गलत हो सकता है)। मुझे लगता है कि विषयों की अपनी तालिका होनी चाहिए।

ग्रेडिंग = {छात्रनाम, विषय कोड, # परीक्षा, ग्रेड}

विषय = {विषय कोड, विषय नाम}

लेकिन 2NF इसका उत्पादन नहीं करता है। 3NF गैर-प्रमुख विशेषताओं के बीच निर्भरता के बारे में है इसलिए यह इसका उत्पादन नहीं करता है। लेकिन मुझे लगता है कि यह सही परिणाम है, क्योंकि इसमें कोई अतिरेक नहीं है।

मुझे लगता है कि यदि गैर-प्रमुख विशेषता को "विशेषता जो उम्मीदवार कुंजी नहीं है" के रूप में परिभाषित किया गया था, तो 2NF वांछित परिणाम देगा। लेकिन मैंने इसे बार-बार जांचा है और गैर-प्रमुख विशेषता को "विशेषता के रूप में परिभाषित किया गया है जो एक उम्मीदवार की कुंजी से संबंधित नहीं है"।

मैं क्या गलत कर रहा हूं?

Answer 1

आपका संबंध 3NF में है, (और न केवल 2NF में), क्योंकि आप कहते हैं कि केवल गैर प्रमुख विशेषता ग्रेड है , जो केवल आपके FDs के दाईं ओर दिखाई देता है।

संबंध बीसीएनएफ में नहीं है, क्योंकि दो छोटे एफडी के बाएं हाथ एक सुपरकी नहीं है।

हालाँकि, आप ( SubjectCode , SubjectName ) और या तो ( StudentName, SubjectCode, #Exam, Grade ) या ( StudentName, SubjectName, #Exam, ग्रेड ) के संबंध को दोषपूर्ण रूप से विघटित कर सकते हैं

यह अपघटन आपको दो बीसीएनएफ संबंध देता है और सभी कार्यात्मक निर्भरता को संरक्षित करता है। यह हमेशा संभव नहीं होता है (आप हमेशा 3NF के संबंध को विघटित कर सकते हैं, लेकिन जरूरी नहीं कि BCNF को)।

2NF

यदि आप 2NF (और 3NF) का उदाहरण चाहते हैं, तो आपके संबंध में सकर्मक निर्भरताएँ होना आवश्यक है।

उदाहरण के लिए, मान लें कि आपके पास एक स्कोर कॉलम है। सहज रूप से स्कोर-> ग्रेड चूंकि सभी परीक्षाओं में एक ही स्कोर के साथ एक ही ग्रेड प्राप्त होना चाहिए (यह अन्यथा अनुचित होगा), लेकिन ध्यान दें कि हम ग्रेड नहीं कह सकते-> स्कोर क्योंकि कई अंकों में समान ग्रेड (11% और 12%) हो सकते हैं उदाहरण के लिए "विफल" होगा।

अब आपका रिश्ता है:

ग्रेडिंग ( छात्रनाम, विषय, विषय, विषय, # परीक्षा, अंक, ग्रेड )

और आपके पास अतिरेक का एक नया रूप है क्योंकि हर बार जब आप उसी स्कोर के साथ परिणाम दर्ज करते हैं तो एक और ग्रेडिंग रिकॉर्ड के साथ आपको संबंधित ग्रेड को भी दोहराना होगा। 3NF को पाने के लिए आप इसलिए विघटित हो सकते हैं

स्कोरग्रैड्स ( स्कोर, ग्रेड )

कुंजी के रूप में स्कोर के साथ , और

स्कोर ( स्टूडेंटनाम, सब्जेक्टकोड, सब्जेक्टनेम, # एक्जाम, स्कोर )

Answer 2

आप अपनी हर बात में सही हैं। विषय कोड, वांछित निर्भरता को लागू करने के लिए विषय को अपनी तालिका में जाने की आवश्यकता है। यह एक अच्छा उदाहरण है कि क्यों 2NF और 3NF अच्छे डेटाबेस डिजाइन का उत्पादन करने के लिए पर्याप्त नहीं हैं - आपको इसके बजाय बॉयस कॉड सामान्य फॉर्म (BCNF) की आवश्यकता है।

2NF और 3NF BCNF द्वारा अधिगृहीत किए जाते हैं जो व्यावहारिक रूप से बोलते हैं जो कम NF को अप्रचलित कर देते हैं *। बीसीएनएफ समझाने और लागू करने के लिए अधिक महत्वपूर्ण और यकीनन सरल है। एक शिक्षक के रूप में मेरा सुझाव है कि आप बीसीएनएफ पर अधिक समय व्यतीत करें और 2 एनएफ और 3 एनएफ पर कम। यदि कोई तालिका BCNF की आवश्यकताओं को पूरा करती है तो यह 2NF और 3NF को भी संतुष्ट करती है।

---

* 3NF उच्चतम निर्भरता-संरक्षण सामान्य रूप नहीं है। एलिमेंटरी की नॉर्मल फॉर्म (EKNF) है। कड़ाई से यह कहना EKNF है, BCNF नहीं, जो 3NF को अप्रचलित बनाता है, लेकिन EKNF अन्यायपूर्ण रूप से उपेक्षित है और अधिकांश पाठ्य पुस्तकों और पाठ्यक्रमों में इसका उल्लेख नहीं है। बीसीएनएफ को डिजाइन करने के लिए एक ही बात क्या है और फिर जांचें कि सभी वांछित निर्भरताएं और किसी भी अन्य अखंडता नियमों को ठीक से लागू किया जा सकता है - यदि नहीं, तो डिजाइन को संशोधित करें। NFs में से कोई भी डेटा अखंडता का एक पूर्ण समाधान नहीं है, लेकिन BCNF आम तौर पर निकटतम आता है और समझाने और उपयोग करने में सबसे आसान है।

Comments

क्या आपके पास ईकेएनएफ के लिए कोई अच्छा संदर्भ है, खासकर शुरुआत के लिए? मैं इस पर पढ़ने की कोशिश कर रहा हूं और इसके लिए अच्छे दस्तावेज ढूंढना मुश्किल साबित हुआ है। विकी से एक-लाइन सारांश के बाहर, ईकेएनएफ बनाम बीसीएनएफ / 3 एनएफ की सूक्ष्मताओं का एक काम कार्यात्मक विवरण मुझे अभी तक मुठभेड़ करना है।

— साज़ीन_नैब

Answer 3

मैं यह नहीं कहूंगा कि जब से मैंने पहली बार यह सब सीखा है, तब से यह कितना लंबा है। लेकिन मुझे याद है कि मेरे पास एक प्रोफेसर था, जिसने हमें "कार्यात्मक निर्भरता" और "गैर-प्रधान विशेषता" और अन्य सभी buzzwords के उचित अर्थों को सिखाने के बाद, हमें यह देखने के लिए सरल प्रश्नों की एक श्रृंखला दी कि क्या कोई विशेष सामान्य रूप तक पहुँच गया था। चलो देखते हैं कि क्या मुझे याद है कि अब तक ...

हमने उम्मीदवार कुंजी की पहचान कर ली है, इसलिए हम शेष गैर-प्रमुख विशेषताओं का यह प्रश्न पूछते हैं। इस मामले में, केवल एक है: ग्रेड।

पूरी तरह से न्यूनतम जानकारी क्या है हमें विशिष्ट रूप से ग्रेड की पहचान करने की आवश्यकता है? हमें छात्र, विषय और परीक्षा के बारे में जानना चाहिए। ठीक है, यह उम्मीदवार की चाबियों में से एक है।

EDIT: वीवीवी

लेकिन जवाब सिर्फ छात्र का नाम, विषय का नाम और परीक्षा हो सकता है। यह दूसरी उम्मीदवार कुंजी से मेल खाएगा।

यह मानते हुए कि SubjectCode और SubjectName दोनों Subject इकाई के लिए उम्मीदवार कुंजी हैं, दोनों क्षेत्रों के यहाँ होने का कोई कारण नहीं है। विषय तालिका में एक पंक्ति के लिए एक अद्वितीय संदर्भ काफी पर्याप्त है। इसलिए हम मॉडल के किसी भी अखंडता का त्याग किए बिना पूरी तरह से विषय क्षेत्र से छुटकारा पा सकते हैं।

हालांकि, अपने मूल उत्तर में, सामान्यीकरण के एक और स्तर को दिखाने की मेरी इच्छा में, मैंने इस बात को नजरअंदाज कर दिया कि सब्जेक्टनेम का उपयोग उम्मीदवार कुंजी में किया गया था और इसे सिर्फ एक और गैर-प्रमुख विशेषता माना। मुझे लगता है कि यह मेरे लिए इतना स्पष्ट था कि यह एक बेकार क्षेत्र था, मुझे लगा कि यह सभी के लिए बिल्कुल स्पष्ट होगा और किसी भी तरह से हमें मैदान से छुटकारा मिल गया, इससे क्या फर्क पड़ा?

लेकिन जवाब के उस हिस्से को हटाने के बजाय, मैं इसे तुलना के लिए रखूंगा।

END EDIT: ^ ^ ^

विषय न्यूनतम नाम को विशिष्ट रूप से पहचानने के लिए हमें न्यूनतम न्यूनतम जानकारी क्या है?

SubjectName केवल SubjectCode पर निर्भर है - उम्मीदवार कुंजी का सबसेट। तो यह टपल 2nf में नहीं है। SubjectCode Subjects तालिका की प्राथमिक कुंजी होनी चाहिए ताकि SubjectName को रखने के लिए उचित स्थान हो। इसे इस टपल से निकालें और यह अब 2nf में है।

यदि हम एक विशेषता का सवाल पूछते हैं और उत्तर सभी या उम्मीदवार कुंजी का हिस्सा नहीं है, तो ट्यूपल 3nf में नहीं है। लेकिन यह tuple 3nf और उससे आगे के क्षेत्र में भी तुच्छ है, क्योंकि हम खेतों से बाहर निकलकर सवाल पूछते हैं। ;)

नोट: जब हम कहते हैं कि "सामान्य करें", हम एक तार्किक इकाई पर लागू होने वाली प्रक्रिया का उल्लेख कर रहे हैं। जैसा कि आपूर्ति की गई टपल को "ग्रेड" नामक एक इकाई की परिभाषा प्रतीत होती है, तो हम इसे सामान्य कर सकते हैं। हालांकि, एक बिंदु पर मैंने कहा "यह ट्यूल 2nf में नहीं है," जो अधिक ठीक से होना चाहिए था, "यह इकाई 2nf में नहीं है।" अगर इससे भ्रम हुआ है तो मैं माफी चाहता हूं।

Answer 4

एकमात्र गैर-प्रधान विशेषता (ग्रेड) एक उम्मीदवार कुंजी के एक भाग पर निर्भर नहीं करती है, इसलिए यह तालिका 2NF में लगती है।

यह 2NF में है।

समस्या यह है कि मुझे लगता है कि कुछ गलत है (और मैं गलत हो सकता है)। मुझे लगता है कि विषयों की अपनी तालिका होनी चाहिए।

यह उम्मीद करने का कोई कारण नहीं है कि 2NF के लिए मूल तालिका के अपघटन के लिए विषयों की अपनी तालिका होनी चाहिए । आप "वगैरह" की कुछ अस्पष्ट धारणा को भ्रमित कर रहे हैं जो वास्तव में आपको कोई विशेष रूप देता है।

3NF गैर-प्रमुख विशेषताओं के बीच निर्भरता के बारे में है इसलिए यह इसका उत्पादन नहीं करता है।

"3NF गैर-प्रमुख विशेषताओं के बीच निर्भरता के बारे में है" 3NF की उचित परिभाषा नहीं है, इसलिए "यह या तो इसका उत्पादन नहीं करता है" ध्वनि निष्कर्ष नहीं है। हालांकि एक वास्तविक परिभाषा को लागू करने से पता चलता है कि तालिका 3NF में है, जिसकी कोई छात्र तालिका आवश्यक नहीं है। लेकिन फिर, उम्मीद करने का कोई कारण नहीं है कि वहाँ होगा।

लेकिन मुझे लगता है कि यह सही परिणाम है, क्योंकि इसमें कोई अतिरेक नहीं है।

फिर से, "अतिरेक" अस्पष्ट रूप से अस्पष्ट है, इसलिए आपकी "क्योंकि" और छात्र तालिका की उम्मीदें निराधार हैं। विभिन्न सामान्य रूप विशेष प्रकार की विसंगतियों और संबद्ध "अतिरेक" से मुक्त हैं। लेकिन सामान्यीकरण द्वारा संबोधित अन्य "अतिरेक" नहीं रह सकते हैं।

यह तालिका बीसीएनएफ में नहीं है, क्योंकि इसमें एफडी हैं जो सीके से बाहर नहीं हैं। इसे बीसीएनएफ के अनुसार प्रतिरूपित करने से छात्र तालिका प्राप्त करता है। बीसीएनएफ जेडी (एफडी पर निर्भरता) के साथ काम करने के लिए उच्चतम सामान्य रूप है जो एफडी के साथ होता है। हालांकि, अन्य जेडी समस्याग्रस्त हो सकते हैं (अर्थात "सीके द्वारा निहित" नहीं) और सामान्यीकरण द्वारा 5NF तक हटा दिया जाना चाहिए।

PS मूल तालिका भी FD {StudentName, SubjectName, #Exam} -> ग्रेड को संतुष्ट करती है।

निर्भरताएं इस प्रकार हैं:

इसका क्या मतलब है? यह स्पष्ट नहीं है।

क्या आपका मतलब है, "ये सभी गैर-तुच्छ एफडी हैं जो धारण करते हैं"? नहीं, क्योंकि वे चौथे का अर्थ करते हैं। "यहां कुछ एफडी हैं जो धारण करते हैं"? नहीं, इसका मतलब है कि सकर्मक क्लोजर होल्ड में एफडी है, लेकिन यह नहीं कहता है कि अन्य लोग होल्ड नहीं करते हैं, फिर भी आप सीके निर्धारित करने में सक्षम थे। "एफडी जो धारण करते हैं, वे इन के सकर्मक बंद होने की स्थिति में हैं"? यदि आपका मतलब है कि, आप इसे केवल तभी जान पाएंगे जब आपने इसे दिखाया था, अर्थात आपको वह बंद (आमतौर पर, न्यूनतम / विहित कवर के माध्यम से) मिल गया होगा और फिर दिखाया गया कि कोई अन्य एफडी नहीं हैं; क्या तुमने किया? बावजूद इसके, आपने जो लिखा है, उसका मतलब यह नहीं है। इसलिए मुझे उम्मीद है कि आप FD और CK स्थिति के बारे में उचित तर्क नहीं दे रहे हैं।

Answer 5

आप सही हैं, विषयों के लिए अपनी तालिका आवश्यक है। यदि आप अपनी एक उम्मीदवार कुंजी चुनते हैं, तो subject_codeया तो subject_nameएक गैर-प्राथमिक उम्मीदवार कुंजी बन जाती है। आप तब गैर-प्राथमिक विषय फ़ील्ड को ग्रेडिंग टेबल से हटा देते हैं।

आपके पास उस विषय पर एक कार्यात्मक निर्भरता है जिसके लिए आपके पास दो विशिष्ट पहचानकर्ता हैं। यह subject_codeऔर के बीच सकर्मक निर्भरता द्वारा प्रदर्शित होता है subject_name। यह उन दो फ़ील्ड वाली तालिका बनाने और अन्य सभी तालिकाओं में से एक फ़ील्ड को निकालने की आवश्यकता को इंगित करता है। इस तालिका में अतिरिक्त निर्भर स्तंभ हो सकते हैं, हालांकि मुझे इस उदाहरण में कोई नहीं दिखता है। तीसरे सामान्य रूप में आपने चुना है।

ग्रेड नए ग्रेडिंग टेबल में अन्य तीन क्षेत्रों (उम्मीदवार कुंजी) पर निर्भर करता है। जैसा कि ऊपर उल्लेख किया गया है कि आपको विषय तालिका के लिए एक उम्मीदवार फ़ील्ड चुनने की आवश्यकता है। आम तौर पर यह एक कोड मान होगा यदि उपलब्ध हो क्योंकि वे अधिक स्थिर होते हैं। परिणामस्वरूप मॉडल 3nf में है क्योंकि सभी गैर-कुंजी फ़ील्ड प्राथमिक कुंजी में फ़ील्ड पर पूरी तरह से निर्भर हैं।

समस्या (आवश्यकताओं) के आगे के विश्लेषण से सत्र तालिका प्राप्त करने की संभावना है जिसके खिलाफ अंक लगाए जाते हैं। वर्तमान मॉडल में पाठ्यक्रम दोहरा रहे छात्र को कवर करने की संभावना नहीं है। इसे बाद के पाठ में शामिल किया जाएगा।

छात्रों को भी एक अलग तालिका बनने की संभावना है क्योंकि एक ही नाम के साथ कई छात्रों के लिए संभव है। यह संभवतः एक सिंथेटिक प्राथमिक कुंजी (छात्र संख्या?) के अतिरिक्त द्वारा हल किया जाएगा।

subjects --->  sessions ---+--> grades
students  -----------------+

Comments

"यदि आप अपनी एक उम्मीदवार कुंजी चुनते हैं, तो या तो subject_code या subject_name एक गैर-प्राथमिक उम्मीदवार कुंजी बन जाता है ।" यह स्पष्ट रूप से गलत है। बाकी विश्लेषण में कुछ मूल्यवान बिंदु हैं लेकिन जब कोई गलत बिंदु से शुरू होता है, तो हम निष्कर्ष पर भरोसा नहीं कर सकते।

— ypercube y

Answer 6

मैं इसे हटाने की तैयारी कर रहा हूं क्योंकि इसे गलत माना जाता है

विषय का नाम भी एक गैर-प्रमुख विशेषता है और यह प्राथमिक कुंजी विषय कोड के नियम पर निर्भर करता है (नियम को तोड़ता है - प्राथमिक कुंजी पर किसी भी स्तंभ की आंशिक निर्भरता नहीं होनी चाहिए)।

यह 2nd नॉर्मल फॉर्म में निषिद्ध है और आपको संदेह होने पर इसे अपनी टेबल में रखना चाहिए।

मुझे लगता है कि जहां आप अनस्टक आए थे, उम्मीदवार कुंजी के दो सेटों की पहचान करने में है, जब आप तालिका बनाते हैं तो आपको प्राथमिक कुंजी बनाने के लिए उम्मीदवार कुंजी का एक सेट चुनना होगा। शेष कॉलम नॉन-प्राइम विशेषता बन जाते हैं, यानी यदि आपने अपनी दूसरी उम्मीदवार कुंजी को चुना है, तो सब्जेक्ट कोड प्राथमिक कुंजी (सब्जेक्ट नेम) के हिस्से पर निर्भर एक गैर-प्राइम विशेषता बन जाता है और इसे उसी तालिका में रखा जाना चाहिए।

जैसे ही वे एक-दूसरे पर निर्माण करते हैं, पहले, दूसरे और तीसरे सामान्य रूपों को सिखाना महत्वपूर्ण होता है। बीसीएनएफ भी अनिवार्य रूप से तीसरे सामान्य रूप का विस्तार है इसलिए निचले स्तरों पर एक मजबूत पकड़ आवश्यक है।

आगे की; एक अनुभवी डेवलपर सामान्यीकरण के स्वतंत्र स्तरों पर विचार नहीं करेगा क्योंकि कई नियम सहज हो जाते हैं।

वे यह भी जानेंगे कि कुछ डिज़ाइन और अनुकूलन समस्याओं को हल करने के लिए सामान्यीकरण नियमों को कब तोड़ना है। सामान्यीकरण को एक अच्छा नियम नहीं कड़े नियम के रूप में माना जाना चाहिए, मेरा मानना ​​है कि यह एक अच्छा शिक्षण बिंदु भी होगा।

Comments

ओपी सही ढंग से कहता है कि "उम्मीदवार कुंजी 2 है {StudentName, SubjectName, #Exam}।" तो, StudentNameएक प्रमुख विशेषता है।

— ypercube y 10

"जब आप तालिका बनाते हैं तो आपको प्राथमिक कुंजी बनाने के लिए उम्मीदवार कुंजी का एक सेट चुनना होगा। शेष कॉलम गैर-प्रमुख विशेषता बन जाते हैं। " यह स्पष्ट रूप से गलत है।

— ypercube y