Разработка программного обеспечения для формирования базы данных для государственной итоговой аттестации 9 классов
Дипломная работа - Компьютеры, программирование
Другие дипломы по предмету Компьютеры, программирование
действия по устранению их конфликта, указанное определение следует расширить.
При рассмотрении схемы синхронизации БД типа звезда будем говорить об одновременной синхронизации двух и более баз данных. Например, на рис. 1 синхронизируется состояние трех БД за один сеанс репликации.
Опишем правила, с помощью которых можно получить левые части всех правил разрешения конфликтов версий записей.
1.Запись может быть создана только в одной БД. Поэтому предикат ins может присутствовать в левых частях только в единственном экземпляре и сочетаться только с предикатами nil. Максимальное количество таких сочетаний равно количеству БД, состояние которых одновременно синхронизируются.
2.Остальные варианты правых частей формируются путем перебора всех вариантов сочетания предикатов nil, upd и del. Среди них будет ровно один вариант, такой что: nih1 & nih2 & ... & nilN . Этот вариант следует отклонить, как не существующий.
.Для каждого сгенерированной левой части подсчитаем количество предикатов, которые зависят от времени (upd, del). Если таких предикатов более одного, то такую левую часть следует повторить 3K-1 раз, если использовать три вида соотношения времен (, =) и 2K-1 - если использовать два вида соотношения (), где К - количество предикатов, зависящих от времени, сочетая их с полученными вариантами состояний.
Количество левых частей растет пропорционально степенной функции. Если для двух БД количество левых частей импликаций равно 16, то для трех БД уже 114. Случай 2-х БД есть вырожденный случай звезды.
2.3Схема Сеть
В этой схеме за один сеанс репликации синхронизируются состояния только 2-х БД, однако, одна запись может дрейфовать по всей сети. Для того, чтобы все БД были синхронны, требуется исполнить все репликации (рис. 2).
В этой структуре возможна ситуация, которая изображена на рис. 3. После того, как была выполнена синхронизация БД1 и БД3 (Р1) в БД1 добавляется новая запись (ins1). При следующей репликации Р2 эта запись переносится в БД2 (ins2). Затем, при синхронизации состояний БД2 и БД3 (Р3) запись вносится в БД3. После этого запись модифицируется в БД1 (upd1). При разрешении конфликта версий записей при репликации Р4 получается ситуация, при которой для базы БД1 запись имеет статус upd, а для БД3 - ins. Таким образом, для успешного разрешения конфликтов версии в левых частях правил следует предусмотреть ситуацию, в которой символ ins сочетается не только с символом nil, но и с символами upd и del.
Правила образования левых частей для этой схемы аналогичны правилам, применяемым для схемы звезда с учетом приведенной выше особенности.
2.4Практическая реализация
Пусть требуется обеспечить репликацию данных между двумя базами DB1 и DB2. Для построения правил разрешения конфликтов версий записей выберем схему звезда. Пусть в базе данных DB1 существует таблица, схематичная структура которой выглядит следующим образом:
RTable1(PK, Data, DBID, RID, ChType, TransTime)
где PK - первичный ключ;- данные хранимые таблицей;- идентификатор БД, в которой была создана запись;- идентификатор записи для репликации, который был присвоен при создании записи;- код типа изменения, произошедшего с записью, целочисленный тип данных;
Для ChType примем следующую кодировку:
0 - с записью ничего не произошло
1 - запись внесена;
2 - запись изменена;
3 - запись помечена на удаление.- момент времени, в который произошло изменение записи. Также допустим, что база данных DB2 также содержит таблицу RTable1 идентичной схематичной структуры с теми же наименованиями атрибутов. Несложно заметить, что этот вариант схематичного представления структуры таблицы эквивалентен Table1. При этом
RK = {DBID, RID}; Ver_Stamp = {ChType, TransTime}
Пусть существует таблица, которая будет разрешать конфликт версий записей указанных таблиц. Ее схематичная структура будет следующей:
_Table(time_relation,state1,state2,action1,action2),
где time_relation имеет целочисленный тип и следующую кодировку:
1 - t1 > t2;
2 - t1 = t2;
3 - t1 < t2,
где t1 и t2 - моменты изменения состояния записи соответственно в DB1 и DB2.и state2 - состояния, в которых находятся записи в соответствующих базах. Их кодировка совпадает с кодировкой ChType.и action2 - действия, которые следует предпринять для разрешения конфликта версий записей. Тип данных этих полей, а также их кодировка могут выбираться разработчиком по обстоятельствам. Заполним поля time_relation, state1 и state2 таблицы Res_Table в соответствии с правилами образования левых частей схемы звезда, а поля action1 и action2 в соответствии с тем, как требуется разрешать конфликт версий записей в том или ином случае. Для распознавания соотношения моментов времени будем использовать следующую функцию:
CREATE FUNCTION time_moment_relation
(time1 datetime,datetime)intres as inttime1>time2res=1time1=time2res=2time1<time2 select res=3
end
RETURN res
END
Для того, чтобы обнаружить актуальные изменения в таблице требуется еще одна точка на временной шкале. Это момент завершения последней успешной репликации между этими БД. Обозначим его как SRT. С каждой записью что-то когда-то происходило, и если не установить некоторого порогового значения момента времени, то сравнивать версии придется для всех записей, находящихся в RTable1.
Используя указанное ограничение, запрос
Select
DBID,
RID,,.RTable1
(TransTime > SRT)
вернет значения RK и Ver_Stamp всех записей, которые были внесены в таблицу, либо