ADABAS - основа семейства программных продуктов фирмы Software AG для создания корпоративных баз данных

И.В.Брусенков, В.А.Кондратенков, В.Д.Силин - Software AG

1. Общие сведения о современном состоянии

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

Не первая нормальная форма (NF2 - Non-First Normal Form)

Эта модель данных (рис. 1)традиционна для ADABAS с 1969 года, когда он впервые вышел на рынок систем обработки данных, по ней большинство пользователей и знает эту СУБД. Его сегодняшнее название ADABAS C.


Простая группа		Периодическая группа

	Множественное поле
			Множественное поле периодической группы

Рис. 1. Традиционная модель данных ADABAS

Традиционная реляционная модель данных

Эта модель соответствует ANSI/ISO стандарту SQL и реализована в виде либо надстройки над ADABAS-C, либо как неотъемлемая часть ADABAS D.

Модель данных сущность-связь (E/R модель)

В ADABAS предусмотрено расширение до модели Entity-Relationship (или E/R модели) для управления сложными структурами данных с высокой степенью связности. Оно поддерживает также рекурсивные структуры данных.
Объединяя эту модель с другими моделями ADABAS можно строить мощные интегрированные базы данных и, соответственно, прикладные системы. Предпочтительные области для применения этих моделей - системы представления знаний, моделирование поведения сложных технических и биологических систем, расчеты потребностей, планирование материальных ресурсов различного вида и назначения (Bills of Materials).

Обработка и управление произвольными текстами

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

Обработка и управление географическими данными

В отличие от традиционных географических (картографических) систем, которые используют структуры хранения данных (реляционные и др.) независимо от собственно географической информации, обеспечивая их совместное использование, как правило, только на уровне SQL- интерфейса, подход SOFTWARE AG характеризуется глубокой интеграцией на всех уровнях хранения и обработки.
Картографическая информация, координатные привязки объектов, форматированные данные и текстовая информация неограниченного объема хранятся в рамках единой БД. Точно также в рамках одной программы и даже одного оператора (среда NATURAL) интегрирована и обработка этой комплексной информации. Важно, что при этом обеспечивается не только высокая производительность геоинформсистем, но за счет поддержания логики транзакций гарантируется целостность и безопасность хранения базы данных и другие ее неотъемлемые характеристики.

2. ADABAS в корпоративных информационных системах

По классификации Gartner Group (рис. 2)peализация концепции клиент/сервер в распределенной неоднородной вычислительной среде возможна в следующих конфигурациях:

распределенное отображение данных;
удаленное отображение данных (эмуляция терминала);
распределенное приложение (серверы приложений);
доступ к удаленной базе данных (серверы баз данных);
доступ к распределенной базе данных (интеграция/репликация баз данных).

Модели клиент-сервер Источник:Gartner Group


					Клиент
					Сервер
Распределенное отображение данных	Удаленное отображение данных	Распределенное приложение	Доступ к удаленной базе данных	Доступ к распределенной базе данных	Сервер

Рис. 2. Классификация архитектур клиент/сервер

SOFTWARE AG использует этот подход для поддержки прикладных проектов, предлагая широкий набор собственных программных продуктов.
С целью интеграции в приложения функциональности программных средств других фирм соблюдены многочисленные интерфейсы, получившие общее признание.

Конфигурации программно-технических средств

Программно-технические средства для реализации распределенных клиент-серверных приложений, поддерживаемых продуктами Software AG, могут включать в себя следующие компоненты:

главные ЭВМ (ГЭВМ) верхнего уровня системы (типа IBM mainframe, UNIX- суперсерверы);
серверные ЭВМ (CЭВМ) среднего и малого классов (UNIX-серверы, OS/2, Windows NT);
блоковые (типа IBM 3270) и символьные (типа VT 100 или ASCII) терминалы;
низкопроизводительные ПЭВМ (типа IBM PC/XT/286/386-MS DOS);
высокопроизводительные ПЭВМ (типа IBM PC/486/Pentium-MS Windows, OS/2);
опорную сеть и протоколы (FDDI/Ethernet и/или TCP/IP, SPX/IPX и др.);
программные продукты других фирм для доступа к базам данных, обработки и коммуникации, поддерживающие общепризнанные протоколы межпрограммного взаимодействия и связные протоколы (ORACLE, INFORMIX, SYBASE, NOVELL, IBM, MICROSOFT и др.).

Удаленное отображение данных (эмуляция терминала)

Средства эмуляции терминалов исторически являются одними из первых продуктов, реализующих возможность совместного функционирования ГЭВМ, СЭВМ и ПЭВМ. Они по-прежнему остаются одними из наиболее популярных продуктов, особенно для удаленного администрирования ресурсами ГЭВМ и СЭВМ.
SOFTWARE AG предлагает использовать в качестве эмулятора терминалов продукт ENTIRE CONNECTION (рис. 3).

ГЭВМ (IBM)	СЭВМ (UNIX)

MS Windows

Рис. 3. Взаимодействие компонент эмуляции терминалов с ENTIRE CONNECTION

Распределенное приложение (серверы приложений)

Характерной чертой таких приложений является логическое разделение приложения на две или более частей, каждая из которых может выполняться на разных компьютерах. Выделенные части приложения взаимодействуют друг с другом, обмениваясь сообщениями в заранее согласованном формате. Следует подчеркнуть, что в данном случае клиентом может быть не только Windows-приложение, но и приложение (или его часть), выполняемое на одной из платформ СЭВМ.
Для создания среды выполнения распределенных приложений SOFTWARE AG предлагает использовать продукт ENTIRE BROKER, который может быть установлен на платформе любой СЭВМ (IBM, UNIX и т.д.) изолированно (рис. 4) или на одной или нескольких СЭВМ совместно с серверами приложений.

ЭВМ 1		ЭВМ N

Windows PC	UNIX	IBM	OS/2, NT
Платформы клиентов

Рис.4. Инфраструктура среды распределенных приложений

Данный продукт предлагает коммуникационный интерфейс, с помощью которого части (или разные) приложения могут обмениваться информацией. Функции интерфейса поддерживают синхронное и асинхронное взаимодействие приложений, при этом, первый тип наиболее подходит для реализации диалоговых систем, тогда как второй - для систем типа запрос/ответ или предполагающих обмен большими объемами данных.
С точки зрения архитектуры продукт ENTIRE BROKER выполнен в виде ядра - коммуникационного сервера, регистрирующего доступные в сети серверы приложений (функциональные серверы) и клиентов, запрашивающих данные серверы.
Взаимодействие клиентов ENTIRE BROKER с ядром базируется на еще одном продукте SOFTWARE AG - ENTIRE NET-WORK, с помощью которого взаимодействие частей приложения становится полностью независимым от используемого в системе транспортного протокола.
В качестве языков, на которых может быть разработано приложение, использующее как возможности обращения к функциональным серверам (клиенты), так и собственно функциональные серверы, могут быть использованы наиболее распространенные языки, поддерживающие CALL-интерфейс.

Рекомендуемый SOFTWARE AG подход к построению распределенных приложений состоит в разработке их частей на NATURAL, в котором имеется полный набор компонентов, необходимых для построения распределенных приложений не зависящих от аппаратно-программных платформ.
Сочетание ENTIRE BROKER, ENTIRE NET-WORK и NATURAL обеспечивает прозрачность для клиентов местонахождения сервера (необходимо знать только своего брокера), создавая администраторам прикладных систем условия для их правильного масштабирования.

Доступ к удаленной базе данных (серверы баз данных)

Доступ к удаленным базам данных (серверу базы данных) предполагает, что приложение, взаимодействующее с базой данных не должно меняться в зависимости от того, в каком узле сети находится сервер базы данных.
При этом, существенную роль начинает играть язык, на котором приложение взаимодействует с СУБД. За последние годы развитие получил язык SQL, ставший фактически промышленным стандартом в мире открытых систем.
Реализация принципа независимости приложений от источников (серверов) данных, нашло решение в виде уже упоминавшегося выше продукта ENTIRE NET-WORK, обеспечивающего универсальный транспорт запросов от приложения до серверов баз данных.
Установка этого продукта на каждом из узлов сети как на платформах серверных ЭВМ, так и рабочих станций клиентов, обеспечивает доставку запросов и данных между серверами баз данных ADABAS и их клиентами.
На следующих схемах изображены варианты доступа к базам данных ADABAS, расположенных на различных серверных платформах из приложений-клиентов на рабочих станциях.
Изображенные на рис. 5 конфигурации являются стандартными для доступа к серверам баз данных ADABAS со стороны клиентов на рабочих станциях под Windows.

Платформа клиентов (MS Windows)

Рис. 5. Схемы удаленного доступа к БД ADABAS посредством SQL

В случае, если прикладная система написана на NATURAL или языках 3-го поколения с использованием языка манипулирования данными (ЯМД) СУБД ADABAS, доступ к удаленной СУБД реализуется в соответствии с рис. 6.

Платформы клиентов
Платформа СЭВМ (UNIX, IBM)

IBM, UNIX, MS Windows	MS Windows

Рис. 6. Схемы удаленного доступа к БД ADABAS посредством ЯМД ADABAS

Данный интерфейс предлагается фирмой SOFTWARE AG в качестве основного при разработке переносимых приложений в среде ADABAS/NATURAL.
Как видно из рисунка клиентами СУБД ADABAS могут быть не только приложения, выполняемые в среде рабочих станций, но и приложения, написанные на NATURAL или языках программирования 3-го поколения и выполняемые как под Windows, так и в среде IBM и UNIX.
Дополнительно к основному интерфейсу языка манипулирования данными для платформы Windows SOFTWARE AG предлагает доступ к базам данных ADABAS с помощью DDE- протокола, оформляя доступ к СУБД в виде DDE-сервера (ADADDE). Некоторые примеры программных продуктов, поддерживающих DDE-протокол, также приведены на рис. 6.
Наряду с удаленным доступом к базам данных ADABAS, SOFTWARE AG предлагает использовать продукт ENTIRE ACCESS для доступа к реляционным базам данных третьих фирм из приложений, написанных на NATURAL (рис. 7).

Рис. 7. Схемы удаленного доступа к реляционным СУБД с помощью ENTIRE ACCESS

ENTIRE ACCESS позволяет разработчику приложений полностью использовать преимущества NATURAL как универсального инструментария разработки переносимых приложений в средах неоднородных баз данных, обеспечивая доступ не только к удаленным, но и к локальным (работающим на той же ЭВМ, что и приложение) реляционным базам данных других фирм.
Предоставляемый этим продуктом интерфейс позволяет разработчику приложений на NATURAL применять для доступа к реляционным СУБД, наряду с ANSI SQL, синтаксис ЯМД, реализованный в NATURAL для доступа к базам данных ADABAS.
При этом из одной программы NATURAL возможно обращение к нескольким реляционным СУБД разных изготовителей и работающим на разных платформах.
Внутренняя исполнительная система NATURAL преобразовывает предложения ЯМД и SQL в вызовы ENTIRE ACCESS, выполняющего необходимые преобразования форматов данных и обмен сообщениями с соответствующей СУБД.
В качестве транспорта запроса к удаленной РСУБД применяется продукт ENTIRE NET- WORK.

Доступ к распределенной базе данных (интеграция/репликация данных)

Среда распределенных баз данных в рамках проектов корпоративных систем предполагает возможность синхронизации изменений, производимых в отдельных фрагментах таких баз данных, путем автоматического распространения транзакций изменений по узлам сети ( репликация данных).
SOFTWARE AG включила XA-интерфейс (спецификация X/Open XO/CAE/91/300) в продукт ADABAS версии 2.2 для ряда платформ UNIX и операционных систем IBM mainframe.
Продукт ENTIRE TRANSACTION PROPAGATOR поддерживает репликацию данных, предоставляя возможность распространения транзакций изменений в среде баз данных ADABAS.
В отличие от схем с двухфазовой фиксацией транзакции, требующей постоянной доступности всех вовлеченных в транзакцию ядер СУБД (узлов), репликаторы данных требуют доступности только одного ядра, называемого главным (рис. 8). Изменение файлов, на главном узле выполняется синхронно с обработкой.

Рис. 8. Концепция репликации данных

Главный узел может находиться под управлением IBM или UNIX-ЭВМ. Узлы-реплики могут располагаться на любой платформе серверных ЭВМ, на которой может быть установлен ADABAS, и которая может быть доступна через ENTIRE NET-WORK.
В состав продукта входит административная компонента, использующая специальные файлы главной СУБД, где создаются описания главных файлов и файлов-реплик, а также связанные с ними файлы журналов изменений и файлы подтверждения.
Файл подтверждения необходим для регистрации ранее выполненных транзакций в файлах- репликах.
Файл-реплика может быть полной или выборочной копией главного файла в зависимости от условий репликации, задаваемых администратором распределенной базы данных.
Процесс репликации может быть инициирован вручную, с помощью специальной диалоговой утилиты, выполняться по таймеру в пакетном режиме, либо запускаться автоматически, при завершении транзакции в главном узле.
Для обеспечения целостности данных используются стандартные механизмы обеспечения целостности транзакций ADABAS, что требует присутствия в одной базе данных главного файла и соответствующего ему файла журнала изменений. Аналогичные условия налагаются и на файлы- реплик и связанные с ними файлы подтверждения.

[Назад] [Содержание] [Вперед]