Драйвер базы данных это

Обновлено: 21.01.2025

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

Список типов драйверов JDBC

Существует четыре различных типа драйвера JDBC. Эти типы драйверов:

Тип 1: драйвер JDBC моста JDBC-ODBC
Тип 2: драйвер JDBC для собственного кода Java +
Тип 3: Все драйверы JDBC для перевода Java + Middleware
Тип 4: Все драйверы Java JDBC.

Сегодня большинство драйверов JDBC являются драйверами типа 4. Тем не менее, я только кратко расскажу о 4 типах драйверов JDBC.

Драйвер JDBC типа 1

Драйвер JDBC типа 1 состоит из части Java, которая переводит вызовы интерфейса JDBC в вызовы ODBC. Затем мост ODBC вызывает драйвер ODBC для данной базы данных. Драйверы типа 1(были) в основном предназначались для использования в начале, когда не было драйверов типа 4(все драйверы Java). Вот иллюстрация того, как организован драйвер JDBC типа 1:

Драйвер JDBC типа 2

Драйвер JDBC типа 2 подобен драйверу типа 1, за исключением того, что часть ODBC заменяется частью собственного кода. Часть собственного кода предназначена для конкретного продукта базы данных. Вот иллюстрация драйвера JDBC типа 2:

Драйвер JDBC типа 3

Драйвер JDBC типа 4

Драйвер JDBC типа 4 является полностью драйвером Java, который подключается непосредственно к базе данных. Он реализован для конкретного продукта базы данных. Сегодня большинство драйверов JDBC являются драйверами типа 4. Вот иллюстрация того, как организован драйвер JDBC типа 4:

Собственно вопрос, каков механизм выполнения запросов к СУБД (например, пусть это будет MySQL) и какова роль в этом механизме таких компонентов, как язык SQL и ODBC? Непонятно вот что, если есть универсальный язык выполнения запросов, который нивелирует различия между СУБД, зачем нужен ещё и универсальный драйвер?

sql (язык) - не универсален. Есть диалекты. odbc это один из стандартов (библиотек), позволяющий как сделать запрос, так и узнать список таблиц полей процедур не используя запросы. Кроме odbc есть ещё jdbc, oledb и другие. @nick_n_a, наличие диалектов не отменяет его универсальности, в противном случае в нём бы не было необходимости. Большинство запросов, написанных в соответствии со стандартом, будут одинаково интерпретированы на большинстве реляционных СУБД. А если вы под диалектами понимаете нечто вроде T-SQL или PL/SQL, ну так это скорее процедурные расширения универсального SQL, о которых, замечу, в вопросе речи не шло. Вам правильно ответили. sql = язык. odbc = библиотека (интерфейс для драйверов) к СУБД. odbc может выполнять sql, а sql выполнять odbc нет (sql не связан с odbc). Под универсальностью я имел ввиду то что sql(mysql):show tables не будет равен sql(mssql):select * from sys.tables , а в odbc предусмотрена функция типа gettables которая всегда одинаково вернёт список таблиц для любой СУБД.

SQL это язык запросов. ODBC это способ подключения к конкретному серверу конкретной БД. Все БД имеют разные протоколы для доступа к серверу БД. ODBC предоставляет унифицированный интерфейс и скрывает конкретную реализацию протокола доступа.

14.1k 1 1 золотой знак 18 18 серебряных знаков 30 30 бронзовых знаков

Задача драйвера не только передать SQL-запрос серверу, такой протокол передачи можно было бы стандартизироать, если бы он был просто текстом. Но есть такая вещь как передаваемые в запрос параметры и самое главное - результат выполнения запроса. Задача драйвера упаковывать запрос, параметры и результаты в пакеты передаваемые по сети. И формат упаковки языком никак не оговаривается и каждая СУБД реализует его по своему. Тем более, что во многих СУБД существуют не только разные типы данных, но и сложные типы, например, как массивы PostgreSQL, которых в стандартах SQL вообще нет. И как передавать по сети эти типы данных опять же каждая БД решает самостоятельно.

Поэтому для работы с СУБД программы линкуются с библиотеками (драйверами) конкретных СУБД, которые умеют общаться с конкретной БД. Драйвер ODBC предназначен для того, что бы программа могла быть слинкована с единственной библиотекой и через нее получать доступ к разным БД, понятно, что при этом программа не сможет получить доступ к не стандартным типам данных и надо будет ограничиваться в работе стандартизированными, боле менее одинаковыми в разных СУБД возможностям языка SQL.

42.7k 2 2 золотых знака 30 30 серебряных знаков 64 64 бронзовых знака

Разработчики БД должны имплементировать интерфейс java.sql.Driver для того, чтобы их БД могла работать с JDBC.

Типы драйверов

Существует 4 типа драйверов для JDBC.

Рассмотрим их по отдельности:

Этот тип драйвера транслирует JDBC в установленный на каждой машине клиентской машине ODBC. Использование ODBC требует конфигурации DSN, который является целевой БД.

Изначально, именно этот тип драйверов был наиболее используемым, так как большинство БД поддерживало только ODBC.

В этом драйвере JDBC API преобразовывается в уникальный для каждой БД нативный C/C++ API. Его принцип работы крайне схож с драйвером первого типа.

Если мы меняем БД, то нам необходимо изменить и нативный API, который будет работать с конкретной БД.

Тип 3. JDBC драйвер на основе библиотеки Java

Этот тип драйверов использует трёх-звенный подход для получения доступа к БД. Для свзяи с промежуточным сервером приложения используется стандартный сетевой сокет. Информация, полученная от этого сокета транслируется промежуточным сервером в формат, который необходим для конкретной БД и направляется в сервер БД.

Этот подход является крайне гибким, так как нет необходимости устанавливать ПО на стороне клиента и один драйвер способен обеспечить доступ к различным типам БД.

Тип 4. Чистая Java.

Ярким примером такого драйвера является MySQL Connector/J.

Если мы используем такие БД, как MySQL, Oracle и т.д., то наиболее предпочтительным будет использование драйвера типа 4.

Если наше приложение использует различные виды БД, то тип 3 будет более приемлемым.

Если для нашей БД ещё нет драйверов типа 3 или 4, то мы будем вынуждены использовать дврайвер типа 2.

ODBC (Open DataBase Connectivity) — широко применяемый прикладной программный интерфейс (API) для доступа к БД. Основан на спецификациях Call-Level Interface из Open Group и ISO/IEC для функций API БД и использует SQL [Источник 1] .

Содержание

Архитектура

Рисунок 1 – Архитектура ODBC

Приложения
Диспетчер драйверов
Драйвер
Источник данных

На рисунке 1 можно увидеть архитектуру ODBC.

Приложения

Приложения — это программа, которая вызывает API ODBC для доступа к данным. Большинство приложений делятся на три категории [Источник 3] :

Универсальные приложения

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

Вертикальные приложения

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

Приложение использует ODBC таким образом, что приложение не привязано к любой из СУБД, несмотря на то, что он может быть привязан к ограниченному числу СУБД, которые предоставляют аналогичные функциональные возможности. Таким образом, разработчик приложения может продавать приложение независимо от СУБД. Вертикальные приложения совместимы при разработке, но иногда модифицируются, чтобы включить несовместимый код, когда клиент выбрал СУБД.

Пользовательские приложения

Пользовательские приложения используются для выполнения определенных задач в одной компании. Например, приложение в крупной компании может собирать данные о продажах с нескольких подразделений (каждый из которых использует различные СУБД) и создать единый отчет. ODBC используется в том случае, когда он представляет собой общий интерфейс и предотвращает программистов от необходимости обучения нескольким интерфейсам. Такие приложения обычно не являются функционально совместимыми и записываются в определенном СУБД и драйверов.

Число задач является общим для всех приложений, независимо от того, как они используют ODBC. В общем, они во многом определяют поток любого приложения ODBC. Например:

Выбор источника данных и подключение к нему.
Отправка инструкции SQL для выполнения.
Извлечение результатов (если таковые имеются).
Ошибки обработки.
Фиксация или откат транзакции, заключив инструкцию SQL.
Отключение от источника данных.

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

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

Драйвера

Драйверы — это библиотеки, которые реализуют функции в API ODBC. Каждый специфичен для конкретной СУБД. Например, драйвер для Oracle не может напрямую обращаться к данным в СУБД с Informix. Драйверы раскрывают возможности базовых СУБД. Они не требуются для реализации возможностей, не поддерживаемых в СУБД. Если базовая СУБД не поддерживает внешние соединения, то драйвер не нужен. Единственным серьезным является то, что драйверы для СУБД, которые не имеют автономных механизмов БД, таких как Xbase, должен реализовать механизм СУБД, поддерживающий по крайней мере минимальный объем SQL [Источник 4] .

Задачи драйвера

Определенные задачи, выполняемые драйверами включают:

Подключение и отключение от источника данных.
Проверка ошибки функций, не проверяется диспетчером драйверов.
Запуск транзакций. Этот процесс прозрачен для приложения.
Отправка инструкций SQL к источнику данных для выполнения. Драйвер должен изменить ODBC SQL в конкретный СУБДSQL.
Отправка и извлечение данных из источника данных, в том числе преобразование типов данных, определенной в приложении.
Отображение ошибок, связанных с СУБД в ODBC SQLSTATE.

Архитектура драйвера

Файловый драйвер

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

СУБД драйверы

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

Читайте также: