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

From Vigyanwiki
Revision as of 20:48, 20 February 2023 by alpha>Jyotimehta (TEXT)

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

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

उद्देश्य

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

1. संबंधों के संग्रह को अवांछित प्रविष्टि, अद्यतन और विलोपन निर्भरता से मुक्त करने के लिए।

2, संबंधों के संग्रह के पुनर्गठन की आवश्यकता को कम करने के लिए, क्योंकि नए प्रकार के डेटा पेश किए जाते हैं, और इस प्रकार आवेदन कार्यक्रमों के जीवन काल में वृद्धि होती है।

3, संबंधपरक मॉडल को उपयोगकर्ताओं के लिए अधिक जानकारीपूर्ण बनाने के लिए। 4, क्वेरी आँकड़ों के लिए संबंधों के संग्रह को तटस्थ बनाने के लिए, जहाँ ये आँकड़े समय बीतने के साथ बदलने के लिए उत्तरदायी हैं।

— ई.एफ. कोड, "डाटा बेस रिलेशनल मॉडल का और अधिक सामान्यीकरण"[3]
एक सम्मिलन विसंगति। जब तक नए संकाय सदस्य, डॉ. न्यूजोम को कम से कम एक पाठ्यक्रम पढ़ाने के लिए नियुक्त नहीं किया जाता है, तब तक उनका विवरण दर्ज नहीं किया जा सकता है।
एक अद्यतन विसंगति। कर्मचारी 519 को अलग-अलग अभिलेख पर अलग-अलग पते के रूप में दिखाया गया है।
एक विलोपन विसंगति। डॉ. गिड्डेंस के बारे में सारी जानकारी खो जाती है यदि वे अस्थायी रूप से किसी भी पाठ्यक्रम को आवंटित करना बंद कर देते हैं।

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

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

डेटाबेस संरचना का विस्तार करते समय रीडिज़ाइन को छोटा करें

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

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

सामान्य रूप

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

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

प्रतिबंध
(कोष्ठक में अनौपचारिक विवरण) 		UNF
(1970) 		1NF
(1970) 		2NF
(1971) 		3NF
(1971) 		EKNF
(1982) 		BCNF
(1974) 		4NF
(1977) 		ETNF
(2012) 		5NF
(1979) 		DKNF
(1981) 		6NF
(2003)
अद्वितीय पंक्तियाँ (कोई समरूप अभिलेख नहीं)[4] Maybe Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes
अदिश स्तंभ (स्तंभ में संबंध या मिश्रित मान नहीं हो सकते)[5] No Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes
प्रत्येक गैर-प्रमुख विशेषता में एक उम्मीदवार कुंजी पर पूर्ण कार्यात्मक निर्भरता होती है (विशेषताएँ पूर्ण प्राथमिक कुंजी पर निर्भर करती हैं)[5] No No Yes Yes Yes Yes Yes Yes Yes Yes Yes
प्रत्येक गैर-साधारण कार्यात्मक निर्भरता या तो एक उत्कृष्ट कुंजी के साथ प्रारम्भ होती है या एक प्रमुख विशेषता के साथ समाप्त होती है (विशेषताएँ केवल प्राथमिक कुंजी पर निर्भर करती हैं)[5] No No No Yes Yes Yes Yes Yes Yes Yes Yes
प्रत्येक गैर-साधारण कार्यात्मक निर्भरता या तो एक उत्कृष्ट कुंजी के साथ प्रारम्भ होती है या एक प्राथमिक प्रधान विशेषता (3NF का एक कठोर रूप) के साथ समाप्त होती है। No No No No Yes Yes Yes Yes Yes Yes —
प्रत्येक गैर-साधारण कार्यात्मक निर्भरता एक उत्कृष्ट कुंजी (3NF का एक कठोर रूप) से प्रारम्भ होती है No No No No No Yes Yes Yes Yes Yes —
प्रत्येक गैर-साधारण बहु-मूल्यवान निर्भरता एक उत्कृष्ट कुंजी से प्रारम्भ होती है No No No No No No Yes Yes Yes Yes —
प्रत्येक सम्मिलित निर्भरता में एक उत्कृष्ट कुंजी घटक होता है[8] No No No No No No No Yes Yes Yes —
प्रत्येक सम्मिलित निर्भरता में केवल उत्कृष्ट कुंजी घटक होते हैं No No No No No No No No Yes Yes —
प्रत्येक प्रतिबंध कार्यक्षेत्र प्रतिबंध और कुंजी प्रतिबंध का परिणाम है No No No No No No No No No Yes No
प्रत्येक सम्मिलित निर्भरता साधारण है No No No No No No No No No No Yes


चरण दर चरण सामान्यीकरण का उदाहरण

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

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

प्रारंभिक डेटा

निम्नलिखित संरचना के साथ डेटाबेस तालिका मौजूद होने दें:[10]

शीर्षक लेखक लेखक राष्ट्रीयता प्रारूप मूल्य विषय पृष्ठ मोटाई प्रकाशक प्रकाशक राष्ट्र प्रकाशन

प्रकार

विधा ID विधा का नाम
MySQL डाटाबेस अभिकल्पन और अनुकूलन का प्रारम्भ चाड रसेल अमेरीका हार्डकवर 49.99
MySQL
Database
Design
520 मोटा अप्रेस अमेरीका E-पुस्तक 1 अनुशिक्षण

इस उदाहरण के लिए, यह माना जाता है कि प्रत्येक पुस्तक का केवल एक लेखक है।

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


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

MySQL
Database
Design

|520 |मोटा |अप्रेस |अमेरीका |ई-पुस्तक |1 |अनुशिक्षण |}

संतोषजनक 1NF

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

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

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

Book
ISBN शीर्षक प्रारूप लेखक लेखक राष्ट्रीयता मूल्य पृष्ठ मोटाई प्रकाशक प्रकाशक राष्ट्र Genre ID विधा का नाम
1590593324 Beginning MySQL Database Design and Optimization Hardcover Chad Russell American 49.99 520 Thick Apress USA 1 Tutorial
विषय
ISBN विषय name
1590593324 MySQL
1590593324 Database
1590593324 Design

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

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

संतोषजनक 2NF

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

Book
शीर्षक प्रारूप लेखक लेखक राष्ट्रीयता मूल्य पृष्ठ मोटाई Genre ID विधा का नाम प्रकाशक ID
Beginning MySQL Database Design and Optimization Hardcover Chad Russell American 49.99 520 Thick 1 Tutorial 1
Beginning MySQL Database Design and Optimization E-book Chad Russell American 22.34 520 Thick 1 Tutorial 1
The Relational Model for Database Management: Version 2 E-book E.F.Codd British 13.88 538 Thick 2 Popular science 2
The Relational Model for Database Management: Version 2 Paperback E.F.Codd British 39.99 538 Thick 2 Popular science 2

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

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

Book
शीर्षक लेखक लेखक राष्ट्रीयता पृष्ठ मोटाई Genre ID विधा का नाम प्रकाशक ID
Beginning MySQL Database Design and Optimization Chad Russell American 520 Thick 1 Tutorial 1
The Relational Model for Database Management: Version 2 E.F.Codd British 538 Thick 2 Popular science 2
प्रारूप - मूल्य
शीर्षक प्रारूप मूल्य
Beginning MySQL Database Design and Optimization Hardcover 49.99
Beginning MySQL Database Design and Optimization E-book 22.34
The Relational Model for Database Management: Version 2 E-book 13.88
The Relational Model for Database Management: Version 2 Paperback 39.99
प्रकाशक
प्रकाशक ID Name राष्ट्र
1 Apress USA
2 Addison-Wesley USA

अब, पुस्तक तालिका दूसरे सामान्य रूप के अनुरूप है।

संतोषजनक 3NF

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

Book
शीर्षक लेखक पृष्ठ मोटाई Genre ID प्रकाशक ID
Beginning MySQL Database Design and Optimization Chad Russell 520 Thick 1 1
The Relational Model for Database Management: Version 2 E.F.Codd 538 Thick 2 2
मूल्य
शीर्षक प्रारूप मूल्य
Beginning MySQL Database Design and Optimization Hardcover 49.99
Beginning MySQL Database Design and Optimization E-book 22.34
The Relational Model for Database Management: Version 2 E-book 13.88
The Relational Model for Database Management: Version 2 Paperback 39.99

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

| वर्ग = विकिटेबल |+शैली !लिंग आईडी !शैली का नाम |- |- |1 |अनुशिक्षण |- |- |2 | लोकप्रिय विज्ञान |}

संतोषजनक ईकेएनएफ

Main article: Elementary key normal form

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


संतोषजनक 4NF

मान लें कि डेटाबेस का स्वामित्व एक पुस्तक रिटेलर फ़्रैंचाइज़ी के पास है जिसमें कई फ़्रैंचाइज़ी हैं जो विभिन्न स्थानों में अपनी दुकानें रखते हैं। और इसलिए खुदरा विक्रेता ने एक तालिका जोड़ने का निर्णय लिया जिसमें विभिन्न स्थानों पर पुस्तकों की उपलब्धता के बारे में डेटा शामिल है:

Franchisee - Book - Location
Franchisee ID शीर्षक Location
1 Beginning MySQL Database Design and Optimization California
1 Beginning MySQL Database Design and Optimization Florida
1 Beginning MySQL Database Design and Optimization Texas
1 The Relational Model for Database Management: Version 2 California
1 The Relational Model for Database Management: Version 2 Florida
1 The Relational Model for Database Management: Version 2 Texas
2 Beginning MySQL Database Design and Optimization California
2 Beginning MySQL Database Design and Optimization Florida
2 Beginning MySQL Database Design and Optimization Texas
2 The Relational Model for Database Management: Version 2 California
2 The Relational Model for Database Management: Version 2 Florida
2 The Relational Model for Database Management: Version 2 Texas
3 Beginning MySQL Database Design and Optimization Texas

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

इसका अर्थ है कि, चौथे सामान्य रूप को संतुष्ट करने के लिए, इस तालिका को भी विघटित करने की आवश्यकता है:

Franchisee - Book
Franchisee ID शीर्षक
1 Beginning MySQL Database Design and Optimization
1 The Relational Model for Database Management: Version 2
2 Beginning MySQL Database Design and Optimization
2 The Relational Model for Database Management: Version 2
3 Beginning MySQL Database Design and Optimization
Franchisee - Location
Franchisee ID Location
1 California
1 Florida
1 Texas
2 California
2 Florida
2 Texas
3 Texas

अब, प्रत्येक अभिलेख स्पष्ट रूप से एक key द्वारा पहचाना जाता है, इसलिए 4NF संतुष्ट है।

संतोषजनक ईटीएनएफ

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

  • यदि एक निश्चित आपूर्तिकर्ता एक निश्चित शीर्षक की आपूर्ति करता है
  • और शीर्षक फ्रेंचाइजी को प्रदान किया जाता है
  • और फ्रेंचाइजी आपूर्तिकर्ता द्वारा आपूर्ति की जा रही है,
  • फिर आपूर्तिकर्ता फ़्रैंचाइजी को शीर्षक की आपूर्ति करता है।[13]
Supplier - Book - Franchisee
Supplier ID शीर्षक Franchisee ID
1 Beginning MySQL Database Design and Optimization 1
2 The Relational Model for Database Management: Version 2 2
3 Learning SQL 3

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

Supplier - Book
Supplier ID शीर्षक
1 Beginning MySQL Database Design and Optimization
2 The Relational Model for Database Management: Version 2
3 Learning SQL
Book - Franchisee
शीर्षक Franchisee ID
Beginning MySQL Database Design and Optimization 1
The Relational Model for Database Management: Version 2 2
Learning SQL 3
Franchisee - Supplier
Supplier ID Franchisee ID
1 1
2 2
3 3

अपघटन ईटीएनएफ अनुपालन पैदा करता है।

संतोषजनक 5NF

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

Franchisee - Book - Location
Franchisee ID शीर्षक Location
1 Beginning MySQL Database Design and Optimization California
1 Learning SQL California
1 The Relational Model for Database Management: Version 2 Texas
2 The Relational Model for Database Management: Version 2 California

इस तालिका को विघटित करने से अतिरेक कम होता है, जिसके परिणामस्वरूप निम्नलिखित दो तालिकाएँ बनती हैं:

Franchisee - Book
Franchisee ID शीर्षक
1 Beginning MySQL Database Design and Optimization
1 Learning SQL
1 The Relational Model for Database Management: Version 2
2 The Relational Model for Database Management: Version 2
Franchisee - Location
Franchisee ID Location
1 California
1 Texas
2 California

इन तालिकाओं में शामिल होने वाली क्वेरी निम्न डेटा वापस कर देगी:

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

| |

Franchisee - Book
Franchisee ID शीर्षक
1 Beginning MySQL Database Design and Optimization
1 Learning SQL
1 The Relational Model for Database Management: Version 2
2 The Relational Model for Database Management: Version 2

|

Franchisee - Location
Franchisee ID Location
1 California
1 Texas
2 California

|

Location - Book
Location शीर्षक
California Beginning MySQL Database Design and Optimization
California Learning SQL
California The Relational Model for Database Management: Version 2
Texas The Relational Model for Database Management: Version 2

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

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


संतोषजनक डीकेएनएफ

आइए पिछले उदाहरणों से पुस्तक तालिका पर एक नज़र डालें और देखें कि क्या यह कार्यक्षेत्र-कुंजी के सामान्य रूप को संतुष्ट करती है:

Book
शीर्षक पृष्ठ मोटाई Genre ID प्रकाशक ID
Beginning MySQL Database Design and Optimization 520 Thick 1 1
The Relational Model for Database Management: Version 2 538 Thick 2 2
Learning SQL 338 Slim 1 3
SQL Cookbook 636 Thick 1 3

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

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

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

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

मोटाई Enum
मोटाई Min पृष्ठ Max पृष्ठ
Slim 1 350
Thick 351 999,999,999,999
Book - पृष्ठ - Genre - प्रकाशक
शीर्षक पृष्ठ Genre ID प्रकाशक ID
Beginning MySQL Database Design and Optimization 520 1 1
The Relational Model for Database Management: Version 2 538 2 2
Learning SQL 338 1 3
SQL Cookbook 636 1 3

इस तरह, कार्यक्षेत्र अखंडता उल्लंघन समाप्त हो गया है, और तालिका कार्यक्षेत्र-कुंजी सामान्य रूप में है।

संतोषजनक 6NF

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

प्रकाशक
प्रकाशक ID Name राष्ट्र
1 Apress USA

आगे दो तालिकाओं में विघटित करने की जरूरत है:

प्रकाशक
प्रकाशक ID Name
1 Apress
प्रकाशक राष्ट्र
प्रकाशक ID राष्ट्र
1 USA

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

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

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


यह भी देखें

नोट्स और संदर्भ

  1. ↑ "The adoption of a relational model of data ... permits the development of a universal data sub-language based on an applied predicate calculus. A first-order predicate calculus suffices if the collection of relations is in first normal form. Such a language would provide a yardstick of linguistic power for all other proposed data languages, and would itself be a strong candidate for embedding (with appropriate syntactic modification) in a variety of host languages (programming, command- or problem-oriented)." Codd, "A Relational Model of Data for Large Shared Data Banks" Archived June 12, 2007, at the Wayback Machine, p. 381
  2. ↑ Codd, E.F. Chapter 23, "Serious Flaws in SQL", in The Relational Model for Database Management: Version 2. Addison-Wesley (1990), pp. 371–389
  3. ↑ Codd, E.F. "Further Normalisation of the Data Base Relational Model", p. 34
  4. ↑ 4.0 4.1 Codd, E. F. (June 1970). "A Relational Model of Data for Large Shared Data Banks". Communications of the ACM. 13 (6): 377–387. doi:10.1145/362384.362685. S2CID 207549016.
  5. ↑ 5.0 5.1 5.2 5.3 Codd, E. F. "Further Normalization of the Data Base Relational Model". (Presented at Courant Computer Science Symposia Series 6, "Data Base Systems", New York City, May 24–25, 1971.) IBM Research Report RJ909 (August 31, 1971). Republished in Randall J. Rustin (ed.), Data Base Systems: Courant Computer Science Symposia Series 6. Prentice-Hall, 1972.
  6. ↑ Codd, E. F. "Recent Investigations into Relational Data Base Systems". IBM Research Report RJ1385 (April 23, 1974). Republished in Proc. 1974 Congress (Stockholm, Sweden, 1974), N.Y.: North-Holland (1974).
  7. ↑ Date, C. J. (1999). An Introduction to Database Systems. Addison-Wesley. p. 290.
  8. ↑ Darwen, Hugh; Date, C. J.; Fagin, Ronald (2012). "A Normal Form for Preventing Redundant Tuples in Relational Databases" (PDF). Proceedings of the 15th International Conference on Database Theory. EDBT/ICDT 2012 Joint Conference. ACM International Conference Proceeding Series. Association for Computing Machinery. p. 114. doi:10.1145/2274576.2274589. ISBN 978-1-4503-0791-8. OCLC 802369023. Archived (PDF) from the original on 2016-03-06. Retrieved 2018-05-22.
  9. ↑ Kumar, Kunal; Azad, S. K. (October 2017). Database normalization design pattern. doi:10.1109/upcon.2017.8251067. ISBN 9781538630044. S2CID 24491594. {{cite book}}: |journal= ignored (help)
  10. ↑ 10.0 10.1 10.2 "Database normalization in MySQL: Four quick and easy steps". ComputerWeekly.com (in English). Archived from the original on 2017-08-30. Retrieved 2021-03-23.
  11. ↑ "Database Normalization: 5th Normal Form and Beyond". MariaDB KnowledgeBase. Retrieved 2019-01-23.
  12. ↑ "Additional Normal Forms - Database Design and Relational Theory - page 151". what-when-how.com. Retrieved 2019-01-22.
  13. ↑ 13.0 13.1 Date, C. J. (December 21, 2015). The New Relational Database Dictionary: Terms, Concepts, and Examples (in English). "O'Reilly Media, Inc.". p. 138. ISBN 9781491951699.
  14. ↑ Date, C. J. (December 21, 2015). The New Relational Database Dictionary: Terms, Concepts, and Examples (in English). "O'Reilly Media, Inc.". p. 163. ISBN 9781491951699.
  15. ↑ "normalization - Would like to Understand 6NF with an Example". Stack Overflow. Retrieved 2019-01-23.
  16. ↑ Microsoft Corporation. Columnstore Indexes: Overview. https://docs.microsoft.com/en-us/sql/relational-databases/indexes/columnstore-indexes-overview . Accessed March 23, 2020.


अग्रिम पठन


बाहरी संबंध

Template:Database normalization

Retrieved from ‘https://www.vigyanwiki.in/index.php?title=डेटाबेस_सामान्यीकरण&oldid=94163’