- सामान्य आकार
- पहला सामान्य रूप (1FN)
- दूसरा सामान्य रूप (2FN)
- तीसरा सामान्य रूप (3FN)
- तीसरे सामान्य रूप के उदाहरण
- उदाहरण 1
- नई तालिका बनाएं
- उदाहरण 2
- संदर्भ
तीसरे सामान्य रूप (डेटाबेस) एक संबंधपरक डेटाबेस डिजाइन तकनीक है, जहां विभिन्न तालिकाओं कि रचना यह न केवल दूसरा सामान्य रूप के साथ पालन, लेकिन इसकी सभी विशेषताओं या क्षेत्रों प्राथमिक कुंजी पर सीधे निर्भर है।
डेटाबेस डिजाइन करते समय, मुख्य लक्ष्य डेटा का सटीक प्रतिनिधित्व, उनके बीच संबंधों और प्रासंगिक डेटा पर प्रतिबंध बनाना है।
स्रोत: pixabay.com
इस लक्ष्य को प्राप्त करने के लिए, कुछ डेटाबेस डिज़ाइन तकनीकों का उपयोग किया जा सकता है, जिनके बीच सामान्यीकरण है।
यह एक डेटाबेस में डेटा को व्यवस्थित करने की प्रक्रिया है, जो डेटा के सम्मिलन, अद्यतन या उन्मूलन में अतिरेक और संभावित विसंगतियों से बचने के लिए है, इस प्रकार वैचारिक मॉडल का एक सरल और स्थिर डिजाइन तैयार करता है।
यह विशेषताओं के बीच कार्यात्मक संबंध या निर्भरता की जांच करके शुरू होता है। ये डेटा की कुछ संपत्ति या उनके बीच संबंध का वर्णन करते हैं।
सामान्य आकार
सामान्यीकरण परीक्षणों की एक श्रृंखला का उपयोग करता है, जिन्हें सामान्य रूप कहा जाता है, इन विशेषताओं के इष्टतम समूह की पहचान करने में मदद करने के लिए और अंततः उन संबंधों के उचित सेट को स्थापित करने में मदद करता है जो किसी कंपनी की डेटा आवश्यकताओं का समर्थन करते हैं।
यही है, सामान्यीकरण तकनीक सामान्य रूप की अवधारणा के आसपास बनाई गई है, जो बाधाओं की एक प्रणाली को परिभाषित करती है। यदि कोई संबंध किसी विशेष सामान्य रूप की बाधाओं से मिलता है, तो संबंध उस सामान्य रूप में होना कहा जाता है।
पहला सामान्य रूप (1FN)
यदि किसी विशेषता या फ़ील्ड में केवल अनन्य मान हैं, तो तालिका को 1FN में कहा जाता है। अर्थात्, प्रत्येक विशेषता के लिए प्रत्येक मान अविभाज्य होना चाहिए।
परिभाषा के अनुसार, एक संबंधपरक डेटाबेस को हमेशा पहले सामान्य रूप में सामान्य किया जाएगा, क्योंकि विशेषता मान हमेशा परमाणु होते हैं। एक डेटाबेस में सभी रिश्ते 1FN में हैं।
हालाँकि, डेटाबेस को इस तरह छोड़ना कई समस्याओं को उत्तेजित करता है, जैसे अतिरेक और संभावित अपग्रेड विफलता। इन समस्याओं को ठीक करने के लिए उच्च सामान्य रूप विकसित किए गए थे।
दूसरा सामान्य रूप (2FN)
यह एक मेज से परिपत्र निर्भरता को हटाने से संबंधित है। एक संबंध 2 एफएन में कहा जाता है यदि यह 1 एफएन में है और इसके अलावा प्रत्येक गैर-कुंजी फ़ील्ड या विशेषता पूरी तरह से प्राथमिक कुंजी पर निर्भर करती है, या अधिक विशेष रूप से, यह सुनिश्चित करता है कि तालिका का एक ही उद्देश्य है।
एक गैर-कुंजी विशेषता किसी भी विशेषता है जो एक रिश्ते के लिए प्राथमिक कुंजी का हिस्सा नहीं है।
तीसरा सामान्य रूप (3FN)
यह एक मेज से सकर्मक निर्भरता को खत्म करने से संबंधित है। यही है, गैर-प्रमुख विशेषताओं को हटा दें जो प्राथमिक कुंजी पर निर्भर नहीं करते हैं, लेकिन किसी अन्य विशेषता पर।
एक सकर्मक निर्भरता एक प्रकार की कार्यात्मक निर्भरता है जिसमें एक गैर-कुंजी फ़ील्ड या विशेषता का मान किसी अन्य फ़ील्ड के मान से निर्धारित होता है जो कुंजी भी नहीं है।
आपको गैर-प्रमुख विशेषताओं में मूल्यों को दोहराने के लिए देखना चाहिए ताकि यह सुनिश्चित हो सके कि ये गैर-प्रमुख विशेषताएं प्राथमिक कुंजी के अलावा किसी अन्य चीज़ पर निर्भर नहीं करती हैं।
विशेषताओं को पारस्परिक रूप से स्वतंत्र कहा जाता है यदि उनमें से कोई भी कार्यात्मक रूप से दूसरों के संयोजन पर निर्भर नहीं है। यह पारस्परिक स्वतंत्रता सुनिश्चित करती है कि विशेषताओं को किसी अन्य विशेषता को प्रभावित करने के खतरे के बिना, व्यक्तिगत रूप से अपडेट किया जा सकता है।
इसलिए, डेटाबेस में किसी रिश्ते को तीसरे सामान्य रूप में होने के लिए, इसका अनुपालन करना चाहिए:
- 2FN की सभी आवश्यकताएँ।
- यदि ऐसी विशेषताएँ हैं जो प्राथमिक कुंजी से संबंधित नहीं हैं, तो उन्हें हटा दिया जाना चाहिए और एक अलग तालिका में रखा जाना चाहिए, दोनों तालिकाओं को विदेशी कुंजी के माध्यम से संबंधित करना। यही है, कोई भी निर्भरता नहीं होनी चाहिए।
तीसरे सामान्य रूप के उदाहरण
उदाहरण 1
तालिका को स्टूडेंट होने दें, जिसकी प्राथमिक कुंजी छात्र की पहचान (STUDENT_ID) है और यह निम्नलिखित विशेषताओं से बना है: 2FN होने के लिए शर्तों को पूरा करते हुए STUDENT_NAME, STREET, CITY और POST_CODE।
इस मामले में, STREET और CITY का प्राथमिक कुंजी STUDENT_ID के साथ सीधा संबंध नहीं है, क्योंकि वे सीधे छात्र से संबंधित नहीं हैं, लेकिन पूरी तरह से पोस्टल कोड पर निर्भर हैं।
जैसा कि छात्र CODE_POSTAL द्वारा निर्धारित साइट द्वारा स्थित है, STREET और CITY संबंधित हैं यह विशेषता के साथ है। निर्भरता की इस दूसरी डिग्री के कारण, इन विशेषताओं को छात्र तालिका में संग्रहीत करना आवश्यक नहीं है।
नई तालिका बनाएं
मान लीजिए कि एक ही ज़िप कोड में कई छात्र स्थित हैं, जिसमें स्टूडेंट टेबल के पास भारी मात्रा में रिकॉर्ड है, और इसके लिए गली या शहर का नाम बदलना आवश्यक है, तो इस सड़क या शहर को पूरी तालिका में ढूंढना और अपडेट करना होगा। छात्र।
उदाहरण के लिए, यदि आपको गली "एल लिमोन" को "एल लिमोन II" में बदलने की आवश्यकता है, तो आपको पूरे छात्र तालिका में "एल लिमोन" की खोज करनी होगी और फिर इसे "एल लिमोन II" में अपडेट करना होगा।
एक विशाल तालिका में खोज करना और एकल या एकाधिक रिकॉर्ड को अपडेट करने में लंबा समय लगेगा और इसलिए डेटाबेस के प्रदर्शन को प्रभावित करेगा।
इसके बजाय, इन विवरणों को एक अलग तालिका (POSTCARD) में रखा जा सकता है जो POST_CODE विशेषता का उपयोग करके छात्र तालिका से संबंधित है।
POST तालिका में तुलनात्मक रूप से कम रिकॉर्ड होंगे और इस POST तालिका को केवल एक बार अपडेट करने की आवश्यकता होगी। यह डेटाबेस और प्रश्नों को सरल बनाते हुए, स्वचालित रूप से छात्र तालिका में परिलक्षित होगा। तो टेबल 3 एफएन में होंगे:
उदाहरण 2
निम्न तालिका को प्राथमिक कुंजी के रूप में Project_Num फ़ील्ड के साथ और उन विशेषताओं में बार-बार मान के साथ उपयोग किया जाए जो कुंजियाँ नहीं हैं।
प्रत्येक बार जब प्रबंधक का नाम दोहराया जाता है, तो टेलीफोन मूल्य दोहराया जाता है। ऐसा इसलिए है क्योंकि फोन नंबर में केवल प्रोजेक्ट नंबर पर दूसरी डिग्री निर्भरता है। यह वास्तव में पहले प्रबंधक पर निर्भर करता है, और यह बदले में परियोजना की संख्या पर निर्भर करता है, जो एक सकरात्मक निर्भरता बनाता है।
Project_Manager विशेषता प्रोजेक्ट्स तालिका में संभावित कुंजी नहीं हो सकती क्योंकि एक ही प्रबंधक एक से अधिक प्रोजेक्ट का प्रबंधन करता है। इसका समाधान एक अलग तालिका बनाते हुए दोहराया डेटा (फोन) के साथ विशेषता को निकालना है।
संबंधित विशेषताओं को एक साथ समूहीकृत किया जाना चाहिए, जिससे उन्हें बचाने के लिए एक नई तालिका बनाई जा सके। डेटा दर्ज किया गया है और यह सत्यापित है कि दोहराया मान प्राथमिक कुंजी का हिस्सा नहीं हैं। प्राथमिक कुंजी प्रत्येक तालिका के लिए सेट की जाती है और यदि आवश्यक हो, तो विदेशी कुंजी जोड़ दी जाती है।
तीसरे सामान्य रूप का पालन करने के लिए, समस्या को हल करने के लिए एक नई तालिका (प्रबंधक) बनाई गई है। दोनों तालिका Project_Manager फ़ील्ड के माध्यम से संबंधित हैं:
संदर्भ
- टेराडाटा (2019)। पहला, दूसरा, और तीसरा सामान्य रूप। से लिया गया: docs.teradata.com
- ट्यूटोरियल कप (2019)। तीसरा सामान्य रूप (3NF)। से लिया गया: tutorialcup.com।
- डेटाबेस देव (2015)। तीसरा सामान्य रूप (3NF) - अपने डेटाबेस को सामान्य बनाना। से लिया गया: databasedev.co.uk
- रिलेशनल डीबी डिज़ाइन (2019)। थर्ड नॉर्मल फॉर्म का परिचय। से लिया गया: relationaldbdesign.com
- डमीज़ (2019)। SQL फर्स्ट, सेकंड और थर्ड नॉर्मल फॉर्म। से लिया गया: dummies.com