Развитие систем управления базами данных

СОДЕРЖАНИЕ: Тенденция развития систем управления базами данных. Иерархические и сетевые модели СУБД. Основные требования к распределенной базе данных. Обработка распределенных запросов, межоперабельность. Технология тиражирования данных и многозвенная архитектура.

Введение

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

Распределенные базы данных

По общему мнению, Россия и другие страны СНГ, обладая большой территорией, просто обречены на создание и развитие информационных систем на основе распределенных баз данных. Не секрет, что практически все преуспевающие средние и крупные региональные компании имеют свои представительства в Москве и/или Петербурге. Поэтому при управлении такими предприятиями не обойтись без сложных корпоративных распределенных информационных систем. Ярким примером распределенной базы данных является система DNS:

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

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

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

Первые иерархические и сетевые СУБД были созданы в начале 60-х годов прошлого века. Причиной послужила необходимость управления огромным количеством записей, связанных друг с другом, как правило, иерархическим образом (обслуживание выборов, переписей населения, моделирование ядерных испытаний, погодных и геологических явлений, информационное обеспечение космических полетов и т. д.). Причиной выбора иерархической модели во многом послужило ее подобие уже имевшимся и хорошо отработанным и освоенным на практике многочисленным массивам информации на неэлектронных носителях (банки данных, картотеки, досье, справочники). Среди реализованных на практике СУБД этого типа следует отметить системы IMS (Information Management System) компании IBM, а также TDMS (Time-Shared Date Management System) компании Development Corporation; Mark IV Multi — Access Retrieval System компании Control Data Corporation; System — 2000 разработки SAS-Institute.

Отношения в иерархической модели данных организованы в виде совокупностей деревьев, где дерево — структура данных, в которой тип сегмента потомка связан только с одним типом сегмента предка (рис. 1.1).

Рис. 1.1. Иерархическая модель БД

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

Сетевая модель данных — это представление сетевыми структурами типа запись данных, связанных отношениями «один - к – одному» или «один - ко – многим» (рис. 1.2). Основная идеология и стандартные требования к этой модели были разработаны комитетом Database Task Group (DTBG) на рубеже 60—70-х годов. Впервые сетевая архитектура была реализована в СУБД Integrated Data Store (IDS) компании General Electric и IDMS компании Computer Associates.

Рис. 1.2. Сетевая модель БД

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

Сетевая модель допускает также использование в базах данных связей «многие - ко – многим». Это позволяет устранить многие недостатки иерархической модели, такие как: низкую приспособленность к описанию данных неиерархической структуры и слабую гибкость при развитии системы.

Реляционная модель была описана в 1970—1971 годах в работах Е. Ф. Кодда. Она основана на процедурном языке обработки таблиц данных и языке запросов. В сетевой и иерархической моделях использовались жесткие физические подходы к связыванию записей из разных файлов путем применения физических указателей или адреса на диске. Такие базы существенно затрудняют и ограничивают операции над данными. Кроме того, является очевидным, что иерархические и сетевые базы данных весьма чувствительны к аппаратным изменениям. Перенос данных с одного накопителя на другой, или вообще Изменение числа приводит к необходимости внимательно и кропотливо изменять адреса в связях записей на новые. Также такие модели чувствительны к реструктуризации самой базы (добавление или удаление новых полей приводит к изменению физических адресов записей). Все эти проблемы преодолела реляционная модель, основанная на логических отношениях данных. Именно реляционная модель породила все современные известные СУБД, ее детищем является SQL, благодаря использованию реляционной модели возможно создание распределенных баз данных.

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

Согласно принципам, изложенным в трудах известного ученого Дейта, можно выделить:

12 основных требований к распределенной базе данных (они же являются основными признаками)

* локальная автономия (local autonomy);

* децентрализация (no reliance on central site);

* непрерывность операций (continuous operation);

* прозрачность расположения (location independence);

* независимая фрагментация (fragmentation independence);

* независимое тиражирование (replication independence);

* обработка распределенных запросов (distributed query processing);

* обработка распределенных транзакций (distributed transaction processing);

* независимость от оборудования (hardware independence);

* независимость от операционных систем (operationg system independence);

* прозрачность сети (network independence);

* независимость от СУБД (database independence).

Рассмотрим каждое из этих требований подробнее.

Локальная автономия

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

Децентрализация

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

В распределенных БД поддержка целостности и согласованности данных, в свете предыдущих требований, представляет собой довольно сложную проблему. Синхронное и согласованное изменение данных в нескольких локальных БД, составляющих распределенную базу данных, достигается, как правило, применением протокола двухфазной фиксации транзакций. Кроме согласования и верификации данных, этот протокол может выполнять защиту от сбоев в системе в критических случаях (обрыв связи, например). Если распределенная БД однородна — т. Е. на всех узлах данные хранятся в формате одной базы и на всех узлах функционирует одна и та же СУБД, то используется механизм двухфазной фиксации транзакций для конкретной СУБД. В случае же неоднородности распределенной БД, для обеспечения согласованных изменений в нескольких базах данных, используют менеджеры распределенных транзакций. Это, однако, возможно, если участники обработки распределенной транзакции (СУБД, функционирующие на узлах системы), поддерживают ХА-интерфейс, определенный в спецификации DTP консорциума Х/Ореn. ХА-интерфейс имеют, например, Informix, Microsoft SQL Server, Oracle, Sybase, CA-Openlngres.

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

Непрерывность операций

Это качество можно трактовать как возможность непрерывного доступа (формат 24x7 — доступ 24 часа в сутки 7 дней в неделю) в рамках распределенной БД к данным вне зависимости от их расположения и операций, выполняемых на локальных узлах. Одним словом, данные доступны всегда, а операции над ними могут выполняться непрерывно.

Прозрачность расположения

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

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

Независимая фрагментация

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

Независимое тиражирование

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

Принципиальная характеристика тиражирования данных (Data Replication — DR) заключается в отказе от физического распределения, привязки данных. Суть репликации состоит в том, что любая база данных (как для СУБД, так и для работающих с ней пользователей) всегда является локальной; данные размещаются локально на том узле сети, где они обрабатываются; все транзакции в системе завершаются локально.

Тиражирование данных — это асинхронный перенос изменений объектов исходной базы данных в базы, принадлежащие различным узлам распределенной системы. Функции тиражирования выполняет, как правило, специальный модуль СУБД — сервер тиражирования данных, называемый репликатором (СУБД CA-Openlngres и Sybase). В других СУБД (Informix-OnLine Dynamic Server) регашкатор встроен в сервер или поставляется опционально (Oracle). Специфика механизмов репликации данных зависит от используемой СУБД. Один из простейших вариантов репликации — использование так называемых «моментальных снимков» (Snapshot) — сохранение на разных узлах копий той или иной таблицы в определенный момент времени; данные копии периодически (раз в неделю, например) подлежат обновлению.

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

Синхронное обновление распределенных БД и технология репликации данных — в определенном смысле, антиподы. Краеугольный камень первой — синхронное завершение транзакций одновременно на нескольких узлах распределенной системы, т. Е. синхронная фиксация изменений в распределенной БД. Ее «ахиллесова пята» — жесткие требования к производительности и надежности каналов связи. Если база данных распределена по нескольким территориально удаленным узлам, объединенным медленными и ненадежными каналами связи, а число одновременно работающих пользователей составляет сотни и выше, то вероятность того, что распределенная транзакция будет зафиксирована в обозримом временном интервале, становится чрезвычайно малой. В таких условиях (характерных, кстати, для большинства отечественных организаций) обработка распределенных данных практически невозможна.

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

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

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

При использовании механизмов репликации данных также остро стоит вопрос совместимости разнородных локальных баз данных, составляющих исходную БД. Зачастую штатные средства тиражирования в составе данной конкретной БД позволяют переносить данные в однородную базу. Ответом стало появление продуктов, выполняющих тиражирование между разнородными базами данных. Здесь развитие технологий пошло по двум путям. Первый — создание средств унифицированного доступа к данным (стандарт ODBC — Open DataBase Connectivity). Очевидный недостаток ODBC — недоступность для приложения многих полезных механизмов каждой конкретной СУБД, поскольку они могут быть использованы в большинстве случаев только через расширения SQL в диалекте языка данной СУБД, но в стандарте ODBC эти расширения могут не поддерживаться. Другой подход – это создание шлюзов, позволяющих приложениям оперировать над базами данных в ином формате так, как будто это собственные базы данных. Задача шлюза — организация доступа к унаследованным БД и служит для решения задач согласования форматов баз данных при переходе к какой-либо одной СУБД. Шлюзы можно рассматривать как средство, облегчающее миграцию, но не как универсальное средство межоперабельности в распределенной системе. Вообще, универсального рецепта решения задачи межоперабельности в этом контексте не существует — все определяется конкретной ситуацией, историей информационной системы и массой других факторов.

Обработка распределенных запросов

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

Обработка распределенных запросов — задача, более сложная, нежели обработка локальных запросов, и она требует интеллектуального решения с помощью особого компонента — оптимизатора распределенных запросов. Предположим, у нас имеется распределенная база данных, размещенная на двух узлах. Пусть, таблица detail хранится на одном узле, а таблица main — на другом. Размер первой таблицы — 2000 строк, размер второй — 200 строк (множество товаров поставляется небольшим числом поставщиков). Допустим, что выполняется запрос:

SELECT detail_name, main_name, main _address

FROM detail, main WHERE detail, main _number = main, main _number ;

Тогда результирующая таблица представляет собой объединение таблиц

detail и main, выполненное по столбцу detail.main_number (внешний ключ) И main.main _number (первичный ключ).

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

Обработка распределенных транзакций

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

Независимость от оборудования

Это свойство означает, что в качестве узлов распределенной системы могут выступать компьютеры любых моделей и производителей — от мэйнфреймов до персональных компьютеров и даже ноутбуков.

Независимость от операционных систем

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

Прозрачность сети

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

Независимость от баз данных

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

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

1 Целостность данных

В DDB поддержка целостности и согласованности данных, ввиду свойств 1-2, представляет собой сложную проблему. Ее решение – синхронное и согласованное изменение данных в нескольких локальных базах данных, составляющих DDB – достигается применением протокола двухфазной фиксации транзакций. Если DDB однородна – то есть на всех узлах данные хранятся в формате одной базы и на всех узлах функционирует одна и та же СУБД, то используется механизм двухфазной фиксации транзакций данной СУБД. В случае же неоднородности DDB для обеспечения согласованных изменений в нескольких базах данных используют менеджеры распределенных транзакций. Это, однако, возможно, если участники обработки распределенной транзакции – СУБД, функционирующие на узлах системы, поддерживают XA-интерфейс, определенный в спецификации DTP консорциума X/Open. В настоящее время XA-интерфейс имеют CA-OpenIngres, Informix, Microsoft SQL Server, Oracle, Sybase.
Если в DDB предусмотрено тиражирование данных, то это сразу предъявляет дополнительные жесткие требования к дисциплине поддержки целостности данных на узлах, куда направлены потоки тиражируемых данных. Проблема в том, что изменения в данных инициируются как локально – на данном узле – так и извне, посредством тиражирования. Неизбежно возникают конфликты по изменениям, которые необходимо отслеживать и разрешать.

2 Обработка распределенных запросов

Выше уже упоминалось это качество DDB. Обработка распределенных запросов (Distributed Query –DQ) – задача, более сложная, нежели обработка локальных и она требует интеллектуального решения с помощью особого компонента – оптимизатора DQ. Обратимся к базе данных, распределенной по двум узлам сети. Таблица detail хранится на одном узле, таблица supplier – на другом. Размер первой таблицы – 10000 строк, размер второй – 100 строк (множество деталей поставляется небольшим числом поставщиков). Допустим, что выполняется запрос:

SELECT detail_name, supplier_name, supplier_address

FROM detail, supplier

WHERE detail.supplier_number = supplier.supplier_number;

Результирующая таблица представляет собой объединение таблиц detail и supplier, выполненное по столбцу detail.supplier_number (внешний ключ) и supplier.supplier_number (первичный ключ).

Данный запрос – распределенный, так как затрагивает таблицы, принадлежащие различным локальным базам данных. Для его нормального выполнения необходимо иметь обе исходные таблицы на одном узле. Следовательно, одна из таблиц должна быть передана по сети. Очевидно, что это должна быть таблица меньшего размера, то есть таблица supplier. Следовательно, оптимизатор DQ запросов должен учитывать такие параметры, как, в первую очередь, размер таблиц, статистику распределения данных по узлам, объем данных, передаваемых между узлами, скорость коммуникационных линий, структуры хранения данных, соотношение производительности процессоров на разных узлах и т.д. От интеллекта оптимизатора DQ впрямую зависит скорость выполнения распределенных запросов.

3 Межоперабельность

В контексте DDB _ежоперабельность означает две вещи. Во-первых, - это качество, позволяющее обмениваться данными между базами данных различных поставщиков. Как, например, тиражировать данные из базы данных Informix в Oracle и наоборот? Известно, что штатные средства тиражирования в составе данной конкретной СУБД позволяют переносить данные в однородную базу. Так, средствами CA-Ingres/Replicator можно тиражировать данные только из Ingres в Ingres. Как быть в неоднородной DDB? Ответом стало появление продуктов, выполняющих тиражирование между разнородными базами данных.

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

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

4 Технология тиражирования данных

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

Тиражирование данных – это асинхронный перенос изменений объектов исходной базы данных в базы, принадлежащим различным узлам распределенной системы. Функции DR выполняет, как правило, специальный модуль СУБД – сервер тиражирования данных, называемый репликатором (так устроены СУБД CA-OpenIngres и Sybase). В Informix-OnLine Dynamic Server репликатор встроен в сервер:

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

В конфигурации серверов Informix-OnLine DS с тиражированием выделяется один основной и один вторичный сервер. На основном сервере выполняется и чтение, и обновление данных, а все изменения передаются на вторичный сервер, который доступен только на чтение (Рис. 2). В случае отказа основного сервера вторичный автоматически или вручную переводится в режим доступа на чтение и запись (Рис. 3). Прозрачное перенаправление клиентов при отказе основного сервера не поддерживается, но оно может быть реализовано в рамках приложений.

Тиражирование. Основной сервер доступен на чтение и запись, вторичный - только на чтение.

Когда основной сервер выходит из строя, вторичный переводится в режим доступа на чтение, и на запись.

Oracle 7 для использования DR необходимо приобрести дополнительно к Oracle7 DBMS опцию Replication Option.

Специфика механизмов DR зависит от используемой СУБД. Простейший вариант DR - использование моментальных снимков (snapshot). Рассмотрим пример из Oracle:

CREATE SNAPSHOT unfilled_orders

REFRASH COMPLETE

START WITH TO_DATE (DD-MON-YY HH23:MI:55)

NEXT SYSDATE + 7

AS SELECT customer_name, customer_address, order_date

FROM customer@paris, order@london

WHERE customer.cust_name = order.customer_number AND

order_complete_flag = N;

«Моментальный снимок» в виде горизонтальной проекции объединения таблиц customer и order будет выполнен в 23:55 и будет повторятся каждые 7 дней. Каждый раз будут выбираться только завершенные заказы.

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

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

Синхронное обновление DDB и DR-технология - в определенном смысле антиподы. Краеугольный камень первой - синхронное завершение транзакций одновременно на нескольких узлах распределенной системы, то есть синхронная фиксация изменений в DDB. Ee Ахиллесова пята - жесткие требования к производительности и надежности каналов связи. Если база данных распределена по нескольким территориально удаленным узлам, объединенным медленными и ненадежными каналами связи, а число одновременно работающих пользователей составляет сотни и выше, то вероятность того, что распределенная транзакция будет зафиксирована в обозримом временном интервале, становится чрезвычайно малой. В таких условиях (характерных, кстати, для большинства отечественных организаций) обработка распределенных данных практически невозможна.

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

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

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

5 Многозвенная архитектура

Архитектура клиент-сервер

Распределенные системы — это системы клиент-сервер. Существует, по меньшей мере, три модели клиент-сервер:

* модель доступа к удаленным данным (RDA-модель);

* модель сервера базы данных (DBS-модель);

* модель сервера приложений (AS-модель).

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

* компонент интерфейса с пользователем;

* программное обеспечение промежуточного слоя (middleware);

* компонент управления данными.

Middleware — это главный компонент трехзвенных распределенных систем. Он выполняет функции управления транзакциями и коммуникациями, транспортировки запросов, управления именами и иные функции.

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

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

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

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

Заключение

Сегодня можно считать, что распределенные базы данных - тема достаточно локальная и далеко не так актуальная, как архитектура распределенных систем. В DDB-технологии за последние 2-3 года не было каких-либо существенных новаций (за исключением, быть может, технологии тиражирования данных). Можно считать, что в этой сфере информатики все более или менее устоялось и каких-либо революционных шагов не предвидится. Более интересное направление (включающее DDB) - архитектура, проектирование и реализация распределенных информационных систем. Горячие темы в этом направлении - системы с трехзвенной архитектурой, продукты класса middleware, объектно-ориентированные средства разработки распределенных приложений в стандарте CORBA. Их активное применение будет доминировать в отечественной информатике в ближайшие 3-5 лет и станет технологической базой реальных интеграционных проектов.

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

Список литературы

http://www.zeiss.net.ru/docs/dbms/oracle/oraclepr_03.htm

http://jonni3.narod.ru/I_Progr/gl4/gl4.html

http://www.citforum.ru/database/kbd96/45.shtml

Скачать архив с текстом документа