В вычислительной технике 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 в программе, написанной на другом языке, например Fortran или C. Это привело к концепции Embedded SQL , которая позволяла встраивать код SQL в другой язык. Например, оператор SQL, например, можно было вставить как текст в исходный код C, и во время компиляции он преобразовывался в пользовательский формат, который напрямую вызывал функцию в библиотеке , которая передавала оператор в систему SQL. Результаты, возвращаемые операторами, интерпретировались обратно в форматы данных C, например, с использованием аналогичного библиотечного кода.SELECT * FROM citychar *
Было несколько проблем с подходом Embedded SQL. Как и различные разновидности SQL, Embedded SQL, которые их использовали, сильно различались не только от платформы к платформе, но даже между языками на одной платформе — система, которая допускала вызовы в IBM Db2 , выглядела бы совсем иначе, чем система, которая вызывала их собственный SQL/DS . [ сомнительно — обсудить ] Еще одной ключевой проблемой концепции Embedded 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 способствовал общеотраслевой переход от библиотечных систем, которые были тесно связаны с определенным языком, к библиотечным системам, которые предоставлялись операционной системой и требовали, чтобы языки на этой платформе соответствовали ее стандартам. Это означало, что одна библиотека могла использоваться с (потенциально) любым языком программирования на данной платформе.
Первый проект Microsoft Data Access API был опубликован в апреле 1989 года, примерно в то же время, когда Lotus объявила о Blueprint. [4] Несмотря на большое лидерство Blueprint — он был запущен, когда MSDA был еще бумажным проектом — Lotus в конечном итоге присоединилась к усилиям MSDA, поскольку стало ясно, что SQL станет фактическим стандартом баз данных. [2] После значительного участия отрасли летом 1989 года стандарт стал SQL Connectivity ( SQLC ). [5]
В 1988 году несколько поставщиков, в основном из сообществ Unix и баз данных, сформировали SQL Access Group (SAG) в попытке создать единый базовый стандарт для языка SQL. На первой встрече были серьезные дебаты о том, должны ли усилия работать исключительно над самим языком SQL или попытаться провести более широкую стандартизацию, которая включала бы также динамическую систему встраивания языка SQL, которую они назвали Call Level Interface (CLI). [6] Присутствуя на встрече с ранним проектом того, что тогда еще было известно как MS Data Access, Кайл Гейгер из Microsoft пригласил Джеффа Бальбони и Ларри Барнса из Digital Equipment Corporation (DEC) присоединиться к встречам SQLC. SQLC был потенциальным решением для призыва к CLI, который возглавляла DEC.
Новая «банда из четырех» SQLC, MS, Tandem, DEC и Sybase, представила обновленную версию SQLC на следующем заседании SAG в июне 1990 года. [7] SAG ответила открытием стандарта для любых конкурирующих проектов, но из многих предложений только у Oracle Corp была система, которая представляла серьезную конкуренцию. В конце концов, SQLC выиграл голоса и стал проектом стандарта, но только после того, как были удалены большие части API — документ стандартов был сокращен со 120 страниц до 50 в это время. Также в этот период было официально принято название Call Level Interface. [7] В 1995 году SQL/CLI стал частью международного стандарта SQL, ISO/IEC 9075-3. [8] Сама SAG была передана группе X/Open в 1996 году и со временем стала частью Common Application Environment группы 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] , а вскоре последовал их 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 Data Objects (ADO) и ADO.net , которые в той или иной степени взаимодействовали с ODBC на протяжении своего жизненного цикла.
Поскольку Microsoft отвлеклась от работы непосредственно над ODBC, область Unix все больше охватывала его. Этому способствовали два изменения на рынке: введение графических пользовательских интерфейсов (GUI), таких как GNOME , которые обеспечивали необходимость доступа к этим источникам в нетекстовой форме, и появление открытых систем баз данных программного обеспечения, таких как PostgreSQL и MySQL , изначально под Unix. Более позднее принятие 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 edition ), Mimer SQL , Sybase ASE , SAP HANA [28] [29] и IBM Db2 . Поскольку разные технологии имеют разные возможности, большинство драйверов ODBC не реализуют все функции, определенные в стандарте ODBC. Некоторые драйверы предлагают дополнительные функции, не определенные стандартом.
Драйверы устройств обычно перечисляются, настраиваются и управляются отдельным слоем Manager, который может предоставлять дополнительную функциональность. Например, системы печати часто включают функциональность для предоставления функции спулинга поверх драйверов, обеспечивая спулинг печати для любого поддерживаемого принтера.
В 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, мост SequeLink JDBC-ODBC, мост ZappySys JDBC-ODBC.
Мост 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, мост SequeLink OLEDB-ODBC.
Мост ADO.NET-ODBC состоит из поставщика ADO.NET , который использует службы драйвера ODBC для подключения к целевой базе данных. Этот поставщик транслирует вызовы методов ADO.NET в вызовы функций ODBC. Программисты обычно используют такой мост, когда в данной базе данных отсутствует поставщик ADO.NET, но она доступна через драйвер ODBC. Microsoft поставляет один как часть системного компонента MDAC вместе с другими драйверами баз данных для упрощения разработки на C# . Третьи стороны также разработали такие. Примеры: OpenLink ADO.NET-ODBC Bridge, SequeLink ADO.NET-ODBC Bridge.
Первые драйверы ODBC […] использовали процессор запросов SIMBA, который преобразовывал вызовы в вызовы Microsoft Jet ISAM и направлял вызовы соответствующему драйверу ISAM для доступа к бэкэнду […]
ODBC 1.0 был выпущен в сентябре 1992 г.
Windows 7 включает обновленную версию ODBC, ODBC 3.8.
Спустя более 15 лет с момента последнего выпуска Microsoft рассматривает возможность обновления спецификации Open Data Base Connectivity (ODBC).