1. Sybase System 10 – современная высоко-производительная СУБД

Фирма Sybase является одним из ведущих производителей промышленных СУБД.

В начале 1994 года вышла версия Sybase System 10 на основных платформах, в том числе на Sun, HP, IBM RS/6000, DECVAX/VMS, DECAXPVMS, DEC Alpha OpenVMS, DEC Alpha OSF, NCR, NEC, Sequent, Silicon Graphics, Unisys.

В третьем квартале 1994 года выпущена полнофункциональная система 10 на платформах PC-серверов для Novell NetWare, Windows NT, OS/ 2, SCO UNIX. В четвертом квартале нынешнего года выходит новая версия – System 11.

Рассмотрим наиболее интересные компоненты Sybase System 10, свя-занные с распределенной обработкой.

1.1. Технологии распределенной обработки и доставки данных

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

Содержательная сторона задачи обычно требует обмена данными между группами АРМ, так как изменения в какие-либо данные могут вноситься в одной группе (например, в НГДУ), а использоваться они могут в другой (например, в цехе). На практике обмен информацией реализуется регламентной передачей файлов – через модемное соединение или "с курьером".

То, что данные доставляются к месту назначения не системными средствами, а путем экспорта/импорта файлов, приводит к необходимости участия человека в процессе обмена, а это влечет за собой малую оперативность поступления данных и необходимость реализации внешних механизмов контроля целостности и непротиворечивости. В результате возрастает вероятность появления ошибок. Кроме того, реализация всех алгоритмов обмена данными и контроля в этом случае возлагается на прикладных программистов, проектирующих АРМ. Объем работ по программированию и отладке подпрограмм обмена соответствует числу различных АРМ. Это также приводит к повышению вероятности сбоев в системе.

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

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

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

1.2. Двухфазная фиксация

Исторически первым появился метод синхронного внесения изменений в несколько БД, называемый двухфазной фиксацией (2РС, two-phase commit). Этот механизм реализован сейчас практически всеми производителями СУБД.

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

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

1.3. Асинхронное тиражирование транзакций

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

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

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

Вместе с тем асинхронная репликация транзакций принципиально обеспечивает целостность информации, так как объектом обмена данными здесь является логическая единица работы – транзакция, а не просто данные из измененных таблиц.

1.4. Репликационный сервер Sybase

В состав пакета Sybase System 10 входят реляционная СУБД SQLServer 10 и ряд других компонентов – репликационный сервер, отладчик, библиотеки серверной и клиентской части, средства управления и мониторинга и пр.

Репликационный сервер использует асинхронную модель репликации транзакций. Правила репликации проектируются одновременно с разработкой модели данных. Затем проводится конфигурирование системы.

При работе прикладной программы изменения данных отслеживаются системными средствами, и в соответствии с конфигурацией требуемая информация передается в удаленную СУБД (см. рис.1).

Репликационный сервер представляет собой отдельную задачу, запускаемую одновременно с СУБД. Он имеет свой входной язык и стандартный для продуктов Sybase сетевой интерфейс Open Server. Такое разделение снижает нагрузку на СУБД и делает систему в целом более открытой.

Репликация использует интуитивно понятный принцип "публикации" изменяемых данных и "подписки" на изменения.

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

Возможность тиражирования группы записей таблицы означает, в частности, что часть записей может быть первичными данными в каком-то одном узле, а еще часть – в других узлах.

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

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

В узле, содержащем первичные данные, для каждой тиражируемой базы данных запускается специальный модуль – менеджер журнала транзакций (Log Transfer Manager – LTM) Он подключается к серверу БД и получает от него уведомления о завершении транзакций. Измененные данные из журнала передаются репликационному серверу, обслуживающему этот узел. Репликационный сервер в соответствии с описанием тиражирования и подписками отправляет данные в специальном эффективном протоколе по месту назначения, то есть соответствующим репликационным серверам в удаленных узлах.

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

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

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

СУБД, хранящая вторичные данные, может быть любой из ряда доступных через шлюз: будь то Oracle, Informix, Ingres, DB2, RMS, ISAM или даже приложение, созданное в Open Server.

СУБД, хранящая первичные данные, требует наличия менеджера журнала транзакций (далее LTM). Сейчас разработаны LTM для Sybase SQL Server и Oracle; на очереди другие СУБД. Интерфейс LTM является открытым, и в скором времени, возможно, подобные модули будут созданы для нестандартных источников данных.

Вообще, тиражирование данных может найти самое разнообразное применение:

 – для разгрузки сервера, выполняющего активное обновление данных (OLTP) от сложных запросов, связанных с поддержкой принятия решений (decision-support);

 – для консолидации данных от подразделений в центре;

 – для обмена данными по медленным или ненадежным линиям связи,

 – для поддержания резервной базы данных;

 – для построения сети равноправных узлов, обменивающихся данными.

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

1.5. Инструменты управления SQL-сервером

Для анализа функционирования сервера на ЭВМ – клиенте Sybase предоставляет модуль SQL Monitor, представляющий в графическом виде процессы загрузки, ввода/вывода и использования памяти сервером, а также степень интенсивности транзакций.

Для управления сервером предназначен набор хранимых процедур и set-команд Модуль Sybase SQL Server Manager выполняет те же функции, но имеет оконный интерфейс

Для учета информации о действиях пользователей служит модуль Sybase Audit Server, работающий со специальной базой данных, которая доступна для последующего анализа.

1.6. Распределенная обработка и доступ к данным при помощи Sybase OmniConnect

Зачастую в информационных системах (ИС) возникают ситуации, когда требуется обеспечить доступ к источникам данных, которые сами по себе не являются СУБД.

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

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

Компонент OmniConnect, входящий в состав Sybase System10, осуществляет унифицированный доступ приложений к разнородным источникам данных. Специальные шлюзовые компоненты организуют работу в системе с любой промышленной СУБД, включая Oracle и Informix. Приложения-клиенты при этом взаимодействуют только с сервером OmniConnect на диалекте SQL фирмы Sybase (TransactSQL), а необходимая трансляция и преобразование типов данных автоматически осуществляются шлюзовыми модулями.

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

Технология OpenServer, входящая в состав Sybase System 10, на основе имеющихся библиотек позволяет разрабатывать собственные приложения, использующие данные от промышленного оборудования. Для приложения-клиента такие программы "выглядят" как хранимые процедуры на Sybase-совместимом сервере базы данных.

На базе технологии OpenServer реализуется специальный драйвер, обеспечивающий доступ к ODBC-источникам данных. Приложение может подключаться к этому драйверу как к обычному серверу Sybase и выполнять на нем операции TransactSQL Sybase. Драйвер самостоятельно выполняет приведение ????? TransactSQL к стандарту ODBC. Использование подобных драйверов позволяет включать в систему не только промышленные СУБД других производителей, но и desktop-СУБД (dBase, Access и т.д.). Другим примером применения технологии OpenServer может служить реализация доступа к электронной почте.

2. Опыт разработки приложений в технологии "клиент-сервер"

Отметим ряд положений, связанных с проведением разработки сложных информационных систем.

1. Очевидно, что наиболее важным является этап исследования структуры бизнеса автоматизируемого предприятия, когда проводятся следующие мероприятия

 – Формализация бизнес-процессов, имеющих место на предприятии (составляется функциональная модель); анализ функциональной модели и выдача исходных данных для проведения информационного моделирования.

 – Построение информационной модели; выдача рекомендаций по выбору СУБД и ее платформы, а также платформы для рабочих мест клиента.

 – Выдача основных проектных решений.

 – Макетирование экранов основных узлов программного обеспечения рабочих мест системы.

Результатом этапа исследования является готовое техническое задание, содержащее основные проектные решения.

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

3. При разработке системы, несмотря на определяющий фактор используемой разработчиками методологии и накопленного ими опыта, немаловажную роль играет и выбор инструментов. Средства поддержки моделирования должны работать с промышленными СУБД и легко интегрироваться с системой разработки приложений. Поэтому здесь желательно ориентироваться на инструменты одного производителя, чтобы быть уверенным в полной совместимости между СУБД, средством моделирования и системой разработки приложений.

4. Часто при выполнении пилотного проекта большой системы заказчик настаивает на использовании разработчиком "простой" и дешевой СУБД, относящейся к классу серверов для рабочих групп. Такой подход, хотя и понятен авторам, страдает существенными недостатками. Во-первых, кажущаяся близость к стандартам промышленной СУБД при ближайшем рассмотрении таковой не оказывается, что приводит к большим затратам при последующем переходе на промышленную СУБД. Во-вторых, использование СУБД непромышленного класса приводит к тому, что по завершении работы над пилотным проектом оказывается невозможным использование уже разработанного ПО. Для поддержки разработчиков компания Sybase выпускает продукт под названием Workgroup SQL Server, специально предназначенный для групп разработчиков и гарантирующий полную совместимость в SQL Server, реализованных на UNIX-машинах.

5. Средства разработки должны эффективно работать с промышленными СУБД, обеспечивать групповую разработку, а также обладать свойствами масштабируемости. Так, например, приложения, созданные на PowerBuilder, без каких-либо изменений в исходном коде могут быть перенесены в среду Sun Solans или Macintosh.

Московская фирма "АлконсСофт" провела ряд успешных разработок ИС на основе описываемых в статье продуктов и методологий. Например, информационная система рекламного агентства (ИС РА) предназначена для проведения менеджером РА полного цикла работы с клиентом по размещению видеороликов в телевизионных программах. Система разработана на PowerBuilder; для информационного моделирования применялась методология IDEF1X. В качестве СУБД здесь использовалась Sybase System 10.

База данных ИС РА содержит: информацию о расписании передач, расценках; социологические данные, данные по клиентам, договорам и приложениям; и самое главное – информацию по подготовленным медиа-планам и размещениям. Рабочие места менеджеров, социологов-аналитиков и администратора созданы в PowerBuilder. Они содержат сложные экранные и отчетные формы, деловую графику, а также всевозможные интерфейсы (для операций с факсами, импорта данных из социологических подсистем и экспорта результатов в различные документы).

Среди важных функций ИС РА отметим размещение роликов и отслеживание выходов роликов в эфир, централизованный ввод программы передач и нескольких типов расценок, отслеживание бюджета, подготовку медиа-планов на основе социологических данных и сценариев [3].

Другая ИС предназначена для сбора статистической информации и осуществляет подготовку форм статистической отчетности, их контроль и собственно сбор данных от распределенных по территории страны предприятий в центральный офис.

Вся служебная информация собирается централизованно и после изменений автоматически передается на нижние уровни. Алгоритмы контроля проектируются в мини-CASE-компоненте и тиражируются на нижние уровни. Данные по отчетным

формам автоматически передаются в центр. Рабочие места оператора, проектировщика форм и алгоритмов контроля, а также администратора системы также выполнены в PowerBuilder.

ЛИТЕРАТУРА:

1 Тандоев А.Ю. Архитектура продуктов "клиент-сервер" фирмы Sybase СУБДп1. 1995. С. 62-69.

2 Кодд Е.Ф. Реляционная модель данных для больших совместно используемых банков данных СУБД п1. 1995.

3 Chen P.P. The Entity Relationship Model Toward a Unified View of Data // ACM Transactions on Database Systems. 1976. Vol. 1. N 1.

4 Горин С.В., Тандоев А.Ю. Среда разработки приложении PowerBuilder DBMS / Russian Edition. 1995.  N 1.

5 Горин С.В., Тандоев А.Ю. CASE средство S-Designer4.2 для разработки структуры базы данных // Монитор. 1995.  № 7.

(Продолжение следует.)