Открытое подключение к базе данных - Open Database Connectivity

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

История

До ODBC

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

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

Было несколько проблем с подходом Embedded SQL. Как различные разновидности SQL, встроенного SQLs , которые использовали их сильно различались, а не только с платформы на платформу, но даже через языки на одной платформе - это система , которая позволила вызовы в IBM «s 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 Architecture ( DRDA ) и компании Apple Computer «s доступа к данным языка . Однако гораздо более распространенными были системы, которые полностью работали на микрокомпьютерах, включая полный стек протоколов, который включал любую необходимую поддержку сети или трансляции файлов.

Одним из первых примеров такой системы был Lotus Development «s 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. Большая часть системы была основана на системе Sybase DB-Library с удаленными разделами, специфичными для Sybase, и несколькими дополнениями для поддержки других платформ. DB-Library способствовал общеотраслевой переход от библиотечных систем, которые были тесно связаны с конкретным языком, к библиотечным системам, которые были предоставлены операционной системой и требовали, чтобы языки на этой платформе соответствовали ее стандартам. Это означало, что одну библиотеку можно было использовать (потенциально) с любым языком программирования на данной платформе.

Первый черновик Microsoft Data Access API был опубликован в апреле 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 страниц. Также в этот период было официально принято название Call Level Interface. В 1995 году SQL / CLI стал частью международного стандарта SQL ISO / IEC 9075-3. Сам SAG был захвачен X / Open группы в 1996 году, и, со временем, стал частью Open Group «s Common Application окружающей среды .

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

JET и ODBC

В это время Microsoft занималась разработкой своей системы баз данных Jet . Jet объединил три основные подсистемы; ISAM основанное ядро базы данных (также названный Джет , смешения), интерфейс C-основе позволяет приложениям получать доступ к этим данным и выбор драйвера динамически подключаемых библиотек (DLL) , что позволило один и тот же интерфейс C для ввода и вывода Перенаправление на другие базы данных на основе ISAM, такие как Paradox и xBase . Jet позволял использовать один набор вызовов для доступа к общим базам данных микрокомпьютеров аналогично Blueprint, к тому времени переименованному в DataLens. Однако Jet не использовал SQL; как и DataLens, интерфейс был на C и состоял из структур данных и вызовов функций.

Усилия по стандартизации SAG предоставили Microsoft возможность адаптировать свою систему Jet к новому стандарту CLI. Это не только сделает Windows ведущей платформой для разработки интерфейса командной строки, но также позволит пользователям использовать 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 во внутренний C-формат Jet, а затем передавались драйверу для обратного преобразования в вызовы 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 , первоначально под управлением Unix. Позднее внедрение 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 остается широко используемым сегодня, с драйверами, доступными для большинства платформ и большинства баз данных. Нередко можно найти драйверы ODBC для механизмов баз данных, которые предназначены для встраивания, например SQLite , как способ, позволяющий существующим инструментам выступать в качестве внешних интерфейсов для этих механизмов для тестирования и отладки.

Однако рост числа тонких клиентов, использующих HTML в качестве промежуточного формата, снизил потребность в ODBC. Многие платформы веб-разработки содержат прямые ссылки на целевые базы данных - MySQL является очень распространенным явлением. В этих сценариях нет прямого доступа на стороне клиента или поддержки нескольких клиентских программных систем; все проходит через предоставленное программистом HTML-приложение. Виртуализация, которую предлагает ODBC, больше не является серьезным требованием, и разработка ODBC уже не так активна, как раньше. Но хотя ODBC больше не является сильным требованием для программирования клиент-сервер, теперь он более важен для доступа, виртуализации и интеграции в сценарии аналитики и обработки данных. Эти новые требования отражены в новых функциях ODBC 4.0, таких как полуструктурированные и иерархические данные, веб-аутентификация и повышение производительности.

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

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

  • 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 года, и дополнительными драйверами для настольных ПК в конце 2018 года, окончательная спецификация на Github

Драйверы и менеджеры

Драйверы

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

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

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

Диспетчер драйверов

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

В ODBC диспетчер драйверов (DM) предоставляет эти функции. DM может перечислить установленные драйверы и представить их в виде списка, часто в форме графического интерфейса.

Но более важным для работы системы ODBC является концепция имени источника данных (DSN) DM . 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 мост , 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, чей 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 .

Смотрите также

использованная литература

Библиография
  • Гейгер, Кайл (1995). Внутри ODBC . Microsoft Press. ISBN 9781556158155.
Цитаты

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