اتصال قاعدة البيانات المفتوحة

أدى ظهور قواعد البيانات العلائقية القائمة على الحواسيب المركزية خلال سبعينيات القرن الماضي إلى انتشار واسع لأساليب الوصول إلى البيانات. عمومًا، كانت هذه الأنظمة تعمل بالتزامن مع معالج أوامر بسيط يسمح للمستخدمين بكتابة أوامر شبيهة باللغة الإنجليزية، والحصول على مخرجات. من أشهر الأمثلة على ذلك لغة SQL من شركة IBM ولغة QUEL من مشروع Ingres . قد تسمح هذه الأنظمة أو لا تسمح لتطبيقات أخرى بالوصول المباشر إلى البيانات، وتلك التي سمحت بذلك استخدمت منهجيات متنوعة. كان الهدف من إدخال لغة SQL هو حل مشكلة توحيد اللغة ، على الرغم من بقاء اختلافات جوهرية في التنفيذ.

نظرًا لأن لغة SQL كانت تفتقر إلى ميزات برمجية أساسية، فقد رغب المستخدمون غالبًا في استخدامها ضمن برنامج مكتوب بلغة أخرى، مثل Fortran أو C. أدى ذلك إلى ظهور مفهوم SQL المضمن ، الذي يسمح بتضمين كود SQL ضمن لغة أخرى. على سبيل المثال، يمكن إدراج عبارة SQL كنص ضمن كود مصدر C، وأثناء عملية الترجمة، يتم تحويلها إلى تنسيق مخصص يستدعي مباشرةً دالةً ضمن مكتبة، والتي بدورها تمرر العبارة إلى نظام SQL. تُفسَّر النتائج المُعادة من العبارات إلى تنسيقات بيانات C، مثل `<SQL>` أو ` <SQL>`، باستخدام كود مكتبة مماثل.SELECT * FROM citychar*char[]

واجهت تقنية SQL المضمنة عدة مشاكل. فكما هو الحال مع أنواع SQL المختلفة، تباينت استعلامات SQL المضمنة التي تستخدمها بشكل كبير، ليس فقط بين المنصات المختلفة، بل حتى بين لغات البرمجة على المنصة الواحدة - فالنظام الذي يسمح باستدعاء IBM Db2 يختلف تمامًا عن النظام الذي يستدعي SQL/DS الخاص به . ومن المشاكل الرئيسية الأخرى لمفهوم SQL المضمنة أن كود SQL لا يمكن تعديله إلا في الكود المصدري للبرنامج، مما يجعل حتى التغييرات الطفيفة في الاستعلام تتطلب جهدًا كبيرًا من المبرمج. وقد أطلق سوق SQL على هذا النوع اسم SQL الثابت ، مقابل SQL الديناميكي الذي يمكن تعديله في أي وقت، مثل واجهات سطر الأوامر التي كانت تُرفق مع معظم أنظمة SQL، أو واجهة برمجة تُبقي SQL كنص عادي حتى يتم استدعاؤه. وقد أصبحت أنظمة SQL الديناميكية محورًا رئيسيًا لموردي SQL خلال ثمانينيات القرن الماضي.

لم تكن قواعد بيانات الحواسيب المركزية القديمة، والأنظمة الحديثة القائمة على الحواسيب الصغيرة والمبنية عليها، تحتوي عمومًا على معالج أوامر شبيه بلغة SQL بين المستخدم ومحرك قاعدة البيانات . بدلًا من ذلك، كان البرنامج يصل إلى البيانات مباشرةً - مكتبة برمجية في حالة أنظمة الحواسيب المركزية الكبيرة، أو واجهة سطر أوامر أو نظام نماذج تفاعلية في حالة dBASE والتطبيقات المشابهة. لم يكن بالإمكان عمومًا الوصول مباشرةً إلى بيانات dBASE من قِبل البرامج الأخرى العاملة على الجهاز. قد تُمنح هذه البرامج طريقةً للوصول إلى هذه البيانات، غالبًا من خلال مكتبات، لكنها لن تعمل مع أي محرك قاعدة بيانات آخر، أو حتى مع قواعد بيانات مختلفة ضمن نفس المحرك. في الواقع، كانت جميع هذه الأنظمة ثابتة، مما شكّل مشاكل كبيرة.

بحلول منتصف ثمانينيات القرن العشرين، أدى التطور السريع في الحواسيب الصغيرة، ولا سيما ظهور واجهة المستخدم الرسومية وبرامج التطبيقات الغنية بالبيانات مثل لوتس 1-2-3، إلى تزايد الاهتمام باستخدام الحواسيب الشخصية كمنصة العميل المفضلة في الحوسبة القائمة على نموذج العميل والخادم . في هذا النموذج، تُستخدم الحواسيب المركزية الكبيرة والحواسيب الصغيرة بشكل أساسي لتقديم البيانات عبر الشبكات المحلية إلى الحواسيب الصغيرة التي تقوم بدورها بتفسير تلك البيانات وعرضها ومعالجتها. ولنجاح هذا النموذج، كان وجود معيار موحد للوصول إلى البيانات شرطًا أساسيًا؛ ففي مجال الحواسيب المركزية، كان من المرجح أن تكون جميع الحواسيب في المتجر من مورد واحد، وأن تكون أجهزة العميل عبارة عن محطات طرفية تتصل بها مباشرةً، بينما في مجال الحواسيب الصغيرة، لم يكن هناك مثل هذا التوحيد القياسي، وكان بإمكان أي عميل الوصول إلى أي خادم باستخدام أي نظام شبكات.

بحلول أواخر ثمانينيات القرن العشرين، بُذلت جهودٌ حثيثة لتوفير طبقة تجريدية لهذا الغرض. بعض هذه الجهود كان مرتبطًا بالحواسيب المركزية، ومصممًا لتمكين البرامج العاملة عليها من الترجمة بين مختلف لغات SQL، وتوفير واجهة مشتركة واحدة يمكن استدعاؤها من قِبل برامج أخرى تعمل على الحواسيب المركزية أو الحواسيب الصغيرة. شملت هذه الحلول بنية قواعد البيانات العلائقية الموزعة ( DRDA ) من شركة IBM، ولغة الوصول إلى البيانات (DATA ACL) من شركة Apple Computer . مع ذلك، كانت الأنظمة الأكثر شيوعًا هي تلك التي تعمل بالكامل على الحواسيب الصغيرة، بما في ذلك حزمة بروتوكولات كاملة تتضمن أي دعم مطلوب للشبكات أو ترجمة الملفات.

كان نظام DataLens من شركة Lotus Development ، والذي عُرف في البداية باسم Blueprint، أحد الأمثلة المبكرة على هذا النوع من الأنظمة . وقد صُمم Blueprint لنظام 1-2-3، ودعم مجموعة متنوعة من مصادر البيانات، بما في ذلك SQL/DS وDB2 و FOCUS، بالإضافة إلى العديد من أنظمة الحواسيب المركزية المماثلة، فضلاً عن أنظمة الحواسيب الصغيرة مثل dBase، والجهود المبكرة التي بذلتها مايكروسوفت/أشتون-تيت والتي تطورت لاحقًا إلى Microsoft SQL Server . ^{[ 1 ]} وعلى عكس ODBC اللاحق، كان Blueprint نظامًا قائمًا على البرمجة فقط، يفتقر إلى أي شيء يُشبه لغة الأوامر مثل SQL. بدلاً من ذلك، استخدم المبرمجون هياكل البيانات لتخزين معلومات الاستعلام، وقاموا ببناء الاستعلام من خلال ربط العديد من هذه الهياكل معًا. وقد أطلقت شركة Lotus على هذه الهياكل المركبة اسم أشجار الاستعلام . ^{[ 2 ]}

في نفس الفترة تقريبًا، كان فريق متخصص في هذا المجال، يضم أعضاءً من شركة Sybase (توم هاجين)، وشركة Tandem Computers ( جيم جراي وراو يندلوري)، وشركة Microsoft (كايل جايجر)، يعمل على تطوير مفهوم موحد للغة SQL الديناميكية. استند جزء كبير من النظام إلى نظام DB-Library الخاص بشركة Sybase، مع إزالة الأقسام الخاصة بشركة Sybase وإضافة العديد من الأقسام لدعم منصات أخرى. ^{[ 3 ]} وقد ساهم في تطوير DB-Library التحول الذي شهده قطاع الصناعة من أنظمة المكتبات المرتبطة ارتباطًا وثيقًا بلغة برمجة محددة، إلى أنظمة مكتبات يوفرها نظام التشغيل وتتطلب من لغات البرمجة على تلك المنصة التوافق مع معاييره. هذا يعني إمكانية استخدام مكتبة واحدة مع أي لغة برمجة (نظريًا) على منصة معينة.

نُشرت المسودة الأولى لواجهة برمجة تطبيقات الوصول إلى بيانات مايكروسوفت (MSDA) في أبريل 1989، بالتزامن تقريبًا مع إعلان لوتس عن مشروع بلوبرينت. ^{[ 4 ]} على الرغم من ريادة بلوبرينت الكبيرة - إذ كان قيد التشغيل بينما كانت MSDA لا تزال مشروعًا نظريًا - انضمت لوتس في نهاية المطاف إلى جهود MSDA عندما اتضح أن لغة SQL ستصبح المعيار الفعلي لقواعد البيانات. ^{[ 2 ]} بعد مساهمات كبيرة من قطاع الصناعة، أصبح المعيار في صيف عام 1989 هو اتصال SQL ( SQLC ). ^{[ 5 ]}

في عام ١٩٨٨، شكّل عدد من الموردين، معظمهم من مجتمعات يونكس وقواعد البيانات، مجموعة الوصول إلى لغة SQL (SAG) بهدف وضع معيار أساسي موحد للغة SQL. وفي الاجتماع الأول، دار نقاش حاد حول ما إذا كان ينبغي أن يقتصر الجهد على لغة SQL نفسها، أم أن يسعى إلى توحيد المعايير على نطاق أوسع ليشمل نظامًا ديناميكيًا لتضمين لغة SQL، أطلقوا عليه اسم واجهة مستوى الاستدعاء (CLI). ^{[ ٦ ]} وأثناء حضوره الاجتماع ومعه مسودة أولية لما كان يُعرف آنذاك باسم MS Data Access، دعا كايل جايجر من مايكروسوفت كلاً من جيف بالبوني ولاري بارنز من شركة ديجيتال إكويبمنت (DEC) للانضمام إلى اجتماعات SQLC أيضًا. وكانت SQLC حلاً محتملاً للدعوة إلى واجهة مستوى الاستدعاء (CLI)، التي كانت تقودها شركة DEC.

قدمت مجموعة "الأربعة" الجديدة لـ SQLC، وهي مايكروسوفت، وتانديم، ودي إي سي، وسايبيس، نسخة محدثة من SQLC إلى اجتماع SAG التالي في يونيو 1990. ^{[ 7 ]} استجابت SAG بفتح باب النقاش حول المعيار أمام أي تصميم منافس، ولكن من بين المقترحات العديدة، كانت شركة أوراكل الوحيدة التي قدمت نظامًا يُشكل منافسة جدية. في النهاية، فازت SQLC بالتصويت وأصبحت مسودة المعيار، ولكن بعد حذف أجزاء كبيرة من واجهة برمجة التطبيقات (API) - حيث تم تقليص وثيقة المعايير من 120 صفحة إلى 50 صفحة خلال هذه الفترة. وخلال هذه الفترة أيضًا تم اعتماد اسم "واجهة مستوى الاستدعاء" (COL Level Interface) رسميًا. ^{[ 7 ]} في عام 1995، أصبحت SQL/CLI جزءًا من معيار SQL الدولي، ISO/IEC 9075-3. ^{[ 8 ]} في عام 1996، تولت مجموعة X/Open إدارة SAG ، ومع مرور الوقت، أصبحت جزءًا من بيئة التطبيقات المشتركة لمجموعة Open Group .

واصلت مايكروسوفت العمل بمعيار SQLC الأصلي، محتفظةً بالعديد من الميزات المتقدمة التي أُزيلت من إصدار واجهة سطر الأوامر (CLI). وشملت هذه الميزات مؤشرات قابلة للتمرير ، واستعلامات معلومات البيانات الوصفية . قُسّمت الأوامر في واجهة برمجة التطبيقات (API) إلى مجموعات؛ كانت المجموعة الأساسية مطابقةً لواجهة سطر الأوامر، بينما كانت امتدادات المستوى 1 عبارة عن أوامر يسهل تنفيذها في برامج التشغيل، أما أوامر المستوى 2 فاحتوت على الميزات الأكثر تقدمًا مثل المؤشرات. صدر معيار مقترح في ديسمبر 1991، وجُمعت مدخلات الصناعة وطُبّقت في النظام خلال عام 1992، مما أدى إلى تغيير الاسم مرة أخرى إلى ODBC . ^{[ 9 ]}

خلال هذه الفترة، كانت مايكروسوفت منهمكة في تطوير نظام قاعدة بيانات Jet . جمع Jet ثلاثة أنظمة فرعية رئيسية: محرك قاعدة بيانات قائم على ISAM (يحمل الاسم نفسه Jet ، مما قد يُسبب بعض الالتباس)، وواجهة مكتوبة بلغة C تُمكّن التطبيقات من الوصول إلى تلك البيانات، ومجموعة من مكتبات الارتباط الديناميكي (DLL) التي تسمح لواجهة C نفسها بإعادة توجيه المدخلات والمخرجات إلى قواعد بيانات أخرى قائمة على ISAM، مثل Paradox و xBase . سمح Jet باستخدام مجموعة واحدة من الاستدعاءات للوصول إلى قواعد بيانات الحواسيب الصغيرة الشائعة بطريقة مشابهة لـ Blueprint، الذي أُعيد تسميته لاحقًا إلى DataLens. مع ذلك، لم يستخدم Jet لغة SQL؛ فمثل DataLens، كانت الواجهة مكتوبة بلغة C وتتألف من هياكل بيانات واستدعاءات دوال.

أتاحت جهود توحيد معايير SAG فرصةً لشركة مايكروسوفت لتكييف نظام Jet الخاص بها مع معيار واجهة سطر الأوامر الجديد. لم يقتصر الأمر على جعل ويندوز منصةً رائدةً لتطوير واجهات سطر الأوامر، بل سمح أيضًا للمستخدمين باستخدام لغة SQL للوصول إلى Jet وقواعد البيانات الأخرى. كان ينقص النظام محلل SQL القادر على تحويل هذه الاستدعاءات من شكلها النصي إلى واجهة C المستخدمة في Jet. ولحل هذه المشكلة، تعاونت مايكروسوفت مع شركة PageAhead Software لاستخدام معالج الاستعلامات الحالي لديها، SIMBA. استُخدم SIMBA كمحلل فوق مكتبة C الخاصة بـ Jet، مما حوّل Jet إلى قاعدة بيانات SQL. ولأن Jet كان قادرًا على إعادة توجيه استدعاءات C هذه إلى قواعد بيانات أخرى، فقد سمح ذلك أيضًا لـ SIMBA بالاستعلام عن أنظمة أخرى. أضافت مايكروسوفت برامج تشغيل لبرنامج Excel لتحويل مستندات جداول البيانات إلى جداول قواعد بيانات قابلة للوصول إليها عبر SQL. ^{[ 10 ]}

صدرت ODBC 1.0 في سبتمبر 1992. ^{[ 11 ]} في ذلك الوقت، كان الدعم المباشر لقواعد بيانات SQL محدودًا (مقارنةً بـ ISAM)، واشتهرت برامج التشغيل المبكرة بضعف أدائها. كان جزء من هذا الأداء حتميًا نظرًا لمسار استدعاءات ODBC عبر بنية Jet؛ حيث كانت استدعاءات ODBC لقواعد بيانات SQL تُحوّل أولًا من لغة SQL الخاصة بشركة Simba Technologies إلى تنسيق Jet الداخلي القائم على لغة C، ثم تُمرّر إلى برنامج تشغيل لتحويلها مرة أخرى إلى استدعاءات SQL لقاعدة البيانات. تعاقدت كل من Digital Equipment و Oracle مع Simba Technologies لتطوير برامج تشغيل لقواعد بياناتهما أيضًا. ^{[ 12 ]}

في عام 1993 تقريبًا، قامت شركة OpenLink Software بشحن أحد أوائل برامج تشغيل ODBC المطورة بشكل مستقل من قبل جهات خارجية، لنظام إدارة قواعد البيانات PROGRESS ، ^{[ 13 ]} وسرعان ما تبعتها بحزمة تطوير البرامج UDBC (وهي واجهة برمجة تطبيقات متعددة المنصات مكافئة لـ ODBC وSAG/CLI) وبرامج التشغيل المرتبطة بها لأنظمة PROGRESS وSybase وOracle وغيرها من أنظمة إدارة قواعد البيانات، للاستخدام على أنظمة التشغيل الشبيهة بنظام Unix ( AIX و HP-UX و Solaris و Linux وما إلى ذلك) و VMS و Windows NT و OS/2 وغيرها من أنظمة التشغيل. ^{[ 14 ]}

في غضون ذلك، استمر العمل على معيار واجهة سطر الأوامر (CLI) لفترة طويلة، ولم يتم الانتهاء من النسخة النهائية إلا في مارس 1995. وبحلول ذلك الوقت، كانت مايكروسوفت قد منحت شركة Visigenic Software ترخيصًا لشفرة المصدر لتطوير ODBC على منصات غير ويندوز. قامت Visigenic بنقل ODBC إلى نظام التشغيل Mac OS الكلاسيكي ، ومجموعة واسعة من منصات يونكس، حيث سرعان ما أصبح ODBC المعيار الفعلي. ^{[ 15 ]} أما واجهة سطر الأوامر "الحقيقية" فهي نادرة اليوم. لا يزال النظامان متشابهين، ويمكن نقل العديد من التطبيقات من ODBC إلى واجهة سطر الأوامر مع تغييرات طفيفة أو بدون أي تغييرات. ^{[ 16 ]}

بمرور الوقت، استحوذت شركات قواعد البيانات على واجهات برامج التشغيل ووفرت روابط مباشرة لمنتجاتها. غالبًا ما أدى تجاوز التحويلات الوسيطة من وإلى Jet أو ما شابهها من برامج التغليف إلى تحسين الأداء. مع ذلك، بحلول ذلك الوقت، حوّلت مايكروسوفت تركيزها إلى مفهوم OLE DB ^{[ 17 ]} (الذي أُعيد العمل به مؤخرًا ^{[ 18 ]} )، والذي وفّر وصولًا مباشرًا إلى مجموعة أوسع من مصادر البيانات، بدءًا من دفاتر العناوين وصولًا إلى الملفات النصية. تبع ذلك ظهور العديد من الأنظمة الجديدة التي حوّلت اهتمامها بشكل أكبر عن ODBC، بما في ذلك ActiveX Data Objects (ADO) و ADO.net ، والتي تفاعلت بشكل أو بآخر مع ODBC طوال فترة وجودها.

مع تحوّل اهتمام مايكروسوفت عن العمل المباشر على ODBC، ازداد إقبال مستخدمي أنظمة يونكس عليه. وقد حفّز هذا التوجه عاملان رئيسيان في السوق: ظهور واجهات المستخدم الرسومية (GUIs) مثل جنوم، التي وفّرت الحاجة إلى الوصول إلى هذه المصادر بصيغة غير نصية، وظهور أنظمة قواعد البيانات مفتوحة المصدر مثل PostgreSQL و MySQL ، والتي كانت تعمل في البداية ضمن أنظمة يونكس. وقد رسّخ اعتماد آبل لاحقًا لتقنية ODBC لاستخدامها حزمة iODBC القياسية لنظام يونكس Mac OS X 10.2 (جاغوار) ^{[ 19 ]} (والتي كانت شركة OpenLink Software توفّرها بشكل مستقل لنظامي Mac OS X 10.0 وMac OS 9 منذ عام 2001 ^{[ 20 ]} ) مكانة ODBC كمعيار للوصول إلى البيانات عبر مختلف المنصات.

استخدمت شركة صن مايكروسيستمز نظام ODBC كأساس لمعيارها المفتوح الخاص، وهو اتصال قواعد بيانات جافا (JDBC). ويمكن اعتبار JDBC، من معظم النواحي، نسخةً من ODBC للغة البرمجة جافا بدلاً من لغة C. تتيح جسور JDBC-to-ODBC للبرامج المبنية على جافا الوصول إلى مصادر البيانات عبر برامج تشغيل ODBC على المنصات التي تفتقر إلى برنامج تشغيل JDBC أصلي، على الرغم من ندرة هذه المنصات حاليًا. وبالمقابل، تتيح جسور ODBC-to-JDBC للبرامج المبنية على لغة C الوصول إلى مصادر البيانات عبر برامج تشغيل JDBC على المنصات أو من قواعد البيانات التي تفتقر إلى برامج تشغيل ODBC مناسبة.

لا يزال بروتوكول ODBC مستخدمًا على نطاق واسع حتى اليوم، مع توفر برامج تشغيل لمعظم المنصات ومعظم قواعد البيانات. ومن الشائع العثور على برامج تشغيل ODBC لمحركات قواعد البيانات المصممة للتضمين، مثل SQLite ، كوسيلة لتمكين الأدوات الحالية من العمل كواجهات أمامية لهذه المحركات لأغراض الاختبار والتصحيح. ^{[ 21 ]}

في السنوات الأخيرة، تم اعتماد بروتوكول ODBC أيضاً للاتصال بمصادر البيانات السحابية ومنصات البرمجيات كخدمة (SaaS) مثل Salesforce وGoogle BigQuery وSnowflake. وقد مكّن توفر برامج التشغيل عبر مختلف الأنظمة الأساسية (Windows وmacOS وLinux) من التكامل مع أدوات التحليلات الحديثة وأدوات ذكاء الأعمال مثل Power BI وTableau وRStudio. وقد وسّع هذا من نطاق استخدام ODBC ليشمل، بالإضافة إلى قواعد البيانات العلائقية التقليدية، تخزين البيانات السحابية وسير عمل علوم البيانات.

تعتمد تقنية ODBC على نموذج برنامج تشغيل الجهاز ، حيث يغلف برنامج التشغيل المنطق اللازم لتحويل مجموعة قياسية من الأوامر والوظائف إلى استدعاءات محددة يتطلبها النظام الأساسي. على سبيل المثال، يقدم برنامج تشغيل الطابعة مجموعة قياسية من أوامر الطباعة، وهي واجهة برمجة التطبيقات (API)، للتطبيقات التي تستخدم نظام الطباعة. ويقوم برنامج التشغيل بتحويل الاستدعاءات التي تُجرى على واجهات برمجة التطبيقات هذه إلى التنسيق الذي يستخدمه الجهاز الفعلي، مثل PostScript أو PCL .

في حالة ODBC، تُغلف برامج التشغيل العديد من الوظائف التي يمكن تصنيفها إلى عدة فئات رئيسية. تُعنى مجموعة من الوظائف بشكل أساسي بإيجاد نظام إدارة قواعد البيانات (DBMS) والاتصال به وفصل الاتصال عنه. وتُستخدم مجموعة ثانية لإرسال أوامر SQL من نظام ODBC إلى نظام إدارة قواعد البيانات، مع تحويل أو تفسير أي أوامر غير مدعومة داخليًا. على سبيل المثال، يمكن لنظام إدارة قواعد بيانات لا يدعم المؤشرات محاكاة هذه الوظيفة في برنامج التشغيل. وأخيرًا، تُستخدم مجموعة أخرى من الأوامر، تُستخدم في الغالب داخليًا، لتحويل البيانات من التنسيقات الداخلية لنظام إدارة قواعد البيانات إلى مجموعة من تنسيقات ODBC القياسية، والتي تستند إلى تنسيقات لغة C.

يُمكّن برنامج تشغيل ODBC التطبيقات المتوافقة مع ODBC من استخدام مصدر بيانات ، عادةً ما يكون نظام إدارة قواعد بيانات (DBMS). توجد بعض برامج التشغيل غير المخصصة لأنظمة إدارة قواعد البيانات، لمصادر بيانات مثل ملفات CSV ، وذلك من خلال دمج نظام إدارة قواعد بيانات صغير داخل برنامج التشغيل نفسه. تتوفر برامج تشغيل ODBC لمعظم أنظمة إدارة قواعد البيانات، بما في ذلك Oracle و PostgreSQL و MySQL و Microsoft SQL Server (باستثناء الإصدار Compact المعروف أيضًا باسم CE ) و Mimer SQL و Sybase ASE و SAP HANA ^{[ 28 ] [ 29 ]} و IBM Db2 . نظرًا لاختلاف إمكانيات التقنيات المختلفة، فإن معظم برامج تشغيل ODBC لا تُنفّذ جميع الوظائف المُحددة في معيار ODBC. كما تُقدّم بعض برامج التشغيل وظائف إضافية غير مُحددة في المعيار.

عادةً ما يتم تعداد برامج تشغيل الأجهزة وإعدادها وإدارتها بواسطة طبقة إدارة منفصلة، ​​والتي قد توفر وظائف إضافية. على سبيل المثال، غالبًا ما تتضمن أنظمة الطباعة وظائف لتوفير خاصية التخزين المؤقت للطباعة بالإضافة إلى برامج التشغيل، مما يوفر تخزينًا مؤقتًا للطباعة لأي طابعة مدعومة.

في بروتوكول ODBC، يوفر مدير برامج التشغيل (DM) هذه الميزات. ^{[ 30 ]} يستطيع مدير برامج التشغيل سرد برامج التشغيل المثبتة وعرضها كقائمة، غالبًا في شكل واجهة مستخدم رسومية.

لكن الأهم بالنسبة لتشغيل نظام ODBC هو مفهوم اسم مصدر البيانات (DSN) في مدير قواعد البيانات (DM). تجمع أسماء مصادر البيانات معلومات إضافية ضرورية للاتصال بمصدر بيانات محدد ، بدلاً من نظام إدارة قواعد البيانات نفسه. على سبيل المثال، يمكن استخدام برنامج تشغيل MySQL نفسه للاتصال بأي خادم MySQL، لكن معلومات الاتصال بخادم محلي خاص تختلف عن المعلومات المطلوبة للاتصال بخادم عام مُستضاف على الإنترنت. يخزن اسم مصدر البيانات هذه المعلومات بتنسيق موحد، ويُقدمها مدير قواعد البيانات إلى برنامج التشغيل أثناء طلبات الاتصال. كما يتضمن مدير قواعد البيانات وظيفة لعرض قائمة بأسماء مصادر البيانات بأسماء سهلة القراءة، ولتحديدها أثناء التشغيل للاتصال بموارد مختلفة.

يتضمن برنامج إدارة البيانات (DM) أيضًا إمكانية حفظ مصادر بيانات النظام (DSN) غير المكتملة، مع تضمين التعليمات البرمجية والمنطق اللازمين لطلب أي معلومات ناقصة من المستخدم أثناء التشغيل. على سبيل المثال، يمكن إنشاء مصدر بيانات نظام (DSN) بدون كلمة مرور مطلوبة. عندما يحاول تطبيق ODBC الاتصال بنظام إدارة قواعد البيانات (DBMS) باستخدام مصدر البيانات هذا، سيتوقف النظام مؤقتًا ويطلب من المستخدم إدخال كلمة المرور قبل المتابعة. هذا يُغني مطور التطبيق عن كتابة هذا النوع من التعليمات البرمجية، بالإضافة إلى معرفة الأسئلة التي يجب طرحها. كل هذا مُضمن في برنامج التشغيل ومصادر بيانات النظام (DSN).

يتكون جسر ODBC-JDBC من برنامج تشغيل ODBC يستخدم خدمات برنامج تشغيل JDBC للاتصال بقاعدة البيانات. يقوم هذا البرنامج بترجمة استدعاءات دوال ODBC إلى استدعاءات أساليب JDBC. عادةً ما يستخدم المبرمجون هذا الجسر عندما لا يتوفر لديهم برنامج تشغيل ODBC لقاعدة بيانات معينة، ولكن يتوفر لديهم برنامج تشغيل JDBC. أمثلة: جسر OpenLink ODBC-JDBC ، وجسر SequeLink ODBC-JDBC .

يتكون جسر JDBC-ODBC من برنامج تشغيل JDBC يستخدم برنامج تشغيل ODBC للاتصال بقاعدة البيانات المستهدفة. يقوم هذا البرنامج بترجمة استدعاءات أساليب JDBC إلى استدعاءات دوال ODBC. عادةً ما يستخدم المبرمجون هذا الجسر عندما تفتقر قاعدة البيانات إلى برنامج تشغيل JDBC، ولكن يمكن الوصول إليها من خلال برنامج تشغيل ODBC. أدرجت شركة Sun Microsystems جسرًا من هذا النوع في JVM ، لكنها اعتبرته حلاً مؤقتًا في ظل ندرة برامج تشغيل JDBC (تم حذف جسر JDBC-ODBC المدمج من JVM في Java 8 ^{[ 31 ]} ). لم تُصمم Sun جسرها أبدًا للاستخدام في بيئات الإنتاج، وعمومًا أوصت بعدم استخدامه. اعتبارًا من عام 2008توفر شركات مستقلة متخصصة في الوصول إلى البيانات جسور JDBC-ODBC التي تدعم المعايير الحالية لكلا الآليتين، وتتفوق بشكل ملحوظ على جسور JVM المدمجة. ومن الأمثلة على ذلك: جسر OpenLink JDBC-ODBC ، وجسر SequeLink JDBC-ODBC ، وجسر ZappySys JDBC-ODBC .

يتكون جسر OLE DB-ODBC من موفر OLE DB يستخدم خدمات برنامج تشغيل ODBC للاتصال بقاعدة البيانات المستهدفة. يقوم هذا الموفر بترجمة استدعاءات أساليب OLE DB إلى استدعاءات دوال ODBC. عادةً ما يستخدم المبرمجون هذا الجسر عندما تفتقر قاعدة بيانات معينة إلى موفر OLE DB، ولكن يمكن الوصول إليها من خلال برنامج تشغيل ODBC. توفر مايكروسوفت موفرًا، MSDASQL.DLL، كجزء من حزمة مكونات نظام MDAC ، إلى جانب برامج تشغيل قواعد البيانات الأخرى، لتبسيط التطوير في لغات COM (مثل Visual Basic ). كما طورت جهات خارجية مثل هذه الجسور، ولا سيما شركة OpenLink Software التي سدّت الفجوة بموفر OLE DB ذي 64 بت لمصادر بيانات ODBC عندما أوقفت مايكروسوفت دعم هذا الجسر لأنظمة التشغيل 64 بت الخاصة بها. ^{[ 32 ]} (تراجعت مايكروسوفت لاحقًا، وتم شحن أنظمة ويندوز 64 بت بدءًا من ويندوز سيرفر 2008 وويندوز فيستا SP1 مع إصدار 64 بت من MSDASQL.) أمثلة: جسر OpenLink OLEDB-ODBC مؤرشف في 2017-03-27 في Wayback Machine ، جسر SequeLink OLEDB-ODBC .

يتكون جسر ADO.NET-ODBC من موفر ADO.NET يستخدم خدمات برنامج تشغيل ODBC للاتصال بقاعدة البيانات المستهدفة. يقوم هذا الموفر بترجمة استدعاءات أساليب ADO.NET إلى استدعاءات دوال ODBC. عادةً ما يستخدم المبرمجون هذا الجسر عندما تفتقر قاعدة البيانات إلى موفر ADO.NET، ولكن يمكن الوصول إليها من خلال برنامج تشغيل ODBC. توفر مايكروسوفت جسرًا كهذا كجزء من حزمة مكونات نظام MDAC ، إلى جانب برامج تشغيل قواعد البيانات الأخرى، لتسهيل التطوير بلغة C# . كما طورت جهات خارجية جسورًا مماثلة، مثل جسر OpenLink ADO.NET-ODBC وجسر SequeLink ADO.NET-ODBC .