Содержание к диссертации
Введение
1. Анализ существующих систем репликации реляционных субд и способов синхронизации данных в них 9
1.1. Принципы создания распределенных систем 11
1.2. Средства определения и фиксации изменений данных 12
1.3. Способы распространения изменений между узлами рсбд 16
1.4. Репликация данных и основные проблемы асинхронного тиражирования 21 цели работы и задачи исследования 32
2. Разработка схемы проектирования, метода выделения и связывания объектов и оценка эффективности его применения в асинхронной репликации 34
2.1. Разработка метода выделения и связывания объектов и схемы проектирования асинхронной репликации 36
2.2. Число согласований асинхронной репликации с выделением объектов 45
2.3. Целостность и непротиворечивость данных в рсбд с асинхронной репликацией 47
2.4. Математическая модель информационного процесса репликации данных 49
выводы 50
3. Разработка алгоритмов, структур информационного обеспечения и концептуальной модели Данных системы асинхронной репликации на основе метода выделения объектов 52
3.1. Разработка журнала изменений и средств их фиксации 52
3.2. Разработка протокола асинхронного тиражирования 56
3.3. Алгоритмы разрешения конфликтов синхронизации... 59
3.4. Топология тиражирования в системе асинхронной репликации .
61
3.5. Методы сокращения продолжительности блокировок 62
3.6. Концептуальная модель схемы данных асинхронной репликации методом выделения объектов 64
4. Реализация программного обеспечения асинхронной репликации данных реляционных субд методом выделения объектов 76
4.1. Модули и структурные элементы системы асинхронной репликации 76
4.2. Функциональная модель системы асинхронной репликации 86
4.3. Программная реализация проектирования и проведения асинхронной репликации данных на основе метода выделения объектов 99
Выводы но
Заключение 111
Список используемых источников
- Средства определения и фиксации изменений данных
- Репликация данных и основные проблемы асинхронного тиражирования 21 цели работы и задачи исследования
- Число согласований асинхронной репликации с выделением объектов
- Функциональная модель системы асинхронной репликации
Введение к работе
Актуальность темы:
В современных условиях развития информационных технологий, обусловленных доступностью высокопроизводительных ЭВМ и развитием глобальных компьютерных сетей, актуальной стала проблема построения распределенных информационных систем предприятий. Эта актуальность обусловлена географической распределенностью предприятий в России. Тиражирование (или репликация) данных является важным элементом построения распределенных информационных систем. Она позволяет обеспечить доступ пользователям такой системы к актуальным данным в их локальной копии, что позволяет избежать затрат на доступ к удаленному узлу и увеличивает скорость предоставления данных. Использование репликации позволяет также достичь таких преимуществ как повышение производительности, надежности хранения и доступности данных, а также дает возможность поддержки мобильных пользователей.
Мобильность пользователя для таких систем характеризуется, прежде всего, отсутствием постоянного канала связи с ним. В этих случаях для обеспечения локальной независимости узла распределенной системы применяется асинхронное тиражирование данных, которое дает важное преимущество с технической и экономической точек зрения. Основная проблема распределенных систем с асинхронным тиражированием данных -соблюдение непротиворечивости и целостности данных, разрешение конфликтов согласования. И если для последних современные РСУБД предлагают способы автоматического разрешения, то для поддержки целостности базы данных разработчикам информационных систем предлагается самостоятельная разработка алгоритмов.
Таким образом, актуальность диссертационного исследования обусловлена необходимостью анализа основных проблем асинхронного тиражирования данных и разработки методов автоматической поддержки целостности.
Работа выполнена в рамках одного из основных научных направлений ГОУ ВПО «Воронежский государственный технический университет» «Интеллектуализация процессов моделирования и оптимизации в автоматизированных и информационных системах» ГБ 04.04 научного направления «Интеллектуальные информационные системы».
Цели и задачи исследования:
Целью диссертационной работы является повышение эффективности функционирования асинхронной репликации реляционных СУБД за счет разработки методов и алгоритмов повышения уровня целостности данных в распределенных системах.
Для достижения поставленной цели необходимо решить следующие задачи:
Провести анализ принципов построения распределенных систем, современных методов определения и фиксации данных, средств обмена данными и основных проблем асинхронного тиражирования данных.
Создать методы выделения и связывания объектов, схему проектирования репликации. Оценить эффективность применения метода выделения объектов в асинхронных системах репликации, а также выработать рекомендации по его применению.
Разработать средства определения, фиксации и передачи данных, подлежащих тиражированию. Создать алгоритмы разрешения конфликта уникальности первичных ключей, адаптировать алгоритм разрешения конфликта времени выполнения операций над данными. Разработать концептуальную модель схемы данных.
На основе полученных результатов разработать структуру специального программного обеспечения асинхронной репликации данных по методу выделения объектов, разработать программный продукт, реализующий асинхронное тиражирование данных в реляционных СУБД. Методы исследования:
Научные положения, выводы и рекомендации научно обоснованы с помощью математических доказательств с использованием аппарата теории вероятностей, теории конечных автоматов, теории множеств и теории функций. Научная новизна результатов исследования:
В работе получены следующие результаты, характеризующиеся научной новизной: классификация нарушений целостности различных уровней, возникающих при использовании асинхронного тиражирования данных отличающаяся учетом всех возможных уровней целостности; схема проектирования репликации данных, позволяющая разбить процесс проектирования на этапы концептуального и логического проектирования и отличающаяся полнотой описания структуры репликации; метод выделения и связывания объектов для репликации в реляционных СУБД, основывающийся на группировке сущностей реалий и обеспечивающий сохранение уровня числа согласований, а также повышающий целостность данных; концептуальная модель описания схемы данных репликации, основывающаяся на разработанном методе выделения и связывания объектов и учитывающая все классы реалий РСБД; - структура специального программного обеспечения, обеспечивающая настройку схемы данных и асинхронное тиражирование данных в реляционных СУБД и отличающаяся применением разработанного метода выделения и связывания объектов для репликации данных.
Практическая значимость и результаты внедрения: Предложенный алгоритм асинхронной репликации данных реляционных СУБД, основанный на методе выделения и связывания объектов, повышает эффективность тиражирования данных, за счет автоматического контроля целостности данных, и, соответственно, снижает необходимость вмешательства администраторов информационных систем для разрешения нарушений целостности данных.
Разработанная схема проектирования процесса репликации данных может использоваться для ускорения процесса проектирования информационных систем с распределенной базой данных.
Теоретические и практические результаты работы внедрены в деятельность ООО «ГЕЛА. Информационные технологии и консалтинг» и реализованы в виде программной системы проектирования и проведения асинхронной репликации реляционных СУБД, о чем свидетельствует соответствующий акт внедрения.
Апробация работы;
Основные результаты работы были изложены на XIV Всероссийской научно-методической конференции Телематика'2007 (Санкт-Петербург, 2007), научно-технических конференциях профессорско-преподавательского состава, сотрудников, аспирантов и студентов ГОУ ВПО «Воронежский государственный технический университет» (2005-2008).
Публикации:
Основные результаты диссертационной работы изложены в восьми публикациях, в том числе 5 - в изданиях, рекомендованных ВАК РФ.
В работах, опубликованных в соавторстве, лично соискателю принадлежит метод выделения и связывания объектов в реляционной СУБД [6], [7], классификация основных проблем асинхронного тиражирования и нарушений целостности различных уровней [8], математическая модель журнала изменений и критерий его оптимизации [9].
Структура и объем работы;
Диссертация состоит из введения, четырех глав, заключения и одного приложения, изложенных на 120 страницах машинописного текста, списка литературы из 87 наименований. Работа проиллюстрирована 25 рисунками и содержит 19 таблиц.
В первой главе проведено исследование принципов построения распределенных систем, правил выбора схем распространения данных СУБД. Описаны средства определения данных для тиражирования и существующие способы передачи информации. Проведен анализ существующих моделей репликации, классифицированы основные проблемы асинхронного тиражирования данных.
Во второй главе предложена схема проектирования асинхронной репликации, основанная на методике разбиения процесса проектирования на концептуальный и логический этапы. Разработан метод выделения и связывания объектов, основывающийся на группировке сущностей реалий. Проведена оценка эффективности разработанного метода с помощью расчета числа согласований и доказательства повышения уровня непротиворечивости данных. Приведена математическая модель информационного процесса репликации.
В третьей главе проведена разработка средств определения и фиксации данных для тиражирования. Приведена математическая модель журнала изменений и разработан критерий его оптимизации. Разработан протокол асинхронного тиражирования. Разработаны алгоритмы разрешения конфликта уникальности и нарушений целостности из-за конфликта времени выполнения. Предложены алгоритмы проведения процесса синхронизации объектов, проведена разработка концептуальной модели структур данных, необходимых для обеспечения функционала асинхронной репликации.
В четвертой главе приведена структурная и функциональная модели системы асинхронной репликации данных по методу выделения объектов. Описывается структура специального программного обеспечения, реализующего настройку схемы данных и асинхронное тиражирование в реляционных СУБД.
Средства определения и фиксации изменений данных
Для этих целей, например, в СУБД MS SQL Server предусмотрены триггерные таблицы inserted и deleted. В этих таблицах содержатся строки, которые будут вставлены или удалены после выполнения транзакции, соответственно. Структура этих таблиц идентична структуре таблицы, для которой определен триггер.
В СУБД Oracle для этих целей используются строчные триггеры, для обработки строк и слова old и new, предваряющие имя столбца таблицы, для доступа к старым или новым значениям столбцов, соответственно [34].
Недостатком триггерного способа обнаружения изменений служит невозможность контроля над временем исполнения триггера, наличие которого может существенно замедлить работу информационной системы. Для устранения этого недостатка в механизме Advanced Replication СУБД Oracle триггера для отслеживания изменений были созданы на языке С и скомпилированы в ядро СУБД, что повысило производительность и снизило загрузку [74].
Достоинствами такого метода являются высокая скорость работы систем репликации, легкий алгоритм создания и ведения журнала изменений данных.
Следующим механизмом определения изменений могут служить мониторы транзакций. Мониторы обработки транзакций (Transaction Processing Monitor — ТРМ) часто относят к категории middleware (промежуточному) ПО. Первоначально основной задачей ТР-монитора в среде клиент-сервер было сокращение числа соединений клиентских систем с базами данных. ТР-мониторы брали на себя роль концентратора таких соединений, становясь посредником между клиентом и сервером базы данных [23], [40], [41].
Постепенно, с развитием трехзвенной архитектуры клиент-сервер функции ТР-мониторов расширились, и эти продукты превратились в открытую среду для разработки и управления мобильными приложениями в распределенной среде с множеством баз данных от различных поставщиков, ориентированную на оперативную обработку распределенных транзакций. Основное назначение ТР-мониторов - автоматизированная поддержка приложений, оформленных в виде последовательности транзакций. Каждая транзакция — это законченный блок обращений к ресурсу (как правило, базе данных) и некоторых действий над ним, для которого гарантируется выполнение четырех условий, так называемых свойств ACID (Atomicity, Consistency, Isolation, Durability). Atomicity (атомарность) — операции транзакции образуют неразделимый, атомарный блок («unit of work») с определенным началом и концом. Этот блок либо выполняется от начала до конца, либо не выполняется вообще. Если в процессе выполнения транзакции произошел сбой, происходит откат к исходному состоянию; Consistency (согласованность) - по завершении транзакции все задействованные ресурсы находятся в согласованном состоянии; Isolation (изолированность) - одновременный доступ транзакций различных приложений к разделяемым ресурсам координируется таким образом, чтобы эти транзакции не влияли друг на друга; Durability (долговременность) - все модификации ресурсов в процессе выполнения транзакции будут долговременными.
В системе без ТР-монитора, обеспечение свойств ACID берут на себя серверы распределенной базы данных (на основе протокола 2РС). Протокол 2РС [21], [26], [31], [55], [73] описывает двухфазный процесс, в котором перед началом распределенной транзакции все системы опрашиваются о готовности выполнить необходимые действия. Однако в системе с распределенными базами данных выполнение протокола 2РС можно гарантировать только в том случае, если все источники данных принадлежат одному поставщику. Поэтому, для сложной распределенной среды, которая обслуживает тысячи клиентских мест и работает с десятками разнородных источников данных, без монитора транзакций не обойтись. ТР-мониторы способны координировать и управлять транзакциями, которые обращаются к серверам баз данных от различных поставщиков благодаря тому, что большинство этих продуктов помимо протокола 2РС поддерживают транзакционную архитектуру ХА, которая является стандартом для данной категории программного обеспечения. ХА определяет интерфейс для взаимодействия ТР-монитора с менеджером ресурсов, например, СУБД Oracle или Sybase. Спецификация ХА является частью общего стандарта распределенной обработки транзакций (distributed transaction processing - DTP), разработанного X/Open.
Прикладные программы взаимодействуют с ТР-монитором посредством специального интерфейса ТХ, позволяющего реализовать в приложении семантику транзакций, разбивая запросы на логические «unit of works». Большинство ТР-мониторов для Unix-платформ и серверов баз данных поддерживают стандарт ХА.
Функции современных ТР-мониторов не ограничиваются поддержкой целостности прикладных транзакций. Большинство продуктов этой категории способны распределять, планировать и выделять приоритеты запросам нескольких приложений одновременно, тем самым сокращая процессорную нагрузку и время отклика системы.
ТР-мониторы выполняют мультиплексирование запросов к ресурсам от множества клиентов. В большинстве приложений фактический доступ пользователя к базе данных занимает лишь часть общего времени соединения. Таким образом, снимается одно из серьезных ограничений производительности и масштабируемости клиент-серверной среды - необходимость поддержки отдельного соединения с базой данных для каждого клиента. Многие ТР-мониторы имеют возможность оптимально распределять нагрузку на серверы, а также выполнять автоматическое восстановление после сбоя и перезапуск системы.
Таким образом, ТР-монитор - это не только механизм коммуникаций, но и мощная платформа для реализации логики приложения, хороший кандидат на промежуточное звено многозвенной архитектуры клиент-сервер. Среди присутствующих сегодня на рынке продуктов наибольшей популярностью пользуются: Tuxedo компании BEA Systems, интегрированная в ряд важных корпоративных приложений, NCR TopEnd и MS Transaction Server.
Репликация данных и основные проблемы асинхронного тиражирования 21 цели работы и задачи исследования
Обратимся назначению данных, хранящихся в базе данных информационной системы, с точки зрения бизнес-логики. Для проектирования обмена между точками учета данные удобно классифицировать следующим образом [6]:
Справочная информация, такая как перечни товаров, сотрудников и так далее. Справочники представлены обычно линейными или древовидными списками. Как правило, записи справочников редко изменяется, скорее, изменяется количество элементов списка. Информация подобного рода обязательно должна участвовать в обмене, так как на ее основе формируются первичные документы.
Первичные документы - документы, влияющие на количественные или качественные изменения объектов учета в информационной системе. Ими могут быть накладные на прием или отпуск продукции, данные инвентаризации и другие документы. Этот класс данных всегда использует справочную информацию (документы, не удовлетворяющие этому требованию можно рассматривать как справочные данные) и имеет собственный перечень содержательных для учета атрибутов, например всевозможные количественные показатели. Таблицы справочников находятся с таблицами первичных документов в отношении «один-ко-многим» и являются родительскими таблицами.
Отчетные формы - документы, агрегирующие первичные данные и использующиеся в качестве объектов учета в информационной системе. Отчеты в информационной системе, вообще говоря, можно поделить на два типа: формы, агрегирующие и содержание в
обработанном виде первичную информацию, и аналитические отчеты, не имеющие собственных данных (как способ представления информации для анализа). Понятно, что отличительным признаком здесь является наличие у отчетной формы собственных данных, и именно их мы будет рассматривать в данной классификации. Понятно, что эта классификация не является полным перечнем всех реалий, описываемых в базе данных информационной системы. Для простоты исключена, например, такая информация как параметры и настройки информационной системы. Классифицированы только те данные, которые подлежат учету с точки зрения назначения информационной системы, а, следовательно, подлежат обмену между узлами РСБД. Очевидно, что передаче подлежат лишь те типы объектов, которые обладают собственной информацией. Поэтому аналитические отчетные формы в передаче не нуждаются, и при наличии полной справочной и первичной информации могут формироваться в любой точке учета. Оставшиеся типы объектов учета подлежат передаче при необходимости, которая диктуется либо методиками учета, либо функциональностью информационной системы, либо иными соображениями. Итак, перечень данных для передачи определен.
Обратимся теперь к следующему соображению. Во многих СУБД организация обмена данными происходит на уровне таблиц. Отметим важную особенность такого способа организации обмена в условиях задачи: при многонаправленном асинхронном изменении данных одного объекта реального мира, хранящегося в базе данных, может произойти ситуация, когда он станет таким, каким бы никогда не стал, если бы изменения происходили в синхронном режиме. При этом принцип сводимости данных будет выполняться. Происходит нарушение принципа транзакционной непротиворечивости (п. 1.3).
Примером может служить любая реалия, содержащая информацию А и В в двух таблицах. Если в первой точке РБД меняют данные, хранящиеся в первой таблице на А , а во второй точке меняют данные из второй таблицы на В , то после сеанса обмена получится реалия, содержащий информацию А В , с возможно нарушенной логической целостностью уровня базы данных [50]. Во избежание таких ситуаций при реализации обмена придется описывать правила, которые позволят контролировать многосторонние изменения данных [46]. Другим примером такого рода ошибок могут быть логические противоречия в данных двух разных реалиях, связанных между собой, которые происходят таким же образом, и также являются нарушениями целостности уровня базы данных.
Опишем метод проектирования и способ организации репликации данных, который позволит избежать процедур ручного восстановления целостности распределенной базы данных. Метод основывается на передаче объектов, как совокупности данных [7], [10], [33], [56], [57]. Для этого необходимо выделить из массы таблиц группу, описывающую объект. Также необходима возможность указания связи объектов между собой, экземпляры которых будут выгружаться вместе экземпляром определяемого типа. Таким образом, таблицы базы данных разбиваются на группы, относящиеся к объекту. Будем называть такую группу таблиц - типом объекта, а объектом будет называть обособленную совокупность записей в этих таблицах — экземпляр типа. Покажем, что такой метод проектирования и организации асинхронной многосторонней репликации позволяет выполнить требования принципа транзакционной непротиворечивости там, где традиционные способы асинхронной репликации удовлетворяют лишь требованию сводимости данных. Также покажем, что такой метод асинхронного тиражирования повышает целостность РСБД.
Число согласований асинхронной репликации с выделением объектов
Используя эти переменные, можно подсчитать приблизительное количество изменений, которые должны будут быть отосланы на другие узлы при начале сеанса обмена: In_updates к Disconnected_Time х TPS х і (2.1)
Поскольку каждый узел производит такое количество изменений, то количество принимаемый изменений на одном узле приблизительно равно: Out_updates « (N- 1) х Disconnected_Time х TPS х і (2.2)
Необходимость согласований возникает в том случае, если множества входящих и исходящих изменений для таблиц пересекаются. Вероятность того, что изменение попадает в оба множества, согласно [29], [39], [60], [71], рассчитывается по формуле: In_updates х Out_updates _ Р (collision) - obRcS _ (N -1) х (DisconnectedTime x TPS x i)2 ObjecTCount (2 3)
Формула (2.3) показывает вероятность того, что при сеансе обмена согласования понадобятся для одного узла. Общее число согласований, которое может возникнуть в системе с использованием традиционной асинхронной репликации, можно вычислить по формуле: N Reconciliation Rate; = Р (collision) х , - Disconnected_Time Nx(N-l)x Disconnected Time х (TPS х і)2 = І - = ь — (2 4) Object_Count ;
Пусть С — множество изменений для объектов, порождаемых транзакцией, в рамках репликации с выделенными объектами. Обозначим его мощность через j. Поскольку объект представляет собой совокупность таблиц, то введение в модель репликации объектов действует как функции fn: С - С; fn (сь..., ck) = с т, где n - число объектов, m n; (cb...,Ck) cC,l k i. А, значит, согласно формуле (2.4) число согласований для репликации с выделенными объектами будет равно: Reconciliation_Ratej = Nx(N-l)x Disconnected Timex(TPSxj)2 Object_Count к J
Метод выделения, используемый в репликации, позволяет группировать таблицы, согласно их принадлежности объекту. Такая группировка снижает количество записей об изменениях относительно традиционной репликации, поскольку отмечается только факт изменения экземпляра объекта, а не всех его таблиц. Однако уровень числа согласований при этом не уменьшается.
Действительно, выберем произвольное число к такое, что с єС. Тогда,, найдется такое подмножество (cs,..., Ck) с С, s к і, и такая функция fn, что: fn (cSJ. -, Ck) =c m, где c m є С . Следовательно: Reconciliation_Ratej = Reconciliation_Ratej (2.6)
Таким образом, доказано, что асинхронная репликация с выделением объектов не увеличивает уровень числа согласований в РСБД.
Целостность и непротиворечивость данных в РСБД с асинхронной репликацией
Покажем, что асинхронная репликация с выделением объектов повышает целостность данных, а также позволяет достичь транзакционной непротиворечивости второй степени в тех случаях, где традиционные способы репликации приводят только к сводимости данных [5]. Выберем произвольные тип такие, что cmeCm и сп єСп, m Ф п -изменения таблиц на узлах тип соответственно. Предположим, что при репликации данных эти изменения приводят к нарушениям целостности. Для выбранных тип, найдутся такие подмножества (сь..., cm) cz Ст, к т im и (cs,..., cn) cz Cn, s n in и такие функции fm и fn [30], что: fm (сь..., ст) = с т, где с т є С т; fn (cs,..., Cn) = cn, где cn є C n. To есть, для любых двух изменений таблиц в обычной репликации после перехода к репликации методом выделения объектов найдутся также записи об изменении объектов. Рассмотрим первый случай, при котором с т и с п — изменения одного и того же экземпляра объекта на узлах m и п, то в результате сеанса репликации данных, произойдет конфликт изменений, который будет разрешен. Таким образом, нарушения целостности данных не произойдет. Также, такой метод репликации приведет к тому, что данные будут удовлетворять условию транзакционнои непротиворечивости данных второй степени. Традиционный способ потабличной репликации приводит только к сводимости данных.
Рассмотрим второй случай, когда с т и с п— изменения экземпляров различных объектов. Если эти объекты связаны между собой, то этот случай повторяет описанный выше, а значит, будет соблюдена целостность данных и условия транзакционнои непротиворечивости второй степени. Нарушение целостности может произойти, только если эти объекты не связаны между собой. В этом случае администратор системы асинхронной репликации, разрешив нарушение целостности, может изменить схему реплицируемых данных и добавить связи в такие объекты.
Третий вариант - это случай, когда с т и сп являются изменениями различных экземпляров одного и того же типа объекта. Нарушения ссылочной целостности возможны в случае, если какая-то из таблиц объекта предназначена для хранения древовидной структуры. Также возможны и другие нарушения целостности: уровня перехода, уровня сущности.
Функциональная модель системы асинхронной репликации
Модуль загрузки данных (ЗД) состоит из нескольких подсистем. На первом шаге загрузки происходит проверка на изменение схемы реплицируемых данных. В случае обнаружения изменений процесс загрузки останавливается, если изменения на принимающей стороне произошли позже, либо происходит синхронизация схемы данных, в результате которой принимающая сторона обновляет свою схему. Реализация этого механизма ложится на подсистему загрузки.
Следующим этапом загрузки является обработка результатов предыдущей выгрузки. Принимаются данные о результатах загрузки объекта на удаленных узлах, и идет их обработка: после получения данных об успешной загрузке объекта на всех узлах РСБД строка журнала изменений об этом объекте удаляется. Эти действия проводятся в подсистеме обработки результатов выгрузки и загрузки.
На следующем шаге САР проводит обработку поступающего (входящего) журнала изменений для исключения записей, которые загружаться не будут. Это может происходить в случае, когда обрабатывается запись об объекте, экземпляр которого уже загружался ранее и был изменен позднее времени изменения обрабатываемого экземпляра. Такие записи исключаются входящего из журнала изменений. На этой же стадии происходит проверка на наличие изменений в загружаемом объекте в собственном журнале изменений. В случае обнаружения подсистема загрузки передает данные в подсистему определения победителя, которая действует по любому настроенному алгоритму и из записей двух журналов изменений оставляет только одну (п. 3.1). После обработки входящего журнала изменений происходит следующая стадия проверка возможности загрузки - проверка ссылочной целостности. Проверка ссылочной целостности проходит в соответствующей подсистеме. Процедуры проверки подготавливаются подсистемой генерации скриптов из модуля НУ. Во время исключения записей из входящего журнала изменений происходят обращения к подсистеме обработки результатов загрузки и выгрузки, с целью формирования списка записей о результатах загрузки. Так при невозможности загрузки изменений из-за нарушений ссылочной целостности создается запись о неудачной загрузке. При обнаружении данных о загрузке объектов с более поздним временем изменения, создается запись об успешной загрузке, но запись из входящего журнала изменений удаляется до загрузки.
Подсистема блокировок предназначена для блокирования таблиц, с данными подлежащими загрузке, а также таблиц со схемой реплицируемых данных. Подсистема блокирует таблицы перед началом загрузки данных и после снимает блокировки после окончания процесса загрузки данных. Этой подсистемой обеспечивается снятие и установка ограничений целостности внешний ключ, и восстановление счетчиков для identity-полей в таблицах, куда загружались данные. Инструкции этих действий подготавливаются подсистемой генерации скриптов.
После работы подсистемы блокировки происходит непосредственная загрузка изменений. Данные загружаются согласно инструкциям, подготовленным подсистемой генерации скриптов модуля НУ. Инструкции подготавливаются для каждого действия - удаления, вставки или изменения объекта. Хотя для последних двух действий в журнале изменений не делается различий, на практике это различие легко установить по наличию экземпляра объекта в локальной копии РСБД. Непосредственная работа по загрузке происходит в подсистеме работы с данными.
При загрузке происходит также запись ее результатов и определение статусов загруженных объектов, которое производится в соответствующей подсистеме. Подсистема определения статуса оперирует уже инструкциями, предоставленными администратором или проектировщиком схемы реплицируемых данных.
После загрузки данных подсистема блокировок снимает блокировки с таблиц, устанавливает снятые перед загрузкой ограничения целостности, и исправляет внутренние счетчики для identity - полей.
Построим логическую функциональную спецификацию - подробное описание того, что должна делать САР. Диаграммы потоков данных (DFD) [12], [13], [14], [19], [27], [28], [35] являются основным средством моделирования функциональных требований проектируемой системы. С их помощью эти требования разбиваются на функциональные компоненты (процессы) и представляются в виде сети, связанной потоками данных. Для изображения DFD традиционно используются две различные нотации: Иордана (Yourdon) и Гейна-Сарсона (Gane-Sarson). В настоящей работе будем пользоваться второй нотацией.
