Доступ к базам данных в двухзвенных моделях клиент-сервер
В простых двухзвенных моделях клиент-сервер, где несколько БД обслуживают ограниченное число пользователей настольных ПК, в роли встроенного ПО доступа к данным могут выступать обычные ODBC-драйверы.
Необходимость в более сложных решениях возникает в больших, разнородных многозвенных системах, где множество приложений в параллельном режиме осуществляет доступ к разнообразным источникам данных, включая разнотипные СУБД и хранилища данных. В таких системах между клиентами и серверами баз данных размещается промежуточное звено – SQL-шлюз, представляющий набор общих API, позволяющих разработчику строить унифицированные запросы к разнородным данным (в формате SQL или с помощью ODBC-интерфейса). SQL-шлюз выполняет синтаксический разбор такого запроса, анализирует и оптимизирует его и, в конце концов, выполняет преобразование в SQL-диалект нужной СУБД. ПО этого типа реализует синхронный механизм связи, когда выполнение приложения, сделавшего запрос, блокируется до момента получения данных.
Пример такого приложения – система анализа статистических данных о деятельности компаний, отбирающая соответствующую информацию из расположенных в различных регионах БД с разными СУБД. Подобные решения достаточно просты, не требуют сложных механизмов управления транзакциями и способны обеспечить постепенную миграцию важных приложений с унаследованных платформ в архитектуру клиент-сервер.
Каждое приложение, построенное на основе архитектуры «клиент-сервер», включает, как минимум, две части:
- клиентскую часть, отвечающую за целевую обработку данных и организацию взаимодействия с пользователем;
- серверную часть, собственно хранящую данные, обрабатывающую запросы и посылающую результаты клиенту для специальной обработки.
В общем случае предполагается, что эти части приложения функционируют на отдельных компьютерах, т.е. к выделенному серверу БД с помощью сети подключены узлы – компьютеры пользователей (клиенты). При этом узел-клиент сам может быть СУБД.
Создается такое приложение обычно с использованием средств языков высокого уровня (например, C++, Pascal, VisualBasic), позволяющих реализовать эффективную целевую обработку данных и дружественный пользовательский интерфейс. В исходный текст программы включаются SQL-выражения, специфицирующие условия выборки или изменения данных в базе. Во время исполнения приложения эти выражения передаются серверу, который собственно и манипулирует данными. Данные, полученные в результате выполнения сервером SQL-запросов, возвращаются прикладной программе и размещаются в заранее определенных структурах для дальнейшей обработки, в том числе корректировки записей.
Рассмотрим различные способы организации доступа прикладной программы к серверу базы данных в двухзвенной архитектуре.
Использование библиотек доступа и встраиваемого SQL
Каждая СУБД помимо интерактивной SQL-утилиты обязательно имеет библиотеку процедур доступа и набор драйверов СУБД для различных операционных систем. Схема взаимодействия клиентского приложения с сервером базы данных в этом случае представлена на Рис. 19-10:
Рис. 19-10. Схема взаимодействия с использованием
библиотек процедур доступа
Библиотека доступа содержит набор функций, позволяющих клиентскому приложению соединяться с БД, передавать запросы серверу и получать данные – результаты обработки запроса. Типичный набор функций такой библиотеки включает:
· соединение с БД;
· запрос к БД на выполнение SQL-выражения;
· запрос на извлечение данных;
· запрос на изменение данных;
· закрытие соединения с БД.
Обычно в библиотеке присутствуют также функции, позволяющие определить характеристики структуры набора результата (число, порядок и имена столбцов, число строк, номер текущей строки), передвигаться по этой структуре не только вперед, но и назад и т.д.
Библиотечные вызовы преобразуются драйвером БД в сетевые вызовы и передаются сетевым ПО на сервер. На сервере происходит обратный процесс преобразования сетевых пакетов в SQL-запросы, которые обрабатываются СУБД. Результаты обработки передаются клиенту.
Такой способ создания приложений достаточно гибок и позволяет реализовать практически любое приложение, однако имеет и недостатки:
· разработка клиентской программы возможна только для той ОС и на том языке программирования, в которых поддерживается библиотека;
· драйвер БД определяет допустимые типы сетевых интерфейсов;
· библиотечные функции обычно неунифицированы.
Некоторой модификацией данного способа является использование «встроенного» языка SQL. В этом случае текст программы на языке третьего поколения вместо вызовов функций библиотеки включает непосредственно предложения SQL, которые предваряются выражением «EXEC SQL». Перед компиляцией в машинный код такая программа обрабатывается препроцессором, который транслирует смесь операторов «собственного» языка СУБД и SQL-предложений в промежуточный «чистый» исходный код, а затем коды SQL замещаются вызовами соответствующих процедур из библиотек, поддерживающих конкретную СУБД. Такой подход позволяет несколько снизить степень привязанности к СУБД, например, при переключении ПП на работу с другим сервером базы данных – достаточно указать новый сервер и заново перекомпилировать программу.
Программный интерфейс уровня вызовов
Стандарт SQL2 определил интерфейс уровня вызова (CLI – CallLevelInterface), в котором стандартизован общий набор рабочих процедур, обеспечивающий совместимость со всеми основными типами серверов баз данных.
Технологическая основа CLI – размещаемая на компьютере клиента специальная библиотека, хранящая вызовы процедур и сетевых компонентов для организации связи с сервером. Это ПО поставляется обычно в составе среды разработки и поддерживает разнообразные сетевые протоколы.
Использование программных вызовов позволяет свести к минимуму операции на компьютере-клиенте. В общем случае клиент формирует оператор языка SQL в виде строки и пересылает её на сервер посредством процедуры исполнения (execute). Когда же сервер в качестве ответа возвращает несколько строк данных, клиент считывает результат последовательным вызовом процедуры выборки данных. Далее данные из столбцов полученной таблицы могут быть связаны с соответствующими переменными приложения. Вызов специальной процедуры позволяет клиенту определить число полученных строк, столбцов и типы данных в каждом столбце.
Открытый интерфейс доступа к базам данных
Спецификация открытого интерфейса баз данных (ODBC – Open Database Connectivity), предназначена для унификации доступа к данным, размещённым на удалённых серверах. ODBC опирается на спецификации CLI.
ODBC представляет программный слой, унифицирующий интерфейс взаимодействия приложений с БД. За реализацию особенностей доступа к каждой отдельной СУБД отвечает соответствующий специальный ODBC-драйвер. Пользовательское приложение этих особенностей не видит, т.к. взаимодействует с универсальным программным слоем более высокого уровня. Таким образом, приложение становится в значительной степени независимым от СУБД. Вместо создания в каждом отдельном случае СУБД-приложения с обращениями через «родной», но быстро устаревающий интерфейс, можно использовать один общий стандартизированный программный интерфейс.
В архитектуре ODBC используется один ODBCDriverManager и несколько ODBC-драйверов, обеспечивающих доступ к конкретным СУБД. DriverManager связывает приложение и интерфейсные объекты, которые выполняют обработку SQL-запросов к конкретной СУБД.
 |
Рис. 19-11. Структурная схема доступа к данным с использованием ODBC
Такой подход является достаточно универсальным, стандартизируемым, что и позволяет использовать ODBC-механизмы для работы практически с любой системой. Однако этот способ также не лишен недостатков:
· увеличивается время обработки запросов (как следствие введения дополнительного программного слоя);
· необходимы предварительная инсталляция и настройка ODBC-драйвера (указание драйвера СУБД, сетевого пути к серверу, базы данных и т.д.) на каждом рабочем месте. Параметры этой настройки являются статическими, т.е. приложение их изменить самостоятельно не может.
Мобильный интерфейс к базам данных на платформе Java
JDBC (Java Data Base Connectivity) – интерфейс прикладного программирования (API) для выполнения SQL-запросов к БД из программ, написанных на платформенно-независимом языке Java, позволяющем создавать как самостоятельные приложения (standalone application), так и апплеты, встраиваемые в web-страницы.
JDBC во многом подобен ODBC, он также построен на основе спецификации CLI, однако имеет ряд следующих отличий.
· приложение загружает JDBC-драйвер динамически, следовательно, администрирование клиентов упрощается, более того, появляется возможность переключаться на работу с другой СУБД без перенастройки клиентского рабочего места.
· JDBC, как и Java в целом, не привязан к конкретной аппаратной платформе, следовательно, проблемы с переносимостью приложений практически снимаются.
· использование Java-приложений и связанной с ними идеологии «тонких клиентов» обещает снизить требования к оборудованию клиентских рабочих мест.
Обобщенная структурная схема доступа к данным с использованием JDBC приведена на Рис. 19-12.
Назад к разделу "Программное обеспечение распределенных приложений"