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

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

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

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

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

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

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

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

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

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

РаБД можно также рассматривать как конфигурацию, где клиентские приложения, выполняющиеся на настольных компьютерах (ПК или рабочих станциях), обращаются к данным из множества баз данных посредством стандартизованного программного обеспечения промежуточного слоя (middleware), такого, как ODBC (Open DataBase Connectivity, API компании Microsoft). Такие РаБД функционируют на основе интерфейса удаленного вызова процедур, а не производят самих операций доступа и манипулирования удаленными данными.

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

Объект исследования - управление распределенной информацией.

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

Задачи исследования вытекают из поставленной цели:

- проанализировать принципы управления распределенной информацией;

- описать модели распределенных баз данных;

- рассмотреть направления развития управления распределенной информацией.

Методы исследования: изучение и анализ научной литературы, статей по теме работы в периодических изданиях, научных источников в сети Интернет, анализ и сравнение модели распределенных баз данных с другими моделями.

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

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

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

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

Рассмотрим подробнее распределенную обработку данных.

1. История вопроса

История вопроса

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

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

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

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

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

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

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

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

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

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

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

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

К. Дейтом были сформулированы 12 свойств типичной распределенной базы данных:

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

2. Независимость узлов (no reliance on central site) - все узлы равноправны и независимы, а расположенные на них базы являются равноправными поставщиками данных в общее пространство данных. База данных на каждом из узлов самодостаточна - она включает полный собственный словарь данных и полностью защищена от несанкционированного доступа.

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

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

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

6. Прозрачное тиражирование (replication independence) - возможность переноса изменений между базами данных средствами, невидимыми пользователю распределенной системы. Данное свойство означает, что тиражирование возможно и достигается внутрисистемными средствами.

7. Обработка распределенных запросов (distributed query processing) - возможны несколько способов пересылки данных, позволяющих выполнить рассматриваемый запрос.

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

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

10. Независимость от операционных систем (operationg system independence) - многообразие операционных систем, управляющих узлами распределенной системы.

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

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

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

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

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

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

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

1) набор логически связанных разделяемых данных;

2) сохраняемые данные разбиты на некоторое количество фрагментов;

3) между фрагментами может быть организована репликация данных;

4) фрагменты и их реплики распределены по различным узлам;

5) узлы связаны между собой сетевыми соединениями;

6) работа с данными на каждом узле управляется локальной СУБД.

СУБД на каждом узле способна поддерживать автономную работу локальных приложений.

2.2 Однородные и неоднородные базы данных

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

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

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

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

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

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

Противоположностью однородных систем распределенных БД являются неоднородные распределенные системы БД. Неоднородные системы включают два или более существенно различающихся продукта управления данными (например, реляционные СУБД от разных поставщиков, таких, как Oracle и Digital Equipment Corp., или СУБД одного поставщика, но функционирующие на разных платформах и использующие различные структуры баз данных, такие, как DB2 и SQL/DS компании IBM).

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

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

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

Однако при проектировании распределенной базы данных методом «сверху вниз» предполагается, что ее объекты не будут сосредоточены в одном месте, а распределятся по нескольким вычислительным системам.

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

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

Дифференциальные файлы

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

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

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

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

2. Преимущества и недостатки распределенных базы данных