ODBC: Стандарт доступа к базам данных

Введение

ODBC, стандартный интерфейс для доступа к системам баз данных. В вычислительной технике 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 внутри программы, написанной на другом языке, например, Fortran или C. Это привело к концепции встроенного SQL, которая позволяла встраивать код SQL в другой язык. Например, SQL-запрос, такой как SELECT * FROM city, можно было вставить в исходный код C в виде текста, и во время компиляции он преобразовывался бы в специальный формат, который напрямую вызывал функцию в библиотеке, передающую запрос в систему SQL. Результаты, возвращаемые запросом, интерпретировались бы обратно в форматы данных C, такие как char *, с использованием аналогичного библиотечного кода. Подход встроенного SQL имел несколько проблем. Как и различные варианты SQL, встроенные SQL, использующие их, значительно различались не только между платформами, но даже между языками на одной платформе – система, вызывающая IBM Db2, выглядела бы совершенно иначе, чем система, вызывающая их собственный SQL/DS. Еще одной ключевой проблемой концепции встроенного SQL было то, что код SQL можно было изменить только в исходном коде программы, поэтому даже небольшие изменения в запросе требовали значительных усилий программиста для внесения. Рынок SQL называл это статическим SQL, в отличие от динамического SQL, который можно было изменять в любое время, как, например, интерфейсы командной строки, поставляемые почти со всеми системами SQL, или программный интерфейс, оставляющий SQL в виде обычного текста до момента вызова. Динамический SQL стал основным направлением развития для поставщиков SQL в 1980-х годах. Более старые базы данных мейнфреймов и новые системы на основе микрокомпьютеров, созданные на их основе, как правило, не имели командного процессора, похожего на SQL, между пользователем и движком базы данных. Вместо этого программа получала прямой доступ к данным – через библиотеку программирования в случае больших систем мейнфреймов или через интерфейс командной строки или систему интерактивных форм в случае dBASE и аналогичных приложений. Данные из dBASE обычно не могли быть доступны напрямую другим программам, работающим на машине. Эти программы могли получить доступ к этим данным, часто через библиотеки, но это не работало ни с каким другим движком базы данных или даже с разными базами данных в одном и том же движке. По сути, все такие системы были статичными, что создавало значительные проблемы.

The introduction of the mainframe based relational database during the 1970s led to a proliferation of data access methods. Generally these systems operated together with a simple command processor that allowed users to type in English like commands, and receive output. The best known examples are SQL from IBM and QUEL from the Ingres project. These systems may or may not allow other applications to access the data directly, and those that did use a wide variety of methodologies. The introduction of SQL aimed to solve the problem of language standardization, although substantial differences in implementation remained. Since the SQL language had only rudimentary programming features, users often wanted to use SQL within a program written in another language, say Fortran or C. This led to the concept of Embedded SQL, which allowed SQL code to be embedded within another language. For instance, a SQL statement like SELECT * FROM city could be inserted as text within C source code, and during compiling it would be converted into a custom format that directly called a function within a library that would pass the statement into the SQL system. Results returned from the statements would be interpreted back into C data formats like char * using similar library code. There were several problems with the Embedded SQL approach. Like the different varieties of SQL, the Embedded SQLs that used them varied widely, not only from platform to platform, but even across languages on one platform – a system that allowed calls into IBM Db2 would look very different from one that called into their own SQL/DS. Another key problem to the Embedded SQL concept was that the SQL code could only be changed in the program's source code, so that even small changes to the query required considerable programmer effort to modify. The SQL market referred to this as static SQL, versus dynamic SQL which could be changed at any time, like the command line interfaces that shipped with almost all SQL systems, or a programming interface that left the SQL as plain text until it was called. Dynamic SQL systems became a major focus for SQL vendors during the 1980s. Older mainframe databases, and the newer microcomputer based systems that were based on them, generally did not have a SQL like command processor between the user and the database engine. Instead, the data was accessed directly by the program – a programming library in the case of large mainframe systems, or a command line interface or interactive forms system in the case of dBASE and similar applications. Data from dBASE could not generally be accessed directly by other programs running on the machine. Those programs may be given a way to access this data, often through libraries, but it would not work with any other database engine, or even different databases in the same engine. In effect, all such systems were static, which presented considerable problems.

Ранние усилия

К середине 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. В отличие от более позднего ODBC, Blueprint была чисто программной системой, не имевшей ничего, напоминающего язык команд, подобный SQL. Вместо этого программисты использовали структуры данных для хранения информации о запросе, формируя запрос путем связывания множества этих структур вместе. Lotus называла эти составные структуры деревьями запросов. Примерно в то же время отраслевая команда, включавшая представителей Sybase (Том Хаггин), Tandem Computers (Джим Грей и Рао Йендлури) и Microsoft (Кайл Гейгер), работала над стандартизованной концепцией динамического SQL. Большая часть системы базировалась на системе DB Library от Sybase, с удалением специфичных для Sybase разделов и добавлением нескольких расширений для поддержки других платформ. Развитию DB Library способствовал общеотраслевой переход от библиотечных систем, тесно связанных с конкретным языком программирования, к библиотечным системам, предоставляемым операционной системой и требующим от языков на данной платформе соответствия её стандартам. Это означало, что одна библиотека могла использоваться с (потенциально) любым языком программирования на данной платформе. Первый проект Microsoft Data Access API был опубликован в апреле 1989 года, примерно в то же время, когда Lotus объявила о Blueprint. Несмотря на значительное преимущество Blueprint – она работала, когда MSDA оставалась лишь концепцией на бумаге – Lotus в конечном итоге присоединилась к разработке MSDA, когда стало ясно, что SQL станет де-факто стандартом баз данных. После значительного вклада со стороны отрасли летом 1989 года стандарт получил название SQL Connectivity (SQLC).

By the mid 1980s the rapid improvement in microcomputers, and especially the introduction of the graphical user interface and data rich application programs like Lotus 1 2 3 led to an increasing interest in using personal computers as the client side platform of choice in client–server computing. Under this model, large mainframes and minicomputers would be used primarily to serve up data over local area networks to microcomputers that would interpret, display and manipulate that data. For this model to work, a data access standard was a requirement – in the mainframe field it was highly likely that all of the computers in a shop were from one vendor and clients were computer terminals talking directly to them, but in the micro field there was no such standardization and any client might access any server using any networking system. By the late 1980s there were several efforts underway to provide an abstraction layer for this purpose. Some of these were mainframe related, designed to allow programs running on those machines to translate between the variety of SQL's and provide a single common interface which could then be called by other mainframe or microcomputer programs. These solutions included IBM's Distributed Relational Database Architecture (DRDA) and Apple Computer's Data Access Language. Much more common, however, were systems that ran entirely on microcomputers, including a complete protocol stack that included any required networking or file translation support. One of the early examples of such a system was Lotus Development's DataLens, initially known as Blueprint. Blueprint, developed for 1 2 3, supported a variety of data sources, including SQL/DS, DB2, FOCUS and a variety of similar mainframe systems, as well as microcomputer systems like dBase and the early Microsoft/Ashton Tate efforts that would eventually develop into Microsoft SQL Server. Unlike the later ODBC, Blueprint was a purely code based system, lacking anything approximating a command language like SQL. Instead, programmers used data structures to store the query information, constructing a query by linking many of these structures together. Lotus referred to these compound structures as query trees. Around the same time, an industry team including members from Sybase (Tom Haggin), Tandem Computers (Jim Gray & Rao Yendluri) and Microsoft (Kyle Geiger) were working on a standardized dynamic SQL concept. Much of the system was based on Sybase's DB Library system, with the Sybase specific sections removed and several additions to support other platforms. DB Library was aided by an industry wide move from library systems that were tightly linked to a specific language, to library systems that were provided by the operating system and required the languages on that platform to conform to its standards. This meant that a single library could be used with (potentially) any programming language on a given platform. The first draft of the Microsoft Data Access API was published in April 1989, about the same time as Lotus' announcement of Blueprint. In spite of Blueprint's great lead – it was running when MSDA was still a paper project – Lotus eventually joined the MSDA efforts as it became clear that SQL would become the de facto database standard. After considerable industry input, in the summer of 1989 the standard became 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. В 1996 году группа X/Open поглотила SAG, которая впоследствии стала частью Common Application Environment от The Open Group. MS продолжила работу с оригинальным стандартом SQLC, сохранив многие передовые функции, которые были исключены из версии CLI. К ним относились такие возможности, как прокручиваемые курсоры и запросы метаданных. Команды API были разделены на группы: основная группа полностью соответствовала CLI, расширения уровня 1 включали команды, которые было легко реализовать в драйверах, а команды уровня 2 содержали более продвинутые функции, такие как курсоры. Предложенный стандарт был опубликован в декабре 1991 года, и в течение 1992 года были собраны отзывы от индустрии и учтены при доработке системы, что привело к очередному изменению названия на ODBC.

In 1988 several vendors, mostly from the Unix and database communities, formed the SQL Access Group (SAG) in an effort to produce a single basic standard for the SQL language. At the first meeting there was considerable debate over whether or not the effort should work solely on the SQL language itself, or attempt a wider standardization which included a dynamic SQL language embedding system as well, what they called a Call Level Interface (CLI). While attending the meeting with an early draft of what was then still known as MS Data Access, Kyle Geiger of Microsoft invited Jeff Balboni and Larry Barnes of Digital Equipment Corporation (DEC) to join the SQLC meetings as well. SQLC was a potential solution to the call for the CLI, which was being led by DEC. The new SQLC "gang of four", MS, Tandem, DEC and Sybase, brought an updated version of SQLC to the next SAG meeting in June 1990. The SAG responded by opening the standard effort to any competing design, but of the many proposals, only Oracle Corp had a system that presented serious competition. In the end, SQLC won the votes and became the draft standard, but only after large portions of the API were removed – the standards document was trimmed from 120 pages to 50 during this time. It was also during this period that the name Call Level Interface was formally adopted. In 1995 SQL/CLI became part of the international SQL standard, ISO/IEC 9075 3. The SAG itself was taken over by the X/Open group in 1996, and, over time, became part of The Open Group's Common Application Environment. MS continued working with the original SQLC standard, retaining many of the advanced features that were removed from the CLI version. These included features like scrollable cursors, and metadata information queries. The commands in the API were split into groups; the Core group was identical to the CLI, the Level 1 extensions were commands that would be easy to implement in drivers, while Level 2 commands contained the more advanced features like cursors. A proposed standard was released in December 1991, and industry input was gathered and worked into the system through 1992, resulting in yet another name change to ODBC.

JET и 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, а вскоре после этого – UDBC (эквивалент ODBC и SAG/CLI) SDK и соответствующие драйверы для 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 Data Objects (ADO) и ADO.NET, которые в течение своего жизненного цикла в той или иной степени взаимодействовали с ODBC. По мере того, как Microsoft отводила внимание от прямой работы над ODBC, Unix-сообщество все больше его принимало. Этому способствовали два изменения на рынке: появление графических пользовательских интерфейсов (GUI), таких как GNOME, которые требовали доступа к этим источникам в нетекстовом формате, и развитие систем баз данных с открытым исходным кодом, таких как PostgreSQL и MySQL, изначально работавших под Unix. Более позднее внедрение ODBC компанией Apple для использования стандартного пакета iODBC в 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 1.0 was released in September 1992. At the time, there was little direct support for SQL databases (versus ISAM), and early drivers were noted for poor performance. Some of this was unavoidable due to the path that the calls took through the Jet based stack; ODBC calls to SQL databases were first converted from Simba Technologies's SQL dialect to Jet's internal C based format, then passed to a driver for conversion back into SQL calls for the database. Digital Equipment and Oracle both contracted Simba Technologies to develop drivers for their databases as well. Circa 1993, OpenLink Software shipped one of the first independently developed third party ODBC drivers, for the PROGRESS DBMS, and soon followed with their UDBC (a cross platform API equivalent of ODBC and the SAG/CLI) SDK and associated drivers for PROGRESS, Sybase, Oracle, and other DBMS, for use on Unix like OS (AIX, HP UX, Solaris, Linux, etc. ), VMS, Windows NT, OS/2, and other OS. Meanwhile, the CLI standard effort dragged on, and it was not until March 1995 that the definitive version was finalized. By then, Microsoft had already granted Visigenic Software a source code license to develop ODBC on non Windows platforms. Visigenic ported ODBC to the classic Mac OS, and a wide variety of Unix platforms, where ODBC quickly became the de facto standard. "Real" CLI is rare today. The two systems remain similar, and many applications can be ported from ODBC to CLI with few or no changes. Over time, database vendors took over the driver interfaces and provided direct links to their products. Skipping the intermediate conversions to and from Jet or similar wrappers often resulted in higher performance. However, by then Microsoft had changed focus to their OLE DB concept (recently reinstated ), which provided direct access to a wider variety of data sources from address books to text files. Several new systems followed which further turned their attention from ODBC, including ActiveX Data Objects (ADO) and ADO. net, which interacted more or less with ODBC over their lifetimes. As Microsoft turned its attention away from working directly on ODBC, the Unix field was increasingly embracing it. This was propelled by two changes within the market, the introduction of graphical user interfaces (GUIs) like GNOME that provided a need to access these sources in non text form, and the emergence of open software database systems like PostgreSQL and MySQL, initially under Unix. The later adoption of ODBC by Apple for using the standard Unix side iODBC package Mac OS X 10.2 (Jaguar) (which OpenLink Software had been independently providing for Mac OS X 10.0 and even Mac OS 9 since 2001) further cemented ODBC as the standard for cross platform data access. Sun Microsystems used the ODBC system as the basis for their own open standard, Java Database Connectivity (JDBC). In most ways, JDBC can be considered a version of ODBC for the programming language Java instead of C. JDBC to ODBC bridges allow Java based programs to access data sources through ODBC drivers on platforms lacking a native JDBC driver, although these are now relatively rare. Inversely, ODBC to JDBC bridges allow C based programs to access data sources through JDBC drivers on platforms or from databases lacking suitable ODBC drivers.

ОДБК сегодня

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

Драйверы баз данных для рабочего стола

1.0 (1993–08): Использовался процессор запросов SIMBA, разработанный PageAhead Software. 2.0 (1994–12): Использовался совместно с ODBC 2.0. 3.0 (1995–10): Поддерживает Windows 95 и Windows NT Workstation или 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 edition), Mimer SQL, Sybase ASE, SAP HANA и IBM Db2. Поскольку различные технологии обладают разными возможностями, большинство драйверов ODBC не реализуют всю функциональность, определенную в стандарте ODBC. Некоторые драйверы предлагают дополнительную функциональность, не предусмотренную стандартом.

Управляющий водителем

Драйверы устройств обычно перечисляются, настраиваются и управляются отдельным уровнем менеджера, который может предоставлять дополнительную функциональность. Например, системы печати часто включают в себя функции для организации очереди печати поверх драйверов, обеспечивая буферизацию заданий печати для любого поддерживаемого принтера. В ODBC эти функции предоставляет Driver Manager (DM). DM может перечислить установленные драйверы и представить их в виде списка, часто в форме графического пользовательского интерфейса. Однако для работы системы ODBC более важна концепция DM – имя источника данных (DSN). DSN собирают дополнительную информацию, необходимую для подключения к конкретному источнику данных, а не к самой СУБД. Например, один и тот же драйвер MySQL можно использовать для подключения к любому серверу MySQL, но информация для подключения к локальному частному серверу отличается от информации, необходимой для подключения к общедоступному серверу, размещенному в интернете. DSN хранит эту информацию в стандартизированном формате и предоставляет ее драйверу во время запросов на подключение. 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 Data Sources заполнил пробел, когда 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.