ओपन डेटाबेस कनेक्टिविटी

From Vigyanwiki
Revision as of 22:23, 3 March 2023 by alpha>Rahul Katiyar

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

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

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

इतिहास

ओडीबीसी से पहले

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

चूंकि SQL भाषा में केवल अल्पविकसित प्रोग्रामिंग विशेषताएं थीं, इसलिए उपयोगकर्ता अक्सर किसी अन्य भाषा में लिखे गए प्रोग्राम के भीतर SQL का उपयोग करना चाहते थे, जैसे कि फोरट्रान या C (प्रोग्रामिंग भाषा)। इसने एंबेडेड SQL की अवधारणा को जन्म दिया, जिसने PostQUEL कोड को दूसरी भाषा में एम्बेड करने की अनुमति दी। उदाहरण के लिए, एक SQL कथन जैसे SELECT * FROM city सी स्रोत कोड के भीतर पाठ के रूप में डाला जा सकता है, और संकलक के दौरान इसे एक कस्टम प्रारूप में परिवर्तित किया जाएगा जिसे सीधे पुस्तकालय (कम्प्यूटिंग) के भीतर एक फ़ंक्शन कहा जाता है जो कथन को SQL सिस्टम में पास करेगा। बयानों से लौटाए गए परिणामों को सी डेटा प्रारूपों में वापस व्याख्या की जाएगी char * समान लाइब्रेरी कोड का उपयोग करना।

एंबेडेड एसक्यूएल दृष्टिकोण के साथ कई समस्याएं थीं। SQL की विभिन्न किस्मों की तरह, एंबेडेड SQL जो उन्हें व्यापक रूप से उपयोग करते थे, न केवल प्लेटफ़ॉर्म से प्लेटफ़ॉर्म तक, बल्कि एक प्लेटफ़ॉर्म पर भाषाओं में भी - एक सिस्टम जो IBM Db2 में कॉल की अनुमति देता है, वह अपने आप में कॉल करने वाले से बहुत अलग दिखाई देगा। आईबीएम एसक्यूएल / डीएस | एसक्यूएल / डीएस।[dubious – discuss] एंबेडेड एसक्यूएल अवधारणा के लिए एक अन्य महत्वपूर्ण समस्या यह थी कि एसक्यूएल कोड को केवल प्रोग्राम के स्रोत कोड में ही बदला जा सकता है, ताकि क्वेरी में छोटे बदलावों को संशोधित करने के लिए काफी प्रोग्रामर प्रयास की आवश्यकता हो। एसक्यूएल बाजार ने इसे स्थिर एसक्यूएल बनाम डायनेमिक एसक्यूएल के रूप में संदर्भित किया है जिसे किसी भी समय बदला जा सकता है, जैसे [[कमांड लाइन इंटरफेस]] जो लगभग सभी एसक्यूएल सिस्टम के साथ भेज दिया गया है, या एक प्रोग्रामिंग इंटरफ़ेस जो एसक्यूएल को सादे पाठ के रूप में छोड़ देता है जब तक कि इसे कॉल नहीं किया जाता। . 1980 के दशक के दौरान डायनेमिक SQL सिस्टम SQL विक्रेताओं के लिए एक प्रमुख फोकस बन गया।

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

प्रारंभिक प्रयास

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

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

ऐसी प्रणाली के शुरुआती उदाहरणों में से एक कमल का विकास का लोटस डेटालेंस था, जिसे शुरू में ब्लूप्रिंट के रूप में जाना जाता था। ब्लूप्रिंट, 1-2-3 के लिए विकसित किया गया, जिसमें SQL/DS, DB2, FOCUS और इसी तरह के मेनफ्रेम सिस्टम के साथ-साथ dBase जैसे माइक्रो कंप्यूटर सिस्टम और प्रारंभिक Microsoft/Ashton-Tate प्रयासों सहित विभिन्न डेटा स्रोतों का समर्थन किया गया। अंततः Microsoft SQL सर्वर में विकसित होगा।[1] बाद के ODBC के विपरीत, Blueprint पूरी तरह से कोड-आधारित प्रणाली थी, जिसमें SQL जैसी कमांड भाषा का अनुमान लगाने वाली किसी भी चीज़ का अभाव था। इसके बजाय, प्रोग्रामर ने क्वेरी जानकारी को संग्रहीत करने के लिए डेटा संरचनाओं का उपयोग किया, इनमें से कई संरचनाओं को एक साथ जोड़कर एक क्वेरी का निर्माण किया। लोटस इन यौगिक संरचनाओं को क्वेरी ट्री के रूप में संदर्भित करता है।[2] लगभग उसी समय, साइबेस (टॉम हैगिन), टंडेम कंप्यूटर (जिम ग्रे (कंप्यूटर वैज्ञानिक) और राव येंदलुरी) और माइक्रोसॉफ्ट (काइल गीगर) के सदस्यों सहित एक उद्योग टीम एक मानकीकृत गतिशील एसक्यूएल अवधारणा पर काम कर रही थी। अधिकांश सिस्टम साइबेस के डीबी-लाइब्रेरी सिस्टम पर आधारित था, जिसमें साइबेस-विशिष्ट अनुभाग हटा दिए गए थे और अन्य प्लेटफॉर्म का समर्थन करने के लिए कई अतिरिक्त थे।[3] डीबी-लाइब्रेरी को लाइब्रेरी सिस्टम से एक उद्योग-व्यापी कदम से सहायता मिली थी जो ऑपरेटिंग सिस्टम द्वारा प्रदान की गई लाइब्रेरी सिस्टम के लिए एक विशिष्ट भाषा से कसकर जुड़ी हुई थी और उस प्लेटफॉर्म पर भाषाओं को इसके मानकों के अनुरूप बनाने की आवश्यकता थी। इसका मतलब यह था कि किसी दिए गए प्लेटफॉर्म पर किसी भी प्रोग्रामिंग भाषा के साथ (संभावित रूप से) एक पुस्तकालय का उपयोग किया जा सकता है।

Microsoft डेटा एक्सेस एपीआई का पहला मसौदा अप्रैल 1989 में प्रकाशित हुआ था, लगभग उसी समय जब लोटस ने ब्लूप्रिंट की घोषणा की थी।[4] ब्लूप्रिंट के महान नेतृत्व के बावजूद - यह तब चल रहा था जब MSDA अभी भी एक पेपर प्रोजेक्ट था - लोटस अंततः MSDA के प्रयासों में शामिल हो गया क्योंकि यह स्पष्ट हो गया कि SQL वास्तविक डेटाबेस मानक बन जाएगा।[2] काफी उद्योग इनपुट के बाद, 1989 की गर्मियों में मानक SQL कनेक्टिविटी (SQLC) बन गया।[5]


एसएजी और सीएलआई

1988 में कई विक्रेताओं, ज्यादातर यूनिक्स और डेटाबेस समुदायों से, SQL भाषा के लिए एकल बुनियादी मानक तैयार करने के प्रयास में SQL एक्सेस ग्रुप (SAG) का गठन किया। पहली बैठक में इस बात पर काफी बहस हुई कि प्रयास पूरी तरह से SQL भाषा पर ही काम करना चाहिए या नहीं, या एक व्यापक मानकीकरण का प्रयास करना चाहिए जिसमें एक गतिशील SQL भाषा-एम्बेडिंग सिस्टम भी शामिल है, जिसे वे कॉल लेवल इंटरफ़ेस (CLI) कहते हैं। .[6] उस समय के एमएस डेटा एक्सेस के शुरुआती मसौदे के साथ बैठक में भाग लेने के दौरान, माइक्रोसॉफ्ट के काइल गीजर ने डिजिटल उपकरण निगम (डीईसी) के जेफ बालबोनी और लैरी बार्न्स को भी एसक्यूएलसी बैठकों में शामिल होने के लिए आमंत्रित किया। SQLC CLI के लिए कॉल का एक संभावित समाधान था, जिसका नेतृत्व DEC कर रहा था।

चार का नया SQLC गिरोह, MS, Tandem, DEC और Sybase, SQLC का एक अद्यतन संस्करण जून 1990 में अगली SAG बैठक में लाया।[7] एसएजी ने किसी भी प्रतिस्पर्धी डिजाइन के लिए मानक प्रयास खोलकर जवाब दिया, लेकिन कई प्रस्तावों में केवल ओरेकल कार्पोरेशन के पास एक ऐसी प्रणाली थी जिसने गंभीर प्रतिस्पर्धा पेश की। अंत में, SQLC वोट जीत गया और मसौदा मानक बन गया, लेकिन एपीआई के बड़े हिस्से को हटा दिए जाने के बाद ही - मानक दस्तावेज़ इस समय के दौरान 120 पृष्ठों से 50 तक छंटनी की गई थी। इसी अवधि के दौरान कॉल लेवल इंटरफेस नाम औपचारिक रूप से अपनाया गया था।[7] 1995 में SQL/CLI अंतर्राष्ट्रीय SQL मानक, ISO/IEC 9075-3 का हिस्सा बन गया। -लेवल इंटरफेस (एसक्यूएल/सीएलआई)</ref> एसएजी को 1996 में एक्स/ओपन ग्रुप द्वारा अधिग्रहित कर लिया गया था, और समय के साथद ओपन ग्रुप के सामान्य अनुप्रयोग वातावरण का हिस्सा बन गया।

एमएस ने मूल एसक्यूएलसी मानक के साथ काम करना जारी रखा, सीएलआई संस्करण से हटाए गए कई उन्नत सुविधाओं को बरकरार रखा। इनमें कर्सर (डेटाबेस)#स्क्रॉल करने योग्य कर्सर, और मेटा डेटा सूचना क्वेरी जैसी विशेषताएं शामिल थीं। एपीआई में आदेश समूहों में विभाजित थे; कोर ग्रुप सीएलआई के समान था, लेवल 1 एक्सटेंशन कमांड थे जो ड्राइवरों में लागू करना आसान होगा, जबकि लेवल 2 कमांड में कर्सर जैसी अधिक उन्नत सुविधाएं थीं। एक प्रस्तावित मानक दिसंबर 1991 में जारी किया गया था, और उद्योग इनपुट इकट्ठा किया गया था और 1992 के माध्यम से सिस्टम में काम किया गया था, जिसके परिणामस्वरूप ODBC में एक और नाम बदल गया।[8]


जेट और ओडीबीसी

इस समय के दौरान, माइक्रोसॉफ्ट अपने जेट डेटाबेस इंजन के विकास के बीच में था। जेट संयुक्त तीन प्राथमिक उपप्रणालियाँ; एक आईएसएएम-आधारित डेटाबेस इंजन (जिसे जेट भी कहा जाता है), एक सी-आधारित इंटरफ़ेस जो अनुप्रयोगों को उस डेटा तक पहुंचने की इजाजत देता है, और ड्राइवर डायनेमिक-लिंक लाइब्रेरीज़ का चयन। डायनेमिक-लिंक लाइब्रेरीज़ (डीएलएल) जो समान सी इंटरफ़ेस को अनुमति देता है अन्य ISAM-आधारित डेटाबेस, जैसे Paradox (डेटाबेस) और xBase में इनपुट और आउटपुट को पुनर्निर्देशित करें। जेट ने ब्लूप्रिंट के समान फैशन में सामान्य माइक्रो कंप्यूटर डेटाबेस तक पहुंचने के लिए कॉल के एक सेट का उपयोग करने की अनुमति दी थी, तब इसका नाम बदलकर DataLens कर दिया गया था। हालाँकि, जेट ने SQL का उपयोग नहीं किया; DataLens की तरह, इंटरफ़ेस C में था और मैं हूँें डेटा संरचनाएँ और फ़ंक्शन कॉल शामिल थे।

SAG मानकीकरण के प्रयासों ने Microsoft को अपने जेट सिस्टम को नए CLI मानक के अनुकूल बनाने का अवसर प्रदान किया। यह न केवल विंडोज को सीएलआई विकास के लिए एक प्रमुख मंच बना देगा, बल्कि उपयोगकर्ताओं को जेट और अन्य डेटाबेस दोनों को एक्सेस करने के लिए एसक्यूएल का उपयोग करने की भी अनुमति देगा। जो गायब था वह एसक्यूएल पार्सर था जो उन कॉल्स को उनके टेक्स्ट फॉर्म से जेट में इस्तेमाल होने वाले सी-इंटरफेस में बदल सकता था। इसे हल करने के लिए, MS ने अपने मौजूदा क्वेरी प्रोसेसर, SIMBA का उपयोग करने के लिए PageAhead सॉफ़्टवेयर के साथ भागीदारी की। SIMBA को जेट की C लाइब्रेरी के ऊपर एक पार्सर के रूप में इस्तेमाल किया गया था, जिसने जेट को एक SQL डेटाबेस में बदल दिया। और क्योंकि जेट उन सी-आधारित कॉलों को अन्य डेटाबेसों में अग्रेषित कर सकता है, इसने SIMBA को अन्य प्रणालियों को क्वेरी करने की भी अनुमति दी। Microsoft ने अपने स्प्रेडशीट दस्तावेज़ों को SQL-सुलभ डेटाबेस तालिकाओं में बदलने के लिए एक्सेल के लिए ड्राइवरों को शामिल किया।[9]


रिलीज और निरंतर विकास

ओडीबीसी 1.0 सितंबर 1992 में जारी किया गया था।[10] उस समय, SQL डेटाबेस (बनाम ISAM) के लिए थोड़ा प्रत्यक्ष समर्थन था, और शुरुआती ड्राइवरों को खराब प्रदर्शन के लिए नोट किया गया था। जेट-आधारित स्टैक के माध्यम से कॉल्स को ले जाने वाले पथ के कारण इसमें से कुछ अपरिहार्य था; SQL डेटाबेस के लिए ODBC कॉल को पहले सिम्बा टेक्नोलॉजीज की SQL बोली से जेट के आंतरिक C-आधारित प्रारूप में परिवर्तित किया गया था, फिर डेटाबेस के लिए SQL कॉल में रूपांतरण के लिए एक ड्राइवर को पास किया गया। डिजिटल उपकरण और ओरेकल कॉर्पोरेशन दोनों ने सिम्बा टेक्नोलॉजीज को अपने डेटाबेस के लिए ड्राइवर विकसित करने के लिए अनुबंधित किया।[11] लगभग 1993, OpenLink सॉफ़्टवेयर ने प्रोग्रेस DBMS के लिए पहले स्वतंत्र रूप से विकसित तृतीय-पक्ष ODBC ड्राइवरों में से एक को शिप किया,[12] और जल्द ही उनके UDBC (ODBC और SAG/CLI के समतुल्य एक क्रॉस-प्लेटफ़ॉर्म API) SDK और यूनिक्स-जैसे OS (AIX, HP-UX) पर उपयोग के लिए प्रगति सॉफ्टवेयर, साइबेस, ओरेकल और अन्य DBMS के लिए संबंधित ड्राइवर , Solaris (ऑपरेटिंग सिस्टम), Linux, आदि), OpenVMS, Windows NT, OS/2, और अन्य OS।[13] इस बीच, सीएलआई मानक प्रयास जारी रहा, और यह मार्च 1995 तक नहीं था कि निश्चित संस्करण को अंतिम रूप दिया गया था। तब तक, माइक्रोसॉफ्ट ने विजीजेनिक सॉफ्टवेयर को गैर-विंडोज प्लेटफॉर्म पर ओडीबीसी विकसित करने के लिए एक स्रोत कोड लाइसेंस प्रदान कर दिया था। Visigenic ने ODBC को क्लासिक Mac OS और यूनिक्स प्लेटफार्मों की एक विस्तृत विविधता में पोर्ट किया, जहाँ ODBC जल्दी से वास्तविक मानक बन गया।[14] वास्तविक सीएलआई आज दुर्लभ है। दो प्रणालियाँ समान रहती हैं, और कई अनुप्रयोगों को ODBC से CLI में कुछ या बिना किसी बदलाव के पोर्ट किया जा सकता है।[15] समय के साथ, डेटाबेस विक्रेताओं ने ड्राइवर इंटरफेस को अपने कब्जे में ले लिया और अपने उत्पादों के लिए सीधे लिंक प्रदान किए। जेट या इसी तरह के रैपर से मध्यवर्ती रूपांतरणों को छोड़ देने से अक्सर उच्च प्रदर्शन होता है। हालाँकि, तब तक Microsoft ने अपने OLE DB पर फ़ोकस बदल दिया था[16] अवधारणा (हाल ही में बहाल [17]), जो एड्रेस बुक्स से लेकर टेक्स्ट फाइलों तक व्यापक किस्म के डेटा स्रोतों तक सीधी पहुंच प्रदान करता है। इसके बाद कई नई प्रणालियाँ आईं, जिन्होंने ODBC से अपना ध्यान हटा लिया, जिसमें ActiveX डेटा ऑब्जेक्ट्स (ADO) और ADO.net शामिल थे, जिन्होंने अपने जीवनकाल में ODBC के साथ कमोबेश बातचीत की।

जैसे ही माइक्रोसॉफ्ट ने अपना ध्यान ओडीबीसी पर सीधे काम करने से हटा दिया, यूनिक्स क्षेत्र तेजी से इसे गले लगा रहा था। यह बाजार के भीतर दो बदलावों से प्रेरित था, GNOME जैसे ग्राफिकल यूजर इंटरफेस (GUIs) की शुरुआत, जिसने इन स्रोतों को गैर-पाठ रूप में एक्सेस करने की आवश्यकता प्रदान की, और शुरुआत में PostgreSQL और MySQL जैसे खुला सॉफ्टवेयर डेटाबेस सिस्टम के उद्भव के तहत यूनिक्स। मानक यूनिक्स-साइड iODBC पैकेज Mac OS X 10.2 (जगुआर) का उपयोग करने के लिए बाद में Apple द्वारा ODBC को अपनाया गया[18] (जो OpenLink सॉफ़्टवेयर 2001 से Mac OS X 10.0 और यहां तक ​​कि Mac OS 9 के लिए स्वतंत्र रूप से प्रदान कर रहा था[19]) क्रॉस-प्लेटफ़ॉर्म डेटा एक्सेस के लिए मानक के रूप में ODBC को और पुख्ता किया।

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

ओडीबीसी आज

अधिकांश प्लेटफार्मों और अधिकांश डेटाबेस के लिए ड्राइवर उपलब्ध होने के साथ ODBC आज भी व्यापक उपयोग में है। डेटाबेस इंजनों के लिए ODBC ड्राइवरों को खोजना असामान्य नहीं है, जो SQLite की तरह एम्बेडेड होने के लिए हैं, मौजूदा उपकरणों को परीक्षण और डिबगिंग के लिए इन इंजनों के फ्रंट-एंड के रूप में कार्य करने की अनुमति देने के तरीके के रूप में।[20] हालाँकि, एक मध्यवर्ती प्रारूप के रूप में HTML का उपयोग करते हुए दूसरे कंप्यूटर पर निर्भर रहने वाला कंप्यूटर प्रोग्राम कंप्यूटिंग के उदय ने ODBC की आवश्यकता को कम कर दिया है[dubious – discuss][citation needed]. कई वेब विकास प्लेटफार्मों में लक्ष्य डेटाबेस के लिए सीधे लिंक होते हैं - MySQL बहुत सामान्य है। इन परिदृश्यों में, समर्थन करने के लिए कोई प्रत्यक्ष क्लाइंट-साइड एक्सेस नहीं है और न ही कई क्लाइंट सॉफ़्टवेयर सिस्टम हैं; सब कुछ प्रोग्रामर द्वारा प्रदत्त HTML एप्लिकेशन के माध्यम से जाता है। ODBC द्वारा प्रदान किया जाने वाला वर्चुअलाइजेशन अब एक मजबूत आवश्यकता नहीं है, और ODBC का विकास अब उतना सक्रिय नहीं है जितना पहले हुआ करता था।[citation needed] लेकिन जबकि ODBC अब क्लाइंट-सर्वर प्रोग्रामिंग के लिए एक मजबूत आवश्यकता नहीं है, यह अब एनालिटिक्स और डेटा साइंस परिदृश्यों में एक्सेस, वर्चुअलाइजेशन और एकीकरण के लिए अधिक महत्वपूर्ण है। ये नई आवश्यकताएं नई ODBC 4.0 सुविधाओं जैसे अर्ध-संरचित और पदानुक्रमित डेटा, वेब प्रमाणीकरण और प्रदर्शन सुधार में परिलक्षित होती हैं।

संस्करण इतिहास

ODBC विनिर्देशों[21]

  • 1.0: सितंबर 1992 में रिलीज़ हुई[22]
  • 2.0: c. 1994
  • 2.5
  • 3.0: c. 1995, इंटरसॉल्व के जॉन गुडसन और IBM के फ्रैंक पेलो और पॉल कॉटन ने ODBC 3.0 को महत्वपूर्ण इनपुट प्रदान किया[23]
  • 3.5: c. 1997
  • 3.8: c. 2009, विंडोज 7 के साथ[24]
  • 4.0: जून 2016 में घोषित विकास[25] SQL सर्वर 2017 के साथ पहले कार्यान्वयन के साथ सितंबर 2017 को जारी किया गया और 2018 के अंत में अतिरिक्त डेस्कटॉप ड्राइवर Github पर अंतिम कल्पना

डेस्कटॉप डेटाबेस ड्राइवर्स[26]

  • 1.0 (1993-08): पेजअहेड सॉफ्टवेयर द्वारा निर्मित SIMBA क्वेरी प्रोसेसर का उपयोग किया गया।
  • 2.0 (1994-12): ओडीबीसी 2.0 के साथ प्रयोग किया जाता है।
  • 3.0 (1995-10): विंडोज 95 और विंडोज एनटी वर्कस्टेशन या एनटी सर्वर 3.51 को सपोर्ट करता है। इस रिलीज़ में केवल 32-बिट ड्राइवर शामिल किए गए थे।
  • 3.5 (1996-10): डबल-बाइट कैरेक्टर सेट (डीबीसीएस) का समर्थन करता है, और फ़ाइल डेटा स्रोत नाम (डीएसएन) के उपयोग को समायोजित करता है। Microsoft Access ड्राइवर को RISC संस्करण में Windows 95/98 और Windows NT 3.51 और बाद के ऑपरेटिंग सिस्टम के लिए अल्फा प्लेटफॉर्म पर उपयोग के लिए जारी किया गया था।
  • 4.0 (1998 के अंत में): पिछले संस्करणों के एएनएसआई प्रारूप के लिए अनुकूलता के साथ माइक्रोसॉफ्ट जेट इंजन यूनिकोड प्रारूप का समर्थन करें।

ड्राइवर और प्रबंधक

ड्राइवर

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

ODBC के मामले में, ड्राइवर कई कार्यों को समाहित करते हैं जिन्हें कई व्यापक श्रेणियों में विभाजित किया जा सकता है। फ़ंक्शंस का एक सेट मुख्य रूप से उस DBMS को खोजने, कनेक्ट करने और डिस्कनेक्ट करने से संबंधित है जिससे ड्राइवर बात करता है। एक दूसरे सेट का उपयोग ODBC सिस्टम से SQL कमांड को DBMS में भेजने के लिए किया जाता है, आंतरिक रूप से समर्थित किसी भी कमांड को परिवर्तित या व्याख्या करने के लिए। उदाहरण के लिए, एक DBMS जो कर्सर (डेटाबेस) का समर्थन नहीं करता है, ड्राइवर में इस कार्यक्षमता का अनुकरण कर सकता है। अंत में, आदेशों का एक और सेट, जो ज्यादातर आंतरिक रूप से उपयोग किया जाता है, का उपयोग DBMS के आंतरिक स्वरूपों से डेटा को मानकीकृत ODBC प्रारूपों के सेट में परिवर्तित करने के लिए किया जाता है, जो C भाषा स्वरूपों पर आधारित होते हैं।

एक ODBC ड्राइवर एक ODBC-अनुपालन एप्लिकेशन को डेटा स्रोत, सामान्य रूप से DBMS का उपयोग करने में सक्षम बनाता है। कुछ गैर-डीबीएमएस ड्राइवर मौजूद होते हैं, ऐसे डेटा स्रोतों के लिए जैसे कॉमा-सेपरेटेड वैल्यू फाइल्स, ड्राइवर के अंदर एक छोटा डीबीएमएस लागू करके। अधिकांश DBMSs के लिए ODBC ड्राइवर मौजूद हैं, जिनमें Oracle डेटाबेस, PostgreSQL, MySQL, Microsoft SQL सर्वर (लेकिन एसक्यूएल सर्वर कॉम्पैक्ट के लिए नहीं), अनुकूली सर्वर एंटरप्राइज़, SAP HANA शामिल हैं।[27][28] और आईबीएम Db2. क्योंकि विभिन्न तकनीकों की अलग-अलग क्षमताएँ होती हैं, अधिकांश ODBC ड्राइवर ODBC मानक में परिभाषित सभी कार्यक्षमताओं को लागू नहीं करते हैं। कुछ ड्राइवर मानक द्वारा परिभाषित नहीं की गई अतिरिक्त कार्यक्षमता प्रदान करते हैं।

चालक प्रबंधक

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

ODBC में ड्राइवर मैनेजर (DM) ये सुविधाएँ प्रदान करता है।[29] डीएम स्थापित ड्राइवरों की गणना कर सकता है और इसे एक सूची के रूप में प्रस्तुत कर सकता है, अक्सर जीयूआई-आधारित रूप में।

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

डीएम में आंशिक रूप से पूर्ण डीएसएन को बचाने की क्षमता भी शामिल है, कोड और तर्क के साथ उपयोगकर्ता को रनटाइम पर किसी भी लापता जानकारी के लिए पूछने के लिए। उदाहरण के लिए, एक आवश्यक पासवर्ड के बिना एक DSN बनाया जा सकता है। जब कोई ODBC एप्लिकेशन इस DSN का उपयोग करके DBMS से कनेक्ट करने का प्रयास करता है, तो सिस्टम रुक जाएगा और उपयोगकर्ता को जारी रखने से पहले पासवर्ड प्रदान करने के लिए कहेगा। यह एप्लिकेशन डेवलपर को इस प्रकार का कोड बनाने से मुक्त करता है, साथ ही यह जानने के लिए कि कौन से प्रश्न पूछने हैं। यह सब ड्राइवर और DSNs में शामिल है।

ब्रिजिंग कॉन्फ़िगरेशन

एक ब्रिज एक विशेष प्रकार का ड्राइवर है: एक ड्राइवर जो दूसरी ड्राइवर-आधारित तकनीक का उपयोग करता है।

ओडीबीसी-टू-जेडीबीसी (ओडीबीसी-जेडीबीसी) पुल

एक ODBC-JDBC ब्रिज में एक ODBC ड्राइवर होता है जो डेटाबेस से जुड़ने के लिए JDBC टाइप 1 ड्राइवर की सेवाओं का उपयोग करता है। यह ड्राइवर ODBC फ़ंक्शन-कॉल को JDBC मेथड-कॉल में ट्रांसलेट करता है। प्रोग्रामर आमतौर पर ऐसे ब्रिज का उपयोग करते हैं जब उनके पास कुछ डेटाबेस के लिए ODBC ड्राइवर की कमी होती है लेकिन JDBC ड्राइवर तक उनकी पहुंच होती है। उदाहरण: OpenLink ODBC-JDBC ब्रिज, SequeLink ODBC-JDBC ब्रिज।

जेडीबीसी-टू-ओडीबीसी (जेडीबीसी-ओडीबीसी) पुल

JDBC-ODBC ब्रिज में एक JDBC ड्राइवर होता है जो लक्ष्य डेटाबेस से जुड़ने के लिए ODBC ड्राइवर नियुक्त करता है। यह ड्राइवर JDBC विधि (कंप्यूटर विज्ञान) कॉल्स को ODBC फंक्शन कॉल्स में ट्रांसलेट करता है। प्रोग्रामर आमतौर पर ऐसे पुल का उपयोग करते हैं जब किसी दिए गए डेटाबेस में JDBC ड्राइवर की कमी होती है, लेकिन ODBC ड्राइवर के माध्यम से पहुँचा जा सकता है। सन माइक्रोसिस्टम्स ने JVM में एक ऐसा ब्रिज शामिल किया, लेकिन इसे स्टॉप-गैप माप के रूप में देखा, जबकि कुछ JDBC ड्राइवर मौजूद थे (बिल्ट-इन JDBC-ODBC ब्रिज को Java 8 में JVM से हटा दिया गया था)[30]). सूर्य ने उत्पादन वातावरण के लिए अपने पुल का इरादा कभी नहीं किया, और आम तौर पर इसके उपयोग के खिलाफ सिफारिश की। As of 2008 स्वतंत्र डेटा-एक्सेस विक्रेता JDBC-ODBC ब्रिज डिलीवर करते हैं जो दोनों तंत्रों के लिए मौजूदा मानकों का समर्थन करते हैं, और जो JVM बिल्ट-इन से कहीं बेहतर प्रदर्शन करते हैं।[citation needed] उदाहरण: OpenLink JDBC-ODBC ब्रिज, SequeLink JDBC-ODBC ब्रिज।

ओएलई डीबी-टू-ओडीबीसी पुल

एक OLE DB-ODBC ब्रिज में एक OLE DB प्रदाता होता है जो लक्ष्य डेटाबेस से जुड़ने के लिए ODBC ड्राइवर की सेवाओं का उपयोग करता है। यह प्रदाता OLE DB विधि (कंप्यूटर विज्ञान) कॉल का ODBC फ़ंक्शन कॉल में अनुवाद करता है। प्रोग्रामर आमतौर पर ऐसे पुल का उपयोग करते हैं जब किसी दिए गए डेटाबेस में OLE DB प्रदाता की कमी होती है, लेकिन ODBC ड्राइवर के माध्यम से पहुँचा जा सकता है। Microsoft एक, MSDASQL.DLL, Microsoft डेटा एक्सेस कंपोनेंट्स सिस्टम घटक बंडल के हिस्से के रूप में, अन्य डेटाबेस ड्राइवरों के साथ, COM-जागरूक भाषाओं (जैसे मूल दृश्य) में विकास को आसान बनाने के लिए शिप करता है। तृतीय पक्षों ने भी ऐसा विकसित किया है, विशेष रूप से OpenLink सॉफ़्टवेयर जिसके ODBC डेटा स्रोतों के लिए 64-बिट OLE DB प्रदाता ने अंतर को भर दिया जब Microsoft ने अपने 64-बिट OS के लिए इस ब्रिज को शुरू में हटा दिया।[31] (Microsoft ने बाद में नरमी दिखाई, और Windows Server 2008 के साथ शुरू होने वाले 64-बिट Windows और Windows Vista SP1 को MSDASQL के 64-बिट संस्करण के साथ भेज दिया गया है।) उदाहरण: OpenLink OLEDB-ODBC ब्रिज, SequeLink OLEDB-ODBC ब्रिज।

ADO.NET-to-ODBC ब्रिज

एक ADO.NET-ODBC ब्रिज में एक ADO.NET डेटा प्रदाता | ADO.NET प्रदाता होता है जो लक्ष्य डेटाबेस से जुड़ने के लिए ODBC ड्राइवर की सेवाओं का उपयोग करता है। यह प्रदाता ADO.NET मेथड (कंप्यूटर साइंस) कॉल्स को ODBC फंक्शन कॉल्स में ट्रांसलेट करता है। प्रोग्रामर आमतौर पर ऐसे पुल का उपयोग करते हैं जब किसी दिए गए डेटाबेस में ADO.NET प्रदाता की कमी होती है, लेकिन ODBC ड्राइवर के माध्यम से पहुँचा जा सकता है। Microsoft, C Sharp (प्रोग्रामिंग भाषा)|C# में विकास को आसान बनाने के लिए, अन्य डेटाबेस ड्राइवरों के साथ मिलकर, Microsoft डेटा एक्सेस कंपोनेंट्स सिस्टम घटक बंडल के भाग के रूप में शिप करता है। तीसरे पक्ष ने भी ऐसा विकसित किया है। उदाहरण: OpenLink ADO.NET-ODBC ब्रिज, SequeLink ADO.NET-ODBC ब्रिज .

यह भी देखें

संदर्भ

Bibliography
  • Geiger, Kyle (1995). Inside ODBC. Microsoft Press. ISBN 9781556158155.
Citations
  1. ↑ McGlinn, Evan (1988), Blueprint Lets 1-2-3 Access Outside Data", InfoWorld, vol. 10, no. 14, 4 April 1988, pp. 1, 69
  2. ↑ 2.0 2.1 Geiger 1995, p. 65.
  3. ↑ Geiger 1995, p. 86-87.
  4. ↑ Geiger 1995, p. 56.
  5. ↑ Geiger 1995, p. 106.
  6. ↑ Geiger 1995, p. 165.
  7. ↑ 7.0 7.1 Geiger 1995, p. 186-187.
  8. ↑ Geiger 1995, p. 203.
  9. ↑ Harindranath, G; Jože Zupančič (2001). New perspectives on information systems development: theory, methods, and practice. Springer. p. 451. ISBN 978-0-306-47251-0. Retrieved 2010-07-28. The first ODBC drivers […] used the SIMBA query processor, which translated calls into the Microsoft Jet ISAM calls, and dispatched the calls to the appropriate ISAM driver to access the backend […]
  10. ↑ "Linux/UNIX ODBC – What is ODBC?".
  11. ↑ "Our History", Simba Technologies
  12. ↑ Idehen, Kingsley Uyi (October 1994). "ODBC and progress V7.2d". Usenet Newsgroup comp.databases. Retrieved 13 December 2013.
  13. ↑ Idehen, Kingsley Uyi (1995-07-18). "Need ODBC/Ingres driver for DEC OSF/1". Usenet Newsgroup comp.databases.oracle. Retrieved 13 December 2013.
  14. ↑ Sippl, Roger (1996) "SQL Access Group's Call-Level Interface", Dr. Dobbs, 1 February 1996
  15. ↑ "Similarities and differences between ODBC and CLI", InfoSphere Classic documentation, IBM, 26 September 2008
  16. ↑ "OLE DB and SQL Server: History, End-Game, and some Microsoft "dirt"". 25 September 2011.
  17. ↑ "Announcing the new release of OLE DB Driver for SQL Server".
  18. ↑ Anderson, Andrew (2003-06-20). "Open Database Connectivity in Jaguar". O'Reilly MacDevCenter.com. O'Reilly Media, Inc. Retrieved 13 December 2013.
  19. ↑ Sellers, Dennis (2001-07-17). "ODBC SDK update out for Mac OS Classic, Mac OS X". MacWorld. IDG Consumer & SMB. Retrieved 13 December 2013.
  20. ↑ Werner, Christian (2018) "SQLite ODBC Driver" Archived 2014-06-26 at the Wayback Machine, 2018-02-24
  21. ↑ "ODBC Versions". Linux/UNIX ODBC. Easysoft. Retrieved 2009-10-27.
  22. ↑ Antal, Tiberiu Alexandru. "Access to an Oracle database using JDBC" (PDF). Cluj-Napoca: Technical University of Cluj-Napoca. p. 2. Archived from the original (PDF) on 2011-07-22. Retrieved 2009-10-27. ODBC 1.0 was released in September 1992
  23. ↑ Microsoft Corporation. Microsoft ODBC 3.0 Programmer's Reference and SDK Guide, Volume 1. Microsoft Press. February 1997. (ISBN 9781572315167)
  24. ↑ "What's New in ODBC 3.8". Microsoft. Retrieved 2010-01-13. Windows 7 includes an updated version of ODBC, ODBC 3.8.
  25. ↑ Rukmangathan, Krishnakumar (2016-06-07). "A new release of ODBC for Modern Data Stores". Microsoft Data Access / SQL BI Technologies Blog. Microsoft. Retrieved 2017-01-03. After more than 15 years since the last release, Microsoft is looking at updating the Open Data Base Connectivity (ODBC) specification.
  26. ↑ "History of the Desktop Database Drivers".
  27. ↑ "SAP HANA System Properties". DB-Engines. Retrieved 2016-03-28.
  28. ↑ "Connect to SAP HANA via ODBC - SAP HANA Developer Guide for SAP HANA Studio - SAP Library". help.sap.com. Retrieved 2016-03-28.
  29. ↑ Sybase. "Introduction to ODBC". infocenter.sybase.com. Sybase. Retrieved 8 October 2011.
  30. ↑ "Java JDBC API". docs.oracle.com. Retrieved 18 December 2018.
  31. ↑ Microsoft, "Data Access Technologies Road Map", Deprecated MDAC Components, Microsoft "ADO Programmer's Guide" Appendix A: Providers, Microsoft OLE DB Provider for ODBC, retrieved July 30, 2005. Archived 2001 October 5 at the Wayback Machine


बाहरी संबंध

Retrieved from ‘https://www.vigyanwiki.in/index.php?title=ओपन_डेटाबेस_कनेक्टिविटी&oldid=111743’