Ю. А. Григорьев, Г. И. Ревунков - Банки данных

13. Выбор общесистемных пакетов

EXEC SQL declare acur cursor for

select остаток from счет where HOMep=:s;

/* открыть курсор и выполнить запрос к БД*/ EXEC SQL open acur;

/* получить остаток */ EXEC SQL fetch acur into :d; if (SQLCODE!=SQL_OK) {

/* произошла ошибка, направить в VIEW-буфер сообщение об ошибке */ strcpy(transv->ermsg, «ошибка при чтении остатка и таблицы СЧЕТ»); EXEC SQL close acur;

tpreturn(TPFALL, 0, transb->data, sizeof(struct aud), 0);

}

else{

/* операция поиска выполнена успешно */ EXEC SQL close acur;

transv->ocTaTOK=d;

tpreturn(TPSUCCESS, 0, transb->data, sizeof(struct aud), 0);

}

}

Мультиплексирование запросов к базам данных. Tuxedo System мож­ но рассматривать как своеобразный программный мультиплексор запросов к базам данных.

Принципы обращения клиентов приложения к БД в системах, опи­ рающихся на менеджеры транзакций, совершенно иной, чем в двухзвенных системах «SQL-клиент—SQL-сервер». В последних существует понятие одновременных подключений к БД (concurrent connection). Процесс клиента считается подключенным к СУБД, начиная с момента открытия сеанса с БД (инициируется оператором CONNECT) и заканчивая его закрытием. Опера­ ция CONNECT является ресурсоемкой, выполняется медленно и не реко­ мендуется для частого использования. В течение сеанса СУБД считает кли­ ента активным и вынуждена хранить контекст его подключения даже в том случае, если клиент вообще не направляет запросов СУБД, а выполняет свои внутренние функции или, может быть, ушел пообедать. Схема взаимо­ действия клиента и сервера БД выглядит следующим образом: клиент и сервер открывают SQL-канал на весь период работы клиента (инициирует открытие канала клиент) и обмениваются по нему SQL-запросами и данны­ ми в синхронном режиме. В лицензионном соглашении на использование СУБД под количеством пользователей, от которого зависит стоимость ли­ цензии, подразумевается число одновременных подключений к СУБД кли­ ентских процессов. Возможны вариации (для различных СУБД лицензион­ ное соглашение выглядит по-разному), но суть остается одной.

Совершенно иначе выполняется подключение клиентов в системах с трехзвенной архитектурой. Клиент вообще не обращается к базе данных —

290

13.2. Варианты выбора распределенной СУБД

он ее «не видит». Клиент обращается с запросами к серверу приложений в одном из допустимых режимов. Взаимодействие клиента и сервера прило­ жений контролирует Tuxedo System/T. Подключение к System/T (начало сеанса) выполняется вызовом tpinit(), терминирование связи (завершение сеанса) производится вызовом tpterm().

Подключение клиентов к СУБД выполняется сервером приложений, а взаимодействие с БД (выборка, обновление) проводится в рамках сервисов. Схема работы выглядит следующим образом. Клиент приложения подклю­ чается к Tuxedo System/T, формирует исходные данные в буфере и вызыва­ ет сервис, передавая ему данные в буфере. Сервис, в свою очередь, извлека­ ет данные из буфера и формирует SQL-запрос, который направляется соот­ ветствующему менеджеру ресурсов (СУБД). Получив от него данные, сер­ вис размещает их в результирующем буфере и направляет его клиенту. Единственные исполнители прикладных действий — сервисы — не моно­ полизируются каким-либо клиентом, а доступны для общего использования всеми клиентами. При каждом вызове сервиса создается внутренний поток в рамках процесса, содержащего сервис.

Таким образом, для систем с трехзвенной архитектурой, работающей под управлением Tuxedo, не существует ограничений на число клиентов. Это и объясняет применение менеджеров транзакций (и Tuxedo в том числе) для систем, характеризуемых сверхбольшим числом клиентов (от сотен до тысяч). Кроме того, в системах с трехзвенной архитектурой резко сокраща­ ется число одновременных подключений к СУБД (что существенно умень­ шает стоимость лицензии на ее использование). Как уже говорилось, клиен­ ты к СУБД не подключаются. Подключение к СУБД производится процес­ сом сервера приложений (от каждого процесса по одному подключению). Каждый такой процесс одновременно обрабатывает N запросов, поступаю­ щих от клиентов. А количество лицензионных подключений к СУБД опре­ деляется общим числом процессов (серверов), включенных в приложение, и не зависит от числа обрабатываемых в текущий момент запросов от клиен­ тов. Опубликованные данные свидетельствуют о том, что количество под­ ключений к СУБД в системе с трехзвенной архитектурой по сравнению с традиционной технологией применения СУБД может быть уменьшено в 4—16 раз, а выигрыш в стоимости от приобретения менеджера транзакций и СУБД по сравнению с приобретением только СУБД с лицензией на большее число пользователей может достигать 50 %.

Интероперабельность распределенных СУБД: возможность соз­ дания разнородной информационной среды. Шлюзы для доступа к раз­ нородным базам данных. Как отмечалось, шлюзы обеспечивают возмож­ ность приложений, созданных средствами разработки данной СУБД, опери­ ровать над БД в «чужом» формате так, как будто это собственные БД.

На рис. 13.8 представлена схема организации гетерогенной среды с помощью шлюза OmniConnect фирмы Sybase.

291

	13. Выбор общесистемных	пакетов
Server	Server	Server
Oracle	Sybase	Informix
Шлюзовой	OmniConnect	Шлюзовой
компонент		компонент
Sybase		Sybase
ж		Ж

SQL

WS

Рис. 13.8. Связь разнородных СУБД с помощью шлюза OmniConnect

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

На рис. 13.9 приведена схема организации связи разнородных СУБД с помощью шлюза Informix-Enteфrise Gateway фирмы Informix.

Шлюз Informix-Enterprise Gateway обеспечивает для инструменталь­ ных средств и приложений БД, выполняемых под управлением операцион­ ной среды Unix или MS Windows, доступ к информации, хранящейся в БД — более 60 типов (среди которых Oracle, Sybase, Ingres, Adabas, IMS, VSAM, CA-IDMS и др.). Поддерживаемые операционные системы — Unix, MVS, VM, VMS. Доступ реализуется при помощи программных продуктов Enter­ prise Data Access SQL (EDA/SQL) компании Information Builders. Шлюз позволяет выполнять распределенные соединения таблиц из разнородных БД и импортировать «чужие» данные в БД Informix.

Enterprise Gateway выполняется как процесс сервера СУБД Informix, который конвертирует запросы клиентов Informix в запросы EDA/SQL. Ко­ гда от клиентского приложения поступает инструкция SQL или удаленный вызов процедуры, предназначенный для Enterprise Gateway, то он перена­ правляется на EDA/SQL Server, который обращается к соответствующим реляционным или нереляционным источникам данных. Данные, полученные от EDA/SQL Server, Enteфrise Gateway возвращает приложению клиента.

292

J3.2. Варианты выбора распределенной СУБД

Server	Server			Server
Oracle		Informix		Sybase
		Informix-
EDA/SQL	Еп1ефг18е Gate­
		way		EDA/SQL
7^	1	^	\	^—A

S(?L

WS

Рис. 13.9. Связь разнородных СУБД с помощью шлюза Infoпllix-Enteфrise Gateway

На рис. 13.10 представлена схема организации связи разнородных СУБД на базе шлюзов Oracle Transparent Gateways и Oracle Procedural Gateways.

Независимость от источников данных, как важная составляющая откры­ тости Oracle, реализована двумя наборами продуктов: Oracle Transparent Gate­ ways (прозрачные шлюзы) и Oracle Procedural Gateways (процедурные шлюзы). Прозрачные шлюзы обеспечивают доступ из SQL к БД и файловым системам

— DB2, Rdb, ADABAS,ГОМ8,IMS, SQL/DS, SQL/400, VSAM и плоским фай­ лам. Процедурные шлюзы реализуют интерфейс с мониторами транзакций, операционными системами и внешними приложениями из языка PL/SQL.

ОВВС-интерфейс доступа прплоэюений к различным серверам СУБД.

Фирма Microsoft разработала специальный интерфейс ODBC (Open Data­ Base Connectivity), позволяющий Windows-приложениям рабочих станций обращаться к различным СУБД, поддерживающим как модель сервера БД (Oracle, Sybase, Informix и др.), так и модель файлового сервера (dBase, Paradox) (рис. 13.11).

ODBC-интерфейс представляет набор функций для языка С, C++ и Visual Basic для Windows. Связь с СУБД осуществляется с помощью языка SQL (даже с СУБД, поддерживающими модель файлового сервера). С по­ мощью функции SQLConnect приложение может подключиться к различ­ ным СУБД. Далее в программе должна быть подготовлена строка с опера­ тором SQL. Функция SQLExecute выполняет этот оператор, обращаясь че­ рез ODBC-драйвер к требуемой СУБД. Оператор SQLFetch читает результа­ ты выполнения SQL-предложения в ПП.

Комплексы драйверов ODBC предлагают и независимые разра­ ботчики. Этот стандарт обеспечивает эффективные средства доступа к

293

	13. Выбор общесистемных		пакетов
	Server
	Монитор	Oracle
	транзакций
Server		Oracle	Server
			PL/SQL
Informix	Сервис К	Procedural
		Gateways	Sybase
Шлюзовой		Oracle	Шлюзовой
компонент		Transparent	компонент
Oracle		Gateways	Oracle
ж			Ж

SQL

WS

Рис. 13.10. Связь разнородных СУБД с мониторами транзакций с помощью шлюзов Oracle

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

SQL3 — объектно-реляционное расширение языка SQL. Реляци­ онный подход, используемый в современных СУБД, имеет ряд преиму­ ществ:

•реляционные БД построены на солидном теоретическом основании (теория реляционной алгебры);

•реляционная технология подкреплена стандартами, которые одобре­ ны ISO и ANSI (SQL/89 и SQL/92).

В то же время можно отметить недостатки реляционной технологии.

1.Данные описываются только в виде таблиц, связи между таблицами должны быть явно указаны в ПП (конечно, желательно оформить эти про­ граммы в виде методов классов).

2. Реляционные БД предлагают ограниченное множество типов атри­ бутов (с помощью классов можно описывать произвольные типы классов).

3. Реляционная модель не позволяет рассматривать данные послойно, при необходимости отвлекаясь от ненужных деталей (при объектном под­ ходе в поле можно хранить ссылку на запись другой таблицы).

294

13.2. Варианты выбора распределенной СУБД

Oracle	Windows-приложение			dBase	Sybase	Informix
	Менеджер драйверов
	ODBCODBCODBC-			ODBC-
	драйвер	драйвер	драйвер	драйвер
	Oracle	Informix	Sybase	dBase
А				>	A	A
	iл	А	Л
						'I*

Рис. 13.11. Доступ Windows-приложений к различным СУБД

4.В реляционной модели усложнен интерфейс между языком про­ граммирования и языком баз данных: С-курсор-SQL (при объектном подхо­ де объекты встроены в язык программирования).

Перечисленные ограничения реляционной модели можно преодолеть

спомощью объектно-ориентированного подхода. Ниже перечислены ос­ новные свойства объектов (не только для СУБД).

1.Инкапсуляция — совокупность данных и операций (методов). Что­ бы активизировать объект, необходимо послать сообщение какому-либо его методу.

2.Наследование — возможность создавать из объекта новый объект, который наследует данные и методы своего предшественника. Например, объект Сотрудник (номер, местоработы, зарплата) может наследовать дан­ ные объекта Человек (пол, возраст, имя).

3.Полиморфизм — различные объекты могут получать одинаковые сообщения, но реагировать на них по-разному, в соответствии с их метода­ ми, реагирующими на сообщения. Например, на сообщение «нарисовать» объекты «прямая» и «окружность» отреагируют по-разному.

Некоторые СУБД (например, UniSQL 3.5 фирмы UniSQL) уже ис­ пользуют объектно-ориентированную МД, которая является расширением реляционной МД. Такие СУБД часто называют объектно-реляционными. Основой расширения служит примерная равнозначность схемы отношения (таблицы) и класса. Объектно-реляционная модель расширяет реляционную МД следующим образом:

• атрибутом может выступать ссылка на кортеж (запись) другого от­ ношения (таблицы);

295

13.Выбор общесистемных пакетов

•расширение свойств отношений (к атрибутам добавляются методы);

•каждая схема отношения (таблица) расширяется системным атрибу­ том, значение которого является уникальным идентификатором объекта;

•классы (схемы отношений) организуют иерархию, исходя из соот­ ношения общее/частное (род/вид) между парами классов;

•разрешается рекурсивно наследовать свойства класса всем его под­ классам. В подкласс можно добавлять дополнительные атрибуты и методы;

•допускается доступ к атрибутам и методам класса только посредст­ вом сообщений.

Стандарт для построения объектно-реляционных СУБД определяет расширение языка SQL и называется SQL3. Рассмотрим особенности SQL3 подробнее.

Описание классов (инкапсуляция). Класс соответствует схеме отноше­ ния (таблице) реляционной модели. Класс можно описать двумя способами:

1.Описание класса Address:

create type Address (city char(30), state char(2), street char(30), house integer,

flat integer);

Объект Addr класса Address создается с помощью следующего оператора: create table Addr of Address;

2. Совмещенное описание класса Person и создание объекта People (экземпляра класса). Класс Person включает и описание методов:

create table People of new type Person

(
/* описание полей */
name char(30),
address Address,	/* ссылка на кортеж типа Address */
birthdate date,
/* описание методов (функций) */
age virtual,	/* функция age является виртуальной,
	т.е. другая функция с тем же именем
	может быть описана в подклассе */
function age (:р ref(Person))		/* параметр :р есть ссылка (ref)
		на кортеж Person */
returns interval day;		/* функция возвращает возраст
begin		с точностью до дня */

return currentdate — :p.birthdate;

296

13.2. Варианты выбора распределенной СУБД

end;

);'

Наследование определяется с помощью фразы under. Ниже описан класс Employee, который наследует данные и методы класса Person. При обработке записей Employee используется метод age, описанный в этом подклассе, так как он представлен как виртуальный:

create type Employee under Person

(
/* описание полей */
salary float,
job char(20),
manager Employee,	/* рекурсивная ссылка на кортеж Employee */
/* описание методов (функций) */
age virtual,	/* функция age является виртуальной */
function age (:р ref(Employee))		/* параметр :р есть ссылка
		(ref) на кортежemployee */
returns interval year;	/* функция возвращает возраст с точностью
begin	до года*/

return currentdate — :p.birthdate; end;

);'

Создание объекта Empl класса Employee: create table Empl of Employee;

Описание метода. Метод (функцию) можно задавать индивидуально для каждого кортежа (в операторе INSERT). Если метод описан как вирту­ альный, то при переходе к записям подкласса система автоматически пере­ ключается на одноименный метод, описанный в подклассе.

На рис. 13.12 представлено описание связей между объектами (табли­ цами) People, Empl и Addr.

Объектно-реляционный подход значительно расширяет возможности использования поисковых операторов. Рассмотрим два примера.

1. Использование путей и методов в операторе SELECT. Выдать име­ на сотрудников старше 50 лет, проживающих в Лондоне и имеющих управ­ ляющего по имени Джонс:

SELECT	e.name
FROM	Empl e /* e — это псевдоним объекта Empl */
WHERE	e.age>50 AND e.address.city='Лoндoн' AND
	e.manager.name='fl^oHc';

297

13. Выбор общесистемных пакетов

People	Ссылка .
	Addr
	city
name	state
address - ^	street
age	house
	flat

— Наследование

Empl Y

name address

salary job

_ manager

age(так как фун1сция описана как виртуальная)

Рис. 13.12. Связи между объектами примера

Здесь используют два пути (e.address.city и e.manager.name) для дос­ тупа по ссылке к полям других кортежей и метод age. При обращении к методу age система автоматически подставляет в качестве аргумента этой функции ссылку на текущий кортеж Empl.

2. Использование полиморфизма объектов. Выдать возраст всех со­ трудников с точностью до года, а остальных лиц, описанных в People, — с точностью до дня:

SELECT p.age FROM All People p;

Здесь All означает, что просматриваются кортежи класса (People) и подкласса (Empl).

Возможности технологии брокера объектных запросов. Брокер объектных запросов (Object Request Broker — ORB) — это строительные блоки, неоднократно используемые при разработке масштабируемых про­ граммных систем. В ORB реализуются методы, позволяющие одним объек­ там обнаруживать другие и обращаться к ним с запросами по сети, незави­ симо от платформы, на которой исполняется каждый из объектов, и от язы­ ков программирования, посредством которых они были созданы.

Консорциум производителей программного обеспечения Object Man­ agement Group (OMG) установил некоторые из ключевых стандартов, обес-

298

13.2. Варианты выбора распределенной СУБД

печивающих возможности взаимодействия объектов. Утвержденная им спе­ цификация CORBA (Common Object Request Broker Architecture) послужила основой для создания такими производителями, как IBM, Sun Microsystems, Hewlett-Packard, lona Technologies и ExperSoft, программных продуктов, благодаря которым корпоративные разработчики могут создавать распреде­ ленные объектные системы, включающие в себя и унаследованные прило­ жения.

ORB является одним из пяти основных видов программного обеспе­ чения промежуточного слоя. Остальные четыре: связи с БД (database con­ nectivity), системы распространения сообщений (Message-Oriented Middle­ ware — MOM), мониторы обработки транзакций (Transaction Processing (ТР) monitor) и системы, основанные на технологии удаленного вызова про­ цедур (Remote Procedure Call — RPC).

Подобно другим видам программного обеспечения промежуточного слоя, ORB в распределенных вычислительных системах с архитектурой клиент/сервер выполняет ту же роль, что и коммуникации в небоскребе. Обычно программное обеспечение ORB пишется на языке C++ и поддержи­ вает объекты, написанные на C++, Smalltalk и Java.

CORBA представляет собой среду для различных реализаций ORB, поддерживающих общие сервисы и интерфейсы (рис. 13.13), что обеспечи­ вает мобильность клиентов и объектов по отношению к различным реали­ зациям ORB и интероперабельность компонентов глобального объектного пространства.

Определения интерфейсов объектов могут быть помещены в репозиторий интерфейсов (Interface Repository), который представляет компонен­ ты интерфейсов для конкретных языков и обеспечивает доступ к объектам в период выполнения.

При формировании заявки клиент может использовать два интерфейса:

•интерфейс динамического вызова;

•стаб, генерируемый компилятором IDL (Interface Definition Language — язык определения интерфейсов); стаб (stab) — это локальная процедура вызова заданной операции при обращении к ней.

ORB ищет соответствующий код реализации объекта, посылает ему параметры заявки и передает управление (как правило, на другом узле). Реализация объекта принимает параметры заявки через сгенерированный компилятором IDL скелетон (skeleton) и при этом может обращаться к объ­ ектному адаптеру (Object Adapter) и ORB. Скелетон — это специфический для каждого интерфейса компонент ORB, служащий для передачи парамет­ ров заявок конкретным методам. Когда обработка заявки завершена, выход­ ные значения возвращаются клиенту. Объектный адаптер является основ­ ным средством взаимодействия ORB с реализацией объекта.

Различные ORB могут иметь разную реализацию и поддерживать раз­ личные объектные механизмы. В структуре ORB выделяется ядро, обеспе-

299