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

Latest revision as of 10:15, 4 August 2023

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

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

असंगत

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

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

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

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

अभिगम्यता

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

न्यूनीकरण

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

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

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

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

प्रतिपूर्ति

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

उपस्थिति

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[1] 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.

[2] C. J. Date, Relational Database Writings

[3] 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)

[4] 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.

[5] ——— (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.

[6] ——— (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.

[7] Date, Christopher ‘Chris’ J; Darwen, Hugh, "2. Objects and Relations", The Third Manifesto, The first great blunder

[RDMDBobjectmis-8] Neward, Ted (2006-06-26). "कंप्यूटर विज्ञान का वियतनाम" (PDF). Interoperability Happens. Retrieved 2010-06-02.

[9] Johnson, Rod (2002). J2EE Design and Development. Wrox Press. p. 256. ISBN 9781861007841.

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

@@ Line 1: / Line 1: @@
 {{short description|Set of conceptual and technical difficulties}}
-'''वस्तु-संबंधपरक प्रतिबाधा बेमेल''' वैचारिक और तकनीकी कठिनाइयों का सेट है जो अक्सर तब सामने आती है जब संगठन रिलेशनल डेटा स्टोर्स ([[ संबंधपरक डेटाबेस प्रबंधन प्रणाली | संबंधपरक डेटाबेस प्रबंधन प्रणाली]] [“आरडीबीएमएस”]) में डेटा संग्रहीत करते हैं और फिर डोमेन-संचालित ऑब्जेक्ट मॉडल के माध्यम से इस डेटा का उपयोग करते हैं, ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग भाषाओं में व्यवसाय-केंद्रित वस्तुओं को लागू करने की डिफ़ॉल्ट विधि। समस्याएँ डेटा को रिलेशनल या डोमेन ऑब्जेक्ट के रूप में संबोधित करने में विफलता से उत्पन्न नहीं होती हैं, बल्कि दो वैचारिक रूप से भिन्न तर्क मॉडल के डेटा मानों के बीच डेटा मैपिंग को लागू करने की कठिनाई के परिणामस्वरूप उत्पन्न होती हैं; दोनों मॉडल तार्किक मॉडल हैं जिन्हें उपयोग की गई तकनीक (डेटाबेस सर्वर, प्रोग्रामिंग भाषा, डिज़ाइन पैटर्न इत्यादि) के आधार पर अलग-अलग तरीके से लागू किया जा सकता है। ये मुद्दे केवल अनुप्रयोगों तक ही सीमित नहीं हैं, बल्कि उद्यम में मौजूद हैं, जब भी डेटा को रिलेशनल तरीके से संग्रहीत किया जाता है तो डोमेन-संचालित ऑब्जेक्ट मॉडल के रूप में उपयोग किया जाता है, और इसके विपरीत। इन कठिनाइयों को कभी-कभी ऑब्जेक्ट-ओरिएंटेड डेटा स्टोर के उपयोग से कम किया जाता है, लेकिन इसकी भी कार्यान्वयन कठिनाइयों का अपना सेट होता है।
+'''ऑब्जेक्ट-रिलेशनल प्रतिबाधा असंगत''' वैचारिक और विधियों की कठिनाइयों का सेट होता है | और जो अधिकांशतः तब सामने आती है जब संगठन संबंध डेटा संग्रहण [[ संबंधपरक डेटाबेस प्रबंधन प्रणाली |रिलेशनल डेटाबेस प्रबंधन]] रिलेशनल “आरडीबीएमएस” में डेटा संग्रहीत करते हैं और फिर डोमेन-संचालित ऑब्जेक्ट मॉडल के माध्यम से इस डेटा का उपयोग करते हैं,और ऑब्जेक्ट-उन्मुखी प्रोग्रामिंग भाषाओं में व्यवसाय-केंद्रित ऑब्जेक्ट को प्रयुक्त करने की डिफ़ॉल्ट विधि होती हैं। जिसमे समस्याएँ डेटा को संबंध या स्थान ऑब्जेक्ट के रूप में संबोधित करने में विफलता से उत्पन्न नहीं होती हैं, किंतु दो वैचारिक रूप से भिन्न तर्क मॉडल के डेटा मानों के मध्य डेटा मानचित्र को प्रयुक्त करने की कठिनाई के परिणामस्वरूप उत्पन्न होती हैं | और यह दोनों मॉडल तार्किक मॉडल होते हैं जिन्हें उपयोग की गई विधियों (डेटाबेस सर्वर, प्रोग्रामिंग भाषा, डिज़ाइन क्रम इत्यादि) के आधार पर अलग-अलग विधि से प्रयुक्त किया जा सकता है। इस उद्देश्य केवल अनुप्रयोगों तक ही सीमित नहीं होते हैं, किंतु यह उद्यम में उपस्थित हैं| और जब भी डेटा को संबंध विधि से संग्रहीत किया जाता है तब डोमेन-संचालित ऑब्जेक्ट मॉडल के रूप में उपयोग किया जाता है, और इसके विपरीत। इन कठिनाइयों को कभी-कभी ऑब्जेक्ट-उन्मुखी डेटा संग्रहण के उपयोग से आसान किया जाता है, किन्तु इसकी भी कार्यान्वयन कठिनाइयों का अपना सेट होता है।
-''वस्तु-संबंधपरक प्रतिबाधा बेमेल'' शब्द [[ विद्युत अभियन्त्रण |विद्युत अभियन्त्रण]] शब्द ''[[प्रतिबाधा मिलान]]'' से लिया गया है।
+''ऑब्जेक्ट-रिलेशनल प्रतिबाधा असंगत'' शब्द [[ विद्युत अभियन्त्रण |विद्युत अभियन्त्रण]] शब्द ''[[प्रतिबाधा मिलान]]'' से लिया गया है।
-== बेमेल ==
+== असंगत ==
-वस्तुएं (उदाहरण) दूसरे को संदर्भित करती हैं और इसलिए गणितीय अर्थ में [[निर्देशित ग्राफ]] बनाती हैं (लूप और चक्र सहित नेटवर्क)। इसके विपरीत, संबंधपरक स्कीमा सारणीबद्ध होती हैं और [[संबंधपरक बीजगणित]] पर आधारित होती हैं, जो जुड़े हुए विषम टुपल्स (प्रत्येक क्षेत्र के लिए अलग-अलग प्रकारों के साथ डेटा फ़ील्ड को "पंक्ति" में समूहित करना) को परिभाषित करती हैं, जहां लिंक हमेशा प्रतिवर्ती होते हैं (विदेशी कुंजी को पीछे की ओर ले जाया जा सकता है, चूँकि INNER JOIN सममित है), जो अप्रत्यक्ष ग्राफ़ के समान विशेषता है।
+ऑब्जेक्ट- (उदाहरण) दूसरे को संदर्भित करती हैं और इसलिए यह गणितीय अर्थ में [[निर्देशित ग्राफ]] बनाती हैं| इनके (लूप और चक्र सहित नेटवर्क) होते हैं। इसके विपरीत, रिलेशनल स्कीमा सारणीबद्ध होती हैं और यह [[संबंधपरक बीजगणित|रिलेशनल बीजगणित]] पर आधारित होती हैं, जो जुड़े हुए विषम टुपल्स (प्रत्येक क्षेत्र के लिए अलग-अलग प्रकारों के साथ डेटा क्षेत्र को "पंक्ति" में समूहित करना) को परिभाषित करती हैं, जहां लिंक सदैव प्रतिवर्ती होते हैं और इसमें (विदेशी कुंजी को पीछे की ओर ले जाया जा सकता है, चूँकि यह आंतरिक रूप से जुड़ा हुआ सममित होती है), जो अप्रत्यक्ष ग्राफ़ के समान विशेषता है।
-=== वस्तु-उन्मुख अवधारणाएँ ===
+=== ऑब्जेक्ट-उन्मुख अवधारणाएँ ===
 ==== एनकैप्सुलेशन ====
-ऑब्जेक्ट-ओरिएंटेड प्रोग्राम ऐसी तकनीकों के साथ डिज़ाइन किए गए हैं जिनके परिणामस्वरूप [[एनकैप्सुलेशन (ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग)]] ऑब्जेक्ट होते हैं जिनका आंतरिक प्रतिनिधित्व छिपाया जा सकता है। ऑब्जेक्ट-ओरिएंटेड फ्रेमवर्क में, किसी दिए गए ऑब्जेक्ट के अंतर्निहित गुणों को ऑब्जेक्ट के साथ लागू इंटरफ़ेस के बाहर किसी भी इंटरफ़ेस के संपर्क में नहीं आने की उम्मीद की जाती है। हालाँकि, अधिकांश ऑब्जेक्ट-रिलेशनल मैपिंग दृष्टिकोण किसी ऑब्जेक्ट की अंतर्निहित सामग्री को इंटरफ़ेस के साथ इंटरैक्ट करने के लिए उजागर करते हैं जिसे ऑब्जेक्ट कार्यान्वयन निर्दिष्ट नहीं कर सकता है। इसलिए, यह ऑब्जेक्ट-रिलेशनल मैपिंग ऑब्जेक्ट के एनकैप्सुलेशन का उल्लंघन करती है, क्योंकि कई ऑब्जेक्ट-रिलेशनल मैपर स्वचालित रूप से डेटाबेस कॉलम के अनुरूप सार्वजनिक फ़ील्ड उत्पन्न करते हैं। कुछ फ्रेमवर्क इसके बजाय मेटाप्रोग्रामिंग तकनीकों का उपयोग करते हैं, इस प्रकार इनकैप्सुलेशन का उल्लंघन करने से बचते हैं।
+ऑब्जेक्ट-उन्मुखी प्रोग्राम ऐसी विधियों के साथ डिज़ाइन किए गए हैं जिनके परिणामस्वरूप [[एनकैप्सुलेशन (ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग)|एनकैप्सुलेशन (ऑब्जेक्ट-उन्मुखी प्रोग्रामिंग)]] ऑब्जेक्ट होते हैं | और जिनका आंतरिक प्रतिनिधित्व छिपाया जा सकता है। इस प्रकार यह ऑब्जेक्ट-उन्मुखी रूपरेखा में, किसी दिए गए ऑब्जेक्ट के अंतर्निहित गुणों को ऑब्जेक्ट के साथ प्रयुक्त इंटरफ़ेस के बाहर किसी भी इंटरफ़ेस के संपर्क में नहीं आने की अपेक्षा की जाती है। चूँकि, अधिकांश ऑब्जेक्ट-संबंध मानचित्र दृष्टिकोण को किसी ऑब्जेक्ट की अंतर्निहित सामग्री को इंटरफ़ेस के साथ इंटरैक्ट करने के लिए प्रकट करते हैं इस प्रकार जिसे ऑब्जेक्ट कार्यान्वयन निर्दिष्ट नहीं कर सकता है। इसलिए, यह ऑब्जेक्ट-संबंध मानचित्रण ऑब्जेक्ट के एनकैप्सुलेशन का उल्लंघन करती है, क्योंकि अनेक ऑब्जेक्ट-संबंध मानचित्रण पर स्वचालित रूप से डेटाबेस कॉलम के अनुरूप सार्वजनिक क्षेत्र उत्पन्न करते हैं। और अनेक रूपरेखा इसके अतिरिक्त मेटा प्रोग्रामिंग विधियों का उपयोग करते हैं, और इस प्रकार इनकैप्सुलेशन का उल्लंघन करने से बचते हैं।
 ==== अभिगम्यता ====
-संबंधपरक सोच में, निजी बनाम सार्वजनिक पहुंच आवश्यकता के सापेक्ष है। ऑब्जेक्ट-ओरिएंटेड (OO) मॉडल में यह डेटा की स्थिति की पूर्ण विशेषता है। संबंधपरक और OO मॉडल में अक्सर सापेक्षता बनाम वर्गीकरण और विशेषताओं की निरपेक्षता पर टकराव होता है।
+रिलेशनल सोच में, निजी बनाम सार्वजनिक पहुंच में यह आवश्यकता के सापेक्ष है। ऑब्जेक्ट-उन्मुखी (ओओ ) मॉडल में यह डेटा की स्थिति की पूर्ण विशेषता होती है। रिलेशनल और ओओ मॉडल में अधिकांशतः सापेक्षता बनाम वर्गीकरण और विशेषताओं की निरपेक्षता पर टकराव होता है।
 ==== इंटरफ़ेस, वर्ग, वंशानुक्रम और बहुरूपता ====
-ऑब्जेक्ट-ओरिएंटेड प्रतिमान के तहत, ऑब्जेक्ट में [[इंटरफ़ेस (कंप्यूटर विज्ञान)]] होते हैं जो साथ उस ऑब्जेक्ट के आंतरिक तक मात्र पहुंच प्रदान करते हैं। दूसरी ओर, संबंधपरक मॉडल अखंडता सुनिश्चित करने के लिए अलग-अलग दृष्टिकोण और बाधाएं प्रदान करने के लिए व्युत्पन्न संबंध चर [[देखें (डेटाबेस)]] (विचार) का उपयोग करता है। इसी प्रकार, वस्तुओं के वर्गों, [[वंशानुक्रम (कंप्यूटर विज्ञान)]] और [[बहुरूपता (कंप्यूटर विज्ञान)]] के लिए आवश्यक ओओपी अवधारणाएँ, रिलेशनल डेटाबेस सिस्टम द्वारा समर्थित नहीं हैं।
+ऑब्जेक्ट-उन्मुखी प्रतिमान के अनुसार, ऑब्जेक्ट में [[इंटरफ़ेस (कंप्यूटर विज्ञान)]] होते हैं जो उसके साथ उस ऑब्जेक्ट के आंतरिक तक मात्र पहुंच प्रदान करते हैं। दूसरी ओर, रिलेशनल मॉडल अखंडता सुनिश्चित करने के लिए अलग-अलग दृष्टिकोण और बाधाएं प्रदान करने के लिए व्युत्पन्न संबंध चर [[देखें (डेटाबेस)]] (विचार) का उपयोग करता है। इसी प्रकार, ऑब्जेक्ट के वर्गों, [[वंशानुक्रम (कंप्यूटर विज्ञान)]] और [[बहुरूपता (कंप्यूटर विज्ञान)]] के लिए आवश्यक ओओपी अवधारणाएँ, संबंध डेटाबेस रिलेशनल द्वारा समर्थित नहीं होते हैं।
-==== संबंधपरक अवधारणाओं का मानचित्रण ====
+==== रिलेशनल अवधारणाओं का मानचित्रण ====
-संबंधपरक अवधारणाओं और वस्तु-उन्मुख अवधारणाओं के बीच उचित मानचित्रण बनाया जा सकता है यदि संबंधपरक डेटाबेस तालिकाओं को वस्तु-उन्मुख विश्लेषण में पाए जाने वाले [[ एसोसिएशन (वस्तु-उन्मुख प्रोग्रामिंग) |संघों (वस्तु-उन्मुख प्रोग्रामिंग)]] से जोड़ा जाता है [आगे स्पष्टीकरण की आवश्यकता है]।
+रिलेशनल अवधारणाओं और ऑब्जेक्ट-उन्मुख अवधारणाओं के मध्य उचित मानचित्रण बनाया जा सकता है | यदि रिलेशनल डेटाबेस तालिकाओं को ऑब्जेक्ट-उन्मुख विश्लेषण में पाए जाने वाले [[ एसोसिएशन (वस्तु-उन्मुख प्रोग्रामिंग) |संघों (ऑब्जेक्ट-उन्मुख प्रोग्रामिंग)]] से जोड़ा जाता है |
-=== डेटा प्रकार अंतर ===
+=== डेटा प्रकार असमानत ===
-मौजूदा रिलेशनल और OO भाषाओं के बीच बड़ा बेमेल प्रकार सिस्टम अंतर है। संबंधपरक मॉडल सख्ती से उप-संदर्भ विशेषताओं (या [[ सूचक (कंप्यूटर प्रोग्रामिंग) |सूचक (कंप्यूटर प्रोग्रामिंग)]]) को प्रतिबंधित करता है, जबकि ओओ भाषाएं उप-संदर्भ व्यवहार को अपनाती हैं और उसकी अपेक्षा करती हैं। [[ अदिश (कंप्यूटिंग) |अदिश (कंप्यूटिंग)]] प्रकार और उनके ऑपरेटर शब्दार्थ मॉडल के बीच काफी भिन्न हो सकते हैं, जिससे मैपिंग में समस्याएं पैदा हो सकती हैं।
+वर्तमान संबंध और ओओ भाषाओं के मध्य बड़ा असंगत प्रकार की रिलेशनल अंतर होता है। रिलेशनल मॉडल सख्ती से उप-संदर्भ विशेषताओं (या [[ सूचक (कंप्यूटर प्रोग्रामिंग) |सूचक (कंप्यूटर प्रोग्रामिंग)]]) को प्रतिबंधित करता है, जबकि ओओ भाषाएं उप-संदर्भ व्यवहार को अपनाती हैं और उसकी अपेक्षा करती हैं। और [[ अदिश (कंप्यूटिंग) |अदिश (कंप्यूटिंग)]] प्रकार और उनके ऑपरेटर शब्दार्थ मॉडल के मध्य अधिक भिन्न हो सकते हैं, जिससे मानचित्रण में समस्याएं उत्पन्न हो सकती हैं।
-उदाहरण के लिए, अधिकांश [[एसक्यूएल]] सिस्टम अलग-अलग संयोजनों और सीमित अधिकतम लंबाई के साथ [[स्ट्रिंग (कंप्यूटर विज्ञान)]] प्रकारों का समर्थन करते हैं (ओपन-एंडेड टेक्स्ट प्रकार प्रदर्शन में बाधा डालते हैं), जबकि अधिकांश ओओ भाषाएं संयोजन को केवल [[छँटाई एल्गोरिथ्म|सॉर्ट एल्गोरिथ्म]] करने के लिए तर्क के रूप में मानती हैं और स्ट्रिंग्स आंतरिक रूप से उपलब्ध मेमोरी के आकार की होती हैं। अधिक सूक्ष्म, लेकिन संबंधित उदाहरण यह है कि एसक्यूएल सिस्टम अक्सर तुलना के प्रयोजनों के लिए स्ट्रिंग में पिछली [[व्हाइटस्पेस (कंप्यूटर विज्ञान)]] को अनदेखा कर देते हैं, जबकि OO स्ट्रिंग लाइब्रेरीज़ ऐसा नहीं करते हैं। ओओ भाषा में अन्य आदिम प्रकारों के संभावित मूल्यों को सीमित करने के मामले में नए डेटा प्रकारों का निर्माण करना आम तौर पर संभव नहीं है।
+उदाहरण के लिए, अधिकांश [[एसक्यूएल]] रिलेशनल अलग-अलग संयोजनों और सीमित अधिकतम लंबाई के साथ [[स्ट्रिंग (कंप्यूटर विज्ञान)]] प्रकारों का समर्थन करते हैं |और (ओपन-एंडेड टेक्स्ट प्रकार प्रदर्शन में बाधा डालते हैं), जबकि अधिकांश ओओ भाषाएं संयोजन को केवल [[छँटाई एल्गोरिथ्म|सॉर्ट एल्गोरिथ्म]] करने के लिए तर्क के रूप में मानती हैं और स्ट्रिंग्स आंतरिक रूप से उपलब्ध मेमोरी के आकार की होती हैं। यह अधिक सूक्ष्म, किन्तु संबंधित उदाहरण है कि एसक्यूएल रिलेशनल अधिकांशतः तुलना के प्रयोजनों के लिए स्ट्रिंग में पिछली [[व्हाइटस्पेस (कंप्यूटर विज्ञान)]] को अनदेखा कर देते हैं, जबकि ओओ स्ट्रिंग लाइब्रेरीज़ ऐसा नहीं करते हैं। ओओ भाषा में अन्य प्राचीन प्रकारों के संभावित मूल्यों को सीमित करने के स्थिति में नए डेटा प्रकारों का निर्माण करना सामान्यतः संभव नहीं होता है।
 === संरचनात्मक और अखंडता अंतर ===
-एक और बेमेल का संबंध विपरीत मॉडलों के संरचनात्मक और अखंडता पहलुओं में अंतर से है। ओओ भाषाओं में, वस्तुओं को अन्य वस्तुओं से बनाया जा सकता है - अक्सर उच्च स्तर तक - या अधिक सामान्य परिभाषा से विशेषज्ञ। इससे रिलेशनल स्कीमों की मैपिंग कम सरल हो सकती है। ऐसा इसलिए है क्योंकि रिलेशनल डेटा को वैश्विक, अननेस्टेड रिलेशन वेरिएबल्स के नामित सेट में दर्शाया जाता है। स्वयं संबंध, ही हेडर के अनुरूप टुपल्स के सेट होने के कारण ([[टपल]] रिलेशनल कैलकुलस देखें) ओओ भाषाओं में कोई आदर्श समकक्ष नहीं है। ओओ भाषाओं में बाधाओं को आम तौर पर इस तरह घोषित नहीं किया जाता है, लेकिन एन्कैप्सुलेटेड आंतरिक डेटा पर काम करने वाले कोड के आसपास सुरक्षा तर्क बढ़ाने वाले अपवाद के रूप में प्रकट होते हैं। दूसरी ओर, रिलेशनल मॉडल, स्केलर प्रकार, विशेषताओं, संबंध चर और संपूर्ण डेटाबेस पर [[घोषणात्मक प्रोग्रामिंग]] बाधाओं की मांग करता है।
+असंगत का संबंध विपरीत मॉडलों के संरचनात्मक और अखंडता पहलुओं में अंतर से होता है। जिसमे ओओ भाषाओं में, ऑब्जेक्ट को अन्य ऑब्जेक्ट से बनाया जा सकता है | इसमें अधिकांशतः उच्च स्तर तक - या अधिक सामान्य परिभाषा से विशेषज्ञ होते हैं। इससे संबंध स्कीमों की मानचित्रण में आसान सरलता हो सकती है। ऐसा इसलिए है क्योंकि संबंध डेटा को वैश्विक, अनारक्षित संबंध वेरिएबल्स के नामित सेट में दर्शाया जाता है। यह स्वयं संबंध, ही हेडर के अनुरूप टुपल्स के सेट होने के कारण ([[टपल]] संबंध गणना को देखें) | और ओओ भाषाओं में कोई आदर्श समकक्ष नहीं होते है। यह ओओ भाषाओं में बाधाओं को सामान्यतः इस तरह घोषित नहीं किया जाता है, किन्तु एन्कैप्सुलेटेड आंतरिक डेटा पर काम करने वाले कोड के आसपास सुरक्षा तर्क बढ़ाने वाले अपवाद के रूप में प्रकट होते हैं। दूसरी ओर, संबंध मॉडल, अदिश प्रकार, विशेषताओं, संबंध चर और संपूर्ण डेटाबेस पर [[घोषणात्मक प्रोग्रामिंग]] बाधाओं की मांग करता है।
-=== जोड़ तोड़ मतभेद ===
+=== प्रकलित असमानत ===
-हालाँकि, अर्थ संबंधी अंतर विशेष रूप से विपरीत मॉडलों के हेरफेर पहलुओं में स्पष्ट हैं। रिलेशनल मॉडल में क्वेरी और डेटा के हेरफेर में उपयोग के लिए आदिम ऑपरेटरों का आंतरिक, अपेक्षाकृत छोटा और अच्छी तरह से परिभाषित सेट होता है, जबकि ओओ भाषाएं आम तौर पर कस्टम-निर्मित या निचले स्तर, केस- और भौतिक-पहुंच के माध्यम से क्वेरी और हेरफेर को संभालती हैं। -पथ-विशिष्ट [[अनिवार्य प्रोग्रामिंग]] संचालन। कुछ OO भाषाओं में घोषणात्मक क्वेरी उपभाषाओं के लिए समर्थन होता है, लेकिन क्योंकि OO भाषाएँ आम तौर पर सूचियों और शायद [[हैश तालिका|हैश तालिकाओ]] से निपटती हैं, इसलिए जोड़-तोड़ करने वाले आदिम आवश्यक रूप से संबंधपरक मॉडल के [[सेट (कंप्यूटर विज्ञान)]]-आधारित संचालन से अलग होते हैं।
+चूँकि, अर्थ संबंधी अंतर विशेष रूप से विपरीत मॉडलों के इधर उधर के पहलुओं में स्पष्ट होते हैं। इस प्रकार संबंध मॉडल में क्वेरी और डेटा के इधर उधर में उपयोग के लिए प्राचीन ऑपरेटरों का आंतरिक, अपेक्षाकृत छोटा और अच्छी तरह से परिभाषित सेट होता है, जबकि ओओ भाषाएं सामान्यतः कस्टम-निर्मित या निचले स्तर, केस- और भौतिक-पहुंच के माध्यम से क्वेरी और इधर उधर के कार्य को संभालती हैं। जिसमे पथ-विशिष्ट [[अनिवार्य प्रोग्रामिंग]] संचालन होता हैं। अनेक ओओ भाषाओं में घोषणात्मक क्वेरी उपभाषाओं के लिए समर्थन होता है, किन्तु ओओ भाषाएँ सामान्यतः सूचियों और संभवतः [[हैश तालिका|हैश तालिकाओ]] से निपटती हैं, इसलिए जोड़-तोड़ करने वाले प्राचीन आवश्यक रूप से रिलेशनल मॉडल के [[सेट (कंप्यूटर विज्ञान)]]-आधारित संचालन से अलग होते हैं।
-=== लेन-देन संबंधी मतभेद ===
+=== क्रिया कलाप संबंधी असमानत ===
-समवर्ती और लेन-देन के पहलू भी काफी भिन्न हैं। विशेष रूप से,[[डेटाबेस लेनदेन]], डेटाबेस द्वारा किए गए कार्य की सबसे छोटी इकाई, ओओ भाषाओं में कक्षाओं द्वारा किए गए किसी भी ऑपरेशन की तुलना में संबंधपरक डेटाबेस में बहुत बड़ी होती है। रिलेशनल डेटाबेस में लेनदेन मनमाने ढंग से डेटा हेरफेर के गतिशील रूप से बंधे हुए सेट होते हैं, जबकि ओओ भाषा में लेनदेन की ग्रैन्युलैरिटी आम तौर पर आदिम-टाइप किए गए फ़ील्ड के लिए व्यक्तिगत असाइनमेंट के स्तर पर होती है। सामान्य तौर पर, OO भाषाओं में अलगाव या स्थायित्व का कोई एनालॉग नहीं होता है, इसलिए परमाणुता और स्थिरता केवल उन आदिम प्रकारों के क्षेत्रों में लिखते समय सुनिश्चित की जाती है।
+समवर्ती और क्रिया कलाप के पहलू भी अधिक भिन्न होते हैं। और यह विशेष रूप से,[[डेटाबेस लेनदेन]], डेटाबेस द्वारा किए गए कार्य की सबसे छोटी इकाई होते हैं | जिसमे ओओ भाषाओं में कक्षाओं द्वारा किए गए किसी भी ऑपरेशन की तुलना में रिलेशनल डेटाबेस में बहुत बड़ी होती है। इस संबंध डेटाबेस में लेनदेन इच्छानुसार से डेटा इधर उधर के गतिशील रूप से बंधे हुए सेट होते हैं | जबकि ओओ भाषा में लेनदेन की पठन स्तर सामान्यतः प्राचीन-टाइप किए गए क्षेत्र के लिए व्यक्तिगत मूल्यांकन के स्तर पर होती है। सामान्यतः, ओओ भाषाओं में एकांत या स्थायित्व का कोई एनालॉग नहीं होता है, इसलिए परमाणुता और स्थिरता केवल उन प्राचीन प्रकारों के क्षेत्रों में लिखते समय सुनिश्चित की जाती है।
-== प्रतिबाधा बेमेल को हल करना ==
+== प्रतिबाधा असंगत को हल करना ==
-ऑब्जेक्ट-ओरिएंटेड प्रोग्रामों के लिए प्रतिबाधा बेमेल समस्या के आसपास काम करना नियोजित किए जा रहे विशिष्ट तर्क प्रणालियों में अंतर की पहचान के साथ शुरू होता है। फिर बेमेल को या तो कम कर दिया जाता है या उसकी भरपाई कर दी जाती है।<ref>[http://oro.open.ac.uk/18644/  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. ]</ref>
+ऑब्जेक्ट-उन्मुखी प्रोग्रामों के लिए प्रतिबाधा असंगत समस्या के आसपास काम करना नियोजित किए जा रहे विशिष्ट तर्क प्रणालियों में अंतर की पहचान के साथ प्रारंभिक होता है। फिर यह असंगत को तब आसान कर दिया जाता है या उसकी भरपाई कर दी जाती है।<ref>[http://oro.open.ac.uk/18644/  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. ]</ref>
 === वैकल्पिक आर्किटेक्चर ===
-ऑब्जेक्ट-रिलेशनल प्रतिबाधा बेमेल समस्या OO और डेटाबेस के बीच सार्वभौमिक समस्या नहीं है। जैसा कि नाम से पता चलता है, यह प्रतिबाधा समस्या केवल संबंधपरक डेटाबेस के साथ होती है। इस समस्या का सबसे आम समाधान वैकल्पिक डेटाबेस, जैसे [[NoSQL]] या XML डेटाबेस का उपयोग करना है।
+ऑब्जेक्ट-संबंध प्रतिबाधा असंगत समस्या ओओ और डेटाबेस के मध्य सार्वभौमिक समस्या नहीं होती है। जैसा कि नाम से पता चलता है, यह प्रतिबाधा समस्या केवल रिलेशनल डेटाबेस के साथ होती है। इस समस्या का सबसे सरल समाधान वैकल्पिक डेटाबेस, जैसे [[NoSQL|एनओएसक्यूएल]] या एक्सएमएल डेटाबेस का उपयोग करना है।
 === न्यूनीकरण ===
-[[ऑब्जेक्ट डेटाबेस|ऑब्जेक्ट ओरिएंटेड]] डेटाबेस मैनेजमेंट सिस्टम (ओओडीबीएमएस) बनाने के कुछ प्रयास किए गए हैं जो प्रतिबाधा बेमेल समस्या से बचेंगे। हालाँकि, वे संबंधपरक डेटाबेस की तुलना में व्यवहार में कम सफल रहे हैं, आंशिक रूप से डेटा मॉडल के आधार के रूप में OO सिद्धांतों की सीमाओं के कारण। <ref>C. J. Date, Relational Database Writings</ref> [[सॉफ़्टवेयर ट्रांसेक्शनल मेमोरी]]जैसी धारणाओं के माध्यम से ओओ भाषाओं की डेटाबेस जैसी क्षमताओं को विस्तारित करने पर शोध किया गया है।
+[[ऑब्जेक्ट डेटाबेस|ऑब्जेक्ट उन्मुखी]] डेटाबेस प्रबंध रिलेशनल (ओओडीबीएमएस) बनाने के अनेक प्रयास किए गए हैं जो प्रतिबाधा असंगत समस्या से बचते हैं । चूँकि, वे रिलेशनल डेटाबेस की तुलना में व्यवहार में आसान सफल हो रहे हैं,और आंशिक रूप से डेटा मॉडल के आधार के रूप में ओओ सिद्धांत की सीमाओं के कारण होता हैं। <ref>C. J. Date, Relational Database Writings</ref> और [[सॉफ़्टवेयर ट्रांसेक्शनल मेमोरी]] जैसी धारणाओं के माध्यम से ओओ भाषाओं की डेटाबेस जैसी क्षमताओं को विस्तारित करने पर शोध किया गया है।
-प्रतिबाधा बेमेल समस्या का सामान्य समाधान डोमेन और फ्रेमवर्क तर्क को परत करना है। इस योजना में, OO भाषा का उपयोग अधिक स्थिर मानचित्रण के प्रयास के बजाय रनटाइम पर कुछ संबंधपरक पहलुओं को मॉडल करने के लिए किया जाता है। इस विधि को नियोजित करने वाले फ़्रेमवर्क में आम तौर पर टुपल के लिए एनालॉग होगा, आमतौर पर "डेटासेट" घटक में "पंक्ति" के रूप में या सामान्य "इकाई उदाहरण" वर्ग के रूप में, साथ ही किसी संबंध के लिए एनालॉग भी होगा। इस दृष्टिकोण के लाभों में शामिल हो सकते हैं:
+प्रतिबाधा असंगत समस्या का सामान्य समाधान स्थान और रूपरेखा तर्क को परत करना है। इस योजना में, ओओ भाषा का उपयोग और अधिक स्थिर मानचित्रण के प्रयास के अतिरिक्त रनटाइम पर अनेक संबंध परक पहलुओं को मॉडल करने के लिए किया जाता है। इस विधि को नियोजित करने वाले फ़्रेमवर्क में सामान्यतः टुपल के लिए एनालॉग होता है | और सामान्यतः "डेटासेट" घटक में "पंक्ति" के रूप में या सामान्य "इकाई उदाहरण" वर्ग के रूप में होता हैं | इसके साथ ही इसमें किसी संबंध के लिए एनालॉग भी होता हैं। इस प्रकार दृष्टिकोण के लाभों में सम्मिलित हो सकते हैं|
-*डोमेन डेटा के परिवहन, प्रस्तुति और सत्यापन के आसपास ढांचे और स्वचालन के निर्माण के लिए सीधे रास्ते होते हैं ।
+*स्थान डेटा के परिवहन, प्रस्तुति और सत्यापन के आसपास ढांचे और स्वचालन के निर्माण के लिए सीधे रास्ते होते हैं ।
-* छोटा कोड आकार; तेज़ संकलन और लोड समय।
+* छोटा कोड आकार; तेज़ संकलन और लोड के समय लिया जाता हैं।
-* [[डेटाबेस स्कीमा]] को गतिशील रूप से बदलने की क्षमता।
+* [[डेटाबेस स्कीमा]] को गतिशील रूप में बदलने की क्षमता होती हैं।
-* नाम-स्थान और अर्थ संबंधी बेमेल मुद्दों से बचा जाता है।
+* इसमें नाम-स्थान और अर्थ संबंधी असंगत उद्देश्यों से बचा जाता है।
-* अभिव्यंजक बाधा जाँच
+* इसमें अभिव्यंजक बाधा जाँच भी होती हैं |
-* कोई जटिल मानचित्रण आवश्यक नहीं
+* कोई जटिल मानचित्रण आवश्यक नहीं होता हैं |
-नुकसान में शामिल हो सकते हैं:
+*यह हानि में भी सम्मिलित हो सकते हैं |
-*स्थैतिक प्रकार की "सुरक्षा" जांच का अभाव। टाइप किए गए ्सेसर्स का उपयोग कभी-कभी इसे कम करने के तरीके के रूप में किया जाता है।
-* रनटाइम निर्माण और पहुंच की संभावित प्रदर्शन लागत।
-* [[ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग में बहुरूपता]] जैसे विशिष्ट OO पहलुओं का मूल रूप से उपयोग करने में असमर्थता होती हैं।
-=== मुआवजा ===
+*इसमें स्थैतिक प्रकार की "सुरक्षा" जांच का अभाव होता हैं। और टाइप किए गए सेंसर्स का उपयोग कभी-कभी इसे आसान करने के विधि के रूप में किया जाता है।
-ओओ एप्लिकेशन कोड के भीतर [[प्रवचन के स्तर|प्रवचन के स्तरो]] का मिश्रण समस्याएं प्रस्तुत करता है, लेकिन क्षतिपूर्ति के लिए कुछ सामान्य तंत्रों का उपयोग किया जाता है। सबसे बड़ी चुनौती चर्चा के उस स्तर के भीतर फ्रेमवर्क समर्थन, डेटा हेरफेर और प्रस्तुति पैटर्न का स्वचालन प्रदान करना है जिसमें डोमेन डेटा को मॉडल किया जा रहा है। इसे संबोधित करने के लिए, प्रतिबिंब और/या [[स्वचालित प्रोग्रामिंग]] का उपयोग किया जाता है। प्रतिबिंब कोड (वर्गों) को डेटा के रूप में संबोधित करने की अनुमति देता है और इस प्रकार डेटा के परिवहन, प्रस्तुति, अखंडता आदि का स्वचालन प्रदान करता है। जनरेशन इकाई संरचनाओं को कोड जनरेशन टूल या मेटा-प्रोग्रामिंग भाषाओं के लिए डेटा इनपुट के रूप में संबोधित करके समस्या का समाधान करता है, जो सामूहिक रूप से कक्षाओं और सहायक बुनियादी ढांचे का निर्माण करते हैं। ये दोनों योजनाएँ अभी भी कुछ विसंगतियों के अधीन हो सकती हैं जहाँ चर्चा के ये स्तर विलीन हो जाते हैं। उदाहरण के लिए, जेनरेट की गई इकाई कक्षाओं में आम तौर पर ऐसे गुण होंगे जो डोमेन पर मैप होते हैं (उदाहरण के लिए नाम, पता) और साथ ही ऐसे गुण जो राज्य प्रबंधन और अन्य ढांचे के बुनियादी ढांचे (उदाहरण के लिए IsModified) प्रदान करते हैं।
+* रनटाइम निर्माण और पहुंच की संभावित प्रदर्शन निवेश होती हैं।
+* [[ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग में बहुरूपता|ऑब्जेक्ट-उन्मुखी प्रोग्रामिंग में बहुरूपता]] जैसे विशिष्ट ओओ पहलुओं का मूल रूप से उपयोग करने में असमर्थता होती हैं।
-== घटना ==
+=== प्रतिपूर्ति ===
-यद्यपि ऑब्जेक्ट-रिलेशनल प्रतिबाधा बेमेल सामान्य रूप से ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग के साथ हो सकता है, कठिनाई का विशेष क्षेत्र [[ऑब्जेक्ट रिलेशनल मैपर|ऑब्जेक्ट रिलेशनल मैपर्स]] (ओआरएम) के साथ है।<ref>[https://www.semanticscholar.org/paper/Object-Relational-Mapping-Revisited-A-Quantitative-Lorenz-Rudolph/708ac5e798b7e45b949d42e2f872549a3612e1e2 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)</ref> चूँकि ओएमआर को अक्सर कॉन्फ़िगरेशन, एनोटेशन और प्रतिबंधित [[डोमेन-विशिष्ट भाषा]]ओं के संदर्भ में निर्दिष्ट किया जाता है, इसलिए इसमें प्रतिबाधा बेमेल को हल करने के लिए पूर्ण प्रोग्रामिंग भाषा के लचीलेपन का अभाव होता है।
+ओओ एप्लिकेशन कोड के अंदर [[प्रवचन के स्तर|प्रवचन के स्तरो]] का मिश्रण समस्याएं प्रस्तुत करता है, किन्तु क्षतिपूर्ति के लिए अनेक सामान्य तंत्रों का उपयोग किया जाता है। यह सबसे बड़ी चुनौती चर्चा के उस स्तर के अंदर रूपरेखा समर्थन, डेटा इधर उधर और प्रस्तुति क्रम का स्वचालन प्रदान करना है | जिसमें स्थान डेटा को मॉडल किया जा रहा है। इसे संबोधित करने के लिए, प्रतिबिंब या [[स्वचालित प्रोग्रामिंग]] का उपयोग किया जाता है। इस प्रकार प्रतिबिंब कोड (वर्गों) को डेटा के रूप में संबोधित करने की अनुमति देता है और इस प्रकार डेटा के परिवहन, प्रस्तुति, अखंडता आदि का स्वचालन प्रदान करता है। इस जनरेशन इकाई संरचनाओं को कोड जनरेशन टूल या मेटा-प्रोग्रामिंग भाषाओं के लिए डेटा इनपुट के रूप में संबोधित करके समस्या का समाधान करता है, जो सामूहिक रूप से कक्षाओं और सहायक मूलभूत ढांचे का निर्माण करते हैं। ये दोनों योजनाएँ अभी भी अनेक विसंगतियों के अधीन हो सकती हैं जहाँ चर्चा के ये स्तर विलीन हो जाते हैं। उदाहरण के लिए, जेनरेट की गई इकाई कक्षाओं में सामान्यतः ऐसे गुण होंगे जो स्थान पर मानचित्रत होते हैं | और (उदाहरण के लिए नाम, पता) और साथ ही ऐसे गुण जो राज्य प्रबंधन और अन्य ढांचे के मूलभूत ढांचे (उदाहरण के लिए संशोधित है) प्रदान करते हैं।
-== विवाद ==
+== उपस्थिति ==
-=== सच्चा आरडीबीएमएस मॉडल ===
+यद्यपि ऑब्जेक्ट-संबंध प्रतिबाधा असंगत सामान्य रूप से ऑब्जेक्ट-उन्मुखी प्रोग्रामिंग के साथ हो सकता है | इस प्रकार कठिनाई का विशेष क्षेत्र [[ऑब्जेक्ट रिलेशनल मैपर|ऑब्जेक्ट संबंध मानचित्रण]](ओआरएम) के साथ होता है।<ref>[https://www.semanticscholar.org/paper/Object-Relational-Mapping-Revisited-A-Quantitative-Lorenz-Rudolph/708ac5e798b7e45b949d42e2f872549a3612e1e2 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)</ref> चूँकि ओएमआर को अधिकांशतः विन्यास, टिप्पणी और प्रतिबंधित [[डोमेन-विशिष्ट भाषा|डोमेन-विशिष्ट भाषाओं]] के संदर्भ में निर्दिष्ट किया जाता है, इसलिए इसमें प्रतिबाधा असंगत को हल करने के लिए पूर्ण प्रोग्रामिंग भाषा के अन्तःकरण का अभाव होता है।
-क्रिस्टोफर जे. डेट और अन्य लोगों द्वारा यह तर्क दिया गया है कि वास्तव में संबंधपरक डीबीएमएस ऐसी कोई समस्या उत्पन्न नहीं करेगा,<ref>{{Citation | url=http://dbdebunk.blogspot.com.br/2012/08/type-vs-domain-and-class.html | first1 = Christopher ‘Chris’ J | last1 = Date | first2 = Fabian | last2 = Pascal | author2-link = Fabian Pascal | title = Database debunkings | date = 2012-08-12 | orig-year = 2005 | contribution = Type vs. Domain and Class | publisher = Google | format = World Wide Web log | access-date = 12 September 2012}}.</ref><ref>{{Citation | first = Christopher ‘Chris’ J | last = Date | author-mask = 3 | chapter = 4. On the notion of logical difference | quote = Class seems to be indistinguishable from type, as that term is classically understood | page = 39 | title = Date on Database: writings 2000–2006 | publisher = Apress | year = 2006 | place = [[United States of America|USA]] | isbn = 978-1-59059-746-0 | series = The expert’s voice in database; Relational database select writings}}.</ref><ref>{{Citation | first = Christopher ‘Chris’ J | last = Date | author-mask = 3 | chapter = 26. Object/Relational databases | quote = ...any such ''rapprochement'' should be firmly based on the relational model | page = [https://archive.org/details/introductiontoda0000date/page/859 859] | title = An introduction to database systems | edition = 8th | publisher = Pearson Addison Wesley | year = 2004 | isbn = 978-0-321-19784-9 | chapter-url = https://archive.org/details/introductiontoda0000date/page/859 }}.</ref> चूँकि [[डेटा डोमेन]] और क्लास (कंप्यूटर विज्ञान) अनिवार्य रूप से ही चीज़ हैं। कक्षाओं और संबंधपरक स्कीमाटा के बीच मूल मानचित्रण मौलिक डिजाइन गलती है;<ref>{{Citation | last1 = Date | first1 = Christopher ‘Chris’ J | author1-link = Christopher_J._Date | last2 = Darwen | first2 = Hugh | author2-link = Hugh Darwen | title = The Third Manifesto | chapter = 2. Objects and Relations | quote = The first great blunder }}</ref> और डेटाबेस तालिका (संबंध) के भीतर व्यक्तिगत टुपल्स को संस्थाओं के बीच संबंध स्थापित करने के रूप में देखा जाना चाहिए; स्वयं जटिल संस्थाओं के प्रतिनिधित्व के रूप में नहीं। हालाँकि, यह दृश्य ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग के प्रभाव और भूमिका को कम कर देता है, इसे फ़ील्ड प्रकार प्रबंधन प्रणाली से थोड़ा अधिक उपयोग करता है।
-=== बाधाएं और अवैध लेनदेन ===
+== प्रतिद्वंद्विता ==
-प्रतिबाधा बेमेल [[डोमेन ऑब्जेक्ट]] और उपयोगकर्ता इंटरफ़ेस के बीच प्रोग्रामिंग में है। ऑपरेटरों, प्रबंधकों और अन्य गैर-प्रोग्रामरों को डेटाबेस में रिकॉर्ड तक पहुंचने और हेरफेर करने की अनुमति देने के लिए परिष्कृत उपयोगकर्ता इंटरफ़ेस के लिए अक्सर विभिन्न डेटाबेस विशेषताओं (नाम और प्रकार से परे) की प्रकृति के बारे में गहन ज्ञान की आवश्यकता होती है। विशेष रूप से, उपयोगकर्ता इंटरफ़ेस को डिज़ाइन करना अच्छा अभ्यास माना जाता है (अंतिम-उपयोगकर्ता उत्पादकता के दृष्टिकोण से) ताकि यूआई अवैध लेनदेन (जो डेटाबेस बाधा का उल्लंघन करते हैं) को प्रवेश करने से रोक सके; ऐसा करने के लिए [[कोड दोहराव]] रिलेशनल स्कीमाटा में मौजूद अधिकांश तर्क को कोड में डुप्लिकेट करने की आवश्यकता होती है।
+=== यथार्थ आरडीबीएमएस मॉडल ===
+क्रिस्टोफर जे. डेट और अन्य लोगों द्वारा यह तर्क दिया गया है कि वास्तव में रिलेशनल डीबीएमएस ऐसी कोई समस्या उत्पन्न नहीं करेगा |<ref>{{Citation | url=http://dbdebunk.blogspot.com.br/2012/08/type-vs-domain-and-class.html | first1 = Christopher ‘Chris’ J | last1 = Date | first2 = Fabian | last2 = Pascal | author2-link = Fabian Pascal | title = Database debunkings | date = 2012-08-12 | orig-year = 2005 | contribution = Type vs. Domain and Class | publisher = Google | format = World Wide Web log | access-date = 12 September 2012}}.</ref><ref>{{Citation | first = Christopher ‘Chris’ J | last = Date | author-mask = 3 | chapter = 4. On the notion of logical difference | quote = Class seems to be indistinguishable from type, as that term is classically understood | page = 39 | title = Date on Database: writings 2000–2006 | publisher = Apress | year = 2006 | place = [[United States of America|USA]] | isbn = 978-1-59059-746-0 | series = The expert’s voice in database; Relational database select writings}}.</ref><ref>{{Citation | first = Christopher ‘Chris’ J | last = Date | author-mask = 3 | chapter = 26. Object/Relational databases | quote = ...any such ''rapprochement'' should be firmly based on the relational model | page = [https://archive.org/details/introductiontoda0000date/page/859 859] | title = An introduction to database systems | edition = 8th | publisher = Pearson Addison Wesley | year = 2004 | isbn = 978-0-321-19784-9 | chapter-url = https://archive.org/details/introductiontoda0000date/page/859 }}.</ref> चूँकि [[डेटा डोमेन|डेटा]] स्थान और कक्षा (कंप्यूटर विज्ञान) अनिवार्य रूप से ऑब्जेक्ट होती हैं। जहाँ कक्षाओं और रिलेशनल स्कीमाटा के मध्य मूल मानचित्रण मौलिक डिजाइन में त्रुटि होती है |<ref>{{Citation | last1 = Date | first1 = Christopher ‘Chris’ J | author1-link = Christopher_J._Date | last2 = Darwen | first2 = Hugh | author2-link = Hugh Darwen | title = The Third Manifesto | chapter = 2. Objects and Relations | quote = The first great blunder }}</ref> और डेटाबेस तालिका (संबंध) के अंदर व्यक्तिगत टुपल्स को संस्थाओं के मध्य संबंध स्थापित करने के रूप में देखा जाना चाहिए | जिसमे यह स्वयं जटिल संस्थाओं के प्रतिनिधित्व के रूप में नहीं होते हैं। चूँकि, यह दृश्य ऑब्जेक्ट-उन्मुखी प्रोग्रामिंग के प्रभाव और भूमिका को आसान कर देता है, और यह क्षेत्र प्रकार प्रबंधन रिलेशनल से थोड़ा अधिक उपयोग करता है।
-कुछ कोड-विकास ढाँचे डेटाबेस के स्कीमा (जैसे संदर्भात्मक अखंडता बाधाएं) में दर्शाए गए तर्क के कुछ रूपों का लाभ उठा सकते हैं, ताकि ऐसे मुद्दों को किसी मामले पर लिखे गए तदर्थ कोड के बजाय लाइब्रेरी रूटीन के माध्यम से सामान्य और मानक फैशन में नियंत्रितजा सके। -मामला-दर-मामला आधार।
+=== व्यवरोध और अवैधता कार्यविवरण ===
+प्रतिबाधा असंगत [[डोमेन ऑब्जेक्ट|स्थान]]ऑब्जेक्ट और उपयोगकर्ता इंटरफ़ेस के मध्य प्रोग्रामिंग में होता है। ऑपरेटरों, प्रबंधकों और अन्य गैर-प्रोग्रामरों को डेटाबेस में रिकॉर्ड तक पहुंचने और इधर उधर करने की अनुमति देने के लिए परिष्कृत उपयोगकर्ता इंटरफ़ेस के लिए अधिकांशतः विभिन्न डेटाबेस विशेषताओं (नाम और प्रकार से परे) की प्रकृति के बारे में गहन ज्ञान की आवश्यकता होती है। विशेष रूप से, उपयोगकर्ता इंटरफ़ेस को डिज़ाइन करना अच्छा अभ्यास माना जाता है | और (अंतिम-उपयोगकर्ता उत्पादकता के दृष्टिकोण से) जिससे यूआई अवैध लेनदेन (जो डेटाबेस बाधा का उल्लंघन करते हैं) को प्रवेश करने से रोक सकते हैं | ऐसा करने के लिए [[कोड दोहराव]] संबंध स्कीमाटा में उपस्थित अधिकांश तर्क को कोड में प्रतिलिपि करने की आवश्यकता होती है।
-=== SQL-विशिष्ट प्रतिबाधा और समाधान ===
+अनेक कोड-विकास प्रारूप डेटाबेस के स्कीमा (जैसे संदर्भात्मक अखंडता बाधाएं) में दर्शाए गए तर्क के अनेक रूपों का लाभ उठा सकते हैं, जिससे ऐसे उद्देश्यों को किसी स्थिति पर लिखे गए अनौपचारिक कोड के अतिरिक्त लाइब्रेरी रूटीन के माध्यम से सामान्य और मानक प्रचलन में नियंत्रित किया जा सकता हैं। यह विषयानुसार आधार होता हैं।
-यह तर्क दिया गया है कि SQL, डोमेन प्रकारों के बहुत सीमित सेट (और अन्य कथित त्रुटियों) के कारण उचित ऑब्जेक्ट और डोमेन-मॉडलिंग को कठिन बना देता है; और यह कि SQL DBMS और एप्लिकेशन प्रोग्राम (चाहे ऑब्जेक्ट-ओरिएंटेड शैली में लिखा गया हो या नहीं) के बीच बहुत ही हानिपूर्ण और अकुशल इंटरफ़ेस बनाता है। हालाँकि, SQL वर्तमान में बाज़ार में मात्र व्यापक रूप से स्वीकृत सामान्य डेटाबेस भाषा है''';''' विक्रेता-विशिष्ट क्वेरी भाषाओं का उपयोग टाले जाने योग्य होने पर खराब अभ्यास के रूप में देखा जाता है। अन्य डेटाबेस भाषाएँ जैसे [[बिजनेस सिस्टम 12]] और ट्यूटोरियल डी प्रस्तावित की गई हैं; लेकिन इनमें से किसी को भी डीबीएमएस विक्रेताओं द्वारा व्यापक रूप से नहीं अपनाया गया है।
-Oracle और Microsoft SQL सर्वर जैसे मुख्यधारा ऑब्जेक्ट-रिलेशनल DBMS के वर्तमान संस्करणों में, उपरोक्त बिंदु गैर-मुद्दा हो सकता है। इन इंजनों के साथ, किसी दिए गए डेटाबेस की कार्यक्षमता को आधुनिक OO भाषा (Oracle के लिए Java, और SQL सर्वर के लिए Microsoft .NET भाषा) में लिखे गए संग्रहीत कोड (फ़ंक्शन और प्रक्रियाओं) के माध्यम से मनमाने ढंग से बढ़ाया जा सकता है, और इन कार्यों को लागू किया जा सकता है SQL कथनों को पारदर्शी तरीके से इन-टर्न करें: अर्थात, उपयोगकर्ता को न तो पता है और न ही इसकी परवाह है कि ये फ़ंक्शन/प्रक्रियाएँ मूल रूप से डेटाबेस इंजन का हिस्सा नहीं थीं। आधुनिक सॉफ्टवेयर-विकास प्रतिमान पूरी तरह से समर्थित हैं: इस प्रकार, कोई लाइब्रेरी रूटीन का सेट बना सकता है जिसे कई डेटाबेस स्कीमा में पुन: उपयोग किया जा सकता है
+=== एसक्यूएल-विशिष्ट प्रतिबाधा और समाधान ===
+यह तर्क दिया गया है कि एसक्यूएल , स्थान प्रकारों के बहुत सीमित सेट (और अन्य कथित त्रुटियों) के कारण उचित ऑब्जेक्ट और डोमेन-मॉडलिंग को कठिन बना देता है; और यह कि एसक्यूएल डीबीएमएस और एप्लिकेशन प्रोग्राम (चाहे ऑब्जेक्ट-उन्मुखी शैली में लिखा गया हो या नहीं) के मध्य बहुत ही हानि पूर्ण और अकुशल इंटरफ़ेस बनाता है। चूँकि, एसक्यूएल वर्तमान में बाज़ार में मात्र व्यापक रूप से स्वीकृत सामान्य डेटाबेस भाषा है | विक्रेता-विशिष्ट क्वेरी भाषाओं का उपयोग टाले जाने योग्य होने पर खराब अभ्यास के रूप में देखा जाता है। अन्य डेटाबेस भाषाएँ जैसे [[बिजनेस सिस्टम 12|बिजनेस रिलेशनल 12]] और ट्यूटोरियल डी प्रस्तावित की गई हैं; किन्तु इनमें से किसी को भी डीबीएमएस विक्रेताओं द्वारा व्यापक रूप से नहीं अपनाया गया है।
-इन विक्रेताओं ने DBMS बैक-एंड पर OO-भाषा एकीकरण का समर्थन करने का निर्णय लिया क्योंकि उन्हें एहसास हुआ कि, SQL में प्रक्रियात्मक निर्माणों को जोड़ने के लिए ISO SQL-99 समिति के प्रयासों के बावजूद, SQL में पुस्तकालयों और डेटा संरचनाओं का समृद्ध सेट कभी नहीं होगा। आज के एप्लिकेशन प्रोग्रामर इसे हल्के में लेते हैं, और मुख्य SQL भाषा का विस्तार करने का प्रयास करने के बजाय इनका यथासंभव सीधे लाभ उठाना उचित है। नतीजतन, "एप्लिकेशन प्रोग्रामिंग" और "डेटाबेस प्रशासन" के बीच का अंतर अब धुंधला हो गया है: बाधाओं और ट्रिगर्स जैसी सुविधाओं के मजबूत कार्यान्वयन के लिए अक्सर दोहरे डीबीए/ओओ-प्रोग्रामिंग कौशल वाले व्यक्ति या इन कौशलों को संयोजित करने वाले व्यक्तियों के बीच साझेदारी की आवश्यकता हो सकती है। . यह तथ्य नीचे दिए गए "जिम्मेदारी के विभाजन" मुद्दे पर भी लागू होता है।
+ओरेकल और माइक्रोसॉफ्टएसक्यूएल सर्वर जैसे मुख्यधारा ऑब्जेक्ट-संबंध डीबीएमएस के वर्तमान संस्करणों में, उपरोक्त बिंदु गैर-उद्देश्य हो सकता है। इन इंजनों के साथ, किसी दिए गए डेटाबेस की कार्यक्षमता को आधुनिक ओओ भाषा (ओरेकल के लिए जावा, और एसक्यूएल सर्वर के लिए माइक्रोसॉफ्ट.नेट भाषा) में लिखे गए संग्रहीत कोड (फ़ंक्शन और प्रक्रियाओं) के माध्यम से इच्छानुसार से बढ़ाया जा सकता है, और इन कार्यों को प्रयुक्त किया जा सकता है एसक्यूएल कथनों को पारदर्शी विधि से इन-टर्न करते हैं | अर्थात, उपयोगकर्ता को न तब पता है और न ही इसकी परवाह है कि ये फ़ंक्शन/प्रक्रियाएँ मूल रूप से डेटाबेस इंजन का हिस्सा नहीं थीं। आधुनिक सॉफ्टवेयर-विकास प्रतिमान पूरी तरह से समर्थित होते हैं और इस प्रकार, कोई लाइब्रेरी रूटीन का सेट बना सकता है जिसे अनेक डेटाबेस स्कीमा में पुन: उपयोग किया जा सकता है
-हालाँकि, कुछ लोग यह कहेंगे कि यह विवाद इस तथ्य के कारण विवादास्पद है कि: (1) आरडीबीएमएस का उद्देश्य कभी भी ऑब्जेक्ट मॉडलिंग की सुविधा प्रदान करना नहीं था, और (2) एसक्यूएल को आम तौर पर केवल हानिपूर्ण या अक्षम इंटरफ़ेस भाषा के रूप में देखा जाना चाहिए जब कोई हो ऐसा समाधान प्राप्त करने का प्रयास किया जा रहा है जिसके लिए RDBMSes डिज़ाइन नहीं किए गए थे। SQL वह काम करने में बहुत कुशल है जिसके लिए इसे डिज़ाइन किया गया था, अर्थात् डेटा के बड़े सेट को क्वेरी करना, सॉर्ट करना, फ़िल्टर करना और संग्रहीत करना। कुछ लोग अतिरिक्त रूप से इंगित करेंगे कि बैक-एंड में ओओ भाषा कार्यक्षमता को शामिल करने से खराब वास्तुशिल्प अभ्यास की सुविधा मिलती है, क्योंकि यह आरडीबीएमएस के विपरीत, डेटा स्तर में उच्च स्तरीय एप्लिकेशन तर्क को स्वीकार करता है।
+इन विक्रेताओं ने डीबीएमएस बैक-एंड पर ओओ -भाषा एकीकरण का समर्थन करने का निर्णय लिया क्योंकि उन्हें मनोभाव हुआ था कि, एसक्यूएल में प्रक्रियात्मक निर्माणों को जोड़ने के लिए आईएस ओएसक्यूएल-99 समिति के प्रयासों के अतिरिक्त, एसक्यूएल में पुस्तकालयों और डेटा संरचनाओं का समृद्ध सेट कभी नहीं होगा। आज के एप्लिकेशन प्रोग्रामर इसे सरलता में लेते हैं, और मुख्य एसक्यूएल भाषा का विस्तार करने का प्रयास करने के अतिरिक्त इनका यथासंभव सीधे लाभ उठाना उचित होता है। परिणाम स्वरुप , "एप्लिकेशन प्रोग्रामिंग" और "डेटाबेस प्रशासन" के मध्य का अंतर अभी धुंधला हो गया है | बाधाओं और ट्रिगर्स जैसी सुविधाओं के शक्तिशाली कार्यान्वयन के लिए अधिकांशतः दोहरे डीबीए/ओओ-प्रोग्रामिंग कौशल वाले व्यक्ति या इन कौशलों को संयोजित करने वाले व्यक्तियों के मध्य साझेदारी की आवश्यकता हो सकती है। यह तथ्य नीचे दिए गए "जिम्मेदारी के विभाजन" मुद्दे पर भी प्रयुक्त होता है।
+चूँकि, अनेक लोग यह कहेंगे कि यह विवाद इस तथ्य के कारण विवादास्पद है कि (1) आरडीबीएमएस का उद्देश्य कभी भी ऑब्जेक्ट मॉडलिंग की सुविधा प्रदान करना नहीं था, और (2) एसक्यूएल को सामान्यतः हानिपूर्ण या अक्षम इंटरफ़ेस भाषा के रूप में देखा जाना चाहिए जब कोई हो ऐसा समाधान प्राप्त करने का प्रयास किया जा रहा है जिसके लिए आरडीबीएमएसईएस डिज़ाइन नहीं किए गए थे। एसक्यूएल वह काम करने में बहुत कुशल होते है जिसके लिए इसे डिज़ाइन किया गया था, अर्थात् इसमें डेटा के बड़े सेट को क्वेरी करना, सॉर्ट करना, फ़िल्टर करना और संग्रहीत करना होता हैं। अनेक लोग अतिरिक्त रूप से इंगित करेंगे कि बैक-एंड में ओओ भाषा कार्यक्षमता को सम्मिलित करने से खराब वास्तुशिल्प अभ्यास की सुविधा मिलती है, क्योंकि यह आरडीबीएमएस के विपरीत, डेटा स्तर में उच्च स्तरीय एप्लिकेशन तर्क को स्वीकार करता है।
 === डेटा की कैनोनिकल प्रतिलिपि का स्थान ===
-यहां राज्य की विहित प्रति स्थित है। डेटाबेस मॉडल आम तौर पर मानता है कि [[डेटाबेस प्रबंधन प्रणाली]] उद्यम से संबंधित राज्य का मात्र आधिकारिक भंडार है; किसी एप्लिकेशन प्रोग्राम द्वारा रखी गई ऐसी स्थिति की कोई भी प्रतिलिपि बस यही है{{snd}} अस्थायी प्रतियां (जो पुरानी हो सकती हैं, यदि अंतर्निहित डेटाबेस रिकॉर्ड को बाद में किसी लेनदेन द्वारा संशोधित किया गया हो)। कई ऑब्जेक्ट-ओरिएंटेड प्रोग्रामर ऑब्जेक्ट के इन-मेमोरी अभ्यावेदन को कैनोनिकल डेटा के रूप में देखना पसंद करते हैं, और डेटाबेस को बैकिंग स्टोर और दृढ़ता तंत्र के रूप में देखना पसंद करते हैं।
+यहां राज्य की विहित प्रति स्थित है। डेटाबेस मॉडल सामान्यतः मानता है कि [[डेटाबेस प्रबंधन प्रणाली|डेटाबेस प्रबंधन]] रिलेशनल उद्यम से संबंधित राज्य का मात्र आधिकारिक भंडार है; किसी एप्लिकेशन प्रोग्राम द्वारा रखी गई ऐसी स्थिति की कोई भी प्रतिलिपि बस यही है{{snd}} अस्थायी प्रतियां (जो पुरानी हो सकती हैं, यदि अंतर्निहित डेटाबेस रिकॉर्ड को बाद में किसी लेनदेन द्वारा संशोधित किया गया हो)। अनेक ऑब्जेक्ट-उन्मुखी प्रोग्रामर ऑब्जेक्ट के इन-मेमोरी अभ्यावेदन को कैनोनिकल डेटा के रूप में देखना उपयुक्त करते हैं, और डेटाबेस को बैकिंग संग्रहण और दृढ़ता तंत्र के रूप में देखना उपयुक्त करते हैं।
 === उत्तरदायित्व का विभाजन ===
-विवाद का अन्य मुद्दा एप्लिकेशन प्रोग्रामर और [[ डेटाबेस प्रशासक |डेटाबेस प्रशासक]] (डीबीए) के बीच जिम्मेदारी का उचित विभाजन है। अक्सर ऐसा होता है कि एप्लिकेशन कोड में आवश्यक बदलावों के लिए (अनुरोधित नई सुविधा या कार्यक्षमता को लागू करने के लिए) डेटाबेस परिभाषा में संबंधित बदलावों की आवश्यकता होती है; अधिकांश संगठनों में, डेटाबेस परिभाषा डीबीए की ज़िम्मेदारी है। उत्पादन डेटाबेस प्रणाली को 24 घंटे बनाए रखने की आवश्यकता के कारण कई डीबीए डेटाबेस स्कीमाटा में ऐसे बदलाव करने के लिए अनिच्छुक हैं जिन्हें वे अनावश्यक या अनावश्यक मानते हैं और कुछ मामलों में ऐसा करने से सीधे इनकार कर देते हैं। विकासात्मक डेटाबेस का उपयोग (उत्पादन प्रणालियों के अलावा) कुछ हद तक मदद कर सकता है; लेकिन जब नया विकसित एप्लिकेशन लाइव होगा तो डीबीए को किसी भी बदलाव को मंजूरी देने की आवश्यकता होगी। कुछ प्रोग्रामर इसे अकर्मण्यता के रूप में देखते हैं; हालाँकि, यदि डेटाबेस परिभाषा में कोई भी बदलाव उत्पादन प्रणाली में सेवा की हानि का कारण बनता है, तो डीबीए को अक्सर जिम्मेदार ठहराया जाता है - परिणामस्वरूप, कई डीबीए एप्लिकेशन कोड में डिज़ाइन परिवर्तन शामिल करना पसंद करते हैं, जहां डिज़ाइन दोषों के भयावह परिणाम होने की संभावना बहुत कम होती है।
+विवाद का अन्य उद्देश्य एप्लिकेशन प्रोग्रामर और [[ डेटाबेस प्रशासक |डेटाबेस प्रशासक]] (डीबीए) के मध्य जिम्मेदारी का उचित विभाजन है। अधिकांशतः ऐसा होता है कि एप्लिकेशन कोड में आवश्यक बदलावों के लिए (अनुरोधित नई सुविधा या कार्यक्षमता को प्रयुक्त करने के लिए) डेटाबेस परिभाषा में संबंधित बदलावों की आवश्यकता होती है| अधिकांश संगठनों में, डेटाबेस परिभाषा डीबीए की ज़िम्मेदारी में होता है। और उत्पादन डेटाबेस रिलेशनल को 24 घंटे बनाए रखने की आवश्यकता के कारण अनेक डीबीए डेटाबेस स्कीमाटा में ऐसे बदलाव करने के लिए अनिच्छुक हैं जिन्हें वे अनावश्यक मानते हैं | इस प्रकार अनेक स्थितियों में ऐसा करने से सीधे अस्वीकार कर देते हैं। विकासात्मक डेटाबेस का उपयोग (उत्पादन प्रणालियों के अतिरिक्त) अनेक सीमा तक सहायता कर सकता है, किन्तु जब नया विकसित एप्लिकेशन लाइव होगा तब डीबीए को किसी भी बदलाव को मंजूरी देने की आवश्यकता होती हैं। अनेक प्रोग्रामर इसे अकर्मण्यता के रूप में देखते हैं, चूँकि, यदि डेटाबेस परिभाषा में कोई भी बदलाव उत्पादन रिलेशनल में सेवा की हानि का कारण बनता है, तब डीबीए को अधिकांशतः जिम्मेदार ठहराया जाता है | इसके परिणामस्वरूप, अनेक डीबीए एप्लिकेशन कोड में डिज़ाइन परिवर्तन सम्मिलित करना उपयुक्त करते हैं, जहां डिज़ाइन दोषों के भयावह परिणाम होने की संभावना बहुत आसान होती है।
-हालांकि, डीबीए और डेवलपर्स के बीच गैर-अकार्यात्मक संबंध वाले संगठनों में, उपरोक्त मुद्दा खुद को प्रस्तुत नहीं करना चाहिए, क्योंकि डेटाबेस स्कीमा को बदलने या न करने का निर्णय केवल व्यावसायिक जरूरतों से प्रेरित होगा: अतिरिक्त डेटा को बनाए रखने के लिए नई आवश्यकता या ए उदाहरण के लिए, महत्वपूर्ण एप्लिकेशन के प्रदर्शन को बढ़ावा देने से स्कीमा संशोधन शुरू हो जाएगा।
-==दार्शनिक मतभेद ==
+चूंकि, डीबीए और डेवलपर्स के मध्य गैर-अकार्यात्मक संबंध वाले संगठनों में, उपरोक्त उद्देश्य स्वमं को प्रस्तुत नहीं करना चाहिए, क्योंकि डेटाबेस स्कीमा को बदलने या न करने का निर्णय केवल व्यावसायिक जरूरतो से प्रेरित होता हैं | इसके अतिरिक्त डेटा को बनाए रखने के लिए नई आवश्यकता या ए उदाहरण के लिए, महत्वपूर्ण एप्लिकेशन के प्रदर्शन को बढ़ावा देने से स्कीमा संशोधन प्रारंभिक हो जाता हैं।
-OO और संबंधपरक मॉडल के बीच प्रमुख दार्शनिक अंतरों को निम्नानुसार संक्षेपित किया जा सकता है |
-* '''घोषणात्मक बनाम अनिवार्य इंटरफेस{{snd}}''' संबंधपरक सोच डेटा को इंटरफ़ेस के रूप में उपयोग करती है, व्यवहार को इंटरफ़ेस के रूप में नहीं। इस प्रकार इसमें ओओ के व्यवहारिक झुकाव के विपरीत डिजाइन दर्शन में घोषणात्मक झुकाव है। (कुछ संबंधपरक प्रस्तावक जटिल व्यवहार प्रदान करने के लिए ट्रिगर्स, संग्रहीत प्रक्रियाओं आदि का उपयोग करने का सुझाव देते हैं, लेकिन यह सामान्य दृष्टिकोण नहीं है।)
+==दार्शनिक असमानता ==
-*'''स्कीमा बाउंड''' '''-''' ऑब्जेक्ट को "पैरेंट स्कीमा" का पालन करने की आवश्यकता नहीं होती है जिसके लिए किसी ऑब्जेक्ट के गुण या एक्सेसर्स होते हैं, जबकि तालिका पंक्तियों को इकाई की स्कीमा का पालन करना होगा। दी गई पंक्ति और केवल इकाई से संबंधित होनी चाहिए। OO में निकटतम चीज़ वंशानुक्रम है, लेकिन यह आम तौर पर पेड़ के आकार का और वैकल्पिक है। गतिशील डेटाबेस प्रणालियाँ जो तदर्थ स्तंभों की अनुमति देती हैं, स्कीमा बाध्यता को शिथिल कर सकती हैं, लेकिन ऐसी प्रणालियाँ या तो वर्तमान में दुर्लभ हैं, या "संबंधपरक" के रूप में उनका वर्गीकरण प्रश्न में है।
+ओओ और रिलेशनल मॉडल के मध्य प्रमुख दार्शनिक अंतरों को निम्नानुसार संक्षेपित किया जा सकता है |
-* '''प्रवेश नियम{{snd}}''' रिलेशनल डेटाबेस में, विशेषताओं को पूर्वनिर्धारित रिलेशनल ऑपरेटरों के माध्यम से एक्सेस और परिवर्तित किया जाता है, जबकि OO प्रत्येक वर्ग को अपना स्वयं का राज्य परिवर्तन इंटरफ़ेस और अभ्यास बनाने की अनुमति देता है। OO का स्व-संचालन संज्ञा दृष्टिकोण प्रत्येक वस्तु को स्वतंत्रता देता है जिसे संबंधपरक मॉडल अनुमति नहीं देता है। यह मानक बनाम स्थानीय स्वतंत्रता की बहस है। ओओ का तर्क है कि संबंधपरक मानक अभिव्यक्ति को सीमित करते हैं, जबकि संबंधपरक समर्थकों का सुझाव है कि नियम का पालन अधिक अमूर्त गणित जैसे तर्क, अखंडता और डिजाइन स्थिरता की अनुमति देता है।
-* '''संज्ञा और क्रिया के बीच संबंध{{snd}}''' OO क्रियाओं (क्रियाओं) और संज्ञाओं (संस्थाओं) के बीच मजबूत संबंध को प्रोत्साहित करता है, जिस पर परिचालन संचालित होता है। संज्ञा और क्रिया दोनों से युक्त परिणामी कसकर बंधी इकाई को आमतौर पर वर्ग (कंप्यूटर विज्ञान) कहा जाता है, या ओओ विश्लेषण में, संकल्पनात्मक मॉडल (कंप्यूटर विज्ञान) कहा जाता है। संबंधपरक डिज़ाइन आम तौर पर यह नहीं मानते हैं कि ऐसे तंग संघों (संबंधपरक ऑपरेटरों के बाहर) के बारे में कुछ भी प्राकृतिक या तार्किक है।
-*वस्तु की पहचान{{snd}} वस्तुओं (अपरिवर्तनीय को छोड़कर) को आम तौर पर विशिष्ट पहचान माना जाता है; दो वस्तुएँ जो निश्चित समय पर ही स्थिति में होती हैं, उन्हें समान नहीं माना जाता है। दूसरी ओर, संबंधों में इस प्रकार की पहचान की कोई अंतर्निहित अवधारणा नहीं होती है। जैसा कि कहा गया है, विश्व स्तर पर अद्वितीय [[उम्मीदवार कुंजी]] के उपयोग के माध्यम से डेटाबेस में रिकॉर्ड के लिए "पहचान" बनाना आम बात है; हालाँकि कई लोग इसे किसी भी डेटाबेस रिकॉर्ड के लिए ख़राब अभ्यास मानते हैं जिसका वास्तविक विश्व इकाई के साथ -से-एक पत्राचार नहीं होता है। (संबंध, वस्तुओं की तरह, पहचान उद्देश्यों के लिए बाहरी दुनिया में मौजूद होने पर डोमेन कुंजियों का उपयोग कर सकते हैं)। व्यवहार में संबंधपरक प्रणालियाँ स्थायी और निरीक्षण योग्य पहचान तकनीकों के लिए प्रयास करती हैं और उनका समर्थन करती हैं, जबकि वस्तु पहचान तकनीकें क्षणिक या स्थितिजन्य होती हैं।
-* सामान्यीकरण{{snd}} [[डेटाबेस सामान्यीकरण]] प्रथाओं को अक्सर OO डिज़ाइन द्वारा अनदेखा कर दिया जाता है। हालाँकि, यह OO की मूल विशेषता के बजाय केवल बुरी आदत हो सकती है। वैकल्पिक दृष्टिकोण यह है कि ऑब्जेक्ट का संग्रह, किसी प्रकार के पॉइंटर (कंप्यूटर प्रोग्रामिंग) के माध्यम से जुड़ा हुआ, [[नेटवर्क डेटाबेस]] के समान है; जिसे बदले में अत्यंत असामान्य संबंधपरक डेटाबेस के रूप में देखा जा सकता है।
-* स्कीमा विरासत{{snd}} अधिकांश रिलेशनल डेटाबेस स्कीमा इनहेरिटेंस का समर्थन नहीं करते हैं। यद्यपि इस तरह की सुविधा को ओओपी के साथ संघर्ष को कम करने के लिए सिद्धांत में जोड़ा जा सकता है, संबंधपरक समर्थकों को पदानुक्रमित वर्गीकरण और उप-टाइपिंग की उपयोगिता पर विश्वास करने की कम संभावना है क्योंकि वे [[ समुच्चय सिद्धान्त |सेट सिद्धान्त]] -आधारित टैक्सोनॉमी या वर्गीकरण प्रणालियों को अधिक शक्तिशाली और लचीला रूप में देखते हैं | पेड़ों की तुलना में.ओओ समर्थकों का कहना है कि इनहेरिटेंस/सबटाइपिंग मॉडल को पेड़ों तक सीमित करने की आवश्यकता नहीं है (हालांकि [[जावा (भाषा)]] जैसी कई लोकप्रिय ओओ भाषाओं में यह सीमा है), लेकिन गैर-ट्री ओओ समाधानों को सेट कीआधारित में तैयार करना अधिक कठिन माना जाता है। विषय-वस्तु पर आधारित विविधता प्रबंधन तकनीकों को रिलेशनल द्वारा प्राथमिकता दी जाती है। कम से कम, वे आमतौर पर संबंधपरक बीजगणित में उपयोग की जाने वाली तकनीकों से भिन्न हैं।
-*संरचना बनाम व्यवहार - OO मुख्य रूप से यह सुनिश्चित करने पर ध्यान केंद्रित करता है कि कार्यक्रम की संरचना उचित (रखरखाव योग्य, समझने योग्य, विस्तार योग्य, पुन: प्रयोज्य, सुरक्षित) है, जबकि संबंधपरक प्रणालियाँ इस बात पर ध्यान केंद्रित करती हैं कि परिणामी रन-टाइम सिस्टम में किस प्रकार का व्यवहार है (दक्षता, अनुकूलनशीलता) , दोष-सहिष्णुता, जीवंतता, तार्किक अखंडता, आदि)। ऑब्जेक्ट-ओरिएंटेड विधियाँ आम तौर पर मानती हैं कि ऑब्जेक्ट-ओरिएंटेड कोड और उसके इंटरफेस के प्राथमिक उपयोगकर्ता एप्लिकेशन डेवलपर हैं। संबंधपरक प्रणालियों में, सिस्टम के व्यवहार के बारे में अंतिम-उपयोगकर्ताओं के दृष्टिकोण को कभी-कभी अधिक महत्वपूर्ण माना जाता है। हालाँकि, संबंधपरक प्रश्न और "विचार" एप्लिकेशन- या कार्य-विशिष्ट कॉन्फ़िगरेशन में जानकारी प्रस्तुत करने की सामान्य तकनीक हैं। इसके अलावा, रिलेशनल स्थानीय या एप्लिकेशन-विशिष्ट संरचनाओं या तालिकाओं को बनाने से प्रतिबंधित नहीं करता है, हालांकि कई सामान्य विकास उपकरण सीधे ऐसी सुविधा प्रदान नहीं करते हैं, यह मानते हुए कि वस्तुओं का उपयोग इसके बजाय किया जाएगा। इससे यह जानना मुश्किल हो जाता है कि रिलेशनल का बताया गया गैर-डेवलपर परिप्रेक्ष्य रिलेशनल में अंतर्निहित है, या केवल वर्तमान अभ्यास और उपकरण कार्यान्वयन मान्यताओं का उत्पाद है।
-* सेट बनाम ग्राफ़ संबंध{{snd}} विभिन्न वस्तुओं (वस्तुओं या रिकॉर्ड) के बीच संबंध को प्रतिमानों के बीच अलग-अलग तरीके से नियंत्रित किया जाता है। संबंधपरक संबंध आमतौर पर सेट सिद्धांत से लिए गए मुहावरों पर आधारित होते हैं, जबकि वस्तु संबंध [[ग्राफ सिद्धांत]] (ट्री (ग्राफ सिद्धांत) सहित) से अपनाए गए मुहावरों की ओर झुकते हैं। हालाँकि प्रत्येक व्यक्ति दूसरे के समान ही जानकारी का प्रतिनिधित्व कर सकता है, लेकिन जानकारी तक पहुँचने और उसे प्रबंधित करने के लिए उनके द्वारा प्रदान किए जाने वाले दृष्टिकोण भिन्न-भिन्न होते हैं।
+* '''घोषणात्मक बनाम अनिवार्य इंटरफेस{{snd}}''' रिलेशनल सोच डेटा को इंटरफ़ेस के रूप में उपयोग करती है, इसमें व्यवहार को इंटरफ़ेस के रूप में उपयोग नहीं किया जाता हैं। इस प्रकार इसमें ओओ के व्यवहारिक झुकाव के विपरीत डिजाइन दर्शन में घोषणात्मक झुकाव है। (अनेक रिलेशनल प्रस्तावक जटिल व्यवहार प्रदान करने के लिए ट्रिगर्स, संग्रहीत प्रक्रियाओं आदि का उपयोग करने का सुझाव देते हैं, किन्तु यह सामान्य दृष्टिकोण नहीं होता है।)
+*'''स्कीमा बाउंड''' '''-''' ऑब्जेक्ट को "पैरेंट स्कीमा" का पालन करने की आवश्यकता नहीं होती है | और जिसके लिए किसी ऑब्जेक्ट के गुण या एक्सेसर्स होते हैं, जबकि तालिका पंक्तियों को इकाई की स्कीमा का पालन करना होता हैं। इस प्रकार दी गई पंक्ति और केवल इकाई से संबंधित होनी चाहिए। जिसे ओओ में निकटतम ऑब्जेक्ट वंशानुक्रम होती है, किन्तु यह सामान्यतः ट्री के आकार का और वैकल्पिक होता है। जिसे गतिशील डेटाबेस प्रणालियाँ जो विशेष स्तंभों की अनुमति देती हैं, जिन्हें स्कीमा बाध्यता को शिथिल कर सकती हैं, किन्तु ऐसी प्रणालियाँ तब वर्तमान में दुर्लभ होती हैं, या "रिलेशनल" के रूप में उनका वर्गीकरण प्रश्न में होता है।
+* '''प्रवेश नियम{{snd}}''' संबंध डेटाबेस में, विशेषताओं को पूर्व निर्धारित संबंध ऑपरेटरों के माध्यम से एक्सेस और परिवर्तित किया जाता है, जबकि ओओ प्रत्येक वर्ग को अपना स्वयं का राज्य परिवर्तन इंटरफ़ेस और अभ्यास बनाने की अनुमति देता है। ओओ का स्व-संचालन संज्ञा दृष्टिकोण प्रत्येक ऑब्जेक्ट को स्वतंत्रता देता है जिसे रिलेशनल मॉडल अनुमति नहीं देता है। यह मानक बनाम स्थानीय स्वतंत्रता की चर्चा होती है। ओओ का तर्क है कि रिलेशनल मानक अभिव्यक्ति को सीमित करते हैं, जबकि यह रिलेशनल समर्थकों का सुझाव होता है कि नियम का पालन अधिक अमूर्त गणित जैसे तर्क, अखंडता और डिजाइन स्थिरता की अनुमति देता है।
+* '''संज्ञा और क्रिया के मध्य संबंध{{snd}}''' ओओ क्रियाओं (क्रियाओं) और संज्ञाओं (संस्थाओं) के मध्य शक्तिशाली संबंध को प्रोत्साहित करता है, जिस पर परिचालन संचालित होता है। संज्ञा और क्रिया दोनों से युक्त परिणामी कसकर बंधी इकाई को सामान्यतः वर्ग (कंप्यूटर विज्ञान) कहा जाता है, या इनको ओओ विश्लेषण में, संकल्पनात्मक मॉडल (कंप्यूटर विज्ञान) कहा जाता है। इस प्रकार रिलेशनल डिज़ाइन सामान्यतः यह नहीं मानते हैं कि ऐसे तंग संघों (रिलेशनल ऑपरेटरों के बाहर) के बारे में अनेक प्राकृतिक या तार्किक होते है।
+*'''ऑब्जेक्ट की पहचान{{snd}}''' ऑब्जेक्ट (अपरिवर्तनीय को छोड़कर) को सामान्यतः विशिष्ट पहचान माना जाता है; दो वस्तुएँ जो निश्चित समय पर ही स्थिति में होती हैं, उन्हें समान नहीं माना जाता है। दूसरी ओर, संबंधों में इस प्रकार की पहचान की कोई अंतर्निहित अवधारणा नहीं होती है। जैसा कि कहा गया है,कि विश्व स्तर पर अद्वितीय [[उम्मीदवार कुंजी|अपेक्षावार कुंजी]] के उपयोग के माध्यम से डेटाबेस में रिकॉर्ड के लिए "पहचान" बनाना सरल बात है; चूँकि अनेक लोग इसे किसी भी डेटाबेस रिकॉर्ड के लिए ख़राब अभ्यास मानते हैं जिसका वास्तविक विश्व इकाई के साथ पत्राचार नहीं होता है। औरइसके (संबंध, ऑब्जेक्ट की तरह, पहचान उद्देश्यों के लिए बाहरी संसार में उपस्थित होने पर स्थान कुंजियों का उपयोग कर सकते हैं)। व्यवहार में रिलेशनल प्रणालियाँ स्थायी और निरीक्षण योग्य पहचान विधियों के लिए प्रयास करती हैं और उनका समर्थन करती हैं, जबकि ऑब्जेक्ट पहचान विधियों में इसकी स्थिति क्षणिक या स्थितिजन्य होती हैं।
+* '''सामान्यीकरण{{snd}}''' [[डेटाबेस सामान्यीकरण]] प्रथाओं को अधिकांशतः ओओ डिज़ाइन द्वारा अनदेखा कर दिया जाता है। चूँकि, यह ओओ की मूल विशेषता के अतिरिक्त हानिकारक आदत हो सकती है। वैकल्पिक दृष्टिकोण यह है कि ऑब्जेक्ट का संग्रह, किसी प्रकार के पॉइंटर (कंप्यूटर प्रोग्रामिंग) के माध्यम से जुड़ा हुआ होता हैं | जो [[नेटवर्क डेटाबेस]] के समान होता है | जिसे बदले में अत्यंत असामान्य रिलेशनल डेटाबेस के रूप में देखा जा सकता है।
+* '''स्कीमा विरासत{{snd}}''' अधिकांश संबंध डेटाबेस स्कीमा विरासत का समर्थन नहीं करते हैं। यद्यपि इस तरह की सुविधा को ओओपी के साथ संघर्ष को आसान करने के लिए सिद्धांत में जोड़ा जा सकता है, और रिलेशनल समर्थकों को पदानुक्रमित वर्गीकरण और उप-टाइपिंग की उपयोगिता पर विश्वास करने की आसान संभावना होती है क्योंकि वे [[ समुच्चय सिद्धान्त |सेट सिद्धान्त]] -आधारित टैक्सोनॉमी या वर्गीकरण प्रणालियों को अधिक शक्तिशाली और परिवर्तित रूप में देखते हैं | ट्री की तुलना में.ओओ समर्थकों का कहना है कि विरासत /सबटाइपिंग मॉडल को ट्री तक सीमित करने की आवश्यकता नहीं है (चूंकि [[जावा (भाषा)]] जैसी अनेक लोकप्रिय ओओ भाषाओं में यह सीमा होती है), किन्तु गैर-ट्री ओओ समाधानों को सेट की आधारित में तैयार करना अधिक कठिन माना जाता है। विषय-ऑब्जेक्ट पर आधारित विविधता प्रबंधन विधियों को संबंध द्वारा प्राथमिकता दी जाती है। और वह सरल से सरल होते हैं | और वह सामान्यतः रिलेशनल बीजगणित में उपयोग की जाने वाली विधियों से भिन्न होते हैं।
+*'''संरचना बनाम व्यवहार -''' ओओ मुख्य रूप से यह सुनिश्चित करने पर ध्यान केंद्रित करता है कि कार्यक्रम की संरचना उचित (रख रखाव योग्य, समझने योग्य, विस्तार योग्य, पुन: प्रयोज्य, सुरक्षित) होती है, जबकि रिलेशनल प्रणालियाँ इस बात पर ध्यान केंद्रित करती हैं कि परिणामी रन-टाइम रिलेशनल में किस प्रकार का व्यवहार होता है जिसे (दक्षता, अनुकूलनशीलता) , दोष-सहिष्णुता, जीवंतता, तार्किक अखंडता, आदि होते हैं। ऑब्जेक्ट-उन्मुखी विधियाँ सामान्यतः मानती हैं कि ऑब्जेक्ट-उन्मुखी कोड और उसके इंटरफेस के प्राथमिक उपयोगकर्ता एप्लिकेशन डेवलपर हैं। रिलेशनल प्रणालियों में, रिलेशनल के व्यवहार के बारे में अंतिम-उपयोगकर्ताओं के दृष्टिकोण को कभी-कभी अधिक महत्वपूर्ण माना जाता है। चूँकि, रिलेशनल प्रश्न और "विचार" एप्लिकेशन- या कार्य-विशिष्ट विन्यास में जानकारी प्रस्तुत करने की सामान्य विधि हैं। इसके अतिरिक्त, संबंध स्थानीय या एप्लिकेशन-विशिष्ट संरचनाओं या तालिकाओं को बनाने से प्रतिबंधित नहीं करता है, चूंकि अनेक सामान्य विकास उपकरण सीधे ऐसी सुविधा प्रदान नहीं करते हैं, यह मानते हुए कि ऑब्जेक्ट का उपयोग इसके अतिरिक्त किया जाता हैं। इससे यह जाननाआसान हो जाता है कि संबंध का बताया गया गैर-डेवलपर परिप्रेक्ष्य संबंध में अंतर्निहित है, या केवल वर्तमान अभ्यास और उपकरण कार्यान्वयन मान्यताओं का उत्पाद होता है।
+* '''सेट बनाम ग्राफ़ संबंध{{snd}}''' विभिन्न ऑब्जेक्ट (ऑब्जेक्ट या रिकॉर्ड) के मध्य संबंध को प्रतिमानों के मध्य अलग-अलग विधि से नियंत्रित किया जाता है। रिलेशनल संबंध सामान्यतः सेट सिद्धांत से लिए गए मुहावरों पर आधारित होते हैं, जबकि ऑब्जेक्ट संबंध [[ग्राफ सिद्धांत]] (ट्री (ग्राफ सिद्धांत) सहित) से अपनाए गए मुहावरों की ओर झुकते हैं। चूँकि प्रत्येक व्यक्ति दूसरे के समान ही जानकारी का प्रतिनिधित्व कर सकता है, किन्तु जानकारी तक पहुँचने और उसे प्रबंधित करने के लिए उनके द्वारा प्रदान किए जाने वाले दृष्टिकोण भिन्न-भिन्न होते हैं।
-वस्तु-संबंधपरक प्रतिबाधा बेमेल के परिणामस्वरूप, बहस के दोनों पक्षों के पक्षकारों द्वारा अक्सर यह तर्क दिया जाता है कि अन्य तकनीक को छोड़ दिया जाना चाहिए या उसका दायरा कम कर दिया जाना चाहिए। <ref name="RDMDBobjectmis">{{cite web| first = Ted| last=Neward | title = कंप्यूटर विज्ञान का वियतनाम| date=2006-06-26|access-date=2010-06-02| publisher = Interoperability Happens| url=https://www.odbms.org/wp-content/uploads/2013/11/031.01-Neward-The-Vietnam-of-Computer-Science-June-2006.pdf}}</ref> कुछ डेटाबेस समर्थक पारंपरिक "प्रक्रियात्मक" भाषाओं को कई OO भाषाओं की तुलना में RDBMS के साथ अधिक संगत मानते हैं; या सुझाव दें कि कम OO शैली का उपयोग किया जाना चाहिए। (विशेष रूप से, यह तर्क दिया जाता है कि एप्लिकेशन कोड में लंबे समय तक रहने वाले डोमेन ऑब्जेक्ट मौजूद नहीं होने चाहिए; ऐसी कोई भी ऑब्जेक्ट जो मौजूद है, उसे तब बनाया जाना चाहिए जब कोई क्वेरी की जाती है और लेनदेन या कार्य पूरा होने पर उसका '''निपटान''' किया जाना चाहिए)। इसके विपरीत, कुछ OO समर्थकों का तर्क है कि [[OODBMS]] जैसे अधिक OO-अनुकूल दृढ़ता तंत्र को विकसित और उपयोग किया जाना चाहिए, और संबंधपरक तकनीक को चरणबद्ध तरीके से समाप्त किया जाना चाहिए। कई (यदि अधिकतर नहीं) प्रोग्रामर और डीबीए इनमें से कोई भी दृष्टिकोण नहीं रखते हैं; और वस्तु-संबंधपरक प्रतिबाधा बेमेल को जीवन के मात्र तथ्य के रूप में देखें जिससे सूचना प्रौद्योगिकी को निपटना है।
+ऑब्जेक्ट-रिलेशनल प्रतिबाधा असंगत के परिणामस्वरूप, चर्चा के दोनों पक्षों के पक्षकारों द्वारा अधिकांशतः यह तर्क दिया जाता है कि अन्य विधि को छोड़ दिया जाना चाहिए या उसकी सीमा को सरल कर दिया जाना चाहिए। <ref name="RDMDBobjectmis">{{cite web| first = Ted| last=Neward | title = कंप्यूटर विज्ञान का वियतनाम| date=2006-06-26|access-date=2010-06-02| publisher = Interoperability Happens| url=https://www.odbms.org/wp-content/uploads/2013/11/031.01-Neward-The-Vietnam-of-Computer-Science-June-2006.pdf}}</ref> इस प्रकार अनेक डेटाबेस समर्थक पारंपरिक "प्रक्रियात्मक" भाषाओं को अनेक ओओ भाषाओं की तुलना में आरडीबीएमएस के साथ अधिक संगत मानते हैं | और यह सुझाव दें कि आसान ओओ शैली का उपयोग किया जाना चाहिए। (विशेष रूप से, यह तर्क दिया जाता है कि एप्लिकेशन कोड में लंबे समय तक रहने वाले स्थान ऑब्जेक्ट उपस्थित नहीं होने चाहिए | ऐसी कोई भी ऑब्जेक्ट जो उपस्थित होती है, उसे तब बनाया जाना चाहिए जब कोई क्वेरी की जाती है|इस प्रकार लेन देन या कार्य पूरा होने पर उसका विक्रय किया जाना चाहिए)। इसके विपरीत, अनेक ओओ समर्थकों का तर्क है कि [[OODBMS|ओओ डीबीएमएस]] जैसे अधिक ओओ -अनुकूल दृढ़ता तंत्र को विकसित और उपयोग किया जाना चाहिए | और रिलेशनल विधि को चरणबद्ध विधि से समाप्त किया जाना चाहिए। और ( अनेक ) प्रोग्रामर और डीबीए इनमें से कोई भी दृष्टिकोण नहीं रखते हैं| और ऑब्जेक्ट-रिलेशनल प्रतिबाधा असंगत को जीवन के मात्र तथ्य के रूप में देखें जिससे सूचना प्रौद्योगिकी को सही करना होता है।
-यह भी तर्क दिया जाता है कि ओ/आर मैपिंग से कुछ स्थितियों में फायदा हो रहा है, लेकिन संभवत: इसकी अधिक बिक्री हो रही है: इसमें कमियों के अलावा फायदे भी हैं। संशयवादियों का कहना है कि इसका उपयोग करने से पहले सावधानी से सोचना उचित है, क्योंकि कुछ मामलों में इसका मूल्य थोड़ा बढ़ जाएगा।<ref>{{cite book|title=J2EE Design and Development|url=https://archive.org/details/expertoneononej200rodj|url-access=registration|first=Rod|last=Johnson|publisher=Wrox Press|date=2002|page=[https://archive.org/details/expertoneononej200rodj/page/256 256]|isbn=9781861007841 }}</ref>
+यह भी तर्क दिया जाता है कि ओ/आर मानचित्रण से अनेक स्थितियों में लाभ हो रहा है, और संभवत: इसकी अधिविक्रीत हो रही है इसमें सरल के अतिरिक्त लाभ भी हैं। संशयवादियों का कहना है कि इसका उपयोग करने से पहले सावधानी से सोचना उचित है, क्योंकि अनेक स्थितियों में इसका मूल्य थोड़ा बढ़ जाता हैं।<ref>{{cite book|title=J2EE Design and Development|url=https://archive.org/details/expertoneononej200rodj|url-access=registration|first=Rod|last=Johnson|publisher=Wrox Press|date=2002|page=[https://archive.org/details/expertoneononej200rodj/page/256 256]|isbn=9781861007841 }}</ref>
 == यह भी देखें ==
 * {{annotated link|ऑब्जेक्ट-रिलेशनल मैपिंग     }}
@@ Line 116: / Line 116: @@
 * [https://www.odbms.org/wp-content/uploads/2013/11/031.01-Neward-The-Vietnam-of-Computer-Science-June-2006.pdf The Vietnam of Computer Science] – Examples of mismatch problems
-{{DEFAULTSORT:Object-relational impedance mismatch}}[[Category: ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग]] [[Category: ऑब्जेक्ट-रिलेशनल मैपिंग]] [[Category: संबंधपरक मॉडल]]
+{{DEFAULTSORT:Object-relational impedance mismatch}}
-[[Category: Machine Translated Page]]
+[[Category:Created On 10/07/2023|Object-relational impedance mismatch]]
-[[Category:Created On 10/07/2023]]
+[[Category:Lua-based templates|Object-relational impedance mismatch]]
+[[Category:Machine Translated Page|Object-relational impedance mismatch]]
+[[Category:Pages with script errors|Object-relational impedance mismatch]]
+[[Category:Short description with empty Wikidata description|Object-relational impedance mismatch]]
+[[Category:Templates Vigyan Ready|Object-relational impedance mismatch]]
+[[Category:Templates that add a tracking category|Object-relational impedance mismatch]]
+[[Category:Templates that generate short descriptions|Object-relational impedance mismatch]]
+[[Category:Templates using TemplateData|Object-relational impedance mismatch]]
+[[Category:ऑब्जेक्ट-रिलेशनल मैपिंग|Object-relational impedance mismatch]]
+[[Category:ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग|Object-relational impedance mismatch]]
+[[Category:संबंधपरक मॉडल|Object-relational impedance mismatch]]

Anonymous

Search

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

Namespaces

More

Page actions

Latest revision as of 10:15, 4 August 2023

Contents

असंगत

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

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

अभिगम्यता

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

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

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

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

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

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

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

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

न्यूनीकरण

प्रतिपूर्ति

उपस्थिति

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

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

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

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

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

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

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

यह भी देखें

संदर्भ

बाहरी संबंध

Navigation

Navigation

Wiki tools

Wiki tools

Anonymous

Search

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

Latest revision as of 10:15, 4 August 2023

असंगत

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

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

अभिगम्यता

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

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

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

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

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

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

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

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

न्यूनीकरण

प्रतिपूर्ति

उपस्थिति

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

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

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

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

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

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

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

यह भी देखें

संदर्भ

बाहरी संबंध

Navigation

Wiki tools

Page tools

Other projects

Categories