Contents | Prev | Next JDBCTM Guide: Getting Started


1 - Введение

1.1    Что такое JDBCTM?

JDBCTM - это прикладной программный интерфейс (далее API) JavaTM для выполнения SQL-запросов. Он состоит из множества классов и интерфейсов, написанных на языке Java. JDBC предоставляет стандартный API для разработчиков, использующих базы данных (далее БД). С помощью JDBC можно писать приложения на языке Java, использующие БД.

С помощью JDBC легко отсылать SQL-запросы почти ко всем реляционным БД. Другими словами, использование JDBC API избавляет от необходимости для каждой СУБД (Informix, Oracle и т.д.) писать свое приложение. Достаточно написать одну единственную программу, использующую JDBC API, и эта программа сможет отсылать SQL-запросы к требуемой БД. Кроме того, это проложение будет переносимо на различные платформы.

JDBC расширяет и без того богатую функциональность Java. Например, можно опубликовать в Интернет веб-страницу, содержащую апплет, связанный с БД на сервере. Еще один пример: организация с помощью JDBC может подключить всех сотрудников к одной БД, даже если мы имеем дело с конгломератом операционных систем на рабочих станциях сотрудников - Windows, Macintosh, UNIX

1.1.1     Что может JDBC?

  • Устанавливать соединение с БД
  • Отсылать SQL-запросы
  • Обрабатывать результаты.
    А вот пример этих действий:

        Connection con = DriverManager.getConnection (
                    "jdbc:odbc:wombat", "login", "password"); // Устанавливаем соединение
        Statement stmt = con.createStatement();
        ResultSet rs = stmt.executeQuery("SELECT a, b, c FROM Table1"); // Выполняем запрос
        while (rs.next()) {
          int x = getInt("a");  // получаем результат
          String s = getString("b");
          float f = getFloat("c");
        }
    

    1.1.2     JDBC против ODBC и других API

    В настоящее время, возможно, ODBC (Open DataBase Connectivity) наиболее популярен при разработке прилодений для доступа к БД. Этот интерфейс "понимают" почти все СУБД на всех платформах. Возникает вопрос: а почему бы не использовать ODBC в языке Java?

    Дело в том, что лучше использовать так называемый мост JDBC-ODBC, который мы рассмотри чуть позже. На поставленный вопрос существцет несколько ответов:

    1. ODBC использует интерфейс, наиболее родной для языка C и не совсем подходящий для Java. Вызовы C-кода из языка Java страдают плохой защищенностью, гибкостью и переносимостью приложений.
    2. Непосредственная трансляция интерфейса ODBC API в Java API нежелательна по той причине, что в языке Java нет адресной арифметики, а ODBC активно ее использует в виде указателей void *.
    3. ODBC сложнее для изучения. Он перемешивает в себе одновременно и простые, и сложные возможности и требует сложных программистских "выкрутасов" даже для выполнения простейших запросов. В то же время в JDBC все простое делается просто, но и сложные возможности остаются доступными.
    4. JDBC отвечает концепции "истинной Java". Когда используется ODBC, необходимо на каждую клиентскую машину ставить odbc-драйвер. Если JDBC-драйвер написан целиком на языке Java, то приложение, использующее его, лишено такого недостатка и, кроме того, обладает переносимостью и защищенностью, присущей языку Java.
    Короче говоря, JDBC - это "родной" для Java интерфейс к базовым абстакциям и концепциям языка SQL. Он чем-то похож на ODBC, поэтому программистам, знакомым с ODBC, изучить JDBC не составит труда.

    1.1.3     Двухзвенные и трехзвенные модели

    JDBC использует двух- и трех- звенные модели лдя доступа к БД.

    В двухзвенной модели приложение или апплет на языке Java обращается непосредсвенно к БД. В этом случае JDBC-драйвер "умеет" общаться с соответствующей СУБД. SQL-запросы отсылаются в СУБД, а результаты отсылаются обратно к пользователю. БД может находиться на другой машине, с которой пользователь соединяется по сети. И пользовательская машина, и сервер БД работают в конфигурации клиент/сервер. В качестве сети может выступать Интранет, соединяя между собой работников корпорации, или Интернет:


    В трехзвенной модели команды поступают в т.н. сервис среднего звена, который отсылает SQL-выражения в БД. БД обрабатывает SQL, отсылая запросы в этот самый сервис, который затем возвращает результат конечному пользователю. Трехзвенная модель очень привлекательна тем, что может контролировать доступ и изменения, вносимые в корпоративную БД. Другое достоинство такого подхода заключается в том, что программист может реализовать свой собственный предметно-ориентированный API, который транслируется средним звеном низкоуровневые SQl-запросы. Кроме того, во многих случаях трехзвенная архитектура может увеличить произведительность.


    Вплоть до недавнего времени промежуточный слой было принято писать на таких высокопроизводительных языках как C или C++. Тем не менее с созданием компиляторов из байт-кода языка Java в эффективный машинный код реализация промежуточного звена на Java становится практически выгодной. Достоинства языка Java, которые в этом случае переносятся на промежуточное звено, - это гибкость, многопоточность и защищенность. JDBC в этой схеме предоставляет доступк БД из промежуточного звена, написанного на Java.

    1.1.4     Соответствие языку SQL

    Структурный язык запросов (SQL) - это стандартный язык для доступа к реляционным СУБД. Но, как это часто бывает со стандартами, существует много различных не совместимых между собой реализаций SQL. Многие СУБД, хоть и используют стандартные формы базовой функциональности SQL, не соответствуют наиболее позднему синтаксису или семантики SQL для более продвинутых функций. Например, не все СУБД поддерживают хранимые процедуры, а если и поддерживают, то используют различный синтаксис. Не все СУБД поддерживают внешние соединения ("outer joins"), различные СУБД имеют разный формат записи даты.

    Один из способов, которым JDBC API решает эту проблему - это перенаправление всех SQL-запросов через драйвер СУБД "как есть". Это означает, что приложение вольно использовать все возможности SQL на полную катушку, но при этом рискуя получить сообщение об ошибке от некоторых СУБД. Фактически, запрос может и не быть SQL-запросом, а быть запросом, специфичным для данной СУБД (например, запросы к документам).

    Второй способ разрешения проблем плохого соответствия языку SQL - это использование т.н. escape-конструкций в стиле ODBC, которые рассматриваются в разделе 4.1.5, "Escape-синтаксис SQL в объектах Statement.". Escape-синтаксис предлагает единый синтаксис для наиболее типичных разногласий в SQL. Например, существует escape-синтаксис для констант типа "дата" и вызовов хранимых процедур.

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

    Поскольку JDBC API используется в качестве основы для построения более высокоуровневых инструментов доступа к БД, то возникают также проблемы совместимости того, что надстроено сверху JDBC. Обозначение "JDBC COMPLIANTTM" ("Соответствует JDBCTM") было придумано с целью определить стандартные границы функциональности, на которую может положиться пользователь. Чтобы отвечать этому обозначению, драйвер JDBC должен поддерживать как минимум ANSI SQL-2 Entry Level (вводный уровень ANSI SQL-2. ANSI SQL-2 - это стандарт, принятый Американским Национальным Институтом Стандартов, 1992. Вводный уровень - это определенный список возможностей SQL). Разработчики драйверов должны убедиться, что их драйверы соответствуют этим стандартам, с помощью специального тестового набора, поставляемого вместе с JDBC API.

    Знак "JDBC COMPLIANTTM" показывает, что реализация JDBC прошла тесты на совместимость, поставляемые компанией JavaSoft. Эти тесты совместимости проверяют на наличие всех классов и методов, декларированных в JDBC API, и проверяют так тщательно, насколько это возможно, что функциональность SQL Entry level достигнута. Эти тесты, конечно, не исчерпывающие, и JavaSoft в настоящее время не сертифицирует разработчиков драйверов. Тем не менее, в связи с быстрым распространением JDBC среди поставщиков баз данных и средств коммуникации и разработчиков приложений, JDBC стал стандартом доступа к БД из Java.

    1.2    JDBC-продукты

    Среди разнообразия продуктов, ориентированных на JDBC, можно отметить:

    1.2.1     Структура JDBC

    JavaSoft поставляет три компонента JDBC вместе с Java Development Kit (JDK) версии 1.1.x:

    JDBC driver manager - это остов архитектуры JDBC. В версии JDK 1.1.x. он маленький и простой; его первичная функция - это присоединение Java-приложений к требуемому драйверу JDBC. После этого он выходит из игры.

    Средства тестирования драйверов JDBC дают некоторую степень уверенности в том, что JDBC-драйверы будут работать с вашей программой. Только драйверы, прошедшие эти тесты, могут быть помечены как JDBC COMPLIANTTM.

    Мост JDBC-ODBC позволяет использовать драйверы ODBC, как будто они были бы JDBC-драйверами. Этот мост был разработан с целью повысить популярность JDBC и дать разработчикам возможность работать с СУБД, которые пока не поддерживают JDBC.


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

    JDBC-драйверы, разработанные до настоящего момента, можно классифицировать по четырем категориям:

    1. Мост JDBC-ODBC + драйвер ODBC: Этот мост, как уже было сказано, использует интерфейс JDBC для доступа к драйверам ODBC. Надо заметить, что исполняемый код ODBC и, во многих случаях, клиентский код для СУБД должны быть установлены на кождой машине, использующий этот тип драйверов. Следовательно, этот тип драйверов наиболее типичен либо для корпоративных сетей, для которых конфигурация клиентских мест - не проблема, либо для серверного приложения, написанного на Java в трехзвенной архитектуре.
    2. Наполовину-Java драйверы: Этот тип драйверов преобразуют вызовы JDBC в вызовы клиентского API для Oracle, Sybase, Informix, DB2 и т.д. Как и мост JDBC-ODBC, этот тип драйверов требует, чтобы на каждой клиентской станции был установлен некоторый исполняемый (двоичный) не-java код.
    3. Сетевые JDBC-драйверы на чистом Java: Эти драйверы транслируют программные вызовы JDBC в независимый от СУБД сетевой протокол, который затем транслируется в протокол СУБД специальным промежуточным сервером. Этот сетевое промежуточное серверное приложение соединяет клиентов на чистой Jave со множеством раздичный БД. Этот специальный сетевой протокол зависит от конкретного поставщика, то есть жестко не стандартизован. Это наиболее гибкий и защищенный в агрессивной среде Интернета способ.
    4. Драйверы "родного" протокола СУБД: Этот тип драйверов преобразует программные вызовы в сетевой протокол, используемый СУБД непосредственно. Становится возможным прямое подключение клиентских машин к серверу БД. Этот метод находит практическое применение в Интранет-среде. Так как многие такие протоколы патентованы (являются собственностью поставщиков), то за разработку таких драйверов отвечают поставщики СУБД.
    Предпочтительным способом доступа к БД являются драйверы типа 3 и 4. Типы 1 и 2 драйверов - это временные решения для тех случаев, когда драйверы на чистом Java не доступны. В случае 3 и 4 мы получаем все преимущества Java, включая возможность автоматической инсталляции (например, загрузка и запуск апплетов, которые используют JDBC).

    Следующая таблица показывает четыре типа драйверов и их свойства:

    Категория драйверов Полностью на JAVA? Сетевой протокол
    1 - Мост JDBC-OCBC Нет Непосредственно
    2 - "Родной" API в качестве основы Нет Непосредственно
    3 - JDBC-Net Да Требуется "коннектор"
    4 - "Родной" сетевой протокол Да Непосредственно

    1.2.3     Другие продукты

    Разрабатываются различные инструменты разработки JDBC-приложений. См. страницы сервера JavaSoft. См. также полный список драйверов, зарегистрированных в JavaSoft.



    Содержание | Следующий