1 - Введение

    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.3     Двухзвенные и трехзвенные модели

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

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

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

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

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

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

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

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

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

1.2    JDBC-продукты

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

      http://www.javasoft.com/products/jdbc
  

1.2.1     Структура JDBC

• JDBC driver manager,
  
  
• средства для тестирование драйверов JDBC и
  
  
• мост JDBC-ODBC.
  
  

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

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

1.2.2     Типы драйверов 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. Драйверы "родного" протокола СУБД: Этот тип драйверов преобразует программные вызовы в сетевой протокол, используемый СУБД непосредственно. Становится возможным прямое подключение клиентских машин к серверу БД. Этот метод находит практическое применение в Интранет-среде. Так как многие такие протоколы патентованы (являются собственностью поставщиков), то за разработку таких драйверов отвечают поставщики СУБД.

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

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

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