По сведениям Gartner Group (1994 г.), в западном мире до 70% корпоративных данных все еще пребывает в информационных хранилищах, которые можно отнести к классу реликтовых (под этим термином подразумеваются СУБД с устаревшими, нестандартными форматами данных, и СУБД, не имеющие интерфейсов прикладного программирования API - Applications Programming Interface, - которые обеспечивали бы приложениям открытый доступ к информации). Исторически это было связано с ограниченным объемом внешней памяти ЭВМ массового применения, что вынуждало разработчиков создавать хитроумные методы сжатия данных и смешанные форматы, c отсутствием на первых порах стандартов и безудержной эксплуатацией гибких средств Ассемблера и языков третьего поколения (Си, Паскаль и т. п.). К таким хранилищам можно отнести не только БД на мэйнфреймах (IBM с операционной системой MVS), но и многие системы на мини-ЭВМ и даже на PC. Основным признаком реликтовой БД в наше время можно считать отсутствие интерфейсов API для SQL-доступа к информации.
Обзор современных решений в сфере соединений с БД приводится ниже.
Язык структурированных запросов SQL
Начало эпохи стандартизации в информационной технологии связано с реляционной моделью данных, разработанной Коддом и Дейтом в конце семидесятых годов для мэйнфреймов IBM. Тогда же появился и язык структуированных запросов SQL (Structured Query Language), который довольно быстро был возведен в ранг промышленного стандарта. Ныне большинство реляционных СУБД поддерживает один или более стандартов SQL, разработанных американским институтом стандартов ANSI (American National Standards Institute).
К сожалению (а может быть, к счастью), почти каждый производитель реляционных СУБД считал своим долгом добавить к промышленному стандарту собственные расширения. Отчасти это было вызвано просто коммерческим давлением: "Как могу я убедить Вас купить мою базу данных, если она не отличается от продуктов моих конкурентов?" Некоторые из этих расширений стали стандартом де-факто и способствовали резкому расширению возможностей информационных систем. Среди таких расширений - строки произвольной длины, большие бинарные объекты (BLOB), двухфазная фиксация транзакций и т. п. Одновременно расширения SQL создали пользователям дополнительные проблемы: при покупке средств соединения вы должны убедиться, что они могут полностью использовать возможности уже установленных или планируемых к установке серверов ваших баз данных.
ODBC
ODBC (Open Database Connectivity) - один из основных протоколов, разработанных Microsoft в 1991 - 1992 гг. в рамках открытой архитектуры Windows (WOSA - Windows Open Services Architecture). ODBC подготовлен на базе предложений Группы доступа к SQL (SAG - SQL Access Group), разработавшей требования к соответствующему API под названием Call Level Interface (CLI - интерфейс уровня вызовов). ODBC фирмы Microsoft содержит более 20 функций, предусмотренных стандартом CLI, и около 30 собственных функций. Можно считать, что ODBC - это и стандарт API фирмы Microsoft, и диалект SQL для доступа к данным из приложения Windows. ODBC позволяет приложению клиента манипулировать данными на платформе сервера безотносительно к конкретной структуре данных БД. Основа технологии ODBC - драйвер клиента, который обычно функционирует как промежуточный транслятор между приложением клиента и собственным интерфейсом конкретных СУБД. Уже сейчас существуют драйверы, которые поддерживают весьма сложные функции средств соединения (например, вызовы удаленных процедур).
Вместе с тем нельзя считать, что применение ODBC само по себе решает все проблемы. Первая и главная проблема - производительность. Как уже говорилось, драйвер клиента играет роль транслятора между API клиента и интерфейсом БД. Однако такой транслятор, как и всякое промежуточное звено, увеличивает накладные расходы системы, добавляя к обычным процессам извлечения и передачи информации сложные операции по идентификации типов данных, их преобразованию, форматированию и транспортировке. К сожалению, большинство предлагаемых драйверов клиента не оптимизировано с точки зрения производительности.
Вторая проблема связана со сложностью протокола ODBC. Производители не всегда могут гарантировать, что данный драйвер будет нормально функционировать в конкретной конфигурации приложение - драйвер - СУБД. Возможно, эта проблема в ближайшее время по мере приобретения разработчиками опыта в использовании ODBC станет менее актуальной.
Наконец, как уже говорилось, весьма важной остается задача обеспечения в драйверах ODBC оптимального использования всех расширений SQL (а значит, и возможностей), предусмотренных на сервере конкретным производителем СУБД.
Другие стандарты средств соединения
Для своих мэйнфреймов на основе SNA (сетевой архитектуры систем - Systems Network Architecture) IBM разработала усовершенствованный интерфейс одноранговой связи между программами - APPC (Advanced Program-to-Program Communications). Он позволяет двум программам обмениваться неформатированными сообщениями, причем программист сам должен определить содержание сообщения и интерпретировать его.
Однако APPC является интерфейсом низкого уровня - он обеспечивает большую гибкость, но за счет очень высокой сложности. Транзакции APPC разрабатывать довольно трудно, поэтому некоторые производители (Gupta, Oracle, IBM) создали на основе APPC свои собственные средства соединения, которые позволяют пользователям в какой-то степени решить проблемы, связанные с использованием интерфейсов низкого уровня.
Большинство новых стандартов, возникших в последнее время, связано с технологией вызова удаленных процедур (RPC - Remote Procedure Call) и обработки распределенных объектов. Основные подходы: DCE - среда распределенных вычислений (Distributed Computing Environment), CORBA - единая архитектура программы-посредника объектных запросов (Common Object Request Broker Architecture) и технология OLE 2.0 фирмы Microsoft (как часть единой объектной модели COM - Common Object Model). Сейчас наметилась тенденция к интеграции систем обработки распределенных объектов, в частности в ближайшее время предполагается выпуск единой спецификации моста между CORBA и COM.
Средства соединения корпорации Gupta (Centura)
Фирмой Gupta (Centura) декларировано обеспечение непосредственного доступа к реликтовым БД на мэйнфреймах из приложений клиент - сервер.
Трудно сказать, насколько актуальна для российских пользователей задача оптимального соединения клиента SQLWindows со "старинными" базами данных на мэйнфреймах IBM (например, с IMS или ADABAS), однако есть основания предполагать, что еще немало крупных российских предприятий работают с корпоративными хранилищами данных на ЕС ЭВМ и не знают, что с ними делать после перехода на сети ПК. Gupta дает такой ответ: включить свое информационное богатство в современную ИС, используя технологию клиент - сервер и продукты SQLNetwork и SQLWindows.
К тому же, похоже, что Gupta считает делом чести обеспечить в будущем с помощью SQLNetwork стопроцентную совместимость своей системы разработки приложений буквально со всеми СУБД, известными цивилизованному человечеству: IMS (российский вариант - "Ока"), ADABAS (российский вариант - ДИСОД), с бесчисленными системами на плоских файлах, начиная со сжатых файлов VSAM (мэйнфреймы) и кончая dBASE-подобными системами на ПК, а также с современными SQL-РСУБД, в первую очередь с такими мощными серверами, как Oracle, Sybase, Informix.
Рассмотрим подробнее основные подходы Gupta.
SQLNetwork
SQLNetwork - это семейство маршрутизаторов и шлюзов для баз данных. Доступ к ним осуществляется через один и тот же интерфейс API - SQLAPI, причем это тот же самый API, который используется и при работе с "родным" сервером Gupta - SQLBase. Приложение клиента взаимодействует c SQLNetwork только через SQLAPI. На рис. 1 показаны некоторые варианты конфигурации средств соединения, предусмотренные в SQLAPI.
Рис. 1 Возможности средств соединения Gupta
Сейчас поддерживаются следующие интерфейсы: Oracle, Sybase, SQLServer, Informix, HP AllBase, Ingres, AS/400, DB2/2 (через шлюз), DB2, транзакции CICS и ODBC.
В состав поставки ПО включены средства соединения для всех серверов, кроме СУБД IBM (об этом исключении говорится далее).
В SQLAPI введена поддержка хранимых процедур Sybase/SQLServer: в SAL для вызова этих процедур предусмотрена функция SqlExecuteProc с тем же механизмом обмена данными между клиентом и сервером, что и в расширении Oracle.
Следует заметить, что SQLAPI не выполняет трансляции операторов SQL. Это означает, что запросы, введенные клиентом, без изменений передаются на сервер БД. Тем самым обеспечивается возможность полностью использовать все расширения SQL, предусмотренные конкретной СУБД. Правда, при этом возникает определенная зависимость от производителя средств. Однако, если вы используете не слишком много разных БД, преимущества такого подхода с лихвой окупают недостатки: при выполнении приложения интерфейс SQLAPI оповещает клиента, с какой БД он в данный момент соединен, поэтому несложно организовать передачу управления к тому или иному сегменту программы в зависимости от текущего сервера.
Работа с мэйнфреймами
В технологии Gupta для доступа к данным IBM применяется шлюз, который выступает в роли диспетчера запросов, поступающих от множества клиентов сети. Направляя эти запросы источнику данных (мэйнфрейму), шлюз использует те же маршрутизаторы сети, что и SQLBase, поэтому при установке шлюза менять ПО мэйнфрейма не надо.
До недавнего времени API для доступа к DB2 из Windows отсутствовал, поэтому Gupta разработала средства маршрутизации APPC для своего хост-модуля (SQLHost), который, собственно, и взаимодействует с DB2. SQLHost поддерживает монитор транзакций фирмы IBM под названием CICS (Customer Information Control System - абонентская информационно-управляющая система), рассчитанный на интенсивный поток транзакций. Единичная операция взаимодействия с DB2 обычно оформляется либо как транзакция CICS, либо как задача виртуального телекоммуникационного метода доступа. В настоящее время поставляются две версии шлюза: одна выполняется как загружаемый модуль NetWare, другая - как процесс ОС OS/2. Завершается работа над третьей версией, которая обеспечит доступ к хосту MVS непосредственно через протокол TCP/IP.
SQLNetwork, SQLWindows и Quest
Одно из главных достоинств средств SQLNetwork - высокий уровень интеграции с системой разработки приложений SQLWindows и другими продуктами Gupta. Работая с SQLNetwork, программист SQLWindows не обязан знать детали БД, к которой он обращается. На рис. 2 показан фрагмент кода SQL (точнее, SAL), который будет работать с любой из баз данных, перечисленных выше, с ODBC, а может быть, как считает автор фрагмента Роберт Браун, и с любым хранилищем данных, известным ныне.
Большинство других средств соединения сравнительно мало отличаются друг от друга и касаются либо производительности, либо переносимости. Поэтому, если вы избрали для разработки приложений SQLWindows, которая максимально интегрирована c SQLNetwork, вряд ли целесообразна ориентация на какие-либо другие продукты. По утверждению эксперта RCMS Computing Services Роберта Брауна, для доступа к DB2 из клиентского приложения SQLWindows через SQLNetwork достаточно написать исходный текст из трех строк (рис. 2), однако для доступа к той же БД и с тем же результатом через другие продукты соединения пришлось бы написать на том же SAL от 20 до 100 строк кода.
В среде Windows имеются механизмы, позволяющие организовать доступ к СУБД из SQLWindows через динамически подключаемые библиотеки (DLL), например External CICS Interface корпорации IBM и Remote Server Call фирмы Tandem. В принципе такие API могут обеспечить более высокую эффективность, чем SQLNetwork, но за счет более высокой стоимости обработки.
В статье использованы материалы журнала Gupta World
Лев Бродский, Евгений Бухштаб, Юрий Шафрин
Рис. 2. Доступ к транзакции CICS из приложения SQL Windows
- Set SQLDatabase = ‘MYDB’
- Call SQLConnect (hSql)
- Call SalTblPopulate (TblData, hSql,‘Select Code, Data from Table’, TBL_FillNormal)
