इस प्रश्नोत्तर के बारे में क्या दिलचस्प है कि वास्तव में 3 प्रश्न हैं। हर किसी ने एक अलग उत्तर दिया है, और लगभग किसी ने भी पहले एक का उत्तर नहीं दिया है:
- क्यों नहीं कर रहे हैं जंगल में कुछ डेटाबेस सामान्यीकृत?
- क्यों / कब एक सामान्यीकृत डेटाबेस को वंचित किया जाना चाहिए ?
- पहली बार में सामान्य करना किन परिस्थितियों में हानिकारक या अनावश्यक है?
सचेतक पाठक ध्यान देंगे कि ये बहुत अलग प्रश्न हैं, और मैं बहुत अधिक विस्तार से बचने के दौरान उनमें से प्रत्येक का अलग-अलग उत्तर देने का प्रयास करूंगा। "बहुत अधिक" से, मेरा मतलब है कि मुझे नहीं लगता कि यह उपयुक्त संदर्भ है जिसमें विभिन्न तर्कों के गुणों पर सामान्यीकरण के पक्ष में या उसके खिलाफ एक विस्तारित बहस को अंजाम दिया जाना है; मैं बस यह समझाने जा रहा हूं कि वे तर्क क्या हैं, शायद कुछ कैविएट को सूचीबद्ध करें, और अधिक विशिष्ट प्रश्नों के लिए दर्शन को बचाएं, अगर वे कभी भी आते हैं।
इसके अलावा, इस उत्तर में मैं मान रहा हूं कि "सामान्यीकरण" का अर्थ है "बीसीएनएफ, 3 एनएफ, या कम से कम 2 एनएफ" , क्योंकि यह सामान्यीकरण का स्तर है जिसे डिजाइनर आमतौर पर प्राप्त करने का लक्ष्य रखते हैं। यह 4NF या 5NF डिज़ाइन देखने के लिए दुर्लभ है; हालांकि वे निश्चित रूप से असंभव लक्ष्य नहीं हैं, वे केवल अपने प्रतिनिधित्व के बजाय रिश्तों के शब्दार्थ के साथ खुद को चिंतित करते हैं , जो कि डोमेन के बारे में काफी अधिक ज्ञान की आवश्यकता होती है।
तो, आगे और ऊपर:
1. क्यों कुछ डेटाबेस में सामान्यीकृत नहीं हैं?
इसका जवाब सकता है "क्योंकि वे नहीं होना चाहिए" हो सकता है, लेकिन यह है कि इस धारणा सही बल्ले से दूर कर रही है सुंदर पेशाब गरीब जासूसी काम है। हम एक समाज के रूप में बहुत प्रगति नहीं करेंगे अगर हम हमेशा इस धारणा पर काम करते हैं कि जो कुछ भी है, वह होना चाहिए।
डेटाबेस में सामान्य नहीं होने के वास्तविक कारण अधिक जटिल हैं। यहाँ शीर्ष 5 हैं जिन्हें मैंने देखा है:
डेवलपर के लिए जिन्होंने तैयार किया गया यह नहीं पता था या समझ में नहीं आया को सामान्य बनाने के लिए। इसके मजबूत प्रमाण बुरे डिजाइन विकल्पों के साथ कई अन्य चीजों के रूप में मिलते हैं, जैसे कि हर चीज के लिए वर्कर कॉलम का उपयोग करना या अर्थहीन तालिका और स्तंभ नामों की स्पैगेटी गड़बड़ होना । और मैं आपको विश्वास दिलाता हूं, मैंने "वास्तविक" डेटाबेस देखे हैं जो टीडब्ल्यूटीटीएफ लेखों में उन लोगों की तरह हर बुरे हैं।
जिन डेवलपर्स ने इसे डिज़ाइन किया था वे सिद्धांत पर ध्यान नहीं देते थे या सामान्य रूप से सक्रिय नहीं थे । ध्यान दें, यहां मैं ऐसे उदाहरणों के बारे में बात नहीं कर रहा हूं, जहां एक जानबूझकर निर्णय प्रासंगिक विश्लेषण के आधार पर सामान्य करने के लिए नहीं किया गया था, बल्कि टीमों या कंपनियों को जहां सामान्यीकरण अधिक-या-कम समझा जाता है, लेकिन बस नजरअंदाज कर दिया जाता है या आदत से बाहर कर दिया जाता है। फिर, आश्चर्यजनक रूप से आम है।
सॉफ्टवेयर एक ब्राउनफील्ड परियोजना के रूप में किया गया है । कई शुद्धतावादी सामान्यीकरण न करने के तकनीकी कारण के बजाय इस पूरी तरह से वैध व्यवसाय की उपेक्षा करते हैं । कभी-कभी आपको वास्तव में खरोंच से एक नया डेटाबेस डिजाइन करने के लिए नहीं मिलता है, आपको एक मौजूदा विरासत स्कीमा पर बोल्ट करना होगा, और उस बिंदु पर सामान्य करने का प्रयास करना होगा जिसमें बहुत अधिक दर्द होगा। 3NF का आविष्कार 1971 तक नहीं किया गया था, और कुछ प्रणालियों - विशेष रूप से वित्तीय / लेखा प्रणालियों - की जड़ें इससे भी ज्यादा दूर हैं!
डेटाबेस को मूल रूप से सामान्यीकृत किया गया था , लेकिन समय की एक लंबी अवधि में छोटे परिवर्तन और / या व्यापक रूप से वितरित टीम ने दोहराव के सूक्ष्म रूपों और सामान्य रूप से जो कुछ भी सामान्य रूप में था, के अन्य उल्लंघन पेश किए। दूसरे शब्दों में, सामान्यीकरण का नुकसान आकस्मिक था , और बहुत कम समय रिफैक्टरिंग पर खर्च किया गया था।
एक जानबूझकर व्यापार निर्णय व्यापार विश्लेषण या डेटाबेस डिजाइन पर किसी भी समय खर्च नहीं करने के लिए किया गया था और बस "इसे पूरा करें"। यह अक्सर एक गलत अर्थव्यवस्था है और अंततः तकनीकी ऋण का एक बढ़ता हुआ रूप बन जाता है , लेकिन कभी-कभी एक तर्कसंगत निर्णय होता है, कम से कम जानकारी के आधार पर जो उस समय ज्ञात थी - उदाहरण के लिए, डेटाबेस का उद्देश्य एक प्रोटोटाइप के रूप में किया गया हो सकता है लेकिन समाप्त हो गया समय की कमी या कारोबारी माहौल में बदलाव के कारण उत्पादन उपयोग को बढ़ावा दिया जा रहा है।
2. क्यों और कब एक सामान्यीकृत डेटाबेस को वंचित किया जाना चाहिए?
इस चर्चा अक्सर आता है जब एक डेटाबेस है के साथ शुरू करने के लिए सामान्यीकृत। या तो प्रदर्शन खराब है या प्रश्नों (जोड़) में बहुत अधिक दोहराव है, और टीम को लगता है, सही या गलत, कि वे वर्तमान डिजाइन के साथ दूर तक जा सकते हैं। यह ध्यान रखना महत्वपूर्ण है कि सामान्यीकरण प्रदर्शन को अधिकांश समय बेहतर बनाता है , और अतिरिक्त ज्वाइन को खत्म करने के लिए कई विकल्प होते हैं जब सामान्यीकरण आपके खिलाफ काम करता हुआ दिखाई देता है, जिनमें से कई बस एक असामान्य मॉडल में बदलने की तुलना में कम आक्रामक और जोखिम भरा होता है:
अनुक्रमित विचार बनाएं जो सबसे आम समस्या क्षेत्रों को घेरता है। आधुनिक DBMSes उन्हें डालने योग्य या अद्यतन करने योग्य बनाने में सक्षम हैं (जैसे SQL सर्वर INSTEAD OFट्रिगर)। यह अंतर्निहित टेबल्स / इंडेक्स पर डीएमएल बयानों के लिए मामूली लागत पर आता है लेकिन आम तौर पर पहला विकल्प आपको प्रयास करना चाहिए क्योंकि इसे खराब करना लगभग असंभव है और लागत को बनाए रखने के लिए लगभग कुछ भी नहीं है। बेशक, प्रत्येक क्वेरी को अनुक्रमित दृश्य में नहीं बदला जा सकता है - समग्र प्रश्न सबसे अधिक परेशानी वाले हैं। जो हमें अगले आइटम की ओर ले जाता है ...
स्वचालित रूप से ट्रिगर्स द्वारा अद्यतन किए जाने वाले हरित सारणी बनाएं। ये टेबल सामान्यीकृत तालिकाओं के अलावा मौजूद हैं और एक प्रकार का CQRS मॉडल बनाते हैं । एक और CQRS मॉडल, इन दिनों अधिक लोकप्रिय है, क्वेरी मॉडल को अपडेट करने के लिए पब / उप का उपयोग करना है, जो अतुल्यकालिक का लाभ देता है, हालांकि यह बहुत दुर्लभ उदाहरणों में उपयुक्त नहीं हो सकता है जहां डेटा बासी नहीं हो सकता है।
कभी-कभी, अनुक्रमित विचार संभव नहीं होते हैं, स्वीकार्य प्रदर्शन के साथ ट्रिगर को स्वीकार करने के लिए लेनदेन की दरें और डेटा वॉल्यूम बहुत अधिक हैं, और प्रश्नों को हमेशा रीयलटाइम डेटा वापस करना होगा। ये स्थितियां दुर्लभ हैं - मुझे लगता है कि वे हाई-फ़्रीक्वेंसी ट्रेडिंग या कानून प्रवर्तन / खुफिया डेटाबेस जैसी चीज़ों पर लागू हो सकते हैं - लेकिन वे मौजूद हो सकते हैं। इन मामलों में आपके पास वास्तव में कोई विकल्प नहीं होता है, लेकिन मूल तालिकाओं को अपभ्रंश करने के लिए।
3. किन स्थितियों में पहली जगह पर इसे सामान्य करना हानिकारक या अनावश्यक है?
वास्तव में, यहाँ कई अच्छे उदाहरण हैं:
यदि डेटाबेस का उपयोग केवल रिपोर्टिंग / विश्लेषण के लिए किया जा रहा है । आमतौर पर इसका तात्पर्य है कि ओएलटीपी के लिए उपयोग किया जा रहा एक अतिरिक्त , सामान्यीकृत डेटाबेस है, जो समय-समय पर ईटीएल या मैसेजिंग के माध्यम से विश्लेषण डेटाबेस के लिए सिंक्रनाइज़ किया जाता है।
जब एक सामान्य मॉडल लागू करने के लिए आने वाले डेटा का अनावश्यक रूप से जटिल विश्लेषण की आवश्यकता होगी। इसका एक उदाहरण एक ऐसी प्रणाली हो सकती है जिसे कई बाहरी प्रणालियों या डेटाबेस से एकत्र किए गए फोन नंबरों को संग्रहीत करने की आवश्यकता होती है। आप कॉल कोड और क्षेत्र कोड को असामान्य कर सकते हैं , लेकिन आपको विभिन्न स्थानों का उल्लेख नहीं करने के लिए सभी संभावित प्रारूपों, अमान्य फ़ोन नंबर, वैनिटी नंबर (1-800-GET-STUFF) के लिए खाता बनाना होगा। यह आमतौर पर इसके लायक होने की तुलना में अधिक परेशानी है, और फोन नंबर आमतौर पर केवल एक ही क्षेत्र में छोड़े जाते हैं जब तक कि आपके पास क्षेत्र कोड के लिए विशिष्ट व्यवसाय की आवश्यकता न हो ।
जब रिलेशनल डेटाबेस मुख्य रूप से एक अतिरिक्त, गैर-रिलेशनल डेटाबेस के लिए लेन-देन का समर्थन प्रदान करने के लिए होता है। उदाहरण के लिए, आप रिलेशनल डेटाबेस का उपयोग संदेश कतार के रूप में, या लेन-देन या गाथा की स्थिति को ट्रैक करने के लिए कर सकते हैं, जब प्राथमिक डेटा Redis या MongoDB में या जो भी संग्रहीत किया जा रहा हो। दूसरे शब्दों में, डेटा "नियंत्रण डेटा" है। आमतौर पर डेटा को सामान्य करने का कोई मतलब नहीं है जो वास्तव में व्यावसायिक डेटा नहीं है ।
सेवा-उन्मुख आर्किटेक्चर जो एक भौतिक डेटाबेस साझा करते हैं। यह थोड़ा अजीब है, लेकिन एक सच्चे SOA में, आपको कभी-कभार शारीरिक रूप से डुप्लिकेट होने के लिए डेटा की आवश्यकता होगी क्योंकि सेवाओं को एक दूसरे के डेटा को सीधे क्वेरी करने की अनुमति नहीं है। अगर वे ऐसा ही भौतिक डेटाबेस को साझा करने, डाटा होगा दिखाई सामान्यीकृत करने के लिए नहीं - लेकिन आम तौर पर, प्रत्येक व्यक्ति सेवा के स्वामित्व वाला डेटा है अभी भी सामान्य जब तक कि अन्य कम करने वाले कारकों में से एक ही स्थान पर है। उदाहरण के लिए, एक बिलिंग सेवा बिल इकाई की मालिक हो सकती है, लेकिन लेखा सेवा को उस वर्ष के लिए राजस्व में शामिल करने के लिए बिल दिनांक और राशि प्राप्त करने और संग्रहीत करने की आवश्यकता होती है।
मुझे यकीन है कि अधिक कारण हैं जो मैंने सूचीबद्ध नहीं किए हैं; जो मुझे मिल रहा है, संक्षेप में, यह है कि वे काफी विशिष्ट हैं और व्यवहार में आने पर काफी स्पष्ट होंगे। OLAP डेटाबेस को स्टार स्कीमा का उपयोग करने के लिए माना जाता है, SOA को कुछ दोहराव आदि के रूप में माना जाता है, यदि आप एक प्रसिद्ध आर्किटेक्चर मॉडल के साथ काम कर रहे हैं जो बस सामान्यीकरण के साथ काम नहीं करता है, तो आप सामान्य नहीं करते हैं; सामान्यतया, आर्किटेक्चर मॉडल डेटा मॉडल पर पूर्वता लेता है।
और बहुत अंतिम प्रश्न का उत्तर देने के लिए:
क्या यह सच है कि अच्छे आर्किटेक्ट और विशेषज्ञ एक असमान्य डिजाइन चुनते हैं जबकि गैर-अनुभवी डेवलपर्स इसके विपरीत चुनते हैं? मन में सामान्यीकरण के साथ अपने डिजाइन को शुरू करने के खिलाफ तर्क क्या हैं?
नहीं, यह पूरी तरह से है और बी एस बीएस इट्स बीएस भी है कि विशेषज्ञ हमेशा एक सामान्यीकृत डिजाइन चुनते हैं । विशेषज्ञ सिर्फ एक मंत्र का पालन नहीं करते हैं। वे शोध करते हैं, विश्लेषण करते हैं, चर्चा करते हैं, स्पष्ट करते हैं और पुनरावृति करते हैं, और फिर वे चुनते हैं जो भी दृष्टिकोण उनकी विशेष स्थिति के लिए सबसे अधिक समझ में आता है।
3NF या BCNF डेटाबेस आमतौर पर विश्लेषण के लिए एक अच्छा शुरुआती बिंदु है क्योंकि यह पूरी दुनिया में दसियों हज़ारों परियोजनाओं में आजमाया और सिद्ध किया गया है, लेकिन फिर से, इसलिए सी। का मतलब यह नहीं है कि हम स्वचालित रूप से हर में सी का उपयोग करते हैं। नया काम। वास्तविक दुनिया की स्थितियों में मॉडल के लिए कुछ संशोधनों या पूरी तरह से एक अलग मॉडल के उपयोग की आवश्यकता हो सकती है। जब तक आप कर रहे हैं आप नहीं जानते कि में उस स्थिति।