वस्तु-संबंधपरक प्रतिबाधा बेमेल
वस्तु-संबंधपरक प्रतिबाधा बेमेल वैचारिक और विधियों की कठिनाइयों का सेट है जो अधिकांशतः तब सामने आती है जब संगठन रिलेशनल डेटा स्टोर्स ( संबंधपरक डेटाबेस प्रबंधन प्रणाली [“आरडीबीएमएस”]) में डेटा संग्रहीत करते हैं और फिर डोमेन-संचालित ऑब्जेक्ट मॉडल के माध्यम से इस डेटा का उपयोग करते हैं, ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग भाषाओं में व्यवसाय-केंद्रित वस्तुओं को प्रयुक्त करने की डिफ़ॉल्ट विधि। समस्याएँ डेटा को रिलेशनल या डोमेन ऑब्जेक्ट के रूप में संबोधित करने में विफलता से उत्पन्न नहीं होती हैं, बल्कि दो वैचारिक रूप से भिन्न तर्क मॉडल के डेटा मानों के मध्य डेटा मानचित्रणिंग को प्रयुक्त करने की कठिनाई के परिणामस्वरूप उत्पन्न होती हैं; दोनों मॉडल तार्किक मॉडल हैं जिन्हें उपयोग की गई विधियों (डेटाबेस सर्वर, प्रोग्रामिंग भाषा, डिज़ाइन पैटर्न इत्यादि) के आधार पर अलग-अलग विधि से प्रयुक्त किया जा सकता है। ये मुद्दे केवल अनुप्रयोगों तक ही सीमित नहीं हैं, बल्कि उद्यम में उपस्थित हैं, जब भी डेटा को रिलेशनल विधि से संग्रहीत किया जाता है तब डोमेन-संचालित ऑब्जेक्ट मॉडल के रूप में उपयोग किया जाता है, और इसके विपरीत। इन कठिनाइयों को कभी-कभी ऑब्जेक्ट-ओरिएंटेड डेटा स्टोर के उपयोग से कम किया जाता है, किन्तुइसकी भी कार्यान्वयन कठिनाइयों का अपना सेट होता है।
वस्तु-संबंधपरक प्रतिबाधा बेमेल शब्द विद्युत अभियन्त्रण शब्द प्रतिबाधा मिलान से लिया गया है।
बेमेल
वस्तुएं (उदाहरण) दूसरे को संदर्भित करती हैं और इसलिए गणितीय अर्थ में निर्देशित ग्राफ बनाती हैं (लूप और चक्र सहित नेटवर्क)। इसके विपरीत, संबंधपरक स्कीमा सारणीबद्ध होती हैं और संबंधपरक बीजगणित पर आधारित होती हैं, जो जुड़े हुए विषम टुपल्स (प्रत्येक क्षेत्र के लिए अलग-अलग प्रकारों के साथ डेटा फ़ील्ड को "पंक्ति" में समूहित करना) को परिभाषित करती हैं, जहां लिंक सदैव प्रतिवर्ती होते हैं (विदेशी कुंजी को पीछे की ओर ले जाया जा सकता है, चूँकि INNER JOIN सममित है), जो अप्रत्यक्ष ग्राफ़ के समान विशेषता है।
वस्तु-उन्मुख अवधारणाएँ
एनकैप्सुलेशन
ऑब्जेक्ट-ओरिएंटेड प्रोग्राम ऐसी विधियों ों के साथ डिज़ाइन किए गए हैं जिनके परिणामस्वरूप एनकैप्सुलेशन (ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग) ऑब्जेक्ट होते हैं जिनका आंतरिक प्रतिनिधित्व छिपाया जा सकता है। ऑब्जेक्ट-ओरिएंटेड फ्रेमवर्क में, किसी दिए गए ऑब्जेक्ट के अंतर्निहित गुणों को ऑब्जेक्ट के साथ प्रयुक्त इंटरफ़ेस के बाहर किसी भी इंटरफ़ेस के संपर्क में नहीं आने की उम्मीद की जाती है। चूँकि, अधिकांश ऑब्जेक्ट-रिलेशनल मानचित्रणिंग दृष्टिकोण किसी ऑब्जेक्ट की अंतर्निहित सामग्री को इंटरफ़ेस के साथ इंटरैक्ट करने के लिए उजागर करते हैं जिसे ऑब्जेक्ट कार्यान्वयन निर्दिष्ट नहीं कर सकता है। इसलिए, यह ऑब्जेक्ट-रिलेशनल मानचित्रणिंग ऑब्जेक्ट के एनकैप्सुलेशन का उल्लंघन करती है, क्योंकि अनेक ऑब्जेक्ट-रिलेशनल मानचित्रणर स्वचालित रूप से डेटाबेस कॉलम के अनुरूप सार्वजनिक फ़ील्ड उत्पन्न करते हैं। कुछ फ्रेमवर्क इसके अतिरिक्त मेटाप्रोग्रामिंग विधियों का उपयोग करते हैं, इस प्रकार इनकैप्सुलेशन का उल्लंघन करने से बचते हैं।
अभिगम्यता
संबंधपरक सोच में, निजी बनाम सार्वजनिक पहुंच आवश्यकता के सापेक्ष है। ऑब्जेक्ट-ओरिएंटेड (OO) मॉडल में यह डेटा की स्थिति की पूर्ण विशेषता है। संबंधपरक और OO मॉडल में अधिकांशतः सापेक्षता बनाम वर्गीकरण और विशेषताओं की निरपेक्षता पर टकराव होता है।
इंटरफ़ेस, वर्ग, वंशानुक्रम और बहुरूपता
ऑब्जेक्ट-ओरिएंटेड प्रतिमान के अनुसार, ऑब्जेक्ट में इंटरफ़ेस (कंप्यूटर विज्ञान) होते हैं जो साथ उस ऑब्जेक्ट के आंतरिक तक मात्र पहुंच प्रदान करते हैं। दूसरी ओर, संबंधपरक मॉडल अखंडता सुनिश्चित करने के लिए अलग-अलग दृष्टिकोण और बाधाएं प्रदान करने के लिए व्युत्पन्न संबंध चर देखें (डेटाबेस) (विचार) का उपयोग करता है। इसी प्रकार, वस्तुओं के वर्गों, वंशानुक्रम (कंप्यूटर विज्ञान) और बहुरूपता (कंप्यूटर विज्ञान) के लिए आवश्यक ओओपी अवधारणाएँ, रिलेशनल डेटाबेस प्रणाली द्वारा समर्थित नहीं हैं।
संबंधपरक अवधारणाओं का मानचित्रण
संबंधपरक अवधारणाओं और वस्तु-उन्मुख अवधारणाओं के मध्य उचित मानचित्रण बनाया जा सकता है यदि संबंधपरक डेटाबेस तालिकाओं को वस्तु-उन्मुख विश्लेषण में पाए जाने वाले संघों (वस्तु-उन्मुख प्रोग्रामिंग) से जोड़ा जाता है [आगे स्पष्टीकरण की आवश्यकता है]।
डेटा प्रकार अंतर
वर्तमान रिलेशनल और OO भाषाओं के मध्य बड़ा बेमेल प्रकार प्रणाली अंतर है। संबंधपरक मॉडल सख्ती से उप-संदर्भ विशेषताओं (या सूचक (कंप्यूटर प्रोग्रामिंग)) को प्रतिबंधित करता है, जबकि ओओ भाषाएं उप-संदर्भ व्यवहार को अपनाती हैं और उसकी अपेक्षा करती हैं। अदिश (कंप्यूटिंग) प्रकार और उनके ऑपरेटर शब्दार्थ मॉडल के मध्य अधिक भिन्न हो सकते हैं, जिससे मानचित्रणिंग में समस्याएं उत्पन्न हो सकती हैं।
उदाहरण के लिए, अधिकांश एसक्यूएल प्रणाली अलग-अलग संयोजनों और सीमित अधिकतम लंबाई के साथ स्ट्रिंग (कंप्यूटर विज्ञान) प्रकारों का समर्थन करते हैं (ओपन-एंडेड टेक्स्ट प्रकार प्रदर्शन में बाधा डालते हैं), जबकि अधिकांश ओओ भाषाएं संयोजन को केवल सॉर्ट एल्गोरिथ्म करने के लिए तर्क के रूप में मानती हैं और स्ट्रिंग्स आंतरिक रूप से उपलब्ध मेमोरी के आकार की होती हैं। अधिक सूक्ष्म, किन्तुसंबंधित उदाहरण यह है कि एसक्यूएल प्रणाली अधिकांशतः तुलना के प्रयोजनों के लिए स्ट्रिंग में पिछली व्हाइटस्पेस (कंप्यूटर विज्ञान) को अनदेखा कर देते हैं, जबकि OO स्ट्रिंग लाइब्रेरीज़ ऐसा नहीं करते हैं। ओओ भाषा में अन्य आदिम प्रकारों के संभावित मूल्यों को सीमित करने के स्थिति में नए डेटा प्रकारों का निर्माण करना सामान्यतः संभव नहीं है।
संरचनात्मक और अखंडता अंतर
एक और बेमेल का संबंध विपरीत मॉडलों के संरचनात्मक और अखंडता पहलुओं में अंतर से है। ओओ भाषाओं में, वस्तुओं को अन्य वस्तुओं से बनाया जा सकता है - अधिकांशतः उच्च स्तर तक - या अधिक सामान्य परिभाषा से विशेषज्ञ। इससे रिलेशनल स्कीमों की मानचित्रणिंग कम सरल हो सकती है। ऐसा इसलिए है क्योंकि रिलेशनल डेटा को वैश्विक, अननेस्टेड रिलेशन वेरिएबल्स के नामित सेट में दर्शाया जाता है। स्वयं संबंध, ही हेडर के अनुरूप टुपल्स के सेट होने के कारण (टपल रिलेशनल कैलकुलस देखें) ओओ भाषाओं में कोई आदर्श समकक्ष नहीं है। ओओ भाषाओं में बाधाओं को सामान्यतः इस तरह घोषित नहीं किया जाता है, किन्तुएन्कैप्सुलेटेड आंतरिक डेटा पर काम करने वाले कोड के आसपास सुरक्षा तर्क बढ़ाने वाले अपवाद के रूप में प्रकट होते हैं। दूसरी ओर, रिलेशनल मॉडल, अदिश प्रकार, विशेषताओं, संबंध चर और संपूर्ण डेटाबेस पर घोषणात्मक प्रोग्रामिंग बाधाओं की मांग करता है।
जोड़ तबड़ मतभेद
चूँकि, अर्थ संबंधी अंतर विशेष रूप से विपरीत मॉडलों के हेरफेर पहलुओं में स्पष्ट हैं। रिलेशनल मॉडल में क्वेरी और डेटा के हेरफेर में उपयोग के लिए आदिम ऑपरेटरों का आंतरिक, अपेक्षाकृत छोटा और अच्छी तरह से परिभाषित सेट होता है, जबकि ओओ भाषाएं सामान्यतः कस्टम-निर्मित या निचले स्तर, केस- और भौतिक-पहुंच के माध्यम से क्वेरी और हेरफेर को संभालती हैं। -पथ-विशिष्ट अनिवार्य प्रोग्रामिंग संचालन। कुछ OO भाषाओं में घोषणात्मक क्वेरी उपभाषाओं के लिए समर्थन होता है, किन्तुक्योंकि OO भाषाएँ सामान्यतः सूचियों और संभवतः हैश तालिकाओ से निपटती हैं, इसलिए जोड़-तबड़ करने वाले आदिम आवश्यक रूप से संबंधपरक मॉडल के सेट (कंप्यूटर विज्ञान)-आधारित संचालन से अलग होते हैं।
लेन-देन संबंधी मतभेद
समवर्ती और लेन-देन के पहलू भी अधिक भिन्न हैं। विशेष रूप से,डेटाबेस लेनदेन, डेटाबेस द्वारा किए गए कार्य की सबसे छोटी इकाई, ओओ भाषाओं में कक्षाओं द्वारा किए गए किसी भी ऑपरेशन की तुलना में संबंधपरक डेटाबेस में बहुत बड़ी होती है। रिलेशनल डेटाबेस में लेनदेन इच्छानुसारसे डेटा हेरफेर के गतिशील रूप से बंधे हुए सेट होते हैं, जबकि ओओ भाषा में लेनदेन की ग्रैन्युलैरिटी सामान्यतः आदिम-टाइप किए गए फ़ील्ड के लिए व्यक्तिगत असाइनमेंट के स्तर पर होती है। सामान्यतः, OO भाषाओं में अलगाव या स्थायित्व का कोई एनालॉग नहीं होता है, इसलिए परमाणुता और स्थिरता केवल उन आदिम प्रकारों के क्षेत्रों में लिखते समय सुनिश्चित की जाती है।
प्रतिबाधा बेमेल को हल करना
ऑब्जेक्ट-ओरिएंटेड प्रोग्रामों के लिए प्रतिबाधा बेमेल समस्या के आसपास काम करना नियोजित किए जा रहे विशिष्ट तर्क प्रणालियों में अंतर की पहचान के साथ प्रारंभिक होता है। फिर बेमेल को या तब कम कर दिया जाता है या उसकी भरपाई कर दी जाती है।[1]
वैकल्पिक आर्किटेक्चर
ऑब्जेक्ट-रिलेशनल प्रतिबाधा बेमेल समस्या OO और डेटाबेस के मध्य सार्वभौमिक समस्या नहीं है। जैसा कि नाम से पता चलता है, यह प्रतिबाधा समस्या केवल संबंधपरक डेटाबेस के साथ होती है। इस समस्या का सबसे आम समाधान वैकल्पिक डेटाबेस, जैसे NoSQL या XML डेटाबेस का उपयोग करना है।
न्यूनीकरण
ऑब्जेक्ट ओरिएंटेड डेटाबेस मैनेजमेंट प्रणाली (ओओडीबीएमएस) बनाने के कुछ प्रयास किए गए हैं जो प्रतिबाधा बेमेल समस्या से बचेंगे। चूँकि, वे संबंधपरक डेटाबेस की तुलना में व्यवहार में कम सफल रहे हैं, आंशिक रूप से डेटा मॉडल के आधार के रूप में OO सिद्धांतबं की सीमाओं के कारण। [2] सॉफ़्टवेयर ट्रांसेक्शनल मेमोरीजैसी धारणाओं के माध्यम से ओओ भाषाओं की डेटाबेस जैसी क्षमताओं को विस्तारित करने पर शोध किया गया है।
प्रतिबाधा बेमेल समस्या का सामान्य समाधान डोमेन और फ्रेमवर्क तर्क को परत करना है। इस योजना में, OO भाषा का उपयोग अधिक स्थिर मानचित्रण के प्रयास के अतिरिक्त रनटाइम पर कुछ संबंधपरक पहलुओं को मॉडल करने के लिए किया जाता है। इस विधि को नियोजित करने वाले फ़्रेमवर्क में सामान्यतः टुपल के लिए एनालॉग होगा, सामान्यतः "डेटासेट" घटक में "पंक्ति" के रूप में या सामान्य "इकाई उदाहरण" वर्ग के रूप में, साथ ही किसी संबंध के लिए एनालॉग भी होगा। इस दृष्टिकोण के लाभों में सम्मिलित हो सकते हैं:
- डोमेन डेटा के परिवहन, प्रस्तुति और सत्यापन के आसपास ढांचे और स्वचालन के निर्माण के लिए सीधे रास्ते होते हैं ।
- छोटा कोड आकार; तेज़ संकलन और लोड समय।
- डेटाबेस स्कीमा को गतिशील रूप से बदलने की क्षमता।
- नाम-स्थान और अर्थ संबंधी बेमेल मुद्दों से बचा जाता है।
- अभिव्यंजक बाधा जाँच
- कोई जटिल मानचित्रण आवश्यक नहीं
हानि में सम्मिलित हो सकते हैं:
- स्थैतिक प्रकार की "सुरक्षा" जांच का अभाव। टाइप किए गए सेंसर्स का उपयोग कभी-कभी इसे कम करने के विधि के रूप में किया जाता है।
- रनटाइम निर्माण और पहुंच की संभावित प्रदर्शन निवेश होता हैं।
- ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग में बहुरूपता जैसे विशिष्ट OO पहलुओं का मूल रूप से उपयोग करने में असमर्थता होती हैं।
मुआवजा
ओओ एप्लिकेशन कोड के अंदर प्रवचन के स्तरो का मिश्रण समस्याएं प्रस्तुत करता है, किन्तुक्षतिपूर्ति के लिए कुछ सामान्य तंत्रों का उपयोग किया जाता है। सबसे बड़ी चुनौती चर्चा के उस स्तर के अंदर फ्रेमवर्क समर्थन, डेटा हेरफेर और प्रस्तुति पैटर्न का स्वचालन प्रदान करना है जिसमें डोमेन डेटा को मॉडल किया जा रहा है। इसे संबोधित करने के लिए, प्रतिबिंब और/या स्वचालित प्रोग्रामिंग का उपयोग किया जाता है। प्रतिबिंब कोड (वर्गों) को डेटा के रूप में संबोधित करने की अनुमति देता है और इस प्रकार डेटा के परिवहन, प्रस्तुति, अखंडता आदि का स्वचालन प्रदान करता है। जनरेशन इकाई संरचनाओं को कोड जनरेशन टूल या मेटा-प्रोग्रामिंग भाषाओं के लिए डेटा इनपुट के रूप में संबोधित करके समस्या का समाधान करता है, जो सामूहिक रूप से कक्षाओं और सहायक मूलभूत ढांचे का निर्माण करते हैं। ये दोनों योजनाएँ अभी भी कुछ विसंगतियों के अधीन हो सकती हैं जहाँ चर्चा के ये स्तर विलीन हो जाते हैं। उदाहरण के लिए, जेनरेट की गई इकाई कक्षाओं में सामान्यतः ऐसे गुण होंगे जो डोमेन पर मानचित्र होते हैं (उदाहरण के लिए नाम, पता) और साथ ही ऐसे गुण जो राज्य प्रबंधन और अन्य ढांचे के मूलभूत ढांचे (उदाहरण के लिए IsModified) प्रदान करते हैं।
घटना
यद्यपि ऑब्जेक्ट-रिलेशनल प्रतिबाधा बेमेल सामान्य रूप से ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग के साथ हो सकता है, कठिनाई का विशेष क्षेत्र ऑब्जेक्ट रिलेशनल मानचित्रणर्स (ओआरएम) के साथ है।[3] चूँकि ओएमआर को अधिकांशतः कॉन्फ़िगरेशन, एनोटेशन और प्रतिबंधित डोमेन-विशिष्ट भाषाओं के संदर्भ में निर्दिष्ट किया जाता है, इसलिए इसमें प्रतिबाधा बेमेल को हल करने के लिए पूर्ण प्रोग्रामिंग भाषा के लचीलेपन का अभाव होता है।
विवाद
सच्चा आरडीबीएमएस मॉडल
क्रिस्टोफर जे. डेट और अन्य लोगों द्वारा यह तर्क दिया गया है कि वास्तव में संबंधपरक डीबीएमएस ऐसी कोई समस्या उत्पन्न नहीं करेगा,[4][5][6] चूँकि डेटा डोमेन और क्लास (कंप्यूटर विज्ञान) अनिवार्य रूप से ही चीज़ हैं। कक्षाओं और संबंधपरक स्कीमाटा के मध्य मूल मानचित्रण मौलिक डिजाइन गलती है;[7] और डेटाबेस तालिका (संबंध) के अंदर व्यक्तिगत टुपल्स को संस्थाओं के मध्य संबंध स्थापित करने के रूप में देखा जाना चाहिए; स्वयं जटिल संस्थाओं के प्रतिनिधित्व के रूप में नहीं। चूँकि, यह दृश्य ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग के प्रभाव और भूमिका को कम कर देता है, इसे फ़ील्ड प्रकार प्रबंधन प्रणाली से थोड़ा अधिक उपयोग करता है।
बाधाएं और अवैध लेनदेन
प्रतिबाधा बेमेल डोमेन ऑब्जेक्ट और उपयोगकर्ता इंटरफ़ेस के मध्य प्रोग्रामिंग में है। ऑपरेटरों, प्रबंधकों और अन्य गैर-प्रोग्रामरों को डेटाबेस में रिकॉर्ड तक पहुंचने और हेरफेर करने की अनुमति देने के लिए परिष्कृत उपयोगकर्ता इंटरफ़ेस के लिए अधिकांशतः विभिन्न डेटाबेस विशेषताओं (नाम और प्रकार से परे) की प्रकृति के बारे में गहन ज्ञान की आवश्यकता होती है। विशेष रूप से, उपयोगकर्ता इंटरफ़ेस को डिज़ाइन करना अच्छा अभ्यास माना जाता है (अंतिम-उपयोगकर्ता उत्पादकता के दृष्टिकोण से) जिससे यूआई अवैध लेनदेन (जो डेटाबेस बाधा का उल्लंघन करते हैं) को प्रवेश करने से रोक सके; ऐसा करने के लिए कोड दोहराव रिलेशनल स्कीमाटा में उपस्थित अधिकांश तर्क को कोड में डुप्लिकेट करने की आवश्यकता होती है।
कुछ कोड-विकास ढाँचे डेटाबेस के स्कीमा (जैसे संदर्भात्मक अखंडता बाधाएं) में दर्शाए गए तर्क के कुछ रूपों का लाभ उठा सकते हैं, जिससे ऐसे मुद्दों को किसी स्थिति पर लिखे गए तदर्थ कोड के अतिरिक्त लाइब्रेरी रूटीन के माध्यम से सामान्य और मानक फैशन में नियंत्रितजा सके। -मामला-दर-मामला आधार।
SQL-विशिष्ट प्रतिबाधा और समाधान
यह तर्क दिया गया है कि SQL, डोमेन प्रकारों के बहुत सीमित सेट (और अन्य कथित त्रुटियों) के कारण उचित ऑब्जेक्ट और डोमेन-मॉडलिंग को कठिन बना देता है; और यह कि SQL DBMS और एप्लिकेशन प्रोग्राम (चाहे ऑब्जेक्ट-ओरिएंटेड शैली में लिखा गया हो या नहीं) के मध्य बहुत ही हानिपूर्ण और अकुशल इंटरफ़ेस बनाता है। चूँकि, SQL वर्तमान में बाज़ार में मात्र व्यापक रूप से स्वीकृत सामान्य डेटाबेस भाषा है; विक्रेता-विशिष्ट क्वेरी भाषाओं का उपयोग टाले जाने योग्य होने पर खराब अभ्यास के रूप में देखा जाता है। अन्य डेटाबेस भाषाएँ जैसे बिजनेस प्रणाली 12 और ट्यूटोरियल डी प्रस्तावित की गई हैं; किन्तुइनमें से किसी को भी डीबीएमएस विक्रेताओं द्वारा व्यापक रूप से नहीं अपनाया गया है।
Oracle और Microsoft SQL सर्वर जैसे मुख्यधारा ऑब्जेक्ट-रिलेशनल DBMS के वर्तमान संस्करणों में, उपरोक्त बिंदु गैर-उद्देश्य हो सकता है। इन इंजनों के साथ, किसी दिए गए डेटाबेस की कार्यक्षमता को आधुनिक OO भाषा (Oracle के लिए Java, और SQL सर्वर के लिए Microsoft .NET भाषा) में लिखे गए संग्रहीत कोड (फ़ंक्शन और प्रक्रियाओं) के माध्यम से इच्छानुसारसे बढ़ाया जा सकता है, और इन कार्यों को प्रयुक्त किया जा सकता है SQL कथनों को पारदर्शी विधि से इन-टर्न करें: अर्थात, उपयोगकर्ता को न तब पता है और न ही इसकी परवाह है कि ये फ़ंक्शन/प्रक्रियाएँ मूल रूप से डेटाबेस इंजन का हिस्सा नहीं थीं। आधुनिक सॉफ्टवेयर-विकास प्रतिमान पूरी तरह से समर्थित हैं: इस प्रकार, कोई लाइब्रेरी रूटीन का सेट बना सकता है जिसे अनेक डेटाबेस स्कीमा में पुन: उपयोग किया जा सकता है
इन विक्रेताओं ने DBMS बैक-एंड पर OO-भाषा एकीकरण का समर्थन करने का निर्णय लिया क्योंकि उन्हें मनोभाव हुआ कि, SQL में प्रक्रियात्मक निर्माणों को जोड़ने के लिए ISO SQL-99 समिति के प्रयासों के अतिरिक्त, SQL में पुस्तकालयों और डेटा संरचनाओं का समृद्ध सेट कभी नहीं होगा। आज के एप्लिकेशन प्रोग्रामर इसे हल्के में लेते हैं, और मुख्य SQL भाषा का विस्तार करने का प्रयास करने के अतिरिक्त इनका यथासंभव सीधे लाभ उठाना उचित है। परिणाम स्वरुप , "एप्लिकेशन प्रोग्रामिंग" और "डेटाबेस प्रशासन" के मध्य का अंतर अभी धुंधला हो गया है: बाधाओं और ट्रिगर्स जैसी सुविधाओं के शक्तिशाली कार्यान्वयन के लिए अधिकांशतः दोहरे डीबीए/ओओ-प्रोग्रामिंग कौशल वाले व्यक्ति या इन कौशलों को संयोजित करने वाले व्यक्तियों के मध्य साझेदारी की आवश्यकता हो सकती है। . यह तथ्य नीचे दिए गए "जिम्मेदारी के विभाजन" मुद्दे पर भी प्रयुक्त होता है।
चूँकि, कुछ लोग यह कहेंगे कि यह विवाद इस तथ्य के कारण विवादास्पद है कि: (1) आरडीबीएमएस का उद्देश्य कभी भी ऑब्जेक्ट मॉडलिंग की सुविधा प्रदान करना नहीं था, और (2) एसक्यूएल को सामान्यतः केवल हानिपूर्ण या अक्षम इंटरफ़ेस भाषा के रूप में देखा जाना चाहिए जब कोई हो ऐसा समाधान प्राप्त करने का प्रयास किया जा रहा है जिसके लिए RDBMSes डिज़ाइन नहीं किए गए थे। SQL वह काम करने में बहुत कुशल है जिसके लिए इसे डिज़ाइन किया गया था, अर्थात् डेटा के बड़े सेट को क्वेरी करना, सॉर्ट करना, फ़िल्टर करना और संग्रहीत करना। कुछ लोग अतिरिक्त रूप से इंगित करेंगे कि बैक-एंड में ओओ भाषा कार्यक्षमता को सम्मिलित करने से खराब वास्तुशिल्प अभ्यास की सुविधा मिलती है, क्योंकि यह आरडीबीएमएस के विपरीत, डेटा स्तर में उच्च स्तरीय एप्लिकेशन तर्क को स्वीकार करता है।
डेटा की कैनोनिकल प्रतिलिपि का स्थान
यहां राज्य की विहित प्रति स्थित है। डेटाबेस मॉडल सामान्यतः मानता है कि डेटाबेस प्रबंधन प्रणाली उद्यम से संबंधित राज्य का मात्र आधिकारिक भंडार है; किसी एप्लिकेशन प्रोग्राम द्वारा रखी गई ऐसी स्थिति की कोई भी प्रतिलिपि बस यही है – अस्थायी प्रतियां (जो पुरानी हो सकती हैं, यदि अंतर्निहित डेटाबेस रिकॉर्ड को बाद में किसी लेनदेन द्वारा संशोधित किया गया हो)। अनेक ऑब्जेक्ट-ओरिएंटेड प्रोग्रामर ऑब्जेक्ट के इन-मेमोरी अभ्यावेदन को कैनोनिकल डेटा के रूप में देखना पसंद करते हैं, और डेटाबेस को बैकिंग स्टोर और दृढ़ता तंत्र के रूप में देखना पसंद करते हैं।
उत्तरदायित्व का विभाजन
विवाद का अन्य उद्देश्य एप्लिकेशन प्रोग्रामर और डेटाबेस प्रशासक (डीबीए) के मध्य जिम्मेदारी का उचित विभाजन है। अधिकांशतः ऐसा होता है कि एप्लिकेशन कोड में आवश्यक बदलावों के लिए (अनुरोधित नई सुविधा या कार्यक्षमता को प्रयुक्त करने के लिए) डेटाबेस परिभाषा में संबंधित बदलावों की आवश्यकता होती है; अधिकांश संगठनों में, डेटाबेस परिभाषा डीबीए की ज़िम्मेदारी है। उत्पादन डेटाबेस प्रणाली को 24 घंटे बनाए रखने की आवश्यकता के कारण अनेक डीबीए डेटाबेस स्कीमाटा में ऐसे बदलाव करने के लिए अनिच्छुक हैं जिन्हें वे अनावश्यक या अनावश्यक मानते हैं और कुछ स्थितियों में ऐसा करने से सीधे अस्वीकार कर देते हैं। विकासात्मक डेटाबेस का उपयोग (उत्पादन प्रणालियों के अतिरिक्त) कुछ सीमा तक सहायता कर सकता है; किन्तुजब नया विकसित एप्लिकेशन लाइव होगा तब डीबीए को किसी भी बदलाव को मंजूरी देने की आवश्यकता होगी। कुछ प्रोग्रामर इसे अकर्मण्यता के रूप में देखते हैं; चूँकि, यदि डेटाबेस परिभाषा में कोई भी बदलाव उत्पादन प्रणाली में सेवा की हानि का कारण बनता है, तब डीबीए को अधिकांशतः जिम्मेदार ठहराया जाता है - परिणामस्वरूप, अनेक डीबीए एप्लिकेशन कोड में डिज़ाइन परिवर्तन सम्मिलित करना पसंद करते हैं, जहां डिज़ाइन दोषों के भयावह परिणाम होने की संभावना बहुत कम होती है।
चूंकि, डीबीए और डेवलपर्स के मध्य गैर-अकार्यात्मक संबंध वाले संगठनों में, उपरोक्त उद्देश्य खुद को प्रस्तुत नहीं करना चाहिए, क्योंकि डेटाबेस स्कीमा को बदलने या न करने का निर्णय केवल व्यावसायिक जरूरतबं से प्रेरित होगा: अतिरिक्त डेटा को बनाए रखने के लिए नई आवश्यकता या ए उदाहरण के लिए, महत्वपूर्ण एप्लिकेशन के प्रदर्शन को बढ़ावा देने से स्कीमा संशोधन प्रारंभिक हो जाएगा।
दार्शनिक मतभेद
OO और संबंधपरक मॉडल के मध्य प्रमुख दार्शनिक अंतरों को निम्नानुसार संक्षेपित किया जा सकता है |
- घोषणात्मक बनाम अनिवार्य इंटरफेस – संबंधपरक सोच डेटा को इंटरफ़ेस के रूप में उपयोग करती है, व्यवहार को इंटरफ़ेस के रूप में नहीं। इस प्रकार इसमें ओओ के व्यवहारिक झुकाव के विपरीत डिजाइन दर्शन में घोषणात्मक झुकाव है। (कुछ संबंधपरक प्रस्तावक जटिल व्यवहार प्रदान करने के लिए ट्रिगर्स, संग्रहीत प्रक्रियाओं आदि का उपयोग करने का सुझाव देते हैं, किन्तुयह सामान्य दृष्टिकोण नहीं है।)
- स्कीमा बाउंड - ऑब्जेक्ट को "पैरेंट स्कीमा" का पालन करने की आवश्यकता नहीं होती है जिसके लिए किसी ऑब्जेक्ट के गुण या एक्सेसर्स होते हैं, जबकि तालिका पंक्तियों को इकाई की स्कीमा का पालन करना होगा। दी गई पंक्ति और केवल इकाई से संबंधित होनी चाहिए। OO में निकटतम चीज़ वंशानुक्रम है, किन्तुयह सामान्यतः पेड़ के आकार का और वैकल्पिक है। गतिशील डेटाबेस प्रणालियाँ जो तदर्थ स्तंभों की अनुमति देती हैं, स्कीमा बाध्यता को शिथिल कर सकती हैं, किन्तुऐसी प्रणालियाँ या तब वर्तमान में दुर्लभ हैं, या "संबंधपरक" के रूप में उनका वर्गीकरण प्रश्न में है।
- प्रवेश नियम – रिलेशनल डेटाबेस में, विशेषताओं को पूर्वनिर्धारित रिलेशनल ऑपरेटरों के माध्यम से एक्सेस और परिवर्तित किया जाता है, जबकि OO प्रत्येक वर्ग को अपना स्वयं का राज्य परिवर्तन इंटरफ़ेस और अभ्यास बनाने की अनुमति देता है। OO का स्व-संचालन संज्ञा दृष्टिकोण प्रत्येक वस्तु को स्वतंत्रता देता है जिसे संबंधपरक मॉडल अनुमति नहीं देता है। यह मानक बनाम स्थानीय स्वतंत्रता की बहस है। ओओ का तर्क है कि संबंधपरक मानक अभिव्यक्ति को सीमित करते हैं, जबकि संबंधपरक समर्थकों का सुझाव है कि नियम का पालन अधिक अमूर्त गणित जैसे तर्क, अखंडता और डिजाइन स्थिरता की अनुमति देता है।
- संज्ञा और क्रिया के मध्य संबंध – OO क्रियाओं (क्रियाओं) और संज्ञाओं (संस्थाओं) के मध्य शक्तिशाली संबंध को प्रोत्साहित करता है, जिस पर परिचालन संचालित होता है। संज्ञा और क्रिया दोनों से युक्त परिणामी कसकर बंधी इकाई को सामान्यतः वर्ग (कंप्यूटर विज्ञान) कहा जाता है, या ओओ विश्लेषण में, संकल्पनात्मक मॉडल (कंप्यूटर विज्ञान) कहा जाता है। संबंधपरक डिज़ाइन सामान्यतः यह नहीं मानते हैं कि ऐसे तंग संघों (संबंधपरक ऑपरेटरों के बाहर) के बारे में कुछ भी प्राकृतिक या तार्किक है।
- वस्तु की पहचान – वस्तुओं (अपरिवर्तनीय को छोड़कर) को सामान्यतः विशिष्ट पहचान माना जाता है; दो वस्तुएँ जो निश्चित समय पर ही स्थिति में होती हैं, उन्हें समान नहीं माना जाता है। दूसरी ओर, संबंधों में इस प्रकार की पहचान की कोई अंतर्निहित अवधारणा नहीं होती है। जैसा कि कहा गया है, विश्व स्तर पर अद्वितीय उम्मीदवार कुंजी के उपयोग के माध्यम से डेटाबेस में रिकॉर्ड के लिए "पहचान" बनाना आम बात है; चूँकि अनेक लोग इसे किसी भी डेटाबेस रिकॉर्ड के लिए ख़राब अभ्यास मानते हैं जिसका वास्तविक विश्व इकाई के साथ -से-एक पत्राचार नहीं होता है। (संबंध, वस्तुओं की तरह, पहचान उद्देश्यों के लिए बाहरी संसार में उपस्थित होने पर डोमेन कुंजियों का उपयोग कर सकते हैं)। व्यवहार में संबंधपरक प्रणालियाँ स्थायी और निरीक्षण योग्य पहचान विधियों ों के लिए प्रयास करती हैं और उनका समर्थन करती हैं, जबकि वस्तु पहचान विधियों क्षणिक या स्थितिजन्य होती हैं।
- सामान्यीकरण – डेटाबेस सामान्यीकरण प्रथाओं को अधिकांशतः OO डिज़ाइन द्वारा अनदेखा कर दिया जाता है। चूँकि, यह OO की मूल विशेषता के अतिरिक्त केवल बुरी आदत हो सकती है। वैकल्पिक दृष्टिकोण यह है कि ऑब्जेक्ट का संग्रह, किसी प्रकार के पॉइंटर (कंप्यूटर प्रोग्रामिंग) के माध्यम से जुड़ा हुआ, नेटवर्क डेटाबेस के समान है; जिसे बदले में अत्यंत असामान्य संबंधपरक डेटाबेस के रूप में देखा जा सकता है।
- स्कीमा विरासत – अधिकांश रिलेशनल डेटाबेस स्कीमा इनहेरिटेंस का समर्थन नहीं करते हैं। यद्यपि इस तरह की सुविधा को ओओपी के साथ संघर्ष को कम करने के लिए सिद्धांत में जोड़ा जा सकता है, संबंधपरक समर्थकों को पदानुक्रमित वर्गीकरण और उप-टाइपिंग की उपयोगिता पर विश्वास करने की कम संभावना है क्योंकि वे सेट सिद्धान्त -आधारित टैक्सोनॉमी या वर्गीकरण प्रणालियों को अधिक शक्तिशाली और लचीला रूप में देखते हैं | पेड़ों की तुलना में.ओओ समर्थकों का कहना है कि इनहेरिटेंस/सबटाइपिंग मॉडल को पेड़ों तक सीमित करने की आवश्यकता नहीं है (चूंकि जावा (भाषा) जैसी अनेक लोकप्रिय ओओ भाषाओं में यह सीमा है), किन्तुगैर-ट्री ओओ समाधानों को सेट कीआधारित में तैयार करना अधिक कठिन माना जाता है। विषय-वस्तु पर आधारित विविधता प्रबंधन विधियों ों को रिलेशनल द्वारा प्राथमिकता दी जाती है। कम से कम, वे सामान्यतः संबंधपरक बीजगणित में उपयोग की जाने वाली विधियों ों से भिन्न हैं।
- संरचना बनाम व्यवहार - OO मुख्य रूप से यह सुनिश्चित करने पर ध्यान केंद्रित करता है कि कार्यक्रम की संरचना उचित (रखरखाव योग्य, समझने योग्य, विस्तार योग्य, पुन: प्रयोज्य, सुरक्षित) है, जबकि संबंधपरक प्रणालियाँ इस बात पर ध्यान केंद्रित करती हैं कि परिणामी रन-टाइम प्रणाली में किस प्रकार का व्यवहार है (दक्षता, अनुकूलनशीलता) , दोष-सहिष्णुता, जीवंतता, तार्किक अखंडता, आदि)। ऑब्जेक्ट-ओरिएंटेड विधियाँ सामान्यतः मानती हैं कि ऑब्जेक्ट-ओरिएंटेड कोड और उसके इंटरफेस के प्राथमिक उपयोगकर्ता एप्लिकेशन डेवलपर हैं। संबंधपरक प्रणालियों में, प्रणाली के व्यवहार के बारे में अंतिम-उपयोगकर्ताओं के दृष्टिकोण को कभी-कभी अधिक महत्वपूर्ण माना जाता है। चूँकि, संबंधपरक प्रश्न और "विचार" एप्लिकेशन- या कार्य-विशिष्ट कॉन्फ़िगरेशन में जानकारी प्रस्तुत करने की सामान्य विधि हैं। इसके अतिरिक्त, रिलेशनल स्थानीय या एप्लिकेशन-विशिष्ट संरचनाओं या तालिकाओं को बनाने से प्रतिबंधित नहीं करता है, चूंकि अनेक सामान्य विकास उपकरण सीधे ऐसी सुविधा प्रदान नहीं करते हैं, यह मानते हुए कि वस्तुओं का उपयोग इसके अतिरिक्त किया जाएगा। इससे यह जानना कठिन हो जाता है कि रिलेशनल का बताया गया गैर-डेवलपर परिप्रेक्ष्य रिलेशनल में अंतर्निहित है, या केवल वर्तमान अभ्यास और उपकरण कार्यान्वयन मान्यताओं का उत्पाद है।
- सेट बनाम ग्राफ़ संबंध – विभिन्न वस्तुओं (वस्तुओं या रिकॉर्ड) के मध्य संबंध को प्रतिमानों के मध्य अलग-अलग विधि से नियंत्रित किया जाता है। संबंधपरक संबंध सामान्यतः सेट सिद्धांत से लिए गए मुहावरों पर आधारित होते हैं, जबकि वस्तु संबंध ग्राफ सिद्धांत (ट्री (ग्राफ सिद्धांत) सहित) से अपनाए गए मुहावरों की ओर झुकते हैं। चूँकि प्रत्येक व्यक्ति दूसरे के समान ही जानकारी का प्रतिनिधित्व कर सकता है, किन्तुजानकारी तक पहुँचने और उसे प्रबंधित करने के लिए उनके द्वारा प्रदान किए जाने वाले दृष्टिकोण भिन्न-भिन्न होते हैं।
वस्तु-संबंधपरक प्रतिबाधा बेमेल के परिणामस्वरूप, बहस के दोनों पक्षों के पक्षकारों द्वारा अधिकांशतः यह तर्क दिया जाता है कि अन्य विधि को छोड़ दिया जाना चाहिए या उसका सीमा कम कर दिया जाना चाहिए। [8] कुछ डेटाबेस समर्थक पारंपरिक "प्रक्रियात्मक" भाषाओं को अनेक OO भाषाओं की तुलना में RDBMS के साथ अधिक संगत मानते हैं; या सुझाव दें कि कम OO शैली का उपयोग किया जाना चाहिए। (विशेष रूप से, यह तर्क दिया जाता है कि एप्लिकेशन कोड में लंबे समय तक रहने वाले डोमेन ऑब्जेक्ट उपस्थित नहीं होने चाहिए; ऐसी कोई भी ऑब्जेक्ट जो उपस्थित है, उसे तब बनाया जाना चाहिए जब कोई क्वेरी की जाती है और लेनदेन या कार्य पूरा होने पर उसका निपटान किया जाना चाहिए)। इसके विपरीत, कुछ OO समर्थकों का तर्क है कि OODBMS जैसे अधिक OO-अनुकूल दृढ़ता तंत्र को विकसित और उपयोग किया जाना चाहिए, और संबंधपरक विधि को चरणबद्ध विधि से समाप्त किया जाना चाहिए। अनेक (यदि अधिकतर नहीं) प्रोग्रामर और डीबीए इनमें से कोई भी दृष्टिकोण नहीं रखते हैं; और वस्तु-संबंधपरक प्रतिबाधा बेमेल को जीवन के मात्र तथ्य के रूप में देखें जिससे सूचना प्रौद्योगिकी को निपटना है।
यह भी तर्क दिया जाता है कि ओ/आर मानचित्रणिंग से कुछ स्थितियों में लाभ हो रहा है, किन्तुसंभवत: इसकी अधिक बिक्री हो रही है: इसमें कमियों के अतिरिक्त फायदे भी हैं। संशयवादियों का कहना है कि इसका उपयोग करने से पहले सावधानी से सोचना उचित है, क्योंकि कुछ स्थितियोंमें इसका मूल्य थोड़ा बढ़ जाएगा।[9]
यह भी देखें
- ऑब्जेक्ट-रिलेशनल मैपिंग – Programming technique
- ऑब्जेक्ट-रिलेशनल डेटाबेस - डेटाबेस प्रबंधन प्रणाली
संदर्भ
- ↑ A classification of object–relational impedance mismatch. Ireland, Christopher; Bowers, David; Newton, Mike and Waugh, Kevin (2009). A classification of object–relational impedance mismatch. In: First International Conference on Advances in Databases, Knowledge, and Data Applications (DBKDA), 1-6 Mar 2009, Cancun, Mexico.
- ↑ C. J. Date, Relational Database Writings
- ↑ Object–Relational Mapping Revisited - A Quantitative Study on the Impact of Database Technology on O/R Mapping Strategies. M Lorenz, JP Rudolph, G Hesse, M Uflacker, H Plattner. Hawaii International Conference on System Sciences (HICSS), 4877-4886 (DOI:10.24251/hicss.2017.592)
- ↑ Date, Christopher ‘Chris’ J; Pascal, Fabian (2012-08-12) [2005], "Type vs. Domain and Class", Database debunkings (World Wide Web log), Google, retrieved 12 September 2012.
- ↑ ——— (2006), "4. On the notion of logical difference", Date on Database: writings 2000–2006, The expert’s voice in database; Relational database select writings, USA: Apress, p. 39, ISBN 978-1-59059-746-0,
Class seems to be indistinguishable from type, as that term is classically understood
. - ↑ ——— (2004), "26. Object/Relational databases", An introduction to database systems (8th ed.), Pearson Addison Wesley, p. 859, ISBN 978-0-321-19784-9,
...any such rapprochement should be firmly based on the relational model
. - ↑ Date, Christopher ‘Chris’ J; Darwen, Hugh, "2. Objects and Relations", The Third Manifesto,
The first great blunder
- ↑ Neward, Ted (2006-06-26). "कंप्यूटर विज्ञान का वियतनाम" (PDF). Interoperability Happens. Retrieved 2010-06-02.
- ↑ Johnson, Rod (2002). J2EE Design and Development. Wrox Press. p. 256. ISBN 9781861007841.
बाहरी संबंध
- The Object–Relational Impedance Mismatch – Agile Data Essay
- The Vietnam of Computer Science – Examples of mismatch problems
