IT История

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

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

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

Данный компонент можно разместить либо на клиенте, либо на сервере. Наиболее очевиден первый вариант решения. На компьютере-клиенте, где выполняется приложение, размещается, помимо компонента доступа к БД, еще и сетевые компоненты (обобщенное название X Net Client, где X название конкретной СУБД), обеспечивающие доступ к каждой из баз данных. Так, если приложение работает с базами данных Oracle и Informix, то на компьютер-клиент должны быть установлены продукты Oracle SQL*Net Client и Informix-Net Client. Недостатки подобного решения очевидны.

Во-первых, компьютер-клиент становится просто неприлично толстым. Мало того, что он должен поддерживать компонент представления и прикладной компонент (классическая RDA-модель). Помимо этого, на него дополнительно возлагается унификация доступа к базам данных (вся синтаксическая и, возможно, семантическая трансляция обобщенный SQL диалект SQL ) для каждой из баз данных. Перегруженность клиента системной функциональностью никак не укладывается в современные представления об архитектуре клиент/сервер.

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

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

Не стоит жестко связывать интеграцию баз данных на стороне клиента и доступ к БД на основе ODBC. Дело в том, что ODBC можно использовать и на стороне сервера с использованием продукта Oracle Transparent Gateway for ODBC (TGODBC), о котором также будет рассказано в статье. С ODBC можно работать также и в ОС UNIX.

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

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

Другим возможным решением является размещение компонента доступа к БД на стороне сервера (рис. 3). Приложение на компьютере-клиенте взаимодействует с сервером посредством Oracle SQL. Для организации сетевого взаимодействия клиента и сервера используется SQL*Net (Net8). Клиент обращается к любым базам данных, доступным в рамках корпоративной сети, как к базам данных Oracle. Обращение к базам данных других форматов полностью прозрачно для клиента, то есть клиент ничего не знает о том, на каком из компьютеров-серверов расположена искомая база данных и в каком она формате. Однако обращение к базе данных происходит не напрямую (как в случае с ODBC), а опосредованно, через сервер Oracle (как это сделано технически, будет рассказано ниже). Именно этот факт дает основание говорить о том, что в данном случае имеет место технология сервер/сервер. То есть клиент обращается к Oracle Server, а тот взаимодействует с сервером другой базы данных.

Таким образом, интеграция баз данных на уровне сервера предполагает:

Отметим, что два подхода к интеграции баз данных (на стороне клиента и на стороне сервера) выделены в статье исключительно для объяснения специфики работы продуктов группы Oracle Transparent Gateway. Вообще говоря, при подготовке статьи не ставилась задача детального анализа достоинств и недостатков решений по интеграции баз данных (ODBC, EDA/SQL, IBM DRDA).