Технологии реплицирования данных

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

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

Математическое моделирование - метод исследования процессов и явлений на их математических моделях.

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

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

а) все чаще компьютеры при математическом моделировании используются не только для численных расчетов, но и для аналитических преобразований:

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

1.2 Классификация математических моделей

К классификации математических моделей можно подходить по-разному, положив в основу классификации различные принципы.

Решение этой задачи основывается на поддержке современными «настольными» СУБД (MS Access, MS FoxPro, dBase и др.) технологии «объектов доступа к данным» - DАО[10].

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

Технически технология DАО основана на уже упоминавшемся протоколе ODBC, который принят за стандарт доступа не только к данным на SQL-серверах клиент-серверных систем, но и в качестве стандарта доступа к любым данным под управлением реляционных СУБД.

Непосредственно для доступа к данным на основе протокола ODBC используются специальные программные компоненты, называемые драйверами ODBC (инициализируемые на тех установках, где находятся данные).

Схематично принцип и особенности доступа к внешним базам данных на основе объектного связывания иллюстрируются на рис. 1.

Рис. 1 - Принцип доступа к внешним данным па основе ODBC

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

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

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

Технически оперирование связанными объектами из внешних баз данных «своего» формата мало отличается от оперирования с данными из текущей базы данных.

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

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

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

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

Аналогичным образом обеспечивается доступ к данным, находящимся в базах данных наиболее распространенных форматов других СУБД, таких, например, как базы данных СУБД FoxPro, dBASE[8].

При этом доступ может обеспечиваться как непосредственно ядром СУБД, так и специальными дополнительными драйверами ISAM (Indexed Sequential Access Method), входящими, как правило, в состав комплекта СУБД.

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

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

5. Технологии удалённого доступа и системы БД, тиражирование и синхронизация в распределённых системах БД

В технологиях распределенных информационных систем в настоящее время существуют следующие направления:

- технологии «Клиент-сервер»;

- технологии реплицирования (тиражирования);

- технологии объектного связывания.

Распределенные информационные системы, как правило, построены на основе сочетания всех трех технологий.

Технологии и модели «Клиент-сервер».

В основе клиент-серверных технологий лежат две основные идеи:

- общие для всех пользователей данные на одном или нескольких серверах;

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

Под сервером в широком смысле понимается любая система, процесс, компьютер, владеющие каким-либо вычислительным ресурсом (памятью, временем, производительностью процессора и т.д.).

Клиентом называется также любая система, процесс, компьютер, пользователь, запрашивающие у сервера какой-либо ресурс, пользующиеся каким-либо ресурсом или обслуживаемые сервером иным способом[13].

В структуре СУБД выделяют три компонента:

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

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

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

Исходя из особенностей реализации и распределения в системе этих компонентов, различают четыре модели технологий «Клиент-сервер»:

- модель файлового сервера (FS);

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

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

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

Модель файлового сервера.

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

5.1 Модель удаленного доступа к данным

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

Достоинства. В результате реализации такого подхода резко уменьшается загрузка сети. RDA-модель позволяет также унифицировать интерфейс взаимодействия прикладных компонентов СУБД с общими данными. Такое взаимодействие стандартизовано в рамках языка SQL специальным протоколом ODBC, играющим важную роль в обеспечении независимости от типа СУБД на клиентских установках. Это позволяет интегрировать уже существующие локальные БД в создаваемые распределенные информационные системы независимо от типов СУБД клиентов и сервера. Недостатки. Высокие требования к клиентским вычислительным установкам, так как на них выполняются прикладные программы обработки данных. Значительный трафик сети, поскольку с сервера направляются клиентам наборы данных, которые могут иметь существенный объем[14].

5.2 Модель сервера базы данных

На клиентских установках в DBS-модели размещается только интерфейсный компонент, а все остальные компоненты СУБД размещаются на сервере. От клиентов на сервер направляются только вызовы необходимых процедур, запросов и других функций по обработке данных. Все операции по обработке данных выполняются на сервере, а пользователю направляются лишь результаты обработки (а не наборы данных, как в RDA-модели).

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

5.3 Модель сервера приложений

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

RDA- и DBS-модели называют двухзвенными (двухуровневыми), AS-модель - трехзвенной (трехуровневой).

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

6. Мониторы транзакций

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

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

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

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

«Грязные» данные возникают, когда одна транзакция изменяет какой-либо объект данных, а другая транзакция в это же время читает данные из этого объекта. Так как первая транзакция еще не завершена, то согласованность данных еще не проверена. Поэтому вторая транзакция может «видеть» несогласованные («грязные») данные. Способом предотвращения таких ситуаций является запрет на чтение объекта любой другой транзакцией, пока не завершена транзакция, изменяющая данный объект.

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

6.1 Механизм изоляции транзакций и преодоления ситуаций несогласованной обработки данных основывается на технике сериализации транзакций

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

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

Методы сериализации транзакций:

- синхронизационные захваты (блокировки) объектов БД;

- временные метки объектов БД.

Выделяют два основных режима синхронизационных захватов - совместный (захват по чтению) и монопольный (захват по записи) режимы. При совместном режиме осуществляется разделяемый захват, требующий только операций чтения. При монопольном режиме осуществляется неразделяемый захват, требующий операций обновления данных. Наиболее распространенным вариантом реализации синхронизационных захватов является двухфазный протокол блокировок 2PL, в соответствии с которым выполнение транзакции происходит в два этапа. На первом этапе перед выполнением любой операции транзакция запрашивает и накапливает захваты необходимых объектов в соответствующем режиме. После получения и накопления необходимых захватов выполняется вторая фаза - фиксация изменений или откат по соображениям целостности данных, а также последующее освобождение захватов. При построении сериальных планов допускается совмещение только захватов по чтению. Более эффективные планы сериализации транзакций позволяет строить применение «гранулирования» синхронизационных блокировок. В этом случае «гранулируются» объекты захвата (файлы, таблицы, страницы файла, записи), что позволяет расширить номенклатуру синхронизационных режимов захватов (напр., совместный режим захвата файла с возможностью монопольного захвата отдельных его объектов - таблиц, страниц, записей). Недостаток синхронизационных захватов - возможность возникновения тупиков. Распознавание (автоматическое обнаружение) тупиков основывается на построении и анализе графа ожидания транзакций, состоящего из вершин-транзакций и вершин-объектов захвата. Требуемым захватам соответствуют дуги, исходящие из вершин-транзакций к вершинам-объектам; противоположное направление дуг соответствует полученным захватам. Циклы (петли) на графе соответствуют тупиковым ситуациям. Для обнаружения циклов применяется алгоритм редукции графа, который требует постоянного обновления графа ожидания транзакций, что снижает эффективность обработки данных. Для разрешения (разрушения) тупиков используются различные алгоритмы разрушения тупиков. Такие алгоритмы основываются на выборе транзакции-жертвы, которая временно откатывается для предоставления возможности завершения операций другим транзакциям. В качестве такой транзакции выбирается транзакция с наименьшим приоритетом, либо та транзакция, которая требует меньше всего затрат на выполнение.

Другой, более простой, метод сериализации транзакций - метод временных меток, в соответствии с которым каждой транзакции приписывается временная метка, соответствующая моменту начала выполнения транзакции. При выполнении операции над объектом транзакция «помечает» его своей меткой и типом операции (чтение или изменение). Если при этом другой транзакции требуется операция над уже помеченным объектом, то выполняется ряд действий по разрешению возникшей ситуации. Применение метода временных меток вызывает более частые откаты назад транзакций, чем при синхронизационных блокировках. Однако достоинством метода временных меток является отсутствие тупиков, а, следовательно, и отсутствие накладных расходов на их распознавание и разрушение[16].

7. Технологии тиражирования (реплицирования) данных

Основная идея тиражирования: пользователи работают автономно с одинаковыми (общими) данными, растиражированными по локальным базам данных, что обеспечивает в силу отсутствия необходимости передачи растиражированных данных максимальную производительность используемой вычислительной системы.

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

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

Решение проблемы обеспечения согласованного состояния количества и значений общих данных основывается на реализации одного из двух принципов:

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

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

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

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

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

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

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

8. Примеры применения в производстве

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

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

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

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

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

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

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

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

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

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

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

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

Решение второй проблемы согласованности данных, а именно - согласованности структуры данных, осуществляется через частичное отступление, как и в системах «Клиент-сервер», от принципа отсутствия центральной установки и основывается на технике «главной» реплики.

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

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

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

Автономные приложения. Работают на одном компьютере[17].

9. Реплицирование данных предложенные в Access 7.0

Возможности реплицирования данных и объектов являются нововведением для продуктов, представленных на рынке настольных баз данных. На сегодняшний день ни одна другая настольная СУБД такими возможностями не обладает. Для реплицирования созданных в Access баз данных используется средство «Портфель» (Briefcase) ОС Windows 95, что не может служить ограничением для применения СУБД, способной работать лишь в среде Windows 95.

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

Можно назвать по крайней мере пять наиболее вероятных случаев применения функции реплицирования.

1. При работе вне офиса, например в сфере торговли или обслуживания, можно периодически (ежедневно или еженедельно) обновлять хранимые на портативных ПК базы данных на основе используемой в офисе базовой копии.

2. Реплицирование удобно при ведении одной и той же базы данных в разных местах, в частности в офисе и дома или в нескольких офисах одной фирмы.