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

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

1. ТЕРМИНОЛОГИЯ, КЛАССИФИКАЦИЯ, КОНФЛИКТЫ

Репликация (синхронизация) - процесс приведения данных электронных таблиц двух БД в идентичное состояние

Репликацию можно классифицировать по разному.

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

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

3) По способу передачи информации во время процесса репликации. Если соединение серверов, хранящих распределенные БД, происходит при помощи программы клиента, которая с одной стороны коннектится к своему серверу, а с другого конца имеет прямую связь с БД другого сервера и может подключиться напрямую к данным другого сервера, для прямого изменения и анализа реплицируемых данных с обеих концов, имея при этом гарантированный устойчивый канал связи (ADSL, выделенный канал, двухпроводная линия Dial-Up и пр.), то такой вид синхронизации назовем прямым. Если же канал неустойчивый и не гарантирует устойчивую связь без падений во время процесса синхронизации и данные приходится передавать цельными пачками, при этом принимающая сторона во время закачки и анализа данных не имеет немедленной возможности опросить источник при возникновении на ее взгляд сомнительных моментов, а решение "Что делать?" принимать в любом случае нужно, то такой вид синхронизации будем называть недетерминированной или вероятностной.

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

Как видно из вышеприведенного списка, вариантов репликации существует довольно большое количество.

2. ОСНОВНЫЕ ВЫГОДЫ ВНЕДРЕНИЯ МЕХАНИЗМА РЕПЛИКАЦИЙ

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

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

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

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

5. Работа всех подписчиков с общими ресурсами - репликация позволяет каждому из подписчиков работать с общими ресурсами, например регистр остатков или регистр бухгалтерии, причем для синхронизации потоков всех операций по каждому подписчику применяется контрольное перепроведение документа в эталонной БД, таким образом, на подписчике при проведении документа назначается статус "предварительно проведен", а на эталонной базе "проведен".

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

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

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

Почти идеальное с технической точки зрения решение: соединить головной офис и филиалы скоростными каналами связи и сделать базу данных единой для программы учета. Этот путь возможен только тогда, когда все филиалы имеют постоянный доступ в Интернет по локальной сети или выделенной линии. Что происходит в случае обрыва соединения? Очевидно, что бесперебойной работы в этом решении не добиться. Кроме того, есть психологический аспект, преодолеть который, скорее всего, не удастся: руководство компании будет очень испугано появлением принципиальной возможности зайти из Интернета в "святая святых" - базу данных программы учета. И вряд ли рассказы о межсетевых экранах и прочих средствах безопасности его успокоят.

Применение ПК "Репликация информационных баз" полностью выполняет требование "в реальном времени". Т.е. оператор филиала создаёт / изменяет объект репликации (справочник или документ) и все остальные операторы могут тут же увидеть эту информацию.

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

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

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

2.1 О репликации базы данных

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

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

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

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

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

2.2 Механизмы репликации данных

Для поддержки целостности распределенной БД в СУБД ЛИНТЕР используется механизм асинхронного тиражирования (далее по тексту - репликации) транзакций.

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

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

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

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

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

2.3 Назначение репликации данных

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

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

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

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

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

2.4 Функциональные требования к серверу репликации

При разработке сервера репликации были определены основные требования, которым он должен удовлетворять:

· совмещение функции сервера публикации и сервера подписки;

· исключение нарушения структуры базы данных;

· использование в гетерогенной (смешанной) системе, т.е. система репликации может включать сервера баз данных как Oracle, так и MS SQL;

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

· сервер подписки может принимать информацию от нескольких серверов публикации;

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

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

· репликация информации таблиц, структура которых включает поля BLOB (binary large object) и поля, допускающие значение NULL;

· кодирование реплицируемой информации.

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

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

2.5 Синхронная репликация

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

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

2.6 Асинхронная репликация

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

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

2.7 Основные принципы, правила построения и функционирования РБД

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

Коммуникационной сети присущи следующие свойства:

1. каждый узел-это полноценная СУБД сама по себе;

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

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

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

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

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

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

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

Самый высший уровень архитектуры распределенной СУБД - это интерфейс прикладной программы и интерфейс процессора запросов.

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

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

1-4 уровни архитектуры распределенной СУБД относятся к сетевой СУБД.

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

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

Для управления распределенной базой данных создается программный комплекс - система управления распределенной базой данных (СУРБД).

C. J. Date в 1987 году сформулировал один основной принцип и двенадцать правил, которым, по его мнению, должны следовать распределенные базы данных .

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

Фундаментальный принцип имеет следствием определённые дополнительные правила или цели. Таких целей всего двенадцать:

1. Локальная независимость. Узлы в распределённой системе должны быть независимы, или автономны. Локальная независимость означает, что все операции на узле контролируются этим узлом.

2. Отсутствие опоры на центральный узел. Локальная независимость предполагает, что все узлы в распределённой системе должны рассматриваться как равные. Поэтому не должно быть никаких обращений к «центральному» или «главному» узлу с целью получения некоторого централизованного сервиса.

3. Непрерывное функционирование. Распределённые системы должны предоставлять более высокую степень надёжности и доступности.

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

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

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

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

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

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

10. Независимость от операционной системы. Возможность функционирования СУБД под различными операционными системами.

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

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

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

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

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

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

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

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

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

Обработка распределенных транзакций DDB можно трактовать как возможность выполнения операций обновления распределенной базы данных (INSERT, UPDATE, DELETE), не разрушающее целостность и согласованность данных. Эта цель достигается применением двухфазового или двухфазного протокола фиксации транзакций (two-phase commit protocol), ставшего фактическим стандартом обработки распределенных транзакций. Его применение гарантирует согласованное изменение данных на нескольких узлах в рамках распределенной, или глобальной транзакции.

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

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

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

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

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

ЗАКЛЮЧЕНИЕ

В основе любых технологических потрясений лежит простой экономический расчет: выгодно - невыгодно. В основе нынешней ситуации в развитии распределенных систем также лежит экономическое обоснование - стоимость передачи данных по сети становится меньше стоимости вычислений на клиентской машине и эта тенденция имеет устойчивый характер. Взрывной рост Internet, который многие связывают с "демократическими свободами" или развитием новой технологии имеет в своей основе все тоже простое экономическое обоснование - эта технология экономически выгодна. Отсюда проистекают и те изменения в мире технологий свидетелями которых мы являемся: стремительный рост пропускной способности каналов (Internet - 2, новые более быстрые модемы, спутниковые каналы для домашнего пользователя ), присутствие в сети большинства корпораций и масс медиа, электронная коммерция и банки … На основе этих технологий выросли новые направления бизнеса, а распространенность Internet растет темпами невиданными в отрасли (быстрее телефонии и телевидения).

СПИСОК ИСПОЛЬЗУЕМОЙ ЛИТЕРАТУРЫ

1. Borland Inter Base Workgroup Server. API Guide. - Borland International

Inc,1995-330c.

2. Borland Inter Base Workgroup Server. Data Definition Guide. – Borland

InternationalInc,1995-212c.

3. Borland Inter Base Workgroup Server. Language Reference. – Borland

InternationalInc,1995-234c.

4. Borland Inter Base Workgroup Server. Programmer’s Guide. – Borland

InternationalInc,1995-340c.

5. Microsoft Online Documentation: Win32 Programmers Reference.

6. R.Barker "CASE* Method - Entity Relationship Modelling". - Oracle Inc.1990-243c.

7. Биллиг В.А., Мусикаев И.Х. «Visual C++ 4. Книга для программистов». М.: Издательский отдел «Русская редакция» ТОО.

8. Галатенко В. «Информационная безопасность - обзор основных положений:Ч1»: - Информационный бюллетень Jet Info №1/1996.

9. Галатенко В. «Информационная безопасность - обзор основных положений: Ч2»: - Информационный бюллетень Jet Info №2/1996.

10. Галатенко В. «Информационная безопасность - обзор основных положений: Ч3»: - Информационный бюллетень Jet Info №3/1996.

11. Грабер Мартин. “Введение в SQL”. Пер. с англ. - М.: Издательство “ЛОРИ”,1996.-375с.,ил.

12. Зубанов Ф. «Windows NT - выбор «профи»». - М.: Издательский отдел «Русская редакция» ТОО «Channel Trading Ltd.» , 1996. - 392 с. ил.

13. Кастер Х. «Основы Windows NT и NTFS». Пер. с англ. - М: Издательский отдел «Русская редакция» ТОО «Channel Trading Ltd.» , 1996.-440с.ил.

14. Ладыженский Глеб. «СУБД - коротко о главном» - Информационный бюллетень.

15. Ларин Л.С., Челдаева Л.А., Гуськова Н.Д. "Технико-экономическое обоснование дипломных проектов", Саранск, 1983, 100 с.

16. «Решения Microsoft» - Вып. 5. - М: АООТ «Типография Новости», 1997.132с.,ил.

17. Рихтер Дж.. «Windows для профессионалов (Программирование в Win32 API для Windows 95 и Windows NT)». Пер. с англ. «Русская редакция» ТОО «Channel Trading Ltd.» , 1995. - 720 с. ил.

18. Паппас К., Мюррей У.. «Visual C++. Руководство для профессионалов»: пер. с англ. - Спб.: BHV - Санкт-Петербург, 1996. - 912 с.,ил.

19. «Сетевые средства Windows NT»: Пер. с англ. - СПб.: BHV - Санкт- Петербург,1996-496с.,ил.