वस्तु-संबंधपरक प्रतिबाधा बेमेल

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

ऑब्जेक्ट-रिलेशनल प्रतिबाधा असंगत शब्द विद्युत अभियन्त्रण शब्द प्रतिबाधा मिलान से लिया गया है।

असंगत

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

ऑब्जेक्ट-उन्मुख अवधारणाएँ

एनकैप्सुलेशन

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

अभिगम्यता

रिलेशनल सोच में, निजी बनाम सार्वजनिक पहुंच में यह आवश्यकता के सापेक्ष है। ऑब्जेक्ट-उन्मुखी (ओओ ) मॉडल में यह डेटा की स्थिति की पूर्ण विशेषता होती है। रिलेशनल और ओओ मॉडल में अधिकांशतः सापेक्षता बनाम वर्गीकरण और विशेषताओं की निरपेक्षता पर टकराव होता है।

इंटरफ़ेस, वर्ग, वंशानुक्रम और बहुरूपता

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

रिलेशनल अवधारणाओं का मानचित्रण

रिलेशनल अवधारणाओं और ऑब्जेक्ट-उन्मुख अवधारणाओं के मध्य उचित मानचित्रण बनाया जा सकता है | यदि रिलेशनल डेटाबेस तालिकाओं को ऑब्जेक्ट-उन्मुख विश्लेषण में पाए जाने वाले संघों (ऑब्जेक्ट-उन्मुख प्रोग्रामिंग) से जोड़ा जाता है |

डेटा प्रकार असमानत

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

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

संरचनात्मक और अखंडता अंतर

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

प्रकलित असमानत

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

क्रिया कलाप संबंधी असमानत

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

प्रतिबाधा असंगत को हल करना

ऑब्जेक्ट-उन्मुखी प्रोग्रामों के लिए प्रतिबाधा असंगत समस्या के आसपास काम करना नियोजित किए जा रहे विशिष्ट तर्क प्रणालियों में अंतर की पहचान के साथ प्रारंभिक होता है। फिर यह असंगत को तब आसान कर दिया जाता है या उसकी भरपाई कर दी जाती है।

वैकल्पिक आर्किटेक्चर

ऑब्जेक्ट-संबंध प्रतिबाधा असंगत समस्या ओओ और डेटाबेस के मध्य सार्वभौमिक समस्या नहीं होती है। जैसा कि नाम से पता चलता है, यह प्रतिबाधा समस्या केवल रिलेशनल डेटाबेस के साथ होती है। इस समस्या का सबसे सरल समाधान वैकल्पिक डेटाबेस, जैसे एनओएसक्यूएल या एक्सएमएल डेटाबेस का उपयोग करना है।

न्यूनीकरण

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

प्रतिबाधा असंगत समस्या का सामान्य समाधान स्थान और रूपरेखा तर्क को परत करना है। इस योजना में, ओओ भाषा का उपयोग और अधिक स्थिर मानचित्रण के प्रयास के अतिरिक्त रनटाइम पर अनेक संबंध परक पहलुओं को मॉडल करने के लिए किया जाता है। इस विधि को नियोजित करने वाले फ़्रेमवर्क में सामान्यतः टुपल के लिए एनालॉग होता है | और सामान्यतः "डेटासेट" घटक में "पंक्ति" के रूप में या सामान्य "इकाई उदाहरण" वर्ग के रूप में होता हैं | इसके साथ ही इसमें किसी संबंध के लिए एनालॉग भी होता हैं। इस प्रकार दृष्टिकोण के लाभों में सम्मिलित हो सकते हैं|

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

• इसमें स्थैतिक प्रकार की "सुरक्षा" जांच का अभाव होता हैं। और टाइप किए गए सेंसर्स का उपयोग कभी-कभी इसे आसान करने के विधि के रूप में किया जाता है।
• रनटाइम निर्माण और पहुंच की संभावित प्रदर्शन निवेश होती हैं।
• ऑब्जेक्ट-उन्मुखी प्रोग्रामिंग में बहुरूपता जैसे विशिष्ट ओओ पहलुओं का मूल रूप से उपयोग करने में असमर्थता होती हैं।

प्रतिपूर्ति

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

उपस्थिति

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

प्रतिद्वंद्विता

यथार्थ आरडीबीएमएस मॉडल

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

व्यवरोध और अवैधता कार्यविवरण

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

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

एसक्यूएल-विशिष्ट प्रतिबाधा और समाधान

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

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

इन विक्रेताओं ने डीबीएमएस बैक-एंड पर ओओ -भाषा एकीकरण का समर्थन करने का निर्णय लिया क्योंकि उन्हें मनोभाव हुआ था कि, एसक्यूएल में प्रक्रियात्मक निर्माणों को जोड़ने के लिए आईएस ओएसक्यूएल-99 समिति के प्रयासों के अतिरिक्त, एसक्यूएल में पुस्तकालयों और डेटा संरचनाओं का समृद्ध सेट कभी नहीं होगा। आज के एप्लिकेशन प्रोग्रामर इसे सरलता में लेते हैं, और मुख्य एसक्यूएल भाषा का विस्तार करने का प्रयास करने के अतिरिक्त इनका यथासंभव सीधे लाभ उठाना उचित होता है। परिणाम स्वरुप , "एप्लिकेशन प्रोग्रामिंग" और "डेटाबेस प्रशासन" के मध्य का अंतर अभी धुंधला हो गया है | बाधाओं और ट्रिगर्स जैसी सुविधाओं के शक्तिशाली कार्यान्वयन के लिए अधिकांशतः दोहरे डीबीए/ओओ-प्रोग्रामिंग कौशल वाले व्यक्ति या इन कौशलों को संयोजित करने वाले व्यक्तियों के मध्य साझेदारी की आवश्यकता हो सकती है। यह तथ्य नीचे दिए गए "जिम्मेदारी के विभाजन" मुद्दे पर भी प्रयुक्त होता है।

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

डेटा की कैनोनिकल प्रतिलिपि का स्थान

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

उत्तरदायित्व का विभाजन

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

चूंकि, डीबीए और डेवलपर्स के मध्य गैर-अकार्यात्मक संबंध वाले संगठनों में, उपरोक्त उद्देश्य स्वमं को प्रस्तुत नहीं करना चाहिए, क्योंकि डेटाबेस स्कीमा को बदलने या न करने का निर्णय केवल व्यावसायिक जरूरतो से प्रेरित होता हैं | इसके अतिरिक्त डेटा को बनाए रखने के लिए नई आवश्यकता या ए उदाहरण के लिए, महत्वपूर्ण एप्लिकेशन के प्रदर्शन को बढ़ावा देने से स्कीमा संशोधन प्रारंभिक हो जाता हैं।

दार्शनिक असमानता

ओओ और रिलेशनल मॉडल के मध्य प्रमुख दार्शनिक अंतरों को निम्नानुसार संक्षेपित किया जा सकता है |

• घोषणात्मक बनाम अनिवार्य इंटरफेस – रिलेशनल सोच डेटा को इंटरफ़ेस के रूप में उपयोग करती है, इसमें व्यवहार को इंटरफ़ेस के रूप में उपयोग नहीं किया जाता हैं। इस प्रकार इसमें ओओ के व्यवहारिक झुकाव के विपरीत डिजाइन दर्शन में घोषणात्मक झुकाव है। (अनेक रिलेशनल प्रस्तावक जटिल व्यवहार प्रदान करने के लिए ट्रिगर्स, संग्रहीत प्रक्रियाओं आदि का उपयोग करने का सुझाव देते हैं, किन्तु यह सामान्य दृष्टिकोण नहीं होता है।)
• स्कीमा बाउंड - ऑब्जेक्ट को "पैरेंट स्कीमा" का पालन करने की आवश्यकता नहीं होती है | और जिसके लिए किसी ऑब्जेक्ट के गुण या एक्सेसर्स होते हैं, जबकि तालिका पंक्तियों को इकाई की स्कीमा का पालन करना होता हैं। इस प्रकार दी गई पंक्ति और केवल इकाई से संबंधित होनी चाहिए। जिसे ओओ में निकटतम ऑब्जेक्ट वंशानुक्रम होती है, किन्तु यह सामान्यतः ट्री के आकार का और वैकल्पिक होता है। जिसे गतिशील डेटाबेस प्रणालियाँ जो विशेष स्तंभों की अनुमति देती हैं, जिन्हें स्कीमा बाध्यता को शिथिल कर सकती हैं, किन्तु ऐसी प्रणालियाँ तब वर्तमान में दुर्लभ होती हैं, या "रिलेशनल" के रूप में उनका वर्गीकरण प्रश्न में होता है।
• प्रवेश नियम – संबंध डेटाबेस में, विशेषताओं को पूर्व निर्धारित संबंध ऑपरेटरों के माध्यम से एक्सेस और परिवर्तित किया जाता है, जबकि ओओ प्रत्येक वर्ग को अपना स्वयं का राज्य परिवर्तन इंटरफ़ेस और अभ्यास बनाने की अनुमति देता है। ओओ का स्व-संचालन संज्ञा दृष्टिकोण प्रत्येक ऑब्जेक्ट को स्वतंत्रता देता है जिसे रिलेशनल मॉडल अनुमति नहीं देता है। यह मानक बनाम स्थानीय स्वतंत्रता की चर्चा होती है। ओओ का तर्क है कि रिलेशनल मानक अभिव्यक्ति को सीमित करते हैं, जबकि यह रिलेशनल समर्थकों का सुझाव होता है कि नियम का पालन अधिक अमूर्त गणित जैसे तर्क, अखंडता और डिजाइन स्थिरता की अनुमति देता है।
• संज्ञा और क्रिया के मध्य संबंध – ओओ क्रियाओं (क्रियाओं) और संज्ञाओं (संस्थाओं) के मध्य शक्तिशाली संबंध को प्रोत्साहित करता है, जिस पर परिचालन संचालित होता है। संज्ञा और क्रिया दोनों से युक्त परिणामी कसकर बंधी इकाई को सामान्यतः वर्ग (कंप्यूटर विज्ञान) कहा जाता है, या इनको ओओ विश्लेषण में, संकल्पनात्मक मॉडल (कंप्यूटर विज्ञान) कहा जाता है। इस प्रकार रिलेशनल डिज़ाइन सामान्यतः यह नहीं मानते हैं कि ऐसे तंग संघों (रिलेशनल ऑपरेटरों के बाहर) के बारे में अनेक प्राकृतिक या तार्किक होते है।
• ऑब्जेक्ट की पहचान – ऑब्जेक्ट (अपरिवर्तनीय को छोड़कर) को सामान्यतः विशिष्ट पहचान माना जाता है; दो वस्तुएँ जो निश्चित समय पर ही स्थिति में होती हैं, उन्हें समान नहीं माना जाता है। दूसरी ओर, संबंधों में इस प्रकार की पहचान की कोई अंतर्निहित अवधारणा नहीं होती है। जैसा कि कहा गया है,कि विश्व स्तर पर अद्वितीय अपेक्षावार कुंजी के उपयोग के माध्यम से डेटाबेस में रिकॉर्ड के लिए "पहचान" बनाना सरल बात है; चूँकि अनेक लोग इसे किसी भी डेटाबेस रिकॉर्ड के लिए ख़राब अभ्यास मानते हैं जिसका वास्तविक विश्व इकाई के साथ पत्राचार नहीं होता है। औरइसके (संबंध, ऑब्जेक्ट की तरह, पहचान उद्देश्यों के लिए बाहरी संसार में उपस्थित होने पर स्थान कुंजियों का उपयोग कर सकते हैं)। व्यवहार में रिलेशनल प्रणालियाँ स्थायी और निरीक्षण योग्य पहचान विधियों के लिए प्रयास करती हैं और उनका समर्थन करती हैं, जबकि ऑब्जेक्ट पहचान विधियों में इसकी स्थिति क्षणिक या स्थितिजन्य होती हैं।
• सामान्यीकरण – डेटाबेस सामान्यीकरण प्रथाओं को अधिकांशतः ओओ डिज़ाइन द्वारा अनदेखा कर दिया जाता है। चूँकि, यह ओओ की मूल विशेषता के अतिरिक्त हानिकारक आदत हो सकती है। वैकल्पिक दृष्टिकोण यह है कि ऑब्जेक्ट का संग्रह, किसी प्रकार के पॉइंटर (कंप्यूटर प्रोग्रामिंग) के माध्यम से जुड़ा हुआ होता हैं | जो नेटवर्क डेटाबेस के समान होता है | जिसे बदले में अत्यंत असामान्य रिलेशनल डेटाबेस के रूप में देखा जा सकता है।
• स्कीमा विरासत – अधिकांश संबंध डेटाबेस स्कीमा विरासत का समर्थन नहीं करते हैं। यद्यपि इस तरह की सुविधा को ओओपी के साथ संघर्ष को आसान करने के लिए सिद्धांत में जोड़ा जा सकता है, और रिलेशनल समर्थकों को पदानुक्रमित वर्गीकरण और उप-टाइपिंग की उपयोगिता पर विश्वास करने की आसान संभावना होती है क्योंकि वे सेट सिद्धान्त -आधारित टैक्सोनॉमी या वर्गीकरण प्रणालियों को अधिक शक्तिशाली और परिवर्तित रूप में देखते हैं | ट्री की तुलना में.ओओ समर्थकों का कहना है कि विरासत /सबटाइपिंग मॉडल को ट्री तक सीमित करने की आवश्यकता नहीं है (चूंकि जावा (भाषा) जैसी अनेक लोकप्रिय ओओ भाषाओं में यह सीमा होती है), किन्तु गैर-ट्री ओओ समाधानों को सेट की आधारित में तैयार करना अधिक कठिन माना जाता है। विषय-ऑब्जेक्ट पर आधारित विविधता प्रबंधन विधियों को संबंध द्वारा प्राथमिकता दी जाती है। और वह सरल से सरल होते हैं | और वह सामान्यतः रिलेशनल बीजगणित में उपयोग की जाने वाली विधियों से भिन्न होते हैं।
• संरचना बनाम व्यवहार - ओओ मुख्य रूप से यह सुनिश्चित करने पर ध्यान केंद्रित करता है कि कार्यक्रम की संरचना उचित (रख रखाव योग्य, समझने योग्य, विस्तार योग्य, पुन: प्रयोज्य, सुरक्षित) होती है, जबकि रिलेशनल प्रणालियाँ इस बात पर ध्यान केंद्रित करती हैं कि परिणामी रन-टाइम रिलेशनल में किस प्रकार का व्यवहार होता है जिसे (दक्षता, अनुकूलनशीलता) , दोष-सहिष्णुता, जीवंतता, तार्किक अखंडता, आदि होते हैं। ऑब्जेक्ट-उन्मुखी विधियाँ सामान्यतः मानती हैं कि ऑब्जेक्ट-उन्मुखी कोड और उसके इंटरफेस के प्राथमिक उपयोगकर्ता एप्लिकेशन डेवलपर हैं। रिलेशनल प्रणालियों में, रिलेशनल के व्यवहार के बारे में अंतिम-उपयोगकर्ताओं के दृष्टिकोण को कभी-कभी अधिक महत्वपूर्ण माना जाता है। चूँकि, रिलेशनल प्रश्न और "विचार" एप्लिकेशन- या कार्य-विशिष्ट विन्यास में जानकारी प्रस्तुत करने की सामान्य विधि हैं। इसके अतिरिक्त, संबंध स्थानीय या एप्लिकेशन-विशिष्ट संरचनाओं या तालिकाओं को बनाने से प्रतिबंधित नहीं करता है, चूंकि अनेक सामान्य विकास उपकरण सीधे ऐसी सुविधा प्रदान नहीं करते हैं, यह मानते हुए कि ऑब्जेक्ट का उपयोग इसके अतिरिक्त किया जाता हैं। इससे यह जाननाआसान हो जाता है कि संबंध का बताया गया गैर-डेवलपर परिप्रेक्ष्य संबंध में अंतर्निहित है, या केवल वर्तमान अभ्यास और उपकरण कार्यान्वयन मान्यताओं का उत्पाद होता है।
• सेट बनाम ग्राफ़ संबंध – विभिन्न ऑब्जेक्ट (ऑब्जेक्ट या रिकॉर्ड) के मध्य संबंध को प्रतिमानों के मध्य अलग-अलग विधि से नियंत्रित किया जाता है। रिलेशनल संबंध सामान्यतः सेट सिद्धांत से लिए गए मुहावरों पर आधारित होते हैं, जबकि ऑब्जेक्ट संबंध ग्राफ सिद्धांत (ट्री (ग्राफ सिद्धांत) सहित) से अपनाए गए मुहावरों की ओर झुकते हैं। चूँकि प्रत्येक व्यक्ति दूसरे के समान ही जानकारी का प्रतिनिधित्व कर सकता है, किन्तु जानकारी तक पहुँचने और उसे प्रबंधित करने के लिए उनके द्वारा प्रदान किए जाने वाले दृष्टिकोण भिन्न-भिन्न होते हैं।

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

यह भी तर्क दिया जाता है कि ओ/आर मानचित्रण से अनेक स्थितियों में लाभ हो रहा है, और संभवत: इसकी अधिविक्रीत हो रही है इसमें सरल के अतिरिक्त लाभ भी हैं। संशयवादियों का कहना है कि इसका उपयोग करने से पहले सावधानी से सोचना उचित है, क्योंकि अनेक स्थितियों में इसका मूल्य थोड़ा बढ़ जाता हैं।

यह भी देखें

• ऑब्जेक्ट-रिलेशनल मैपिंग  – Programming technique
• ऑब्जेक्ट-रिलेशनल डेटाबेस - डेटाबेस प्रबंधन प्रणाली

बाहरी संबंध

• The Object–Relational Impedance Mismatch – Agile Data Essay
• The Vietnam of Computer Science – Examples of mismatch problems