Возможность подключения к открытой базе данных

В вычислительной технике 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, и приложения можно переносить с одной платформы на другую с небольшими изменениями.

История

До ODBC

Появление мэйнфреймов на базе реляционной базы данных в 1970-х годах привело к распространению методов доступа к данным. Обычно эти системы работали вместе с простым командным процессором, который позволял пользователям вводить команды, подобные английским, и получать выходные данные. Наиболее известные примеры — SQL от IBM и QUEL из проекта Ingres . Эти системы могут разрешать или не разрешать другим приложениям прямой доступ к данным, а также тем, которые использовали самые разные методологии. Внедрение SQL было направлено на решение проблемы стандартизации языка , хотя существенные различия в реализации остались.

Поскольку язык SQL имел лишь элементарные возможности программирования, пользователи часто хотели использовать SQL в программе, написанной на другом языке, Фортране или C. например Это привело к появлению концепции встроенного SQL , которая позволила SQL код встроить в другой язык. Например, оператор SQL типа SELECT * FROM city может быть вставлен как текст в исходный код C, и во время компиляции он будет преобразован в собственный формат, который напрямую вызывает функцию в библиотеке , которая передает оператор в систему SQL. Результаты, возвращаемые операторами, будут интерпретированы обратно в форматы данных C, например char * используя аналогичный библиотечный код.

С подходом 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 язык доступа к данным . Однако гораздо более распространенными были системы, полностью работающие на микрокомпьютерах, включая полный стек протоколов , включающий любую необходимую поддержку сети или трансляции файлов.

Одним из первых примеров такой системы была Lotus Development от DataLens , первоначально известная как Blueprint. Blueprint, разработанный для 1-2-3, поддерживал множество источников данных, включая SQL/DS, DB2, FOCUS и множество подобных мэйнфреймов, а также микрокомпьютерные системы, такие как dBase и ранние разработки Microsoft/Ashton-Tate, которые в конечном итоге превратился в Microsoft SQL Server . В отличие от более позднего ODBC, Blueprint представляла собой чисто кодовую систему, в которой не было ничего похожего на командный язык, такой как SQL. Вместо этого программисты использовали структуры данных для хранения информации запроса, создавая запрос путем связывания многих из этих структур вместе. Lotus называл эти составные структуры деревьями запросов .

Примерно в то же время отраслевая группа, в которую входили представители Sybase (Том Хаггин), Tandem Computers ( Джим Грей и Рао Йендлури) и Microsoft (Кайл Гейгер), работала над концепцией стандартизированного динамического SQL. Большая часть системы была основана на системе DB-Library от Sybase, с удаленными разделами, специфичными для Sybase, и несколькими дополнениями для поддержки других платформ. DB-Library помог общеотраслевой переход от библиотечных систем, тесно связанных с определенным языком, к библиотечным системам, которые предоставлялись операционной системой и требовали, чтобы языки на этой платформе соответствовали ее стандартам. Это означало, что одну библиотеку можно было использовать (потенциально) с любым языком программирования на данной платформе.

Первый проект API доступа к данным Microsoft был опубликован в апреле 1989 года, примерно в то же время, когда Lotus анонсировала Blueprint. Несмотря на значительное лидерство Blueprint (он работал, когда MSDA еще был бумажным проектом), Lotus в конечном итоге присоединился к усилиям MSDA, поскольку стало ясно, что SQL станет фактическим стандартом баз данных. После значительного вклада отрасли летом 1989 года стандартом стал SQL Connectivity ( SQLC ).

SAG и CLI

В 1988 году несколько поставщиков, в основном из сообществ Unix и баз данных, сформировали SQL Access Group (SAG) в попытке создать единый базовый стандарт для языка SQL. На первой встрече разгорелись серьезные споры о том, следует ли работать исключительно над самим языком SQL или попытаться провести более широкую стандартизацию, которая включала бы также динамическую систему встраивания языка SQL, которую они назвали интерфейсом уровня вызовов (CLI). . Присутствуя на встрече с ранним проектом того, что тогда еще называлось MS Data Access, Кайл Гейгер из Microsoft пригласил Джеффа Балбони и Ларри Барнса из Digital Equipment Corporation (DEC) также присоединиться к собраниям SQLC. SQLC был потенциальным решением проблемы CLI, которую возглавляла DEC.

Новая «банда четырех» SQLC — MS, Tandem, DEC и Sybase — представила обновленную версию SQLC на следующем собрании SAG в июне 1990 года. В ответ SAG открыл стандартную программу для любого конкурирующего проекта, но из многих предложений только у Oracle Corp была система, представляющая серьезную конкуренцию. В конце концов, SQLC выиграл голоса и стал черновым стандартом, но только после того, как были удалены большие части API — за это время документ стандартов был урезан со 120 страниц до 50. Также в этот период было официально принято название «Интерфейс уровня вызова». В 1995 году SQL/CLI стал частью международного стандарта SQL ISO/IEC 9075-3. Сама SAG была передана группе X/Open в 1996 году и со временем стала частью The Open Group Common Application Environment .

MS продолжала работать с исходным стандартом SQLC, сохранив многие расширенные функции, которые были удалены из версии CLI. К ним относятся такие функции, как прокручиваемые курсоры и метаданных запросы . Команды API были разделены на группы; группа Core была идентична CLI, расширения уровня 1 представляли собой команды, которые можно было легко реализовать в драйверах, а команды уровня 2 содержали более продвинутые функции, такие как курсоры. Предлагаемый стандарт был выпущен в декабре 1991 года, а данные отрасли были собраны и использованы в системе до 1992 года, что привело к еще одному изменению названия на ODBC .

ДЖЕТ и ODBC

В это время 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.

Выпуск и дальнейшее развитие

ODBC 1.0 был выпущен в сентябре 1992 года. В то время прямая поддержка баз данных SQL (по сравнению с ISAM) была незначительной, а ранние драйверы отличались низкой производительностью. Отчасти это было неизбежно из-за пути, по которому вызовы проходили через стек на базе Jet; Вызовы ODBC к базам данных SQL сначала преобразовывались из диалекта SQL Simba Technologies во внутренний формат Jet на основе C, а затем передавались драйверу для преобразования обратно в вызовы SQL для базы данных. Digital Equipment и Oracle контракт также заключили с Simba Technologies на разработку драйверов для своих баз данных.

Примерно в 1993 году компания OpenLink Software выпустила один из первых независимо разработанных сторонних драйверов ODBC для СУБД PROGRESS . и вскоре последовал их SDK UDBC (кросс-платформенный API-эквивалент ODBC и SAG/CLI) и связанные драйверы для PROGRESS , Sybase, Oracle и других СУБД для использования в Unix-подобных ОС ( AIX , HP-UX , Solaris , Linux и т. д.), VMS , Windows NT , OS/2 и другие ОС.

Тем временем разработка стандарта CLI затянулась, и только в марте 1995 года окончательная версия была завершена. К тому времени Microsoft уже предоставила Visigenic Software лицензию на исходный код для разработки ODBC на платформах, отличных от Windows. Visigenic портировал ODBC на классическую Mac OS и широкий спектр платформ Unix, где ODBC быстро стал стандартом де-факто. «Настоящий» CLI сегодня встречается редко. Обе системы остаются схожими, и многие приложения можно переносить с ODBC на CLI с небольшими изменениями или без них.

Со временем поставщики баз данных взяли на себя интерфейсы драйверов и предоставили прямые ссылки на свои продукты. Пропуск промежуточных преобразований в Jet или аналогичные оболочки и обратно часто приводил к повышению производительности. Однако к тому времени Microsoft переключила внимание на свою OLE DB. концепция (недавно восстановлена ), что обеспечивало прямой доступ к более широкому спектру источников данных — от адресных книг до текстовых файлов. За этим последовало несколько новых систем, которые еще больше отвлекли свое внимание от ODBC, включая объекты данных ActiveX (ADO) и ADO.net , которые более или менее взаимодействовали с ODBC на протяжении всего своего существования.

Поскольку Microsoft отвлеклась от непосредственной работы над ODBC, область Unix все больше охватывала его. Этому способствовали два изменения на рынке: появление графических пользовательских интерфейсов (GUI), таких как GNOME , которые обеспечивали необходимость доступа к этим источникам в нетекстовой форме, и появление с открытым программным обеспечением, систем баз данных таких как PostgreSQL и MySQL , первоначально Юникс. Более позднее принятие ODBC компанией Apple для использования стандартного iODBC пакета на стороне Unix Mac OS X 10.2 (Jaguar) (которое OpenLink Software независимо предоставляло для Mac OS X 10.0 и даже Mac OS 9 с 2001 года). ) еще больше закрепил 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 , как способ позволить существующим инструментам выступать в качестве интерфейсов для этих механизмов для тестирования и отладки.

История версий

Спецификации ODBC

• 1.0: выпущен в сентябре 1992 г.
• 2.0: в. 1994 г.
• 2.5
• 3.0: в. В 1995 году Джон Гудсон из Intersolv, Фрэнк Пеллоу и Пол Коттон из IBM внесли значительный вклад в разработку ODBC 3.0.
• 3.5: в. 1997 год
• 3.8: в. 2009 г., с Windows 7
• 4.0: разработка объявлена ​​в июне 2016 г. с первой реализацией с SQL Server 2017, выпущенной в сентябре 2017 года, и дополнительными драйверами для настольных компьютеров, окончательная спецификация на Github в конце 2018 года.

Драйверы баз данных настольных компьютеров

• 1.0 (1993–08): использовался процессор запросов SIMBA, созданный PageAhead Software.
• 2.0 (1994–12): используется с ODBC 2.0.
• 3.0 (1995–10): поддерживает Windows 95 и рабочую станцию ​​Windows NT или NT Server 3.51. В этот выпуск были включены только 32-битные драйверы.
• 3.5 (1996–10): поддерживает двухбайтовый набор символов (DBCS) и позволяет использовать имена источников данных файлов (DSN). Драйвер Microsoft Access был выпущен в версии RISC для использования на платформах Alpha для операционных систем Windows 95/98 и Windows NT 3.51 и более поздних версий.
• 4.0 (конец 1998 г.): поддержка формата Unicode Microsoft Jet Engine, а также совместимость с форматом ANSI более ранних версий.

Водители и менеджеры

Драйверы

ODBC основан на модели драйвера устройства , где драйвер инкапсулирует логику, необходимую для преобразования стандартного набора команд и функций в конкретные вызовы, необходимые базовой системе. Например, драйвер принтера предоставляет стандартный набор команд печати (API) приложениям, использующим систему печати. Вызовы этих API преобразуются драйвером в формат, используемый реальным оборудованием, например PostScript или PCL .

В случае ODBC драйверы инкапсулируют множество функций, которые можно разбить на несколько широких категорий. Один набор функций в первую очередь связан с поиском, подключением и отключением от СУБД, с которой общается драйвер. Второй набор используется для отправки команд SQL из системы ODBC в СУБД, преобразования или интерпретации любых команд, которые не поддерживаются внутри. Например, СУБД, не поддерживающая курсоры, может эмулировать эту функциональность в драйвере. Наконец, другой набор команд, в основном используемый внутри компании, используется для преобразования данных из внутренних форматов СУБД в набор стандартизированных форматов ODBC, основанных на форматах языка C.

Драйвер ODBC позволяет ODBC-совместимому приложению использовать источник данных , обычно СУБД. Некоторые драйверы, не относящиеся к СУБД, существуют для таких источников данных, как файлы CSV , путем реализации небольшой СУБД внутри самого драйвера. Драйверы ODBC существуют для большинства СУБД, включая Oracle , PostgreSQL , MySQL , Microsoft SQL Server (но не для версии Compact, известной как CE ), Mimer SQL , Sybase ASE , SAP HANA. и IBM Db2 . Поскольку разные технологии имеют разные возможности, большинство драйверов ODBC не реализуют все функции, определенные в стандарте ODBC. Некоторые драйверы предлагают дополнительные функции, не определенные стандартом.

Менеджер драйверов

Драйверы устройств обычно перечисляются, настраиваются и управляются отдельным уровнем диспетчера, который может предоставлять дополнительные функции. Например, системы печати часто включают в себя функцию буферизации поверх драйверов, обеспечивая буферизацию печати для любого поддерживаемого принтера.

В ODBC эти функции предоставляет диспетчер драйверов (DM). 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 для подключения к базе данных. Этот драйвер преобразует вызовы функций ODBC в вызовы методов JDBC. Программисты обычно используют такой мост, когда у них нет драйвера ODBC для какой-либо базы данных, но есть доступ к драйверу JDBC. Примеры: OpenLink ODBC-JDBC Bridge , SequeLink ODBC-JDBC Bridge .

Мосты JDBC-ODBC (JDBC-ODBC)

Мост JDBC-ODBC состоит из драйвера JDBC , который использует драйвер ODBC для подключения к целевой базе данных. Этот драйвер преобразует вызовы методов JDBC в вызовы функций ODBC. Программисты обычно используют такой мост, когда в данной базе данных отсутствует драйвер JDBC, но она доступна через драйвер ODBC. Sun Microsystems включила один такой мост в JVM , но рассматривала его как временную меру, пока существовало мало драйверов JDBC (встроенный мост JDBC-ODBC был исключен из JVM в Java 8). ). 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. Программисты обычно используют такой мост, когда у данной базы данных нет поставщика OLE DB, но она доступна через драйвер ODBC. Microsoft поставляет один из них, MSDASQL.DLL, как часть пакета MDAC системных компонентов вместе с другими драйверами баз данных, чтобы упростить разработку на языках, поддерживающих COM (например, Visual Basic ). Третьи стороны также разработали такие технологии, в частности OpenLink Software, чей 64-битный поставщик OLE DB для источников данных ODBC заполнил пробел, когда Microsoft изначально отказалась от этого моста для своей 64-битной ОС. (Позже 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. Программисты обычно используют такой мост, когда у данной базы данных нет поставщика ADO.NET, но она доступна через драйвер ODBC. Microsoft поставляет один из них как часть MDAC пакета системных компонентов вместе с другими драйверами баз данных, чтобы упростить разработку на C# . Третьи стороны также разработали такие. Примеры: OpenLink ADO.NET-ODBC Bridge , SequeLink ADO.NET-ODBC Bridge .

См. также

• Доступ к данным GNU
• Подключение к базе данных Java (JDBC)
• Архитектура открытых служб Windows
• Администратор ODBC

Ссылки

Библиография

• Гейгер, Кайл (1995). Внутри ODBC . Майкрософт Пресс. ISBN  9781556158155 .

Цитаты

Внешние ссылки

• Обзор Microsoft ODBC
• Администрирование IBM i ODBC
• Слайды презентации с сайта www.roth.net
• Статья об истории Microsoft ODBC и API доступа к данным .
• Страница Github: Спецификация Microsoft ODBC 4.0