डेटाबेस सामान्यीकरण

डेटाबेस सामान्यीकरण या डेटाबेस सामान्यीकरण (देखें अमेरिकी और ब्रिटिश अंग्रेजी वर्तनी अंतर#-ise, -ize (-isation, -ization)) तथाकथित #सामान्य रूपों की एक श्रृंखला के अनुसार एक संबंध का डेटाबेस को संरचित करने की प्रक्रिया है। ' डेटा अतिरेक को कम करने और डेटा अखंडता में सुधार करने के लिए। यह पहली बार ब्रिटिश लोगों के कंप्यूटर वैज्ञानिक एडगर एफ. कॉड द्वारा उनके संबंधपरक मॉडल के हिस्से के रूप में प्रस्तावित किया गया था।

सामान्यीकरण एक डेटाबेस के कॉलम (डेटाबेस) (गुण) और संबंध (डेटाबेस) (संबंध) को व्यवस्थित करने के लिए यह सुनिश्चित करता है कि उनका निर्भरता सिद्धांत (डेटाबेस सिद्धांत) डेटाबेस अखंडता बाधाओं द्वारा ठीक से लागू किया जाता है। यह कुछ औपचारिक नियमों को या तो संश्लेषण (एक नया डेटाबेस डिज़ाइन बनाना) या अपघटन (मौजूदा डेटाबेस डिज़ाइन में सुधार) की प्रक्रिया द्वारा लागू करके पूरा किया जाता है।

उद्देश्य
1970 में कॉड द्वारा परिभाषित पहले सामान्य रूप का एक मूल उद्देश्य डेटा को प्रथम-क्रम तर्क में आधारित एक सार्वभौमिक डेटा उप-भाषा का उपयोग करके क्वेरी और हेरफेर करने की अनुमति देना था। ऐसी भाषा का एक उदाहरण SQL है, हालांकि यह एक ऐसी भाषा है जिसे Codd गंभीर रूप से त्रुटिपूर्ण मानता है। 1NF (प्रथम सामान्य रूप) से परे सामान्यीकरण के उद्देश्यों को Codd द्वारा इस प्रकार बताया गया था:

जब किसी संबंध को संशोधित करने (अद्यतन करने, सम्मिलित करने, या उससे हटाने) का प्रयास किया जाता है, तो उन संबंधों में निम्नलिखित अवांछनीय दुष्प्रभाव उत्पन्न हो सकते हैं जो पर्याप्त रूप से सामान्य नहीं हुए हैं:


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

डेटाबेस संरचना का विस्तार करते समय रीडिज़ाइन को छोटा करें
एक पूरी तरह से सामान्यीकृत डेटाबेस मौजूदा संरचना को बहुत अधिक बदले बिना नए प्रकार के डेटा को समायोजित करने के लिए इसकी संरचना को विस्तारित करने की अनुमति देता है। नतीजतन, डेटाबेस के साथ बातचीत करने वाले एप्लिकेशन न्यूनतम रूप से प्रभावित होते हैं।

सामान्यीकृत संबंध, और एक सामान्यीकृत संबंध और दूसरे के बीच संबंध, वास्तविक दुनिया की अवधारणाओं और उनके अंतर्संबंधों को प्रतिबिंबित करते हैं।

सामान्य रूप
Codd ने सामान्यीकरण की अवधारणा पेश की और जिसे अब 1970 में पहले सामान्य रूप (1NF) के रूप में जाना जाता है। Codd ने 1971 में दूसरे सामान्य रूप (2NF) और तीसरे सामान्य रूप (3NF) को परिभाषित किया, और Codd और Raymond F. Boyce ने 1974 में Boyce-Codd normal form (BCNF) को परिभाषित किया। अनौपचारिक रूप से, एक संबंधपरक डेटाबेस संबंध को अक्सर सामान्यीकृत के रूप में वर्णित किया जाता है यदि यह तीसरे सामान्य रूप से मिलता है। अधिकांश 3NF संबंध सम्मिलन, अद्यतन और विलोपन विसंगतियों से मुक्त हैं।

सामान्य रूप (कम से कम सामान्यीकृत से सबसे सामान्यीकृत) हैं:

• UNF: Unnormalized form

• 1NF: First normal form

• 2NF: Second normal form

• 3NF: Third normal form

• EKNF: Elementary key normal form

• BCNF: Boyce–Codd normal form

• 4NF: Fourth normal form

• ETNF: Essential tuple normal form

• 5NF: Fifth normal form

• DKNF: Domain-key normal form

• 6NF: Sixth normal form

चरण दर चरण सामान्यीकरण का उदाहरण
सामान्यीकरण एक डेटाबेस डिज़ाइन तकनीक है, जिसका उपयोग संबंधपरक डेटाबेस तालिका को उच्च सामान्य रूप तक डिज़ाइन करने के लिए किया जाता है। प्रक्रिया प्रगतिशील है, और डेटाबेस सामान्यीकरण का एक उच्च स्तर तब तक प्राप्त नहीं किया जा सकता जब तक कि पिछले स्तर संतुष्ट न हों। इसका मतलब यह है कि, असामान्य रूप में डेटा (कम से कम सामान्यीकृत) और सामान्यीकरण के उच्चतम स्तर को प्राप्त करने का लक्ष्य रखते हुए, पहला कदम पहले सामान्य रूप का अनुपालन सुनिश्चित करना होगा, दूसरा कदम यह सुनिश्चित करना होगा कि दूसरा सामान्य रूप संतुष्ट हो, और इसी तरह ऊपर वर्णित क्रम में, जब तक कि डेटा छठे सामान्य रूप के अनुरूप न हो।

हालांकि, यह ध्यान देने योग्य है कि 4NF से परे सामान्य रूप मुख्य रूप से अकादमिक रुचि के हैं, क्योंकि वे जिन समस्याओं को हल करने के लिए मौजूद हैं, वे शायद ही कभी व्यवहार में दिखाई देती हैं। निम्नलिखित उदाहरण में डेटा जानबूझकर अधिकांश सामान्य रूपों का खंडन करने के लिए डिज़ाइन किया गया था। वास्तविक जीवन में, सामान्यीकरण के कुछ चरणों को छोड़ना काफी संभव है क्योंकि तालिका में दिए गए सामान्य रूप के विपरीत कुछ भी नहीं है। यह आमतौर पर भी होता है कि एक सामान्य रूप का उल्लंघन ठीक करने से प्रक्रिया में एक उच्च सामान्य रूप का उल्लंघन भी ठीक हो जाता है। साथ ही प्रत्येक चरण पर सामान्यीकरण के लिए एक तालिका का चयन किया गया है, जिसका अर्थ है कि इस उदाहरण प्रक्रिया के अंत में, अभी भी कुछ तालिकाएँ उच्चतम सामान्य रूप को संतुष्ट नहीं कर सकती हैं।

प्रारंभिक डेटा
निम्नलिखित संरचना के साथ डेटाबेस तालिका मौजूद होने दें: इस उदाहरण के लिए, यह माना जाता है कि प्रत्येक पुस्तक का केवल एक लेखक है।

संबंधपरक मॉडल के अनुरूप होने के लिए एक शर्त के रूप में, एक तालिका में एक प्राथमिक कुंजी होनी चाहिए, जो विशिष्ट रूप से एक पंक्ति की पहचान करती है। दो पुस्तकों का शीर्षक समान हो सकता है, लेकिन एक ISBN विशिष्ट रूप से एक पुस्तक की पहचान करता है, इसलिए इसे प्राथमिक कुंजी के रूप में उपयोग किया जा सकता है:

!आईएसबीएन !शीर्षक !लेखक !लेखक राष्ट्रीयता !प्रारूप !कीमत !विषय पन्ने !मोटाई प्रकाशक !प्रकाशक देश प्रकाशन प्रकार !शैली आईडी !शैली का नाम
 * वर्ग = विकिटेबल
 * 1590593324
 * MySQL डेटाबेस डिजाइन और अनुकूलन की शुरुआत
 * चाड रसेल
 * अमेरिकी
 * हार्डकवर
 * 49.99
 * 49.99


 * 520
 * मोटा
 * अप्रेस
 * अमेरीका
 * ई-पुस्तक
 * 1
 * ट्यूटोरियल
 * }

संतोषजनक 1NF
प्रथम सामान्य रूप को संतुष्ट करने के लिए, तालिका के प्रत्येक स्तंभ का एक मान होना चाहिए। मूल्यों के सेट या नेस्टेड रिकॉर्ड वाले कॉलम की अनुमति नहीं है।

प्रारंभिक तालिका में, विषय में विषय मूल्यों का एक सेट होता है, जिसका अर्थ है कि यह अनुपालन नहीं करता है।

समस्या को हल करने के लिए, विषयों को एक अलग विषय तालिका में निकाला जाता है:

विषय-सारणी में एक विदेशी कुंजी स्तंभ जोड़ा जाता है, जो उस पंक्ति की प्राथमिक कुंजी को संदर्भित करता है जिससे विषय निकाला गया था। इसलिए समान जानकारी का प्रतिनिधित्व किया जाता है लेकिन गैर-साधारण डोमेन के उपयोग के बिना।

असामान्य रूप में एक तालिका के बजाय, अब 1NF के अनुरूप दो तालिकाएँ हैं।

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

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

संतोषजनक 3NF
पुस्तक तालिका में अभी भी सकर्मक कार्यात्मक निर्भरता है ({लेखक राष्ट्रीयता} {लेखक} पर निर्भर है, जो {शीर्षक} पर निर्भर है)। शैली के लिए एक समान उल्लंघन मौजूद है ({शैली का नाम} {शैली आईडी} पर निर्भर है, जो {शीर्षक} पर निर्भर है)। इसलिए, बुक टेबल 3NF में नहीं है। इसे 3NF में बनाने के लिए, निम्न तालिका संरचना का उपयोग करते हैं, जिससे {Author Nationality} और {Genre Name} को उनकी संबंधित तालिकाओं में रखकर सकर्मक कार्यात्मक निर्भरता समाप्त हो जाती है:

! लेखक !लेखक राष्ट्रीयता
 * वर्ग = विकिटेबल
 * +लेखक
 * चाड रसेल
 * अमेरिकी
 * ई.एफ. कॉड
 * ब्रिटिश
 * }
 * ब्रिटिश
 * }

! लिंग आईडी !शैली का नाम
 * वर्ग = विकिटेबल
 * +शैली
 * 1
 * ट्यूटोरियल
 * 2
 * लोकप्रिय विज्ञान
 * }
 * लोकप्रिय विज्ञान
 * }

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

संतोषजनक 4NF
मान लें कि डेटाबेस का स्वामित्व एक पुस्तक रिटेलर फ़्रैंचाइज़ी के पास है जिसमें कई फ़्रैंचाइज़ी हैं जो विभिन्न स्थानों में अपनी दुकानें रखते हैं। और इसलिए खुदरा विक्रेता ने एक तालिका जोड़ने का निर्णय लिया जिसमें विभिन्न स्थानों पर पुस्तकों की उपलब्धता के बारे में डेटा शामिल है: चूंकि इस तालिका संरचना में एक यौगिक कुंजी होती है, इसमें कोई गैर-कुंजी विशेषता नहीं होती है और यह पहले से ही बॉयस-कॉड सामान्य रूप में है (और इसलिए सभी पिछले डेटाबेस सामान्यीकरण # सामान्य रूपों को भी संतुष्ट करता है)। हालाँकि, यह मानते हुए कि सभी उपलब्ध पुस्तकें प्रत्येक क्षेत्र में प्रस्तुत की जाती हैं, शीर्षक स्पष्ट रूप से एक निश्चित स्थान के लिए बाध्य नहीं है और इसलिए तालिका चौथे सामान्य रूप को संतुष्ट नहीं करती है।

इसका अर्थ है कि, चौथे सामान्य रूप को संतुष्ट करने के लिए, इस तालिका को भी विघटित करने की आवश्यकता है: अब, प्रत्येक रिकॉर्ड स्पष्ट रूप से एक key द्वारा पहचाना जाता है, इसलिए 4NF संतुष्ट है।

संतोषजनक ईटीएनएफ
मान लीजिए कि फ़्रैंचाइजी विभिन्न आपूर्तिकर्ताओं से किताबें मंगवा सकते हैं। चलो रिश्ता भी निम्नलिखित बाधा के अधीन है:


 * यदि एक निश्चित आपूर्तिकर्ता एक निश्चित शीर्षक की आपूर्ति करता है
 * और शीर्षक फ्रेंचाइजी को प्रदान किया जाता है
 * और फ्रेंचाइजी आपूर्तिकर्ता द्वारा आपूर्ति की जा रही है,
 * फिर आपूर्तिकर्ता फ़्रैंचाइजी को शीर्षक की आपूर्ति करता है।

यह तालिका चौथे सामान्य रूप में है, लेकिन प्रदायक आईडी इसके अनुमानों के जुड़ने के बराबर है: {{Supplier ID, Title}, {Title, Franchisee ID}, {Franchisee ID, Supplier ID}}. उस ज्वाइन डिपेंडेंसी का कोई भी घटक सुपरकी नहीं है (एकमात्र सुपरकी संपूर्ण शीर्षक है), इसलिए तालिका आवश्यक टपल सामान्य रूप को संतुष्ट नहीं करती है और इसे और विघटित किया जा सकता है: अपघटन ईटीएनएफ अनुपालन पैदा करता है।

संतोषजनक 5NF
किसी तालिका को पांचवें सामान्य रूप से संतुष्ट नहीं करने के लिए, आमतौर पर डेटा की पूरी तरह से जांच करना आवश्यक होता है। मान लीजिए डेटाबेस सामान्यीकरण से तालिका # डेटा में थोड़ा संशोधन के साथ 4NF को संतुष्ट करना और यह जांचना कि क्या यह पांचवें सामान्य रूप को संतुष्ट करता है: इस तालिका को विघटित करने से अतिरेक कम होता है, जिसके परिणामस्वरूप निम्नलिखित दो तालिकाएँ बनती हैं: इन तालिकाओं में शामिल होने वाली क्वेरी निम्न डेटा वापस कर देगी:

! फ़्रैंचाइज़ी आईडी ! शीर्षक ! स्थान JOIN तीन पंक्तियों को जितना चाहिए उससे अधिक लौटाता है; तीन अलग-अलग तालिकाओं में संबंध परिणामों को स्पष्ट करने के लिए एक और तालिका जोड़ना:
 * वर्ग = विकिटेबल
 * + संरेखित = शीर्ष |फ्रेंचाइजी - पुस्तक - स्थान शामिल हुआ
 * 1
 * MySQL डेटाबेस डिजाइन और अनुकूलन की शुरुआत
 * कैलिफोर्निया
 * 1
 * एसक्यूएल सीखना
 * कैलिफोर्निया
 * 1
 * डेटाबेस प्रबंधन के लिए संबंधपरक मॉडल: संस्करण 2
 * California
 * 1
 * डेटाबेस प्रबंधन के लिए संबंधपरक मॉडल: संस्करण 2
 * टेक्सास
 * 1
 * SQL सीखना
 * Texas
 * 1
 * शुरुआत MySQL डेटाबेस डिजाइन और अनुकूलन
 * Texas
 * 2
 * डेटाबेस प्रबंधन के लिए संबंधपरक मॉडल: संस्करण 2
 * कैलिफोर्निया
 * }
 * शुरुआत MySQL डेटाबेस डिजाइन और अनुकूलन
 * Texas
 * 2
 * डेटाबेस प्रबंधन के लिए संबंधपरक मॉडल: संस्करण 2
 * कैलिफोर्निया
 * }
 * }
 * }



JOIN अब क्या लौटाएगा? वास्तव में इन तीन तालिकाओं में शामिल होना संभव नहीं है। इसका मतलब यह है कि फ्रेंचाइजी - पुस्तक - स्थान को डेटा हानि के बिना विघटित करना संभव नहीं था, इसलिए तालिका पहले से ही 5NF को संतुष्ट करती है।
 * }
 * }

क्रिस्टोफर जे. डेट|सी.जे. दिनांक ने तर्क दिया है कि केवल 5NF में एक डेटाबेस वास्तव में सामान्यीकृत है।

संतोषजनक डीकेएनएफ
आइए पिछले उदाहरणों से पुस्तक तालिका पर एक नज़र डालें और देखें कि क्या यह डोमेन-कुंजी के सामान्य रूप को संतुष्ट करती है: तार्किक रूप से, मोटाई पृष्ठों की संख्या से निर्धारित होती है। इसका मतलब है कि यह उन पेजों पर निर्भर करता है जो की नहीं है। आइए एक उदाहरण परंपरा निर्धारित करें कि 350 पृष्ठों तक की पुस्तक को पतला माना जाता है और 350 पृष्ठों से अधिक की पुस्तक को मोटा माना जाता है।

यह सम्मेलन तकनीकी रूप से एक बाधा है लेकिन यह न तो डोमेन बाधा है और न ही मुख्य बाधा है; इसलिए हम डेटा अखंडता को बनाए रखने के लिए डोमेन बाधाओं और प्रमुख बाधाओं पर भरोसा नहीं कर सकते हैं।

दूसरे शब्दों में - कुछ भी हमें डालने से नहीं रोकता है, उदाहरण के लिए, केवल 50 पृष्ठों वाली पुस्तक के लिए मोटा - और यह तालिका को डोमेन-कुंजी के सामान्य रूप का उल्लंघन करता है।

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

संतोषजनक 6NF
छठे सामान्य रूप की एक सरल और सहज परिभाषा यह है कि एक तालिका छठे सामान्य रूप में होती है जब 'पंक्ति में प्राथमिक कुंजी होती है, और अधिक से अधिक एक अन्य विशेषता ' ' होती है। इसका अर्थ है, उदाहरण के लिए, #Satisfying_1NF के दौरान डिज़ाइन की गई प्रकाशक तालिका आगे दो तालिकाओं में विघटित करने की जरूरत है:

6NF का स्पष्ट दोष एक इकाई पर सूचना का प्रतिनिधित्व करने के लिए आवश्यक तालिकाओं का प्रसार है। यदि 5NF में एक तालिका में एक प्राथमिक कुंजी स्तंभ और N विशेषताएँ हैं, तो 6NF में समान जानकारी का प्रतिनिधित्व करने के लिए N तालिकाओं की आवश्यकता होगी; एकल वैचारिक रिकॉर्ड के लिए बहु-फ़ील्ड अद्यतनों के लिए एकाधिक तालिकाओं के अद्यतनों की आवश्यकता होगी; और सम्मिलित करने और हटाने के लिए समान रूप से कई तालिकाओं में संचालन की आवश्यकता होगी। इस कारण से, डेटाबेस में OLTP जरूरतों को पूरा करने के लिए, 6NF का उपयोग नहीं किया जाना चाहिए।

हालाँकि, डेटा गोदाम में, जो इंटरैक्टिव अपडेट की अनुमति नहीं देते हैं और जो बड़े डेटा वॉल्यूम पर तेज़ क्वेरी के लिए विशिष्ट हैं, कुछ DBMS एक आंतरिक 6NF प्रतिनिधित्व का उपयोग करते हैं - जिसे कॉलम-ओरिएंटेड DBMS के रूप में जाना जाता है। ऐसी स्थितियों में जहां स्तंभ के अद्वितीय मानों की संख्या तालिका में पंक्तियों की संख्या से बहुत कम है, स्तंभ-उन्मुख भंडारण डेटा संपीड़न के माध्यम से अंतरिक्ष में महत्वपूर्ण बचत की अनुमति देता है। स्तंभकार भंडारण भी श्रेणी प्रश्नों के तेजी से निष्पादन की अनुमति देता है (उदाहरण के लिए, सभी रिकॉर्ड दिखाएं जहां एक विशेष स्तंभ एक्स और वाई के बीच है, या एक्स से कम है।)

इन सभी मामलों में, हालाँकि, डेटाबेस डिज़ाइनर को अलग-अलग तालिकाएँ बनाकर मैन्युअल रूप से 6NF सामान्यीकरण नहीं करना पड़ता है। कुछ DBMS जो वेयरहाउसिंग के लिए विशिष्ट हैं, जैसे कि Sybase IQ, डिफ़ॉल्ट रूप से कॉलमर स्टोरेज का उपयोग करते हैं, लेकिन डिज़ाइनर अभी भी केवल एक मल्टी-कॉलम टेबल देखता है। अन्य DBMSs, जैसे कि Microsoft SQL Server 2012 और बाद में, आपको किसी विशेष तालिका के लिए एक कॉलमस्टोर इंडेक्स निर्दिष्ट करने देते हैं।

यह भी देखें

 * विसामान्यीकरण
 * डेटाबेस रीफैक्टरिंग
 * दोषरहित अपघटन में शामिल हों

अग्रिम पठन

 * Date, C. J. (1999), An Introduction to Database Systems (8th ed.). Addison-Wesley Longman. ISBN 0-321-19784-4.
 * Kent, W. (1983) A Simple Guide to Five Normal Forms in Relational Database Theory, Communications of the ACM, vol. 26, pp. 120–125
 * H.-J. Schek, P. Pistor Data Structures for an Integrated Data Base Management and Information Retrieval System

बाहरी संबंध

 * Database Normalization Basics by Mike Chapple (About.com)
 * Database Normalization Intro, Part 2
 * An Introduction to Database Normalization by Mike Hillyer.
 * A tutorial on the first 3 normal forms by Fred Coulson
 * Description of the database normalization basics by Microsoft
 * Normalization in DBMS by Chaitanya (beginnersbook.com)
 * A Step-by-Step Guide to Database Normalization
 * ETNF – Essential tuple normal form
 * ETNF – Essential tuple normal form