SQL विशेष रूप से 3VL (3-मूल्यवान तर्क) के अपने संस्करण के अनुसार NULL का इलाज करता है। सामान्यीकरण और अन्य संबंधपरक सिद्धांत नहीं है। हालाँकि, हम SQL डिज़ाइन को रिलेशनल डिज़ाइन और बैक में अनुवाद कर सकते हैं। (मान लें कि यहां कोई डुप्लीकेट पंक्तियां नहीं हैं।)
सामान्यीकरण संबंधों . के लिए होता है और उन ऑपरेटरों के संदर्भ में परिभाषित किया गया है जो विशेष रूप से न्यूल का इलाज नहीं करते हैं। "सामान्यीकरण" शब्द के दो सबसे सामान्य अर्थ हैं:एक तालिका को "1NF" और "उच्च NFs (सामान्य रूप)" में डालना। NULL "1NF के सामान्यीकरण" को प्रभावित नहीं करता है। "उच्च NFs के लिए सामान्यीकरण" एक तालिका को छोटी तालिकाओं से बदल देता है जो स्वाभाविक रूप से इसमें वापस जुड़ जाती हैं। सामान्यीकरण के प्रयोजनों के लिए आप NULL को उस मान के रूप में मान सकते हैं जो उसके SQL प्रकार के मानों के अलावा एक अशक्त स्तंभ के डोमेन में अनुमत है। यदि हमारे एसक्यूएल टेबल में कोई एनयूएलएल नहीं है तो हम उन्हें संबंध और एसक्यूएल जॉइन इत्यादि के रूप में शामिल होने आदि के रूप में व्याख्या कर सकते हैं। लेकिन यदि आप विघटित होते हैं जहां घटकों के बीच एक शून्य कॉलम साझा किया गया था तो महसूस करें कि एसक्यूएल में मूल को फिर से बनाने के लिए आपको एसक्यूएल में शामिल होना होगा समान-नाम वाले कॉलम बराबर या दोनों NULL . और आप SQL डेटाबेस में ऐसे CKs (उम्मीदवार कुंजियाँ) नहीं चाहेंगे। जैसे आप इसे SQL PK (प्राथमिक कुंजी) के रूप में घोषित नहीं कर सकते क्योंकि इसका अर्थ है UNIQUE NOT NULL। उदाहरण के लिए, एक अशक्त स्तंभ में एक अद्वितीय बाधा कई पंक्तियों की अनुमति देती है जिनमें उस स्तंभ में एक NULL होता है, भले ही पंक्तियों में प्रत्येक स्तंभ में समान मान हों। उदाहरण के लिए SQL FKs में NULLs उन्हें संतुष्ट करने का कारण बनते हैं (प्रति MATCH मोड में विभिन्न तरीकों से), संदर्भित तालिका में प्रदर्शित नहीं होने से विफल नहीं होते हैं। (लेकिन डीबीएमएस मानक एसक्यूएल से अलग हैं।)
दुर्भाग्य से अपघटन से सभी . के साथ एक तालिका बन सकती है CK में NULL होता है, ताकि हमारे पास SQL PK या UNIQUE NOT NULL घोषित करने के लिए कुछ भी न हो। एकमात्र निश्चित समाधान एक पूर्ण-मुक्त डिज़ाइन में कनवर्ट करना है। उसके बाद सामान्य करने के बाद हम घटकों में कुछ अशक्तता को फिर से प्रस्तुत करना चाह सकते हैं।
व्यवहार में, हम तालिकाओं को डिज़ाइन करने का प्रबंधन करते हैं ताकि हमेशा NULL-मुक्त स्तंभों का एक सेट हो, जिसे हम SQL PK या UNIQUE NOT NULL के माध्यम से CK के रूप में घोषित कर सकते हैं। फिर हम एक अशक्त स्तंभ को तालिका से हटाकर और उस स्तंभ के साथ एक तालिका और कुछ NULL-मुक्त CK के स्तंभों को जोड़कर छुटकारा पा सकते हैं:यदि स्तंभ पुराने डिज़ाइन में एक पंक्ति के लिए गैर-NULL है तो एक पंक्ति के साथ इसकी सीके सबरो और कॉलम वैल्यू जोड़ी गई तालिका में जाती है; अन्यथा यह पुराने डिज़ाइन में NULL है और अतिरिक्त तालिका में कोई संगत पंक्ति नहीं है। (मूल तालिका नए लोगों का स्वाभाविक बायां जोड़ है।) बेशक, हमें पुराने डिज़ाइन से नए डिज़ाइन में प्रश्नों को भी संशोधित करना होगा।
हम हमेशा एक डिजाइन के माध्यम से एनयूएलएल से बच सकते हैं जो प्रत्येक पुराने नलबल कॉलम के लिए बूलियन कॉलम जोड़ता है और पुराना कॉलम न्यूल नहीं है। नया कॉलम एक पंक्ति के लिए कहता है कि क्या पुराना कॉलम पुराने डिज़ाइन में NULL था और जब सही होता है तो पुराना कॉलम कोई एक मान होता है जिसे हम उस उद्देश्य के लिए पूरे डेटाबेस में चुनते हैं। बेशक, हमें पुराने डिज़ाइन से नए डिज़ाइन में प्रश्नों को भी संशोधित करना होगा।
क्या आप NULL से बचना चाहते हैं यह एक अलग प्रश्न है। आपका डेटाबेस किसी भी तरह से आपके एप्लिकेशन के लिए किसी भी डिज़ाइन के साथ "बेहतर" या "बदतर" हो सकता है। NULL से बचने के पीछे का विचार यह है कि यह प्रश्नों के अर्थ को जटिल बनाता है, इसलिए अधिक NULL-मुक्त तालिकाओं से अधिक जुड़ने की जटिलता की तुलना में, एक विकृत तरीके से पूछताछ को जटिल बनाता है। (उस विकृति का प्रबंधन आमतौर पर क्वेरी अभिव्यक्तियों में NULLs को जितना संभव हो उतना करीब से हटाकर किया जाता है।)
PS PK और FK सहित कई SQL शब्द संबंधपरक शब्दों से भिन्न हैं। एसक्यूएल पीके का मतलब सुपरकी जैसा कुछ और है; एसक्यूएल एफके का मतलब विदेशी सुपरकी की तरह कुछ और है; लेकिन SQL में "सुपरकी" के बारे में बात करने का कोई मतलब नहीं है:
<ब्लॉकक्वॉट>संबंधों के लिए SQL तालिकाओं के समानता के कारण, संबंधों को शामिल करने वाले शब्दों को तालिकाओं पर धीरे-धीरे लागू किया जाता है। लेकिन यद्यपि आप शर्तों को उधार ले सकते हैं और उन्हें SQL अर्थ दे सकते हैं - मान, तालिका, FD (कार्यात्मक निर्भरता), सुपरकी, CK (उम्मीदवार कुंजी), PK (प्राथमिक कुंजी), FK (विदेशी कुंजी), शामिल हों, और, विधेय, NF (सामान्य रूप), सामान्यीकृत करें, 1NF, आदि - आप RM परिभाषाओं, प्रमेयों या एल्गोरिदम में उन शब्दों के लिए उन SQL अर्थों को केवल स्थानापन्न नहीं कर सकते हैं और कुछ समझदार या सत्य प्राप्त कर सकते हैं। इसके अलावा RM धारणाओं की SQL प्रस्तुतियाँ लगभग कभी नहीं वास्तव में आपको एसक्यूएल डेटाबेस में आरएम धारणाओं को अच्छी तरह से लागू करने का तरीका बताता है . वे सिर्फ आरएम प्रस्तुतियों को तोते करते हैं, इस बात से बेखबर कि क्या उनके शब्दों के लिए SQL अर्थों का उपयोग चीजों को निरर्थक या अमान्य बनाता है।
