В вычислительной технике Open Database Connectivity ( ODBC ) — это стандартный интерфейс прикладного программирования (API) для доступа к системам управления базами данных (СУБД). Разработчики ODBC стремились сделать его независимым от систем баз данных и операционных систем . [ нужна цитация ] Приложение, написанное с использованием ODBC, может быть перенесено на другие платформы, как на стороне клиента, так и на стороне сервера, с небольшими изменениями в коде доступа к данным.
ODBC обеспечивает независимость от СУБД, используя драйвер ODBC в качестве уровня трансляции между приложением и СУБД. Приложение использует функции ODBC через менеджер драйверов ODBC , с которым оно связано, и драйвер передает запрос в СУБД. Драйвер ODBC можно рассматривать как аналог драйвера принтера или другого драйвера, предоставляющий стандартный набор функций для использования приложением и реализующий функциональные возможности, специфичные для СУБД. Приложение, которое может использовать ODBC, называется «ODBC-совместимым». Любое ODBC-совместимое приложение может получить доступ к любой СУБД, для которой установлен драйвер. Драйверы существуют для всех основных СУБД, многих других источников данных, таких как системы адресных книг и Microsoft Excel , и даже для текстовых файлов или файлов со значениями, разделенными запятыми (CSV).
ODBC был первоначально разработан Microsoft и Simba Technologies в начале 1990-х годов и стал основой для интерфейса уровня вызовов (CLI), стандартизированного группой SQL Access Group в области Unix и мэйнфреймов . ODBC сохранил несколько функций, которые были удалены в рамках CLI. Позже полный ODBC был перенесен обратно на эти платформы и стал стандартом де-факто, значительно более известным, чем CLI. CLI остается похожим на ODBC, и приложения можно переносить с одной платформы на другую с небольшими изменениями.
Появление реляционной базы данных на базе мэйнфреймов в 1970-х годах привело к распространению методов доступа к данным. Обычно эти системы работали вместе с простым командным процессором, который позволял пользователям вводить команды, подобные английским, и получать выходные данные. Наиболее известные примеры — SQL от IBM и QUEL из проекта Ingres . Эти системы могут разрешать или не разрешать другим приложениям прямой доступ к данным, а также тем, которые использовали самые разные методологии. Внедрение SQL было направлено на решение проблемы стандартизации языка , хотя существенные различия в реализации остались.
Поскольку язык SQL имел лишь элементарные возможности программирования, пользователи часто хотели использовать SQL в программе, написанной на другом языке, например Фортране или C. Это привело к появлению концепции встроенного SQL , которая позволила встроить код SQL в другой язык. Например, оператор SQL вроде может быть вставлен как текст в исходный код C, и во время компиляции он будет преобразован в специальный формат, который напрямую вызывает функцию в библиотеке , которая передает оператор в систему SQL. Результаты, возвращаемые операторами, будут интерпретированы обратно в форматы данных C, например, с использованием аналогичного библиотечного кода.SELECT * FROM citychar *
С подходом Embedded SQL было несколько проблем. Как и различные разновидности SQL, встроенные SQL-коды, в которых они использовались, сильно различались не только от платформы к платформе, но даже в разных языках на одной платформе — система, которая позволяла обращаться к IBM Db2 , сильно отличалась от той, которая вызывала их собственную. SQL/DS . [ сомнительно ] Другая ключевая проблема концепции встроенного SQL заключалась в том, что код SQL можно было изменить только в исходном коде программы, поэтому даже небольшие изменения в запросе требовали значительных усилий программиста для внесения изменений. Рынок SQL называл это статическим SQL , в отличие от динамического SQL , который можно было изменить в любое время, например, интерфейсы командной строки , поставляемые почти со всеми системами SQL, или интерфейс программирования, который оставлял SQL в виде обычного текста до тех пор, пока он не был вызван. . Системы динамического SQL стали основным направлением деятельности поставщиков SQL в 1980-х годах.
Старые базы данных мэйнфреймов и новые системы на базе микрокомпьютеров , основанные на них, обычно не имели SQL-подобного командного процессора между пользователем и ядром базы данных. Вместо этого программа имела прямой доступ к данным – программную библиотеку в случае больших мэйнфреймов или интерфейс командной строки или систему интерактивных форм в случае dBASE и подобных приложений. К данным из dBASE обычно не могли получить прямой доступ другие программы, работающие на машине. Этим программам может быть предоставлен доступ к этим данным, часто через библиотеки, но он не будет работать с каким-либо другим ядром базы данных или даже с другими базами данных в одном и том же механизме. По сути, все такие системы были статичными, что представляло значительные проблемы.
К середине 1980-х годов быстрое развитие микрокомпьютеров и особенно появление графического пользовательского интерфейса и прикладных программ с большим объемом данных, таких как Lotus 1-2-3 , привело к возрастанию интереса к использованию персональных компьютеров в качестве предпочтительной клиентской платформы. в клиент-серверных вычислениях. В соответствии с этой моделью большие мэйнфреймы и миникомпьютеры будут использоваться в первую очередь для передачи данных по локальным сетям на микрокомпьютеры, которые будут интерпретировать, отображать и манипулировать этими данными. Чтобы эта модель работала, требовался стандарт доступа к данным: в области мэйнфреймов весьма вероятно, что все компьютеры в магазине были от одного поставщика, а клиентами были компьютерные терминалы , говорящие с ними напрямую, но в микрообласти такой стандартизации не было, и любой клиент мог получить доступ к любому серверу, используя любую сетевую систему.
К концу 1980-х годов предпринималось несколько попыток создать для этой цели уровень абстракции. Некоторые из них были связаны с мэйнфреймами и предназначены для того, чтобы позволить программам, работающим на этих машинах, преобразовывать различные SQL-коды и обеспечивать единый общий интерфейс, который затем мог быть вызван другими программами для мэйнфреймов или микрокомпьютеров. Эти решения включали в себя архитектуру распределенных реляционных баз данных IBM ( DRDA ) и язык доступа к данным Apple Computer . Однако гораздо более распространенными были системы, полностью работающие на микрокомпьютерах, включая полный стек протоколов , включающий любую необходимую поддержку сети или трансляции файлов.
Одним из первых примеров такой системы была DataLens от Lotus Development , первоначально известная как Blueprint. Blueprint, разработанный для 1-2-3, поддерживал множество источников данных, включая SQL/DS, DB2, FOCUS и множество подобных мэйнфреймов, а также микрокомпьютерные системы, такие как dBase и ранние разработки Microsoft/Ashton-Tate, которые в конечном итоге превратился в Microsoft SQL Server . [1] В отличие от более позднего ODBC, Blueprint была чисто кодовой системой, в которой не было ничего похожего на командный язык, такой как SQL. Вместо этого программисты использовали структуры данных для хранения информации запроса, создавая запрос путем связывания многих из этих структур вместе. Lotus называл эти составные структуры деревьями запросов . [2]
Примерно в то же время отраслевая группа, в которую входили представители Sybase (Том Хаггин), Tandem Computers ( Джим Грей и Рао Йендлури) и Microsoft (Кайл Гейгер), работала над концепцией стандартизированного динамического SQL. Большая часть системы была основана на системе DB-Library от Sybase, с удаленными разделами, специфичными для Sybase, и несколькими дополнениями для поддержки других платформ. [3] DB-Library помог общеотраслевой переход от библиотечных систем, которые были тесно связаны с конкретным языком, к библиотечным системам, которые предоставлялись операционной системой и требовали, чтобы языки на этой платформе соответствовали ее стандартам. Это означало, что одну библиотеку можно было использовать (потенциально) с любым языком программирования на данной платформе.
Первый проект API доступа к данным Microsoft был опубликован в апреле 1989 года, примерно в то же время, когда Lotus анонсировала Blueprint. [4] Несмотря на большое лидерство Blueprint – он работал, когда MSDA еще был бумажным проектом – Lotus в конечном итоге присоединился к усилиям MSDA, поскольку стало ясно, что SQL станет фактическим стандартом баз данных. [2] После значительного вклада отрасли летом 1989 года стандартом стал SQL Connectivity ( SQLC ). [5]
В 1988 году несколько поставщиков, в основном из сообществ Unix и баз данных, сформировали группу доступа SQL (SAG) в попытке создать единый базовый стандарт для языка SQL. На первой встрече разгорелись серьезные споры о том, следует ли работать исключительно над самим языком SQL или попытаться провести более широкую стандартизацию, включающую также динамическую систему встраивания языка SQL, которую они назвали интерфейсом уровня вызовов (CLI). . [6] Присутствуя на встрече с ранним проектом того, что тогда еще называлось MS Data Access, Кайл Гейгер из Microsoft пригласил Джеффа Балбони и Ларри Барнса из Digital Equipment Corporation (DEC) также присоединиться к собраниям SQLC. SQLC был потенциальным решением проблемы CLI, которую возглавляла DEC.
Новая «банда четырех» SQLC, MS, Tandem, DEC и Sybase, представила обновленную версию SQLC на следующем собрании SAG в июне 1990 года . среди множества предложений только у Oracle Corp была система, которая представляла собой серьезную конкуренцию. В конце концов, SQLC выиграл голоса и стал черновиком стандарта, но только после того, как были удалены большие части API — за это время документ стандартов был урезан со 120 страниц до 50. Также в этот период было официально принято название «Интерфейс уровня вызова». [7] В 1995 году SQL/CLI стал частью международного стандарта SQL ISO/IEC 9075-3. [8] Сама SAG была передана группе X/Open в 1996 году и со временем стала частью Common Application Environment The Open Group .
MS продолжала работать с исходным стандартом SQLC, сохранив многие расширенные функции, которые были удалены из версии CLI. К ним относятся такие функции, как прокручиваемые курсоры и запросы метаданных . Команды API были разделены на группы; группа Core была идентична CLI, расширения уровня 1 представляли собой команды, которые можно было легко реализовать в драйверах, а команды уровня 2 содержали более продвинутые функции, такие как курсоры. Предлагаемый стандарт был выпущен в декабре 1991 года, а данные отрасли были собраны и использованы в системе до 1992 года, что привело к еще одному изменению названия на ODBC . [9]
В это время Microsoft находилась в процессе разработки своей системы баз данных Jet . Jet объединил три основные подсистемы; механизм базы данных на основе ISAM (также называемый Jet , что сбивает с толку), интерфейс на основе C, позволяющий приложениям получать доступ к этим данным, и набор библиотек динамической компоновки драйверов (DLL), которые позволяли одному и тому же интерфейсу C перенаправлять ввод и вывод в другие базы данных на базе ISAM, такие как Paradox и xBase . Jet позволял использовать один набор вызовов для доступа к общим базам данных микрокомпьютеров аналогично Blueprint, к тому времени переименованному в DataLens. Однако Jet не использовал SQL; как и в DataLens, интерфейс был написан на языке C и состоял из структур данных и вызовов функций.
Усилия SAG по стандартизации предоставили Microsoft возможность адаптировать свою систему Jet к новому стандарту CLI. Это не только сделает Windows лучшей платформой для разработки CLI, но и позволит пользователям использовать SQL для доступа как к Jet, так и к другим базам данных. Чего не хватало, так это анализатора SQL, который мог бы преобразовывать эти вызовы из их текстовой формы в C-интерфейс, используемый в Jet. Чтобы решить эту проблему, MS заключила партнерское соглашение с PageAhead Software и использовала существующий процессор запросов SIMBA. SIMBA использовалась в качестве анализатора над библиотекой C Jet, превращая Jet в базу данных SQL. А поскольку Jet мог перенаправлять вызовы на основе C в другие базы данных, это также позволяло SIMBA запрашивать другие системы. Microsoft включила драйверы для Excel, позволяющие превращать документы электронных таблиц в таблицы базы данных, доступные для SQL. [10]
ODBC 1.0 был выпущен в сентябре 1992 года. [11] В то время прямая поддержка баз данных SQL (по сравнению с ISAM) была незначительной, а ранние драйверы отличались низкой производительностью. Частично это было неизбежно из-за пути, по которому вызовы проходили через стек на базе Jet; Вызовы ODBC к базам данных SQL сначала конвертировались из диалекта SQL Simba Technologies во внутренний формат Jet на основе C, а затем передавались драйверу для преобразования обратно в вызовы SQL для базы данных. Digital Equipment и Oracle также заключили с Simba Technologies контракт на разработку драйверов для своих баз данных. [12]
Примерно в 1993 году компания OpenLink Software поставила один из первых независимо разработанных сторонних драйверов ODBC для СУБД PROGRESS [13] , а вскоре за ней последовал SDK UDBC (кросс-платформенный API-эквивалент ODBC и SAG/CLI) и связанный с ним пакет SDK. драйверы для PROGRESS , Sybase, Oracle и других СУБД, для использования в Unix-подобных ОС ( AIX , HP-UX , Solaris , Linux и т. д.), VMS , Windows NT , OS/2 и других ОС. [14]
Тем временем разработка стандарта CLI затянулась, и только в марте 1995 года окончательная версия была завершена. К тому времени Microsoft уже предоставила Visigenic Software лицензию на исходный код для разработки ODBC на платформах, отличных от Windows. Visigenic портировал ODBC на классическую Mac OS и широкий спектр платформ Unix, где ODBC быстро стал стандартом де-факто. [15] «Настоящий» CLI сегодня встречается редко. Обе системы остаются схожими, и многие приложения можно переносить с ODBC на CLI с небольшими изменениями или без них. [16]
Со временем поставщики баз данных взяли на себя интерфейсы драйверов и предоставили прямые ссылки на свои продукты. Пропуск промежуточных преобразований в Jet или аналогичные оболочки и обратно часто приводил к повышению производительности. Однако к тому времени Microsoft переключила внимание на свою концепцию OLE DB [17] (недавно восстановленную [18] ), которая обеспечивала прямой доступ к более широкому спектру источников данных — от адресных книг до текстовых файлов. За этим последовало несколько новых систем, которые еще больше отвлекли свое внимание от ODBC, включая объекты данных ActiveX (ADO) и ADO.net , которые более или менее взаимодействовали с ODBC на протяжении всего своего существования.
Поскольку Microsoft отвлеклась от непосредственной работы над ODBC, область Unix все больше охватывала его. Этому способствовали два изменения на рынке: появление графических пользовательских интерфейсов (GUI), таких как GNOME , которые обеспечивали необходимость доступа к этим источникам в нетекстовой форме, и появление систем баз данных с открытым программным обеспечением, таких как PostgreSQL и MySQL , первоначально Юникс. Более позднее принятие ODBC компанией Apple для использования стандартного пакета iODBC на стороне Unix Mac OS X 10.2 (Jaguar) [19] (который OpenLink Software независимо предоставляла для Mac OS X 10.0 и даже Mac OS 9 с 2001 года [20] ). еще больше закрепил ODBC в качестве стандарта кросс-платформенного доступа к данным.
Sun Microsystems использовала систему ODBC в качестве основы для своего собственного открытого стандарта Java Database Connectivity (JDBC). Во многих отношениях JDBC можно рассматривать как версию ODBC для языка программирования Java вместо C. Мосты JDBC-ODBC позволяют программам на основе Java получать доступ к источникам данных через драйверы ODBC на платформах, на которых отсутствует собственный драйвер JDBC, хотя сейчас они встречаются относительно редко. И наоборот, мосты ODBC-JDBC позволяют программам на основе C получать доступ к источникам данных через драйверы JDBC на платформах или из баз данных, в которых отсутствуют подходящие драйверы ODBC.
ODBC по-прежнему широко используется и сегодня, драйверы доступны для большинства платформ и большинства баз данных. Нередко можно найти драйверы ODBC для механизмов баз данных, которые предназначены для встраивания, например SQLite , как способ позволить существующим инструментам выступать в качестве интерфейсов для этих механизмов для тестирования и отладки. [21]
ODBC основан на модели драйвера устройства , где драйвер инкапсулирует логику, необходимую для преобразования стандартного набора команд и функций в конкретные вызовы, необходимые базовой системе. Например, драйвер принтера предоставляет стандартный набор команд печати (API) приложениям, использующим систему печати. Вызовы этих API преобразуются драйвером в формат, используемый реальным оборудованием, например PostScript или PCL .
В случае ODBC драйверы инкапсулируют множество функций, которые можно разбить на несколько широких категорий. Один набор функций в первую очередь связан с поиском, подключением и отключением от СУБД, с которой общается драйвер. Второй набор используется для отправки команд SQL из системы ODBC в СУБД, преобразования или интерпретации любых команд, которые не поддерживаются внутри. Например, СУБД, не поддерживающая курсоры , может эмулировать эту функциональность в драйвере. Наконец, другой набор команд, в основном используемый внутри компании, используется для преобразования данных из внутренних форматов СУБД в набор стандартизированных форматов ODBC, основанных на форматах языка C.
Драйвер ODBC позволяет ODBC-совместимому приложению использовать источник данных , обычно СУБД. Некоторые драйверы, не относящиеся к СУБД, существуют для таких источников данных, как файлы CSV , путем реализации небольшой СУБД внутри самого драйвера. Драйверы ODBC существуют для большинства СУБД, включая Oracle , PostgreSQL , MySQL , Microsoft SQL Server (но не для версии Compact, известной как CE ), Sybase ASE , SAP HANA [28] [29] и IBM Db2 . Поскольку разные технологии имеют разные возможности, большинство драйверов ODBC не реализуют все функции, определенные в стандарте ODBC. Некоторые драйверы предлагают дополнительные функции, не определенные стандартом.
Драйверы устройств обычно перечисляются, настраиваются и управляются отдельным уровнем диспетчера, который может предоставлять дополнительные функции. Например, системы печати часто включают в себя функцию буферизации поверх драйверов, обеспечивая буферизацию печати для любого поддерживаемого принтера.
В ODBC эти функции предоставляет диспетчер драйверов (DM). [30] DM может перечислить установленные драйверы и представить их в виде списка, часто в форме графического интерфейса.
Но более важным для работы системы ODBC является концепция DM имени источника данных (DSN). DSN собирают дополнительную информацию, необходимую для подключения к конкретному источнику данных, а не к самой СУБД. Например, один и тот же драйвер MySQL можно использовать для подключения к любому серверу MySQL, но информация о соединении для подключения к локальному частному серверу отличается от информации, необходимой для подключения к общедоступному серверу, размещенному в Интернете. DSN хранит эту информацию в стандартизированном формате, а DM предоставляет ее драйверу во время запросов на соединение. DM также включает в себя функциональные возможности для представления списка DSN с использованием удобочитаемых имен и выбора их во время выполнения для подключения к различным ресурсам.
DM также включает в себя возможность сохранять частично полные DSN с кодом и логикой, позволяющей запрашивать у пользователя любую недостающую информацию во время выполнения. Например, DSN можно создать без обязательного пароля. Когда приложение ODBC попытается подключиться к СУБД с помощью этого DSN, система приостановит работу и попросит пользователя ввести пароль, прежде чем продолжить. Это освобождает разработчика приложения от необходимости создавать такого рода код, а также от необходимости знать, какие вопросы задавать. Все это включено в драйвер и 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 Bridge, SequeLink JDBC-ODBC Bridge.
Мост OLE DB-ODBC состоит из поставщика OLE DB , который использует службы драйвера ODBC для подключения к целевой базе данных. Этот поставщик преобразует вызовы методов OLE DB в вызовы функций ODBC. Программисты обычно используют такой мост, когда у данной базы данных нет поставщика OLE DB, но она доступна через драйвер ODBC. Microsoft поставляет один из них, MSDASQL.DLL, как часть пакета системных компонентов MDAC вместе с другими драйверами баз данных, чтобы упростить разработку на языках, поддерживающих COM (например, Visual Basic ). Третьи стороны также разработали такие технологии, в частности OpenLink Software, чей 64-битный поставщик OLE DB для источников данных ODBC заполнил пробел, когда Microsoft изначально отказалась от этого моста для своей 64-битной ОС. [32] (Позже Microsoft уступила, и 64-битные версии Windows, начиная с Windows Server 2008 и Windows Vista SP1 , поставлялись с 64-битной версией MSDASQL.) Примеры: OpenLink OLEDB-ODBC Bridge, SequeLink OLEDB-ODBC Bridge.
Мост ADO.NET-ODBC состоит из поставщика ADO.NET , который использует службы драйвера ODBC для подключения к целевой базе данных. Этот поставщик преобразует вызовы методов ADO.NET в вызовы функций ODBC. Программисты обычно используют такой мост, когда у данной базы данных нет поставщика ADO.NET, но она доступна через драйвер ODBC. Microsoft поставляет один из них как часть пакета системных компонентов MDAC вместе с другими драйверами баз данных, чтобы упростить разработку на C# . Третьи стороны также разработали такие. Примеры: мост OpenLink ADO.NET-ODBC, мост SequeLink ADO.NET-ODBC.
Первые драйверы ODBC […] использовали процессор запросов SIMBA, который преобразовывал вызовы в вызовы Microsoft Jet ISAM и отправлял вызовы соответствующему драйверу ISAM для доступа к серверной части […]
ODBC 1.0 был выпущен в сентябре 1992 года.
Windows 7 включает обновленную версию ODBC — ODBC 3.8.
Спустя более 15 лет с момента последнего выпуска Microsoft рассматривает возможность обновления спецификации Open Data Base Connectivity (ODBC).