सामान्यीकरण (या सामान्यीकरण) क्या है?
जवाबों:
सामान्यीकरण मूल रूप से एक डेटाबेस स्कीमा को डिजाइन करने के लिए है ताकि डुप्लिकेट और निरर्थक डेटा से बचा जा सके। यदि डेटा के कुछ टुकड़े को डेटाबेस में कई स्थानों पर डुप्लिकेट किया जाता है, तो जोखिम है कि इसे एक स्थान पर अपडेट किया जाता है, लेकिन दूसरे को नहीं, जिससे डेटा भ्रष्टाचार होता है।
1. सामान्य रूप से सामान्यीकरण स्तरों की संख्या होती है। 5. सामान्य रूप। प्रत्येक सामान्य रूप बताता है कि कैसे कुछ विशिष्ट समस्या से छुटकारा पाया जाए, आमतौर पर अतिरेक से संबंधित।
कुछ सामान्य सामान्यीकरण त्रुटियां:
(1) सेल में एक से अधिक मान होना। उदाहरण:
UserId | Car
---------------------
1 | Toyota
2 | Ford,Cadillac
यहां "कार" कॉलम (जो एक स्ट्रिंग है) में कई मान हैं। यह पहला सामान्य रूप है, जो कहता है कि प्रत्येक सेल का केवल एक मूल्य होना चाहिए। हम इस समस्या को दूर कर सकते हैं प्रति कार की एक अलग पंक्ति:
UserId | Car
---------------------
1 | Toyota
2 | Ford
2 | Cadillac
एक सेल में कई मान होने के साथ समस्या यह है कि यह अद्यतन करने के लिए मुश्किल है, खिलाफ क्वेरी करने के लिए मुश्किल है, और आप अनुक्रमित, बाधाओं और इतने पर लागू नहीं कर सकते हैं।
(2) अनावश्यक गैर-कुंजी डेटा (यानी। डेटा को कई पंक्तियों में अनावश्यक रूप से दोहराया गया)। उदाहरण:
UserId | UserName | Car
-----------------------
1 | John | Toyota
2 | Sue | Ford
2 | Sue | Cadillac
यह डिज़ाइन एक समस्या है क्योंकि प्रत्येक कॉलम में नाम दोहराया जाता है, भले ही नाम हमेशा UserId द्वारा निर्धारित किया गया हो। यह एक पंक्ति में सू के नाम को बदलने के लिए सैद्धांतिक रूप से संभव बनाता है और दूसरे में नहीं, जो डेटा भ्रष्टाचार है। दो में तालिका को विभाजित करने और एक प्राथमिक कुंजी / विदेशी कुंजी संबंध बनाने से समस्या हल हो जाती है:
UserId(FK) | Car UserId(PK) | UserName
--------------------- -----------------
1 | Toyota 1 | John
2 | Ford 2 | Sue
2 | Cadillac
अब ऐसा लग सकता है कि हमारे पास अभी भी अनावश्यक डेटा है क्योंकि UserId के दोहराए गए हैं; हालांकि पीके / एफके बाधा सुनिश्चित करता है कि मूल्यों को स्वतंत्र रूप से अपडेट नहीं किया जा सकता है, इसलिए अखंडता सुरक्षित है।
क्या यह महत्वपूर्ण है? हाँ, यह बहुत है महत्वपूर्ण है। सामान्यीकरण त्रुटियों वाली डेटाबेस होने से, आप डेटाबेस में अमान्य या दूषित डेटा प्राप्त करने का जोखिम खोलते हैं। चूंकि डेटा "हमेशा के लिए रहता है" यह भ्रष्ट डेटा से छुटकारा पाने के लिए बहुत कठिन है जब पहली बार डेटाबेस में प्रवेश किया है।
सामान्यीकरण से डरें नहीं । सामान्यीकरण के स्तर की आधिकारिक तकनीकी परिभाषाएँ बहुत ही अप्रिय हैं। यह इसे सामान्य बनाता है जैसे कि एक सामान्य गणितीय प्रक्रिया है। हालाँकि, सामान्यीकरण मूल रूप से सामान्य ज्ञान है, और आप पाएंगे कि यदि आप सामान्य ज्ञान का उपयोग करके एक डेटाबेस स्कीमा डिज़ाइन करते हैं तो यह आमतौर पर पूरी तरह से अनुकूलित हो जाएगा।
सामान्यीकरण के आसपास कई तरह की भ्रांतियां हैं:
कुछ का मानना है कि सामान्यीकृत डेटाबेस धीमा है, और निरूपण प्रदर्शन में सुधार करता है। यह बहुत विशेष मामलों में ही सही है। आमतौर पर एक सामान्यीकृत डेटाबेस भी सबसे तेज़ होता है।
कभी-कभी सामान्यीकरण को एक क्रमिक डिजाइन प्रक्रिया के रूप में वर्णित किया जाता है और आपको "कब रोकना है" यह तय करना होगा। लेकिन वास्तव में सामान्यीकरण स्तर केवल विभिन्न विशिष्ट समस्याओं का वर्णन करते हैं। तीसरी एनएफ के ऊपर सामान्य रूपों द्वारा हल की गई समस्या पहली जगह में काफी दुर्लभ समस्याएं हैं, इसलिए संभावना है कि आपका स्कीमा पहले से ही 5NF में है।
क्या यह डेटाबेस के बाहर कुछ भी लागू होता है? सीधे नहीं, नहीं। संबंधपरक डेटाबेस के लिए सामान्यीकरण के सिद्धांत काफी विशिष्ट हैं। हालांकि सामान्य अंतर्निहित विषय - कि आपके पास डुप्लिकेट डेटा नहीं होना चाहिए यदि विभिन्न उदाहरण सिंक से बाहर निकल सकते हैं - मोटे तौर पर लागू किया जा सकता है। यह मूल रूप से DRY सिद्धांत है ।
के नियम सामान्यीकरण के (स्रोत: अज्ञात)
सबसे महत्वपूर्ण बात यह है कि डेटाबेस रिकॉर्ड से दोहराव को हटाने के लिए कार्य करता है। उदाहरण के लिए यदि आपके पास एक से अधिक स्थान (टेबल) हैं, जहां किसी व्यक्ति का नाम आ सकता है, तो आप नाम को एक अलग तालिका में ले जाएं और इसे हर जगह संदर्भित करें। इस तरह यदि आपको बाद में व्यक्ति का नाम बदलने की आवश्यकता है तो आपको इसे केवल एक स्थान पर बदलना होगा।
यह उचित डेटाबेस डिजाइन के लिए महत्वपूर्ण है और सिद्धांत रूप में आपको इसे अपने डेटा अखंडता को बनाए रखने के लिए जितना संभव हो उतना उपयोग करना चाहिए। हालाँकि, कई तालिकाओं से जानकारी प्राप्त करते समय आप कुछ प्रदर्शन खो रहे हैं और इसीलिए कभी-कभी आप प्रदर्शन महत्वपूर्ण अनुप्रयोगों में उपयोग किए जाने वाले डेटाबेस तालिका (जिसे चपटा भी कहा जाता है) देख सकते हैं।
मेरी सलाह है कि सामान्य डिग्री की अच्छी डिग्री के साथ शुरुआत करें और केवल डी-सामान्यकरण करें जब वास्तव में जरूरत हो
PS भी इस लेख की जाँच करें: http://en.wikipedia.org/wiki/Database_normalization इस विषय पर और अधिक पढ़ने के लिए और तथाकथित सामान्य रूपों के बारे में
सामान्यकरण एक तालिका में स्तंभों के बीच अतिरेक और कार्यात्मक निर्भरता को खत्म करने के लिए इस्तेमाल की जाने वाली प्रक्रिया।
आम तौर पर कई सामान्य रूप मौजूद होते हैं, जिन्हें आमतौर पर एक संख्या द्वारा दर्शाया जाता है। अधिक संख्या का मतलब कम अतिरेक और निर्भरता है। कोई भी SQL टेबल 1NF (पहले सामान्य रूप में, बहुत ज्यादा परिभाषा के अनुसार) सामान्य करने का मतलब है स्कीमा को बदलना (अक्सर टेबल को विभाजित करना) एक प्रतिवर्ती तरीके से, एक मॉडल देता है जो कम अतिरेक और निर्भरता के साथ कार्यात्मक रूप से समान है।
डेटा की अतिरेक और निर्भरता अवांछनीय है क्योंकि यह डेटा को संशोधित करते समय विसंगतियों को जन्म दे सकता है।
इसका उद्देश्य डेटा की अतिरेक को कम करना है।
अधिक औपचारिक चर्चा के लिए, विकिपीडिया देखें http://en.wikipedia.org/wiki/Database_normalization देखें
मैं कुछ हद तक सरल उदाहरण दूंगा।
एक संगठन के डेटाबेस को मान लें जिसमें आमतौर पर परिवार के सदस्य होते हैं
id, name, address
214 Mr. Chris 123 Main St.
317 Mrs. Chris 123 Main St.
के रूप में सामान्य किया जा सकता है
id name familyID
214 Mr. Chris 27
317 Mrs. Chris 27
और एक परिवार की मेज
ID, address
27 123 Main St.
निकट-पूर्ण सामान्यीकरण (बीसीएनएफ) आमतौर पर उत्पादन में उपयोग नहीं किया जाता है, लेकिन एक मध्यवर्ती कदम है। एक बार आपने डेटाबेस को बीसीएनएफ में डाल दिया, तो अगला कदम आमतौर पर प्रश्नों को गति देने और कुछ सामान्य आवेषणों की जटिलता को कम करने के लिए इसे तार्किक तरीके से डी-सामान्य करना है। हालाँकि, आप इसे पहले ठीक से सामान्य किए बिना अच्छी तरह से नहीं कर सकते।
विचार यह है कि निरर्थक जानकारी एकल प्रविष्टि में कम हो जाती है। यह विशेष रूप से पतों जैसे क्षेत्रों में उपयोगी है, जहां श्री क्रिस अपना पता यूनिट -7 123 मेन सेंट और श्रीमती क्रिस के रूप में प्रस्तुत करते हैं, सुइट -7 123 मेन स्ट्रीट को सूचीबद्ध करते हैं, जो मूल तालिका में दो अलग-अलग पते के रूप में दिखाई देंगे।
आमतौर पर, तकनीक का उपयोग दोहराया तत्वों को खोजने के लिए किया जाता है, और उन क्षेत्रों को अद्वितीय आईडी के साथ एक अन्य तालिका में अलग कर दिया जाता है और दोहराया तत्वों को नई तालिका को संदर्भित करने वाली प्राथमिक कुंजी के साथ प्रतिस्थापित किया जाता है।
कोटिंग CJ दिनांक: सिद्धांत व्यावहारिक है।
सामान्यीकरण से प्रस्थान आपके डेटाबेस में कुछ विसंगतियों के परिणामस्वरूप होगा।
फर्स्ट नॉर्मल फॉर्म से डिपॉज़िट करने से ऐक्सेस विसंगतियों का कारण बनेगी, जिसका अर्थ है कि आपको अलग-अलग मूल्यों को विघटित करना और स्कैन करना होगा ताकि आप जो खोज रहे हैं वह मिल जाए। उदाहरण के लिए, यदि मानों में से एक स्ट्रिंग "फोर्ड, कैडिलैक" है जैसा कि पहले की प्रतिक्रिया द्वारा दिया गया है, और आप "फोर्ड" के सभी समुद्रों की तलाश कर रहे हैं, तो आपको स्ट्रिंग को खोलने और देखने के लिए चलना होगा। सबस्ट्रिंग। यह कुछ हद तक, रिलेशनल डेटाबेस में डेटा को स्टोर करने के उद्देश्य को पराजित करता है।
फर्स्ट नॉर्मल फॉर्म की परिभाषा 1970 से बदल गई है, लेकिन उन अंतरों के लिए आपको चिंता करने की जरूरत नहीं है। यदि आप रिलेशनल डेटा मॉडल का उपयोग करके अपनी एसक्यूएल टेबल्स को डिज़ाइन करते हैं, तो आपकी टेबलें स्वचालित रूप से 1NF में होंगी।
सेकंड नॉर्मल फॉर्म और उससे आगे के डिपॉजिट्स के कारण अपडेट विसंगतियां होंगी, क्योंकि एक ही तथ्य एक से अधिक स्थानों पर संग्रहित होता है। ये समस्याएं अन्य तथ्यों को संग्रहीत किए बिना कुछ तथ्यों को संग्रहीत करना असंभव बनाती हैं जो मौजूद नहीं हो सकती हैं, और इसलिए उन्हें आविष्कार करना होगा। या जब तथ्य बदल जाते हैं, तो आपको उन सभी मैदानों का पता लगाना पड़ सकता है जहाँ कोई तथ्य संग्रहीत होता है और उन सभी स्थानों को अद्यतन करता है, ऐसा न हो कि आप एक डेटाबेस के साथ समाप्त हो जाएँ जो स्वयं विरोधाभासी हो। और, जब आप डेटाबेस से एक पंक्ति को हटाने के लिए जाते हैं, तो आप पा सकते हैं कि यदि आप करते हैं, तो आप केवल उसी जगह को हटा रहे हैं जहां एक तथ्य जो अभी भी आवश्यक है वह संग्रहीत है।
ये तार्किक समस्याएं हैं, प्रदर्शन समस्याएं या अंतरिक्ष समस्याएं नहीं हैं। कभी-कभी आप सावधानीपूर्वक प्रोग्रामिंग करके इन अपडेट विसंगतियों के आसपास पहुँच सकते हैं। कभी-कभी (अक्सर) सामान्य रूपों का पालन करके पहली जगह में समस्याओं को रोकना बेहतर होता है।
पहले से ही कहे गए मूल्य के बावजूद, यह उल्लेख किया जाना चाहिए कि सामान्यीकरण नीचे अप दृष्टिकोण है, न कि ऊपर नीचे दृष्टिकोण। यदि आप डेटा के अपने विश्लेषण में कुछ पद्धतियों का पालन करते हैं, और आपके आंतरिक डिजाइन में, आपको गारंटी दी जा सकती है कि डिजाइन कम से कम 3NF के अनुरूप होगा। कई मामलों में, डिजाइन पूरी तरह से सामान्यीकृत हो जाएगा।
जहां आप वास्तव में सामान्यीकरण के तहत सिखाई गई अवधारणाओं को लागू करना चाहते हैं, जब आपको विरासत डेटा दिया जाता है, एक विरासत डेटाबेस से बाहर या रिकॉर्ड से बनी फाइलों से बाहर, और डेटा को सामान्य रूपों और प्रस्थान के परिणामों की पूर्ण अज्ञानता में डिजाइन किया गया था उनसे। इन मामलों में आपको सामान्यीकरण से प्रस्थान की खोज करने और डिज़ाइन को सही करने की आवश्यकता हो सकती है।
चेतावनी: सामान्यीकरण को अक्सर धार्मिक ओवरटोन के साथ सिखाया जाता है, जैसे कि पूर्ण सामान्यीकरण से प्रत्येक प्रस्थान एक पाप है, जो कोडड के खिलाफ अपराध है। (वहाँ थोड़ा सा दंड)। कि खरीद मत करो। जब आप वास्तव में, वास्तव में डेटाबेस डिज़ाइन सीखते हैं, तो आप न केवल नियमों का पालन करना जानेंगे, बल्कि यह भी जान पाएंगे कि उन्हें तोड़ना कब सुरक्षित है।
सामान्यीकरण बुनियादी अवधारणाओं में से एक है। इसका अर्थ है कि दो चीजें एक-दूसरे पर प्रभाव नहीं डालती हैं।
डेटाबेस में विशेष रूप से इसका मतलब है कि दो (या अधिक) तालिकाओं में समान डेटा नहीं है, अर्थात कोई अतिरेक नहीं है।
पहली नजर में यह वास्तव में अच्छा है क्योंकि कुछ तुल्यकालन समस्याओं को बनाने की आपकी संभावना शून्य के करीब है, आप हमेशा जानते हैं कि आपका डेटा कहां है, आदि लेकिन, शायद, आपकी तालिकाओं की संख्या बढ़ेगी और आपको डेटा पार करने में समस्या होगी। और कुछ सारांश परिणाम प्राप्त करने के लिए।
तो, अंत में आप डेटाबेस डिज़ाइन के साथ समाप्त करेंगे जो शुद्ध सामान्यीकृत नहीं है, कुछ अतिरेक के साथ (यह सामान्यीकरण के कुछ संभावित स्तरों में होगा)।
सामान्यीकरण क्या है?
सामान्यीकरण एक चरण वार औपचारिक प्रक्रिया है जो हमें डेटाबेस तालिकाओं को इस तरह से विघटित करने की अनुमति देती है, जिससे डेटा अतिरेक और विसंगतियों को अपडेट किया जा सके। को कम से कम किया जा सके।
सामान्यीकरण प्रक्रिया शिष्टाचार
पहला सामान्य रूप यदि और केवल तभी यदि प्रत्येक विशेषता के डोमेन में केवल परमाणु मान शामिल हैं (एक परमाणु मान एक ऐसा मान है जिसे विभाजित नहीं किया जा सकता है), और प्रत्येक विशेषता के मूल्य में उस डोमेन से केवल एक ही मान होता है (उदाहरण: - डोमेन के लिए लिंग स्तंभ है: "M", "F"।)।
पहला सामान्य रूप इन मानदंडों को लागू करता है:
- व्यक्तिगत तालिकाओं में दोहराए जाने वाले समूहों को हटा दें।
- संबंधित डेटा के प्रत्येक सेट के लिए एक अलग तालिका बनाएं।
- प्राथमिक कुंजी के साथ संबंधित डेटा के प्रत्येक सेट को पहचानें
दूसरा सामान्य रूप = 1NF + कोई आंशिक निर्भरता नहीं है। सभी गैर-कुंजी विशेषताएँ प्राथमिक कुंजी पर पूरी तरह कार्यात्मक हैं।
तीसरा सामान्य रूप = 2NF + कोई सकर्मक निर्भरता नहीं है। सभी गैर-कुंजी विशेषताएँ पूरी तरह से कार्यात्मक निर्भर हैं केवल प्राथमिक कुंजी पर।
बॉयस-कॉड सामान्य रूप (या बीसीएनएफ या 3.5 एनएफ) तीसरे सामान्य रूप (3 एनएफ) का थोड़ा मजबूत संस्करण है।
नोट: - दूसरा, तीसरा और बॉयस-कॉड सामान्य रूप कार्यात्मक निर्भरताओं से संबंधित हैं। उदाहरण
चौथा सामान्य रूप = 3NF + बहुविकल्पीय निर्भरता को दूर करता है
पांचवां सामान्य रूप = 4NF + जुड़ाव निर्भरता को हटा दें
जैसा कि मार्टिन क्लेपमैन ने अपनी पुस्तक डिजाइनिंग डेटा इंटेंसिव एप्लिकेशन में कहा है:
संबंधपरक मॉडल पर साहित्य कई अलग-अलग सामान्य रूपों को अलग करता है, लेकिन अंतर थोड़ा व्यावहारिक रुचि के हैं। अंगूठे के एक नियम के रूप में, यदि आप उन मानों की नक़ल कर रहे हैं जो केवल एक ही स्थान पर संग्रहीत किए जा सकते हैं, तो स्कीमा सामान्यीकृत नहीं है।
यह डुप्लिकेट (और बदतर, परस्पर विरोधी) डेटा को रोकने में मदद करता है।
हालांकि प्रदर्शन पर नकारात्मक प्रभाव पड़ सकता है।